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.

Rails Engines are an architectural pattern that can be used to modularize a Rails application. They are self-contained applications that can be mounted within a larger Rails application. In this post, we will dive into the world of Rails Engines and explore what they are, how to create them, how to use them, when to use them, and why they are important.

You might have extended classes or instances in Rails, but do you know you can also extend Rails associations?

class Account < ActiveRecord::Base
    has_many :people, -> { extending FindOrCreateByNameExtension }
end

In this article I’ll discuss a strategy for different readability: a simple way to split your routes file on a Ruby on Rails project.

Let’s begin with a simple question:

Have you seen config.load_defaults 6 in any application?

6 is an argument and could vary, I’m just giving an example.