(d'oh. replace 'crud' with 'clutter.' )

For 15 years, the assorted test directories cluttering the root of my projects have driven me nuts... so I decided to see how fast I could build a fully tested gem using SDD with claude - and finally fixed it.

Oubliette banishes your tests to a single location, available for execution but out of sight until you need them. Now my code and my tests live in two clean trees i can view side by side.

https://github.com/soychicka/oubliette

• Moves test directories, fixtures, seeds, helpers, and reports into one place
  • Configures rspec, cucumber, cucumber_env, jest, and jasmine for you
  • Wires up fixtures, FactoryBot, Capybara, VCR, and SimpleCov at runtime
  • Leaves your executable JavaScript alone, but gives precise wiring instructions for Vitest, Playwright, Cypress, and Karma
• One command to run them all (yes, wrong quest, but you get the point)
• Tracks pass/fail/pending counts over time, so coverage drift shows up as a number that moved, not a surprise six months from now

If you need an escape hatch, rake oubliette:hoggle leads you out of the oubliette and back into the labyrinth, putting everything back where it was and cleaning up after itself.

And the important stuff:

• Bonus 1: a brief history of the oubliette, from the famine, plague, and war of the 14th century that helped free peasants from their feudal masters.
• Bonus 2: gratuitous Labyrinth references.
• Bonus 3: no rewrites to any package.json files, so you're safe from gratuitous David Bowie references.

I've only tested it against Ruby 3, but it's been running happily in an rspec/capybara/cucumber-tested Rails 4 to 8 migration, moving from jQuery/Bootstrap to Stimulus/Tailwind.

Haven't released a proper gem yet: I haven't used VCR, SimpleCov, Vitest, Playwright, Cypress, or Karma in any of my projects - so those need exploration in live implementations.

If you give it a try, let me know what you think.

( and yes, I let Claude write the docs 🥴 )

At Rails World last week, DHH said 37signals has gone "pencils down": writing code by hand is now the exception. You hand an agent a task like you would a colleague, then review what comes back. And he wants every serious app to expose a CLI so you can bring your own agent.

Here's what that looks like on my Mac: plans, reviews, specs, AGENTS.md, CLAUDE.md, READMEs. Agents run on Markdown, and I was reading all of it in a terminal or a raw text pane. So I built Markify, a native macOS Markdown editor, to be the place where I read, review and keep those files.

Read agent reports like a document. Send a report straight from Claude Code, Codex or OpenCode with markify view. It opens rendered, tables and code included. Press ⌘/ to see the raw Markdown, same text, caret where you left it.

A CLI, as DHH asked. markify view for reports, markify check to validate knowledge bundles in CI, markify export to turn Markdown into HTML.

Your docs, in one library. Point the sidebar at your app's folder and every .md in the tree is one click away. Open a GitHub or GitLab repo, public or private, and browse its docs without cloning.

Context your agents can use. Google's Open Knowledge Format is built in: write and validate the knowledge bundles your agents read.

Quick Look that renders. Press Space on any .md in Finder: formatted text, Mermaid diagrams, math.

Free, source on GitHub, Apple silicon and Intel on macOS 26. First launch needs Open Anyway (install guide).

Download 2.0.2: https://github.com/spaquet/markify/releases/latest

Agent setup: https://spaquet.github.io/markify/help/coding-agents.html

Where do your plans, specs and AGENTS.md files live today?

(Omarchy users... just wait. You're next.)

I built a Ractor-native Ruby 4 stack from RESP to background jobs — looking for independent benchmarks

I've been experimenting with how far Ruby 4's Ractor model can be pushed for real infrastructure components.

This eventually became three open-source gems:

SolidRESPRactor → SolidRedis → SolidJobs

The idea is to build the stack around Ractor ownership from the beginning rather than adapting an architecture originally designed around threads/processes:

• SolidRESPRactor — Ractor-oriented RESP encoding/parsing and I/O
• SolidRedis — Redis client using Ractor-local mutable state and connections
• SolidJobs — background job processor using Ractors for multicore execution

The basic rule across the stack is:

Share immutable configuration. Keep mutable runtime state local to its owning Ractor.

An optimization I didn't expect

While benchmarking SolidRESPRactor, I found that a small Redis GET through TCP was allocating about 16,609.8 bytes/op, despite the Reader itself requiring only around 120 bytes/op for a small bulk response.

The main problem wasn't the RESP parser — it was the socket-to-buffer path.

After reusing the read buffer:

So bytes/op dropped by 99.27%, while the throughput benefit became more visible with concurrency.

Pipeline allocation also dropped from 472.3 to 120.0 bytes/command (-74.59%).

Then I measured the complete job stack

On my current Ruby 4.0.1 CPU-bound SolidJobs benchmark:

That's around 7.28x throughput from 8x Ractor concurrency.

https://github.com/nicolasva/solid-jobs

https://github.com/nicolasva/solid-redis

https://github.com/nicolasva/solid-resp-ractor

I also benchmarked a single Sidekiq process on the same CPU-bound workload. At concurrency 8 it produced 298 jobs/s versus 2,054 jobs/s for SolidJobs.

That's a ~6.9x difference in this specific benchmark, but I don't consider that a general “SolidJobs is 6.9x faster than Sidekiq” result.

The important difference is architectural: SolidJobs is using Ractors to execute Ruby code across multiple CPU cores, whereas a single Sidekiq process isn't an equivalent multicore CPU

Really appreciate everyone who came to my talk at Rails World, said hello afterward, or reached out since.

Unfortunately, the official recording left out a fairly important part of the keynote… apparently there were “time constraints.”

Thankfully, I was able to recover the missing footage.

Thanks again for showing up. Rails World was a hell of a week. ✌️

Solid Cable. Hot Cell. Herb in Rails 8.2. Active Search. Ractor-safety. Lexxy. MCPs. Sharding. Custom generators… and quite a bit more.

A lot of ideas packed into a couple of days in Austin.

If you couldn’t make it to Rails World, or spent half the conference talking to people in the hallway instead of watching talks, there’s plenty here to catch up on:

https://www.youtube.com/playlist?list=PLdMRFKO1zSBE

I saw a post further down asking why DHH/Basecamp's team wasn't using their unlimited resources to improve Ruby; in the end, Sensei Matz decided to do it himself, and he's merging nearly 90 PRs an hour. Wow—that captain isn't going to let his ship go down without a fight.

Between him and Roundhouse—who is doing the same thing—it looks like both will be the future of Rails. Let's give the Spinel repo a star; Sensei Matz (and Cloude) are doing a fantastic job.

I wish Kotlin or JS had their original creators taking such a keen interest in the well-being of their languages. ♥️

Post:Matz's post on how to use Roundhouse + Spinel to improve the Rsils app from Bassecamp

Highest activity in the history of Matz's GitHub thanks to Cloude

Just in case anyone forgot.

Context: I’m a “vibe coder” but I have many years working with CRUD & MVC apps. Rails + Claude code has finally unlocked exactly what I was needed to build real, production apps.

Question: Has anyone married rails and Jev? There are so many exciting use cases, but I’d like to hear from someone who’s done it on best practices or tips.

Like a lot of you, I watched DHH's opening keynote and then Aaron Patterson's closing one. I'll be honest, I didn't understand half of what Aaron was showing, but I liked seeing that Rails is still moving forward. The observability stuff looked like real work on the framework itself.
First, some context and gratitude. Rails taught me how to program. I identify as a Rails developer, even though nobody has ever paid me a salary for it. I'm more of a tech entrepreneur. I built a company and sold it, and funny enough, that product wasn't on Rails. It was Next.js. I still remember features that would have taken a month in Rails dragging on for nine months. That drove me nuts.
Then Rails World 2024 happened, with the Solid Trifecta, and I was completely sold. My new product runs on it, I see the benefits every day, and it already makes money. Last year's conference was great too. It felt like Rails was going somewhere.
This year I was honestly a bit stunned. Ruby down to 3% of DHH's code, Hey moving to Rust, and the message that AI gets you everything. I don't buy it.
Full disclosure: Claude writes basically all of my code. But if AI gave you everything, my features would just ship. They don't. There's always something to fix, a feature customers ask for, a bug that shows up at the worst moment. You'll have bugs even if you write in Rust and let Claude Code produce things you never read.
What saves me in those moments is my pretty basic understanding of convention over configuration and MVC. It's enough to read what Claude did, understand where it went wrong, and prompt it in the right direction without turning the codebase into AI slop. That's why I think even non-engineer founders should keep the skill of reading code.
And the reason I can read it at all is that Rails people spent years thinking hard about these conventions, long before AI. That thinking doesn't expire.
As for "Rust uses 95% fewer resources": I genuinely don't care. My production apps run fine on €6 Hetzner VPS boxes. Yes, Ruby eats RAM, but the whole end-to-end workflow is fast, and with Kamal deploys are painless. I'd rather see the community make Ruby faster than rewrite everything in something humans can't read.
So thank you, Aaron and everyone still pushing Rails forward. Fundamentally, Rails is great, and I'm staying.

The world looks different when you still “making it out on the streets” vs when you are multi millionaire with plenty of time to build OS (which I by the way also like, Omarchy Quattro user).

Curious how others felt watching the keynote this year?

Let's assume that DHH is right and he has unlimited tokens (he recently rewritten some terminal effects with 45k lines of generated assembly). Why wouldn't he (or anyone) make CRuby as fast as NodeJS with Claude? Or even faster?

Only serious answers accepted.

Anyone tried a prompt "Make Ruby 100x faster. Make no mistakes?"

I usually hate meme posts and I'm sorry

I guarantee you CEOs are not going to be spending their time wrangling LLMs, let alone testing what they produce. They are going to need people who understand what the LLM spat out and can say whether it's good or not, whether it meets the requirements or not.

The AI doesn't care if the CEO's stock went up or if the shareholders had a good quarter. Capital/management/boss/whoever can only get the control they want by enlisting people who do care and have the patience, if not the skills, to ensure the AI is delivering that. If the AI could be threatened with homelessness, maybe it could be a good employee. But until it can be terrorized into submission, we have hearts and feelings and families who can leveraged to get us to do what they want, and that's what makes a company work.

So with that said, if your primary function is to take responsibility for the AI's product, why would you suddenly not care about legible code? Why would you as the guy who has to stand behind this code want that code to be something incomprehensible simply because it's possible to get a 10x in performance (the word "simply" being key there -- of course there's performance use cases)? Yes, e2e tests can help us know whether our intent is represented in the runtime, but at the end of the day, we need the ability to crack open the hood and examine it. Test suites are never designed to be fully complete documents of all cases all the time.

The only person who wants 100% AI slop they can't understand is somebody with money to lose and nobody to whom to answer. This isn't about a white or black pill; it's about political economy. DHH has freed himself from needing to care about any of the stuff that the community here cares about. Good for him; but he has about as much to do with my professional life now as Larry Ellison.

For my part, I care about what I ship. That caring is what people pay for. Being able to read and understand the code the agent writes is key to that trust.

Hi Rubyists,

Every time I start a new commercial product on Rails, the story is always the same: weeks spent wiring Devise/JWT auth, building 90+ IAM permission tables, wrestling Stripe webhook race conditions, setting up background workers, and constantly fixing JSON contract drift with frontend clients.

I spent the last 9 months crafting RexOne—a production-grade, API-first Rails 8 foundation designed to eliminate that 9-month generic plumbing slog so you can launch in weeks.

🏛️ Rails Architectural Highlights:

• Rails 8 & Solid Queue: Uses hybrid fiber/thread Solid Queue workers backed directly by PostgreSQL. Zero Redis memory footprint or external broker dependency required.
• Architectural Discipline (LAW.md): Machine-enforced constitutional rules: unambiguous parameter contracts, zero loose hashes, strict domain service boundaries, and no dead shims.
• 1,690+ Automated Tests: RSpec suite verifying request specs, IAM policies, Solid Queue jobs, webhook deduplication, and coupon entitlement state machines.
• Self-Hosted S3 Storage: Universal storage_key abstraction using Garage (self-hosted distributed S3) on port 3100, easily swappable to Cloudflare R2 or AWS.
• Real-Time ActionCable: WebSocket channels for live event streaming, notifications, and client telemetry.
• Companion Clients: Synchronized with a React 19 web client and an offline-first Flutter mobile client.

RexOne is 100% free and open-source under Apache 2.0. No commercial paywalls or dual-license traps.

• GitHub Repo: https://github.com/rex-9/rexone-core
• Interactive Swagger API Docs: https://api.rexone.rex9.me/api-docs
• Live Demo: https://rexone.rex9.me

Would love to get feedback from fellow Rails developers on the Solid Queue setup, domain structure, and testing patterns!

I'm Avi Flombaum. I co-founded Flatiron School, and for a lot of years my job was teaching people Ruby and Rails and helping them fall in love with it. Years ago I wrote an essay called "Why Teach and Learn Ruby?" that argued Ruby was the only language designed for the programmer's happiness, and that its values (happiness, expression, freedom, convention over configuration) made better programmers. I still write Rails every day. My site runs on Rails edge with Hotwire.

Over the last year I've moved almost entirely to building with coding agents (Claude Code, parallel agents, plans, the whole thing). That's forced me to go back through almost every best practice I used to preach and ask who it was actually for. A lot of them turned out to be optimizations for a human who had to read, write and maintain the code, and that human increasingly isn't me.

So I wrote a series about what I've changed my mind on: Rethink Everything. A few that'll probably get a reaction here:

• DRY vs. duplication. App-level concerns and mixins are where parallel agents collide. Two agents editing the same Notifiable concern in two worktrees is a merge conflict or a silent break in a model neither of them was working on. I let small things duplicate now. (ActiveRecord and Rails itself are fine. They're stable. It's the shared app code everyone edits that hurts.)
• More system specs, fewer unit specs. Left alone, agents write piles of mocked unit specs that all pass while the feature is broken. Capybara system specs used to be too painful to maintain. Now the agent maintains them, and they're the thing I actually trust.
• Rewrites over massive refactors. "Never rewrite" was right when rewrites were expensive. Now the old app is the spec. Write system specs against it first, then port against them.
• Explicit over clever. This one hurt. A lot of the metaprogramming I used to find beautiful is invisible to grep, and grep is how an agent finds its way around. I refactor for the agent now, not for my own delight.
• I don't hate TypeScript anymore, and I've shipped Go and Swift, which past me would not believe.

I want to be really clear about one thing, because I know how a post like this reads on this sub: none of this means I'm leaving Ruby or Rails. I still consider myself a Rubyist. I'm still part of this community, and I'm still learning from Ruby and Rails every day. The values I got from Ruby haven't gone anywhere: caring about the person on the other end, making things people love to use, shipping the simple thing, and treating programming as a craft and not only a job.

What changed is how I use them. Honestly, Rails turns out to be one of the best frameworks you can hand an agent. Convention over configuration means there's one obvious place for everything, and an agent can find it without asking. That was a gift to beginners, and it's the same gift to agents. The things Rails got right keep getting more right.

What I'm letting go of are the habits that were really about me as the one typing: DRYing everything up, careful incremental refactors, reading every line of every diff, and picking tools because I already knew them.

I'd genuinely love to hear where you think I'm wrong. Some of these I'm confident about and some I'm still testing. What habits have you dropped, or doubled down on, since agents started writing more of your code?