For many applications, access is usually through a single domain, such as yourapp.com. This way, the application developer is able to offer a unified experience to all users. This works great most of the time, but imagine a situation where you need to give each user a customized experience; how would you achieve this? One of the ways you can customize the user experience in a single application is by using account-based subdomains.

One great feature that comes with modern web frameworks is the ability to manage database schema migrations. However, schema migrations are not 100% safe and remain a recurring cause of issues within projects I have encountered over the last 15 years. This article will review the issues surrounding poorly managed schema migrations and then look into Strong Migrations, a gem that can help you avoid most problems. Finally, we will discuss a few good practices around database management. Let's get started!

In part one of this series, we used Hotwire's Stimulus and Turbo Frames to present modals in Rails. Now, we'll dive into another method we can use to present modals: Turbo Streams.

There are many ways to deploy a Ruby on Rails application to the internet. Between hosting on your own hardware, renting a virtual machine, using a cloud provider, and using a platform, the opportunities are endless. The low-hassle way to host a Rails application is to use a Platform as a Service (PaaS). In this article, we'll show you how to deploy a Rails Application to Render.com, and as a bonus, monitor it with Honeybadger! You can find the final project here on Github.

Modals are widely used on the web, but they are rarely built with accessibility in mind. When a modal is displayed, the background is dimmed visually but it's still visible to screen readers and keyboard-only users. In this post, the first of a two-part series, we'll look at presenting accessible modals in Rails using two different approaches powered by Hotwire's Turbo and Stimulus libraries. But first, let's see what we need to do to make modals accessible.

In this post, we'll turn to the last piece of the puzzle in LiteStack: Litesearch. As an example, we will equip a prompts index page with a search bar to query a database for certain prompts. We will generate a couple of fake records to test our search functionality against. Let's get to it!

At Honeybadger, we use Ahoy for first-party analytics in Rails. Ahoy is excellent for developers because it lives in your Rails application alongside your other data and code. Want to answer a specific question about your product or website visitors? It's just one ActiveRecord query away: Ahoy also works with Chartkick and Groupdate to visualize your data.

In our last post, we looked at the basics of RSpec and explored how well it works with Behavior Driven Development in Ruby. Now, we will look at specific types of RSpec tests for different parts of a Ruby on Rails application. Let's dive straight in!

Reusable UI components are user interface widgets or elements that can be used in various places in a web project. These components are typically small and created for a specific functionality. Typically, you write the code once and then import the UI components wherever needed. For example, you can create a card component that displays certain information or have a navigation bar that will appear at the top of all web pages. Such UI elements can be imported and added to your desired web page.

In this series, we have looked at the "musts" (databases) and "shoulds" (asynchronous jobs, websockets) of a web application. Now we turn to one of the "coulds" (that is nonetheless recommended for scaling businesses): caching. In particular, we mean caching HTML fragments and other snippets of data, as referred to in Rails Guides. We are not concerned with HTTP or SQL query caching. In this part, we'll see how to speed up our Rails app using LiteCache.