In the beginning, Rails callbacks like after_save or after_commit feel like magic. You save a user, and—poof—a welcome email is sent. It’s easy, it’s fast, and it keeps your controller clean.

For years, Rails has provided seamless ways to respond with various data formats. Yet, SVG—despite being raw XML—often required manual workarounds. Developers typically had to manually set the image/svg+xml MIME type or create separate .erb templates just to wrap a string.

In Rails, we’ve always had ignored_columns to tell ActiveRecord: “Ignore these columns, even if they exist in the database.” But what if we want the opposite? What if we have a table with dozens of columns and our specific service only needs three?

Schemas are essential for organizing tables or managing multi-tenant architectures. While Rails has long supported basic database operations, renaming a schema used to require dropping down into raw SQL. Since Rails 7.0, the rename_schema method has brought this capability directly into the ActiveRecord migration DSL for those using PostgreSQL.

The methods update_columns and update_column are well-known for their speed because they bypass all Rails validations and callbacks. However, they had a major “side effect”: by default, they wouldn’t update the updated_at timestamp.

In Rails, we are used to using the .inquiry method on strings (like the famous Rails.env.development?). However, ActiveSupport also extends this functionality to Arrays, transforming a simple list into an object capable of answering questions semantically.

Every Rails developer is familiar with rails db:seed, the command used to populate the database with initial data. But what happens when you modify your seeds.rb file and want to start fresh without deleting the entire database? That’s where rails db:seed:replant comes in.

In Ruby, we often create modules to serve as libraries of utility functions. You’ve likely seen modules in various projects that use extend self right at the top. But what does it actually do, and why not just use def self.method?

Most Rails applications rely on the popular time_ago_in_words helper to show how much time has passed since an event. However, when dealing with future events or very recent dates, saying “in 20 hours” isn’t always the best way to communicate with a user.

current_user is a daily companion in Controllers and Views. However, the moment you need that information inside a Model to validate a business rule, things get tricky. Many developers end up passing the user as a parameter everywhere. But did you know Rails has a native solution for this?

ActiveRecord excels at providing methods that balance convenience and performance. Among the most powerful are delete_all and update_all, which execute bulk operations directly in SQL. However, until recently, they behaved inconsistently when used with certain query methods like limit or distinct.

ActiveRecord enums are a convenient way to map human-readable states to integers stored in the database. They make your models more expressive and your code easier to read. However, sorting records by enum values can be tricky when the default numeric order doesn’t match your business logic.

Rails provides two closely related routing helpers — resource and resources — and although they look similar, they serve different purposes. Understanding the distinction between them is essential for designing clean, intention-revealing routes in a Rails application.

This year, Rails introduced a new method for ActionMailer called deliver_all_later. This feature simplifies enqueuing multiple emails for delivery through Active Job. Instead of sending each email individually, you can now enqueue a batch of emails, allowing them to be sent asynchronously when their respective jobs run.

When building a Rails app, you often need to create navigation links that highlight the current page. However, Rails’ default current_page? helper only works with GET and HEAD requests. This can be problematic when dealing with forms or actions that use other HTTP methods like POST, PUT, or PATCH. This feature was introduced in this PR

Quick iteration and efficient debugging are crucial for productivity. One feature that has made its way into Rails 8.1.0 makes the debugging experience even smoother by allowing you to open the file that caused an error directly in your favorite editor — straight from the error page. No more manually searching for the file that triggered the issue.

Caching is one of the key techniques to optimize the performance of web applications, and Rails makes it easy to implement caching with various built-in helpers. These helpers help us cache fragments, partials, or even entire views, significantly reducing the load on your server by storing previously rendered content and reusing it when needed.

Securely handling user passwords is crucial; thankfully, Rails provides a straightforward and powerful method for password management with has_secure_password. This method ensures that passwords are never stored in plain text, making your applications more secure by default.

When building applications that require long-running background jobs, interruptions and restarts are inevitable. Whether due to server restarts, manual interventions, or just the natural limitations of background job queues, you need a way to make sure jobs can resume from where they left off.

Being able to detect changes in model attributes is often essential for building reactive, state-aware systems in Rails. Whether you’re logging updates, triggering side effects, or enforcing validations, it helps to know what a value used to be before it was changed.

For Rails developers, understanding how to effectively handle and report errors is a critical skill. With the introduction of the Error Reporter API in Rails 7, a standardized and powerful mechanism for managing exceptions across your application has emerged.

Have you ever found yourself writing a series of operations in Ruby that felt a bit too verbose? The then method, introduced in Ruby 2.6, is a clean and elegant way to chain transformations on a value, avoiding intermediate variables and improving code clarity.

In some API responses, it’s necessary to return plain text even when the original method outputs HTML. This can be challenging when the source method can’t be modified and the response format must follow strict requirements.

When working with ActiveModel::Serialization in a Ruby on Rails API, it’s common to organize serializers using inheritance—especially when building and maintaining different versions of your API.

Ruby 2.7 introduced a small but powerful method: tally. If you’ve ever written code to count how many times each item appears in a collection, you’re going to love this.