Zeitwerk is the code autoloader and reloader that was integrated with Rails 6. Beginning in Rails 7, it will be the only codeloader option. As a result, upgrading to Zeitwerk will be an important step in getting your application ready for the next version of Rails. In this article, we’ll talk about upgrading your Rails 6 application from classic to zeitwerk mode.

In case you are not familiar with us, FastRuby.io specializes in Ruby and Rails upgrades. Over these past 10 years we have had the opportunity to perform dozens of upgrades for our clients, which has given us all sorts of experiences. A common scenario that we experience is when the upgrade isn’t straightforward and we can’t just upgrade the Ruby or the Rails version directly.

We often find ourselves in a situation where we need to upgrade one or more dependencies before we can actually upgrade Ruby or Rails itself. For instance, if your want to upgrade your app from Rails 5.x to 6.x and the application still uses Paperclip to manage your file attachments, first you’ll need to replace that gem because Paperclip was deprecated in favor of Active Storage after Rails 5.2 was released.

This was the case for one of our clients that has been doing upgrades with us for a few years now. In this article I’m going to share the mishaps found by the team and the strategy that we adopted to migrate their huge volume of attachments over to Active Storage while still keeping Paperclip active until the migration was finished.

In this article we will discuss and demonstrate how we can use Ruby to encode UUIDs into URL friendly representations. This article does not assume any previous knowledge about UUIDs. Instead we will first discuss what exactly a UUID is. We look at all the reasons we would prefer using UUIDs over conventional incremental integers.

You can look forward to some binary math and adding a simple but effective encoding algorithm to your tool belt.

We are excited to share a new gem for the Ruby community: dotenv_validator! A library that will help you validate that the values in your environment are valid according to the comments in your .env.sample file.

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 6.0 to 6.1.

Ruby 3.0 was released on December 25th 2020. We can now enjoy the great new features of this version, such as performance boost (we talked about that in this recent article), ractors for concurrency, fiber schedulers, and type checking.

If you already have an application running in production and want to be able to use such benefits you’ll need to upgrade your Ruby version.

This article will cover the most important aspects that you’ll need to know to get your Ruby application from version 2.7 to 3.0

I’m seeing a lot of disappointment about the speed of Ruby 3 out there. I think there are a lot of reasons for that, and I think they’re worth looking at.

So: why wasn’t Ruby 3 faster? Did it break its promise? (Spoiler: I don’t think so, but I understand why some people do.)

One of the steps we recommend taking when doing an upgrade for any Rails version is to dual boot the application with your current Rails version and your next rails version.

This is important because it allows you to quickly run the test suite for both versions, having dual booting available allows you to debug and also revert to your current version in a much simpler fashion.

However, sometimes changes that you make for the new version of Rails may not be compatible with your current version of Rails. This means that you will need to use a few different techniques to get both versions to be able to use the dual booting and run smoothly.

If you’ve been following me awhile, you know that I was hired by AppFolio years ago to measure Ruby 3’s performance, especially on Rails. This has been a long trip. And that very first project is finally over: Ruby 3 exists and I can check its final, released Rails performance.

If you have been following along, the numbers in this post won’t surprise you. But it’s important to do the final measurement. If you haven’t been following, this will bring you up to date.

Welcome to our series of Rails upgrade miniguides. Here you’ll find links to all of the relevant posts to help with an upgrade.

Sometimes you will be caught between a rock and a hard place. For example: You really need to upgrade your Rails application because Heroku is discontinuing your stack in two weeks so you don’t have the time to write an entire test suite.

Sometimes the situation will be that your boss really needs you to upgrade Ruby or Rails to use a version that gets security updates and they won’t allow you to write tests beforehand.

This article will explain how to ship a Rails upgrade project without a test suite. If your application has no tests, you will learn how to upgrade without having to write tests first.

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 prepare your Ruby on Rails application for working on an upgrade.

If you’re a developer you know the reasons why you should be using the latest Rails framework. You understand the implications of performance gains, dependency issues and unsupported versions.

But these big picture benefits get lost in translation when talking to non-technical executives. What they need to know is the business case for an upgrade, how the work will translate into increased revenue.

So, here is an article to use or forward to communicate why an upgrade should be a priority. We also wrote an article on the more technical reasons if you are interested.

Ruby 3x3 is coming in about a month. One of its new concurrency primitives is Ractors, which used to be called “Guilds.” (The other new concurrency primitive is Autofibers.)

Ruby has a Global VM Lock (GVL), also called the Global Interpreter Lock (GIL), that prevents running Ruby code in more than one thread at once. So Ruby threads are great for I/O like waiting on files or databases. And they’re great for cases where a C extension can keep calculating in a background thread while a foreground thread runs Ruby. But you can’t do calculations in Ruby in more than one thread at once within the same process.

At least not until Ruby 3 and not without Ractors.

Great! Now how fast is the current implementation of Ractors?

When upgrading a Rails application, you might find that sometimes functionality is extracted from Rails and moved into a new gem. These gems are called shims, and they will basically allow you to keep using an old functionality, once the core API takes that out. You can also find shims in form of monkey patches. In this case it’s functionality that you develop to make your migration easier.

In this article I will list some of the functionality of past versions of Rails that was extracted into gems.