Systems | Development | Analytics | API | Testing

Reading a lot of code from very senior engineers is probably one of the best ways to level up as a Ruby on Rails developer. By doing so, we can learn new tips and techniques that we can reuse in our jobs. Thanks to open source, we can read code written by the best developers from all over the world, and for free! However, reading code from a Ruby gem or a Rails engine for the first time without being guided can be daunting. There are so many files; how do we even know where to start?

Today, we're going to have a little history lesson for those of you who haven't been around since forever, but for those of you who have been around since forever, hopefully this will be a nostalgia fest. We can enjoy some good memories together. From FTP to Kamal, an oral history of deploying Rails apps. Watch the video for the full story!

In part one of this series, we looked at how to extend the ActiveStorage ingest process with custom analyzers. In this post, we will reverse the procedure and explore how to utilize ActiveStorage previewers to display data.

Our previous article in this series established that Solid Queue is an excellent choice if you need a system for processing background jobs. It minimizes external dependencies — no need for Redis! — by storing all jobs in your database. Despite that, it is incredibly performant. But just being performant is not enough for a production-ready background job system. Rails developers have come to expect a lot over the years. We don't just want to enqueue jobs to run in the background.

One of the most exciting additions to Rails 8 is undoubtedly Solid Queue, a new library for processing background jobs. You might not think it's that big of a deal. After all, there are plenty of other queuing systems out there. If you work with Rails, you'll likely know about Sidekiq and Resque — both are exceptionally performant and reliable. There is also GoodJob and the venerable DelayedJob. With all those options available, do we really need another queuing system? Let's find out together.

Rails 8 shipped with a bold premise: “No PaaS Required.” As cloud platforms have grown more costly, Ruby on Rails has shifted to reducing external infrastructure dependencies so that developers can deploy and run applications with fewer ever service dependencies. Traditionally, deploying a Rails app to the internet has meant provisioning a database server (e.g., PostgreSQL) and additional services like Redis for caching, background jobs, or WebSockets.

In the part 1 of this series, we covered the fundamentals of caching (like fragment and Russian Doll caching). Before continuing, read that post here. This time, we’ll look at understanding Rails cache stores at a deeper level, so let’s jump in! Before we start part 2, let’s note that another way to make sure your Rails apps are ultra-fast is with Scout’s integrated monitoring and logging, so you can spot problems before your users do.

Before we can release our software to end users, we must perform different kinds of tests to ensure that the application is bug-free and meets business requirements. When users begin using the application, various things can cause the application to behave unexpectedly, for some of the following reasons: For large-scale applications, these things are crucial to know before a full-fledged release.

When it comes to optimizing web applications, a proper caching strategy is critical because it can significantly reduce load times and improve the overall user experience. This is especially true for Ruby on Rails applications, where performance can often experience bottlenecks due to heavy database queries or complex view rendering.

The concept of caching is an important one in computer science and is directly relevant to building web apps. At a high level, caching takes advantage of the fact that memory lookups are faster and less compute-intensive than database queries. If you have a database query that might get made repeatedly, caching the result in a cache speeds up that flow of execution. Rails applications are no exception as they often use memory-based caches like Redis to cache data and improve application performance.