引き続き最終日も参加してきました。"Deletion Driven Development: Code to delete code!"でのエッジケース乱舞は本当につらい案件であり、入らないコードはざくざく削除していこうと思いました。ちなみにC#で似たようなことをしたことありますね……あとHTTP/2の話は非常に勉強になった。
Web Clients for Ruby and What they should be in the future
- Toru Kawamura
- Rubyで書かれたWeb APIにアクセスする人が操作するクライアントを対象
- ほしくないクライアント
- 簡単に変更できない
- 再利用できない
- 今のgem
- 疎結合なクライアント
- URLをハードコードせず、リンクをたどる
- Web APIは簡単
- Web APIでの状態管理
- クライアントが状態管理してしまえばいいと思っている
- ほしいWeb Clientsは状態管理できるもの
- サーバ側のrackみたいにクライアント側も決めごとがあればいいかなぁ
- Faradayがあった
- Rack Middlewareのような形を採用している
- gemでつくるのではなくFaraday Middlewareでつくるのが再利用もしやすいのではないだろうか
- gemを作った
- faraday-navigatoin
- back/forward
- リンクをたどる
- RFC5988
- RFC6570
- faraday-link-extractor
- リンクを抽出してLink/Link-Template headerに変換する
- faraday-navigatoin
Deletion Driven Development: Code to delete code!
Deletion Driven Development: Code to delete code! - RubyKaigi 2016
- Chris Arcand
- コードを殺す方法w
- コード書くのも好きだけど、削除するのが好き
- Dead
- over engineering
- poorly written
- refactoring
- 誰がめんどうみるの?
- deleting code 2002
- コードのノイズは開発者の大敵
- deleting code 2002
- どうやって削除するコードみつける?
- その方法
- .rb => ???
- Rubyは難しい
- エッジケースある
- Rails DSLは
- エッジケースおおすぎ……
- gemあり
- debride以外もいろいろある
- メソッドが相互に呼んでる場合は検知できる?
- できない?
- Railsのunused actionは検知できる?
Recent Advances in HTTP and Controlling them using ruby
- Kazuho Oku
- Current State of http
- なんでhttp2か?
- レイテンシがボトルネックに
- http2ではconcurrencyでレイテンシを隠蔽
- 2015/5 released
- 全体の3割がhttp2
- http2 feature
- header圧縮
- positiveな結果 中央値で90%データ削減
- 多重化&優先順位漬け
- push
- positive&negative
- pushしたものの5割が無駄
- positive&negative
- header圧縮
- なんでhttp2か?
- 問題点をどうやってfixするか?
- 理想 => 優先順位が高いリクエストに早く返す、リソースを正しい順序で返す、ないデータをpushする
- どれもできてない
- head of line blocking
- 優先度の高いデータがあるけど低いデータが滞留しているのでおくれない
- 技術的に解決できそう
- 実装して評価
- 理想的な最適化を得られる
- 実装して評価
- 優先順位漬け
- クライアント側で提示、サーバで参考にして送る
- CSSやJavascriptが帯域のほとんどをしめる
- SafariやBlinkは優先順位漬けしてくれない
- 画像が帯域をしめてしまう => HtmlやCSS, Javascriptが後回し => 表示が遅くなる
- バンド幅の正しいわりふり
- WFQやDRRを使ってスケジューリング
- nghttp2とかH2OはWFQを実装
- 頭の悪そうなクライアントにはCSSやJavascriptを先に送信する
- WFQやDRRを使ってスケジューリング
- hidden resource
- CSSの@importなど
- リソースみつかるまでに画像が流れるので遅くなる
- Hidden resourceを使わない
- preloadタグを使う
- push
- 優先順位漬け
- リクエスト処理中にpush
- CDNからpush
- いくつか考えられている
- RUM(ログとかから学習してpush)
- DSLベースでやる
- いくつか考えられている
- 複数の中間レスポンスと一つの最終レスポンスを返せる(HTTPの仕様)
- Unicornはraw socket, Pumaはパッチ当てる必要あり
- H2Oはmrubyでハンドラかける
- Push vs Cache
- 画像はpushしないようにしたほうがいい
- pushしたデータとpullしたデータの優先順位がむずかしい
- JSやCSSはpushしたほうがいい
- head of line lock問題が顕在化しやすい
- http2はポピュラーに
- まだ使うモノによって差がある
- H2Oつかってね
Optimizing Ruby
- Urabe, Shyouhei
- deoptimizotion over Ruby2.4
- Rubyは遅い
- どちらかというと遅い方
- 最適化されてないから
- 1 + 2 => 3?
- +が再定義おこなわれる可能性があるため3とは限らない
- 1 + 2 => 3?
- Deoptimization
- 再定義がなかったとして最適化
- 再定義されていたらフォールバック
- JRubyやRubinuisにもそれぞれで実装
- Strategy
- nativeにはしない
- sequenceにパッチするかたち
- 何がいいか
- Pure C コード
- program counterをいじらない
- VMの状態を戻さなくてイイ
- 再定義の検出
- 別途カウンタを用意
- Optimize on it
- いくつかの最適化をした
- これまでの最適化は動的におこなわれる
- ほかにもやることはある
- benchmarks
- make benchmark
- 一応はやくなってる
- 最適化の結果シーケンスが同じになるものもある
- vm2_eval
- 邪悪なやつ
- overheadで遅くなってるがまあこの程度ならはやくなってるかな
- はやくなったのはめちゃはやくなった、遅くなったのはちょっと遅くなった
- methodがpureかどうかの判定はrubyでわかる
- ある、つくりました
- 最適化の方法でメモリの使用量はふえてそうだけどどの程度増えてる?
- 増えてますがまだ評価していない
- 大きいアプリケーションでの評価は?
- まだ
- Folkで影響あるように思えるけどどうか?
- そこのところ考えてなかったけどありうる
- 最適化したあとのシーケンスが長くなる場合には?
- まだそこは考えられてない、対応必要
Hijacking syscalls with (m)ruby
- Franck Verrot
- mrubyをいろんなシステムに組み込んできた
- 今Redisやってる
- System call
- osとのinterface
- Hijacking syscalls what for?
- Sercuring Ruby apps is kinda tricky
- なんでmrubyでsyscallsをオーバーライドするか
- performance
- naive implementationだと24倍遅い
- optimized implementationだとnaiveより10倍速い
- system callを置き換える理屈というかうれしさがイマイチぴんときてない
Dive into CRuby
- NARUSE, Yui
- CRubyへの貢献
- 新しい機能、最適化、トラブルシューティングが簡単にする
- 新機能
- なぜ追加する => いまあるものじゃだめだから
- 実際にどういうコードの場合にだめなのかということをしっかり固める必要がある
- 必要は発明の母
- 例:壊れた文字列
- webクローラーでOK
- 壊れたファイル NG
- そもそも壊れたファイルを無理矢理読み込む必要はない
- 新環境
- 最適化
- Debugging/ Profiling/Tracing
- まとめ
おまけ
今日も美味しかったです。はい。