What if the most useful software in your life isn’t a product, but something you built for yourself in an evening? That’s the spark for this conversation with Travis Dockter, a Rails developer and organizer of Blast Off Rails, where we dig into how AI turns personal ideas into working tools—fast. From a “house health” app that scores chores to a suite of single-user utilities, we break down what’s changed: ideation is quicker, boilerplate is lighter, and the cost of experimentation has never been lower.

We get real about security for personal apps and why network-level access with Tailscale can be the right fit when you’re the only user. It’s a conversation about risk, not dogma—matching controls to stakes and keeping momentum. We also examine the blurry space around AI-assisted pen testing, the difference between “won’t” and “can’t” in model behavior, and how to navigate that responsibly. Then we push forward: what happens when an agent can manage a Markdown knowledge base or a SQLite file directly? If the UI becomes conversation, design becomes orchestration and feedback, not screens.

Docs turn out to be the sleeper blocker. Travis details a pragmatic Obsidian workflow: agents.md files scoped to code areas, linked session notes, and templates that help models find the right context when it counts. We round it out with hard-won lessons on token efficiency, choosing the right model for planning vs building, and experimenting with multi-model “counselors” to balance cost and quality. Finally, we share why a Rails-focused, single-track conference in Albuquerque can actually boost your day-to-day work: tighter content, lower travel costs, and rooms full of people solving the same problems.

If you’ve been itching to ship something small and useful, this is your nudge. Subscribe for more builder-first conversations, share this episode with a friend who loves Rails, and leave a quick review so others can find the show.

Send us some love.

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

Support the show

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

What if AI could make your work more creative instead of more crowded? We sit down with Scott Werner to unpack a practical path for Ruby developers who want the leverage of AI without sacrificing taste, clarity, or joy. From agentic coding with Claude Code to context-rich tools like Tidewave, we walk through how better inputs—logs, DOM access, database state—turn generic suggestions into usable plans that reduce cognitive load and speed up real problem solving.

Scott shares the origin story of Artificial Ruby, a New York meetup that started as a casual happy hour and became a monthly mini conference. That community energy matters: many devs began their careers remotely and missed the spark of live conversations. By focusing on play and curiosity, the group channels the early Ruby vibe—ship small experiments, trade sharp feedback, and rediscover the fun of making software together. That ethos powers Scott’s projects: Monkey’s Paw, a prompt-based web framework that leans into expressive generation, and Latent Library, a hallucinatory book explorer that asks what new interfaces AI enables.

We also tackle the “slop generator” problem and how to curb it. Different models have different tendencies, so route tasks where they fit: broad ideation to one, surgical changes to another. Constrain edits, ask for reasoning before code, and hand the model real context so it can propose focused steps. The same philosophy informs testing with computer-use models: if an agent can’t find your logout or complete checkout by looking at the UI, maybe your users struggle too. Rather than replacing developers, these tools elevate the craft—pushing commodity work downward while widening the canvas for design, problem framing, and tasteful implementation.

Want more? Check out ArtificialRuby.ai for upcoming events and videos, explore LatentLibrary.xyz, and find Scott’s essays and tutorials at WorksOnMyMachine.ai. If this conversation helps you rethink your workflow, follow, share with a teammate, and leave a review so more builders can join the experiment.

Send us some love.

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

Support the show

In this episode of C4, Andrew Mason and Rachael Wright-Munn join Drew to unpack recent controversies surrounding Ruby Central and its alleged takeover of Ruby Gems and Bundler. The trio delves into the timeline of events, conflicting narratives, communication failures, and the underlying security concerns. They address theories and facts, scrutinize the governance of Ruby Central, and discuss the implications for the Ruby community. The episode emphasizes the importance of asking questions and seeking clarity, while advocating for a balanced and constructive approach to resolving the community's issues.

Sources discussed*:

• Ellen's first post on the RubyGems controversy
• A board member's perspective on the RubyGems controversy
• An Update From Ruby Central (Video)
• Investigation (allegedly) reveals Shopify manipulated Ruby Central to force takeover of Bundler and RubyGems
• Strengthening the Stewardship of RubyGems and Bundler
• Martin Emde's post on Bluesky
• Reddit post for "An update from Ruby Central"
• Bundler Policies on GitHub
• Ruby Central "About" page
• Advocacy for Reduced Rails Usage
• Alpha-Omega Project
• Organization & Structure of Open Source Software Development Initiatives - Cyberlaw Clinic
• Ruby Central News Post: Alpha-Omega support
• StepSecurity: npm supply chain compromise
• Socket: npm supply chain attack
• Palo Alto Networks Unit 42: npm supply chain attack

* Some sources include unverified information being presented as fact. Read with caution.

Send us some love.

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

Support the show

Ruby core team member Aaron Patterson (tenderlove) takes us deep into the cutting edge of Ruby's performance frontier in this technical exploration of how one of the world's most beloved programming languages continues to evolve.

At Shopify, Aaron works on two transformative projects: ZJIT, a method-based JIT compiler that builds on YJIT's success by optimizing register allocation to reduce memory spills, and enhanced Ractor support to enable true CPU parallelism in Ruby applications. He explains the fundamental differences between these approaches - ZJIT makes single CPU utilization more efficient, while Ractors allow Ruby code to run across multiple CPUs simultaneously.

The conversation reveals how real business needs drive language development. Shopify's production workloads unpredictably alternate between CPU-bound and IO-bound tasks, creating resource utilization challenges. Aaron's team aims to build auto-scaling web server infrastructure using Ractors that can dynamically adjust to workload characteristics - potentially revolutionizing how Ruby applications handle variable traffic patterns.

For developers interested in contributing to Rails, Aaron offers practical advice: start reading the source code, understand the architecture, and look for ways to improve it. He shares insights on the challenges of making Rails Ractor-safe, particularly around passing lambdas between Ractors while maintaining memory safety.

The episode concludes with a delightful tangent into Aaron's latest hardware project - building a color temperature sensor for camera calibration that combines his photography hobby with his programming expertise. True to form, even his leisure activities inevitably transform into coding projects.

Whether you're a seasoned Ruby developer or simply curious about language design and performance optimization, Aaron's unique blend of deep technical knowledge and playful enthusiasm makes this an engaging journey through Ruby's exciting future.

Send us some love.

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

Support the show

Marco Roth joins us to unveil Herb, his revolutionary toolchain for Rails views that's reshaping how we work with HTML and ERB. Having identified a critical gap in the Rails ecosystem—robust tooling for the view layer—Marco decided to build the solution himself, learning C along the way to create a parser with unparalleled cross-platform compatibility.

Far from just another syntax checker, Herb represents a comprehensive vision for modernizing Rails views. Marco walks us through his layered approach, starting with immediate editor feedback for markup errors and ambitious plans for reactive views inspired by Phoenix LiveView. The most exciting prospect? Allowing developers to write modern, interactive applications without abandoning Ruby for JavaScript frameworks. "I want to bring back some awesome experiences from JavaScript to the Rails ecosystem so we can keep doing Ruby," Marco explains, highlighting how Herb could transform ActionView after two decades of relative stagnation.

We also explore Marco's approach to managing multiple ambitious projects alongside a consulting career, his upcoming conference schedule (including RailsWorld, FrienlyRB, and Euruko), and his work on Ruby Events—a catalog of over 7,000 Ruby talks that serves as an invaluable community resource. Marco shares insights into his development process, the challenges of mapping tag helpers to HTML, and his recent implementation of Tailwind class sorting in the Herb formatter.

Whether you're frustrated with Rails' front-end limitations or simply curious about innovative tools reshaping the Ruby ecosystem, this conversation offers a fascinating glimpse into the future of web development with Rails. Marco's work reminds us that with the right tooling, we can build modern, reactive applications while maintaining the developer happiness that drew us to Ruby in the first place.

Send us some love.

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

Support the show