tech.kayac.com

(今年初の更新なので)あけましておめでとうございます! acidlemon です。今年も8分の1がおわりましたね! みなさん進捗どうですか? ぼくはダメです。


さて、本日はカヤック主催の技術勉強会の開催告知をお届けします。

きたる2月25日(水)、渋谷ヒカリエにてカヤックのエンジニアが最近アツい技術やノウハウについてトークをするtech.kayac meetup #0 を開催します。詳細につきましてはconnpassをご参照ください。

告知は以上です。

告知が淡泊すぎてスペースが余ってしまいました。せっかくなので駄文を書きます。

開催の苦悩

開催告知エントリになんでいきなり苦悩を書き始めるのかみたいな感じですが、まぁちょっとダマされたと思ってお時間がありましたら読んでみてください。

カヤックでは昔から毎週金曜日に社内で技術部勉強会を行っています。たまに社外のエンジニアをお招きして話をしてもらったりすることもあり、ぼくも「ペパボからドクターペッパーが好きな四天王が来る」と聞いてドクターペッパーを買いに走ったことがありました。

そんな歴史のある会なのですが、結構これ普通に外部で話をしてもっと広めたほうがよいよね〜みたいな内容が出てくることも多く、社内に埋もれてるのはもったいない! ということでパブリックな勉強会を数ヶ月に1回くらいのペースでやったらいいんじゃないかなぁと思いたちました。そこで、社内の協力してくれそうなエンジニア達を一人ずつ捕まえて協力を取り付けたので、実現とあいなりました。今回はまぁ最初だしということでパイロット版、#0です。

しかしながら、一つ問題がありまして。その問題とは、場所なんです。

カヤックはいま横浜にほぼ全社員が集まる支社があります。じゃあ横浜でやるかーと思ったのですが、都内の人は結構横浜にくるのが大変というのが過去にISUCON3反省会とかYokohama.pmを横浜で開催したときの印象としてありました。まぁそれは逆にいうと横浜から平日夜に都内の勉強会に出かけるのもちょっと大変という意味でもあります(私は鎌倉住まいなので終電マジ早い)。

ぼくは勉強会みたいなのは内容もさることながらやっぱりホスピタリティが大事だなと感じています。それはいくつものエンジニア向けイベントに参加してきたことから来ています。イベントを通してそういうことを教わったので、自分たちもホスピタリティを軽視するわけにはいかないよね、ということで色々考えました。

で、結論としては、都内の人が遠くまでくるのが大変ということであれば、自分たちが勉強会開きに出かけていけばいいのではないかな! という感じになりました。逆に都内のほうが遠いよ! って人たちも当然いると思いますが、別にずっと都内開催にこだわるというわけでもないので、次回以降は場所も含めてもうちょっとゆっくり考えて開催していきたいなーと考えています。

よし、出前だ出前だー! 都内に限らず勉強会出前していくぞ!

ということで、場所について苦悩した結果自ら外に出ていくことにした、というわけです。弊社には昔から旅する支社という文化がありまして、これをもじって旅する勉強会と題すればちょうどいいよね〜みたいな感じです。なんという予定調和。

とはいえ自社のスペースでやるのと違って場所代や遠征費みたいなところも気にしなきゃならないので、まぁ最初は近場でやろうかなということでパイロット版の旅する勉強会は「渋谷まで東横線で30分! 電車の旅!」となりました。

…とまぁ開催の経緯と苦悩はこんな感じなのですが、この話は続きがあるので残りは会場で話せばいいかなーと思っております。場所の広さの都合上お招きできるのは40人程度となりますが、早い者勝ちではなく抽選で勝手に決まりますのでどしどしお申し込みくださいませ。

この記事は tech.kayac.com Advent Calendar 2014 24日目です。

tech.kayac.com アドベントカレンダー、いかがでしたか?

こんにちは、@acidlemon です。今日はクリスマスイブ! 今年のtech.kayac.com Advent Calendar はお楽しみいただけたでしょうか? Unityあり、Golangあり、Rubyあり、Javascript/ECMAScriptあり、Perlありとバラエティに富んだ内容でしたね。個人的にはSwiftがなかったのが心残りなのですが…。まぁ来年若者にがんばってもらいます。

また、1日目でご紹介した、ぼくがノリで11月末にIKEAで買ってきたリアルアドベントカレンダーも無事ぼくの手元に帰ってきました。チョコおいしいです。

リアルアドベントカレンダー
※心に余裕がなかったらしく、「書いたら」が「買いたら」になっている…

さて、今年も残すところあと1週間あまりとなりました。先週金曜日まで仕事が多忙を極めて個人的にたいへんあらぶっておりましたが、ようやく落ち着きを取り戻して平穏なクリスマスイブを過ごしています(ひとりです)。

mirageがコンテナ内で動くようになりました

本日の記事は、今年の8月くらいにこのブログで記事にしたmirageの話の続きです。

あの記事以来社内でじわじわと使われ始めまして、先行プロジェクトによるバグ出しもおおよそ終わって安定期に入りました。弊社では主にCentOS6を使っていたため、CentOS6でのDockerは色々ハマリどころが多いという外部の知見から、なかなか開発環境のDocker化が進んでいませんでした。ただ、ちょうど来年上半期にいくつかのプロジェクトのdevサーバが移転するのに合わせて普及が進んでいきそうです。

今ぼくが考えてたのは導入を楽にするというところでして、当初はrpmパッケージを作ったらいいのではないかと思っていました。ただ、その後考え直しまして、お手軽に試すならDockerの中でmirageが動けばよいのでは? ということでこのたびDockerfileを用意してみました。

Dockerコンテナを管理するのをDockerコンテナ内からやるというのはだいぶ不思議な感じではありますが、DockerにアクセスするためのUnix Socketをdocker run -v /var/run/docker.sock:/var/run/docker.sockでコンテナに渡してやれば普通に管理できます。

あと、mirageはcgo要らずのPure Go実装な簡易データベースとしてleveldb-goを使っていますので、これの永続化も必要です。そこで、あらかじめサンプルとして用意したdocker_run.shでは-v /mirageでData Volumeを指定してDockerさんに/mirageを永続化するようにお願いしてあります。

この辺は昨日ドキュメントとにらめっこしてこれでいけるはず! という感じでスクリプトにしましたが、実際の細かい検証はインフラチームの頼れる若者、@tkuchikiにお願いしてやってもらいました。まいどありがとうございます。

その検証結果によると、docker run -v /mirageで永続化したものはdocker rm <container id>でコンテナを削除しても消えないが、docker rm -v <container id>で-v(--volume=true)を指定すると消えるとのことです。ご留意ください。

mirageは来年以降も任意のパラメータ渡せるようにするなどのアップデート計画があります。引き続きよろしくおねがいします。

mirage 開発秘話

さて! 事務的な話がやっと終わったので、ここからはなぜmirageが生まれたのかという小話をお届けします。クリスマスの読み物としてお楽しみください。

弊社の開発フローはチームごとに異なりますが、開発からリリースまでの流れで言うと、大体devサイトにまずデプロイして開発者(デザイナーなども含みます)が自分で確認し、stagingサイトにデプロイしてチームチェック/QAなどを行い、最後に本番サーバにデプロイしてリリース、という流れになっています。

devサイトは複数用意してあり、複数の開発ラインが同時で走っても大丈夫というような感じになっています。gitを利用していますので、gitでブランチを切り替えればすぐdevサイトもそのブランチの内容に切り替わるのでgit便利ですね。

しかし、いくつか問題もあります。一番大きいのはDBのスキーマが変わるときでしょうか。コマンド一発でスキーマをマイグレーションできるようにはなっていますが、そうはいってもテストデータを毎回クリアしているわけではないためマイグレーションに失敗してエンジニアが時間を取られることもしばしばあります。

また、いくつかのdevサイトを使い回して利用するのにはもう一つ問題があり、「最後に使ったのは誰か」「このdevサイトまだその人が使ってるのか」という非常に人間くさい問題があります。

新しい機能/デザインを作ったクリエイターがサーバで確認するために「dev01使ってるひといますかー?」「13時までに返事がなかったら使いますよー」などと毎回やるので、非効率です。常に全員がチャットを見ているわけでもないので、リアルタイムに「あ、今使ってます」と反応できないことも多いです。

この問題の解決のために、社内ではいろいろ策が講じられてきました。たとえばコレです。

風船部長

映っているのは弊社の技術部長の庄司です。背中になにか②と書かれた風船をつけていますね…。そうです。これは「オレが今dev02サーバを使ってるぞ風船」なのです。

なるほど! 風船置き場に風船があればそのdevサーバは使われていない、誰かの背中に風船がついていればその人がそのdevサーバを使っている! すばらしい! アナログ! エレガント!

しかしこの方法には問題がありました。

「風船は、いつか、しぼむ」

この写真は9月のチャレンジのときで、ちゃんとしたヘリウムの漏れづらい風船なのですが、それでもやっぱりそのうちしぼみます。

また、これに先立ち7月にトライラルしたときはちゃんとした風船では無く、デカイビニール袋にヘリウム入れて浮かせてみた、みたいな感じだったためこんな会話もありました。

17:03:08 fujiwara: ゴミ袋浮かんでるのは美観的にどうなのw
17:09:52 handlename: 頭いい方法ではありますねw
17:09:56 handlename: リーズナブルで目立つ
17:10:46 acidlemon: |'-')?
17:10:57 fujiwara: 今ヘリウム高いんだけどなw
17:11:24 acidlemon: 猿山より目視にて浮くゴミ袋を確認
17:11:40 acidlemon: 割り箸鉄砲で撃墜したい
17:12:08 syoji: 真下に俺いるから辞めてw
17:12:14 gs: w
17:12:22 acidlemon: 余計にやる気がUP

しかし、翌日にはゴミ袋はしぼみました。噂ではfujiwaraさんが会社に来ると空気の抜けた風船がインフラチームに流れ着いて落ちていたとかなんとか…

16:35:47 acidlemon: 風船作戦1日で終了か
16:36:00 gs: 全部沈没しました
16:37:18 fujiwara: ドメインを [username].dev.lobi.co みたいにして
16:37:33 fujiwara: 一人ずつdevを起動できるようにしたい…
16:38:07 acidlemon: さっきXXくん(PM)とDockerの話したらYYY(当時のプロジェクト)でも同じようにカジュアルにDockerで自分のdev建てたいって話になった
16:38:26 handlename: テストしてると人依存じゃなかったりするので、各自複数台用意できるようにしないと・・・

そうです! この会話がmirageの開発のきっかけでした。

そんなわけで生まれたmirage、意外とこういった悩みはどこのチームにもあるのではないかと思います。どうぞご利用ください。

こんばんは、@takashicompanyこと、タックルです。
普段はUnityでゲーム作ってます。
この記事は、tech.kayac.com Advent Calendar 2014 23日目となります。 がんばります。

100.png101.gif

ふと思い立って、弊社の象徴・マスコットキャラクターであるコンチ勝手に3Dドット絵にしたので、3Dドット絵を作るときのフローを紹介したいと思います。

ちなみに、出来合いのものはGitHubに一式あがっているので、もし欲しい方いたらどうぞ。

今回紹介する3Dドット絵作成フローはUnityのMecanimで人間のアニメーションそのまま適用できるようにしました。

下絵を描く

00.png

まずは、3Dモデルを制作する際の下絵から描いていきます。
下絵を描くツールは、特に指定はありません。なんでも良いです。
陰影や枠線などはつけず、全体象を捉えられるくらいでOKです。
できたら.png形式で保存しましょう。

3Dドット絵をつくる

01.png

今回はQubicle 2.0を使います。
Qubicle 2.0はフリーで利用可能(エクスポートなどはライセンスを購入する必要あり)です。
Windows/Mac版がリリースされており、Windowsのペイント感覚で3Dドット絵(ボクセルアート)を作ることができます。

201.gif

1. Qubicleに下絵をインポート

まずは、下絵をQubicleに取り込みます。 File > Import > PNG で選択できます。

取り込むとこんな感じで表示されるはず。
02.png

下絵で透過されていた部分が灰色になって表示されるので、魔法の杖ツールなどで選択して消してしまいましょう。
03.png

2. 下絵から3Dドット絵を削り出していく

下絵に奥(Z方向)に引き伸ばし、3Dモデルを削りだしていきたいと思います。
Tools > Extrude Tools を選択して、引き伸ばしを行います。
04.png

引き伸ばしができたら、後は鉛筆・消しゴムツールなどで、モデルを削って行きたいと思います。
04_a.png

完成したコンチはこんな感じ。
05.png

正面・側面・上面・斜めから見て自分のイメージとあっているかをチェックしながら微調整をするのがコツです。

3. 関節ごとに3Dドット絵を分割する

3Dドット絵モデルができたら、関節ごとに部品を分割します。

分割したいボクセルを選択して、Modify > Detatched > Sprit offで分割することができます。
今回、コンチはこんな感じで分割しました。
06.png
(画像は分割をわかりやすくするため各パーツを離して配置していますが、本来は元の位置のまま分割します)

分割の区分は下記になります。

  • 上腕(左右)
  • 下腕(左右)
  • 上脚(左右)
  • 下脚(左右)

4. .obj形式でエクスポート

分割ができたら、.obj形式でエクスポートしましょう。
(書き出しはQubicleのライセンスの購入が必要になります。)
書き出しの際の設定は↓になります。
07.png

  • <ファイル名>.mtl
  • <ファイル名>.obj
  • Materials/<ファイル名>_Atlas_tex.png

が書き出されれば成功です。

3Dドット絵モデルにボーンをつける

10.png
ここからは Blenderを使います。

1. Blenderにobjファイルをインポート

生成した .objファイルをBlenderに取り込みたいと思います。
File > Import > Wavefront (.obj) で.objファイルを選択してください。

3Dドット絵モデルがBlender上に表示されます。
11.png

ドットがボケて表示されてしまう場合は、レンダリング時には解消されるので、そのままで大丈夫です。

2. ボーンを作成する

3Dドット絵モデルにあったアーマチュア(ボーン)を作成します。
12.png

ボーンの階層構成はUnityのMecanimの仕様に沿ったものにします。 13.png

ここではボーンを作るところまででOKです!

3. 関節ごとにVertex Groupを作成する

頂点をグループ化(Vertex Group)して、 7.で作ったボーンとメッシュを適用する下準備をしたいと思います。
関節ごとに分割された状態でBlenderにメッシュがインポートされているかと思うので、それをそのままVertex Groupとして登録します。
14.png

全ての関節をVertex Group化します。

4. 各メッシュ(関節)を一つのオブジェクトにまとめる

全ての関節のVertex Group登録が終わったら、メッシュを一つのオブジェクトにまとめます。
15.png

メッシュオブジェクトを全て選択した状態でCtrl + Jを実行すると、メッシュがひとつのオブジェクトにまとまります。 16.png

17.png

5. ボーンとメッシュを結合する

続いて、ボーンとメッシュを結合します。
アーマチュアの子階層にメッシュを配置する感じとなります。

メッシュ → ボーン(アーマチュア)の順で選択してCtrl + P > Armature Deform > With Empty Groupsを実行します。
18.png

6. ボーンと関節のVertex Groupを連携させる

メッシュを選択した状態でEditModeに切り替えると、Vertex Groupsの項目に各ボーン名と同じVertexGroupが空の状態で定義されています。
このVertex Groupに頂点を登録すると、ボーンを動かした際に登録した頂点(メッシュ)が動きます。
3.で設定したVertex Groupをそれぞれのボーンに設定(Assign)します。
19.png

今回の3Dドット絵では、ドットの粒感を出すために、自動のウェイトペイントではなく、手動で頂点ごとに設定する方式を採用しました。
自動ウェイトペイントを使うと、また違った動きをする3Dドット絵ができあがるので、試してみても良いかもしれません。

7. 関節が正しく動いているかを確認する

PoseModeでボーンを動して、確認をしましょう。
20.png

Unityに3Dドット絵モデルをインポートする

細かい手順についてはこちらをご覧ください。

注意点としては

  • 3DモデルをBlenderから.fbx形式でエクスポートした後に、Unityにインポートする際に、.obj生成時に作られたpngファイルもインポートし、マテリアルに設定する
    • .fbxをインポートしただけだと、マテリアルにテクスチャーが設定されない
  • マテリアルのテクスチャのテクスチャー設定でFilter ModeをPointに設定する
    • 設定しないとドットがぼやけて表示されることがある

を忘れずに!

ボーンの構造がUnityのMecanimの仕様に合わせているので、人間用に作られたアニメーションを適用することができます。
102.gif
腕が短いため、剣の両手持ちとかはできないですが…(-_-;)

ちなみに、3Dドット絵コンチの頂点数は1088なので、ダイナミックバッチングの適用外ですが、比較的軽い3Dモデルではないでしょうか。
103.png

明日はゆるふわぽわわ系エンジニア、acidlemon氏がフィナーレを飾ります!
これは期待ですね!!!!