Articles by Ariel Juodziukynas

When we think about Ruby code coverage, our go-to gem for this is SimpleCov opens a new window , which works great when the test suite uses Minitest opens a new window , RSpec opens a new window , Cucumber opens a new window , Capybara opens a new window , and all these tools that are integrated with Ruby and Rails. But many applications also use other tools like Playwright opens a new window or Cypress opens a new window to run e2e tests, and we can’t use SimpleCov the same way.

Most of the time, what we have seen is that the Ruby code executed when running these tools ends up left behind and not being counted for the total code coverage, even though we know the code is actually being tested.

At FastRuby.io, we always recommend that clients set up an Application Performance Monitor. It’s not just useful for our Tune Report Service opens a new window , but good practice for visibility into server health, user experience, and more.

One concern that we sometimes hear is that the application may have really sensitive information about the users and it may not be possible to send the information to a third-party provider, or that a managed service can be too expensive. In this article, we are going to explore some open source solutions that can be self-hosted.

This article shows the compatibility between Sidekiq opens a new window and Rails opens a new window across different versions. Even though Rails is not a dependency of Sidekiq, there are compatibility considerations for different combinations given that Sidekiq provides integrations with Rails.

The Asset Pipeline has had many changes over the years, from not needing NodeJS when using Sprockets, to supporting NodeJS to manage JS dependencies through npm packages, to requiring NodeJS by default with Webpacker, and to not needing NodeJS by default again with ImportMaps.

ImportMaps is a good way to not have NodeJS as a dependency of the application, but it has many limitations (like the lack of TypeScript support) and it requires a lot of work to migrate to it when upgrading older applications.

In this blog post, we will see how to use Bun to remove the need to install NodeJS system-wide, how to use the standalone binary to not require an installation step, and at the same time keep using npm packages as needed to make the transition easier.

Last month, we finished a big upgrade for a client. The client had 2 main pain points for their app. The first one was that they were using Rails 2.3 LTS with Ruby 2.5. The next big issue was that the test suite took 40 minutes to run, blocking engineers from merging code into the main branch, and also slowing down the whole feedback loop for every code change.

After finishing the upgrade (we got the application to Rails 8.1.1 and Ruby 3.4.7), we focused our attention on improving the test’s speed and we reduced the time it took to run the whole test suite (over 10k tests) from 40 minutes to around 4!

There has been a lot of conversations on social media about the “NoBuild opens a new window ” approach: using native browser features and plain CSS+JavaScript to avoid a precompilation step for our assets.

In many cases, it’s not easy to move to a “NoBuild” setup (and in some cases it’s not even possible depending on the application’s needs), and we can still aim to make the assets:precompile task as fast as possible if we can’t eliminate it.

In this article we’ll explore some areas for optimization using one of our applications.

As we mentioned many times, at FastRuby.io we like to use the Dual-Boot technique opens a new window during upgrades to quickly test the same code with the current and the next version of what we are upgrading. We usually talk about dual-booting Rails versions but this can be used to upgrade Ruby itself too. We have to make some changes to adapt the technique, and we’ll explain the basic changes in this article.

Starting in Rails 7.1, Docker files are added by default opens a new window in new applications, but Docker opens a new window has been popular for Rails development for many years before that. At FastRuby.io, we use the Dual-Boot technique opens a new window when we work on upgrades, and using that approach when an application uses Docker requires some extra steps to keep a great development experience.

Late last year our team members headed to beautiful San Diego to join the incredible Ruby community at RubyConf 2023. Attending the conference is always a highlight, and we were excited to participate as a sponsor and engage with attendees, learn and share expertise, and have some fun.

The Ruby community is special. It has an incredibly inclusive and supportive culture that feels different than other languages. It was great to take some time to come together and enjoy the community’s hard work, network, and plan for the future.

With the Ruby 3.3.0 release around the corner, we wanted to share a summary of the changes that are coming in this new version. There are many exciting new features and improvements!

You just finished upgrading your app to the latest Rails version and you made the decision to never stay behind and always be ready to upgrade as soon as possible… But how can you do that?

In this article we’ll explain how the Dual-Boot technique opens a new window can be used to test the app against Rails’ main branch opens a new window , to catch problems and warnings before a new version is released.

By default, Ruby defines many constants and global variables that can be used in the code to get information about the current state of the application and the runtime. In this article we’ll go over most of them to understand what they are and what information we can set and get to simplify our scripts or to debug problems.

When working on upgrades, we use the Dual-Boot technique opens a new window so we can gradually update the app to work with the current version and the next one.

Eventually, the upgrade is done and the app is ready to drop the old version, but how do we handle that process? What are the steps between one upgrade and the next?

We are used to checking the deprecation warnings displayed by Rails or warnings from different gems, but Ruby itself can also display warnings to help us find code that can be problematic.

In this article we will explore how to use them, how to analyze them, and some examples of interesting warnings that can be really helpful during upgrades.

There have been a lot of changes over the years in asset management opens a new window for Ruby on Rails applications. The main question, after all the madness, is… “What should I do if I need to upgrade my Rails application?”

In this article we will talk about the options we have for each version jump.

You are upgrading a Rails application. You finished fixing a deprecation warning and it’s not present anymore. You continue working on other tasks and one day you find out the deprecation is back in the codebase. New code was added using the deprecated behavior, but it was not detected and now it needs to be fixed again…

How can you prevent that from happening and, at the same time, let the team know?

Over the years, Rails has been changing the default way to handle assets while also adding different alternative options at the same time.

At first there were static files, then Sprockets appeared, then we had a choice between Webpacker and Sprockets for a few years, now Webpacker is gone and importmaps are the default. But jsbundling-rails and cssbundling-rails are also official options.

Sound confusing? In this article we’ll try to explain the history of all these changes.

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.

This is the second part of the Optimizing Images series. In the first article opens a new window we talked about the basic concepts and techniques to optimize raster images, and today we’ll talk about techniques to optimize SVG opens a new window files.

Imagine this scenario: you open a website on your phone, you see an image loading really really slowly, you wonder what’s going on and download the image to see more details… turns out the image is 3000x3000px with a size of 1.5Mb!

So, let’s talk about different ways to optimize images, common problems, and ways to find these issues early.

Gems are a central part in a Rails application, they help us add new functionality to our apps so we don’t have to reinvent the wheel, but also allows us to extract code to better organize the codebase and to share logic between multiple apps. In many cases, we have custom made gems, and we need to ensure they will work properly with the two Rails versions we run when we use the Dual Boot technique opens a new window during upgrades. But… How do you dual boot the gems?

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.

At FastRuby.io, we recommend using the Dual Boot opens a new window technique for upgrades. This requires us to generate a Gemfile.next.lock file that will be used to boot the app with the next version or Rails. In this article we’ll share 2 techniques to generate this file: the faster one and the safer one.

When we run tests, we don’t want to hit external services in most cases, so our tests don’t depend on external services and are more stable. We can use gems like VCR opens a new window or WebMock opens a new window to stub the requests that are done by the Rails application, but when the request is initiated by the JavaScript code… that’s a different story.

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.

In modern apps, it’s common to enhance the user experience with JavaScript. Whether it’s just some JavaScript sprinkles here and there or a full JS-based frontend, this is as important as your Ruby code when it comes to the app’s correct functionality. In this article we’ll show how to measure the test code coverage for the JavaScript code when running system/integration tests along with the Ruby code coverage.

Rails UJS opens a new window (Unobtrusive JavaScript) is the JavaScript library that helps Rails do its magic when we use options like remote: true for many of the html helpers.

In this article I’ll try to explain the main concept of how this works to make it transparent for the user. Knowing a bit about the inner workings can help when debugging issues and also if we need to do something more complex than the provided interactions but reusing what’s provided.

If you are using an old version of Rails and you are still using jquery-ujs opens a new window , some code will not reflect how it does the magic, but most of these concepts apply as well (rails-ujs is a re-implementation of jquery-ujs removing the jquery dependency).

Have you ever had to deal with complex forms creating multiple objects and hierarchies in one request? Rails is there to help provide a set of helpers, methods and conventions to build nested forms, handle assignment, and creation of the objects involved in only a few lines of code. In this blog I’ll explain how that works using accepts_nested_attributes_for, fields_for, strong parameters and more.

Since the release of Rails 6, Webpack is the default JavaScript bundler for new Rails apps. We all struggled at first coming from a Sprockets background, and more often than not, we, as Rails developers, tried to avoid making JavaScript changes so we wouldn’t have to deal with it.

In this post, I’ll try to explain some basic concepts and ideas from the point of view of a Rails developer used to working with the Assets Pipeline, comparing how to do the same thing on both.

Back in 2011, Rails 3.1 introduced The Assets Pipeline opens a new window feature using the Sprockets gem opens a new window . This made it really easy to handle assets (images, fonts, JavaScript, CSS and more), solving many of the issues that developers had to face everyday.

In 2012, Webpack opens a new window was released solving the same issues in a different way and in time became the most used solution to handle assets. And since Rails 6, Webpack became the default solution to handle JavaScript assets using the Webpacker gem opens a new window on new Rails applications.

In this article I’ll explain the steps we took to migrate to Webpack to handle our JavaScript assets, and how we added support as a node module in our styleguide opens a new window .

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.