はじめに

愛媛県松山市で開催された、2025年のRubyKaigiに参加してきました。2回目のRubyKaigi参加です。昨年の参加ブログはこちら。

ある程度私にも理解できて、かつ印象に残ったセッションの概要と感想を書きます。雑談はトグルで折りたたんでおきました。

Day -4 から Day 0

Day -4 から Day 0

四国に行くのが初めてだったので、せっかくなら四国一周しよう！と決めて、前週の金曜日に四国入りしました。香川→徳島→高知→愛媛の順番に周りました。四国グリーン紀行という、特急グリーン車にも乗り放題の周遊きっぷが大活躍でした。


鳴門の渦潮
RubyKaigiは最近始めた副業先の方たちに挨拶できる機会でもあったのですが、出発直前にその副業先でちょっとバグらせてしまい、移動時間はちょこちょこバグ修正もしました。これからも大歩危峡を見るとそのバグを思い出しそうです。

Day 1

Bringing Linux pidfd to Ruby

karafkaの作者で、セキュリティ企業に勤めているMaciejさんのセッションでした。

Karafka is a Ruby and Rails multi-threaded efficient Kafka processing framework

Linux 5.3から追加された、pidfd (Process File Descriptor)をRubyに導入する取り組みについて発表されました。

PID (Process ID)はただの数字で、killしても再利用されることにより、競合したり、モニタリングが正しくできなかったり、間違ったプロセスにシグナルを送ってしまう問題があります。pidfdをRubyに導入できれば、それらの問題を防ぐことができそうです。
とはいえpidfdが必要になるケースは、限られたエッジケースで、ほとんどの場合pidfdはオーバーキルだと言及されていました。それでも取り組み続けていこうと思う、とのことでした。

直近の予定としては、スタンドアロンのgemとしてpidfdを使えるように提供したり、LinuxでないmacOSやWindowsでも代替手段を用意する予定とのことでした。

Empowering Developers with HTML-Aware ERB Tooling

Herbという、HTML+ERBを解析できるパーサーについてのセッションでした。

Ruby on RailsでViewレイヤーを実装しようとすると <h1><%= @variable %></h1> のようにHTML+ERBを書きますが、今までHTML+ERBには開発サポートツールがありませんでした。そこで開発されたのがHerbという、HTML+ERBを解析するパーサーです。
https://github.com/marcoroth/herb

パーサーはリリース済みでPlaygroundもここにあります。Herbを活かしたformatterやlinterもリリース予定とのことです。
http://herb-tools.dev/playground

最近はHotwireなどでViewレイヤーの開発もRuby on Railsで快適に行えるようになってきました。Ruby自体には色々なツールが開発されてきたけれど、Viewレイヤーにも同じくらい目を向けるときがきたのではないか、それをHerbで実現できると良い、とのことでした。

私もHotwireは以前試して期待感を持っていますし、フロントエンドまでRuby on Railsで完結したい場面がよくあるので、Herbのformatterやlinterが使えるようになるのが楽しみです。

オフィシャルパーティー

オフィシャルパーティー

昨年はチケットを買いそこねたオフィシャルパーティーに無事参加できました。城山公園で野外開催という、まさにフェスでした。
1番面白かったのは、会場に入ろうとしたら、お酒片手に散歩していた地元の方が "これ何のイベントですか？" と話しかけてくれて、RubyKaigiの説明を何とか一生懸命したら "へーー頭いい人たちなんですね！" と返ってきたことです。色々面白い方で、10分くらい話してから会場に入りました。旅のこういう瞬間は醍醐味です。
Day -4 - Day 0に書いた、副業先の皆さんにも挨拶できました。バグらせちゃってすみません！で挨拶すると、ちょっとアイスブレイクになって良かったです (良くない)。

Day 2

ZJIT: Building a Next Generation Ruby JIT

昨年のRubyKaigiではMaximeさんからYJITの発表がありましたが、今年はYJITを更に向上するZJITの発表でした。発音はZee-JITで、Zed-JITでは無いとのこと。

YJITは約20%のスピード向上を実現できましたが、いくつかのベンチマークでは期待ほど良くなくて、例えば10億回のネストされたループではJavascriptがRubyより10倍速かったりしました。
そこで直近2.5ヶ月くらい取り組まれているのがZJITです。YJITは同じコードを何度もコンパイルする非効率さがありますが、ZJITではコンパイル済みのコードを再利用することでパフォーマンスを向上を目指すそうです。
ZJITはまだWIPですが、Ruby 3.5.0で利用可能になる予定です。ただYJITもRuby 3.5.0に含めるので、ZJITでビルドしたいときは ./configure --enable-zjit を必要にする予定、とのことでした。

Issueはこちらで、MatzはZJITの開発については、チームを信頼して任せてくれています。
https://bugs.ruby-lang.org/issues/21221

まずはYJITと同じパフォーマンスを出すことが目標で、YJITのパフォーマンスを打ち負かすには少し時間がかかりそう、とのことでした。"パフォーマンスが悪かったらそのプログラミング言語はいつか死ぬ" ともおっしゃっていて、YJITでも相当偉大なのに、パフォーマンスへの飽くなき探究心を感じました。

Day 3

Eliminating Unnecessary Implicit Allocations

Ruby 3.4で、内部的に無駄な配列やハッシュへの割り当てを削減した、というセッションでした。

Ruby3.3で、変更や修正により無駄な割り当てが発生するリグレッションが3つ起きたので、それらを約2週間という短期間でRuby3.4で修正したそうです。このようなリグレッションを今後防ぐにはテストを書くしかない、ということで様々な割り当てパターンのテストを書いたら、他のパターンも改善できた、とのことでした。

Rubyではsplat展開 * やキーワード引数が書けますが、場合によっては無駄な配列やハッシュへの割り当てが発生していました。例えばこのような呼び出しで発生していた無駄な割り当てを、Ruby 3.4では解消したそうです。

a(1, *ary, **kw, **kw, &block)

パーサーの実装には理解が追いつきませんでしたが、シンプルにテストを書くことの重要性もひたすら伝わってくるセッションでした。

Matz Keynote

AIと私達の共存についてのお話が面白かったです。"私達がAIの召し使いになるべきではない、あくまで私達がAIを使いこなすべき" や "プログラミングの面白い部分をAIにやらせる (取られる) のは違わない？" という趣旨の言葉が刺さりました。

私は "個人的には共感するけれど、きっとこの流れはもう誰にも止められないのだろうな…" と何だか切ない気持ちになりました。自分がどちらに舵を切るか、決断を迫られている感じもしました。

RubyKaigi後の色々

RubyKaigi後の色々

 Drink Up昨年は企業主催のDrink Upに参加しなかったのですが、今年は最終日だけ参加してみました。2日目のLightning Talksで "Ruby on Playstation" の発表をしたポーランドの方と同じテーブルで、準備の裏話を色々聞けて楽しかったです。多国籍なテーブルで、それぞれの母国語のweirdな単語を教え合ったりしました。

 Ruby Music Mixin昨年から気になっていた、RubyistがDJするイベントRuby Music Mixinに友人と行きました。皆さんシンプルにDJもVJも技術が高くて驚きました。確かにエンジニアと親和性高そうですよね。最近DJコントローラーを買ったので、モチベーションが高まりました。

普段ライブやクラブにはいなさそうな、RubyistやRubyコミッターたちが音に揺れている光景は貴重でした。そのあと友人達としょうもない話をして、3時頃に宿に帰りました。

 Day 4死んだ顔で宿をチェックアウトして、ささっと買い物や観光をしました。漱石珈琲店 愛松亭というカフェの看板猫に会いに行ったら、とても人懐こくて最高の時間を過ごせました。

まとめ

普段会えない友人や知人と話したり、色々な企業や人を知ったり、個人的にはコミュニケーションにほぼ全振りのRubyKaigi参加回でしたが、これはこれで良かったなとも思います。

来年の函館も参加するか？と言われると、もうちょっとセッション自体を理解する準備をしてからが良いな…とは思います。参加不参加に関わらず、来年もどのようなRubyKaigiになるのか楽しみです 🐻‍❄️

Discussion