Ruby歴4年程ですが、先日初めてRuby Kaigiに参加してきました。
三重開催で当初はオフライン参加も検討していましたがコロナもあったので控え、オンラインのみの参加でした。
オンラインながら、めちゃくちゃ刺激になりました！もっと早くから参加すればよかったとも思うほど楽しかったです🎉
目次
Ruby Kaigi 2022 day1
Types teaches success, what will we do?
現状、TypeScriptを導入しているプロジェクトはそこそこ増えていますが、Rubyで型をプロジェクトに導入している例はまだまだ少ないみたいです。
実際、2022年9月時点でgemの数は約170,000に対し、型定義されているgemの数は44とかなり少ない状況で、対応するgemが少ないことは、型導入の障壁になるのでgem_rbs_collectionにコントリビュートしていこう！という話でした。
また、contributeの方法についても詳しくお話してくれていました。
と、本格的に型定義を進めようとしていることを感じる発表だった。実際、型から得られる恩恵は大きく、自分も関心が高い。Rubyの書きやすさを保ちつつ、小さく導入することができるのも良いと思いました。
Rubyではおそらく既存PJに型を追加していきたいというニーズがでてくるので、型導入する日も遠くない未来かもしれないです。
と同時に、Steepがバージョン3.1からバンドルされていることからもRubyとしても型のある世界を目指していることを強く感じました。
はてぶでご本人の記事もありました
この記事読んでるとやっぱりオフラインで参加したかった。。。！と思いました。
Tools for Providing rich user experience in debugger
こちらもRuby3.1から標準ライブラリとして搭載されたdebugというデバッグツールのお話でした。
このdebugは便利だぞと噂は聞いていたんですが、今までRailsではbinding.pryしか使っていませんでした。
これが想像以上にリッチだった。なんとChromeでRubyファイルをそのままdebugできるとは。demoも丁寧でわかりやすかったです。
仕組みとしてはclient(Chrome)でserverと通信してコードの実行止めたらその結果をclientに返して、というものみたい。
Rubyらしいというか、debugのしやすさみたいなところはコードのとっつきやすさにつながるので良さそうに思いました。
Towards Ruby 4 JIT
英語の発表でしたが、聞いてみた。
I want Ruby 4 to be as fast as Java or JavaScript
Ruby 4’s performance should be a reason to leave Python
Towards Ruby 4 JIT
上記の発言が部分が最も印象的でした
具体的なベンチマークを定めているところも目指すところがわかりやすくて好印象でした
本当にこれできるの？という部分ですが、新しいJITであるYJITを活用することでまだまだRubyのパフォーマンス改善の余地があるようです。
JITに関しては、そもそも前提知識があまりなかったのと、英語が全然だったのでかなり浅い理解になってしまいましたが、下記などかなりわかりやすかったです
https://zenn.dev/kenzan100/articles/5a1b21d6207e64
（全然発表とは関係ないですが、LTでの英語をちゃんとヒアリングできるぐらいに英語力つけたい、、、と思いました）
Ruby Kaigi 2022 day2
matzのkeynote
登壇資料そのものは見つからなかったですが、Twitterでいい感じにまとめてくれている人がいました、めっちゃわかりやすい
売上トップ50の企業のプロダクトのうち52%はRuby
転職ドラフトのデータいわく、Rspecつかっていると給与高いらしい
最初は30名程度の人が集まるカンファレンスから、少しずつ価値が認められお金を集められる技術になってきたという話が印象的でした
また、Communityの強さも大きく、GemやRailsといったの価値のある周辺ツールの存在もRubyの強みであるとも話していました
実際、企業もRubyに還元する動き（スポンサー活動、OSSへのフルタイムコミッターを雇うなど）もあり、良い循環ができているように感じました
Rubyのパワフルさというか、熱量の背景がわかった気がしました
Make RuboCop super fast
タイトル通り、Rubocopを850倍とめちゃくちゃ早くしたという内容でした
自分もいくつものプロダクトに脳死でいれるぐらい好きなGemですので嬉しい
requireするときにrubocopではなくrubocop.serverを実施することで読み込む処理を最適化してめちゃくちゃ早くなるらしい
デフォルトは今までの挙動みたいですが、オプションで実施できるようなのですぐにでも試してみたいところです
Ruby Kaigi 2022 day3
RBS generation framework using Rack architecture
途中からの参加になってしまいましたが、OrthosesというRBS generatorについてのお話でした
https://github.com/ksss/orthoses
その際のアーキテクチャとしてRackアーキテクチャ（オニオンアーキテクチャ）を使っており、実際ネストなどもかなり浅く可読性の高いコードを紹介していました
別のセクションでも書きましたが、型定義の自動生成は型導入のハードルがめちゃくちゃ下がるので本当に良いアプローチだと思います
ここからは完全に推測ですが、だからこそメンテナビリティの高いアーキテクチャ（Rack architecture）を選定されていているのかなぁなんて思ったりしました
録画という特性もあってか発表が穏やかで聞きやすかったです
こちらに予習記事もありました
ご本人の登壇後の記事もありました、感想もまとまっていてエモくなる😁
Let’s collect type info during Ruby running and automaticall
RBSファイルの自動生成についてのお話でした
他の発表でも感じましたが、ここまで型の話があると思ってなかったです
Ruby Committerの方々は型やRBSにめちゃくちゃ関心があること、同時に一般ユーザーにはそれが広がっていないということを危惧している印象でした
TypeProfというRuby3.1でバンドルされているツールとは違うアプローチで自動生成をしており、実コードの実装に寄せた厳密な型定義ができるようになっているようです
Rubyはあとから型を付与しやすいことが求められます
Rubyの型が流行るためには、型定義のハードルそのものを下げる必要があるので、型定義（RBS）の自動生成はそのためにもとても有効なアプローチだと思いました
The Better RuboCop World to enjoy Ruby
個人的に今回のセクションで一番共感できる発表でした
rubocopの違反を避けようとして改悪されてしまうことを恐れる
初学者がrubocopをつかうことで自由さが奪われ、かつrubocopに従わされすぎてしまうのでは？
この2つは今だからこそわかりみが深かった、最初はrubocopをとにかく治すことに囚われてしまい必要以上にメソッド分割していた気がします
今ならRuleを柔軟に見直すことが選択肢にあがりましたが、完全に無視してしまうルール変更にはハードルがあって、結局Rubocopに合わせる
みたいなことめちゃくちゃあったなぁと思い出しました
ルールの妥当性（硬さ）にはグラデーションがある
BADかGOODかをわけるのではなく、EnforcementとInformationとMaybe Goodの領域を作るのがいいのでは？
たしかにそうだ!と思いました。
自分も悩んでいた課題にドンピシャだったので天才か、、、ってなりました（コメントでも盛り上がっていた気がする）
String Meets Encoding
文字コードというニッチながらも、自分も定期的に戦うことになるテーマで興味深かったです
ボトルネックを特定して解消していく思考プロセスを聞くことができたのは勉強になりました
Stackprofを使ってボトルネックをみつけ、着実に原因を特定していく手法は他のパフォーマンス改善でも役立ちそうなので覚えておきたいです
あと、KEN_ALL.csvは地味に馴染みがあってじわりました
Overall review
エンジニアになってから初めて大型のカンファレンスに参加しましたが、非常に面白かったです。コロナもあってあまりこうしたイベントは敬遠していましたが、今までにないような刺激を受けました。
オンラインだけでこれなので、オフラインだったら更に受け取るものもあったんだろうなぁと思います。セクション内容も勿論面白かったですが、Rubyに対する熱量みたいなものを直で受け取りたかったと後悔しています。
次回は松本開催のようですので、必ず行きたいと思います💪
また、直前まで転職活動やらでバタバタしていたこともあり、オンラインチケットを前日に購入したのも失敗でした。。。
30,000円は高かった、、、
次からは絶対早割買おうと思います