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.

At FastRuby.io, we recommend using the Dual Boot 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 or WebMock 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 (and RuboCop) 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.

Back in 2011, Rails 3.1 introduced The Assets Pipeline feature using the Sprockets gem. 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 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 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.

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.