Ruby on Rails is the most popular web framework in the Ruby ecosystem and has a large user base, ranging from freelancers to large established companies. With an active user community and wide-ranging documentation, it can be used to build everything from simple applications to complex web platforms. That said, a new contestant is taking on Rails’ dominance for the full-stack Ruby framework title: Hanami.

The ability to record and see everything happening across your web applications is essential when building resilient and highly available systems. All of your events—from application logs to errors to user behavior—contain data that could be useful to you and your team. When you have a central place to access all this information, finding issues and their root causes becomes easier because you have the data at your fingertips.

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!