Rails Engines are an architectural pattern that can be used to modularize a Rails application. They are self-contained applications that can be mounted within a larger Rails application. In this post, we will dive into the world of Rails Engines and explore what they are, how to create them, how to use them, when to use them, and why they are important.

Ever since we started offering productized Ruby and Rails upgrade services and upgrade roadmaps, we’ve been interested in helping as many people and companies as possible.

Unfortunately, in the past we’ve had to turn down companies who wanted to work with us but couldn’t secure the minimum monthly budget to work with our experts.

I’m pleased to announce that we’re now offering new opportunities for startups and small businesses to work alongside our team.

In this article, I will share a few new options to collaborate with our team of experts who specialize in technical debt remediation.

Power Home Remodeling (Power) is the nation’s largest full-service exterior home remodeler and a top workplace.

Headquartered in Chester, Pennsylvania with offices in 18 territories across the United States, the award-winning company’s primary product line includes windows, siding, doors, roofing, solar roofing panels, and attic insulation.

In this article we will share how our Tune Report helped Power speed up their application by reducing their average page load time from 5 to 3 seconds.

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.

At FastRuby.io we love Ruby on Rails because it is so powerful: You can quickly create an application that is feature complete, stable, and secure

Unfortunately, maintaining a Rails application up to date and secure takes some effort.

In this blog post, we will cover a few Ruby gems and best practices that you can use to stay on top of your security, reliability, and stability needs.

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.

Have you ever tried to update a Rails app from 5.2 to 6.0, or from 6.0 to 6.1? If so, you might have seen this deprecation:

DEPRECATION WARNING: Dangerous query method (method whose arguments are used as raw SQL) called with non-attribute argument(s): "random()". Non-attribute arguments will be disallowed in Rails 6.0. This method should not be called with user-provided values, such as request parameters or model attributes. Known-safe values can be passed by wrapping them in Arel.sql(). (called from ...)

Note: While this deprecation message mentions Rails 6.0 as the version where the behavior is disallowed, that change was postponed, so the deprecation also shows in Rails 6.0. The behavior is actually disallowed in Rails 6.1.

What does this deprecation mean exactly? In this article, I will explain that in plain English, what issue it is trying to prevent, and how to fix the problem if you come across it in your codebase.

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.

Ruby on Rails is a popular web application framework that is constantly evolving with new versions being released frequently. While upgrading to a newer Rails version can bring new features, better performance, and security patches/improvements, it can also be a challenging task.

In this blog post, we will discuss 7 common mistakes made while doing Rails upgrades and how to avoid them.

doxo delivers innovation that transforms the bill pay experience for consumers, billers and financial technology providers. For over eight million consumers, doxo’s all-in-one bill pay makes it simple to organize and pay any bill on any device through a secure checkout.

Since 2017 we have been focusing on upgrading Ruby on Rails applications. It’s been quite a fulfilling learning process as we continuously improve our workflow best practices, and internal tooling.

In this article I will go into detail to explain how we determine the best approach to create the roadmap for a successful upgrade project.

Smile.io is the world’s largest rewards program provider. Providing solutions for merchants and e-commerce businesses, its loyalty management software integrates with Shopify, BigCommerce, and Wix to reward customers with points and perks for purchases, referrals, and sharing content.

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.

When we allow users to upload images, they usually upload files without any optimization for the web. It’s up to us to add some measure to prevent those images from slowing down our app. Luckily, the different gems commonly used to handle user uploads also give us solutions for this problem.