詳細
感じたことは斜体でメモった
「cookpad.comの中身〜クックパッドでの開発〜」（Cookpad前田さん）
- 5500万人以上の利用者、219万レシピ
- Ruby/rails
- CoffeeScript
- Android / Ob-c
- インフラエンジニアもコードが書ける
「Fablicの誕生と軌跡 〜創業期から今日までの会社とサービス（FRIL）の変遷について〜」（Fablic堀井さん）
- FRIL作ってる会社
- FRILは去年のGoogleベストアプリに選ばれた
FRILは初期からマテリアルデザインに独自対応していてすごいなーと感じてた
- ディレクターがいなくて、エンジニア、デザイナー主導で使用を決めて開発
- Google+の社内コミュニティでユーザからの意見を募集
- 社内のQAチーム（実際のユーザ）と一緒にテスト
フリマアプリのようなヘビーユーザーがいそうなアプリだから出来ることかもしれないが、実際のユーザにQAしてもらうってのはとても効率的に感じた
- GoogleDeveloperツールを使えば段階的なリリースができる
アルファ版またはベータ版テストと段階的公開の使用 - Google Play デベロッパー ヘルプ
段階的リリースは知らなかった、最初に２割程度にアップデートかけてbugfixしてから全体にアップデートかけるってのはいいアイデア
「クックパッドにおけるAndroidエンジニアの役割〜native化へのフルスクラッチ、開発プロセス構築、そしてサービス開発へ〜」(Cookpad八木さん）
Android界隈では有名な八木さんからのCookpadの歴史のお話
visible true
- 最初はcookpadはハイブリッドアプリだった（webviewを使った枠だけnative）
- パフォーマンスチューニングの限界
- css.jsをモバイルごとに振り分けていたので超複雑化
- OSバージョン間によるwebviewの差異
個人的に今なら
Visual Studio Tools for Apache Cordova の使用を開始する
とか環境もマシンスペックも上がってきたので4.4系以上とかに絞って完全ハイブリッドは再挑戦してみたい
- でてきた問題
- リリースプロセスが確立していない
- ナレッジが属人的
- 少人数での開発に限界
- 開発プロセス構築
- モバイル開発用のチーム開設
- リリース後監視
- potatotips（開発tipsの共有会）
- 開発プロセスが成長し安定的なスケジュールがさばけるようになってきた
- 部署によりKPIが異なるのでサービス改善ができない
- モバイルアプリチームを解散し、色んな部署（サービス）にアプリエンジニアを散らせた
- 色んな部署でサービスを改善していく
- これからやりたいこと
- 低速環境の動作
- パフォーマンスの改善
- UX改善（Webに比べてのAppの優位性
- デバッグ環境の強化
- 仮説検証を加速する基盤
→UX改善もデバッグ環境の強化もすべてはサービス改善のため！
これエンジニアだけやってると忘れがちなので注意したい
「Fril開発生活3つの心得 〜インフラ・サーバサイド開発の楽しみ〜」（Fablic上杉さん）
サムライ・エピソードの中の人
サムライ・エピソード - 達人出版会
インフラ屋さんからプログラマにキャリアチェンジ
