Back in 2011, Rails 3.1 introduced The Assets Pipeline opens a new window feature using the Sprockets gem opens a new window . This made it really easy to handle assets (images, fonts, JavaScript, CSS and more), solving many of the issues that developers had to face everyday.

In 2012, Webpack opens a new window was released solving the same issues in a different way and in time became the most used solution to handle assets. And since Rails 6, Webpack became the default solution to handle JavaScript assets using the Webpacker gem opens a new window on new Rails applications.

In this article I’ll explain the steps we took to migrate to Webpack to handle our JavaScript assets, and how we added support as a node module in our styleguide opens a new window .

Do you ever look at the list of Amazon EC2 instance types? opens a new window . Those are sizes of virtual machine you can rent to run your code on. Well, okay, they’re groups of sizes, since each one of those headings has a bunch of different sizes of VM…

So what type of EC2 instances should you run your Rails app on?

The answer is simpler than it looks.

Do you love numbers? I love numbers. Do you hate numbers? Skip to the bottom, there’s a nice summary paragraph. Do you really really love numbers? There are raw data dumps opens a new window including all my intermediate results.

When inheriting a project or starting an upgrade, it is useful to understand how big and complex the application really is. So, what is a good way to understand whether a Rails application is tiny, medium, or huge?

The good news is that there are a couple of gems that make this easy for us.

In this article I will explain how you can use these gems to begin to understand the size and complexity of a Rails application.

The new Ruby 3.0 preview opens a new window is out! Woo-hoo!

If you’ve heard of me, you know performance is kinda my thing opens a new window , especially Rails performance on large apps opens a new window . I do other stuff too, but I got paid to do that for years (thanks, AppFolio!), so I’ve written a lot about it.

How does the new preview’s performance stack up on Rails? And how reliable are these numbers?

At FastRuby.io we are constantly looking at code coverage metrics for Ruby on Rails applications. It’s a key indicator for us. We even use that information to decide whether we work on a Rails upgrade project or not opens a new window .

So, I was interested in seeing code coverage metrics for the Ruby on Rails framework opens a new window . I couldn’t find any information about this online, so I decided to generate a few reports for each component.

This is an article about my process and my findings.

Having a clear idea of how much test coverage your Rails application has is really important. Especially if you are planning to upgrade to a newer version of Rails. A good test suite will tell you if your application is working as it did before the upgrade.

At FastRuby.io opens a new window , we recommend having at least 80% of your application covered before attempting to upgrade. A number lower than that would require you to make a lot more manual testing to ensure that the application is properly working after the upgrade. If your application doesn’t meet that number, we suggest to first spend some time improving the test suite before starting the upgrade.

In this article, I’ll show you how you can measure your test coverage using SimpleCov opens a new window .

A quick note before starting: SimpleCov doesn’t work in projects with Ruby 1.8.7 or lower. If that’s your case, you can try rcov opens a new window .

Contributing to open source projects is a big part of our philosophy at OmbuLabs opens a new window . It’s even written into our values opens a new window . Some of us like to contribute to open source even in our spare time!

Recently we have been thinking about what guidelines we should follow when starting a new open source project, and also about how to organize and keep track of the ones we contribute to.

This article will give you some tips on keeping those open source projects organized, and also how to start them off on the right foot.

We recently collaborated with Procore opens a new window on a Rails upgrade opens a new window for their Rails application which allows teams in the construction industry to connect their entire business process.

We spoke with Andy Maltun, Procore’s VP of Software Engineering, about the work performed to help them upgrade their app to version 5.1. According to Maltun, Procore’s R&D department is large and complex. While Procore opens a new window previously had handled their Rails upgrades internally, with so many teams working on the application, it caused a lot of disruption as each team would handle only part of the upgrade. Therefore, Maltun “wanted to take a different approach this time in an effort to centralize the update and minimize the project management overhead and disruption of teams.”

Rails upgrades can be done in many different ways. Depending on the application that you want to upgrade, some ways make more sense than others. There are factors that determine which Rails upgrade strategy is the best for your case, like how big your application is, or how frequently changes are pushed to the master branch. In this article I’ll be covering two common Rails Upgrade strategies so you can decide which one is the best for your application.

We all know testing is important. We have our unit tests and integration tests to make sure everything is working as expected. At OmbuLabs opens a new window , we use Capybara opens a new window for our integration tests so that we can interact with the app as a real user would.

This is the process we used to replace the capybara-webkit gem in a legacy project with a more modern approach that uses the webdrivers opens a new window gem and a headless browser.

Churn vs. Complexity analysis is a great way to find insights about the maintainability of a project. Two of my favorite authors have written great articles about the Churn vs. Complexity graph:

• Getting Empirical about Refactoring opens a new window by Michael Feathers
• Breaking up the Beheamoth opens a new window by Sandi Metz

This two-dimensional graph can be very useful in finding the files that are the hardest to maintain in your application. In this article I will explain:

1. How you can calculate these metrics and use them in your legacy project
2. How code coverage metrics can guide your technical debt’s collection efforts

Deprecation warnings are a common thing in our industry. They are warnings that notify us that a specific feature (e.g. a method) will be removed soon (usually in the next minor or major opens a new window version) and should be replaced with something else. Features are deprecated rather than immediately removed, in order to provide backward compatibility (a solution that works in both the current and the future version), and to give programmers time to implement the code in a way that follows the new standard.

In this guide we’ll show you what the workflow is that we use at FastRuby.io opens a new window to address deprecation warnings when we upgrade Rails applications opens a new window .

We know that there are many challenges involved in a Rails upgrade project. Depending on how big your application is, how old your Rails version is and how well structured your code is, it can be difficult to perform that job and keep your sanity. If you don’t find a reliable and trustable process to guide you from version X to version Y, you can end-up in a nightmare.

The good news is that here at OmbuLabs opens a new window , we have been upgrading Rails applications for over 10 years now and this gave us a know-how to define a process that has proven to be very effective. And today I want to share Our Rails Upgrade Process with you.

There are some really great guides for starting a new open source projects opens a new window , yet when it comes to dealing with a possibly abandoned, unmaintained project, there is no definitive guide for users, contributors, or maintainers.

I hope that this can be a useful guide for our community.

Problem

When do you declare that an open source project has been abandoned? How many days have to go by until you start maintaining your own fork? What’s the standard for communicating with maintainers, contributors, and users? How do you avoid n competing OSS forks of popular projects? How do you avoid duplicated work by people who want to maintain popular, but unmaintained OSS projects? What’s the best way to find that one fork everybody is using?

Right before my talk at RubyConf Australia opens a new window , I worked on a way to make it easy for anyone to run skunk opens a new window in their Ruby projects. In order to do that I decided to use GitHub Actions opens a new window . It’s a powerful service by GitHub and it’s quite easy to set up.

This article is about the process that I followed and how you can use it in your own application.