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.

At OmbuLabs we like to follow a style guide to drive our own products. A style guide is a document that provides guidelines for the way your brand should be presented from both a graphic and language perspective. You can see FastRuby.io’s style guide at this link opens a new window .

Since we have a few applications in place and it’s important to make sure that they all use the same style, we need to ensure that they will all inherit the same CSS files. One way to do this is to copy the above style guide and paste it inside all of our apps, but this would end up causing a lot of duplicated code. If we decided to change the font-style, for example, we would need to change it in all apps individually.

Something else we are super fans of at OmbuLabs is to follow good code and development practices. One of our favorites is the DRY (Don’t Repeat Yourself) opens a new window principle, which states that duplication in logic should be eliminated via abstraction. So to avoid the duplicated code here, we decided to create a gem to encapsulate our style guide and to be bundled in all of our products.

In this article, I’ll show you how we did it!

Technology evolves quickly. When you first created your Rails application, it’s likely you did it using the latest version of Rails opens a new window . As time passes, however, new Rails opens a new window versions come out and your application becomes more and more out of touch with the latest version. But why is this important? Why does it matter?

There are several different reasons to upgrade your Rails application opens a new window . In this article, I’ll list what we consider to be the most important ones.

Migrating from Protected Attributes to Strong Parameters in a Rails opens a new window project can be a huge step of the upgrade process. Especially when we are upgrading a large application opens a new window . 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 opens a new window 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 opens a new window 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 opens a new window . 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 opens a new window service at FastRuby.io opens a new window , we analyze the test suite of the application we are auditing to give a proper estimate on how long it will take us to upgrade. One of the tools we use for this is SimpleCov opens a new window .

Often times our clients use parallelization in their continuous integration tools. SimpleCov generates multiple .resultset.json files for the same codebase. However, our goal is to have a single .resultset.json for the whole application. In this blog post we are going to show you how we solved the problem.

We recently collaborated with Amitree opens a new window on a Rails upgrade opens a new window 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 OmbuLabs opens a new window .

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

In this article I’d like to talk about Skunk: A SkunkScore Calculator opens a new window ! 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 opens a new window to assess code quality and SimpleCov opens a new window to assess code coverage.

In my previous article I wrote about free and open source Ruby gems we can use to assess code quality opens a new window for any Ruby or Rails project. After writing that article, I found that RubyCritic opens a new window 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 opens a new window

As part of our Rails upgrade opens a new window 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 opens a new window and SimpleCov opens a new window .

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 opens a new window which accidentally introduced a non-deterministic spec opens a new window (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.

Service Objects are a controversial idea for several different reasons: some developers like to use them, others like to use similar patterns, and some think that they are just unnecessary because they prefer fat models.

Here at OmbuLabs we like to use service objects whenever we can, we think it’s a great way to keep our controllers skinny.

In this post I would like to discuss my idea about service objects and why it’s adopted by our team.

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 opens a new window , 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 opens a new window , we learned that the best way to isolate our client projects’ environments is using Docker opens a new window .

That’s why we decided to use Docker and docker-compose opens a new window 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 opens a new window