こんにちは！サーバーサイドエンジニアの中村(@_naka_0)です。
RubyKaigi 2023に現地参加しています。 1日目（5/11）に聞いたセッションの中でいくつかをピックアップしてレポートしていきたいと思います。
タイムテーブル
タイムテーブルは以下から確認できます。 rubykaigi.org
Matz Keynote
Rubyが生まれてから30年が経過し、そこで学んできた教訓についてのお話でした。
その中でも印象に残った教訓についていくつか紹介していきたいと思います。
良い名前を選ぶ
Rubyは1993年2月24日に「Ruby」という名前が決まったそうですが、この名前が決まる前に「Coral」、「Tish」のような名前の候補があったそうです。 もし、「Ruby」ではなく「Tish」という名前であったら、ここまで多くの人に使われることはなかったかもしれないとのことでした。 この時のことを振り返り、良い名前を選ぶことの重要性を学んだそうです。
最初に決めた基本的原則は保持する
実際にMatzの手元にある一番古いコードは最新のRubyのコードと大きくは変わっておらず、開発当初の時点で基本の部分はすでに完成していたとのことです。
他の人の意見を聞いて、自分の視点では得られない気づきを得ること
1995年12月にRubyをインターネットに公開する前に有志の人に意見を募ったところ、20名程度の人の意見が集まったそうです。 その際、他の人の意見を聞くことで自分の視点では得られない気づきを得ることができたとのことでした。
人と人とのつながりの重要性
2001年9月に行われたJAOOというデンマークのカンファレンスにMatzが参加した際に、当時学生インターン生として参加していたDHH（Railsの生みの親）と話していたそうです。
この後、DHHはRailsを作ることになったそうですが、「この時は後にその人がRailsを作ることになるとは思ってもみなかった」というエピソードが特に印象に残りました。
これらの他にも本の出版や様々な人との出会いが今のRubyにつながっているという素敵な話でした！
リーダーシップとビジョンの提示
Ruby3x3（Rubyを3倍早くする）という目標を掲げた際、Matzは確実にそれが実現できるとは思っていなかったそうです。
しかし、Matzがビジョンを提示したことでMJITやYJITに繋がり、結果的にRubyの性能改善を実現できたそうです。
develop chrome extension with ruby.wasm
develop chrome extension with ruby.wasm - RubyKaigi 2023
本セッションの登壇者の方は実際にruby.wasmを使用してChrome拡張機能を開発してみたそうですが、Rubyらしい書き心地が得られないことに課題感を感じたそうです。
そこで、Rubyのスクリプトを読み込むだけでChrome拡張機能を作成できるようなフレームワークである「unloosen」を開発することに至ったとのことでした。
https://github.com/aaaa777/unloosen
このフレームワークを使用してChrome拡張機能を開発すると、上記リポジトリのREADMEの「Quickstart」に書かれているように少ないコード量とシンプルな構文で拡張機能の開発が実現できるとのことでした。
今後の展望としては、このフレームワークのドキュメント充実化やmanifest.jsonを自動生成できるようにする仕組みを挙げられていました。
また、このフレームワークはGemでは配布しておらず、npmとして配布しているそうです。
https://www.npmjs.com/package/unloosen-ruby-loader
まだ作成したばかりとのことなので、コントリビュートして貢献するのも良さそうだなと感じました！
Power up your REPL life with types
Power up your REPL life with types - RubyKaigi 2023
Ruby irbの補完は便利ですが、メソッドチェーンやブロックパラメータの補完が正確ではない（誤った補完やありとあらゆる候補が出てきてしまう）といった問題があります。 そこで、より正確な補完にするため、irbとRBS（Rubyの型定義を提供する機能）を組み合わせたGemである「katakata_irb」を作ったというお話でした。
「katakata_irb」のリポジトリは以下です。 https://github.com/tompng/katakata_irb
この「katakata_irb」をrequireすることで、メソッドチェーンしてても、ブロック引数・変数などを使ってても、ある程度正しく型を推測して補完候補を出せるようになるとのことでした。 他にはプロダクトにRBSをきちんと書いている場合、rails consoleでもこの補完機能が使えるようになるようです。 また、Gemに型定義がされている場合（rbs_collectionにも型定義されている場合）でも「katakata_irb」の恩恵を受けることができるとのことでした。
既存のプロダクトでも型を定義していればrails consoleでも使えるとのことなので、RBSを導入して型情報を増やしていけると開発体験が上がりそうだと感じました。
Lightning Talks
1発表5分で合計12のLT登壇がありました。
その中でも私が一番興味深いと感じた「RBS meets LLMs - Type inference using LLM」というセッションについてご紹介します。
このセッションでは、LLM（大規模言語モデル）を使って型の推測を行うことができないかという発想から、ChatGPTを使ってコードの型を推測する方法をデモを交えながら紹介していく発表でした。
ChatGPTにコードの型を推論させようとすると、出力されるRBSの構文がおかしいことや不要な出力がある等の課題が出てきたそうです。 そこで、Fewshotを用いて意図した出力が得られるように改良していった様子が紹介されていました。
Matz KeynoteでもLLM等で型を推論できないかどうかの話があったため、個人的に今後の発展に期待が持てそうな分野だと思いました。
おわりに
セッションの中では自分の理解が追いつかなかった部分もありましたが、普段は学べないことを学べたり、多くの刺激を受けることができた1日目でした！ Day2以降の記事も公開予定なのでぜひご覧ください。
是非読者になってください
メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！
■募集ポジションはこちら
■エンジニア紹介ページはこちら
