RubyKaigi2024 DAY1予習

RubyKaigi2024 DAY1(5/15)の発表について、超ざっくりと予習というか、こんな感じのお話っぽいな〜というのをまとめました（各トークの紹介文にちょっと補足したりした感じ）。

Writing Weird Code by tomoya ishida

quineで有名なtompngさんのkeynoteです！！
RubyKaigi2022で見た綺麗な金魚のコードがとても印象的でした。
紹介文の

the large effect of writing lots of weird code

というのも気になります。
とても楽しみだったのですが、今回自分の移動スケジュール的に間に合わない・・・😭

The grand strategy of Ruby Parser by Yuichiro Kaneko

CRubyのコミッターで、Ruby3.3で導入されたLrama LALR parser generatorの作者でもあるYuichiro Kanekoさんによる、Ruby parserに関する発表です。
（ここでいうparserは、Rubyで書かれたコードをAST(抽象構文木)に変換してインタプリタ等に渡せる形にするもの。多分。）
RubKaigi2023では、Ruby parserが対応しなければならない問題（ユーザビリティ、保守性、Universal Parserの実現）に対する戦術的な発表をされたようです。
タイトルからすると、今回はより基礎的、根本的なところのお話をしていただける感じでしょうか。
Rubyのコードがどんな仕組みて実行されるのか学ぶことができそうです。

参考

speakerdeck.com | The future vision of Ruby Parser(RubyKaigi2023での発表)
gihyo.jp | Lrama LRパーサジェネレータが切り開く⁠⁠、Rubyの構文解析の未来

Unlocking Potential of Property Based Testing with Ractor by Masato Ohba

Rubyの並列実行の仕組みであるRactorを使って、プロパティベーステストを効率的に実施しようという発表のようです。
プロパティベーステストとは・・・？

プロパティベーステストとは、自動テストの手法の一つで、「システムのあるべき挙動を満たす条件」をプロパティと呼び、その条件を満たすであろう入力をランダムに自動生成し実行することで、想定していない挙動をしないかどうか検証する手法です。
(引用：Qiita | プロパティベーステストをやってみよう)

確かにこれを並列実行したら便利そう！
「あまり知られていないテストメソッドに焦点を当て、Rubyのテスティングポテンシャルをフルに引き出す」とのことで、現場でのテスト作成に役立つお話が聞けそうです。

参考

Qiita | プロパティベーステストをやってみよう

Remembering (ok, not really Sarah) Marshal by Samuel Giddins

MarshalはRubyの組み込みライブラリの一つで、Rubyオブジェクトをファイルや文字列に書き出したり読み戻したりするためのモジュールらしいです（使ったことない）。
現在はあまり使われていないようですが、そこから得られるシリアライズにまつわる知見を共有してくださるようです。
SamuelさんはGemのセキュリティ周りをずっと対応してくださっているとのことで、脆弱性などの観点からのお話が聞けそうです。

参考

Rubyリファレンスマニュアル | Marshalモジュール

Strings! Interpolation, Optimisation & Bugs by Matt Valentine-House

8行のコードを削除したことでstring interpolation（文字列補間。たぶん式展開(#{})とかのこと？）を２倍高速化したお話とのことです！
めちゃくちゃ頻繁に使うものだと思うので、その裏側がどんなことになっていて、そのように改善されたのかが知れるのはおもしろそうです。

Long journey of Ruby standard library by Hiroshi SHIBATA

Rubyの標準ライブラリ整備の道のりとして、bundled gemとdeafault gemについて、また、requiresやbundle exec等の詳細についてのお話とのことです。
bundled gemとdeafault gemについては、柴田さんがすでに記事を書いてくださっているようです。
それによると、

• Rubyインタプリタと同時に配布されている標準添付ライブラリには、Default gems, Bundled gems, 標準ライブラリの3種類が種類がある
• 標準ライブラリは、Rubyのインタプリタの挙動に深く依存し、Rubyのminorバージョンレベルの互換性（3.2系で動くものは3.1系や3.3系だと動かない）
• Default gemsは、標準添付ライブラリのうち、Rubyインタプリタに依存しないライブラリをgemとして切り出したもの
• Bundled gemsは、Default gemsの中で、Rubyコミッタ以外の開発者がリリースまで含めたメンテナンスをを行うようになったもの
  ということのようです。

標準ライブラリを整備するには、こうしたgemの分別が必要なのですね・・・。
インタプリタからDefault gems、さらにBundled gemsを抽出していくにあたり、きっと色々な苦労をされてるのだろうと想像されます。

参考

gihyo.jp | 徹底解説！ default gemsとbundled gemsのすべて

Cross-platform mruby on Sega Dreamcast and Nintendo Wii by Yuji Yokoo

mrubyで、ドリキャスとWiiの両方で動くコードを書いているお話とのことです！
改造なしのゲーム機で動くんですね・・・
今回はほとんど変更なしで両ハードで動くクロスプラットフォームなコードの書き方や、実際に行われている移植作業についてお話ししてくださるようです。
ゲーム機で動くRubyというのがどんな感じなのか気になります！

Namespace, What and Why by Satoshi Tagomori

開発中のNamespace機能について、それがどんなものか、なぜ必要なのかについてのお話です。
RubyはModuleで名前空間っぽいことができるけど、名前空間そのものな機能はなくて、ライブラリ製作者はよく使われる名前は避けなければいけないし、使用者側ももしも使いたいライブラリがお互いに同じ名前のモジュールをトップレベルに持っていたら競合してしまうので、それらを両方使うことはできなくなるなどの問題があります。
これだけなら「トップレベルに固有のモジュール置いて全てその中にくくればいいのでは？」とも思いますが、例えばあるライブラリに他の複数ライブラリが依存していて、かつそれぞれバージョン制約が異なる場合、依存される側のライブラリを複数バージョン持っていたいけど、名前が競合するのでそれができないという問題もあり、これについてはトップレベルに固有モジュールを、というだけでは解決しにくそうです。
Namespaceがあればそうした問題を解決できるはず、ということのようです。
個人的に直面したことのない問題ですが、言われてみれば確かに・・・。
今後本当にRubyに入っていきうるのかも含めて気になるところです。

参考

たごもりすメモ | ご意見募集: Rubyに名前空間サポート的なものが欲しいという話
なるせにっき | Rubyとnamespaceと拡張ライブラリについて

Let's use LLMs from Ruby 〜 Refine RBS type definitions using by Shunsuke Mori (kokuyou)

RubyでLLMを活用するお話です！
Langchain.rbでプロンプトを作ったりいろいろなLLMを使ったりして、RBS Gooseの開発に活用するという内容のようです。
Langchain.rbは、LLMを利用してアプリケーションを開発するためのフレームワークであるLangChainのRuby(Rails)版です。
RBS Gooseは黒曜さんご自身が開発されているツールで、LLMを使ってRubyコードからRBSの型を推量するもののようです！
LLMを活用するような開発をまだしたことがないので、どんな感じなのかぜひ知りたいです。

参考

GitHub | patterns-ai-core/langchainrb
Yu's YuruTech Blog | Ruby版LangChain「LangChain.rb」入門

The depths of profiling Ruby by Daisuke Aritomo (osyoyu)

Rubyのプロファイラの開発についてのお話です。
プロファイリングというと個人的にはDatadogが思い浮かぶのですが、gemとしても色々なプロファイラがあるんですね。
osyoyuさんはpf2という新いプロファイラを開発されています。
上記リポジトリのREADMEでは、特筆すべき機能として複数スレッドのアクティビティのトラック、スレッドごとのサンプリング間隔設定が可能、ネイティブ（Cレベル）のスタックトレースとRubyのスタックトレースを並べて杭録可能という点が挙げられています。
かなり詳細に追える感じなんですね！
パフォーマンス改善でどこが一番重いのか調査しなければいけないタイミングは結構あると思います。
Rubyのトラッキングをどう行なっているのか、どんな困難があるのか、興味深いです。

参考

GitHub | osyoyu/pf2
テックブログです | Rubyのプロファイラメモ

Vernier: A next generation profiler for CRuby by John Hawthorn

前項に続き、こちらもVernierという新しいプロファイラのお話です。
マルチスレッドやGVLのトラッキングができるなど、こちらも詳細に追える感じみたいです。
（新しいプロファイラに求められている要素で大きいものは並列処理のトラッキングということなんでしょうか）
osyoyuさんの発表と合わせて聞くことで、プロファイリングについてより深く理解することができそうです。

参考

GitHub | jhawthorn/vernier

Reline's Journey to GNU Readline Compatibility by Mari Imaizumi

RubyのRelineについて、元となっているGNU Readlineとの比較や、いかにして機能を実装している（する）のかについてのお話のようです。
Readlineは、UNIX系でCLIでのテキスト入力に使用されているライブラリであり、テキストの読み込み・編集・入力履歴管理などを行うものらしいです。
これを純粋なRubyで再実装したのがRelineで、これによってirbの複数行編集など、とても便利な機能が追加されました。
開発体験を大きく改善してくれたRelineについて、その実装がどうなっているのか知ることができそうです。

参考

GitHub | ruby/reline
しまもん | Reline::Faceで快適ターミナル生活
AMBI | Ruby 2.7のここがすごい！ パターンマッチ、コンパクションGCなどをリリースマネージャーに聞いた

Generating a custom SDK for your web service or Rails API by Matt Muller

AWSのRuby SDKのメンテナであるMattさんによる、Smithyに関する発表です。
Smithyは、API作成者がそれを利用するためのクライアントとサーバ、APIドキュメント、テストなどを生成することができるもののようです。便利！
この発表では、Ruby SDKを生成することができるSimthy Rubyを使ってSDKを作る方法を解説してださるようです。
統一的なフォーマットから複数言語のSDKを生成できるのすごく良さそうですね。

参考

AWSブログ | 開発者プレビュー : Smithy を利用した Ruby SDK コード生成

Ractor Enhancements, 2024 by Koichi Sasada

Ractorの最近のアップデートに関する発表で、requireメソッドがメイン以外のractorでは使えないなどの問題の解決方法や、改良した上での性能解析などを話していただけるようです。
RactorはRuby3.0で実験的機能として導入されましたが、機能や性能の不足などから、まだあまり本格的には使われていないようで、そうした点の改良についてのお話が聞けそうです！

参考

クックパッド開発者ブログ | Ruby 3.0 の Ractor を自慢したい
OPTiM TECH BLOG | RubyKaigi 2023 RactorとThread、Ractor local GCについて
.atdot.net | “Ractor” reconsidered（RubyKaigi2023の資料）

An adventure of Happy Eyeballs by Misaki Shioi

Rubyのsocketライブラリにおいて、接続失敗した時に他のアドレスファミリに素早くフォールバックできないという問題があり、これをHappy Eyeballs Version 2アルゴリズムで解決しようとするお話のようです。
Happy Eyeballs Version 2(HEv2)は、IPv4とIPv6の両方利用可能なデュアルスタック環境で、IPv4とIPv6を並列で試してより早く名前解決できた方と通信するという仕組みで、これを使うにあたって冒険があったとのこと。
私は通信部分を触ったことなく、socketライブラリも全然知らないですが、かなりコアなお話が聞けそうです・・・！

参考

ASnoKaze blog | Happy Eyeballs Version 2 の仕様 (RFC8305)
「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 | アドレスファミリ

Refactoring with ASTs and Pattern Matching by Brandon Weaver

ASTとパターンマッチングを組み合わせることで強力なリファクタリングツールとなるというお話しです。
どんな感じなんだろう？？？と思ったら、Brandonさんがそれっぽい記事をすでに公開されていました。
RubyのコードをASTに変換して、それをパターンマッチングにかけて適切にコードをリファクタする小さな実装が紹介されています。確かに便利そう！
記事の公開が結構前なので、当日はよりパワフルな活用方法なども紹介してくれそうな予感です。

参考

dev.to | ASTs in Ruby Series' Articles