In this article I’ll discuss a strategy for different readability: a simple way to split your routes file on a Ruby on Rails project.

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 during upgrades. But… How do you dual boot the gems?

SoundCloud is the world’s largest music and audio platform. With a diverse creator community, the platform is renowned for its unique content and features, including the ability for artists to share music and connect directly with fans.

If you search online for using SSH keys with Docker, to access private Github repositories, you will get a lot of search results, but the solutions you’ll find are almost all out of date, insecure, or fragmentary (i.e. they provide a small snippet of information but not a complete solution). Given how popular both Docker and Github are, I found this quite surprising. We recently had to set up Docker with a Rails application that fetches gems from private repositories. We’re also using Docker Compose, which added to the challenge. This comment on the Docker project, which is from February 2021, unfortunately is still accurate:

There are several questions and answers out there about how to pull from a private repository (using the hosts ssh key & config). A lot of them are not working, not secure or unanswered

After several hours of research and testing, we have a good solution to share. But first let’s take a look at the different approaches to consider.

Let’s begin with a simple question:

Have you seen config.load_defaults 6 in any application?

6 is an argument and could vary, I’m just giving an example.

The Opportunity Scholars & Guides program is one of the least known and also one of the best aspects of RubyConf and RailsConf:

Opportunity Scholars (Scholars) are new to the Ruby community and looking to make professional connections. Scholars are typically students, new professionals, and/or members of underrepresented tech communities (women, BIPOC, etc.) interested in starting a career in the technology sector. Scholars are paired with a Guide (mentor) who can help them get the most out of the conference, and offer insight and advice on Ruby programming and working as a developer… Due to the generous donation from our conference sponsors and supporters, we are delighted to offer a limited amount of financial support for Scholars’ transportation and/or accommodation.

Recently I worked on a client project that required me to implement good code conventions across the project. One of the tasks besides implementing the Rubocop standard cops was to write a custom cop for two different Datetime methods, so in this article I will explain how I created a custom Rubocop cop that solved that problem.

I’ve always wanted to create a gem that becomes popular enough to be well known and everybody speaks about it. Unfortunately, until now it has been only a dream. In the meantime, I’ve learned how to create and release gems manually and I’d like to share that with you. Maybe somehow your gem could be the next most popular gem and I’ll be super proud of that if your first step was to read this blog post.

At FastRuby.io, we talk a lot about software quality. It’s how we determine whether a client is a good fit for an upgrade. The less technical debt a codebase has, the easier it is to maintain, and the more likely a Rails upgrade will go smoothly. But what determines whether software is “good quality”? In this article, we will talk about what software quality is, and explain the metrics that people use when talking about how to measure it.

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, full stack Rails engineers, have come a long way. We started off as full stack engineers with our backend and frontend all in one framework. We had the asset pipeline (with sprockets) to help us maintain this ecosystem. When the time came we introduced webpacker to fill in where sprockets fell short.

In this post we will take a look at how we can take the next step on our journey by migrating from webpacker to esbuild.

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.

At OmbuLabs, one of our specialities is upgrading Ruby on Rails applications through our specialized service called FastRuby.io. In this post, I want to share with you some of the things that I’ve learned while working on my first Rails upgrade client project as a less experienced Rails developer.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 6.1 to version 7.0.