Application Performance Monitoring (APM) is a line item that may be approved for $2k/month, but can easily creep to over $6K/month during the course of the year. It shows up as a modest monthly subscription, gets buried inside an engineering budget, and then during the end of year reporting, someone asks why the bill tripled. In our current market state, looking into financial savings with your infrastructure can be a quick company win!

It is not that you are using the wrong APM (although we are happy to consult to see if your APM fits your business objectives). This is a story about how we often see unmanaged growth in APM use with our clients. APM costs do not spike because the software declined in performance. They spike because usage crept up quietly. There were more logs, custom metrics, environments, pricing driven spikes or usage spikes all without a clear monitoring infrastructure.

Rails 8.1 includes support for marking associations as deprecated right in your models. In this post, I’ll explain how the feature works, why it matters, and how you can use it to safely remove outdated associations from your application.

At OmbuLabs.ai, we’ve explored the importance of identifying meaningful AI opportunities opens a new window before selecting a solution. Once a worthwhile opportunity has been identified, however, a new question emerges:

Is this problem worth solving in the first place?

Too often, teams focus on the technology before evaluating the value. AI can automate tasks, generate content, and process information at incredible speed, but if the underlying work doesn’t matter, making it faster won’t create meaningful business outcomes.

Once a worthwhile opportunity has been identified, however, a new question emerges:

What should we build first?

At FastRuby.io, we always recommend that clients set up an Application Performance Monitor. It’s not just useful for our Tune Report Service, but good practice for visibility into server health, user experience, and more.

One concern that we sometimes hear is that the application may have really sensitive information about the users and it may not be possible to send the information to a third-party provider, or that a managed service can be too expensive. In this article, we are going to explore some open source solutions that can be self-hosted.

You may not be aware that, since Rails 7.1, the standard way to store secrets is by using credentials.yml instead of the old secrets.yml.

DEPRECATION WARNING:
`Rails.application.secrets` is deprecated in favor of `Rails.application.credentials`
and will be removed in Rails 7.2.

If you still see this warning, your app uses secrets.yml and the migration applies to you. If you don’t use Rails.application.secrets or config/secrets.yml at all, you can ignore the deprecation and the rest of this post.

The migration itself isn’t hard, but it can take some coordination: if your app runs in several environments, you’ll probably need to work with whoever manages your servers to move everything over. This post walks you through it, and explains why the change matters and what you gain from it.

Many Rails teams that we have worked with have a version of the same story: a test suite that grew organically, was never quite prioritized, and now sits somewhere between “unreliable” and “actively avoided.” Maybe tests are slow. Maybe they’re flaky. Maybe coverage gaps makes deployments feel like a roll of the dice. Or a manual battle against a behemoth of a beast. It is likely you have heard engineers gripe about the test’s reliability and may be worried that they are sinking time in the application.

Improving your test suite is one of the highest leverage investments a development team can make even though it’s often deprioritized. While the benefits are not always obvious to those that approve budgets and sign contracts, issues related to the test suite can become a sifon of time, budget and team energy. Optimizing your test suite requires critical knowledge of the application and its business functions that require management and direction from experienced engineers, especially if leveraging AI models.

This article shows the compatibility between Sidekiq opens a new window and Rails opens a new window across different versions. Even though Rails is not a dependency of Sidekiq, there are compatibility considerations for different combinations given that Sidekiq provides integrations with Rails.

Writing effective test cases is as important as writing the business logic in your application. This blog post dives into the simple yet effective ways developers can use when crafting test cases.

This is a short post to show the compatibility between JRuby opens a new window and Ruby on Rails opens a new window across different versions. JRuby is an implementation of Ruby that runs on the JVM, so picking a version means lining up four things at once:

• JRuby release
• Ruby version
• Minimum Java version
• Rails version

The Asset Pipeline has had many changes over the years, from not needing NodeJS when using Sprockets, to supporting NodeJS to manage JS dependencies through npm packages, to requiring NodeJS by default with Webpacker, and to not needing NodeJS by default again with ImportMaps.

ImportMaps is a good way to not have NodeJS as a dependency of the application, but it has many limitations (like the lack of TypeScript support) and it requires a lot of work to migrate to it when upgrading older applications.

In this blog post, we will see how to use Bun to remove the need to install NodeJS system-wide, how to use the standalone binary to not require an installation step, and at the same time keep using npm packages as needed to make the transition easier.

Waiting over an hour for a test suite to finish is a productivity killer.

On a recent project, that was our reality.

Running the full local RSpec suite took almost 2 hours, making it difficult to get quick feedback and confidently iterate on changes. While there are many ways to optimize test performance including fixtures, request stubbing, faster tooling, and more, most of these options require significant effort to implement.

Instead, we explored a simpler approach: bringing parallel test execution to local development. The result was a much faster feedback loop (down to 5 minutes) and a significantly better developer experience.

It’s common for Rails applications to serve massive CSS files filled with unused Bootstrap, Tailwind, or custom utility classes as projects grow. This bloat isn’t just a developer annoyance—it has a real impact on your users. Every unused kilobyte adds milliseconds to page load time. In this post, we’ll explore what PurgeCSS opens a new window is and how your Rails project can benefit from it.

Imagine this scenario: a developer added a pub/sub gem built on top of Sidekiq to handle background event broadcasting in your company’s Rails app. At the time, it was a huge win: instead of building a custom job orchestration system, they could drop in the gem, wire up a few events, and ship a feature in days instead of weeks.

Fast forward a few years: Sidekiq needed an update. You find out the gem wasn’t actively maintained anymore. But by then, the entire application depended on it. Core features like sending notifications, syncing with third-party APIs, and triggering billing logic all ran through this pub/sub layer.

Now you face a painful choice: either keep running on an unmaintained gem and risk breakage every time Sidekiq or Rails is updated, or rip it out and refactor the app to use a supported approach.

What began as a new dependency to save time has turned into a critical piece of fragile infrastructure. The lack of maintenance has turned what should have been a simple dependency update into a full-blown project.

How do we avoid getting into this situation in the first place? In this post, we’ll show you by digging into five critical areas to check before you choose a new gem.

This is a short post to show the compatibility between Sidekiq opens a new window and Ruby opens a new window across different versions. In the process of upgrading really old applications to more modern versions of Ruby and Sidekiq we have run into a lot of these combinations.

At FastRuby.io, we spend a lot of time upgrading Ruby and Rails applications. However, we do more than just that, we also pay attention to other areas of the application that can be improved. For example, we recently migrated a customer’s application from Sprockets to JS bundling with esbuild opens a new window .

In this article, I share my experience migrating from Sprockets opens a new window to JS Bundling opens a new window (JavaScript Bundling for Rails).

This is not a step-by-step guide, as each application has its own unique needs. Instead, I discuss the problems I encountered and the approach I took during the migration to JavaScript bundling.