At FastRuby.io, we offer specialized Rails upgrade, maintenance, and technical debt services.

Before doing an upgrade, we strongly recommend doing the Roadmap to Upgrade Rails, a static analysis of your codebase that outlines the action plan to do the upgrade and provides time and investment estimates.

The first step in every Rails upgrade we do is addressing deprecation warnings in the current version. So recently, we set out to extract all deprecation warnings from all versions of Rails starting at Rails 2.3 to help in our static analysis of Rails applications.

Having reproducible development environments is one of the best ways to guarantee ease of application setup and code sharing in teams. Dev containers are a way to achieve this.

In this article we’ll try to give you a small introduction to what dev containers are at their core and provide a minimal example on how to set up a Rails application to use dev containers.

In this article we will present compatibility between Ruby and Heroku across different versions. In the process of upgrading really old applications to more modern versions of Ruby we have run into a lot of these combinations.

In Ruby, we often want to rename methods or attributes for clarity, to extend functionality and for compatibility. However, there are three different tools for this, each with its own use case and behavior: alias, alias_method and alias_attribute.

In this post we’ll go over each one of them, what they actually do and when to use them.

Founded in 2011, Valid Eval provides a secure, SaaS-based platform that helps organizations make defensible, data-driven decisions in high-stakes situations involving many applicants, subjects, domain experts, and judges. The Denver, Colorado-based company primarily serves federal government agencies that need to evaluate complex bids before awarding contracts.

Aysan recently wrote about accessibility testing in Rails applications using your test suite to ensure that your application is accessible to all users.

However, you may not have a test suite in place or you may not have a Rails application, but you still want to test the accessibility of your web application, right? So, we discovered the WAVE Web Accessibility Evaluation Tools that can help you test the accessibility of your web application, regardless of the technology stack you are using.

Does this sound interesting to you? Let’s dive in!

Have you ever found yourself wondering how to best manage your database migrations in Rails? Migrations are a powerful tool for evolving your database schema, but without proper practices, they can become difficult to manage and even lead to inconsistencies between environments. In this post, we’ll cover essential strategies for keeping your migrations organized, efficient, and in sync across development, staging, and production, helping you avoid common pitfalls and maintain a clean, up-to-date database.

In earlier versions of Elasticsearch, types were a convenient way to categorically organize documents within a single index. However, types were eventually deprecated, pushing developers toward a type-less structure in Elasticsearch 7 and later versions. Recently while working on a project to migrate a Rails application from Elasticsearch 2 to OpenSearch 2, we faced the challenge of identifying a way to replicate this behavior in a way that is allowed with OpenSearch. In this blog we will discuss how types were used for document organization and how to achieve the same behavior in OpenSearch.

For developers, segmentation faults can feel like a sudden nightmare—cryptic errors that crash your application out of nowhere. This frustration is amplified when they show up in high-level languages like Ruby, where memory management is typically handled behind the scenes. Recently, while running my Ruby application, I experienced a segmentation fault caused by a gem. The crash not only halted my program but also left me facing a daunting debugging challenge. In this post, I’ll talk about how I identified the issue, debugged it, and eventually found a solution.

Many times, when looking at applications we have written or that we see around in repositories throughout the internet, we get this feeling that whatever we’re reading has a certain complexity too it. Sometimes this complexity is manegeable and expected. Sometime it’s not. Actually, very frequently, code can be difficult to understand and we usually describe such code as being overcomplicated, for example.

But it’s not just our understanding of written code that suffers. As expected, if code is more complex, it will also require more effort on the part of the computer to execute. And while efficient code might not necessarily be easy to understand, there is indeed such a possibility as code that is hard for humans to read and hard for hardware to compute.

However, in order to try to make things simpler and, especially, in order to coordinate within teams what is acceptable and what isn’t in terms of complexity, we need something that can help us measure complexity.

There are, of course, many metrics that can be used. In this article we’ll talk about cyclomatic complexity.

There’s abundant online guidance about refactoring controllers and keeping them lightweight, but resources on model refactoring are less common. In this blog, we’ll explore some techniques for effectively refactoring models.

In this post, we share our approach to refactoring Rails applications, focusing on improving code maintainability, reducing technical debt, and ensuring scalability. Discover the tools, techniques, and strategies we use to transform complex codebases into cleaner, more efficient systems.

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.