All Articles

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

Here we continue with the series opens a new window 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 opens a new window when it comes to iterations across a large number of records.

This year’s RailsConf opens a new window 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 opens a new window

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 opens a new window upgrades. That’s why a few years ago we decided to launch FastRuby.io opens a new window , our Ruby on Rails upgrade service.

When we receive an inquiry via FastRuby.io opens a new window , 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 opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 5.2 opens a new window to 6.0 opens a new window .

Next week the Rails opens a new window community is having the biggest event of the year, the Rails Conf 2019 opens a new window . We participated in previous editions of this conference but this time we have the honor to be on the speakers side of it. We’ll be teaching you what we’re best at: Rails Upgrades opens a new window .

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 opens a new window 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

At OmbuLabs opens a new window , we are big fans of Ruby on Rails opens a new window and design patterns opens a new window , especially convention over configuration opens a new window ! The beauty of Rails is that you can inherit a legacy project and easily find the different layers of code in different directories.

When it comes to database migrations the policy of Rails is very clear. It’s all about altering the database structure with gradual migration files: “Migrations are a convenient way to alter your database schema over time in a consistent and easy way.” (source opens a new window )

But, what about data migrations? What’s the best way to write, maintain, and run migrations that alter the data in your production database?

In this article I will talk about three different patterns for writing and maintaining your data migrations:

1. Data migrations in db/migrate
2. Data migrations with a set of Rake tasks
3. Data migrations with data_migrate