atteアプリ開発の話をイベントで聞いてきた

これ：アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました - Mercari Engineering Blog

Golang と Google App Engine

https://speakerdeck.com/ttsuruoka/atutekai-fa-falseji-shu-golang-to-google-app-engine

Datastore APIの話とかPython SDKが出た頃によく触っていたので懐かしかった。

App Engineは2013年ぐらいにやっとAPNSのPUSH通知ができるようになったのだけど、（http://blog.lai.so/entry/20130415/1366024996 ）

最近他の会社でもGAE/Goの組み合わせて使っているプロジェクトを見かけるし。特にGCPリリース以降、バックエンドにAWSじゃなくてHerokuでもなくてGAEというのが選択肢になってきているんだなーと感じた。

そういえば2012年に調べたことがあるんだけど、インフラはAWS一色だなーというのhttp://blog.lai.so/entry/2012/02/16/003509 を思い出した。

また言語選定の話で、特にGo言語書き慣れている人たちを集めてきたわけではないというのが興味深かった。Scalaなども選択肢にあったのだろうけど、Goのスクリプト言語系の書き手への相性の良さとGAEの存在が決め手かなと感じた。

（PHPの優位性は協業するウェブデザイナーに一番リーチしているところだと思います）

また重厚なウェブフレームワークは使わずに標準的な小さいライブラリで構成していくのがGoのやり方だろうと解釈もなるほどと思った。

Goは以前話題になった時はCの替わりのシステム開発言語ぐらいに思っていたけど、これでウェブアプリ開発するのに俄然興味を持って帰りに入門書を買ってしまった。

スターティングGo言語 (CodeZine BOOKS)

スターティングGo言語 (CodeZine BOOKS)

Go言語によるWebアプリケーション開発

Go言語によるWebアプリケーション開発

Swift と RxSwift

https://speakerdeck.com/bricklife/atutekai-fa-falseji-shu-swift-to-rxswift

CocoaPodsが嫌いでCarthageが使えるiOS 8以上をターゲットに設定したというネタが枕にあって、パッチ２、３送っているぐらいのファンとしては気になったがビルドエラーのトラブルとかが嫌われてしまう原因かな。それはわかります。

RxSwift、というかリアクティブプログラミング(Rx)系のライブラリを採用した理由として「メルカリアプリでずっとReactiveCocoaを使っているのでなしでは組めなかった」というのが面白かった。

僕はWindows系のアプリケーション開発（Silverlightぐらいの時期）やHaskell for GTK+なプログラミング環境でリアクティブエクステンションとかFRPとかの概念を知り以前から興味を持っていて、 自社のアプリでReactiveCocoa本格的に使いたいなーと思ってもう2年できずにいるので羨ましかった。早い段階でReactiveCocoa導入していた人たちはあとはKobito(OS X), freee(iOS)なども居たと思う。

RxはUI非依存なストリーミング操作だけ保守的に使うというtipsもあるけど、UIコンポーネント拡張を取り入れた方が段違いに恩恵があっていいと思っている。

Reactと同じくプラットフォーム横断で思想が共通しているのがRxの良いところなので、AndroidのUIもRxJavaで組んでいるのでしょうか。ウェブアプリは？RxJS?

質疑応答で発言して「ネコ風のあいつ」が描かれたトートバッグをもらいました

「川」という隠語はよく把握していませんが内輪用方っぽい

アッテiOSの設計と開発フローの変遷

https://speakerdeck.com/ishkawa/atuteiosfalseshe-ji-tokai-fa-hurofalsebian-qian

MVVM

各タイムラインの要素を<Element>で表現したページネーションViewModelを複数のViewから参照する図が出てきたけど、複数のViewControllerにまた別の振る舞いを追加したくて実装をViewModelで共通化したい時にViewControllerはViewModelを一対多で持つのか一対一で巨大なViewModelを拡張していくのかというところが書き慣れてなくてピンとこなくてちょっと自分でやってみないとわからないなという感想だった。

Caching

RealmをキャッシュDBに使ってなんでもオブジェクトを作っていたんだけど破綻したという流れがあったけどちょっとこれも実際のソースコード見てみないと何が問題なのかわからなそうだった。

でもメモリに乗せてJSONに書き出して時限でいらなくなったら消すというのは普通に有効なパターンだと思った。Himotokiとかもいきなり出てきたし設計自体が流動的に変わったのだろうと推測。

ところでなぜRealmはライトウェイなキャッシュストアに使われがちなのだろうか。 というかマイグレーションが必要な永続化ストア需要が地下鉄で使われるアプリケーションとかにはあまりないのも関係していそうだ。

Deployments

結構自社とやっていることが似ていた。というかどこも似たようなものなのかも。

ユビレジではangleddeckというツールがあって、これがプルリクエストのOPENでインストールURL付きのウェブアプリをBOTがコメントでつけてくれてマージする前に非開発者でも確認しつつ作業を進められるのでみんな使った方がいいと思った（でもApple Developerエンタープライズ契約がいる）

ちょうど Quipper の開発事例 とかHerokuの Review Apps のiOS版という感じ

こういうツールはだいたいCTOのsoutaroさん(kではなくmの方)に「こういうのが欲しいんですよ〜」と話すと次の日に納品されてくる（関係性が逆だ……）

あと soutaro/Obihiro というPageObjectでのViewControllerテストツールもお気に入りでこれも使って欲しい

JSON RPC

さらっと出てきていたけど JSON RPC の採用は結構肝だと思った。クライアント側から各通信で欲しいデータを柔軟に取ってきたり調整が楽なんだろうなと想像した。この辺深掘りしたい。

（余談：某社ではNode.jsのAPIサーバーが各大規模サービスの前面にあって、フロントエンドエンジニアの人が自分が叩きたいWeb API自前しているという話も聞いたことがある。それに近い。）

monorepo

FacebookやGoogleのやり方に従って関連リポジトリを１つにまとめて管理する方法を取っていると聞いたのだけどサーバーサイドだけの話だろうか。

モバイルアプリも全部含めて会社で１つ？　聞きそびれた。

所感

メルカリ2年ぐらい前には他のフリマアプリよりは比較的ユーザー少なそうに見えていたんだけどよくこの短期間で急成長したなーとビックリした（偉そう）。

新しい価値を新しい事業で作るために新しい会社を設立して新しい人たちを集め*1新しい技術を使って開発したという意図があるように見えた。

技術者コミュニティへのブランディング活動の巧さはテックブログ黎明期の頃のウノウラボブログの存在を思い浮かべさせてちょっと面白い。

*1:中心となっている技術者は古株メンバーだったけど