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 and Ruby on Rails 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 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 and Ruby 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.

In this article, I share my experience migrating from Sprockets to JS Bundling (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.

People focus so much on <h1> and alt attributes that they forget about usability.

Introduction

When discussing accessibility (a11y), we all focus on the structure of our <h1>/<h2>, the alt image texts, the contrast, and all the necessary rules to be covered. The problem is that during the process, we forget to think about usability: Is the page saying what it is supposed to be saying? Does the image description reflect what you can see there? Or take link text as an example: Does “Read More” explain what content the user is about to access?

Most of the time, usability is overshadowed by a focus on compliance with accessibility standards. As a result, we end up with a site that passes validation but neglects to measure usability… or worse, we don’t even consider it.

Last weekend I migrated my Doctor’s App from Heroku to Railway.

It’s a multi-tenant Rails app where each hospital gets its own subdomain, one.doctors.com, two.doctors.com, and so on.

Five hospitals, around 25,000 appointments, 9,700+ patients. Not huge, but not trivial either.

Here’s how it went, including the part where I accidentally broke the database.

For more than 8 years, we have been publishing detailed guides on how to upgrade Rails applications.

We have documented every minor version from Rails 2.3 through 8.1 in our Rails Upgrade Series and distilled our methodology into an ebook: The Complete Guide to Upgrade Rails

All of that knowledge comes from more than 60,000 developer-hours of hands-on upgrade work for companies of all sizes, from solo-founded SaaS products to huge Rails monoliths running at Fortune 500 public companies.

Today, we are making that methodology available to everyone as an open source Claude Code Skill: claude-code_rails-upgrade-skill.

For the past twenty years, TitleLeaf has been helping educational book publishers maintain and share their content with industry partners such as reviewers, wholesalers, and distributors. Its robust content management system and handcrafted digital solutions simplify the process of sharing metadata, digital assets, and marketing material for the book industry.

Here was the situation

Tim Peterson, Founder of TitleLeaf, is a solopreneur balancing the challenges of entrepreneurship with a flexible lifestyle. One of his dreams is to have more time and freedom to do what he enjoys most—skiing and biking in the mountains of Northern California while still running his company as efficiently as possible.

Peterson’s goal is to build an ever-evolving, feature-rich SaaS service and share his domain knowledge with customers without having to manage a team or chase technical updates:

“I got fed up chasing contractors and micromanaging. I tried hiring and outsourcing, but nothing was the right fit. I just wanted reliable maintenance so I didn’t have to worry about it.”

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 8.0 to version 8.1.

Last month, we finished a big upgrade for a client. The client had 2 main pain points for their app. The first one was that they were using Rails 2.3 LTS with Ruby 2.5. The next big issue was that the test suite took 40 minutes to run, blocking engineers from merging code into the main branch, and also slowing down the whole feedback loop for every code change.

After finishing the upgrade (we got the application to Rails 8.1.1 and Ruby 3.4.7), we focused our attention on improving the test’s speed and we reduced the time it took to run the whole test suite (over 10k tests) from 40 minutes to around 4!

Today is a sad day because last week a platform that we know, like, and trust made a surprising and disappointing announcement.

On February 6, 2026, Heroku published an update on the future of the platform. The announcement confirms what many in the community had suspected for a while: Heroku is transitioning to a “sustaining engineering model.”

In plain English, that means maintenance model: No new features, no new Enterprise Account contracts for new customers, and a focus on stability only.

If your Rails application runs on Heroku, this is the moment to start thinking about your next move. The platform is not disappearing overnight, but the direction is clear: Heroku’s best days are behind it and it’s time to migrate on your own terms to a provider that is not on maintenance mode.

Considering all this we are announcing a new productized service by FastRuby.io: Our Heroku Migration Service.