Most Rails developers have crossed paths with Rake opens a new window (usually to run a migration, seed a database, or clear out test data). If you’re like me, you may have quietly filed Rake away under “that place where Rails keeps database tasks.” But Rake is far more powerful than that.

It isn’t just a Rails helper: it’s a full-blown, general-purpose build system, sitting quietly in your project, ready to automate almost anything. And the best part? It speaks Ruby. That means, as a Rails developer, you’re already fluent in the language your build tool understands. In this post, I want to open your eyes to the wider world of Rake, beyond migrations and seeds, into using it as a central hub for building, scripting, and orchestrating your entire workflow.

Today I’m excited to share a new open source project: A Claude Code skill to assess technical debt in a Ruby on Rails application. It leverages some of the libraries that we have open sourced and maintained for a long time.

Over the years, we’ve written about many of the tools we use: Skunk opens a new window for combining code quality and code coverage data, bundler-audit opens a new window for security vulnerabilities in your dependencies, libyear-bundler opens a new window for measuring dependency freshness in a Ruby application, and RubyCritic opens a new window for churn vs. complexity analysis.

The challenge? Running all these tools manually takes time and interpreting the results across multiple reports can be tedious.

What if we could automate the entire audit process and generate a comprehensive report with a single command?

In this article, I’ll show you how we built a Claude Code skill that does exactly that, in minutes!

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 opens a new window , 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 opens a new window 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.