A race condition is a type of software bug that occurs when multiple threads or processes access a shared resource simultaneously, and the outcome of the execution depends on the timing of these accesses.

Recently I worked on a client project that required me to implement good code conventions across the project. One of the tasks besides implementing the Rubocop standard cops was to write a custom cop for two different Datetime methods, so in this article I will explain how I created a custom Rubocop cop that solved that problem.

At FastRuby.io, we talk a lot about software quality. It’s how we determine whether a client is a good fit for an upgrade. The less technical debt a codebase has, the easier it is to maintain, and the more likely a Rails upgrade will go smoothly. But what determines whether software is “good quality”? In this article, we will talk about what software quality is, and explain the metrics that people use when talking about how to measure it.

We all have been there, we work on a project and, over time, we write similar code in different ways (either by two different developers or by the same developer). We have two blocks of code that follow the same logic but look different; and we have to make an extra effort to understand them only because the code is written in a different way.

Defining a code style will prevent this, but we need a way to enforce it. In this article, we’ll show what’s our setup to use StandardRB (and RuboCop) to improve the quality of the code by keeping a consistent style to help the developers.

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.

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

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