Articles on Best Practices

You get a site audit report and it looks manageable. A few dozen findings, most of them small: a page with barely any text on it, a link whose text is just “here”, a page whose title tag is a copy of its H1, a hero image heavy enough to hurt the largest contentful paint opens a new window . None of it is that hard. You spend an afternoon on it, close the tickets, and move on.

Then a few months pass, a dozen new pages ship, and the next audit reports the same findings again. Not because anyone ignored the first round, but because the first round fixed pages instead of fixing the process that produces pages.

That happened to us, on this site and on OmbuLabs.ai opens a new window . So the second time around we spent the effort somewhere else. Instead of just fixing the pages, we wrote checks that run on every build and say when a new page has the same problem. It is roughly the same idea as automating a tech debt audit opens a new window : most of the value is not in the report, it is in being able to produce the report again for free. No two of them wanted the same kind of check.

The goal here is search traffic, not a clean report. Thin pages, vague link text, and duplicated title tags are the things that hold a page back in search results, and a page that ships with them costs us traffic until the next audit finds it. A check on every build moves that discovery from months later to the pull request.

In this article, you will learn how we turned three kinds of audit findings into checks that run in CI.

You approved an APM tool at a modest monthly rate. A year later, the renewal invoice bears little resemblance to what you signed, and nobody remembers deciding to spend that much more.

APM is worth having when it’s used well: it resolves incidents faster by showing you where in the stack a problem started, it gives you warning before a threshold alert turns into an outage, and it gives you a defensible answer when a client or stakeholder asks whether you hit your SLA (often measured through percentile response times opens a new window like p95 and p99). None of that is in question here. What tends to go unexamined is whether the bill still matches what you’re getting for it.

In this article, we’ll walk through where APM spend typically concentrates, the warning signs that a bill has drifted from usage-driven growth into unmanaged creep, and a concrete checklist for getting ahead of it before your next renewal.

Many Rails teams that we have worked with have a version of the same story: a test suite that grew organically, was never quite prioritized, and now sits somewhere between “unreliable” and “actively avoided.” Maybe tests are slow. Maybe they’re flaky. Maybe coverage gaps makes deployments feel like a roll of the dice. Or a manual battle against a behemoth of a beast. It is likely you have heard engineers gripe about the test’s reliability and may be worried that they are sinking time in the application.

Improving your test suite is one of the highest leverage investments a development team can make even though it’s often deprioritized. While the benefits are not always obvious to those that approve budgets and sign contracts, issues related to the test suite can become a sifon of time, budget and team energy. Optimizing your test suite requires critical knowledge of the application and its business functions that require management and direction from experienced engineers, especially if leveraging AI models.

Writing effective test cases is as important as writing the business logic in your application. This blog post dives into the simple yet effective ways developers can use when crafting test cases.

Imagine this scenario: a developer added a pub/sub gem built on top of Sidekiq to handle background event broadcasting in your company’s Rails app. At the time, it was a huge win: instead of building a custom job orchestration system, they could drop in the gem, wire up a few events, and ship a feature in days instead of weeks.

Fast forward a few years: Sidekiq needed an update. You find out the gem wasn’t actively maintained anymore. But by then, the entire application depended on it. Core features like sending notifications, syncing with third-party APIs, and triggering billing logic all ran through this pub/sub layer.

Now you face a painful choice: either keep running on an unmaintained gem and risk breakage every time Sidekiq or Rails is updated, or rip it out and refactor the app to use a supported approach.

What began as a new dependency to save time has turned into a critical piece of fragile infrastructure. The lack of maintenance has turned what should have been a simple dependency update into a full-blown project.

How do we avoid getting into this situation in the first place? In this post, we’ll show you by digging into five critical areas to check before you choose a new gem.

People focus so much on <h1> and alt attributes that they forget about usability.

Introduction

When discussing accessibility (a11y), we all focus on the structure of our <h1>/<h2>, the alt image texts, the contrast, and all the necessary rules to be covered. The problem is that during the process, we forget to think about usability: Is the page saying what it is supposed to be saying? Does the image description reflect what you can see there? Or take link text as an example: Does “Read More” explain what content the user is about to access?

Most of the time, usability is overshadowed by a focus on compliance with accessibility standards. As a result, we end up with a site that passes validation but neglects to measure usability… or worse, we don’t even consider it.

At FastRuby.io opens a new window , we deeply value the Ruby and Rails communities and believe in giving back through open source contributions. We wouldn’t be where we are today if it wasn’t thanks to a lot of open source projects we use on a daily basis.

We actively use, maintain, and enhance several tools designed to empower developers and teams who want to handle Ruby and Rails upgrades themselves, especially those who might not have the budget to hire our services.

These open source projects facilitate upgrades by improving transparency, managing technical debt, and ensuring smooth transitions between Ruby and Rails versions.

Here’s an overview of each tool and how it can support your next upgrade project.

Aysan opens a new window recently wrote about accessibility testing in Rails applications opens a new window using your test suite to ensure that your application is accessible to all users.

However, you may not have a test suite in place or you may not have a Rails application, but you still want to test the accessibility of your web application, right? So, we discovered the WAVE Web Accessibility Evaluation Tools opens a new window that can help you test the accessibility of your web application, regardless of the technology stack you are using.

Does this sound interesting to you? Let’s dive in!

Have you ever found yourself wondering how to best manage your database migrations in Rails? Migrations are a powerful tool for evolving your database schema, but without proper practices, they can become difficult to manage and even lead to inconsistencies between environments. In this post, we’ll cover essential strategies for keeping your migrations organized, efficient, and in sync across development, staging, and production, helping you avoid common pitfalls and maintain a clean, up-to-date database.

There’s abundant online guidance about refactoring controllers and keeping them lightweight, but resources on model refactoring are less common. In this blog, we’ll explore some techniques for effectively refactoring models.

In this post, we share our approach to refactoring Rails applications, focusing on improving code maintainability, reducing technical debt, and ensuring scalability. Discover the tools, techniques, and strategies we use to transform complex codebases into cleaner, more efficient systems.

Diving into an existing Rails application for the first time can feel a bit overwhelming, especially when you’re trying to piece together how everything works. In this article, we’ll walk you through the process of truly understanding (or grokking) an existing Rails app for the first time.

In a previous blog post, How Do You Know When Your App is Not Compliant? opens a new window , I briefly discussed the importance of the accessibility standards of Web Content Accessibility Guidelines or WCAG opens a new window , 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 opens a new window 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 opens a new window

How many times have you or someone on your team brushed off a failing build with a casual, ‘It’s fine, it’s just a flaky spec—ignore it’?

If you’re nodding in agreement, you’re not alone. It’s a scenario familiar to many of us, especially when dealing with sprawling monolithic projects and untouched code sections.

One essential tool that we as software developers rely on is known as “test doubles.” These versatile components come in various forms, including dummies, fakes, stubs, spies, and mocks opens a new window . However, like other power tools, they require careful handling to prevent unintended consequences.

In this post, we’ll explore the strategic use of test doubles at the boundaries of our application, harnessing their full potential while minimizing associated risks.

Most people and companies that we talk to about upgrades assume that we generally help organizations that need to migrate to the latest Rails version.

However, this isn’t necessarily the truth. Instead, we mostly perform Rails upgrades for companies who are all the way back on Rails 3 or 4. To give you a better understanding of how common it is for companies to be on much older versions, this is a general list of our statistics from the past few years.

• Rails 2.3 - 3.2: 5 - 15 upgrades
• Rails 3.2 - 4.2: ~40 upgrades
• Rails 4.2 - 5.2: ~40 upgrades
• Rails 5.2 - 6.1: ~10 upgrades
• Rails 6.1 - 7.1: ~10 upgrades

We generally work with a lot of large, well established companies, so how did these successful companies fall so far behind, and how can you help your company to never need to hire us?

When we work on Rails upgrades, most of the time we have to solve issues after updating the gems. These problems can go from simple and straightforward to really complex and hard to debug. Here we will discuss different skills and techniques that we use to complete the upgrade.

Are you looking for a reliable way to test your applications? Look no further than the AAA pattern.

The AAA pattern stands for:

1. Arrange
2. Act
3. Assert

This pattern helps you structure your tests in a clear consistent manner, and it is not tied to a particular programming language or testing tool, making it a versatile and effective approach to testing opens a new window .

To automate the Ruby gem release process, we will only need to configure two things, the GitHub Actions workflow, and using conventional commit messages.

Does this sound interesting? Come and let’s dig into it.

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.

In the developers’ world, there is a well known quote by Phil Karlton opens a new window that goes There are only two hard things in Computer Science: cache invalidation and naming things. We usually think about that phrase in the sense that it’s hard to come up with a clear, descriptive, and concise name for the code we write (variables, methods/functions, modules/classes, etc), but sometimes, the perfect name we found can be a problem too.

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 opens a new window (and RuboCop opens a new window ) to improve the quality of the code by keeping a consistent style to help the developers.

We are excited to share a new gem for the Ruby community: dotenv_validator opens a new window ! A library that will help you validate that the values in your environment are valid according to the comments in your .env.sample file.

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

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

Contributing to open source projects is a big part of our philosophy at OmbuLabs opens a new window . It’s even written into our values opens a new window . Some of us like to contribute to open source even in our spare time!

Recently we have been thinking about what guidelines we should follow when starting a new open source project, and also about how to organize and keep track of the ones we contribute to.

This article will give you some tips on keeping those open source projects organized, and also how to start them off on the right foot.

We all know testing is important. We have our unit tests and integration tests to make sure everything is working as expected. At OmbuLabs opens a new window , we use Capybara opens a new window for our integration tests so that we can interact with the app as a real user would.

This is the process we used to replace the capybara-webkit gem in a legacy project with a more modern approach that uses the webdrivers opens a new window gem and a headless browser.

There are some really great guides for starting a new open source projects opens a new window , 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?

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.

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.