When building a Rails application you will need to think about scaling as you get more and more users and data. One way in which your application may need to scale is at the database level. Rails supports using multiple databases, so you don’t have to store all your data in one place.

In a previous post, we discussed the importance of assessing an application’s dependency freshness and demonstrated how you can use different tools for this purpose. One of these tools is libyears. In this post, we’ll share the libyears calculations for several popular Ruby projects and discuss our findings with you.

Technical debt, a term coined by Ward Cunningham in the 1990s, refers to the trade-off between short-term gains and long-term consequences in the development process. In this article, we will explore what technical debt is, why it happens, why you should care about it, and discover some new tools to help you discover the technical debt in your Rails applications.

This is a short post to show the compatibility between Ruby on Rails and Ruby across different versions. In the process of upgrading really old applications to more modern versions of Ruby and Rails we have run into a lot of these combinations.

Hanami is a modern web framework which is looking for new ways to build maintainable, secure, faster and testable Ruby applications. This is a short post to show the compatibility between Hanami and Ruby across different versions.

Ruby on Rails is a powerful web application framework that has evolved over the years, with new versions bringing in features, improvements, and security updates. As your application matures, keeping it up-to-date with the latest Rails version becomes crucial. However, the prospect of upgrading an entire Rails application can be daunting. In this blog post, we’ll explore whether it’s possible to upgrade your Rails application in increments and how to go about it.

In software development, there are instances where creating a long-running branch when working on a project will be considered by developers. Long-running branches have been debated a lot by many teams due to their risks mainly around but not limited to, dare I say it, merge conflicts.

However, it isn’t necessarily the evil it’s made out to be and when handled with care, they can present extreme value to a team. Even DHH argues the benefits of maintaining a ‘cohesive architecture’ in this article

Need help executing a GitHub Actions workflow for your Rails application, especially when dealing with a MYSQL database? Whether you’re just starting or transitioning from another CI service, navigating potential pitfalls can be challenging. If you’ve found yourself nodding along, then this blog post is tailored just for you.

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.