muzigram

山椒は小粒でもピリリと辛い

2017/06/22

UnityでSceneやPrefabがコンフリクトした時のUnityYAMLMergeについて

■はじめに
Unityでチーム開発する際ってみんなどうしてるんすか案件の話。
つまりは同じSceneやPrefabを触ったときにコンフリクトとか起きると思うんですけど、どうやってその問題を
解決、もしくは回避してますか?
  • 声かけて同じ物を触らないようにするのか -> 運用でカバーしてもミスは避けられない気がする。
  • git-lfsのロック機能を使うのか -> YAMLを登録するのなんかずれてる感じがしません?

■つまり?
SceneとPrefabの作業が被ってYAMLマージすか死ねますね。

■対策

あるのか?あるらしい、以下
https://docs.unity3d.com/jp/540/Manual/SmartMerge.html

■検証

今回は

Unity 5.5.1p4
SourceTree 2.5.2 (111)
の環境で試しました。

解決済みになってるのにコンフリクトが解決されてなかったりしてつらすぎる。うまく動いてなくね?というわけで調査。

* http://labs.gree.jp/blog/2015/04/13836/
* http://qiita.com/Shaula/items/ebe778c232c30aff46fd
* http://tsubakit1.hateblo.jp/entry/2015/05/14/040852

だいぶ参考にさせてもらったのですが、少なくとも自分の環境(5.5.1p4)では上記だけではうまくいかない模様。特に「auto」というファイルでツールを指定するところがうまく行きません。

フォーラムみたり
https://www.reddit.com/r/Unity3D/comments/39bdq5/how_to_solve_scene_conflicts_with_unitys_smart/

色々触ってみた結果、以下のような挙動をするらしい


  1. gitでマージする
  2. SceneやPrefabでコンフリクトが発生する。
  3. CLIならgit mergetool。SourceTreeなら外部マージツールで設定したUnityYAMLMergeを起動。
  4. マージ作業を行ってくれる
  5. どうしても解決できない更新があった場合(同じPrefabの同じパラメータを触った場合)
  6. /Applications/Unity/Unity.app/Contents/Tools/mergespecfile.txt で指定した外部マージツールを起動させる。
  7. マージツールでDiffを解消して、マージツール終了するとUnityYAMLMergeに戻り、終了。


■いろいろつまったところ

MacのデフォルトのDiffツールとUnityYAMLMergeの相性が悪い。Diffツールのファイル保存を待たず、UnityYAMLMergeが終了するのでDiffが残ったままのファイルが残り、Sceneが死ぬ。ということでP4Mergeを利用してます。

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: Cannot find transform parent for fileID
で死ぬ。ファイル削除とかそのあたりなのかなー。あんまり詳しくは見てない。

autoファイルで指定するって話があったけど、認識してくれなかった。結局app内のファイル書き換えた。←マジで?
自分はこんな感じで指定してます。
#
# UnityYAMLMerge fallback file
#
# Modify the next two lines if scene or prefab files should fallback
# on other that the default fallbacks listed below.
#
# %l is replaced with the path of you local version
# %r is replaced with the path of the incoming remote version
# %b is replaced with the common base version
# %d is replaced with a path where the result should be written to
# On Windows %programs% is replaced with "C:\Program Files" and "C:\Program Files (x86)" there by resulting in two entries to try out
# On OSX %programs% is replaced with "/Applications" and "$HOME/Applications" thereby resulting in two entries to try out
unity use "/Applications/p4merge.app/Contents/Resources/launchp4merge" "%b" "%r" "%l" "%d"
prefab use "/Applications/p4merge.app/Contents/Resources/launchp4merge" "%b" "%r" "%l" "%d"
* use "%programs%/p4merge.app/Contents/Resources/launchp4merge" "%b" "%r" "%l" "%d"
#
# Default fallbacks for unknown files. First tool found is used.
#
それでも、マージが失敗するときがある。何回かmergetoolを起動すると動くことがある(いやいやいや…




結論

git mergetoolやSourceTreeの外部マージツールにUnityYAMLMergeを適用。
/Applications/Unity/Unity.app/Contents/Tools/mergespecfile.txt

細かくブランチを切って、細かくマージする。に勝る対策はない感じ。
それでも、ちょっとした更新のマージならUnityYAMLMergeが吸収してくれるのではないか。という手応えはある。
ただ、情報がすくなかったり、機能が更新されたりすると、また喧々諤々としそうではあるけども。
というわけで、うまい感じのgit-flowを構築しつつ、UnityYAMLMergeを頼っていくるのがいいのかなという感じ。

Unityを触っている開発者がココらへんどうやって運用してるのかいい感じの運用やツールがあったら教えてください

2017/06/12

FirebaseとUnity

個人で製作するUnityアプリとFirebaseは相性が良いのではないか?という直感があるので
改めて検証していこうと思う。

なんで?


  • サーバー管理が(自前で用意するよりかは)必要ない
  • ライブラリが一通り揃ってる
  • ホスティング、認証サービスも使える。
  • AdMobとも親和性があるので
  • Push通知も行ける。
  • 開発環境であればほぼノーコストでOK
といった利点があると思う。

欠点として考えられるもの

  • Parseの二の舞いの可能性
  • RDBとは違ったDB管理の理解
  • CloudFunctionがJavaScriptのみなので苦手な人は大変そう
  • 移行を希望するときの選択肢のなさ


ドキュメント

https://firebase.google.com/docs/auth/unity/password-auth?hl=ja

2017/06/11

lambdaでSlack Interactive Message. まずはHello world

概要

http://tech.mercari.com/entry/2017/05/23/095500
をみてGo + AWS lambdaでJenkins氏を叩くか。と思い至る。

環境

⋊> ~ sw_vers
ProductName: Mac OS X
ProductVersion: 10.12.4
BuildVersion: 16E195
⋊> ~ go version
go version go1.8.1 darwin/amd64
⋊> ~ docker --version
Docker version 17.03.1-ce, build c6d412e
⋊> ~ aws --version
aws-cli/1.11.97 Python/2.7.10 Darwin/16.5.0 botocore/1.5.60

準備

ドキュメントをかき集める


手順

ざっくりと環境インストールと設定を行う。


  • AWS CLIをインストール
  • AWSにIAMを用意、AccessKey,Secretを作成して、CLIに登録する。←aws configure
  • Docker環境も用意する必要がある(https://docs.docker.com/docker-for-mac/)
eawsyにあるコマンドを試しに実行してみる。
wget -qO- https://github.com/eawsy/aws-lambda-go-shim/raw/master/src/preview.bash | bash
# "Hello, World!" executed in 0.45 ms
の中身を覗いてみると、DockerでGoコードのビルド、
AWS環境の整備(lambdaを実行できるように)、アップロード等を行っている。

lambdaを作成したらAPIGatewayで公開。ひとまず、HelloWorldまで完了。


2016/11/06

サイクリングしまなみ当日

前日

松山ー>今治 今治ー>松山。行って戻ってくる。明日も同じことをやる模様。

登録、ゼッケンの受取等は前日の為松山から今治へ移動。(片道1時間程度
輪行袋で自転車を持ち歩いている人もちらほら。ちなみに自転車は当日チェックとのことで、会場に無理に持ってくる必要はなかった模様。1時間おきにループバスも出ていたので歩きでも問題なし。


荷物預かり用のザックはけっこう大きめ(iPadとの比較

前日会場の様子。

お、おう

スポンサーの晩餐館。飲みながら走る?

は か た の し お !

当日


04:00 起床
05:00 松山駅集合(サイクルトレインを予約済み)
05:20 松山出発
06:20 今治到着
06:50 ループバスでサイクルステーション到着
07:00 イベント便で送っておいた自転車を受取り、組み立て、スタート地点に移動。
07:20 知り合いに挨拶も済ませ、荷物を預けてスタート地点に移動。

4時起きなのにけっこうギリギリだったな、という印象。スタッフの方々にはいろいろ誘導なりしていただいて感謝。

コースについて
合計110km。高速道路から大三島一周、伯方島、大島を得て今治に帰るルート。

http://latlonglab.yahoo.co.jp/route/watch?id=2b954f1e63a2d6a9aa9dd5b52a8dd69e

高速道路を走れることについて
30kmオーバーをノンストップで走り続けられる体験は貴重ですよ!道路の継ぎ目には重いゴム板が敷いてあるようでひたすらノンストップに走り続けることができます。
ちなみに、高速道路を封鎖して走れるイベント。というのはこのサイクリングしまなみだけ!

沿道の応援
坂のめっちゃ足着きたくなるタイミングに応援に来てる人はなんなんすかね。
あそこで応援されると頑張るしかない。定期的に沿道で応援してくれる人や運営のボランティアがいて、拍手、声援、応援をいただけました。普通に生活してるだけではここまで人に応援される機会なんてないので謎の感動が。地元の人からしたら高速道路は封鎖



 盲点だったのは橋を渡るためのアプローチ坂で、島を渡るために登って降りて、登って降りてを繰り返すのでなんだかんだ獲得標高が増えて最後の方はひたすら軽いペダルを無心で回し続けてました。あと、ゴール前のアースランドしまなみに至る道が鬼畜。

完走

最後の方は若干渋滞もあって安全運転重視。ゴールは16:00、リミットの1時間前でなかなかにギリギリでした。ゴールした後のフィニッシュエイドは焼豚玉子飯をチョイス。最高のうまさ。



持ってきてよかったもの

サイクルジャージの下に着るベースレイヤー。吸湿速乾に優れているので、山登った後の下りに体を冷やして調子を崩すこともなく走れました。

 
当日の天気は12度〜20度くらいだったので、ウインドブレイカーの代わりにカバーを選択、暑くて脱いだとしても荷物にならないだろうという判断。結果正解。

 あったほうがよかったもの


・ビンディングシューズ、ペダル:坂道とか変わってくるんだろうなーという
・サングラス:向かい風が強くて写真写りが最悪だったんじゃ・・・
・カメラ:スマホのカメラだとやっぱり揺れが酷いとか表示時間の問題とか色々あるので、ソニーのアクションカメラとか買いたい欲がましてきてます。

愛媛、松山、今治について

愛媛は観光する人にとってとても過ごしやすい環境が整ってますね。けっこう色んな場所に愛媛Wifiがあって、松山の路面電車も頻繁に行き来してて気軽に乗れます。
空港から松山駅も近くにあり、自転車用のスペースも用意してあって最高。

レース後の疲れを癒やしてくれたキスケBOXも最高でした。
http://www.kisuke.com/service/box/

道後温泉、平日昼間は流石にガラガラ、中は普通の銭湯っぽかった


松山城は体験コーナーが充実

おすすめされた霧の森大福。開店と同時にいったけど10人くらい並んだ。

2016/11/03

サイクリングしまなみに参加してきました。準備編

最高のサイクリング体験をしてきた話

サイクリングしまなみ2016に参加してきました。
結論からいうと、しまなみ海道は最高であるし、愛媛は最高だった。
お陰様でなんとか完走(制限時間1時間前…)することもできました。エンジニアには自転車愛好家も多いので後に参加するひとや、しまなみどうなん?って人のためにいろいろ書き残していきたいと思います。



サイクリングしまなみについて


サイクリングしまなみは2年に1回のペースで行われるらしく今回で3回目(プレ大会を含む)特徴としてはなんといっても、高速道路を封鎖して行われる。という点。信号もなく、整った道路を30km以上ひたすら走リ続けることができます。しかも雄大な瀬戸内の景色とともに!



こーんな感じの景色がずっと続くわけです。最高か?

登録

抽選の受付等が始まったのが2016/4月末5月頭くらい。
サイクリングしまなみはかなり抽選倍率が高く、地元の人も2割くらいしか割り当てがない。と嘆いていました。しかし、今回はANAの「旅作」経由で申し込むとコースDの出走権がもれなくついてくる。というプランがあり、速攻で飛びつきました。
(コースDは30km程高速道路を走った後、大三島一周、伯方島通過、大島を超え、今治に戻る。合計110kmのコースです)

 半年前の時点で今治のホテルに止まるプランはほぼ埋まっていて、結局松山にホテルを取り、当日4時起きで頑張るという流れに。半年前の時点ではサイクルトレインの予約の詳細等もなく、半ば行っとけ予約のような形でしたがなんとかうまく回りました。
 松山のホテルサンルートを陣取り、飛行機の往復を予約して4万円程度。安い!今治にホテルを確保できれば当日はだいぶ余裕ができると思います。

旅における自転車の取扱いについて

最初は飛行機輪行を、と考え、旅作専用のサイクルトレインも予約したのだけれども帰りの羽田〜自宅間が帰宅ラッシュとかぶることや、最終日の観光のことを考えると自転車イベント便にしてしまうのがベストという考えに至りました
http://www.seino.co.jp/seino/service/domestic/cycling/

 サイクリングしまなみではイベント便という連動が行われており、上記のサービスで送った自転車を当日、西濃運送のサイクルステーションで受取り、そこからスタート地点まで移動、帰りもそこで梱包する。という便利なしくみがあります。ありがたいことに、当日は今治駅からサイクルステーションまでのバスも出ており大きな混乱もなく移動することができました。
箱はけっこう大きめです。

自分はヘルメットなんかも送っちゃいました。

旅行プラン等

自転車を送ることにしたので、けっこう気楽なもんです。
大会前日に松山入り、大会参加の次の日の便で帰る。というプランにしたため、
愛媛観光もするぞ!という意気込み。これは大成功でした。ココらへんの旅行記はのちほど。

準備編まとめ

・サイクリングしまなみは人気イベントの為、抽選が厳し目、スポンサーにANAが入っていれば旅行プランがありそうなので、確実に出走したい人はそちらがおすすめ。
・自転車輪行に不安がある人は自転車イベント輸送便を利用するのがよい。(価格は1万プラスα)
・今治近辺のホテルは半年前でも埋まっているので松山等も視野に入れよう!



2016/09/30

LineBot動かしてみた #golang #linebot #heroku

始まり


  • LineさんのStreaming APIが公開されたようです。
  • とりあえずやれ(JUST DO IT)動かすぞの精神で動かします。 
  • 今回はGoとHerokuを使います

 JUST DO IT!!!!


今回はGoとHerokuを使います。理由は以下
 コードとりあえずGithubに。(と言っても、SDKに入ってたエコーをherokuに上げるように修正したのみ。
  https://github.com/mogeta/lbot

手順、および詰まった箇所等


  • そもそも、どこから登録すんだ?
  • channel_secret?channel_token?どこだ?ってなるので、素直に動画見たほうが良い。
  • webhookに指定するURLはhttps必須。とりあえず試す場合、herokuやLet's Encryptに頼ることになるかな?
  • IPのホワイトリスト指定。起動して、対話するとこんな感じでログが出てる。ひとまず動かすだけなので、指定されたアドレスをさくっと登録しときましょうねー。
linebot: APIError 403 Access to this API denied due to the following reason: Your ip address [<ipアドレス>] is not allowed to access this API. Please add your IP to the IP whitelist in the developer center.

herokuで起動の手順


  • herokuにユーザー登録。
  • herokuツールベルトのインストール
  • 後は各自、コマンドライン上でコマンド打っていく
  • 大体公式の手順書に従う感じでやれば問題ない、Goの場合はここ
  • heroku create 
    • >これだけでサーバーが立ち上がる、URLとgitリポジトリが示される
    • >デプロイしたいアプリがあるディレクトリでかつ、git initしとくとherokuというリモートを追加してくれる。
    • >というかgit initしてなくて、コマンドが動かんぞ?ってやってた。
  • herokuにgit push
  • 環境変数を指定。
    • >herokuのページから立ち上げたサーバーのSettings->Config Variables
    • >CHANNEL_SECRET
    • >CHANNEL_TOKEN
    • >それぞれLineの管理ページから取ってきましょう

動かしてみた

動いたーやったー。特に感動はないけど。
たまに反応してないのはホワイトリストに登録してないアドレスから来てるからっぽい。知識とheroku力が足りてないのでとりあえずスルーしてる。


終わりに

 優勝賞金1,000万円の「LINE BOT AWARDS」があるらしいのでなんか作ってみようぜ。つーことですね。

参考URL
https://github.com/line/line-bot-sdk-go
https://developers.line.me/

2016/09/29

サービスを作りたいエンジニアってなんだろうなー。リアルウォンテッドリーに行ってきた。

リアルウォンテッドリーに参加してきましたよっと。
お酒も入ってるけど、一気に書かないとブログ書かないなと思ったので。
(エンジニアという表記がブレてるなーと思ったけど、大体ITのエンジニア、いわゆるWeb系プログラムを書いたりする人と思ってください)
あ、コーヒー、めっちゃうまかったです。↓
 自分のような緊張しいには面接の場よりも数段カジュアルに仕事や技術のことが聞けたのでだいぶありがたい集まりでした。(それでも緊張してかなりしどろもどろ感もあったけど)

 どういうエンジニアを求めていますか?という質問をすると、多くの企業で「サービスを作りたいエンジニア」もしくはそれに準じたニュアンスをもらった。自分はどちらかと言えば、技術を追求して価値を高めるエンジニアではなく、今ある状況、使える技術においてどのように最大利益を追求するか?というエンジニアだと自負しているのでこの点に関してはだいぶ心強いなと思った。(ちなみに、自分と仕事をしたことがあるエンジニアや同僚に聞きたいんだけど、この点ってニュアンス合ってます?技術を追求する方のエンジニアって思われてる?)

 余談)前職ではベトナムのエンジニアと協業でゲームを製作していたのだけれど、エンジニアとしての仕事よりも、ゲームの仕組みづくりやどうやったら広告を見てもらえるか、ユーザーが続けたいと思うモチベーションはなにか。どうやってゲームが遷移するのか。みたいなのを考えてることが多かったなーなどとつくづく。一年かけて、結局3,4回フルスクラッチで作り直してポシャったんだけど。)

 ところで「サービスを作りたいエンジニア」ってなんだろう。という根本的な疑問が湧いてきている。思いつく限り、適当に羅列していく。

  • 企画から参加し、意見を出せるエンジニア
  • 改善案を提案出来る。
  • 自分ごとのように考える。
うーん、もうちょい具体例を出したいな。どういうのがいいだろう。自分はゲーム業界畑だったのでそちら側に流れがちになるけど。
  • どのタイミングで動画広告だす?それってユーザーがみたくなる?、じゃあこのタイミングで(ry
  • この数字が撃破したモンスターだと伝わるように魂的なエフェクト載せません?
  • PCとかスマホとかゲームのビュー複数持つならサーバー側APIにしてSAPに挑戦してみます?
一方でサービスを作るITエンジニアとして自分が弱いなーと感じる部分
  • 金になるコンテンツを企画する。金を払いたくなる機能
  • データ分析に基づく提案
技術に基づく提案っていうのがアプローチとしては一番かっこいいんだろうな。なかなか、過去のキャリアでそういうのって言えてないな。

 でもそれって今では割りと普通のプログラマ、エンジニアなんじゃないかなーという気もする。(業界にもよる?)。Web寄りの会社なんかだとアジャイル、スクラム。といった単語が浸透して、タスクも「プログラムの機能一つ」という状態から「ユーザーストーリーの完成」という状態になってきて、「プログラムや機能を作って終わり」ではなく「サービスとしてユーザーに使ってもらう」「金を産んで完成」という形になってきたんだなと。

ーーーーー区切り線ーーーーーー

 なんでこんな支離滅裂な文章書いたかっていうと、自分は「サービスを作りたいエンジニア」だと思っているけどそれを、転職時アピールとして「なぜならこういうことをやってきたし、これからもこういうことをやりたいと思っている」にどうやって昇華させようか、という悩みに直面したから。

 今までは「ゲームを楽しむ人を増やしたい、だから誰でも手に取れる携帯ゲームを俺はやるんだ」とか「世の中がどんどん便利になって、豊かになっていくのなら、最後に求められるのはゲームだろ」って思うところがあってゲームをやってきたけど、ソーシャルゲームやガチャ、課金システムに対して、うまく折り合いがつけられない。

 ゲームじゃない業界にもいた事あるし、そもそもパチンコ、パチスロの仕事をしてた時はゲームじゃねえよなぁ。と思ってたので他業種でも全然構わないとは思ってるけど、外から見た人は自分を「サービスを作りたいエンジニア」としてちゃんと評価してもらえるのか。という疑問もある。


まとめじゃないまとめ
  • サービスを作りたいエンジニアとしての自負はあるけど難しいね。
  • Go言語の仕事してみたいけど、Rubyおおいねー。(白目
  • 元ゲーム業界です。って人多いなー。スマートフォンゲーム一段落感
  • どのジャンルのエンジニアも募集してます。のお互いの難しさ
  • 自分のような浅く広くなんでもやってました的なエンジニアの難しさ。
 リアルウォンテッドリーはどんなスタートアップがあるのか?とか話気軽に聞いてみたいなーってフェーズの方はかなりおすすめな感じがしました。ありがとうございました。今、暇なんで職やら仕事は募集中です。