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?, 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

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. 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.

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 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 (and RuboCop) 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! 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.

So, I was interested in seeing code coverage metrics for the Ruby on Rails framework. 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. It’s even written into our values. 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, we use Capybara 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 gem and a headless browser.

There are some really great guides for starting a new open source projects, 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 service at FastRuby.io, 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.

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