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.

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.

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.

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.

So, I was interested in seeing code coverage metrics for the Ruby on Rails framework. 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.

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 by Michael Feathers
• Breaking up the Beheamoth 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

There are some really great guides for starting a new open source projects, 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, I worked on a way to make it easy for anyone to run skunk in their Ruby projects. In order to do that I decided to use GitHub Actions. 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.

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 SkunkScore 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.

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 SkunkScore 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.

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.

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

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.

In this article I will explain how you can dual boot your application in your local environment and your continuous integration (CI) service. I hope that this will help you get ready for the next stable release of Rails.

I had to come up with a clever title because this article is about legacy Rails applications and I know that you might fall asleep by the third paragraph. Boooooring… You probably want to read about that new JavaScript framework that came out (I love that this sentence will always be true, it doesn’t matter when you read this)

If you have been working with Rails for a few years, you have seen your fair share of shiny new applications, well-maintained and poorly-maintained legacy applications. This post is about Legacy Rails applications

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

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.

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.