Raksulサーバーサイドエンジニアの平島です。 去年の初参加に引き続き、RubyKaigi 2023へ現地参加してきたので、印象に残った発表について紹介します！
RubyKaigi 2023
RubyKaigiとは、Rubyプログラミング言語のコミュニティが年に一度集まる、盛大な国際カンファレンスです！ ここでは、世界各地から集まったRubyの開発者やエンジニアが、様々な発表を通して知識を共有します。
RubyKaigiの大きな特徴として、Rubyそのものの開発者による発表の多さが挙げられます。 普段使っている言語について、開発者から直接お話を聞けるというのはとても貴重な経験です！ Rubyの開発者たちによる発表では、今後のRubyの開発の方向性や、開発者の考え方を直接知ることができます。 内容はとても高度なものが多く、話についていくことすら困難な発表もありますが、普段は接する機会の少ない最新の技術情報に触れることができ、非常に刺激的で楽しい経験となります。
さらに、もう一つの特徴として、活発なコミュニティの存在が挙げられます。 RubyKaigiには、Rubyの開発者だけでなく、Rubyを活用した開発を行っている企業や個人のエンジニアも多く参加しています。 そのため、懇親会やアフターイベントなどを通じて、多くのエンジニアとの交流を深めることが可能です。
今年のRubyKaigi2023は、長野県松本市で開催されました。 3日間の開催で、約1,200人のRubyistが現地参加したようです。 近隣の食事処や駅、ホテル、松本城など、どこに行ってもRubyistばかり！街全体がRubyKaigiで盛り上がっていました。
事前準備：RubyKaigiへの道
RubyKaigiを最大限に楽しむためには、しっかりとした準備が欠かせません。 まずは、セッション選びから始めました。 「RubyKaigi 2023 Schedule.select」を活用し、自分が見たいセッションを先に選び、一緒に参加するメンバーと共有しました。 これにより、当日はタイムスケジュールに悩むことなく、時間を有効に使うことができました。
次に、特定のテーマに絞って予習しました。 今年は「JITコンパイラ」、「静的型解析」、「パーサ」の3つを中心に進めました。 JITコンパイラについては、Rubyの処理系の歴史や、YJITのパフォーマンスがどこから来るのかを学び直しました。 一方、静的型解析については、関連gemのリポジトリを巡り、最新の動向を把握。 そして、パーサについては、Rubyのparse.yを眺めて理解を深めました。 また、各テーマについては、過去のRubyKaigiの発表も参考にし、理解を深めるための資料としました。
最後に、自分はSmartHRさんの「Matsumoto Box」に応募していたため、開催前からRubyKaigiの雰囲気を自宅で先取りすることができました。 このボックスの中には、オリジナルボトル、松本の地元のお菓子、安曇野の水、水出しコーヒーパックなどが詰まっていて、その一つ一つがRubyKaigiへの期待を高めてくれました。 （同梱されていた「ふるだけで水筒の茶渋もきれいになる ボトルクリーナー」も嬉しいお気遣い！ありがとうございました！！）
印象に残ったセッション
私が聞いたセッションの中で、特に印象に残ったものを紹介します！
The future vision of Ruby Parser / Yuichiro Kaneko
Rubyにマージされた新しいパーサー[Lrama](https://github.com/ruby/lrama)の開発者Kaneko Yuichiroさんによる、Rubyの既存パーサーの問題点とその解決についてのセッションです。
[JA] The future vision of Ruby Parser / Yuichiro Kaneko @spikeolaf (www.youtube.com)
新パーサーは大きく3つの改善点があります。
Error Tolerant
１つめは、Error Tolerantの改善です。 これは何かというと、構文に問題の有るコードをパースした際に、より開発者フレンドリーな情報を返すことができるようになったということです。
既存パーサーでは、ある箇所で構文エラーがあった場合、前後のコードを捨てることによって構文木を作成していました。 一方新しいパーサーでは、削除だけではなく、足りない要素を仮挿入することで構文木を作成します。 これにより、LSP(言語サーバープロトコル)を通じて、書きかけのコードに対するより強力な補完やサジェストが可能になるかもしれません。
メンテナンス性
新パーサーLramaの重要な改善点の２つめは、パーサーコードのメンテナンス性の向上です。 旧パーサーのコードは長くて複雑で、特にレクサー（字句解析器）とパーサー（構文解析器）が密結合している部分がメンテナンスを難しくしていました。
例えば、Rubyではdoというキーワードが複数の働きを持っているため、解析が難しいケースが存在します。旧パーサーでは、レクサーが複数の状態を持ち、4種類のdoをそれぞれ異なるトークンとして扱っていました。このように、構文解析のロジックがレクサーにまで及んでしまうことが、密結合性を生む原因となっていました。
一方、新パーサーでは、この問題をNonterminal attributesというアイデアと、それに優先度を設定することにより解決しました。これにより、レクサーとパーサーのロジックが分離され、コードのメンテナンス性が大幅に向上しました。
Universal Parser
最後に、新パーサーはRubyだけでなく、他のgemからも利用可能なUniversalなパーサーになりました。 現在、rubyからの切り出し作業が完了し、その後のinterfaceの整理などが行われています。
Build a mini Ruby debugger in under 300 lines / Stan Lo
ShopifyでRuby LSPなどの開発をしているチームのStan Loさんによる、Rubyデバッガを300行未満で作成してみようというセッションです。
実際にはたった189行で、breakpointやstep in/outなどの機能を5段階のステップバイステップで実装していく、とてもおもしろいセッションでした。 さらに、セッションの終わりには、今後のデバッガ強化のための追加機能についての提案があり、取り組んでみたいと思っています。
全体的に、このセッションはデバッガーの作成方法について深い理解を得るだけでなく、自分で何か新しいものを作る際の刺激にもなったと感じました。
[EN] Gradual typing for Ruby: comparing RBS and RBI/Sorbet / Alexandre Terrasa
こちらもShopifyでRuby LSPなどの開発をしているチームの、Staff Production EngineerのAlexandre Terrasaさんによる、RBS/SteepとRBI/Sorbetの比較についてのセッションです。
RBSはRuby3.0から導入された公式の型定義です。 RBSで型定義を行い、Steep gemを用いて型チェックを行えます。 一方、RBI/Sorbetは、Shopifyが主導して開発した静的型解析ツールで、RBIで型定義を行い、Sorbetを用いて型チェックを行います。
Ruby本体にバンドルされているのはRBSですが、速度面ではRBI/Sorbetのほうが圧倒的に優れており、どちらをプロジェクトに導入するほうが良いか悩む方も多いと思います。 このセッションでは、それぞれのツールの具体例などがわかりやすく整理されており、さらにShopify社内での導入結果なども紹介されてとても参考になりました。
それまで、私自身は型注釈の利便性を感じていましたが、チーム全体の負担という観点からどうかと考えていました。 しかし、Shopify社内で「型注釈を続けたい」と回答した人が約8割もいるとの情報を得て、自分のチームでも試してみる価値があると感じました。 初期導入には、パフォーマンスを考慮してRBI/Sorbetを試してみたいと思っています。 tapiocaやsorbet-railsを使えばRBIの自動生成が可能なので、低い導入コストで簡単に試すことができそうです。
感想
全体を通じて、今年のRubyKaigiも非常に刺激的で、とても楽しむことができました！ 言語の開発者から直接新機能の解説を聞いたり、他社のエンジニアと意見を交換したりすることで、日常の業務で狭まってしまいがちな視野を大きく広げることができました。 そして最先端の技術について学ぶことはもちろん、それらを自分の業務にどのように適用できるかを具体的に考える機会にもなりました。
来年のRubyKaigi 2024は、沖縄県那覇市で開催ということで、参加者も増えてより盛り上がるカンファレンスになるのではと期待しています！ それでは、皆様にまた会場でお会いできることを楽しみにしています！
