This article takes a look at some of the changes to the ActiveRecord::Dirty module between Rails 5.1 and 5.2.

If you’re running Rails 5.1, you may have already seen some of the deprecation warnings related to the API changes contained in it. Most of them are behavior changes, and there are some new additions as well.

To better understand these modifications, we’ll take a look at sample projects in Rails 5.1 and Rails 5.2.

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 4.1 to 4.2.

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 4.0 to 4.1.

This article is part of our Upgrade Rails series. To see more of them, check our article title The Rails Upgrade Series.

A previous post covered some general tips to take into account for this migration. This article will try to go a bit more in depth. We will first go from 3.2 to 4.0, then to 4.1 and finally to 4.2. Depending on the complexity of your app, a Rails upgrade can take anywhere from one week for a single developer, to a few months for two developers.

This is part of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 3.1 to 3.2.

This is part of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 3.0 to 3.1. If you are in an older version, you can take a look at our previous article.

This article is the first of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 2.3 to 3.0.

Rails is a powerful framework. You can write a lot of features in a short period of time. In the process you can easily write code that performs poorly.

At OmbuLabs we like to maintain Ruby on Rails applications. In the process of maintaining them, adding features and fixing bugs, we like to improve the code and its performance (because we are good boy scouts!)

Here are some tips based on our experience.

Prefer where instead of select

When you are performing a lot of calculations, you should load as little as possible into memory. Always prefer a SQL query vs. an object’s method call.

There are already quite a few guides in the wild to help with the upgrade of Rails 3.2 to Rails 4.0.

The official Rails guide for upgrading from Rails 3.2 to 4.0 is very thorough. With the recent release of Rails 5.0, apps currently in production running Rails 3.2 should probably be updated to any stable Rails 4 release as soon as possible.

There is even an e-book about upgrading from Rails 3 to 4, which serves as a useful guide to make this upgrade easier, and also helps understand the advantages & disadvantages of this new (soon to be old) version.

However, if you’re using any non-standard gems, you’re mostly on your own. Some gems stopped being maintained before Rails 4 was released, as was the case with CanCan, a well known authorization library. After many open pull requests were left unmerged, CanCanCan was released. It is a community driven effort to have a semi-official fork of CanCan. It serves as a drop-in replacement for people who want to use CanCan after upgrading to Rails 4.