RubyKaigi 2017 に行って来ました（1日目）

発表

10:30-11:30: Keynote by @n0kada

https://slide.rabbit-shocker.org/authors/nobu/rubykaigi-2017/

13:00-13:40: Fiber in the 10th year by @ko1

13:50-14:30: How Close is Ruby 3x3 For Production Web Apps? by @noahgibbs

http://bit.ly/kaigi2017-gibbs

14:40-15:20: Gemification for Ruby 2.5/3.0 by @hsbt

https://www.youtube.com/watch?v=VKm93Mwe__k&feature=youtu.be

15:50-16:30: How to optimize Ruby internal by @watson1978

16:40-17:20: mruby gateway for huge amount of realtime data processing by @naritta

17:30-18:30: Ruby Commiters vs the World

発表感想

Keynote by @n0kada

Rubyコミッターの日常はこんな感じですよ、というお話。 ライブコミットやスライドのライブ編集など、その場にいる事で楽しめるコンテンツが盛り込まれていて、会場で聞くことができてよかったです。Rubyのコードはコアっぽいところはそこそこ読んでるつもりですが、parse.yは複雑すぎて変更が難しくなってると感じます。。。

Fiber in the 10th year by @ko1

Fiberを10年前に作ったけど、意外なところで使われて嬉しかったし、ちょっと微妙な実装だったところを最近直したりしてたよ、みたいなお話でした。 Fiberはコルーチンやサブコルーチンの機能を実現できるので、個人的には結構好きだったりします（https://qiita.com/south37/items/99a60345b22ef395d424 みたいに async/await の実装に使えたりするので面白いです）。

How Close is Ruby 3x3 For Production Web Apps

Rubyが3x3に向けてどれだけ早くなってるかを調べるために、Rails appを対象にしてbenchmarkをとってみたよ、という話。指標は色々あるけど、http requestを捌くthroughputで1.5倍くらい早くなってるとの事。 会社としてこういう取り組みをしてるみたいで、OSSへのモチベーションが高い会社なんだなーと思いました。

Gemification for Ruby 2.5/3.0

Rubyの標準ライブラリをGemに移行して行ってるよ、というお話。狙いとしては、Ruby本体からライブラリを切り離す事で「Ruby本体はバージョンアップできないけど特定のライブラリだけバージョンアップする」みたいな事をやりやすくしたいらしいです。 個人的には、Gemに移行する際に基本的にgithubにレポジトリを作ってるみたいだったので、外からコードが見えやすくなってコントリビュートのハードルが下がりそうなのが好感触でした。

How to optimize Ruby internal

watsonさんが3月頃からRubyにperformance改善のpatchを送り続けていた際に、どういう狙いでどういった変更を行ってたかを話していました。 自分もちょうどその頃Rubyのコードを読んだりRedmineのIssueを見たりGitHubのPRを見たりしていて、watsonさんの怒涛のperformance improvementのpatchも目撃していたので、どういうモチベーションだったのか聞けて良かったです。

mruby gateway for huge amount of realtime data processing

h2oのmruby handlerの中で外部通信を並列で行いたくて、その辺の処理をうまく記述するためにhttp_requestとFiberを組み合わせて書いてたよ、というお話。 僕の中ではFiberは基本的にloopと組み合わせて使う印象で、そのループがおそらくh2oの管理するイベントループなのが興味深かったです（もしかしたら何か勘違いしてるかも）。

Ruby Commiters vs the World

Ruby Commiter が会場のみんなから質問を受け付けて色々答えるセッションです。 EndohさんがCookpadのフルタイムコミッターになりましたっていうニュースの後で始まり、EndohさんがRubyへ型システムを載せようとしてる事から型の議論が熱かったです。matzさんは型を手で書くのはすごく嫌、どうしても入れるならせめて後から消せる形（コメントにメタ情報として記載）で、と言っていて、強い思い入れを感じました。個人的にはcompile時にstaticに型チェックして欲しい気持ちはあり、その為なら多少記述が増えても良いと思う派ですが、そこをテクノロジーで何とか記述させずに済ませたいという気持ちはわかるなーと言うスタンスです。

懇親会

  • Rubyコミッターの方とたくさん話せました。
  • 以前から話してみたかった人と話せたので、良い体験でした。

Watsonさん

彼の patch を参考にして自分も performance improvement の patch を書いたりしていたので、以前からお話ししてみたかった方でした。どうやって着手する箇所を見つけてるのか気になってましたが、やっぱりコードを端から見ていって直せそうな箇所を直す、というアプローチをとっていたらしいです。（普通のアプリケーションの速度改善なら profile をとってボトルネックを見つけて、という形で performance improvement は行いますが、Watsonさんはばらばらと色々な箇所に着手していたので、profiling とは別のアプローチが必要だよなーと感じていました。）

rheniumさん

自分のpatchのreviewを行なってくれた人で、調べるとすごく若い雰囲気を感じたのでどんな人か気になっていました。話すと、大学3年生らしく、やっぱり若かったです。どういう経緯でRubyコミッターになったのか、みたいな話をしました（openssl本体やopenssl gemにバグがあって修正patchを送っていたら、任命されたらしいです）。

Endohさん

実は2年前のRubyKaigiでお話ししたことがあり、さらに弊社CTOと大学の同級生というちょっとした繋がりもあり、覚えてくださっていて向こうから話しかけてくれました。とても嬉しかったです。Rubyの型システムをどういう形にするかは悩ましいけど、PythonのType Hintsっぽいものが落とし所としてはありえそう、みたいな話をしました。

k0kubunさん

llrbなどが良いアプローチだなーと思っていたので以前からお話ししてみたかった方でした。話しかけたら、向こうも自分を知ってくれていて、嬉しかったです（自分の書いたpatchを彼がスライドで取り上げてくれたことがあって、そこで認知してくれていました）。 Rubyを根本的に早くするにはJITやその中での様々なoptimizeが必要なはずで、whileみたいなキーワードは扱いやすい方だけどeachみたいなメソッド呼び出しのループは難しいよね（blockのinline化やメソッド再定義された時のdeoptimizeが必要）って話をしたら、「VradがJITに着手していて、『2ヶ月後にはCRubyのJITが作れる』らしいよ」と言っていました。すごいw Vradimir MakarovさんはRuby 2.4で内部のhash table実装高速化もしていてすごい人なので、期待したいです。