Articles by Mateus Pereira

Over in the OmbuLabs.ai blog, our post on the ReAct pattern in Ruby opens a new window walked through building an agent that reasons about a task, calls tools, and acts on the results, all inside a single Ruby script. That’s fine for a command-line experiment. It’s a different story once that same agent needs to run inside a Rails app, triggered by a web request, where a multi-step reasoning loop can easily take longer than any request should stay open.

The obvious fix is to move the agent into a background job. Sidekiq already handles work that takes a while, so an agent’s loop of thinking, searching, and acting should fit right in. It does, mostly, but a job’s retry semantics were built around retrying a database write, not a chain of API calls that has real, sometimes irreversible, side effects.

In this article, you’ll learn why an agent’s reasoning loop doesn’t survive a naive move into a background job, how to make its side effects idempotent against Sidekiq retries, and how to stream its progress to the user while it runs.

Here at FastRuby.io we work with test suites and test coverage reports every single day, given our specialty. In the Ruby world that means we interact with SimpleCov every day. Not only that, we explicitely rely on SimpleCov reports in two of the open source projects we maintain, RubyCritic opens a new window and Skunk opens a new window .

Which is why, after more than a decade at 0.x, we were super excited to see SimpleCov opens a new window ship its first stable release on July 12, 2026. In this article we’d like to share the details on the breaking changes, the deprecations and how to address them, if you’re impacted by them.

For anyone that has ever used RubyCritic, churn calculations were always painful. Especially for projects with commit histories going back to when YouTube was mostly cat videos.

Here I’ll relate the story of how we were able to make churn calculations cut down from 30 minutes to just a few seconds or 4 or 5 minutes at worst.

Having reproducible development environments is one of the best ways to guarantee ease of application setup and code sharing in teams. Dev containers are a way to achieve this.

In this article we’ll try to give you a small introduction to what dev containers are at their core and provide a minimal example on how to set up a Rails application to use dev containers.

In Ruby, we often want to rename methods or attributes for clarity, to extend functionality and for compatibility. However, there are three different tools for this, each with its own use case and behavior: alias, alias_method and alias_attribute.

In this post we’ll go over each one of them, what they actually do and when to use them.

Many times, when looking at applications we have written or that we see around in repositories throughout the internet, we get this feeling that whatever we’re reading has a certain complexity too it. Sometimes this complexity is manegeable and expected. Sometime it’s not. Actually, very frequently, code can be difficult to understand and we usually describe such code as being overcomplicated, for example.

But it’s not just our understanding of written code that suffers. As expected, if code is more complex, it will also require more effort on the part of the computer to execute. And while efficient code might not necessarily be easy to understand, there is indeed such a possibility as code that is hard for humans to read and hard for hardware to compute.

However, in order to try to make things simpler and, especially, in order to coordinate within teams what is acceptable and what isn’t in terms of complexity, we need something that can help us measure complexity.

There are, of course, many metrics that can be used. In this article we’ll talk about cyclomatic complexity.

In a previous article opens a new window , we listed down common culprits that led to a sub-optimal performance in Rails applications. One of the culprits was missing or incorrect indexes.

Therefore we thought it would be very useful to have a handy reference to the different kinds of indexes, when you should use them and maybe even when not to use them.

Here at FastRuby.io we always try to have our own applications in such a state that they can always be pointed to as models in terms of performance and accessibility.

One of the tools we use to achieve that is our CDN. After all, considering we have clients everywhere from the US to New Zealand, we want anyone perusing our websites to have good loading times for the pages and, especially, the assets.

However, no matter how thorough, one always misses a spot or two.

Recently, Robby Russel posted opens a new window posted on Twitter asking for Heroku alternatives for small Rails apps. Since it got quite a bit of traction, I decided to explore some options and post my experiences as blog posts.

For my first post, I’ll go for one that I’ve already used in the past and liked it very much: Fly.io

I like them because they’re dead simple and have great docs. The dashboard is pretty good too, but since I’m not one to have too many requirements around my apps, the simplicity of use is what I like the most.