builderscon 2017 - day 1 メモ

以下、所感混じりのメモ。まとめや感想はあとで書く。

※ 内容については間違っている可能性あり。

Desktop Apps with JavaScript

Electron = node.js(JavaScript) + Chromium(のレンダリングエンジン) + C++(OSネイテイブ機能の活用)
monaco editor
Electron の hello world の敷居はかなり低い
Slack app React で作り直している
electron-forge CLI よい
http://felix.fun

マイクロチームでの高速な新規開発を支える開発・分析基盤

LUCRA
gunosy で得られた知見を使って記事のグルーピングを機械学習でやる
最初から分析できる環境が欲しかった
うまくいったポイント
- やるやらないの切り分け
- Gunosy の基盤の強さ、gunosy はGoの使用歴がかなり長い
やるやら基準
- アプリのコンセプトを検証する
- 大事なのは記事が見られて、検証・運用可能な基盤をつくること
- やらないこと：Android、リファクタ、フォロー、お気に入り
gunosy/go という共有資産があり、OpsWorksでデプロイすればAPIサーバがすぐできる
記事分類・生成に必要なAPI
- クローラー、カテゴリ分類器、タブジェネレーター（特定カテゴリの記事一覧を生成する）
2段階キャッシュ（ローカル、リモート）
マイクロアーキテクチャをやりすぎない
分析
- 大量のログを取得している、トップビューだけで10以上
- 分析環境はRedash
- 運用開発問わずチーム全員が分析用SQLを書く
- Slack にKPIを通知
分析結果の理由
- ブランドイメージを追求したいからと言って、根拠なく「ファッション」「コスメ」を推すという意思決定は絶対にしない（データで確信が持てない施策は極力許さない）
- 高いCTRやRRが期待できるプッシュ、機能通知しかやらない
ログ設計を最初からうまくやるには？
- Gunosy にはもともと似たようなアプリがあり、ある程度ログの型が決まっているのでだいぶやりやすい
プロダクトとログの乖離
- 開発者も分析基盤に触るが、専任のチームがいる。CSの博士号を持っていたり英語論文を読みまくったりするかなり高度な人たちが分析に責任を持っている。また、彼らの提案を受け入れる土壌がチームにある

複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ

何も考えずに作ると何が起きる？
- DOM をコードで作ってるとか…
- 巨大なものを一目で理解するのは不可能
分割する？機能、画面、リソースなどの単位
Presentation Domain Separation
- Presentation と Domain をワケましょうということしか言っていない
MVVM
- MVVM で model が VM を持っても良さそうだけど…？実際にやるとDOMのテストとかがModelのテストに入ってきてつらい。オブザーバパターンで依存関係を整理したりできる
- PDS は model 設計については何も言っていない
layered architecture
- モデルを3層にする。アプリケーション、ドメイン、インフラストラクチャ
- アプリケーション層：プレゼンテーション層との窓口
- ドメイン層：ディレクタ的関心。ドメイン層の設計は非プログラマでも読める感じだと良い
- インフラストラクチャ層：技術的関心。プラットフォームや外部APIに依存した実装をドメインに書くと汚くなってしまうからインフラストラクチャ層に追いやろう
- 依存関係はP->A->D->I だけどテスタビリティが高いのはDだからそこに依存したい
clean architecture
- テスタビリティの高いドメイン層を中心に依存する
- この考え方は具体的なアーキテクチャではない
- 実現方法は、インフラストラクチャ層をDIする、プレゼンテーション層をモデル層が監視するオブザーバパターンなど
状態管理の問題
- ドメイン層に状態が散らかりすぎる
- CQRS（コマンドとクエリを分ける）
バリデーションはアプリケーション層に書いている。コマンドというクラスを作って「アプリケーションへの入力が正しいかどうか」を判定する。（モデルに持つのがよくあるパターンだけど。フォームクラスとかは？）
悩んだら原則に立ち返る

RDB アンチパターン リファクタリング

不適切なデータベースがコードやサービスの成長を止める
データベースリファクタリングおすすめ
データベースの不吉な匂い
- データは生き物、どんどん追加されていく
- 積み木と同じなので初期設計に失敗すると仕様変更ができない
何をリファクタするかはシステムによる
- シングルアプリケーション vs マルチアプリケーション
- シングルアプリケーションのときはDBマイグレーションが活きてくる
- マルチアプリケーションは難しい、片方は止められなかったり…
データベースリファクタリングはすごく長いスパンになる、だから戦う準備が大事
1. 抽象化。データベースアクセスには永続化フレームワークをはさむ
2. データは変化する。モニタリングして変化の影響を知る必要がある
3. テスト。
4. 覚悟。DB停止はありえる。エンジニア以外がサービスの停止可否を握っているなら政治力も必要
手間も時間もかかるからころ検討が大事。そのデータベースに価値はあるか、費用対効果は、いつやるべきか
- 対象選定
- リリース時期を決める
変更前・中・後すべてのテストを行う
DBは影響範囲が広いので切り分けできるように小さな変更を繰り返すことが大事