[Talk::Overflow #23] tiny ruby #{conf} 2025
tiny ruby #{conf} 2025 was a single-track Ruby conference in Helsinki, Finland (21 November 2025). Six talks, one day, no filler.
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. If you ever need Ruby in a product surface area that isn’t a web server (device, kiosk, scripting engine), this is a good map of what’s feasible. It also reframes “Ruby performance” conversations: sometimes the win is choosing the right runtime shape, not micro-optimizing the same one.
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. The tradeoff is that you must be explicit about constraints and objective functions; hand-wavy heuristics are easy to ship and hard to trust. If your Rails app has pricing, scheduling, packing, allocation, or any “best possible under constraints” workflow, this is the mental model upgrade. Bonus: the same approach maps beyond games into domains like energy modeling—where correctness beats vibes.
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 tradeoffs are in maintenance: smart caching and layering can be brittle if the team doesn’t understand why the Dockerfile is structured a certain way. The talk’s stance is pragmatic—optimize where it moves the needle, not because container lore says you should. If your deploys are slow, CI is expensive, or local dev drift is constant, improving your Docker fundamentals is one of the most leverage-heavy fixes you can make.
Unlocking the Rubetta Stones: Translating a Hoard of Ancient Tablets with Ractors and AI — 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. If you’re thinking about speeding up CPU-bound Ruby workloads, or building pipelines that combine parallel work with human/AI review, this is the kind of story that makes the constraints memorable. It’s also a reminder that Ruby has more concurrency options than “just add Sidekiq.”
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. The keywords here are truthiness, modeling, state, domain design, and complexity. Rails apps in particular accumulate boolean flags over time (“active”, “deleted”, “confirmed”, “archived”…), and those flags start interacting in ways nobody intended. If you want codebases that stay maintainable at year 3+, revisiting basic types like this is not pedantry—it’s preventative engineering. The tradeoff is up-front design effort, but it beats debugging “impossible” states in production.
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. Treat AI like another pairing partner: helpful for iteration, but still requiring judgment and verification. If you’re feeling stuck, this talk is a reminder that the solution is often more structured collaboration, not more late-night grinding.
Ruby’s advantage remains the same: it lets you iterate quickly. The difference now is that high-performing teams pair that speed with cleaner models and more intentional delivery mechanics.
💬 Like what you read?
You’re reading Talk::Overflow #23 — the weekly digest for developers who want to stay sharp and skip the noise.
→ Browse past issues
→ Suggest a talk
→ Share it with the friends
Stay curious. Stay kind.
— Talk::Overflow