こんにちは、hachi8833です。GWと年号変わりを経て記憶が薄まらないうちに、引き続きRubyKaigi 2019@博多をキーワードで振り返ります。BPS社内勉強会でのRubyKaigi 2019報告会でBPS社内の他の参加者から得た情報も取り入れました。
rubykaigi.orgより
なお、RubyKaigi 2019（と2018）のツイートタイムラインを追える便利なリンク集（@fuji_syan作）を見つけました❤️。
- サイト: Replay for RubyKaigi
2019年度も、見たいセッションが横に並ぶことが多く、泣く泣くエイヤで決めたことも何度かありました😢。Martin先生も同じように残念そうにしていました。
当初は公式サイトへのリンクに留めようと思いましたが、現時点では公式サイトにまだスライドや動画がまとまっていないので、以下のリンクを参考に貼りつつ、見つけられた範囲でのスライド・資料も貼ってみました。
参考: RubyKaigi2019 スライドまとめ - Qiita
誤りや追加情報などがありましたら@hachi8833までお知らせください。
「Rails」
- Day2セッション: Zeitwerk: A new code loader - RubyKaigi 2019（@fxn）
- Day2セッション: How RSpec works - RubyKaigi 2019（@samphippen）（見に行けず😇）
- Day2セッション: The fastest way to bootstrap Ruby on Rails - RubyKaigi 2019（@udzura）（見に行けず😇）
- Day3セッション: The Selfish Programmer - RubyKaigi 2019（@searls）
- Day3セッション: JRuby: The Road to Ruby 2.6 and Rails 6 - RubyKaigi 2019（見に行けず😇）
- Reducing ActiveRecord memory consumption using Apache Arrow - RubyKaigi 2019（@mrkn）
- Day1セッション: How to use OpenAPI3 for API developer - RubyKaigi 2019（見に行けず😇）
- Day2セッション: Crystalball: predicting test failures - RubyKaigi 2019（見に行けず😇）
- Day1キーノート: The Year of Concurrency - RubyKaigi 2019
2019年度は、例年よりRails向けの実用的な話題が若干多かった印象があります。
Zeitwerkを作った@fxnさんのセッションはおおむねこれまでの情報に沿った内容だと思いました。既にnanocという静的サイトジェネレータgemでもZeitwerkが使われていて、大量のrequire行を削減できたそうです。
@searlsさんの「Selfishプログラマー」は、「unambitions」「ungrateful」「ungenerous」「delusional」「narcissistic」といったネガティブなキーワードをわざと用いて開発を説明しているのがユニークでした。
- サイト: KameSame
@mrknさんのセッションで扱われていたApache Arrowは以前のRailsウォッチでも取り上げましたが、ここではActive RecordのクエリをArrowで高速化を試みていました。メモリ使用量の増大と引き換えに、速度とパラレル実行が向上したそうです。@mrknさんがRailsdm最終回で発表したRubyData and Railsで試みていたArrowの実験では速度が変わらずメモリ消費が減っていましたが、実は当時のコードが壊れていたので今回再実験したとのことです。
OpenAPI 3（Swagger）のセッションはmorimorihogeさんが見たそうです。フロントとバックエンドに分かれて開発する際の共通プロトコルとしてはOpenAPI 3が現時点で最もこなれているようで、今後の動向を追いかける価値がありそうとの見解でした。
参考: 【連載】Swagger 3.0 入門 [1] Swagger(OAS) 3.0の登場｜開発ソフトウェア｜IT製品の事例・解説記事
Railsそのものではありませんが、Crystalball gemは、RSpec実行時にcode dependencyまで追いかけて「修正したコードに関するテスト」だけを実行できます。セッションを見たmorimorihogeさんが「これは実用性高そう」と評価していました。Crystalballは@tenderloveさんの記事「Predicting Test Failures」からヒントを得たそうです。
また、Matzのキーノートで触れられていたMJITの進捗報告では、Ruby 2.6ではoptcarrotでのCPUボトルネックは倍以上に改善されたものの、Railsではまだ遅いということでした。
「JIT」
- Day1セッション: Ruby 3 Progress Report - RubyKaigi 2019
- Day1セッション: Performance Improvement of Ruby 2.7 JIT in Real World - RubyKaigi 2019（@kokubun）
- Day2セッション: A light weight JIT compiler project for CRuby - RubyKaigi 2019
- Day1キーノート: The Year of Concurrency - RubyKaigi 2019
ここ数年RubyKaigiで目にするJITの話題といえば@k0kubunさんと@ymakarovさんです。
@k0kubunさんのセッションでは、上述の「2.6ではRailsが遅い」問題に2.7で取り組んでいる内容を発表していました。メソッド呼び出しとオブジェクトアロケーションが遅いことを突き止め、予測最適化やインライン化などを追い込んでいて、毎度のことながら強烈な印象でした。「Rubyプログラマーが無理な最適化をやらずに済むようにしたい」と言っていたのを思い出します。
参考: skaes/railsbench: benchmarking tool for rails applications
なお今回の発表とは関係ありませんが、LLVMの記事を追っていたらk0kubunさんが以前試していたLLVMベースのJITコンパイラ「LLRB」にたまたまたどり着きました。
参考: CRuby向けのLLVMベースのJITコンパイラを書いている話 - k0kubun's blog
k0kubunさんと並んでJITを追求し続ける@ymakarovさんのセッションも同じくコアな内容でした。2016年の京都でのRubyKaigiではトリをつとめていましたね。GCCの最適化をずっとやりつづけてきた方だけに、MIR（ロシア語で「平和」を表す）という独自の中間表現形式にコンパイルすることで、実験レベルとはいえGCCの100倍前後の高速化を達成していました。MIRプロジェクトではRuby以外にも将来的にLLVMやJavaバイトコードやWASM（Web Assembly）なども扱う野心的な計画を立てていますが、C->MIRコンパイラはRuby 3には間に合わないそうです。
- リポジトリ: vnmakarov/mir: A light-weight JIT compiler based on MIR (Medium Internal Representation) -- READMEにセッションの内容が盛り込まれています
「コントリビューション」
- Day3セッション: Ruby Committers vs the World - RubyKaigi 2019（Rubyコミッター一同大喜利）
- Day3パーティ: RubyKaigi 2019 コード懇親会 - connpass（Speee様スポンサー）
大喜利の質問コーナーで「メンテナーが来てくれるとありがたい分野は？」という質問に、「Windows対応やれる人がいるとうれしい」「GVLのスレッドロック周りをやってくれる人が欲しい（normalpersonさんが最近多忙なので）」という回答がありました。
他に、「Dateは今後Timeに寄せる」「Date.parseはカオス」「curryは後から作る人が出ないように先んじて実装してやった」といった話も出ました。
参考: class Date (Ruby 2.6.0)
参考: sugi/wareki: ruby 向け和暦ライブラリ。和暦と標準Dateの双方向変換をサポート。全元号対応。 -- Date.parseにパッチを当ててます
参考: instance method Method#curry (Ruby 2.6.0)
また「（Rubyやライブラリに足りない）ドキュメントをやってくれる人も欲しい」「最近のRuby標準ライブラリはgemにするようにしているので、C言語がわからなくても貢献できますよ」といった回答もありました。私もお邪魔したDay2「コード懇親会」で早速CSVライブラリのドキュメントに貢献した方がいらっしゃったそうです。たぶん以下がそれかと思います。