All Articles

This article is part of our Upgrade Rails series. To see more of them, click here opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 5.1 opens a new window to 5.2 opens a new window .

Transcript:

Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll be taking a look at the derailed_benchmarks opens a new window 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 opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 5.0 opens a new window to 5.1 opens a new window .

Today we are happy to announce the launch of our new microsite: Gemfile.lock Audit Tool opens a new window - 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 opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 4.2 opens a new window to 5.0 opens a new window .

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

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 opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 4.1 opens a new window to 4.2 opens a new window .

This article is part of our Upgrade Rails series. To see more of them, click here opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 4.0 opens a new window to 4.1 opens a new window .

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

A previous post opens a new window 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 opens a new window 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 opens a new window . We will be covering the most important aspects that you need to know to update your Ruby on Rails opens a new window application from version 3.1 opens a new window to 3.2 opens a new window .

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

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

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 opens a new window , 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 opens a new window test suite (~4000 tests) for a Rails opens a new window application:

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

This Rails app uses a PostgreSQL opens a new window 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.