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

Source: Dev.to

tiny ruby #{conf} 2025

tiny ruby #{conf} 2025 was a single‑track Ruby conference in Helsinki, Finland. 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 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 trade‑off 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

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 stance is pragmatic — optimize where it moves the needle, not because container lore says you should.

Unlocking the Rubetta Stones — Louis Antonopoulos

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 trade‑off 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. Revisiting basic types is not pedantry; it’s preventative engineering for maintainable codebases beyond year 3.

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 practical pitch accelerates growth through mentorship, pair programming, and AI, emphasizing that learning alone often leads to local maxima.

For Rails engineers, the key point is that ecosystems change fast (tooling, deployment norms, testing culture), and solo learning can stall progress. Pairing and mentorship shorten the time‑to‑correctness for both technical and career decisions. The trade‑off is coordination cost: you need to create space and norms that make pairing and mentorship safe and useful.

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