Waiting over an hour for a test suite to finish is a productivity killer.

On a recent project, that was our reality.

Running the full local RSpec suite took almost 2 hours, making it difficult to get quick feedback and confidently iterate on changes. While there are many ways to optimize test performance including fixtures, request stubbing, faster tooling, and more, most of these options require significant effort to implement.

Instead, we explored a simpler approach: bringing parallel test execution to local development. The result was a much faster feedback loop (down to 5 minutes) and a significantly better developer experience.

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 8.0 to version 8.1.

Whether you’re debugging a dependency issue, checking for an optional gem, or just curious about what’s loaded in your Ruby app, there’s a handy command that can help:

puts Gem.loaded_specs.keys.grep(/your_pattern_here/)

In this article, we will discuss what this command does, what exactly it’s checking for, and its limitations.

In earlier versions of Elasticsearch, types were a convenient way to categorically organize documents within a single index. However, types were eventually deprecated, pushing developers toward a type-less structure in Elasticsearch 7 and later versions. Recently while working on a project to migrate a Rails application from Elasticsearch 2 to OpenSearch 2, we faced the challenge of identifying a way to replicate this behavior in a way that is allowed with OpenSearch. In this blog we will discuss how types were used for document organization and how to achieve the same behavior in OpenSearch.

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 7.2 to version 8.0.

Ruby on Rails has a new maintenance policy and it can be a bit confusing as to what it means for both new and existing Rails projects. In this blog, we are going to summarize all the details, changes and important dates to help your team plan your next upgrade.

Let’s take a look!

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 7.1 to version 7.2.

In a previous blog post, How Do You Know When Your App is Not Compliant?, I briefly discussed the importance of the accessibility standards of Web Content Accessibility Guidelines or WCAG, to ensure that everyone, including those with disabilities, can use web applications effectively. In this blog, we are going to further explore the importance of maintaining accessibility compliance, what it means to users, as well as how to use the axe-core-gems for automated accessibility testing to help identify and resolve any gaps that may be currently present in a project.

In software development, there are instances where creating a long-running branch when working on a project will be considered by developers. Long-running branches have been debated a lot by many teams due to their risks mainly around but not limited to, dare I say it, merge conflicts.

However, it isn’t necessarily the evil it’s made out to be and when handled with care, they can present extreme value to a team. Even DHH argues the benefits of maintaining a ‘cohesive architecture’ in this article

Ensuring that your company’s website is current with compliance standards is extremely important and essential for any Rails application. Operating with a compliant application guarantees security that can help with handling sensitive data and maintaining users’ trust. The more compliant your website is, the more secure it will be against data breaches, which helps users feel safe when they’re using it.

So what does it take to be compliant? In this article, we will focus on security and cover some indicators to help identify if your Rails app might not be compliant anymore.

Every year, Ruby enthusiasts anticipate the December release of a new Ruby version. At the end of 2023, Ruby 3.3 was released and you can read this article to learn more about the new features and improvements it brings. This makes it a good time to start considering if your application is due for an upgrade.

Upgrading your application can sound complicated and difficult, but it doesn’t have to be. Below, we will discuss how to identify when to upgrade your Ruby version and the steps necessary to complete a smooth and successful upgrade.

One of our biggest goals as a company is to aim for transparency and honesty when evaluating a project for an upgrade. We understand that the decision to hire an outside vendor versus doing it in house becomes a difficult one. To provide confidence and a clear path to completing an upgrade, before we even begin a project we invest time in doing a thorough investigation of the project to provide the most accurate and detailed game plan for an upgrade.

In this blog, we are going to break down our Roadmap service and explain how it can be used to guide you and your team to making decisions when it comes to upgrading your application.

Recently, while working on a Rails 6.1 to 7.0 upgrade, we encountered the following deprecation warning regarding changes made to ActiveRecord::Relation’s merge method:

"Merging (#{node.to_sql}) and (#{ref.to_sql}) no longer maintains both conditions, and will be replaced by the latter in Rails 7.0. To migrate to Rails 7.0's behavior, use relation.merge(other, rewhere: true)."

In this article, we will talk about the expected behavior of merge, how it has changed and what to do in order to use the new behavior if you find yourself looking at this deprecation.

Recently I got to work on a task that included understanding how to test JavaScript requests with RSpec. One thing that I found missing during my time researching solutions was organized and detailed documentation explaining the solutions based on the version of Rails and RSpec the application runs on.

As of May 1st, 2023, Heroku will no longer be supporting the Heroku-18 stack. The reason for this deprecation is to maintain synchronization with the Ubuntu Long Term Support releases. If you are currently running your Rails application on this stack, when you navigate to the Heroku dashboard you will notice a warning to upgrade to either Heroku-20 or Heroku-22 before the end of the Heroku-18 stack life on April 30th, 2023.

While Heroku-18 will not be supported, do not be alarmed or concerned that the apps running on this stack will stop working. Heroku has confirmed that all existing applications will not be interrupted and non-build functionality will still be available. However, to maintain access to security updates, technical support and the ability to perform new builds, an upgrade will be necessary and is highly recommended.