2016.04.18 に、六本木は森タワーのメルカリさん宅にて、atte fes が行われました。
アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました - Mercari Engineering Blog
本イベントにブログ枠にて参加させていただきましたので、ひとつそのレポートをば、したためます。
発表時に用いられた資料は、↑のリンク先にアップしていただいているので、参照されたし。
ちなみに、冒頭の画像は会場でいただいたデカールです。ねこかわいい。
最初にビールと軽食で乾杯
いきなり技術的な話題ではないところからなんですが、実にシャレオツだったビールブースにふれないわけにはいかない。
図1. 三種類のビールが提供されている。しかも缶じゃない。感動。
図2. 軽食が提供されている。
ビールは3種類とも一杯ずついただきましたが、とても美味でございました。
また夕飯食べずに駆けつけたものだったので、普通に空腹でありました。軽食もいただけて良かった！
おかげさまで集中して発表に耳を傾けることができました。ありがとうございました。
図3. 司会の方の音頭で乾杯。
アッテ開発の技術：
Golang と Google Cloud Platform (鶴岡達也さん)
さて、発表内容について。
図4. 鶴岡さん
ひとつめは鶴岡達也さんによる「Golang と Google Cloud Platform」。
発表の具体的な内容は実際に資料をご覧いただければ分かると思いますので、
本記事では私が印象に残った箇所について触れていくことにします。
なぜ Web アプリ開発に Go/GAE を採用したか？
さまざま理由があったようですが、個人的には、
「3年後にもエンジニアにとって魅力的な場所であるため」 に、多様性と技術の開拓の意味もふくめての採用であったというのが印象的でした。
そういうふうな文化があると、エンジニアにとって満足感が高い職場になっていくんじゃないかなー、等と。
とてもいいと思いました。ええ、弊社でもぜひそうしていきたい…。
Go言語はチームで開発しやすい
私も個人的にちょいちょい Go 言語を触りますが、ほんとに周辺ツールの充実っぷりが凄まじい。
lint、コードフォーマッタ、変数名には Go 言語公式のポリシーが存在する、等。
チーム開発に採用すれば、やれインデントが〜とか、インポートの順番が〜、とかをソースレビューに持ち込むこともなくなる。
そういう点も学習コストを下げるのに役立っているかな。Go 言語、私もオススメです。
GoDoc を有効に使う
GoDoc は概ね常に最新に保っているとのことで、つまり、
「API を使いたいひとはとりあえず GoDoc 見て」で済んでいる、らしいです。
チームで開発しやすい、効率化という面で GoDoc を有効に使えている例かな、と。
ドキュメントをおざなりにしないところ、素敵です。
またこういうドキュメンテーションのためのツールが提供されているのも Go 言語のいいところ。
Go 言語、私もオススメです。
GAE のインスタンスは 200 ms で立ち上がる
速い！この速さはオートスケール時にとっても活きてくる模様。
アクセス過多でスパイクしてもあっとうい間に平穏を取り戻す図は、私の心にも平穏と興奮を与えるものでありました。
その他の話題、RDB vs NoSQL、DataStore の良いところ、等
他にも興味深いトピックについて話されていました。
ぜひ、スライドを直に見ていただければと。
アッテ開発の技術：
Swift と RxSwift (大庭慎一郎さん)
図5. 大庭さん
正直に言うと Reactive Programming というものがほぼ分かってない私ですが、
発表は非常に興味深く聞かせていただきました。Reactive Programming ええな！
Swift の採用を決めた経緯
Swift を採用した経緯について。そもそも流用する資産がなかったとのことで、
だったら色々機能の豊富な Swift にしましょうよ、ということだったと思います。
Objective-C は、それはそれで今まで蓄えられたノウハウが Web 上に豊富に転がっていたりして、いわゆる「ハマりにくさ」では Swift より上のような気はする。そういう意味では Objective-C にも良いところはあるだろう。
とはいえ、Swift と Objective-C、どっち採用したらテンションあがるかと言われれば、やはり Swift であるかなと。3年後もエンジニアにとって魅力的な場所を醸造しているひとつかもしれない、等と思いつつ。
リアクティブプログラミングに頼るとプログラミング能力が下がる？
プログラミング能力が下がるは言い過ぎかも？
スライド上のサンプルコードは短く完結にわかりやすく書かれていて、いったん慣れてしまったら辞められない的なものを感じた。
なるほど、馴染んできたら普通のプログラミング (？) のやり方忘れちゃうかもしれないですね。
とはいえ学習コストは高い模様。
質疑応答では「急に全部ではなく、部分的に採用していくこともできる」と。
データバインディングから始めるのがやりやすいのではないか、と仰っておられました。
リアクティブプログラミング 参考サイト
スライド中でも触れられていますが、リアクティブプログラミングについては以下のサイトが理解の助けになったとのこと。
【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun’s diary
以下のページでは、Reactive な動き (Stream) を図で理解できるようになっています。
RxMarbles - Interactive diagrams of Rx Observables
アッテ開発の技術：
アッテ iOS の設計と開発フローの変遷 (石川洋資さん)
図6. 石川さん
同じ構造の実装の一元化
よくある同じ構造のもの、 ページネーション、フォームのバリデーションであるとかの共通化の話。
MVVM でいうところの VM 部分で、共通するGenericな部分 + 型スペシフィックな部分は型パラメータもらって作る、という構造の紹介。
特にページネーションは、10回書いたら7回くらいバグってるくらいのバグを埋め込みやすい部分らしく、
共通化することで、「高速な開発で、かつ安全」な設計に近づくことができたとのこと。
新しい設計を試すのは、場合によっては難しいことだと思う。
つい、いま動いているところは触りたくない、以前作ったものと同じような構造が出てきたら踏襲する、等と
してしまいがちな昨今（ですよね）、飽き足らず、より良いモノ作ろうぜという熱気にあふれている、等と感じておりました。
素敵だ。
自動デプロイの話
ご多分にもれずというか、やはり iOS アプリも自動ビルド/自動デプロイをなさっている模様。
構成要素としては、
- Travis CI (CI 時間は7分くらい)
- agvtool でビルド番号を振る (Xcodeに付随)。
- DeployGate (dev) と TestFlight (prod) にデプロイ
また、その他の作法として、
- 手元でのアーカイブはしない。
- QAが通ればそのまま審査へ
というのが紹介されていました。
ビルドとかデプロイ、あと審査もだと思いますが、ものすごく属人化しがちな部分であると思う。
「病気で倒れても誰でもデプロイできる」 と仰っていましたが、これって本当に大事なこと。
作業をひとにロックインしない工夫をしていかないとね。属人化は不幸の始まり。
ところで CI に掛かる時間が7分って結構早いような気がしている。
早さ、特に CI とかそういう常日頃から何度も繰り返し行われる事柄の早さは重要。
何も考えずにそこそこの規模の iOS アプリビルドしたら、結構時間かかっちゃうと思うんだよね。それこそ10分くらい余裕で。
さらっと7分って言っていましたが、ここにはきっと色々な工夫がなされているんだと想像します。
その後
図7. 懇親会。みな思い思いの方を捕まえては話し込む。
図8. 懇親会。運営おつかれさまでした。
おわりに
Mercari からスピンアウト (?) した SOUZOH という組織は、なんというか、
新しいやり方をどんどん取り入れていて、エンジニア的にはテンションあがる環境であるという印象でした。
それで実際うまいことやれているっていうのは、なお凄いことかな。
そんな感じで、おいしいビールをいただきながら学ばせていただいた atte fes でございました。オススメは Tokyo White。
運営の方々、登壇の方々におかれましては、大変おつかれさまでございました！