参考: RubyKaigi 2026タイムテーブルを一覧表示
RubyKaigi 2026の演目:
Day1
08:30–09:30
「Ruby Box」は、Ruby 4.0で導入された新しい実験的な機能です。ここでは、Ruby Boxの基本的な仕組みを紹介し、Rubyプログラムの実行中にボックスを見つけたり特定したりする際に生じる問題点、難しい点、そして技術的に興味深い点について説明します。
/icons/hr.icon
10:50–11:20
PicoRubyのコンパクトな設計と組み込みのマルチタスク機能により、ブラウザ上で直接動作する完全なRubyベースのアプリケーション開発の可能性が広がります。この講演では、既存のソリューションに代わる軽量でRuby中心の新しいWebフロントエンドフレームワークであるFunicularの技術的な詳細について説明します。Full-Stack RubyがあなたのRubyライフをいかに楽しくするかを発見してください！
Ruby アプリケーションに対して変更のたびにテストスイート全体を実行する方法は、小規模な環境では有効ですが、最終的には処理速度が遅くなり、コストも高くなります。変更の影響を受けるテストのみを実行しようとする既存のツールの多くは、テストをスキップしすぎてテストの失敗を見逃したり、オーバーヘッドが大きすぎて CI 環境で使用できなかったりします。この問題を解決するために、オープンソースの Datadog テスト最適化 gem 用のテスト影響分析エンジンを構築しました。このツールは現在本番環境で稼働しており、エンジニアリングチームの CI 時間を年間 15 万時間以上節約しています。この講演では、その研究がどのようにしてRubyの内部構造を深く掘り下げる研究へと発展し、Rubyにおけるカバレッジの意味について驚くべき発見につながったのかをご紹介します。カバレッジとは、単にコードの行数だけを指すものではないことが分かったのです。この講演では、テストで実際にカバーされている内容を追跡する高性能ライブラリを構築するまでの道のりについてお話しし、その過程で学んだコツを共有します。
日付系ライブラリは元々Rubyで実装されていましたが、バージョン1.8.7から1.9シリーズへの移行時にパフォーマンス向上のためC言語で書き直されました。現在、日付系ライブラリには専任のメンテナーがおらず、Rubyコミッターにとって負担となっています。そこで、私は日付ライブラリを純粋なRuby実装に置き換えるという課題に取り組んでいます。
/icons/hr.icon
11:30–12:00
従来のLR構文解析では、レキサーはパーサーがトークンを見る前に、どのトークンを返すかを決定する必要があります。しかし、コンテキスト依存構文の場合、正しいトークン化はパーサーだけが知っているコンテキストに依存します。レキサーはそれを見ることができないため、Rubyのレキサーは手動での字句状態管理に頼り、手書きのコードでコンテキストを推測します。これにより、言語ルールが実装の詳細に分散し、バグの再現が困難になり、構文の変更が複雑になります。私がLramaで実装したPSLR(1): Pseudo-Scannerless Minimal LR(1)は、この関係を逆転させます。つまり、パーサーが各ポイントでどのトークンが有効かをレキサーに伝えます。この講演では、PSLR(1)がパーサーとレキサー間の情報ギャップをどのように埋めるかを示し、RubyのパーサーをLexer Hackの呪縛からどのように解放できるかを探ります。
hachi8833.iconPSLR(1) とは？
Ractor は真の並列処理を約束していましたが、「Stop-the-World」ガベージ コレクションが最後のボトルネックとなっていました。しかし、今では状況が変わりました。Ruby 4.x では、オブジェクト ヒープを分離し、分離型ガベージ コレクションを可能にする、メモリ管理における画期的な変化である Ractor-Local GC が導入されました。この講演では、MaNy プロジェクト (M:N スレッド) の技術的ブレークスルーと、それが Ruby のデバイス ワークロードで「ハイパー ジェネレーショナル」を実現する方法について探ります。Ractor ネイティブの AI エージェント フレームワークである ragents を使用して、メモリ管理と LLM コンテキスト管理の概念的なギャップを埋める方法を示します。ヒープ 圧縮とトークン ウィンドウ要約の相乗効果を視覚化し、Ruby 4.x が自律型エージェント群に対してほぼ線形スケーリングを実現する方法を示します。参加者は、Ruby 4.x の内部構造を深く理解し、高並行性 AI オーケストレーションの設計図を得ることができます。
hachi8833.icon Ractor-Local GCとは？
ライブラリが大きくなると、テストスイートの実行速度が遅くなります。これはプログラマーの不満につながります。マルチプロセスに基づく並列テストは、この問題を解決するための一般的な手法です。しかし、ほとんどのテストフレームワークとツールは、さまざまな環境をサポートするのに十分な「移植性」を備えていません。これは、Unix固有の機能forkや、drbなどのバンドルされたgemを含む外部ライブラリに依存しているためです。この問題を解決するため、test-unit（バンドルされたgemとして）は、マルチプロセスに基づいた移植性と高速性を備えた並列テスト実行をネイティブにサポートするようになりました。Windowsなどの様々な環境で、すぐに動作するように設計されています。この講演では、後方互換性を損なうことなく、既存のテストフレームワークに並列実行機能を実装するまでの道のりについて解説します。テストスイートの高速化、移植性の高い並列ライブラリの実装、あるいは既存のコードベースの維持管理に関心のある方にとって、この講演はきっと役立つでしょう。
/icons/hr.icon
13:30–14:00
この講演では、AI時代におけるRubyエコシステムのツールの可能性を探り、特にリンターとフォーマッターに焦点を当てます。従来、RuboCopは人間または他のプログラムによって起動されていました。AI時代に入り、AIエージェントが新たな起動手段として登場しました。本講演では、生成型AIをリンターやフォーマッターと組み合わせる実践的な方法について、例えば、Rubyで実装されたMCP（Model Context Protocol）サーバーを統合することで、これらのツールをAIエージェントと並行して実行するなどといった具体的な方法を解説します。AI分野は急速に進化し、技術も目まぐるしく変化していますが、本講演では、Rubyエコシステムの開発者に対し、RuboCopのような既存のRubyツールがMCPを通じてAI時代にどのように進化できるかを検討する機会を提供することを目的としています。
コードの実行速度が遅い場合、私たちはプロファイラに頼ります。プロファイラは、何が原因で遅いのかを教えてくれると期待できるからです。しかし、本当にそうでしょうか？プロファイラは必ずしも「真実を語る」とは限りません。その非決定的な性質には、サンプリングバイアス、最適化によって削除された隠れたメソッド、スレッド間の作業の誤割り当てといった落とし穴が伴います。既存のプロファイラは、Rubyの実行内部を観察するために、驚くほど多くのトリックに頼っています。RubyはRactors、M:Nスレッド、JITといった機能を備えて進化するにつれ、この外部アプローチの限界がますます明らかになってきている。ランタイムが複雑になればなるほど、VM外部のプロファイラによる分析は困難になる。今日のRubyプロファイラの機能と限界を探り、例えば「ext/profile」のようなプロファイラをCRubyに直接組み込むことで、外部プロファイリングの根本的な限界を打破できる方法を示しましょう。「真」とは何を指すのでしょうか？その答えは最後に明らかになります。
mrubyがCコンパイルなしでどこでも実行できたらどうでしょう？私は、純粋なC#で完全なmruby VM実装であるMRubyCSを構築しました。これにより、クロスプラットフォームアプリケーションへのmrubyの組み込みがはるかに簡単になります。クロスプラットフォーム配布では、ビルドターゲット、静的/動的リンク、多様なホストマシン（iOS、Web、Win、Mac、コンソールなど）の調整が常に面倒な作業となります。また、ゲームコンソール（PS、Switch、Xboxなど）のようなクローズドプラットフォームでは、SDKへのアクセスがないと非現実的な場合が多いのですが、今では簡単に動作します。Unityと.NETは既にプラットフォームの抽象化を処理してくれます。これはRubyコミュニティにも新たな可能性を開きます。ゲーム開発は長らくRubyの存在感が限られていた分野でした。Unityでmrubyが実行できるようになれば、Ruby開発者は世界で最も人気のあるゲームエンジンの1つにRuby言語を持ち込み、ゲームロジックのスクリプト作成、ツールの構築などに活用できます。VM実装の話に加えて、VitalRouter.MRubyとFiberベースのコルーチンを使った実践的なゲームスクリプトも紹介します。
/icons/hr.icon
14:10–14:40
Rubyのスレッドスケジューラはラウンドロビン方式を採用しており、シンプルで公平性に優れています。しかし、I/OとCPUが混在するワークロードの場合、I/OバウンドスレッドはCPUバウンドスレッドの処理完了を待たなければならないため、I/Oバウンドスレッドの応答性が低下します。多くのRubyアプリケーションはこのようなワークロードを抱えているため、優先度スケジューラを導入することでメリットが得られます。本講演では、優先度スケジューラの仕組みと、Rubyアプリケーションにもたらすメリットについて解説します。
hachi8833.icon Ruby VM強者
Zilog Z80は当時人気のあった8ビットプロセッサで、現在でも多くの用途で利用されています。パーソナルコンピュータや、セガマスターシステム、ゲームギアなどのゲーム機に広く採用されていました。しかし、現在Z80上で動作するRubyの実装は存在しません。私はmrubyzというmruby VMの実装に取り組んでいます。これは、いくつかの注意点と制限事項はあるものの、Z80プロセッサ上でmrubyバイトコードを実行することを目的としています。対応機能や命令セットの点で非常に制限があります。また、Z80はかなり古いプロセッサで、処理速度も遅く、多くの制約があります。しかし、いくつかの用途では使えるように改良しています。このプレゼンテーションでは、古い8ビットプロセッサ上でRuby（の一部）を実行するために必要なこと、そして開発を通して得られた知見についてご紹介します。
hachi8833.icon 何というおっさんホイホイ😂
通信速度を向上させるには、これまでボトルネックを一つずつ解消していく必要がありました。かつては帯域幅が最大のボトルネックでしたが、帯域幅が広くなるにつれて、今度はレイテンシが大きな制約として浮上しました。レイテンシを低減するための初期の取り組みとしては、HTTP/2の多重化、TLS 1.3、QUICのハンドシェイク時間の短縮などが挙げられます。QUICが標準化され、普及が進むにつれ、注目は次のボトルネック、つまり接続確立後に利用可能な帯域幅を検出して最大限に活用するまでの時間である起動フェーズに移りつつある。このセッションでは、Fastlyが現在評価中の新しいアプローチ「Rapid Start」を紹介します。従来の帯域幅プロービング手法であるSlow Startを概説し、起動が遅くなる理由、その前提条件、および限界について説明します。次に、Rapid Startが帯域幅推定の初期動作をどのように変更して起動時間を短縮するかを示し、その設計上のポイント、トレードオフ、およびRubyを使用して動作を分析する方法に焦点を当てます。
/icons/hr.icon
14:50–15:20
具体的な実装の詳細1といった些細なことはさておき、パーサーが直面し解決しなければならない根本的な問題2とは何でしょうか？1 + 2 * 3という入力を考えてみましょう。文法によって、この入力は1 + (2 * 3)のように構造化されるべきだとします。 パーサーが左から右に入力を読み込むと1 + 2 に到達し、次のトークンが*であることを認識します。この時点で、パーサーは前の部分を単一の単位にまとめるか、処理を続けるかを決定しなければなりません。この課題は、パーサーの実装方法とは無関係で、構文解析自体に内在する普遍的な問題です。このセッションでは、構文解析の分野におけるいくつかの問題点を取り上げ、さまざまな構文解析器の実装がどのようにそれらを解決しようとしているのかを探ります。
実のところ、「どうやって」という点こそが本当の難題なのだ…
ここでは、左から右へ入力を読み込む、一方向でバックトラッキングを行わないパーサーに限定して考察します 。
hachi8833.icon 金子さんといえばLALRパーサー
ライブコーディングセッションでRubyを入力しながら、音を段階的に生成し、音楽を形作っていくことができたらどうだろうか？私は、Strudel（https://strudel.cc にある、アルゴリズム音楽のためのブラウザベースのライブコーディング環境）に触発されたRuby実装であるstrudel-rbを開発しました。これにより、Ruby構文からリズミカルなパターンやメロディーを生成しながら、Rubyでライブコーディングを行うことができます。このプレゼンテーションでは、ミニ記法で定義された一連の音の解析方法、音の再生タイミングの計算方法、シュトゥルーデルスタイルの構文を適用する際にRubyが処理できない構文、そしてライブコーディング中に構文エラーが発生した場合に音が停止するのを防ぐためのテクニックについて説明します。 @asonas: Sneak peek for RubyKaigi 2026. My Day 1 talk explains the mechanics and principles behind this, and performances like the one in the video will happen a few times in Hakodate. More details soon! #rubykaigi https://pbs.twimg.com/amplify_video_thumb/2043664156134662144/img/-bnONO2Sx4eyPLWK.jpg
PicoRubyの登場により、mrubyを中心とした技術は、マイクロコントローラ向けの軽量な動作環境としてますます広く利用されるようになった。本講演では、より自己完結型のアプローチ、すなわちPicoRubyをベースとしたマイクロコントローラ向けオペレーティングシステムを紹介します。このシステムでは、mruby VMがシステムの中核として機能します。私はこのフレームワークを「Family mruby OS」と呼んでいます。このシステムにより、開発者はPCに頼ることなく、USBキーボード、マウス、ディスプレイを使用して、GUIを備えたマイクロコントローラ上でRubyアプリケーションを直接作成および実行できます。FreeRTOSを活用することで、複数のPicoRuby VMだけでなく、他の言語のVMもマシンコードレベルで同時に実行でき、真のマルチVM実行を実現しながら、アプリケーションのライフサイクル管理はRubyに任せることができます。本講演では、このフレームワークの設計と実装について説明し、関連する主要な技術的課題について議論し、実際のハードウェア上で動作するシステムを実演します。
/icons/hr.icon
16:00–16:30
ZJITチームは昨年、統合直前にZJITについて簡単に説明しました。今回は、何が変わったのか、最適化のアイデアはどこから来たのか、そして定数畳み込み、値番号付け、エスケープ解析、スカラー置換、レジスタ割り当てなど、今後の展望についてお話しします。また、動的言語コンパイラの研究の豊かな歴史と、それがRubyのような動的な言語にどのように応用できるかについても解説します。最後に、Ruby 4がRubyKaigi 2022で示されたパフォーマンスの期待に応えられるかどうかを見ていきます。
Ruby gem を試すのが、Web ページを開くのと同じくらい簡単だったらどうでしょう？ローカル環境の設定も、「バンドル インストール」も、バージョン管理の煩わしさも一切不要です。TutorialKit.rb は、WebAssembly 上の Ruby とブラウザ内開発ランタイムを組み合わせることで、ブラウザ上で直接、Ruby gem のインタラクティブなチュートリアルを実行できるようにします。この講演では、助成金によって実現したプロジェクトの進化について紹介します。TutorialKit.rbは2025年にRuby Association Grantを受賞し、その助成金による成果が、RubyKaigi 2026で私が発表する内容の中核となっています。まず最初に、フレームワークを使用したサンプルチュートリアルの構築方法を紹介します。RubyKaigiは技術カンファレンスなので、デモにとどまらず、エンジニアリングに焦点を当てます。具体的には、ブラウザ→Webコンテナ→Ruby WASMを接続するアーキテクチャ、Ruby⇄Webコンテナブリッジ、そしてブラウザ内でフル機能の開発ワークフローを可能にするビルド/配布パイプラインについて解説します。
CRubyのソースコードを読んでみたいと思ったことはありませんか？Rubyの仕組みを理解したいと思ったことはありませんか？私は「CRubyのぼうけんのしょ」という自費出版の本を書きました。この本では、著者と一緒にCRubyのソースコードを読み進め、まるで冒険に出かけるようにその内部構造を探求していきます。今回の講演では、この本のエッセンスと、執筆を通して私が得たソースコード解読のテクニックをご紹介します。
hachi8833.icon「CRubyのぼうけんのしょ」は登壇時にリリースするのかな？
@youchan: 「CRuby quest ～ Rubyのぼうけんのしょ ～」という同人誌を書きました /icons/hr.icon
16:40–17:10
BigDecimalのBigMathモジュールをご存知ですか？これは、任意の精度で数学関数を計算できるモジュールです。しかし、bigdecimal-3.1.9ではsin(1)はわずか10000桁の計算に数秒もかかってしまいます。これでは「Big」とは言えません。私たちは、より多くの桁数を必要としています。この講演では、BigMathの計算がどのように維持、改善されているか、そして桁計算を設計する上での楽しい部分についてご紹介します。
Bundlerは、20年近くにわたりRubyコミュニティの依存関係のインストールと管理を支えてきましたが、Pythonのuv発表に伴い、「Bundlerはもっと高速化できるのではないか？」という疑問が生じました。そこで、この機会に多数のパフォーマンス問題を調査し、修正したバージョンがBundler 4としてリリースされました。この講演では、Bundler が遅い理由、それに対する私たちの取り組み、そして Ruby コミュニティがどのように協力できるかについて詳しく説明します。私たちの目標は、Rubygems と Bundler を進化させ、Ruby 開発者がbundle install実行時に非常に高速なエクスペリエンスを得られるようにすることです。
現代のコンピューティングは複雑すぎて、若い学習者がプログラミングの感覚をつかむのは難しい。Rubyでプログラミングをする場合でも、初心者はまずOSの管理、エディタの設定、Rubyランタイムのインストールなどを学ぶ必要がある。こうした煩雑さが、プログラミングの本質にたどり着くことを困難にしている。この講演では、mrubyを使ってスタンドアロンのRubyコンピュータを構築する方法を実演します。この20ドルで手作りしたシングルボードコンピュータは、ホストPCなしで、ディスプレイ出力とキーボード入力を備えた完全なプログラミング環境を提供します。本講演では、リアルタイム640x480出力とテキスト/図形レンダリング機能を備えたグラフィックエンジンの実装、USBキーボード入力と外部R2P2デバイスとのシリアル通信に対応したRubyシェルについて詳しく解説します。各コンポーネントがmruby VM上でどのように動作するかを示すことで、このVMが小型マイクロコントローラ上で完全なコンピューティング環境をゼロから構築できるほど強力であることを実証します。
@harukasan: RubyKaigiの発表でつかうデバイス、Harucomについて書きました。 /icons/hr.icon
17:20–18:20
/icons/hr.icon
Day2
09:30–10:30
過去20年間、私はJRubyに心血を注ぎ、Rubyの世界に新たな可能性をもたらしてきました。私たちはRuby初のJITコンパイラを開発し、コミュニティが並列スレッドを受け入れるよう支援し、大規模に展開されている唯一のRuby代替言語となりました。
今日、JRubyはRubyの可能性をさらに広げ、以下のような独自の機能を提供しています。
商用製品向けコードのプリコンパイル
あらゆるデバイス（モバイル端末や組み込み機器を含む）上のあらゆるJDKで、単一ファイルによるデプロイメントが可能。
本番環境アプリケーションの低オーバーヘッドプロファイリング
シンプルでパワフルなマルチスレッド処理で、すべてのコアを活用します。
グラフィックス、GUI、ゲーム、AI向けのクロスプラットフォームライブラリ
JRuby 10.1では、毎日新しい素晴らしい機能と最適化を追加しています。これまでにないRubyを体験してください！
この講演では、JRubyの歴史を探り、Rubyを新たな領域へと発展させ、Rubyアプリケーションの全く新しい世界を切り開く方法をご紹介します。
hachi8833.iconJRubyは現在3.4.0コンパチ！
/icons/hr.icon
10:50–11:20
Rubyは長らくパフォーマンス向上のために仮想マシンに依存してきましたが、その複雑さが増すにつれ、「仮想マシンブルース」と呼ばれる現象が発生することがあります。本講演では、ASTベースの再利用可能な最適化フレームワークであるASTroを紹介し、この新しいアプローチを用いてRubyを再実装した実験についてお話しします。Ruby 1.9以前のRubyプログラムは、ASTを直接走査することで実行されていました。現代のRuby実装はバイトコードVMとJITコンパイラへと移行していますが、本講演ではASTro上にRubyの一部を再構築することで、最新の技術を用いたASTベースの実行について改めて考察します。ASTroを使用すると、RubyプログラムはASTレベルで最適化およびコンパイルされ、Cソースコードが生成され、効率的なネイティブコードが作成されます。これは製品化に向けた提案ではなく、研究段階の実験であり、講演では、何がうまくいき、何がうまくいかなかったのか、そしてこの試みから何が得られたのかに焦点を当てます。
hachi8833.icon 全然関係ないけどASTroについて調べてたらこんなの見つけた
https://www.youtube.com/watch?v=blnCiQZiHxU
近年、Rubyの型エコシステムは着実に成長を続けています。型チェックの恩恵を受ける実用アプリケーションも増えています。しかし、AIが生成するRubyコードの品質が向上するにつれ、私は「本当に型が必要なのだろうか？」と疑問に思うことが増えてきました。このセッションでは、型付けの利点のほとんどは、実際にはNoMethodError型エラーを防ぐことにあるという私の気づきを共有します。これに基づき、型注釈を必要とせずにこの利点を提供する、私が開発中のgemであるMethod-Rayを紹介します。その使用方法、開発の背景、現在のアーキテクチャ（Rustで実装）、そして既存の型チェッカーとの違いについて説明します。
Rubyは非常に多様なプラットフォームで動作しますが、その移植性の背景には、各環境における継続的かつ多くの場合目に見えないパッケージのメンテナンスがあります。本講演では、Rubyコアコミッターではなく、ダウンストリームパッケージメンテナーの視点から、Cygwin環境におけるRubyバイナリパッケージの保守に関するケーススタディを紹介します。アクティブな保守が行われていなかったためにアップストリームリリースから大きく遅れていたCygwin上のRubyパッケージがどのように復元され、最新の状態に維持されたか、そしてその過程で遭遇した技術的な課題に焦点を当てます。これらの課題には、プラットフォーム固有のビルドとテストの問題、パッケージングに関する決定、CygwinのPOSIX互換レイヤー、ツールチェーン、ライブラリの違いがRubyに与える影響などが含まれます。これらの問題の一部は、Rubyアップストリームへのフィードバックとパッチにつながりました。この経験を通して、主流ではないプラットフォーム上でRubyを動作させ続けるための実践的な教訓と、Rubyのマルチプラットフォーム対応を支える下流メンテナンスの役割についてお伝えします。
/icons/hr.icon
11:30–12:00
昨年開催されたRubyKaigi 2025で、Rubyのモジュラーガベージコレクタ機能が発表されました。この機能により、メモリ管理ツールキット（MMTk）フレームワークを使用した代替ガベージコレクタが実装されました。しかし当時、MMTkはRubyのデフォルトのガベージコレクタよりも大幅に低速でした。この1年間で、MMTkのRuby統合機能は大幅に改善され、パフォーマンスはデフォルトのガベージコレクタと同等になりました。Moving Immixのガベージコレクション戦略、並列処理の向上、および多数の最適化がサポートされています。この講演では、モジュラーガベージコレクター機能とそのデフォルトのガベージコレクターとの違いについて説明し、Ruby MMTkの統合を高速化するために使用される技術を検証し、将来的にどのようにさらに改善できるかについて議論します。
Rubyは、Cloudflare Workers、Fastly Compute、Spinといったエッジコンピューティング環境に実際に導入できるのでしょうか？この講演では、「mruby/edge」と、それを基盤としてRubyのパワーをエッジ環境にもたらすためのフレームワーク「Uzumibi」を紹介します。mruby/edgeは、純粋なRustでゼロから構築されたmruby互換の仮想マシンです。移植性の高いWasmバイナリを生成し、400KiB未満の最小限のビルドを可能にします。RubyKaigi 2024以降、mruby/edgeは大きく進化しました。現在では、基本的なオブジェクト指向プログラミング機能、例外処理、クロージャ、制御構造、キーワード引数、および機能フラグをサポートしています。Uzumibiは、mruby/edgeを活用した軽量なWebフレームワークです。Uzumibiは、複数のエッジプラットフォームで同じRubyコードを実行でき、シンプルなWeb APIを提供します。mruby/edgeとUzumibiは、従来Rubyの利用が困難だったエッジコンピューティング分野において、Rubyの新たな可能性を切り開いています。本稿では、私がWasmとエッジコンピューティング向けにVMをゼロから構築した理由、直面した課題と解決策、そして今後のロードマップについて解説します。
現在のDJシーンは、MIDIを介してPCと通信するPCDJコントローラーが主流となっている。これにより、機材やレコードを持ち運ぶ必要がなくなり、手軽にDJを始めることができる。しかし、簡単に始めた人の多くは、すぐに興味を失ったり、自分の才能の限界に気づいたりする。私もまさにその一人だ。DJコントローラーは、ジョグホイール、ボリュームコントロール、ボタンなど、複数のスイッチを備えており、わずか数万円で購入できます。必要な部品を集めて同様のデバイスを自作するのは困難です。本プレゼンテーションでは、DJコントローラーをヒューマンインターフェースデバイス（HID）として効果的に活用する事例を紹介します。DJコントローラーとの通信から、デスクトップアプリケーションやエディタの制御、プログラミングサポートまで、各分野をRubyで実装するためのノウハウを共有したいと思います。
hachi8833.icon 物理のDJコントローラってどんなんだろう？こんなの？
https://scrapbox.io/files/69e0abc93caed06dfeede711.png
/icons/hr.icon
13:30–14:00
Rubyは拡張性の高さで有名です。オープンクラス、included、inherited、TracePointなど、様々な機能が備わっています。しかし、ソースコードの読み込み（つまりrequire）プロセスをインターセプトするとなると、標準的なメカニズムが存在しないのが現状です。トランスパイラ、ロードフローアナライザ、ランタイム型チェッカーなど、これらすべては、require呼び出しをハイジャックするための標準APIがあれば恩恵を受けるでしょう。もしそのようなAPIがあったらどうでしょうか？実は、すでに存在しているのです。
Rubyのrequire（およびload）呼び出しをインターセプトするためのユニバーサルインターフェースを提供する require-hooks gem を紹介しましょう。これにより、ソース変換などを実行できます
2025年のブラックフライデー、ShopifyのストアフロントはFalcon上で数十億件のリクエストを処理しました。ピーク時には毎分2300万件の処理能力を発揮し、リクエストの損失はゼロでした。その1年前、私たちは3種類の異なるWebサーバーを運用しており、15年前から使用しているRailsコードベースのどの部分がスレッドセーフなのか全く把握していませんでした。この講演では、大規模なRailsアプリケーションを本番環境で非同期Rubyに移行する際の3つの視点をまとめて紹介します。
Samuel Williamsは、生産の信頼性について、作業者の健康状態の監視、積極的なメモリ管理、イベントループをブロックするコードを検出するためのファイバープロファイリングなどについて論じています。
Marc-André Cournoyer氏は、「長時間タスク」について詳しく解説しています。これは、CPU負荷の高いRailsアプリケーションがパフォーマンスを低下させることなく同時I/Oを処理できるようにするアプローチです。GraphQLは、@deferワーカーを30秒以上ブロックしていた状態から、ほぼフリーになりました。
Josh Teeterは、インフラ面での成果として、Outboxシステム（数百のKafka接続をポッドごとに1つに集約）、BFCM規模でのみ顕在化した問題のデバッグ、そしてダウンタイムゼロでのロールアウトの実現などを挙げている。
hachi8833.icon 23 million RPMのリクエストを取りこぼしなしですって
Ruby/WASM は、Rubyist がブラウザ上で直接柔軟なアプリケーションを構築できるようにします。私は、Ruby/WASM と Web Audio API を組み合わせたブラウザベースのシンセサイザーおよびシーケンサー「purified-synth」を開発しました。このプロジェクトの核心的な特徴は、標準的な 12 音平均律ではなく「純粋なイントネーション」に焦点を当てていることです。マイクロトーン音楽は 53-TET のような近似値に依存することが多いですが、このシーケンサーは Ruby を使用して正確な周波数比を計算し、最も純粋な数学的形式でコードを実現します。このセッションでは、この音楽理論を Ruby で実装する方法を実演し、Ruby/WASM を使用して機能的なアプリケーションを構築するための実践的なテクニックを紹介します。JavaScript の相互運用性 (JS interop) のニュアンスと、Ruby と Web API の間のギャップを埋めるために必要なアーキテクチャパターンについて議論し、Ruby/WASM で「Hello World」の例を超えて進みたいと考えている人に役立つ洞察を提供します。
ということで改めて、RubyKaigi 2026 で LΛMPLIGHTさんのシャサフ式音楽理論にインスパイアされて作った純正律シーケンサーの話をします。セッション中にデモできなさそうなのでANDPADブースなどで捕まえてもらえたらデモします。
/icons/hr.icon
14:10–14:40
私たちは皆、Rubyでのプログラミングが大好きですが、時にはネイティブコードを呼び出す必要が生じます。残念ながら、C拡張機能は通常、FFIを使用するよりもパフォーマンスが優れています。このプレゼンテーションでは、C拡張機能を使用した場合と同等、あるいはそれ以上のパフォーマンスを実現するFFI実装の方法をご紹介します。FFIが遅くなる原因と、そのパフォーマンスを改善する方法について見ていきましょう。FFIを高速化して、C拡張機能の使用をやめましょう！
前回のRubyKaigiでは、RBSパーサーの大幅な改良が発表され、移植性が向上したことで、Sorbetなどの他のツールでも再利用できるようになりました。新しいパーサーがメインブランチにマージされた後、RBS 3.9パーサーと比較してパフォーマンスが約10%低下するという問題が報告されました。しかし、これは最悪のケースではなかった。すぐに、小さなファイルの場合、新しいパーサーは以前の実装よりも最大で5倍遅くなる可能性があることに気づいた。この講演では、実装のプロファイリング、文書化されていない前提条件の明確化、C言語によるパーサー実装の改善を通して、RBSパーサーを高速化するまでの短い道のりを順を追って説明します。
PicoRubyは、メモリと実行速度の制約が厳しく、実用的なネットワーク構築が難しいマイクロコントローラの世界にRubyをもたらすことを目指しています。本講演では、picoruby-netをベースに構築されたmruby/cを用いた、PicoRuby上で動作する実用的なMQTTクライアントの実装例を紹介します。CRubyとは異なり、mruby/cはスレッド機能がなく、メモリも非常に制限されています。このような環境でMQTTを実装するには、ポーリングに基づく進捗状況、バッファ管理、接続ライフサイクル処理、そしてRubyとネイティブコードの境界を慎重に設計する必要があり、同時にRubyらしいプログラミングモデルを維持する必要がありました。このセッションでは、極めて厳しい制約の下で、複雑なネットワークプロトコルをRubyで実装するために実際に何が必要なのかを探ります。Rubyをベアメタル環境にどれだけ現実的に近づけることができるのか、そしてどこで適応する必要があるのかを示します。
/icons/hr.icon
14:50–15:20
歴史的に、Ruby の Set クラスは標準ライブラリに含まれていました。Ruby 3.2 以降、Set 標準ライブラリはデフォルトで自動ロードされるようになりました。Ruby 4.0 では、Set はコアクラスの 1 つとして実装されています。このプレゼンテーションでは、Set の歴史、コアクラスとして実装された理由と方法、興味深い実装上の問題、そして一部の埋め込み RTypedData オブジェクト (および RTypedData オブジェクトとは何か) のメモリ使用量の削減につながった経緯について説明します。
@jeremyevans0: 私の #rubykaigi プレゼンテーションは、ちょうど1週間後にあります！ @PacktPublishing が「Polished Ruby Programming」のプロモーション用に6冊送ってきてくれて、@rubykaigiで配布することにしましたことを嬉しく思います。1日2冊ずつプレゼントするので、1冊欲しい方はカンファレンスで私を探してください。 optcarrotはRubyのパフォーマンス実験における事実上のベンチマークとなっていますが、レンダリングワークロードは比較的単純です。そこで、異なるパフォーマンスプロファイルを検証するために、1993年のゲーム「Doom」の中核部分をRubyに移植しました。これには、Chocolate Doomから直接移植したBSPベースのレンダラーも含まれています。世間の評判とは裏腹に、Doomはレイキャスターではなく、2Dマップ上で動作する制約のある3Dエンジンであり、動的なライティング、スプライト、階段、可変の床高などを備えている。そのため、Rubyにとっては驚くほどリッチなリアルタイムCPU負荷の高いワークロードとなる。本講演では、大規模なC言語コードベースをRubyに移植するための戦略、元のエンジンとのフレームごとの比較による正当性の検証、およびパフォーマンスの測定について説明します。また、YJITなどの最新のRuby機能がリアルタイムレンダラーにどのような影響を与えるかについても示します。このエンジンは320×240ではプレイ可能なフレームレートに達しますが、より高い解像度ではすぐにボトルネックが露呈します。
デモが含まれています（gem install doom && doom）。
https://www.youtube.com/watch?v=4Q46klPn1-U
2022年にruby.wasmが登場し、ブラウザ上でのRubyの分野で大きな進歩を遂げました。例えば、ファイルからのRubyスクリプトの読み込み、JavaScriptネイティブ型の自動変換、Promise操作などが挙げられます。一方で、JavaScriptからRubyスクリプトを実行する機能に関しては、進展が見られません。現状では、最小限のeval機能しか利用できません。ファイルからのスクリプト読み込み、ネイティブ型の自動変換、メソッド呼び出しなど、ブラウザ上でのRubyと同等の機能を実装することで、Rubyのユースケースを拡大できます。例えば、ブラウザやNode.jsサーバー上で動作するJavaScriptからRubyライブラリを実行できるようになる可能性があります。
/icons/hr.icon
16:00–16:30
ラクターはRuby 3.0の頃から「実験的」な機能として扱われてきた。それから4年経った今でも、ほとんどの開発者はラクターの実用的な使い道を見つけられていない。はい、そうしました。メッセージの逆シリアル化をRactorプールに移行することで、Karafkaは特定のワークロードにおいて最大70%のスループット向上を実現しました。しかも、ユーザーはコードを一行も変更する必要はありません。この講演では、アーキテクチャ、実際に効果を発揮するパターン、そしてRactorを本番環境で活用するために私が学んだことについて解説します。
きっかけはpybind11への憧れでした。2020年、私はpybind11を使って、自社のC++パターン発見エンジン用のPython拡張機能を作成しました。わずか数日で完成し、データサイエンティストたちが癌研究において画期的な発見をすることができました。IRBのようなREPLでコンパイル済みのコードが動き出す瞬間には、何とも言えない魔法のような魅力があります。私はRubyでそのような体験をしたかったのですが、必要なツールが揃っていませんでした。そこで、最新のRuby↔C++ツールチェーンを構築するための5年間の旅が始まりました。その結果、現在ではPyTorch、faiss、OpenCVなどのライブラリのRubyバインディングを支えています。この講演では、ツールチェーンについて解説します。
ffi-clang: libclangを使用してC++ヘッダーを解析する
ruby-bindgen: clang ASTからバインディングを生成する
ライス：RubyとC++の相互運用性
CMake: クロスプラットフォームネイティブビルド
所有権、ガベージコレクション、テンプレート、メソッドオーバーロードといった課題を取り上げます。参加者は、小規模なユーティリティから大規模で複雑なライブラリまで、Rubyと最新のC++を連携させる方法を習得できます。
プログラムの動作を理解するのは難しい。実行されているメソッドの内部で何が起こっているのかを理解する必要があるが、Rubyでは、ソースコードを読むだけでは実際にどのメソッドが呼び出されているのかが分かりにくい場合が多い。さらに、CRubyはGVL駆動のスレッドスケジューリングやガベージコレクションなど、プログラムには表示されないランタイム処理を実行する。CRubyには、TracePointをはじめとするオブザーバビリティAPIが用意されています。今回の講演では、CRubyのリアルタイムオブザーバビリティを実現するための試みであるrrtraceを紹介します。rrtraceは、CRubyのC拡張機能で計測イベントをキャプチャし、専用の外部プロセスにストリーミングし、スレッド/スタックの状態を再構築し、実行をほぼリアルタイムで3D空間（時間×スレッド×コールスタック）として可視化するシステムです。このビューを使えば、GVLスレッドの切り替えやGCの実行を、まさにその場で確認できます。また、観測対象のRubyプロセスへの影響を最小限に抑えつつ、これを実現するために必要なエンジニアリングについても説明します。
/icons/hr.icon
16:40–17:10
TypeProfは、最小限の型注釈でRubyコードを分析するように設計された静的型アナライザーです。TypeProfは着実に進化を遂げてきましたが、その検証は主に自己ホスティング、つまりTypeProf自身で自身のソースコードを分析することに限られていました。ツール自身のコードベースにとどまらず、より広範なエコシステムにおけるその有用性を証明するため、「実世界」のアプリケーションで実験を行った。具体的には、私が開発した純粋なRubyで書かれた8ビットマシンシミュレータであるOptcarrotを使用した。Optcarrotは、これまでRubyインタープリタ開発のベンチマークとして活用されてきました。その最適化された複雑なロジックは、静的解析にとって理想的かつ挑戦的な対象です。本稿では、この実験中に発生した具体的な問題点と、それらを解決するためにTypeProfに加えられた改善点について報告します。最後に、今回の経験から得られた実践的な教訓とワークフローをご紹介します。参加者の皆様は、TypeProfの現在の機能と、それを自身のプロジェクトでどのように活用できるかについて、現実的な理解を深めることができるでしょう。
Rubyの動的な性質は開発者にとって素晴らしい体験をもたらす一方で、コンパイル時に課題を生み出します。より多くの情報を提供することで、コンパイラはより優れたコードを生成できるようになります。この講演では、ZJITにおいてステートメントを最適化、並べ替え、削除する方法をご紹介します。また、新しい副作用分析システムについて説明し、この設計によるコード生成の改善点、そしてこの副作用分析システムが将来的にもたらす可能性のあるパフォーマンス向上についても議論します。
形式手法は日常的なソフトウェア開発では一般的ではないかもしれませんが、仕様における曖昧さや矛盾を検出するための実績のあるツールです。形式仕様から特性を特定し、特性に基づいたテストを自動的に生成できたらどうでしょうか？これは品質保証の観点から非常に有益でしょう。私はこのアイデアを検証するために、形式仕様を解析し、プロパティパターンを検出し、実行可能なプロパティベースのテストコードを生成するRubyツールを開発しています。この講演では、形式手法とRubyのテストを結びつけるという概念を説明し、課題について議論し、そこから得られた知見を共有します。
hachi8833.icon 形式的手法をテストに応用ってどんな感じなんだろう
/icons/hr.icon
17:20–17:50
Rubyのドキュメントが、ここ数年で最大規模のアップデートを迎えます。RDocのメンテナーとして、私はこの1年間、Rubyドキュメントの読み方を現代化することに尽力してきました。しかし、読みやすさの向上は、ほんの始まりに過ぎません。今年は、主に3つの開発に注力しています。RDocマークアップからGitHub Flavored Markdownへの移行、RBS型シグネチャのドキュメントへの直接統合、そしてLLM対応の出力フォーマットとエージェントツールを用いて、AI時代に向けたRubyドキュメントの準備です。この講演では、Rubyドキュメントのこれまでの歩み、今後の展望、そしてRDocの進化に向けた具体的なロードマップについて解説します。Rubyドキュメントの作成と利用は、これから大きく改善されるでしょう。
私たちは皆、Rubyの柔軟性が大好きですが、JITコンパイラにとってはまさに悪夢です。再定義Integer#+や使用evalによってBinding混乱が生じます。高速化のために、JITコンパイラは不変条件と呼ばれる「楽観的な賭け」を行い、冗長なチェックをスキップするために物事が変更されないと仮定します。しかし、これらの賭けが失敗した場合、偉大なMotherインタープリタへの緊急脱出手段、つまり最適化解除が必要になります。今回は、私がMonoruby（Rustでゼロから書かれたRubyの実装）を構築した過程と、それを高速かつ正確に維持する方法をご紹介します。具体的には、以下の点について探っていきます。
JIT生成コードがインタプリタよりも高速な理由。
Rubyの動的な性質を扱うために使用される特定の不変条件。
MonoRubyにおける実装の詳細。
JITの内部構造というブラックボックスを詳しく見ていきましょう！
PicoRubyには現在、PRKファームウェアとR2P2という2つの主要な実装があります。PRKファームウェアはキーボードファームウェアとして機能し、R2P2は汎用電子プラットフォームとして使用できます。これら2つを統合することは可能でしょうか？言い換えれば、R2P2が汎用電子プラットフォームであるならば、R2P2を使ってキーボードファームウェアを作成することはできないのでしょうか？実際には、この統合を実現するにはいくつかの課題があります。このセッションでは、私がこの統合に向けて行ってきた取り組みについて説明します。
/icons/hr.icon
Day3
09:20–10:30
/icons/hr.icon
10:50–11:20
TCPSocket.newとSocket.tcpは、TCP を介してリモート ホストに接続されたソケットを返すメソッドで、Ruby 4.0 以降、open_timeoutと呼ばれる新しいタイムアウト機能が導入されました。Ruby 3.4 より前でも、これらのメソッドは以下の2種類のタイムアウト機能を提供していました。
resolv_timeout、ホスト名解決のタイムアウトを設定する
connect_timeout接続確立のタイムアウトを設定する
では、なぜ今、3 つ目のタイムアウトが必要になったのでしょうか? その答えは、これらのメソッドのあまり知られていないストーリーにあります。この講演では、これらのメソッドがタイムアウト機能を持つようになった経緯、Ruby 3.4 で導入された HEv2 アルゴリズムの影響、実際に長い間存在していたバグ、そして将来に向けてこれらのメソッドを包括的に改善する新機能について、具体的な実装の詳細とともに説明したいと思います。
AIエージェント（LLM）は、プログラミングの面倒な部分を自動化するのに非常に優れています。また、ループ処理にも非常に長けています。つまり、何かを試して、それがうまくいったかどうかを確認し、学習して、また試すというサイクルを繰り返すのです。この記事では、LLMエージェントを活用して「自動調査」を行い、Ruby自体のパフォーマンス問題を解決する方法について解説します。本稿では、LLM、シンプルなスクリプト、スキル、MCPを組み合わせて、再現可能なベンチマークを作成する方法を紹介します。これらのツールを組み合わせることで、「エージェントネイティブ」なRubyパフォーマンス向上ワークベンチを構築できます。また、これらのツールの限界、特にどのような問題解決に不向きなのかについても探究し、議論します。
mruby/cは、組み込みシステムやリソースが限られた環境での使用に最適化された軽量なRuby実装です。mruby/cはネイティブマルチコアをサポートしており、最新のプロセッサの機能を活用できます。本プレゼンテーションでは、mruby/cがネイティブのマルチコア機能を通じてどのように並行処理を可能にするか、特に複数のスレッドを効率的に管理するように設計されたmruby/c VM内でどのように並行処理を可能にするかに焦点を当てます。本プレゼンテーションでは、以下のトピックを取り上げます。
マルチコアサポートにおける課題
ミューテックス
コア間のタスク切り替え
パフォーマンス評価
/icons/hr.icon
11:30–12:00
書き込みバリアの欠落や誤りは、C拡張機能とCRuby本体の両方において、バグの一般的な原因となっています。これらは、特定のGCタイミング下でのみ発生するメモリ破損を引き起こす可能性があり、再現が困難で、修正の確実性も低いという問題があります。この講演では、書き込みバリアの正当性を動的に解析するための新しいガベージコレクタを紹介します。その動作原理、使用方法、修正されたバグ、そして書き込みバリアが必要となる厳密なルールについて説明します。
hachi8833.icon 新しいガベージコレクタとは
今回は、RubyのTracePoint APIの型破りな使い方について掘り下げてみましょう。パフォーマンスプロファイリングのためではなく、メタプログラミングを多用したRubyコードの実行時内省のためです。本稿では、既存のDSLで使用するためのDSLを作成するという、実際のユースケースに焦点を当て、TracePointがメタプログラミング技術の複雑な結果を整理し、DSLで生成されたメソッドへのロジックの動的リンクなどの処理をどのように可能にするかを探ります。高度なRubyテクニック、実践的な洞察、そしてあまり知られていないRuby APIに関する斬新な視点が融合した内容が期待できま
Apache Arrowは、現代のデータ処理システムにおける事実上の標準データフォーマットです。公式のRed Arrow gemを使用すれば、Apache Arrowデータを処理できます。高速で大規模なデータ処理に適していますが、低コストのデータ交換のみを目的とする場合はオーバースペックです。Red Arrowはバインディングとして実装されているため、純粋なRuby gemよりもサイズが大きく、インストールもやや複雑です。私は、低コストのデータ交換ニーズのみに対応するため、公式の純粋なRuby製Apache Arrowリーダー/ライターを実装しています。今後、より多くのRubyライブラリやアプリケーションが、この純粋なRuby製Apache Arrowリーダー/ライターによるApache Arrowの入出力サポートを追加することを期待しています。これにより、Rubyをデータ処理にさらに活用できるようになるでしょう。この講演では、高速な純粋なRubyバイナリデータリーダー/ライターの実装方法と、Rubyにおけるデータ処理の未来について説明します。 /icons/hr.icon
13:30–14:00
YJITやZJITといったJIT実装の台頭により、RubyのプリミティブをRubyで書き直すことが、現実的な最適化手法となってきました。これにより、JITと連携し、Rubyの機能（タイムアウトなど）と自然に統合できる、純粋なRuby製の正規表現エンジンの実現という夢が生まれました。しかし、この夢を実用化可能な現実にするには、大きな壁が立ちはだかります。それは互換性です。Onigmoを置き換えるには、その動作を完全に再現する必要がありますが、これは非常に困難です。私の経験から言うと、互換性のある再実装における最大の障壁は、構文解析と文字クラスのセマンティクスです。私は、Onigmoのパーサーと文字クラスロジックをRuby APIとして公開するという、実用的な解決策を提案します。これにより、エンジンの民主化が図られ、互換性の複雑さはC言語に委ねられる一方で、マッチングロジックのRubyでの書き直しに集中できるようになります。概念実証（PoC）を実演し、ハッキング可能でJITコンパイルに対応した正規表現エンジンの将来について議論します。
hachi8833.icon Onigmoのパーサーと文字クラスロジックをRuby APIとして公開する
Ruby VMはRuby 2からRuby 4にかけて大きく進化しました。この進化はRubyのC APIにも反映されていますが、後方互換性の確保にも細心の注意が払われています。古いgemはRuby 4でもほとんど変更なく動作するため、依存関係の更新がないためにアプリケーションが古いバージョンのままになってしまうといった事態は避けられます。しかし、C言語の拡張機能は「古いやり方」に固執すべきではありません。更新されないままでは、GC圧縮などの最新のVM機能の妨げになったり、ガベージコレクタに不要な余分な作業を強いたりするだけでなく、パフォーマンスや正確性の向上も逃してしまう可能性があります。この講演では、Ruby 4時代のVM向けにdatadog gemを最新化するための現在進行中の取り組みについて紹介し、主要な最新のRuby C API、それらが組み込んでいるVMの前提条件、そしてネイティブgemがそれらをいつ、なぜ採用すべきかを明らかにします。
Smalruby 3（ https://smalruby.app ）は、ScratchブロックとRubyコード間のギャップをシームレスに埋めるビジュアルプログラミング環境です。ScratchはK-12教育における事実上の標準となっていますが、テキストベースの言語への移行は依然として大きな障壁となっています。Smalruby 3は、ブロックとRuby間のリアルタイムかつ双方向の変換を提供することで、この問題を解決します。この講演では、Smalruby 3 の技術的な課題と実装の詳細について探っていきます。Scratch のイベント駆動型アクターモデルを Ruby のオブジェクト指向構文にどのようにマッピングするのでしょうか？ブロックがmove(10)メソッド呼び出しになるように AST をどのように操作するのでしょうか？また、逆に、任意の Ruby コードをどのようにビジュアルブロックに解析し直すのでしょうか？このセッションでは、puts "Hello"がコンソール出力ではなくスプライトの吹き出しとしてどのように視覚化されるか、そしてclassとdefの定義がアクターのプロパティと振る舞いにどのように直感的にマッピングされるかを実演します。このセッションでは、次世代のRubyistを育成するために、Rubyのセマンティクスをどのように「視覚化」できるかを明らかにします。 /icons/hr.icon
14:10–14:40
Rubyの配信プロセスは、単にコードを出荷するだけにとどまりません。それはサプライチェーン攻撃に対する防御策でもあります。私たちのエコシステムを守る強固な要塞を築くためには、最も重大なセキュリティ上の脆弱性である「人的要素」を排除する必要がありました。手作業によるチェックリストや不透明な手順の時代は終わりました。今日では、コードがコードを検証する、安全で自動化されたパイプラインがそれらに取って代わっています。つまり、RubyはRubyを解放しているのです。このセッションでは、Ruby Core リリース マネージャーの視点から、この進化の舞台裏をご紹介します。release-gem と Sigstore のビルドアテステーション（attestations）が、改ざん防止の保証チェーンをどのように構築するかを詳しく解説します。このセッションのハイライトは、「セルフ ホスティング」の課題、つまり依存関係ツリーのルートである Ruby と RubyGems を自律的にリリースすることです。sigstore-ruby を使用して RubyGems 自体のリリースを暗号的に検証する、再帰的なエンジニアリング アプローチを実演します。ぜひご参加いただき、皆様が頼りにしているツールの安全性をどのように確保しているかをご覧ください。
RubyのERBテンプレートは従来、テンプレートを文字列生成器として扱うエンジンによってレンダリングされるため、HTML構造、状態変化、増分更新などを理解するのが困難でした。こうした制約は、現代のHTML over the wireワークフローにおいて特に顕著になります。この講演では、リアクティブなERBレンダリングエンジンを構築するために必要な要素を探ります。まず、既存のERBエンジンがテンプレートをRubyコードにコンパイルする仕組みを再確認し、HTML対応の解析とツールにおける最近の進歩が、新たなアプローチをどのように可能にしているかを見ていきます。Herb::Engineを具体的な例として、構造理解によって、状態認識レンダリング、差分ベースの更新、そしてページ全体の再読み込みなしでの即時更新や豊富なブラウザ内開発者ツールなど、より応答性の高い開発環境がどのように実現されるかを検証します。テンプレートのアウトライン、部分構造ビューやERB構造ビュー、ソースコードへのジャンプナビゲーションなど、その他多くの革新的な機能が含まれます。
RubyKaigi を初めてご覧にならない方は、Ruby が多くのゲーム機に移植されていることをご存知かもしれません。では、NES への移植はどうでしょうか？このセッションでは、mruby/c に触発されて私が開発した、NES 上で動作する小型 Ruby インタープリタである nesruby の作り方について説明します。mruby のバイトコード形式を再利用する方法、cc65 を使用した C 言語での VM 実装、Symbol クラスの実装など、興味深い内部構造について解説します。注: この講演は Ruby インタープリタ側に焦点を当てています。NES 固有のトピック (グラフィック ハードウェアの癖、PPU など) は対象外ですので、NES に関する事前の知識は必要ありません。
/icons/hr.icon
14:50–15:20
ハッシュ関数を並列読み書きに対応させ、スレッドセーフ性を確保しつつ、シングルスレッドでも従来通りの高速性を維持できるようにすることは可能でしょうか？答えはイエスです！並列読み書きを可能にする全く新しいロックを含む、最先端の広範な研究により、これらの目標すべてを達成する方法を見つけました。ハッシュ関数を再実装し、1つのスレッドでも複数のスレッドでも、高速かつ安全に動作するようにする旅に出かけましょう。GVLよりもずっと安全です！
hachi8833.icon ハッシュをスレッド安全にパラレル化する...だと？
Ruby向けのスマートでコード認識機能を備えた開発ツールを構築することは、もっと容易になるはずだ。現在、言語サーバー、ドキュメント生成ツール、型チェッカーといったツールは、それぞれ独自のメカニズムでRubyコードを理解している。Rubydexは、Rubyエコシステム全体にわたる静的解析を簡素化する統合コードインデクサーです。Rubydexは、定数解決、継承の線形化、参照追跡といったコードに関する洞察に、高速かつメモリ効率の良いアクセスを提供します。また、ネイティブバインディングを介して、Rubyツールと非Rubyツールの両方からアクセス可能です。RubyLSP、Tapioca、SpoomにRubydexを統合した結果、最大10倍の速度向上と2倍のメモリ使用量削減が実現しました。この講演では、Rubydexのアーキテクチャ、実装、最適化について詳しく解説し、次世代のRuby開発ツールを作成するためにRubydexをどのように活用できるかをご紹介します。
PicoRubyは、Espressif Systems社が開発した、ESP32などのマイクロコントローラ上でも動作する非常に軽量なRubyの実装です。RubyKaigi 2025では、PicoRubyをESP32に移植することについて講演しました。今回の講演は、前回のセッションの続編です。ESP32上でPicoRubyをインターネット経由でクラウドに接続できるようにする手順について説明します。ESP32はWi-FiとTCP/IPネットワークをサポートしており、IoTアプリケーションに最適です。ESP32上で動作するPicoRuby向けに、WiFi、Socket、MQTTクライアントなどのクラスを実装し、改良しました。この作業には、TLSを使用したセキュアな通信と、X.509クライアント証明書を使用したデバイス認証も含まれています。これらの実装は移植性が高く、POSIX環境や他のマイクロコントローラにも適用可能です。その結果、PicoRubyはパブリッシュ/サブスクライブモデルを使用してAWS IoT Coreなどのクラウドサービスと通信できるようになり、実際のIoTシステムへの導入準備が整った。
/icons/hr.icon
16:00–16:30
Rubyの処理速度低下の大きな原因の一つは、メソッド呼び出しに伴うオーバーヘッドです。最近のRubyバージョンでは、YJITによって様々なメソッド呼び出しタイプに合わせてマシンコードが最適化され、メソッド呼び出しのパフォーマンスが向上していますが、依然として大きなボトルネックが残っています。それは、Rubyメソッドフレームをプッシュするプロセスです。この講演では、メソッドフレーム内でRubyが処理する必要のある様々な要素を探り、ZJITの軽量フレームとメソッドインライン化によってこの処理をほぼゼロコストで実現するアプローチをご紹介します。さらに、Ruby 4.1でYJITからZJITに移行する説得力のある理由について議論し、期待できるパフォーマンス上のメリットを強調します。
hachi8833.icon どのコミットだろう
Rubyは、そのダイナミックで表現力豊かで生産性の高い言語として知られていますが、真のホットスポットに遭遇すると、パフォーマンスチューニングが難しくなることがあります。プロファイリングの結果、アンチパターンコードではなく、Ruby本来の美しいコードが問題視されるようになった場合、どのような選択肢があるでしょうか？この講演では、従来とは異なるものの強力なアプローチ、すなわち、通常のRubyアプリケーションのクリティカルパスを最適化するためにRubyバイトコードを記述（または生成）する方法について探究します。Rubyコードがどのようにバイトコードにコンパイルされるのか、そのバイトコードが実際にどのような構造になっているのか、そしてそれを制御することで、ソースコードレベルでは除去が困難または不可能なオーバーヘッドをどのように排除できるのかを見ていきます。具体的な例を通して、頻繁に実行されるRubyメソッドをバイトコードで生成された同等のメソッドに置き換える方法を示し、それに伴うトレードオフとリスクについて議論し、この手法を検討する価値があるのはどのような場合かを説明します。目標はRubyを置き換えることではなく、パフォーマンスが本当に重要な場合に、Rubyを深く理解し、安全に活用できるようにすることです。
型注釈を書かずに型情報を取得できたらどうでしょう？type-guessrは、ダックタイピングのヒューリスティックを採用したRubyのLSPアドオンです。「これらのメソッドに応答するなら問題ない」という考え方ではなく、「これらのメソッドが呼び出されたのなら、それはこのクラスに違いない」という推論を行います。例えば、変数に対してingredientsとstepsが呼び出され、両方のメソッドを持つクラスがRecipeのみである場合、型は Recipe と推論されます。
この講演では、実際の運用方法、アルゴリズムの設計、そしてこの手法の限界についてお話しします。
hachi8833.icon 福岡.rbで話されてたらしい
/icons/hr.icon
16:40–17:40
/icons/hr.icon
その他気になる記事