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.

In a previous post, we discussed the importance of assessing an application’s dependency freshness and demonstrated how you can use different tools for this purpose. One of these tools is libyears. In this post, we’ll share the libyears calculations for several popular Ruby projects and discuss our findings with you.

Technical debt, a term coined by Ward Cunningham in the 1990s, refers to the trade-off between short-term gains and long-term consequences in the development process. In this article, we will explore what technical debt is, why it happens, why you should care about it, and discover some new tools to help you discover the technical debt in your Rails applications.

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

Hanami is a modern web framework which is looking for new ways to build maintainable, secure, faster and testable Ruby applications. This is a short post to show the compatibility between Hanami and Ruby across different versions.

Ruby on Rails is a powerful web application framework that has evolved over the years, with new versions bringing in features, improvements, and security updates. As your application matures, keeping it up-to-date with the latest Rails version becomes crucial. However, the prospect of upgrading an entire Rails application can be daunting. In this blog post, we’ll explore whether it’s possible to upgrade your Rails application in increments and how to go about it.

In software development, there are instances where creating a long-running branch when working on a project will be considered by developers. Long-running branches have been debated a lot by many teams due to their risks mainly around but not limited to, dare I say it, merge conflicts.

However, it isn’t necessarily the evil it’s made out to be and when handled with care, they can present extreme value to a team. Even DHH argues the benefits of maintaining a ‘cohesive architecture’ in this article

Need help executing a GitHub Actions workflow for your Rails application, especially when dealing with a MYSQL database? Whether you’re just starting or transitioning from another CI service, navigating potential pitfalls can be challenging. If you’ve found yourself nodding along, then this blog post is tailored just for you.