RubyKaigi 2026 記録 Part 2: セッション

rubykaigi tech

つづきです。これまでの記事は

です。

だいたいTwitterの記録から再現しています。

Day 1

まさかの初日のKeynoteの途中で疲れて離脱。そんなことある？

Funicular: A Browser App Framework Powered by PicoRuby.WASM

ここ1年のPicoRubyエコシステムのアップデート総まとめみたいな内容。まさかのブラウザからもLチカができる。フルスペックのruby.wasmでなくても十分な場合はPicoRuby.wasmのほうが軽くて便利。そしてPicoRubyがブラウザサイドもカバーしてくれているおかげで組み込み側のいろいろもCLIだけではなくブラウザでできるようになってきている、本当に便利。

Million-Agent Ruby: Ractor-Local GC in the Age of AI

Ractorにちゃんとアプリケーションあるよシリーズのトークその1。並列にAI Agentを走らせるのにRactorが使えるよ、Ractorはオーナーシップが厳密なのが難しいけどそれによってコンテキスト汚染を防げるという便利な性質もあるよ、Ractor Local GCマダー？といった内容。

Rapid Start: Faster Internet Connections, with Ruby's Help

TCPの輻輳制御にRapid Startという新規の方式を提案するにあたってデータを取っていたけどそれを解析したいというのでついでにbetter jqを作ったよ、という内容。…ついででやることかこれ！？！？！？

Building a Standalone Ruby Programming Environment

自作デバイスでRubyのプログラミング環境を作ったという話。DVIの描画がPicoのハードウェアではかなりのリソースを使うのでその残りにがんばって詰め込んでいるのが感じられた。そのうちWiFi対応したいという話だったけどWiFiやれるハードウェアの余裕あるんだろうか…？あと去年のLTで画面にグリッチが出てた理由の伏線回収が行われてたのがエモかった。

Lightning Talks

ピックアップで:

  • cover_rage - a coverage tool for production environment: 残った時間30秒使ってgem installさせようとしてきたのがよかった
  • Road to RubyKaigi: Play Hard(ware): 去年に引き続き時間切れのさせ方が上手い
  • mruby-gpu: The Joy of Talking to Hardware in Ruby: mrubyでVulkanをしゃべる…だと…！？
  • A Concurrent HTTP/2 Server with Ractor: この内容5分は本当にもったいない
  • Your ruby.wasm Doesn't Work on Mobile. Here's Why.: この内容5分は本当にもったいない2
  • Rebuilding Turbo Streams with ruby.wasm and Ruby Sockets: """ikuraをturboにstream"""

Day 2

Twenty Years of JRuby

RubyがわかりやすかったのでJavaエンジニアからスイッチしてずっとJRubyを作り続けてるよ、という話。BuriKaigiで聞いたProject LilliputがJRubyでもオブジェクトサイズの削減に役立っていて、他の言語の話も聞いておくもんだな、と思った。JRubyもOpenSSLのメンテがしんどいというのは去年も聞いたけどこのへん気持ちのある人が少なくてですね…＞＜

Pure Intonation on Browser: Building a Sequencer with Ruby

えっと…RubyKaigiでシャサフ式音楽理論の話を聞くとは思ってなかったのですが…自作言語界隈のほうでなんかあったな〜〜〜と思ってたやつが突然ポップしてきてびっくりした。

Extreme MQTT on PicoRuby

突然PracticalからExtremeにタイトルが変わったな？こっちはRP2040向け、つまりFemtoRuby向けのMQTTを実装した、という話。私が2年前の発表でいろいろ端折った部分をちゃんと解説していてよかった。TLSまで入れると98.8%のメモリ使用になってしまうという話だったけど、それなのでエッジデバイスでTLSはあまりおすすめしてなくて…

From C to Ruby: Porting Doom

gem install doom というフレーズが単純にパワーがありすぎる。でDOOMを移植したけどそれって実質optcarrotじゃない？ということでRuby本体のパフォーマンス問題に気づくことができていくつかコントリビュートしたよ、という話までついてきた。ZJITよりもYJITのほうが速いケースがあるというのは実際他の枠でそういうトークがあったらしいけどここでも出てきていた。

Thread-Coordinated Ractors: The Pattern That Delivers

Ractorにちゃんとアプリケーションあるよシリーズのトークその2。KarafkaでRactor-basedなdeserializationを導入したら数十%〜2倍近いパフォーマンス向上を得られたよ、という話。Ractor関連のバグを踏んだときにClaudeに聞いたら自分が出したバグレポをベースに回答してきたという話が面白かった。まああまり使われてなかったらそうなるわな…。

Integration of PRK Firmware and R2P2

R2P2でキーボードを動かせるよという内容。そういえばDay 1ではすみさんが何事もなくR2P2をキーボードで動かしてたけどあれ自明じゃなかったですね。そしてやろうとしたこと のほとんどがはすみさんに先を越されてしまったという内容だった。…そんなことある！？

Day 3

午前中は函館朝市〜五稜郭エリアにいて、And The World終わったら戻ろうと思ってたらタワーの列が長すぎて戻れなかった。

Smalruby: Visualizing Ruby with Bidirectional Transpiration

確かRubyConf 2014で話を聞いて以来のSmalruby。今はビジュアルプログラミング環境とRubyコードを行き来できるらしい。ということはRubyコードを理解した上でそれをビジュアルのブロックに戻す必要が出てくる。名前から抱くSmallなRubyという印象よりは言語相互変換の仕組みとして理解するのがよさそうということがわかった。

Pythonは入門のパイプラインが学校でできているのが強いよなあ…。

PicoRuby for IoT: Connecting to the Cloud with MQTT

こっちはmrubyベースのPicoRubyかつESP32ハードウェア上でのMQTT。ESP32のSDKはいろいろ便利だけどRaspberry Pi PicoのSDKとかなりインターフェースの勝手が違うのでしんどいよなあ…というのは去年PicoRuby Overflowでしゃべったときも思っていた。

関係していたPull Requestの話が出てたので以下補足です:

github.com

Ruby the Hard Way: Writing Bytecode to Optimize Plain Ruby

YARVバイトコードを最適化するオプティマイザを手書きしようという話。YARVバイトコード手書きの話はLTでもされていたのでだいぶタイムリー（ほんとに？）。Rubyという言語はコンパイラの置いている仮定があまりにも少なく自由なので普通の言語で可能な最適化ができないことがある。「strict Rubyがあれば最適化できるのに…！」みたいなのは毎年言われているがMatzにAnd The Worldで蹴られているようにそれはRubyをRubyでなくしてしまう可能性がある。トーク中ではRBSの指示が正しいことを仮定して、Integer, Integer -> Integerなメソッドを最適化する例を示していた。強い仮定があれば確かにC++でいうコンパイルタイム計算みたいなことができることが示されて、だけど実際はRubyのdynamicな性質によってこんな単純には行かないよ、ということも示された。

Matz Keynote

その上でRubyのAOTコンパイラの話。この並び順には意図があったのか…！？しかしそれなら前のセッションに30人くらいしか来てなかったのは本当にもったいない。フルセットのRubyではないもののサブセットでも特定の用途に限ればAOTコンパイルで数倍の高速化が得られるとのこと。やっぱりstatic Ruby、strict Ruby必要だったじゃないですか！（

ところでこれは言質です:

今年まあまあ記録の量・質が落ちてきてるし出ているセッションの数もだいぶ減ってきているな…。10年前とかは全部聞いてた気がするがどうやってやってたんだ…。