What if you could keep Rails pages fast, accessible, and SEO‑friendly, yet still get modern interactivity without shipping a mountain of JavaScript? We sit down with Cameron Dutro to unpack Live Component, a server‑first approach that breathes life into ViewComponent by treating state as data, rendering on the server, and morphing the DOM with Hotwire. No fragile ID wiring. No React by default. Just clear state, small payloads, and focused updates.

We trace the path that led here: experiments rendering Ruby in the browser with Ruby.wasm, Opal, and even a TypeScript Ruby interpreter, and why those payloads and debugging pain pushed the work back to the server. Cameron explains the Live Component mental model—initializer‑defined state, slots, and a sidecar Stimulus controller—plus how targeted re‑renders make forms and micro‑interactions feel instant. We talk transports (HTTP vs WebSockets), serialization best practices for Active Record data, and where React still shines for high‑intensity builders and editors.

Beyond the code, we dig into the bigger web story: how DX‑first choices often punish users on slower devices and networks, and why a balanced, server‑driven approach can close that gap. You’ll hear real‑world tradeoffs, debugging techniques that feel like home to Rails devs, and a clever fix born from a Snake game that surfaced timing issues and led to a preempt option for queued renders. If your team wants dynamic islands without adopting a full SPA, this conversation offers a practical roadmap.

Explore Live Component at livecomponent.org and the GitHub org at github.com/livecomponent. If this resonated, follow, share with a Rails friend, and leave a review so more builders can find it.

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show

Rails upgrades don’t have to feel like crossing a minefield. We sit down with Ernesto, founder and CTO of FastRuby and Ombu Labs, to unpack a pragmatic path from legacy Rails to Rails 8.1 and how AI can accelerate the work without sacrificing quality. From Ruby 4.0 landing over the holidays to a near-release of RubyCritic 5.0, we dig into the tools, the traps, and the test-suite realities that make or break an upgrade.

Ernesto walks us through a free AI-powered upgrade roadmap that analyzes your repo, dependencies, and code to chart a step-by-step plan—covering everything from Rails 2.3 onward. We compare it to their paid roadmap that adds time and cost estimates for stakeholders who need budgets before they commit. Along the way, we talk strategy: why 5.2 marked a turning point for smoother jumps, where major versions still bite, and how to avoid the “big bang” deployment that topples fragile apps.

AI shows up as a sharp tool, not an autopilot. Ombu is experimenting with agent-driven PRs that draft changes while humans review and refine. We assess hallucinations (better, not gone), verbose code that bloats review cycles, and the mixed evidence on productivity. Then we get practical about safe AI adoption: organization licenses, editor integrations, and enforcing your existing quality gates like RuboCop, Reek, RubyCritic, and coverage checks so “faster” still means “safer.”

We also celebrate community. Philly.rb is back in person at Indy Hall with talks on AI agents and Hotwire Native, and we swap tips on discoverability, speaker sourcing, and venues. Rails remains a strong choice for startups and teams because convention over configuration helps both humans and AI produce sane, testable code. If you care about getting upgrades right and using AI responsibly, this conversation offers clear steps and real-world guardrails.

Enjoy the episode? Subscribe, share it with a teammate wrestling an upgrade, and leave a quick review so more Rubyists can find us. Have a talk idea for Philly.rb? Reach out—we’d love to host you.

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show

What makes a small Ruby conference feel electric instead of ordinary? We unpack the craft behind Blue Ridge Ruby—why we chose a newly renovated, accessible venue, how a single-track format keeps the room together, and the little details that turn a meetup into a memory. From open lunches across Asheville to surprise sponsor moments, we share the thinking that goes into designing an event that celebrates Ruby, supports new speakers, and still feels human-scale.

Jeremy breaks down the CFP playbook: write clear abstracts with specific outcomes, submit widely, and rehearse before acceptance so you’re not rushing at the end. With only ten talk slots, curation is both art and constraint. We talk honestly about the selection process, why “no” often means “not now,” and how meetups can incubate a 10-minute idea into a conference-ready talk. We also explore the real costs—venues, video, capacity—and why accessibility drove the move to the YMI Cultural Center.

Then we zoom out to the work behind the work: choosing bounded risk to stay motivated, planning sustainable volunteer roles, and creating a container that invites the community to bring their best. On the engineering front, we share how voice-first AI workflows changed our Rails practice. Whisperflow plus LLMs accelerate iteration when conventions set guardrails. We describe using diverge–converge patterns to try multiple implementations, keeping architectural intent while rejecting unnecessary complexity. AI is the nail gun; we’re still the builders who decide what the house should be.

Want to be part of it? The CFP is open, sponsors are welcome, and volunteers make the magic real. Subscribe, share this episode with a Ruby friend, and drop us a review—then send your proposal or reach out about helping in Asheville at BlueRidgeRuby.com.

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show