Imagine your customers are complaining that a few specific pages in your application take forever to load and you get to work to fix the issues. But there is a problem. You don’t know where to begin. If this journey of seeking truth, I mean answers, interests you, then read the rest of the article.

There has been a lot of conversations on social media about the “NoBuild” 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.

Ensuring that your company’s website is current with compliance standards is extremely important and essential for any Rails application. Operating with a compliant application guarantees security that can help with handling sensitive data and maintaining users’ trust. The more compliant your website is, the more secure it will be against data breaches, which helps users feel safe when they’re using it.

So what does it take to be compliant? In this article, we will focus on security and cover some indicators to help identify if your Rails app might not be compliant anymore.

Sinatra is known in the Ruby world for being a lightweight framework for building Ruby web applications with minimal effort.

Over time Sinatra has been through many versions, and sometimes it gets complicated keeping track of which versions of Sinatra are compatible with which versions of Ruby. Therefor, we made a handy chart!

Rails progression emphasizes simplicity and productivity. Through versions, Rails integrated tools, enhanced performance, and adapted to industry standards, keeping a focus on developer happiness and efficiency. ActiveModel::Error is an example of that. On this blog post, we’ll dive into the evolution of this object.

As we mentioned many times, at FastRuby.io we like to use the Dual-Boot technique 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.

In a previous article, we listed down common culprits that led to a sub-optimal performance in Rails applications. One of the culprits was missing or incorrect indexes.

Therefore we thought it would be very useful to have a handy reference to the different kinds of indexes, when you should use them and maybe even when not to use them.

Roda is a web toolkit (or framework) that focusses on simplicity, reliability, extensibility, and performance. This is a short post to show the compatibility between Roda and Ruby across different versions.

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.

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

Is your goal to rank first on Google? Have you already tried using the best keywords and strategies to rank higher but none of that has worked? It might be because your LCP, or Largest Contentful Paint, score is high and needs improvement.

Based in Sydney, Australia, ReadyTech combines technology with a people-centric approach to help organisations navigate complexity and deliver meaningful outcomes. With more than 500 employees globally, the publicly-traded company continues to grow rapidly and now serves 4,000+ customers across three vertical segments: Education & Work Pathways, Workforce Solutions, and Government & Justice.

Maintaining an up-to-date Ruby on Rails application is crucial for performance, security, and feature enhancements. However, finding the time for a full-scale upgrade can be challenging. In this blog post, we’ll explore practical steps you can take to delay a Rails upgrade when you don’t have the immediate bandwidth but want to set the stage for a seamless process in the future.

When it comes to improving application performance and areas to focus on, I would recommend looking at the APM data, and then deciding which areas to prioritize.

However this article isn’t about where to focus efforts, but rather a compilation of techniques to improve your application’s performance, from tackling common problems like N+1 queries and database indexing to leveraging the jemalloc memory allocator. Let’s look at these performance-boosting strategies designed to fine-tune your application.

Every year, Ruby enthusiasts anticipate the December release of a new Ruby version. At the end of 2023, Ruby 3.3 was released and you can read this article to learn more about the new features and improvements it brings. This makes it a good time to start considering if your application is due for an upgrade.

Upgrading your application can sound complicated and difficult, but it doesn’t have to be. Below, we will discuss how to identify when to upgrade your Ruby version and the steps necessary to complete a smooth and successful upgrade.