Puma 8.0 "Into The Arena" has been released! 1. Framework/lib authors can move threads into a special "high IO" pool 2. single/cluster DSL hooks for easier config 3. API for adjusting threadpool size at runtime (who would want to that? stay tuned...)

Re: Axios - so I guess if you're an OSS maintainer, your threat model is now: "I may be targeted by a state-sponsored hacking group at any time."

1 process per pod was a LIE that you were sold by BIG SRE and people who don't understand the oldhead technology of PRE-FORKING SERVERS. We went from 1 Puma proc per pod to 4 and HALVED RESPONSE TIMES and dropped queue time to ZERO, for the same CPU/memory alloc.

Has anyone applied an autoresearch loop (successfully or not) to a Ruby project outside of Shopify yet? I would like to cover it in my RubyKaigi talk.

@simonwillison.net maybe you're used to this level of notability now, but I noticed Jensen Huang explicitly referencing the Lethal Trifecta a few times at GDC, although I noticed he said "it's fine as long as you only have two [legs of the trifecta]"

The #1 most important performance work in almost any web app is converting full navigations into SPA/route changes/Turbo Drive clicks. You are converting a ~4 second experience into a 400ms experience every single time. Nothing else comes close.

Super common mistake I see in Ruby setups: don't allocate more than 1 CPU core to background job containers. You're only running one process in there (usually) so there's no reason to allocate > 1 core.

After ~9 months of experimentation (synthetic and in prod), I can say definitively that MALLOC_CONF has no measurable effect on any Ruby workload that I've seen. Don't bother.

50% of what I'm doing at clients these days is addressing unclear expectations of what queue latencies are allowed to be in background work. Almost no one has the proper suite of alerts and observability, queues routinely ballooning without anyone realizing.

It's pretty rare these days to be on a version this old, but if you're still running Ruby 3.1 in production: it's worth upgrading to 3.2+ purely to get YJIT.

LCP is not a good top-level frontend metric to base your entire frontend perf efforts around _unless_ you are specifically targeting search rankings. LCP is not captured on route change/SPA nav or on Safari at all, which means ~50%+ of clicks go unmeasured.

Datadog's continuous profiling product is now best-in-class. Took them a while but Ivo Anjo has really put in a ton of work here for Ruby and the profiles you get now are so, so good. Being able to see gc activity (as well as the reason!) for GC is so cool.

Seen in a Shopify project README. TIL RSpec is deprecated at Shopify.

LLM slopcannons are putting pressure on top of already broken software dev team cultures. The problem isn't the slop generator, so much as your process was only handling low volumes of human-generated slop until now.

A pattern I am seeing: "Generate a 10 question quiz on how this PR works to test my understanding." Do not allow merge until someone passes the quiz. Gusto did this years ago but with humans writing the questions for certain types of PRs.

You are probably not using LLMs enough to generate non-code artifacts. "Review this PR and then generate an interactive HTML website to explain it. Turn this state machine into a mermaid diagram. Generate a 10,000 word deep research report on the state of the art of CSRF protection."

LLMs are (not _just_) autocomplete. They will tend to do MORE, tend to katamari. The dangers of shipping more code and never shipping less still apply.

Your prior at this point needs to be "if LLMs are breaking my SDE lifecycle, the problem is the lifecycle or how we are using the LLM, not the capabilities of the model". You can make models generate anything now. The problem is how you move them through the latent space.

The only code review agent I have ever seen be even remotely good is just Codex xhigh. All the review services (and I've seen at least a dozen at this point) suck so bad that I'm not sure how they make any money at all.

When you've got a queue with a very tight SLO, you don't want to scale down too fast. You end up with a "sawtooth" or jagged container count. The "true" demand for containers is the red line here. In situations on <30 sec SLOs, you often want cooldowns in the >1hour range.

I’ve seen a number of home-grown Claude code orchestrators with built-in kanban… You’ve just been given access to a magical tool that can build anything you can imagine, and… kanban?

Even if not deployed single-node, it's helpful to use Little's Law to understand if you _could_ be. Avg CPU load = CPU time in seconds per req/job * req-per-sec. If that's below ~16, you could definitely run single-node. Why aren't you? No wrong answers, but have a good one.

Your proposal for RubyKaigi 2026 has been accepted.

In 2026, we're going to see coding models either expand or get rebranded into "tool use" or "computer use" models.

looks like a tiktok

LLMs do not meaningfully "refactor" at anything other than a junior engineering level. They can basically do some window dressing and move code around between files. True refactoring means creating new abstractions, which LLMs can't do because they can't form world-models.

The biggest "stink" of LLM code in Ruby currently is how it writes loops like it's writing C. Set up lots of blank/empty variables, loop with each, update variables inside the loop. Use Enumerable! Matz gave us this gift for a reason!

Getting tired of hearing "There are literally no use cases for LLMs" from people who think the only way to use an LLM is to type into chatgpt dot com, press enter, and hope for the best

I think a major wave of self-retirement is coming. A lot of people were already disillusioned with tech industry post-vibe-shift, those same people are also most likely to dislike LLMs for various reasons.

The salary of the top 10% of designers and product people is going to 2x in 2026.

Thank you to everyone who replied to this. Now I'm following a bunch of people talking about their alchemy MCPs, which, honestly, was exactly the kind of interesting I was looking for from this userbase

Tooling for coding agents is overly focused on scaling numerous parallel workers instead of ensuring correctness. That continues to be where all my time goes and is the real barrier to scaling up. (e.g., Why am I exploratory testing this UI when vision models could be doing it?)

Tell me why I shouldn't preorder a Pebble watch + ring _right now_.

Everyone on X is telling me that actually there's tons of interesting AI conversations happening here on Bluesky. Guess I need to retrain my algorithm because I'm not seeing anything.

The greatest trick the devil ever pulled was to convince you that you needed a three-year reserved instance

Ruby was born a hobbyist's language. Written for a human to enjoy, to write, to delight in. Now, I get paid to write Markdown, not Ruby. I ride the LLM-Shoggoth. I don't read the Ruby it creates, Claude does. Ruby will die a hobbyist's language: written by humans, for fun.

Ruby isn't dying, it is already dead. So is every other language. Rejoice, you have been liberated! You no longer write Ruby for The Man, but yourself! Reclaim the means of production as the means of amusement! Ruby was created to make you happy, not the machine. Wrest back your joy!

Ruby isn't dying, it is already dead. So is every other language. Rejoice, you have been liberated! You no longer write Ruby for The Man, but yourself! Reclaim the means of production as the means of amusement! Ruby was created to make you happy, not the machine. Wrest back your joy!

Literally everyone scaling on Postgres eventually hits SLRU cache issues. For that reason I am now saying PG17+ is a must-upgrade, as the changes around cache banking/SLRU configuration are your only real workarounds.

Looking for a designer for a small project (40-80h) this Q1. Please reach out if you or someone you know might have some spare cycles! Particularly interested in designers with a strong, unique (even weird/grating) visual style.

I'm routinely asked about "automatic N+1 solving" libraries for Rails, which essentially try to manipulate `includes()` calls for you. I don't recommend them. IME, missing `includes` is only ~10% of the actual N+1s I see in the wild. And, includes() isn't always optimal!

Marco Roth on a generational run

As you're considering your charitable giving this year, here's the two organizations I've given to consistently for the last 3 years: 1. Nova Ukraine - humanitarian aid to the people of Ukraine 2. GiveWell - incredibly well-researched poverty/disease intervention

Datadog had no right to have the best browser RUM around, and yet, they have it. Every time I use the product I'm so happy with it. And then, it's integrated with everything else on the DD platform. Heaven.

I never, EVER accept LLM output without making it run code to verify what it did (tests, something more manual, whatever). Neither you nor your LLM can run code in their head. Do not trust, always verify.

Letting Puma auto-set your worker count is the easiest way to go for 90% of usecases. Currently, you can only do that with WEB_CONCURRENCY=auto, but we'll also make this possible in the next puma version by using `workers :auto` in your puma.rb.

If you are using Concurrent.physical_processor_count or Concurrent.processor_count to set your Puma/Unicorn worker counts, that is wrong. Use Concurrent.available_processor_count. It takes into account cpu quotas in envs like k8s/docker.

Tired: Repo github stars Wired: Repo contributor count

have you, too, been to so many conferences that you feel nostalgia for this?

Example of the kind of thing I'm doing more of now in the age of LLMs: A ~1000 line Ruby project for creating Datadog scorecards. A client had ~30+ microservices, but adherence to "platform" standards like "use jemalloc" was spotty. LLM did it in something in ~1hr.