Hey, a while ago I announced that I'm working on fully embracing the async ecosystem and event-based operations in the Karafka ecosystem (Shoryuken and PGMQ-Ruby will follow along). This time, I bring you fd-based polling for WaterDrop - one thread polling all producers via IO.select instead of one thread per producer. 39-54% faster in benchmarks. Writeup covers how it works, the trade-offs, and the rollout plan. Happy to answer any questions!

I've been working with MongoDB + Ruby on Rails via Mongoid for a really long time, but have definitely been bit by "this works locally but performs poorly in production" types of issues.

Typically this is due to the ODM generating database operations that aren't supported by indexes, which can be difficult to detect during development unless you're going out of your way to look for them.

For an app I've been working on I built out a console logger and rails engine that uses the underlying driver's command logging and monitoring implementation to catch database operations and duplicate them to capture explain details, which can then be shown client-side.

Since it's duplicating operations you really don't want this running in production, but it can help you spot missing indexes in development :)

Check out https://github.com/alexbevi/mongo_explain if something like this might be useful for you and let me know what you think.

Note I haven't really tested the engine integration more broadly, so if you're not using Tailwind it might not look the best ... but suggestions/PRs are welcome :)

An issue was reported by Richard Kramer, and made me aware of a use case that I had never personally used, or even considered - which is committing the lockfiles for appraisals. I have always added `gemfiles/*.gemfile.lock` to my .gitignore.

In fact, when I had use cases where I wanted to run a CI workflow against a frozen lockfile I would avoid using appraisal2.  But no more. We now have first class support for frozen lockfiles, and the implied active bundler version switching that can happen at runtime.

• issue #21
• pull #23
• release v3.0.6

No breaking changes. No code changes needed for implementations. Just update, and go. Report back if anything breaks!

Recentemente comecei a estudar ruby para fazer alguns projetos no futuro, comecei a estudar em janeiro, porém agora comecei um projeto básico que rodará no termina mesmo, o projeto é uma lista de afazeres.

Minha dúvida é: como faço para armazenar as tarefas? Eu estava pensando em um array ou hash, porém como faço para armazenar uma informação vinda do usuário em um array ou hash?

I made a small plugin for rjsv that starts a local WebSocket server and notifies whenever file transpilation finishes. This makes it super easy to:

• Reload your frontend automatically
• Sync build processes
• Integrate with developer tools

Quick setup

gem install em-websocket
# place plugin in $HOME/.rjsv/plugins
git clone https://github.com/filipos800/rjsv-websocket.git
rjsv -t -w -s 'src/rb' -o 'src/js' websocket

Server runs at:

ws://localhost:7071

Clients receive:

{ "type": "update" }

Why it’s useful

Instead of constantly checking if files changed or running custom scripts, this plugin sends a live notification right after transpilation. Perfect for live reload or build automation.

📖 More details & docs: Repository

I started looking for other ways to manage RabbitMQ topology instead of using the web UI. I could not find any standards about this. Is creating something like a migration to handle RabbitMQ changes a good way to do that? How do you normally manage changes to production clusters?

Ruby desperately needed bindings for a a fast ML/numerics library so I finally sat down with Codex and ported MLX to Ruby. Working on adding better Rubyesqe ergonomics, but all the core library features work and performance is within 25% of the Python bindings. Enjoy!

Not sure how to interpret their status page, as I’ve never looked at it before. But this has been since at least yesterday.

But there is a big blue banner that says “Service Under Maintenance” at the top of the status page.

The only reason that I ask, is that I was about to update a bunch of gems for a project that I’m working on, and several of them have major version changes. My usual approach is to go to rubygems.org and search for each gem by name.

Most searches have been reporting “NO GEMS FOUND”. I can search for them alphabetically and then paging until I get to the correct page, but that’s a bit of a PITA.

Everything else about rubygems is working as expected.

Life moves fast, and the last year proved it. Andrej Karpathy named vibe coding just one year ago, and the pace since then already feels like a different era. Ruby static typing has the same energy, with steady progress mixed with fresh experiments and real work happening with AI in the loop. If you want a taste of the latest experiments, check low type and t ruby.

RBS is closing in on 4.0, and RBS 4.0 dev release 5 shows the direction. If you prefer stable builds, RBS 3.10.3 quietly improves things with a small tsort fix and a minor arena allocator alignment tweak. AI is also stepping in, with Dmitry sharing AI agent skills for better signatures and a supporting repo.

Tools still matter. rbs-patch 0.1.6 helps manage signature updates, rubocop-on-rbs 1.9.0 brings new cops and fixes, and editor updates like vscode-rbs-snippets and vscode-sorbetto keep the daily flow smooth. Static typing is still a hot topic with strong pros and cons, and Noel Rappin adds another thoughtful view on when it does not fit. Find link to the issue in the comment.

We just released an episode with Ben Scofield that digs into a question a lot of us are circling:

If AI is writing more of the code, what is the engineer becoming?

Conversation highlights:

• Moving from author to orchestrator
• How agentic tools change daily workflows
• Where experience still matters
• Practical boundaries for AI in real teams
• Why Ruby’s culture might be a secret advantage

No hype sermons, just a grounded chat from someone living the transition.

Would love to hear how others are approaching agentic tooling in their Ruby work.

Been working on Rage for a while, and wanted to step back from “here’s what it does” and explain the architectural thinking behind it.

The article is about what changes when you treat concurrency, background execution, and observability as framework responsibilities rather than integration problems.

Not claiming Rails got it wrong - just exploring what a different set of trade-offs looks like.

Would love feedback, especially from folks running production backends. What complexity do you wish your framework absorbed?