Migrating from Protected Attributes to Strong Parameters in a Rails project can be a huge step of the upgrade process. Especially when we are upgrading a large application. This guide is meant to help you tackle that step faster and with a lot less pain.

This year I had the honor to speak at RubyConf in Nashville. It was my second time attending the conference and first time as a speaker. I talked about skunk, a gem to calculate the StinkScore of a module or set of modules.

Since its inception, skunk has changed quite a bit based on real usage in our productized service for Rails upgrades. As a matter of fact, the night before my talk I realized there was a BIG error in our formula.

Here is a description of the problem and solution.

As part of our Roadmap service at FastRuby.io, we have to analyze the test suite of the application we are upgrading to give a proper estimate on how long it will take us to upgrade. We use SimpleCov for this.

Most of our clients use parallelization in their continuous integration tools. SimpleCov generates multiple .resultset.json files for the same codebase. Our goal was to have a single result for the whole application, so in this blog post we are going to show you how we solved that problem.

We recently collaborated with Amitree on a Rails upgrade for their application which "is an AI assistant for email, integrated deeply within Google and Microsoft’s products and is in heavy use by real estate professionals" and were able to speak to them about their experience with Ombu Labs.

Two weeks ago I had the opportunity to speak at Solidus Conf 2019. I presented Escaping the Tar Pit for the first time and I got to talk about a few metrics that we can use to quickly assess code quality in any Ruby project.

In this article I'd like to talk about Skunk: A Stink Score Calculator! I'll explain why we need it, how it works, and the roadmap for this new tool.

Every time we evaluate a new project we follow a well-defined process to decide whether we take it or not. We analyze its dependencies; its code coverage; and its code quality to determine the amount of tech debt in a project. We have been using CodeClimate to assess code quality and SimpleCov to assess code coverage.

In my previous article I wrote about free and open source Ruby gems we can use to assess code quality for any Ruby or Rails project. After writing that article, I found that RubyCritic was really interesting and its community quite active, so I thought it was a good idea to add SimpleCov support to it: https://github.com/whitesmith/rubycritic/pull/319

As part of our Rails upgrade business we get to evaluate a lot of codebases every month. We usually need a quick way to assess the quality of the code we get. For this we like to use CodeClimate and SimpleCov.

CodeClimate is free for open source projects and paid for private projects. I know that not everybody can pay for their service, so I thought it was a good idea to share some free, open source alternatives.

Here is a list of 3 tools that can help you assess the quality of your next codebase.

An outdated Rails application doesn't happen overnight. In FastRuby.io we work with a lot of clients who have outdated Rails applications and we help them upgrade to a newer Rails version. In this article I share some things that you could start doing to avoid falling out of date.

I recently wrote a spec for metric_fu which accidentally introduced a non-deterministic spec (a flaky spec!). I had no idea why it was randomly failing. This is an article to explain the process I followed to debug this issue.

In this blog post I will introduce bundler-leak -- A bundler plugin to find known memory leaks in your dependencies.

Every time we start a new Rails upgrade project, we need to setup a whole new environment in our local machines. Sometimes that leads us down the rabbit hole which ends up breaking our environment for other client projects.

After years upgrading Rails applications, we learned that the best way to isolate our client projects' environments is using Docker.

That's why we decided to use Docker and docker-compose for all of our client projects. This year I had the opportunity to share our process in a series of workshops: Upgrade Rails 101: The Roadmap to Smooth Upgrades

Here we continue with the series of articles where we talk about how minor adjustments in the code can lead to major performance improvements.

In this article we'll focus on the use of ActiveRecord::Batches#find_each when it comes to iterations across a large number of records.

This year's RailsConf was a special conference for me. It was my third time attending and my first time speaking at the conference. I conducted a 2-hour workshop for anyone interested in upgrading their Rails application: Upgrade Rails 101: The Roadmap to Smooth Upgrades

Here are a few lessons learned from running such an ambitious workshop.

Over the years we have seen a significant increase in the demand for Ruby on Rails upgrades. That's why a few years ago we decided to launch FastRuby.io, our Ruby on Rails upgrade service.

When we receive an inquiry via FastRuby.io, the first thing we like to do is schedule a call with the potential client to get more details about their app.

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