@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Video: OSCON 2014: How Instagram.com Works; Pete Hunt

OSCON 2014: How Instagram.com Works; Pete Hunt - YouTube

YouTube で Facebook Developers チャンネルを購読してたら新着動画のお知らせメールに載ってたので視聴した。以下メモ。

  • instagram.com は React を使った Single Page Application
  • ユーザーエクスペリエンスを最優先した結果 SPA を選択した
  • 初回ロード時間はリクエスト数 x 転送バイト数で決まるので .js/.css ファイルを一個に結合するのは良くない
  • エントリポイントごとにモジュールを分けて、モジュール単位で一個に結合、 minify/gzip などすると効率が良い
  • .js/.css は CommonJS の require を使って(?自信なし)ロードする。サイズの小さい画像も DataURI を require して img 要素を作る
  • このような特殊なファイル読み込み手法のため CSS の読み込み順序が不定になりセレクタ名の衝突・上書きで見た目が崩れるので命名規約とかいろいろ使い方を工夫する
  • ファイルの編成には browserify や grunt gulp 等ではなく、依存関係の扱いに長けた(?自信なし) webpack がオススメ。ブラウザのファイルロード・読み込み速度が 250ms -> 120ms に改善した

僕はこう思ったッス

  • ブラウザパフォーマンスも考えた上でモジュールシステムを決めたりしててさすが Facebook だなと思った。 Rails とかでやってると何も考えず一個にまとめているけど、考え無しでやるだけは良くない
  • 「オレは CSS が嫌いだ」には同情するけどセレクタの衝突でややこしくなったりするのは自分らがわざわざ特殊なやり方でファイル読み込みしているせいじゃん...と思った
  • 「Facebook は巨大なベヒーモス」とか所々で笑いをとろうとしてるのに会場の笑い声が一切録音されてなくて気の毒だった。でも会場が広いのとマイクの集音性能が優秀なせいかもしれない
  • webpack って初めて知ったなーと思ったら数ヶ月前に日本語でも紹介されていてアンテナの低さが身にしみた
  • 40分枠のうちほぼ30分ぴったりに収まるトークと10分の質疑応答でほぼ40分ぴったりで終わっててすごいと思った。プレゼン慣れしてるのだろうし、準備や練習も相当してるのだろう

Video: GoGaRuCo 2013 - Measuring Ruby by Sam Saffron and Jeff Atwood

GoGaRuCo 2013 - Measuring Ruby by Sam Saffron and Jeff Atwood - YouTube

YouTube の Watch Later に入ってたのを消化した。硬派なパフォーマンスチューニングの話。以下視聴メモ。

  • Discourse のパフォーマンスチューニング、特に Ruby プログラム部分の話
  • 前半でクヌースの「早すぎる最適化は悪」を引用しつつ、サイトが遅い原因の大半はフロントエンドにあると指摘
  • しかしフロントエンド最適化の話はせず(おそらくそれは踏まえた上でなおサーバーサイドを限界までチューンする話、だったのだろう)
  • dtrace の扱いづらさ(?自信なし)を経て rbtrace に触れる
  • rack_mini_profiler の使い方に触れる、 /?pp=help とすると裏コマンドがいろいろ見られる
  • memory_profiler gem を使うとメモリについて詳しいことがわかる、オブジェクトが作られた数とかそれによって消費したバイト数とか(動画内では ruby-head が必要とあるけど一年前の動画だから。 2014 年現在はふつうに最新リリース版の 2.1 系で使える)
  • あと flamegraph オプションを使うとコールスタックがカラフルなグラフで見れる
  • それらを踏まえてオブジェクト生成コストを減らすコーディング指南とか、常に実行可能なベンチマークコードを持っておいてライブラリの新しいバージョンに対して実行し改善や悪化を計測可能にするとか

僕はこう思ったッス

  • 動画のタイトル見たとき「まさかあの Jeff Atwood なわけないよなー、同姓同名の人なんだろうけど気の毒だなー」と思ったら本人でびっくりした
  • 大規模ハイトラフィックサイトにおけるハイパフォーマンス Ruby プログラミングという感じでためになった
  • 個人的にパフォーマンスへの関心が薄くてベンチマークの類いにもあんまり興味が無いのだけど、技術者としてやっていく上でそれはマイナスに働きそうだなという懸念が以前からあったので、たまにこういうのをみると刺激されてよかった
  • とはいえ個人的には消費メモリを節約するためにオブジェクトの属性をハッシュに詰め直す、みたいなコーディングの工夫でがんばる方向性にはやっぱり賛成できなくて、だったらもっとメモリ効率の良い、用途に適した言語で書けばいいのに、と思ってしまう(もちろん習得コストとかいろいろあるけど、必要に迫られたらできるはず)
  • とはいえ遅いと言うだけよりはコードとデータで示したほうがよっぽどいいし、そういう動きがないと処理系を作る側にも伝わらないだろうから、やっぱこういうことをする人はそれはそれで偉いと思った
  • script/bench.rb で Rails edge とかに対して Discourse のベンチを走らせて継続的にパフォーマンスの変化をチェックする、というのはちゃんと人柱になっててえらいなーと思った。ノブレス・オブリージュっぽさを感じた
  • flamegraph というものを初めて見たけど youpy さんっぽいなと思った