[Talk::Overflow #23] tiny ruby #{conf} 2025

tiny ruby #{conf} 2025 was a single-track Ruby conference in Helsinki, Finland. Six talks, one day, no filler.

Read the full post and subscribe at Talk::Overflow.

Ruby conferences are often mistaken for "Rails conferences with nostalgia." tiny ruby #{conf} 2025 is a useful corrective: the agenda is about engineering choices — how you model complexity, how you ship and run Ruby in real environments, and how you keep your craft (and career) compounding.

For Ruby on Rails engineers, the signal is practical:

• Ruby is still a productivity language, but the bar has moved toward operability, modeling discipline, and developer leverage.
• "Small" runtimes and "small" concepts (booleans!) hide real complexity that bites production systems.
• Tooling and workflows (Docker, CI, mentoring/pairing, AI assistance) are the multiplier, not the side quest.

---

All Talks

Even smaller Rubies — Chris Hasiński

Ruby isn't just "Rails on servers" — it's also a language that can shrink down into places you don't usually associate with dynamic runtimes. This talk tours mruby and mruby/c, focusing on both useful and delightfully weird deployments: game scripting, retro consoles, and even "auto-focus glasses."

The practical takeaway for Rails folks isn't that you should rewrite your app for embedded; it's that Ruby's ecosystem includes runtime options that can fit tighter constraints than CRuby-on-Linux. The tradeoff is obvious: smaller runtimes mean tighter APIs, different extension stories, and fewer "it just works" assumptions.

Brewing potions with Ruby and linear programming — Youssef Boulkaid

This is an applied modeling talk disguised as a cozy-game anecdote. Starting from Potionomics (a game about running a potion shop), it drops into the real work: combinatorics, data modeling, and optimization with linear programming.

The interesting bit for working engineers is the shape of the problem: when "try all the combinations" stops scaling, you need a solver mindset, not more brute force. Ruby is a perfectly reasonable glue language for these kinds of models, especially when the goal is clarity and iteration speed.

Docker – Build the Perfect Home for Ruby — Matti Paksula

Rails ships a Dockerfile now, but "it builds" isn't the same as "it's a good container image." This talk is about turning Docker into a repeatable home for Ruby apps using gem caching, layer strategy, multi-arch builds, and faster CI/CD pipelines.

For teams shipping Rails, the payoff is simple: shorter feedback loops and fewer "works on my machine" mismatches between dev and production. The talk's stance is pragmatic — optimize where it moves the needle, not because container lore says you should.

Unlocking the Rubetta Stones — Louis Antonopoulos

This talk uses a playful framing — decaying "ancient tablets" that must be deciphered quickly — to explore concurrency and assistance workflows in Ruby. The core ingredients are Ractors (Ruby's parallel execution model) and an AI assistant as a collaborator in the translation effort.

Even if you don't use Ractors daily in Rails work, the underlying lesson is relevant: when the workload is parallelizable, architecture choices matter more than clever code. The tradeoff is complexity: concurrency models introduce sharp edges, and "AI help" only helps if you can validate outputs and keep the system grounded in reality.

Revisiting Booleans in Ruby — Sarah Lima

Booleans look harmless until your domain stops being binary. This talk argues that Ruby truthiness and "just use true/false" often become a modeling trap, especially when systems evolve into multi-state workflows.

The useful takeaway is: when you model a complex state machine as a boolean, you're hiding information — and you'll pay for it later in conditionals, edge cases, and unreadable code. If you want codebases that stay maintainable at year 3+, revisiting basic types like this is not pedantry — it's preventative engineering.

Level Up Your Engineering Career with Mentorship, Pairing, and AI — Hana Harencarova

Not every high-leverage talk is about code paths; some are about feedback loops. This one is a practical pitch for accelerating growth through mentorship, pair programming, and AI — with an emphasis on not learning alone.

For Rails engineers, the key point is that ecosystems change fast (tooling, deployment norms, testing culture), and solo learning often leads to local maxima. Pairing and mentorship shorten the time-to-correctness for both technical decisions and career decisions. The tradeoff is coordination cost: you have to create the space for pairing and mentorship to actually happen, and you need norms that make it safe and useful.

---

Read the full post and subscribe at Talk::Overflow.