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?

oddgoo@viriditax.bsky.social · 6mo ago

I love that ppl get handed tools like Claude Code and immediately get extremely busy spinning hella agents to make…extremely bespoke fragile implementations of anal retentive productivity suites and agentic harnesses

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

George Pearkes@peark.es · 6mo ago

I am less knee-jerk “won’t watch anything with AI” than this site tends to be but this objectively looks terrible on screen. Just really bad. No thanks.

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.

Benjamin Borowski 🍁@typeoneerror.com · 6mo ago

Bro, I might just self-cull and wander off into the woods.

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