RubyKaigi 2025 に参加した

セッションの感想

Ruby Taught Me About Encoding Under the Hood

ima1zumiさんのキーノート。恥ずかしながら文字コード全般のことをほぼ知らない状態だったので、インプットとしてとてもありがたい内容だった。

同様にRubyでUnicodeのバージョンを上げるための方法も初めて知った。

Unicodeのプロパティによる文字クラス指定の話あたりから理解が怪しくなってしまい、動画出たら見直したい。

興味を持って深ぼることで見える世界があることを教えてくれる、素晴らしいキーノートでした。

Make Parsers Compatible Using Automata Learning

PrismとLyamaで別れたときから「人間が差分を把握するの厳しくないか…？」と思っていたので、課題感はスッと入ってきた。

Gemや既存アプリケーションの実装から差分を得る手法だと全文法を網羅できるとは限らないため、アプローチとしては完全ではないと。

ブラックボックスのシステムから推論する仕組みがあることを知ること自体知らなかったので、とても興味深かった。

The Evolution of the CRuby Build System

当方crubyを手元のMacでビルドしたことがあるくらいの知識。

バージョンごとのビルド時間の推移おもしろグラフだった。1系以前も今でもビルドできるんだ...？

すいません、前提整理の途中から置いてからてkateiさんのチャレンジ部分まで正直理解が追いつけませんでした......

Ruby's Line Breaks

直近の金子さんがRubyKaigiでの登壇やかねこにっきでされていた、LRパーサーは複数のオートマトンを合成した一つの大きなオートマトンであるという考え方が、自分の中ではかなり破壊的というかなんてわかりやすいんだと感動したのを覚えています。ドラゴンブックの中ではそういった説明なかった気がしているので。

parserも難解で更にカオスなlexerが存在しつつも、今回の発表にあったlexer/とparser共に一つのオートマトンとして考えられるというアプローチのシンプルさは、電磁気学や熱力学の方程式が美しいと感じるのに近しいものを感じました。

この複雑怪奇なlex stateがいるおかげ（lext stateのせい？）で我々は適当なところで改行しつつ、各自が書き読みしやすいコードが書けているんだなあという感謝の気持ち。

State of Namespace

Namespace導入のためにものコツコツとデバッグするリアルな様子が伝わってきた。

dRuby on Browser Again!

fetchAPIやJSON parser（サーバーサイドのcontrollerやserizlizer）の実装が不要になる話は聞いていてめっちゃ便利そうだった。

crubyと同じコードというか、irbで試したコードがそのままブラウザでも動くとなるとすごい使ってみたくなった。wandsの名前もオシャレ。

Performance Bugs and Low-level Ruby Observability APIs

紹介されていたAPI群は正直にいうとtracepointくらいしか知ってるものなかった。

ただその一般的に馴染みのないAPIを使いやすいようにツールキットとして提供して、更にオリジナルプロファイラをスクラッチで作る様子を紹介するの、あまりにもクールで格好良すぎる。

Benchmark and profile every single change

エディタに行毎に実行コストを表示するの、いいアプローチだなと思った。

パフォーマンス問題はチリツモなのは頭だはわかりつつも、コミット単位で計測しようとはなるものではなかったので、こういった解決法は目から鱗というかいい視点を得られたなと感じた。

How to make the Groovebox

キックの音めちゃくちゃよかったですよね？？？？

趣味でやってることの理解を深めるのにRubyを使うという、生活に根付いた感じも良かったなあ。

自分がdRubyに疎くって、dRubyを使った方がシンセサイザーやシーケンサーを実装しやすい理由のところがピンときてないので後で資料見直す。

Speeding up Class#new

Class#newをインライン化して書き直す話。最大1.8倍だかはやくなるって話だった。

無意識に基本的なところすぎて改善の余地がないだろうと思い込んでたので、こういったところに目を向けられる着眼点がまずすごい。

内容とは直接関係ないけど「コードを読む前に、既存の実装を想像するようにしている」ということを話していて、仮説を立てて物事を進めることの大切さをこの場面でも実感した。

Making TCPSocket.new "Happy"!

怒涛のスライド枚数にも関わらず、思考プロセスや実装が丁寧に拾われていてわかりやすい発表だった。

昨年はHappy Eyeballsがそもなんぞやという感じだったのが、今年は昨年と比べると全体像が掴めたかも。

Road to RubyKaigi: Making Tinny Chiptunes with Ruby

理想の矩形波は無限の帯域幅が必要になるから実際にはどこかで打ち止めにしていると思うのだけど、どのくらいまでやったらゲームで使えるくらいになったんだろう。

Ruby on Railroad: The Power of Visualizing CFG

革命的、すごい、便利すぎる。登壇後にPerlのダイアグラム吐くのに成功した人を見かけていて、Ruby以外でも使える最高便利ツールだ。ydahさんのツール作成腕力クールすぎる。

Making a MIDI controller device with PicoRuby/R2P2

音が大好き......Rubyで音を鳴らしてるの格好良すぎる、最後の演奏も素敵でした。

Road to Go gem

GoをRubyで扱うときの一筋縄じゃいかないポイントが網羅されつつ、ユースケースごとに異なる実装を腕力で解決するすごい内容だった。

たくさんコードとダジャレが出てきた楽しかった。

Analyzing Ruby Code in IRB

TRICKもですがペンさんの発表内に出てくるコード、毎回逆立ちしても思いつかねえなと思ってみている。

スカラーシップスポンサー

個人的な話をいうとRubyコミュニティに若い人が気軽にきてくれたらいいなという思いで始めたもの。所属先で起案して今年で3年目。

今年来てくれた学生さんたちは皆プログラミングが好きで、登壇者に質問しにいったり、いろんなRubyistと交流深めてくれたりしてくれたようでやれて良かった。

今年は自社含めて3社がスカラーシップをやって、取り組みを行うところも増えて嬉しい。もっと多くの学生を連れて行きたい。

ただ現状の各社がバラバラとやってる状況だと定員を超えた応募があった時にお断りをせざるを得ない。せっかく興味を持ってくれてる学生がたくさんいるのにもったいないなと思い、課題に感じている。

- RubyKaigiに各社のコネクションを活かして最大限の学生を連れて行ける

- RubyKaigi Teamの手間がかからない

- 各社が学生とコミュニケーションを取れて採用的なメリットを感じられる

これらを叶える座組。拙い原案はあるのでRubyKaigi Teamや各社でその辺取り仕切ってる面々からフィードバックもらう機会を今度作りたいな。

ただ原案にはデメリットもあるので（主に企業側）、冴えた方法がある方いませんかね...？

Kaigi Effect

Rubyで映像表現

元々音楽が好きだったので音勢の発表全般は刺さりつつ、それ以上にほりぐれさんがRubyMusicMixinのVJをRubyでやっていたのも深く刺さった。

RubyKaigi 2011で発表された内容を振り返って`aviglitch`を使ったデータモッシュを手元で試してみたりしていた。データモッシュ以外にもRubyで映像の面白表現ができないかどうか探っている。AEのプラグインとか眺めつつ、流行りの表現を探していく予定。

RubyKaigi 2025 followup

RubyKaigi 2025 followupというイベントを主催します。みなさん8月30日は空けておいてください。

また昨年同様スポンサーや企画を持ち寄ってくれる企業さんをこの後募集する予定ですので何卒。