Although it’s not yet practical, I’ve succeeded in getting Ruby::Box to run on Rails. In this presentation, I’ll introduce an example of using Ruby::Box to define the boundaries of a modular monolith, along with the hacks required to run it on Rails, accompanied by a demo. Through this presentation, I want to share with everyone the potential and appeal of Ruby::Box.

cover_rage is a Ruby code coverage tool designed to be simple and easy to use. It can be used not only for test coverage but also in production services to identify unused or stale code.

Key features:

1. Runs in continuous processes (e.g., Rails servers)
2. Zero dependencies
3. Supports forking and daemonization without additional setup
4. Supports Redis, SQLite and PStore as persistant storage.

We developed the tool cover_rage to solve a pain point at PicCollage server: there wasn't an efficient way to identify unused or stale code for a 15-year-old web application that has experienced multiple refactorings.

The existing libraries are too complex because they don't make use of the _fork method introduced in Ruby 3.1; therefore, they require extra configuration. cover_rage makes use of _fork and provides a cleaner and simpler interface to record code coverage and last execution time for each line of code.

"Road to RubyKaigi" is back!

Road to RubyKaigi is a side-scrolling action game written in Ruby that runs in your terminal. Try it with gem install road_to_rubykaigi. It was presented as an LT at RubyKaigi 2025, and has leveled up since then!

This year, I use a Raspberry Pi Pico 2W to control the game. Let's break free from the computer and play!

Ruby is typically assumed to run on top of an operating system. But how much of Ruby can run on bare metal, without that assumption?

In this talk, I explore these questions by running CRuby on a custom kernel, examining the minimal requirements for executing CRuby and the assumptions behind it. Rather than using embedded-oriented implementations such as mruby or PicoRuby, this work takes the approach of running CRuby itself in a different environment, and shares the challenge of extending Ruby into new domains.

Through this process, I reveal dependencies and initialization mechanisms in CRuby that are usually hidden, and clarify what kind of environment CRuby actually depends on to run.

I built mruby-gpu — a mrbgem that runs Vulkan Compute Shaders on a Raspberry Pi 5 — because I wanted to feel what happens when Ruby talks directly to hardware. It started with a simple vector addition. Then I built matmul, ReLU, and scale, and moved on to MNIST training. That's when I hit the wall: training was painfully slow. The GPU was fast at math, but constant CPU-GPU data transfers for each sample were killing performance. I restructured the data pipeline — packing data efficiently, reducing round trips, keeping work on the GPU side. When training time dropped dramatically, I felt the thrill of understanding what the hardware actually wants. Next I tried real-time face detection on camera input. Surprisingly, GPU was slower than CPU here. But with mruby, switching execution targets is trivial — no recompilation, just edit the script and run again. This fast experiment loop is what makes mruby ideal for hardware exploration. Live demos included. Come feel what the hardware wants.

Every Ruby String carries its own encoding. Most programming languages don't do this. How much runtime cost does this design actually add?

In this talk, I'll progressively strip encoding-related code from CRuby and benchmark the result. Encoding compatibility checks, encoding definition tables, transcoders—I'll measure how Ruby changes when these are removed.

Ever wondered how Ruby actually executes your code? "Ruby YARV Challenge" is a browser-based workshop where you implement a simplified YARV bytecode VM and compiler in Ruby, step by step. All seven steps build toward one goal: running recursive Fibonacci on your own VM. Powered by ruby.wasm, with Prism as the parser, everything runs in the browser.

No prior VM knowledge required—each step starts with a visual tutorial explaining the concept from scratch, followed by progressive hints if you get stuck. The first step is just three lines of Ruby: push a number onto the stack and return it. That's a working VM. No install needed—just open the URL and start building.

TypeGuessr's profiling revealed that 14% of CPU time was spent creating instances of Internal representation for node during index construction. Replacing IR node definitions with plain Class made object creation dramatically faster. This talk shows the benchmark results, briefly looks at where the cost comes from.

I have implemented an HTTP/2 server with Ractor. I believe implementing HTTP/2 is an interesting challenge for Ractor because it requires both concurrency (Streams and Multiplexing) and strict state management (HPACK dynamic tables).

In this talk, I will introduce "biryani," an HTTP/2 server built from scratch using Ractor based on RFC 9113 and RFC 7541. I will demonstrate implementation using Ractor and share insights gained from this.

You ship a ruby.wasm app. It works on your MacBook. You bring it to a conference booth, hand it to a stranger on their iPhone — it crashes. The next person's Android freezes with no error. A third player comes back from a break and their quiz progress is gone. I hit all three at SITCON 2026 which is the only open source conference for students, running a Ruby quiz game powered by Ruby 4.0 WASM in-browser, designed to introduce Ruby to people who had never written a line of it. Each failure has a root cause and a fix under 10 lines. I'll show you all three.

Turbo Streams' append is usually powered by JavaScript. Can we implement it in pure Ruby?

In this talk, I reimplement Turbo Streams' append using ruby.wasm and Ruby's Socket library — with almost no JavaScript. I break down how append actually works, and explore how far Ruby can handle it directly.