Transcript:

Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll be taking a look at the derailed_benchmarks gem, and how you can use it to benchmark your Rails application and find, and hopefully fix bottlenecks in your code.

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 5.0 to 5.1.

Today we are happy to announce the launch of our new microsite: Gemfile.lock Audit Tool - a tool created to allow users to check their Gemfile.lock for vulnerabilities in a quick and secure manner.

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.2 to 5.0.

We recently collaborated with Power Home Remodeling on a Rails upgrade for their self-described “monolith CRM/ERP application” and were able to speak to them about their experience with OmbuLabs.

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.

When working on a Rails project, you may have seen present? calls on ActiveRecord relationships. This might feel natural, mostly because present? exists on all objects via ActiveSupport, so you expect the relationship to respond to it, but it’s actually not a very good idea. If all we want to do is check if the scope returns any results from the database, there are better ways than using present?.

A few weeks ago, I noticed weird output in the RSpec test suite (~4000 tests) for a Rails application:

.............................................................................................unknown OID 353414: failed to recognize type of '<field>'. It will be treated as String  ...........................................................................................................................................

This Rails app uses a PostgreSQL database. After some Googling, it turns out that this is a warning from PostgreSQL. When the database doesn’t recognize the type to use for a column, it casts to string by default.

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.