If you’ve ever used Ruby on Rails, you’ve probably come across the concept of concerns. Whenever you jumpstart a new Rails project, you get a directory app/controllers/concerns and app/models/concerns. But what are concerns? And why do people from the Rails community sometimes talk badly about them?
Few things are scarier than a database slowly losing integrity over weeks or years. For a while, nobody notices anything. Then users start reporting bugs, yet you can't find any code that's broken. By the time you realize the problem, it may be happening for so long that your backups are unusable. We can avoid problems like these with skillful use of transactions.
Whoever first said that "the fastest code is no code" must have really liked memoization. After all, memoization speeds up your application by running less code. In this article, Jonathan Miles introduces us to memoization. We'll learn when to use it, how to implement it in Ruby, and how to avoid common pitfalls. Buckle up!
We've all been there. You're clicking around your Rails application, and it just isn't as snappy as it used to be. You start searching for a quick-fix and find a lot of talk about caching. Take your existing app, add some caching, and voila, a performance boost with minimal code changes. However, it's not this simple. Like most quick fixes, caching can have long-term costs.
It is widespread to have parent-child associations in Rails applications. On the parent side is a :has_many association, and on the child side is a :belongs_to association. Examples include an article with comments, or an author with books--the former is the parent, and the latter is the child. It is often useful to display a count of the children alongside information about the parent, without necessarily loading all the child records.
In today’s post, we’ll take a deep dive into Rails migrations. We’ll break down the migration into different pieces, and in the process, learn how to write an effective migration. We’ll learn how to write migrations for multiple databases, as well as how to handle failed migrations and techniques of performing rollbacks. To understand the whole post, you’ll need to have a basic understanding of databases and Rails.
When you deploy a new Rails app, you typically face a double-bind. If you use an easy platform like Heroku, you could create problems for yourself as your application scales. If you use a more fully-featured platform, you risk wasting time on ops that could be spent on your product. What if you could have both: an easy deployment option that is easy to scale?
In today’s post, we will be looking into a software design pattern called Facade. When I first adopted it, it felt a little bit awkward, but the more I used it in my Rails apps, the more I started to appreciate its usefulness. More importantly, it allowed me to test my code more thoroughly, to clean out my controllers, to reduce the logic within my views and to make me think more clearly about an application’s code’s overall structure.
In today’s post, we’ll learn how to build a Rails app that can support multiple subdomains. Let’s assume that we have a gaming website funkygames.co and we want to support multiple subdomains such as app.funkygames.co, api.funkygames.co, and dev.funkygames.co with a single Rails application. We want to ensure that proper authentication is performed for all subdomains and that there are no duplicate routes.
Application performance is always a concern when building in the modern, competitive web and mobile space. At Scout, it’s why we created application performance monitoring tools in the first place. That said, there are steps you can take to build a more performant application. If you are using Ruby on Rails, caching might be one of the best tools on your belt to build a better application.
