https://tech.andpad.co.jp/entry/2025/05/29/100000

こんにちは、 id:sezemi です。私と同様に RubyKaigi 2025 が終わっていない皆さまもいらっしゃるかと思います。

そこで今回は RubyKaigi 2025 でアンドパッドから登壇したスピーカー 4 名に、発表を終えた余韻を書いてもらいました !!

スピーカーと発表タイトルはこちらです。

Day 1: youchan "dRuby on Browser Again !"
Day 2: ydah "Dissecting and Reconstructing Ruby Syntactic Structures"
Day 2: hasumikin "MicroRuby: True Microcontroller Ruby"
Day 2: makicamel "Road to RubyKaigi: Making Tinny Chiptunes with Ruby"
Day 2: ydah "Ruby on Railroad: The Power of Visualizing CFG"

youchan

こんにちは、@youchanです。RubyKaigi 2025では「dRuby on Browser Again!」という話をしました。

https://slide.youchan-apps.net/slide.youchan-apps.net

タイトルにある通りこのトークには前身があります。RubyKaigi 2017で話した「dRuby on Browser」です。
2017年のトークではOpalを使ってブラウザ上にdRubyを実装しました。今年はruby.wasmを使ったものです。

今年のトークでは、@ledsunさんとの共同のトークとなりました。たまたま同じテーマで別の実装を同時に作っていたことから一緒に出ましょうということになりました。お互いのアプローチがまったく違っていたので、そういう考えかたもあるのかという気付きがあり良いコラボレーションになったかと思います。

RubyKaigiを終えてからはGibier2というツールのメンテナンスをしています。このツールはトークの中でも紹介しましたが、ruby.wasmで実装されており、dRubyを利用しています。

Gibier2の開発の中で感じているのは、かつてOpalで同様のものを開発したときとの比較からOpalの良さを再認識したことです。

OpalはトランスパイラでRubyで書いたコードがJavaScriptに変換されてブラウザ上で実行されます。それに対してruby.wasmはWASMランタイムというJavaScriptエンジンとは違う環境の上で実行されます。

DOMの操作、イベントハンドリング、HTTPによる通信などブラウザ上の操作はすべてJavaScriptで行なわれます。OpalはJavaScriptの世界で動くのでこれらの操作は自然に行なえます。

対するruby.wasmはWASMランタイムからJavaScriptのコードを渡すことでJavaScriptの世界を動かします。ruby.wasmはOpalに比べて何倍も速いというメリットはありつつも、ブラウザアプリを作る上ではOpalにも多くのメリットがあることが分かりました。

発表のおさらいとがんばりポイント

ruby.wasmでdRubyを実装しました。ruby.wasmとdRubyという2つの技術についてお話する必要があったので技術解説が多くなったように思います。

dRubyについてはコード懇親会でも大きな盛り上がりを見せていて、まだまだ人気のある技術だと感じさせられました。あらためてdRubyを紹介することが出来たことは良いことでした。

がんばりポイントは、ruby.wasmを触り始めたのが今年の初めころなのでruby.wasmについてはいろいろがんばりました。とはいえ、数日でOpalでの実装をruby.wasmに移植できたのでOpalもruby.wasmもとても良く出来ていると感じました。

伝えきれなかったこと

前節でも書きましたが、Opalとruby.wasmの違いやそれによるメリット・デメリットのような話は伝えられなかったです。

この話はいつかどこかで発表したいなと思っています。乞う御期待ください。

2026 に向けて

まだ何も考えられていませんが、北海道すこし旅したいですね。今年は松山までフェリー+バイクで行ったのですが、あまりツーリングする時間は取れなかったので来年はもっと余裕のある日程で行きたいと思います。

hasumikin

@hasumikinです。従来のPicoRubyはVMにmruby/cを使用していますが、これをmrubyに置き替える、という開発について発表しました。 MicroRubyとは、この開発のコードネームのようなものです。

MicroRuby: True Microcontroller Ruby

発表のおさらいとがんばりポイント

PicoRubyの主要なアプリケーションにR2P2¹というマイコン上で動くシェルシステムがあり、これを動かすためにはタスクスケジューラをmrubyに実装する必要があります。
CRuby1.9（YARV）では、Threadクラスがpthreadバインドに変更されました。それ以前のバージョン1.8まで使われていたグリーンスレッド実装に似たスレッドメカニズムが、ここで言っているタスクスケジューラです。
タスクスケジューラが動くだけではだめで、R2P2を動かすためにはたくさんのライブラリをmruby向けに移植する必要がありました。
これががんばりポイントでした。

mruby/cもmrubyもVMループの基本的な構造は似ていますが、GCに大きな相違があります。
このあたりのことに触れる余裕がなかったので、この場を借りて簡単に書きます。

mruby/cのGCは参照カウンタ方式です。
これは、C関数内で生成したオブジェクトの生存を開発者がケアしてあげなくてはならないという点では、扱うための難易度が高いものです。
しかしいったん上手く書けると、メモリ利用効率が良い、「ストップザワールド」が発生しない、ソースコード上のオブジェクトの存否が明確であるというメリットもあります。
マルチタスキングとの相性もよいというか、衝突する部分が少ないと思います。

mrubyのGCはインクリメンタルGCで、一般的な起動のトリガはオブジェクトを生成する瞬間です。
オブジェクトの種類によって回収コードが条件分岐したりするし、インクリメンタルのどの段階でなにが起きるのかを理解する必要があり、ここに時間を割きました。
ただ結果的には、マルチタスクとインクリメンタルGCとの間に複雑なガード条件などを書く必要はありませんでした（いまのところ）。

伝えきれなかったこと

今回の発表会場はメインホールでした。メインホールなので、たまたまそこに座っていた聴衆もいただろうと思います。
Rubyでマイコンを動かすという趣味（？）は、私にとってはあらゆることの前提なのですが、たまたまメインホールにいただけの人には意味不明だったでしょう。
開発のモチベーションについて少し説明してもよかったかもしれません。
30分では足りない気もしますが。

2026 に向けて

ことしは3本のプロポーザルを送り、「どれをしゃべってもいいですよ」というフィードバックをもらいました。
つまり3本アクセプトされたも同然です（自慢）。
それらのうち、発表を見送ったテーマのひとつがPicoRuby.wasmです。
このテーマはEuRuKo 2025にも見事アクセプトされました。
が、こちらも2本送ったら両方アクセプトされ（自慢）、もうひとつの別のテーマでEuRuKoへ行くことになりました。
PicoRuby.wasmはまたもやお蔵入りです。
というわけで、1年寝かせてさらにパワーアップしたPicoRuby.wasm（MicroRuby.wasm？）をRubyKaigi 2026へ持っていくかもしれません。

しかし同時に、マイコンネタのアイデアもいろいろあるので、半年後にどうなっているかはわかりません。
RubyKaigiはプロポーザルを通すのが難しく、生半可な開発や、他所で既出のテーマでは通用しません。
とにかく手を動かしてコードを書く。ただそれだけです。

makicamel

こんにちは、@makicamelです。「Road to RubyKaigi: Making Tinny Chiptunes with Ruby」というタイトルでLTをさせて頂きました。「Road to RubyKaigi²」というのはターミナルでプレイするゲームです。これにRubyを音源としたBGMを実装するというお話をしました。

RubyKaigi 2025は音枠がたくさんあってとても楽しかったですね。Day 3にハックスペースでWeb Audio APIを使って音を鳴らしているシーンに遭遇して嬉しい気持ちになりました。音を鳴らすのは楽しいし、Rubyで音をつくるともっと楽しいのでぜひみなさんやりましょう。

発表のおさらいとがんばりポイント

人生初作曲をがんばりました。12小節ほどの短いフレーズですが、考えている期間はずっとファミコンゲームの曲を聞いていました。子どもの頃はファミコン・SFCのゲームで遊んでいましたが、印象に残っている曲がいくつもあります。制限のある状況下で（だからこそ？）強度のあるゲームサウンドはすごいなぁと思います。

技術的にはパルス波（矩形波）のノイズを取るのを頑張りました。最終的には発表の通り角丸にしましたが、当初は波形全体にいわゆるローパスフィルタを適用するなど、直前まで試行錯誤していました。出力デバイスなどによって、同じ波形でもノイズを感じないことがあるのも難航した理由のひとつです。目に見えないものを扱うのは難しいですね。愛媛県県民文化会館のあの格好いいメインホールに音が響いて感動しました。

伝えきれなかったこと

伝えきれなかったというよりも、ゲームとして作りきれなかった部分がたくさんあります。タイトルに「RubyKaigi」という名前を使わせてもらっているので、もっと機能を実装して遊びごころのあるゲームにしたいです。

2026 に向けて

折角ゲームを作っているのだから、パソコンの画面を飛び出して小さなゲームデバイスを作りたいなと思っています。もちろん、PicoRubyで。

ydah

@ydahです。RubyKaigi 2025では「Dissecting and Reconstructing Ruby Syntactic Structures」と、「Ruby on Railroad: The Power of Visualizing CFG」という2つの発表をしました。「Ruby Committers and the World」も含めると3つのセッションにて登壇をしました。

発表のおさらいとがんばりポイント

「Dissecting and Reconstructing Ruby Syntactic Structures」では、Rubyの文法構造を明らかにして、文法定義をリファクタリングする話をしました。
「Ruby on Railroad: The Power of Visualizing CFG」では、構造理解のため文法を図として可視化する話をしました。

前者では、パーサー開発者としての話、後者は、パーサージェネレーター開発者としての話をしました。
どちらもスライドに力を入れていたので、良いフィードバックをいただけて嬉しかったです。