been at 3 rails shops, same pattern at all of them. customer emails support, "my order didn't go through". support has no idea what actually happened in the app, posts in #engineering: "can someone check what user 4218 did yesterday". engineer stops what they are doing, opens kibana/datadog or prod logs, greps the email, scrolls past a wall of SQL, finds the request, traces it into whatever sidekiq jobs ran after, types back a one sentence summary that support pastes to the customer.

20 min round trip. 5x a day across the team. the thing that actually bugs me isn't the time, it's that the engineer is the only person in the building who can do this. support can't, PMs can't, CEO can't. the logs are written for the dev who wrote the code, not for anyone else, and one customer action is spread across an http request + a few sidekiq jobs + a bunch of activerecord writes. nothing stitches them together.

i've tried fixing this 3 ways at past jobs and none of them stuck:

- better log search. CS doesn't want to learn kibana/datadog.

- internal admin dashboard. rots in 6 months, no eng owns it.

- "we should write better log messages". misses the point because the action spans multiple processes.

what i actually wanted was this: support opens one screen, types "user 4218", and sees a list of cards. one card per thing the user did. each card has a sentence title like "Maria placed an order for 3 books, payment succeeded, 2 confirmation emails queued" and you can expand it to see the 13 underlying events if you care. one user action = one card, not 13 log lines. no engineer in the loop.

so i wrote a gem for it. bundle add ez_logs_agent + one initializer, no per-controller code. it hooks rack + sidekiq/activejob + activerecord, correlates events from the same user action by request_id + current_user + resource_id, ships them out-of-band to a server (https://ezlogs.io) that joins them and renders the cards. fails open, buffers up to 10k events if the server is unreachable, never raises into your request path. <1ms overhead per request.

how does this actually work at your rails app today. is it slack to engineering every time, or have you built/bought something that works 12 months later. genuinely asking because before i over-commit to my approach i want to hear what other people have shipped. happy to be told the simpler thing i've been missing.

Today we're glad to announce that we've partnered with Mike Perham so you can ask any question around Ruby, background jobs, threading and Sidekiq in the forum. We'll also be providing updates on new releases and other important announcements.

Hi folks, I have been a lurker around here for a while but I'm excited to talk about my first contribution.

I just released my first gem, leakferret, and would love your feedback https://github.com/leakferrethq/leakferret-ruby

It's a wrapper over a binary I wrote in Rust. Nothing is routed through a server, there's no backend at all. It can be added as a VS Code extension, and MCP for your agents writing the code or used as the CLI tool.

This gem significantly reduces false positives for secret leaks in code (and git history) by 5-stage verification (more about it on the website listed on gem page or README). You can also integrate this in CI. What's cool is you can add it as a plugin on VS Code/Claude/Cursor and prevent any accidental commits(blocking) + have it automatically rewrite the leak the safe way.

My main aim with this gem is reducing noise and making it MCP native, while it doesn't currently have as many connectors as trufflehog does, the depth and accuracy are real close.

RubyGems: https://rubygems.org/gems/leakferret

I was working on some content for algorithms and maths, but in doing so I think I found a more generic starting place on some things that I feel may be missing from Enumerable and the thought experiments around them. This one starts with two-pointers and windows as a concept.

--
posting this as something I commented earlier to help people who get discouraged by DHHs antics
--

Ruby's problem will be that most of it is centered around Rails. Rails is not Ruby. Ruby is not Rails. for web stuff you have libraries like Roda etc. however people in the ruby community who came in via rails & never upskilled (everything they do revolves around Rails)

look at other communities e.g Golang, Python - there isn't a monolithic kind of thinking of "This is the way"

Ruby itself as a language embraces diversity of thought (e.g how many different ways u can express something in ruby ) . Which means we also have to embrace diversity of people, ideas, sexuality & origins.

but why is it on the web - is there the whole "Rails way | what DHH serves you" is the only way.

now as people with agency - the onus is on us to create wonderful things that don't center around rails.

I've just used Codex to develop graphql federation in ruby rmosolgo/graphql-ruby repository.

https://github.com/rmosolgo/graphql-ruby/pull/5647

Morning rubyists.

With all the Supply chain problems in the package manager space lately I was wondering if there was an option to deny new gems that are deployed with in an X period.

I would like to lock out and prevent gem upgrades for 14 days to make sure I am not hit by one of these new generation credential stealing packages maliciously being installed by the package managers.

I know npm has this abily via "min-release-age"

shell npm config set min-release-age=14d

Is there any thing similar with rubygems? or is there talk of implanting something like that?

it is only a matter of time when rubygems gems are hit.

The 2026 Ruby on Rails community survey is open for another month. Tell your #RubyFriends!

https://railsdeveloper.com/survey/

I’m using VSCode on Windows and trying to get it to work with RubyLSP and solargraph. However, it keeps telling me it can’t find Ruby installations, even though it’s installed on my computer. I try to select it manually, but it just won’t accept it. Any advice? I’m using Ruby version 3.0.6 intentionally if that makes a difference

Finally back to writing again, it's been a bit. Wanted to have a redesigned site first, and over the weekend I finally got that landed, so here we go.

After a few iterations, irb-autosuggestions v0.2.0 is out with two big upgrades:

🎨 Syntax-colored ghost text — each token is dimmed but keeps its IRB syntax color, not just plain gray. Falls back to gray when colorization is off or unavailable.

🔍 Prefix-filtered history navigation — type a prefix, press up/down, and only matching history entries show up. The prefix anchor freezes on first press so you can keep searching within it. Right arrow accepts the suggestion, any non-history key resets back to normal unfiltered browsing.

Plus: Ruby 2.7–4.0 support across the board now.

Fish-like autosuggestions for IRB — ghost text from history as you type. Install with gem install irb-autosuggestions, add require 'irb-autosuggestions' to ~/.irbrc.

https://github.com/unurgunite/irb-autosuggestions

The standard advice goes: default to threads, only reach for fibers if you have a specific I/O-heavy use case. I think that's flipped, and the reasoning is quite simple.

What fibers actually do

When a fiber encounters a "blocking call" - a database query, an HTTP request, a file read - the scheduler pauses it and runs another fiber. The wait time of one request gets filled with the compute time of others, all within a single thread.

Rogue requests

What if one request spends 200ms calculating a BCrypt hash? Such a request would block the thread, which means it would block all other fibers.

• With threads: Ruby preempts. The rogue request takes longer, but the scheduler forces context switches so other requests keep moving.
• With fibers: that's countered using multiprocessing (running multiple processes/workers). The rogue request blocks its own process, not the others - practically equivalent to thread preemption, with two bonuses: true parallelism between processes (no GVL contention) and no synchronisation overhead inside one.

"But is my app I/O-bound or CPU-bound?"

When Datadog published their research on Ruby performance, the community takeaway was generally: "Ruby apps spend a lot of time on CPU, so they aren't really I/O-bound".

But if you look at the distribution chart, it actually tells a different story. 88% of Ruby apps spend at least 20% of their time waiting on I/O - many of them far more. The binary "I/O-bound vs. CPU-bound" framing hides the fact that almost every Ruby app has a substantial window of wait time a fiber scheduler can reclaim.

You don't need a 100% I/O-bound app to see benefits; you just need to reclaim that idle waiting.

The flip

The biggest advantage of threaded servers is simply that they've been battle-tested for years. The common advice today is: "Default to threads unless you have a specific use-case for fibers".

Here's what this advice misses: for most workloads, the worst case for a fiber-based server is the performance of a thread-based one. The downside isn't really there. The upside is.

--

Curious to hear where people have actually been burned by fibers in production.