キーワードで振り返るRubyKaigi 2019@博多(#2)Rails、JIT、コントリビューション

こんにちは、hachi8833です。GWと年号変わりを経て記憶が薄まらないうちに、引き続きRubyKaigi 2019@博多をキーワードで振り返ります。BPS社内勉強会でのRubyKaigi 2019報告会でBPS社内の他の参加者から得た情報も取り入れました。


rubykaigi.orgより

なお、RubyKaigi 2019(と2018)のツイートタイムラインを追える便利なリンク集(@fuji_syan作)を見つけました❤️。

2019年度も、見たいセッションが横に並ぶことが多く、泣く泣くエイヤで決めたことも何度かありました😢。Martin先生も同じように残念そうにしていました。

当初は公式サイトへのリンクに留めようと思いましたが、現時点では公式サイトにまだスライドや動画がまとまっていないので、以下のリンクを参考に貼りつつ、見つけられた範囲でのスライド・資料も貼ってみました。

参考: RubyKaigi2019 スライドまとめ - Qiita

誤りや追加情報などがありましたら@hachi8833までお知らせください。

「Rails」

2019年度は、例年よりRails向けの実用的な話題が若干多かった印象があります。


Zeitwerkを作った@fxnさんのセッションはおおむねこれまでの情報に沿った内容だと思いました。既にnanocという静的サイトジェネレータgemでもZeitwerkが使われていて、大量のrequire行を削減できたそうです。

Rails 6 Beta2時点のZeitwerk情報(要訳)



@searlsさんの「Selfishプログラマー」は、「unambitions」「ungrateful」「ungenerous」「delusional」「narcissistic」といったネガティブなキーワードをわざと用いて開発を説明しているのがユニークでした。


@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」


ここ数年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には間に合わないそうです。

「コントリビューション」

大喜利の質問コーナーで「メンテナーが来てくれるとありがたい分野は?」という質問に、「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ライブラリのドキュメントに貢献した方がいらっしゃったそうです。たぶん以下がそれかと思います。

関連記事

キーワードで振り返るRubyKaigi 2019@博多(#1)

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ

BPSアドベントカレンダー