RubyKaigi2022 覚書と感想
RubyKaigi をリモート視聴!Day3は移動しながらであまり聴けなかったのだけどDay2まで聴いたセッションでいくつか覚書。
- Make RuboCop super fast
- How fast really is Ruby 3.x?
- Types teaches success, what will we do?
- TRICK 2022 (Returns)
- 雑感
Make RuboCop super fast
Ruby 3x3(Ruby2の3倍の実行速度を目指すという構想)のようにRuboCop 2x2をキャッチフレーズに、RuboCop 2.0を開発しているという話。RuboCopには開発者体験の向上、またエディタやIDEとの連携が求められている。速さの向上は言うまでもなく。というところで、以下の手法で高速化しているとのこと。
- キャッシング
- .cache/rubocop_cache に分析済みの情報を残す
- マルチコア
- 1.19 からデフォルトでマルチコアで動くようになっているが、さらにparallelでの実行でボトルネックになっている箇所を並列に実行されるようにした
- デーモンモード
- server モードでしか使わないrequireを外すことで850倍速くなった
- 4つ目の手法も紹介されていたがメモしきれず….
また Rubocop の過去と未来の話で、以前は RuboCop を実行するごとに Rubocop::CLI のプロセスを起動しているため重いという課題があったが、これは rubocop-daemon というライブラリの登場である程度解決された。デーモンとしてプロセスに常駐し、実際のCLIはデーモンへのコマンド送信と結果受信のみ行うので早い。なるほど。
そして RuboCop は server モードが 1.31 から導入されたが、 server では重いモジュールの読み込みを解決しておいて、client は server に繋ぐだけにすることで高速化に成功したというもの。
rubocop --server
でオプション指定することで実行できるようになっている。
rubocop-server コマンドの提案もあったが利用者は RuboCop がそのまま速くなるのを期待しているはずなので別コマンドよりはオプション化が望ましいだろうということで「コードにしたものと、コードにしなかったことがプログラミングである 」の指針で検討したというのは、ソフトウェア設計で大事な考え方だなぁと頷きながら聴けた。
How fast really is Ruby 3.x?
Ruby 3 では YJIT や Ractor などの改良があるが実際どのくらい高速化されたのか?というのを Ruby のアプリケーションである Fluentd から評価した、という内容。(問題解決する機会が少ないのでそうか Fluentd って Ruby 製だ!っていうのを忘れていた….)
Fluentd は息の長いプロジェクトであり、Ruby のランタイムに依存しているプロジェクトでもある。
が、それぞれの過去の Ruby をスナップショットした td-agent が残ってるので、比較できるというユニークな強みがある。(td-agent は Fluentd を各OS用に rpm, yum パッケージで配布している)
Rails だとデータを引っ張ってくる処理が多いので、ボトルネックは MySQL や I/O になりがち
→つまり、Ruby3x3 で3倍速くなったとしても Rails が3倍速くなるというのは考えにくく影響は限定的では?となるが、Fluentdでは実際にRubyで重い処理をやっているため違う結論が得られるはずでは?と検証。
Ruby 1.9 と 3.2 を比較しその結果 Fluentd のベンチマークでは Ruby3x3 は達成された、YJIT は素晴らしい。という評価。
他言語(Python)と比較したりするとまだ差はあるというのも語られていたが、ベンチマークテストのプロセスをこうやって聴くのは楽しい。
Types teaches success, what will we do?
Ruby3 から導入された型定義のメリットを享受していこうというお話で、gem の RBS(型定義)ファイルを管理する gem_rbs_collection の紹介。
なぜRubyの型定義をプロジェクトに導入するのは難しいのか。RubyGems.org からどれだけの gem に型定義されているのか見ると、44個/17万 しかない。約0.03%。
gem_rbs_collection へのコントリビュートを行い、型定義された gem を増やすことで既存プロジェクトへの型定義導入障壁を取り除こう!ということでそのコントリビュート方法について
- すでに型定義がある場合、gem のアップデートに伴う型まわりの変更の追従
- steep check というコマンドがあるのでそれを実行しエラーが出て型定義に誤りがありそうなら PR を投げてみる
- また source_location というメソッドがありこれを使うと定義されてるファイルがわかって便利
- 新規に型定義を gem_rbs_collection に登録する場合は コントリビュートガイド に則って進めよう
既存プロジェクトへの型定義導入、確かにどこからやってみるのがいいのだろうというところだったので障壁を取り除くのに gem_rbs_collection へのコントリビュートから初めてみるというのは良い!
TRICK 2022 (Returns)
github.com に全公開されている!
面白かったー。eto award: "Most global"–Yusuke Endoh
こちらが特に好き🌍
https://github.com/tric/trick2022/blob/master/06-mame/entry.rb
雑感
追いつけたもの、追いつけなかったもの含めて10セッションほど聴講したが、全編通して難しかった〜というのはありつつ、知らない用語に触れて学ぶ(この割合が多い)だったり普段使ってる技術要素に対する自分の曖昧な認識を正すいい機会になるなと実感。
というか知らない→知る→やっぱ何もわかってない→今度こそ知る(なお)ということの繰り返しなので、本など読んでみて知った気になるのではなくその都度自分で触って知らない→知るを繰り返していかねば。久しぶりの RubyKaigi 楽しかった!