こんにちは。
hacomono Engineering Office の りゅーほ @rh1011_ です。
hacomonoは、先月沖縄・那覇で開催されたRubyKaigi 2024にプラチナスポンサーとして協賛をさせていただきました。
また多くのエンジニアと一緒に現地参加をしてきましたので、この記事ではRubyKaigi 2024に参加したエンジニアのセッションレポートをお届けします。
[Day1] Unlocking Potential of Property Based Testing with Ractor
▼フィーチャー部 pei（三瓶）
SmartBank社のohbaryeさんのお話。決済系の会社の方のお話なので、業務で近いことをやっている身としては、ぜひ聞きたいと思っていました。
Property Based Testing が Ractor のユースケースとしていいのでは？というところから始まり。
Property Based Testing とは、普段我々が書いている Example Based Testing とは異なり、大量で多様な値を生成してその値を用いてテストを行う手法のことです。
これによってエンジニアでは想像できず本番でのみ起こってしまうようなバグを事前に発見することが期待できます。
そのような機能を持つテストライブラリとして pbt という gem を開発されており、デモを見ましたが、seed を指定して失敗したテストが再現できるところや shrinking という再現する最小の値を見つける実装などもあり、とても便利そうなライブラリでした。
結論としては、一部のユースケースでは Ractor による性能改善が見られたものの、ほとんどは直列実行の方が結果が良かったとのことです。
それはそれとして、Property Based Testing はとても有用な手法であると感じられ、CIで動かすには少し難しさがあるかもしれませんが、バグを極力抑えたいコンポーネントにおいては導入してみる価値があると感じました。導入してみたい。
[Day1] Namespace, What and Why
▼フィーチャー部 kai（甲斐）
namespace 機能を利用することで、影響範囲を限定してモンキーパッチを当てることができる点はとても便利な機能だと感じました。
hacomonoではモジュラーモノリスが採用されていて、各モジュール単位でライブラリを導入したくなることは今後考えられます。
そのときに全体に影響を及ぼすような変更はあまり望ましくないので、それを閉じた形で使用できるのはとても魅力的でした。
▼リアーキテクチャ&イネーブルメント部 Saimon（野崎）
Rubyで名前空間というとmoduleを想起していたので、名前・定義以外にバージョンも識別したいニーズがあることをはじめて知った。
たしかに、名前だけでも“User”や“Configuration”はいろんなところで定義するので衝突しやすいのは共感。
標準ライブラリの話ともオーバーラップすることとして、Ruby本体に入っている（という言い方が正しいのか？）ものとそうでないものを区別できると調べ物する時に便利そうな感触。
[Day1] Exploring Reline: Enhancing Command Line Usability
▼フィーチャー部 pei（三瓶）
irb, reline のコミッターの方のお話。
irb と reline の関係性がいまいちよくわかっていなかったのですが、発表を聞いてだいぶ理解が深まりました。
また、3.0 ~ くらいからかと思いますが、irb 関連の開発が活発になっているようで、普段開発時に rails console を常駐させてヘビーユースしている身としては、とても嬉しいなと感じました。
現在 hacomono では pry を使っていますが、いまとなっては irb に切り替えてもいいんじゃないかと思います。
実際手元で使ってみると、ls などよく使う機能もありますし、補完もリッチなのでみんなにも喜ばれそうな気がします。
repl_type_completor gem を有効化するとさらに強力になるらしいので、これも近々試してみたいと思いました。
reline は GNU readline 互換を目指しているものの、現時点ではまだ不足しているところも多く、絶賛開発中のようでした。
開発の裏話を聞くと、コマンドラインエディタの開発はかなり難しそうに感じました。
ただ、個人的にはとてもおもしろそうだなとも思えたので、いつか何かの形でお手伝いできたらいいな〜とも思いました。
[Day2] RuboCop: LSP and Prism
▼フィーチャー部 pei（三瓶）
Rubocop コミッターの方のお話。
Rubocop は linter, formatter という役割を持っていましたが、LSPを内蔵するようになり、--lsp オプションで使えるようになりました。ruby_lsp がモノリスLSPという位置づけである一方で rubocop はマイクロlsp という位置づけのようです。
実際に rubocop lsp を使っているのですが、かなり高速にエラー表示や修正ができるので非常に使い心地が良いです。
また、面白かったのは、LSPの出現によって、これまで書き終えたコードに対して lint/format を実行すればよかったところ、書き途中のコードに対しても正常に実行できることを考えないといけなくなったというところで、これは開発者にとってはめちゃくちゃに難易度が上がったのではないかと想像されました。
そして、そこで Prism という新しいパーサーの出番が出てくるというところで、ここでも新しいパーサーは必要だったんだなーというのを再認識できました。
[Day2] Community-driven RBS repository
▼運用保守部 tosshi（戸島）
Rubyのような動的型付けの言語は型がなく自由だからこそ良いのですが、静的型付けによって型の安全性につながる（バグ混入を防ぐことができる）というメリットもあり、導入される動きが活発になんだろうなぁと思っています。
RBSもそれで、今回登壇されたpockeさんはRubyコミッターでRBSに力を入れているみたいでした。
色々な方がコミュニティに参加してくれていて、リポジトリのディレクトリ単位にコードオーナーを設けるようにしているが、やはり権限周りによってできる人とできない人との負担差が大きくなっちゃっている・・これをなんとかしたい。
そこでcommunitiy-drivenという考えを導入して、できるだけ（例えば）権限まわりで苦労することないように、actions使ってマージできる仕組み作ったよという感じでした。
あと協力してくれる方がもっと欲しい！！と切実に話していました。
リアーキテクチャチームのエンジニアの顔がチラつきました。。
RBSはどこかでhacomonoに導入されると思っているのと、使い側でなく作る側にhacomono社員がいることに大きなメリットがあるような気がしています。
[Day3] Ruby Committers and the World
▼リアーキテクチャ&イネーブルメント部 Saimon（野崎）
3日間いろいろなセッションを聞いた中で、私が最も興味深く聞いたセッションでした。
アジェンダに私はほとんど知見がありませんでしたが、様々な分野で活躍されているコミッタの方から色々な意見が出、Rubyに広がりを最も感じられました。
特に、frozen_literal_stringはデフォルトでtrueであるべきか？に対する回答は、様々なRubyのユースケースを表す良いテーマでした。
望ましい結論を得るのにまだ時間がかかりそうでしたが、Rubyがどのように意思決定されているのか、垣間見えたように思います。
[Day3] Using Ruby in the browser is wonderful
▼スクール部 sho（山下）
RubyアプリケーションをWebブラウザ上で動かすruby.wasmの話。
ruby.wasmとは何かといったところから、JSとRubyでできること・できないことを挙げそれらの架け橋になるツールについても発表されていました。
JSはnew演算子だがRubyにはnewメソッドしかないため、newメソッドでJSオブジェクトを生成するようにした話などは興味深かったです。
またデモでは、ターミナルで動かしていたテトリスアプリケーションを、ロジック部分はそのままにWebブラウザ上で動かしており、Rubyスクリプトがブラウザで読み込まれているのが新鮮で面白かったです。
今後も新しいツールやフレームワークが追加されることで、Rubyでのアプリケーション作成の幅が広がるかと思うので楽しみです。
[Day3] Speeding up Instance Variables with Red-Black Trees
▼スクール部 たなしゅん（田中）
オブジェクトシェイプ
- Ruby3.2に導入されているオブジェクトシェイプに加え、3.3では平衡二分木一つである赤黒木のキャッシュが導入された話
- インスタンス変数のパフォーマンス向上につながる改善
そもそものオブジェクトシェイプについて、なるべく同じ順序で同じオブジェクトシェイプを共有するように書くことでパフォーマンスの向上につながるというもの。
たとえば同じクラスを元にした別インスタンスでそれぞれ別々の順序でインスタンス変数の生成をしてしまうとオブジェクトシェイプは共有されない。
メソッドの呼び出し順に依存する形でインスタンス変数を定義するよりはinitializeで定義することで全てのインスタンスでオブジェクトシェイプを共有することができ、パフォーマンス向上につながる。まったく意識してこなかったので結構衝撃的でした。
赤黒木の導入
- https://github.com/ruby/ruby/pull/8744
- 3.3でオブジェクトシェイプのキャッシュに赤黒木を利用するようになった
- 最悪計算量が O(n) -> O(log n) に改善された
赤黒木の導入により、よりインデックス探索の計算量が抑えられるという話だが、そもそもオブジェクトシェイプの仕組み自体がとても勉強になりました。
赤黒木の導入による改善点がまだよく理解できていないのでどこかで時間をとって学習してみたいが、その手前としてオブジェクトシェイプを意識したインスタンス変数の持ち方を心がけようと思えました。
[Day3] The state of Ruby dev tooling
▼フィーチャー部 pei（三瓶）
ruby_lsp 開発者の方の、Rubyの開発ツールの現状についてのお話。
Rust や Go といった新しい言語は、開発ツール(lsp, linter, formatter, installer, etc)が統一されていて、ほぼ迷うことがありません。
その一方で Ruby は様々なツールが存在して分散しており、これこそがRuby開発ツールにおける最も大きな問題だと認識されているようでした。
JavaScript は Ruby よりもさらに分断されているといえますが、利用している開発者の数も多いため、Rubyと比べると大きな問題とはいえません。
Ruby の今後の発展のためには、大きなビジョンを描いて、Rubyコミュニティの努力を1箇所に集約することが必要だと述べていました。
Ruby はデファクトスタンダードとして使われているツールが多いような気はするので、統一していくことはそこまで非現実的ではないと感じました。
bundler など、公式に取り込まれる動きも過去実際にあったので、rubocop や rspec が入っていく未来もあるのかなーと、そんな未来を少し想像しました。
一方で自分が使っているツールがスタンダードでない扱いになると地味に悲しいなとも思うので、そういった難しさはあるのかもしれません。
[Day3] Matz Keynote
▼フィーチャー部 pei（三瓶）
Matz のキーノート。これまでの RubyKaigi では Opening に話していたので Closing で話しているのは新鮮でした。ご本人も同じようなことを仰っていました（各所からの期待があって、いつになく緊張されていたらしいです）。
発表内容としては、例年と同じように Ruby の歴史的な話や直近のアップデートについて取り上げつつ、今後もっと Ruby が良くなっていくために必要なことやビジョンについて話されていました。
何度聞いても面白いなと思わせてくれるのはさすが matz だと感じます。当面は Perfomance 系のアップデートがメインになっていきそうなことがよくわかりました。
Ruby の開発者の方が未来に希望を持たせてくれる話をしてくれるのはいつもいいなと思います。今後も Ruby を使っていきたいと思うと同時に、次のバージョンの Ruby を使えるのが楽しみです。
▼リアーキテクチャ&イネーブルメント部 Saimon（野崎）
RubyKaigiのセッションを引用しながら、Ruby 3.3+以上の最新のRubyの動向をよくまとめた、気付きの多いクロージングでした。
他のセッションも通じて、Rubyは十分に速くなっている（少なくとも昔言われていたほど遅くない）と断言して問題ないと、自分も思いました。
他言語コミュニティを例に取りながら、コミュニティによって言語が成長していくためにはどうすればよいか = 完全なリライトではなく、常に現在の延長で考えて作る、という話があり、この話は私の経験をより裏付けるものともなりました。
つまり、製品でも言語でも、作り変えるのではなく現在の延長で改善するしかなくて、過去の遺産と断絶が生まれることでソフトウェアに継続性がなくなってしまう。ずっと改善できているRubyコミュニティが本当に頭が上がらないですし、称賛されるべきものだと思います。
他にもいくつかトピックはありましたが、少なくとも私個人はこのコミュニティに支えられているRubyは今後もっと進化するはずなので、自分もいけるところまでついていきたい。
さいごに
hacomonoは初めてRubyKaigi 2024に組織として参加させていただきました。
今回得たたくさんの学びをhacomonoプロダクトの開発に活かしてまいります。スピーカー、コミッターの皆様、貴重で刺激的なお話をありがとうございました！
＜番外編＞
ブース担当としてエンジニアとともに現地参加したhacomono PRのともPが会場の雰囲気やhacomonoのブースの様子をレポートした記事もありますので、こちらも併せてご覧ください！
note.com
株式会社hacomonoでは一緒に働く仲間を募集しています。
採用情報や採用ウィッシュリストもぜひご覧ください！
