According to a definition of multitenancy, when an app serves multiple tenants, it means that there are a few groups of users who share common access to the software instance. An excellent example of an app that supports multitenancy is the Jira platform, where each company has its subdomain to access the software, for example, mycompany.atlassian.net.
The last 3,650 days of my professional life have been focused on making Rails apps faster. Below are five lessons I've learned the hard way.
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?
Thanks to awesome contributions from the community and the hard work of our integrations team, the Honeycomb Rails integration comes with lots of great features out of the box. This post is an end-to-end tutorial to show you exactly the steps involved, from creating a new Honeycomb team to getting your data in and observing your app in production.
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.