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 7.2 to version 8.0.

Diving into an existing Rails application for the first time can feel a bit overwhelming, especially when you’re trying to piece together how everything works. In this article, we’ll walk you through the process of truly understanding (or grokking) an existing Rails app for the first time.

When upgrading from Rails 3.0 to 3.1, one of the common issues we face is the breaking change in ERB syntax for helper methods. This change impacts form_tag, form_for, content_tag, javascript_tag, fields_for, and field_set_tag.

The main issue is that these helper methods in Rails 3.1 now require the use of <%= %> to output content, whereas in Rails 3.0 (and earlier), they used <% %> without needing to explicitly output the form content. This change is not backward-compatible, and applying it across a large codebase can be quite tedious when we are using our method of dual booting an application to do an upgrade.

In this article we will explore a few possibilities we have uncovered in the past few years while doing these upgrades.

Today I’m happy to share that RailsBump is now being supported and maintained by our team. I wanted to take a moment to explain why this project is so important to our mission of reducing technical debt in our internal, open source, and clients’ applications.

The other day, I was setting up a client project when I came across this dreaded error when running bundle install:

Gem::Ext::BuildError: ERROR: Failed to build gem native extension. 

Have you ever gotten this error and spent hours of your day trying to install the missing gems? In this article, learn why this error occurs and how to solve it for good.

These days, maintaining a secure codebase is crucial. Vulnerabilities in your application’s dependencies can pose significant risks to the security of your application. This is where tools like bundler-audit come into play. bundler-audit is a gem that helps you identify and manage security vulnerabilities in your Rails application’s external dependencies. In this article, we will explore how to use bundler-audit to keep your Rails codebase secure.

Ruby on Rails has a new maintenance policy and it can be a bit confusing as to what it means for both new and existing Rails projects. In this blog, we are going to summarize all the details, changes and important dates to help your team plan your next upgrade.

Let’s take a look!

While working with a client, we noticed that they had two Gemfiles: one with gems specifically for development and local references to a gem, and the other with a reference to a resource on GitHub. They wanted to switch between the local installation of the gem and the external GitHub reference based on whether they were in development or production. This approach worked well for their needs; however, our team was concerned that one downside was the difficulty in maintaining two separate Gemfiles. In this article, we will discuss an approach to creating conditional Gemfiles for development.

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 7.1 to version 7.2.

In a previous blog post, How Do You Know When Your App is Not Compliant?, I briefly discussed the importance of the accessibility standards of Web Content Accessibility Guidelines or WCAG, to ensure that everyone, including those with disabilities, can use web applications effectively. In this blog, we are going to further explore the importance of maintaining accessibility compliance, what it means to users, as well as how to use the axe-core-gems for automated accessibility testing to help identify and resolve any gaps that may be currently present in a project.

As of August 2024, Ruby 3.4 has not been released yet, although the Ruby Core team is working on it and continues to make progress on enhancements and refinements so our ruby apps can have the best performance. In this blog post we will talk about an interesting discussion happening about the # frozen_string_literal comment at the top of Ruby files.

Did you know that we love using the Dual-Boot technique for our Rails upgrades? We rely on the next_rails gem to help us with dual-booting our Rails applications. This gem does more than just enable dual-booting; it also helps us identify outdated gems, check Rails compatibility, find the minimum compatible Ruby version for a target Rails version, and more.

Sounds interesting? Keep reading to learn more about the features of the next_rails gem.

Managing technical debt is a huge concern for businesses of all sizes. At FastRuby.io, we understand the challenges of maintaining a healthy codebase while continuously delivering value to your users. That’s why we’ve introduced Bonsai, our fixed-cost, monthly maintenance service tailored to gradually alleviate technical debt. Join us as we take a deep dive into the value Bonsai brings to the table over the course of a month.

This guide is for you if you have an internal gem and you don’t know if you need to upgrade it or don’t know what steps to take to upgrade it. We’ll cover everything you need to know in this post about upgrading internal gems.

When building a Rails application you will need to think about scaling as you get more and more users and data. One way in which your application may need to scale is at the database level. Rails supports using multiple databases, so you don’t have to store all your data in one place.