
Rails 8 makes it official: every new Rails app is now a **Progressive Web App by default** — complete with a `manifest.json`, service worker, and hooks for web push notifications via the upcoming Action Notifier framework.

This means Rails apps can now be installable, work offline, and send native-like push messages — without extra setup.

### Why PWAs matter

PWAs bridge the gap between web and native apps:

- Installable like a mobile app
- Launch without browser chrome
- Offline-capable
- Support for push notifications

Especially for B2C apps, being installable and having push capabilities can be make-or-break. With Rails 8, these features come out of the box.

### What's included in Rails 8

Rails 8 now scaffolds:

- `manifest.json.erb`: Defines the app name, icons, display behavior, and metadata
- `service-worker.js`: Registered automatically to enable offline caching and push
- Action Notifier (coming soon): A new framework to send push notifications

A recent [Rails PR (#50528)](https://github.com/rails/rails/pull/50528) added default PWA setup to every new app.

### Enabling the manifest

To make your Rails app installable on mobile:

1. Add `<link rel="manifest" href="/manifest.json">` to your layout
2. Ensure your manifest is served at `/manifest.json`
3. Add platform-specific icons:
   ```erb
   <link rel="icon" href="/logo.png" type="image/png">
   <link rel="apple-touch-icon" href="/logo.png">
   ```

Your app now prompts install in Chrome, Safari, Edge, and more.

Sample manifest:

```json
{
  "name": "My Rails App",
  "short_name": "RailsApp",
  "start_url": "/",
  "display": "standalone",
  "theme_color": "#f43f5e",
  "background_color": "#f43f5e",
  "icons": [{ "src": "/logo.png", "sizes": "512x512", "type": "image/png" }]
}
```

### Service worker basics

Rails 8 adds an empty service worker scaffold to get you started:

```js
// app/javascript/application.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js');
}
```

```js
// app/views/pwa/service-worker.js
self.addEventListener('install', () => console.log('Service Worker installed'));
self.addEventListener('activate', () =>
  console.log('Service Worker activated'),
);
```

You can extend it to handle caching and push notifications as needed.

### Push Notifications (coming soon)

The upcoming **Action Notifier** framework will power native-style push notifications with support for:

- Subscription handling
- VAPID keys
- Background delivery

This complements the service worker, making it easy to notify users even when they’re not actively using the app.

### Resources

- [PWA (Progressive Web Apps) in Rails 8](https://youtu.be/dU3Znt5E8Bg?si=ds-M17XSjPkVAgta)
- [Rails PR #50528 - Adds default pwa manifest and service worker](https://github.com/rails/rails/pull/50528)

### Summary

Rails 8 is now **PWA-ready by default**, removing all friction for developers who want modern app-like experiences.

You get:

- `manifest.json` and install prompts
- Service workers out of the box
- Hooks for push via Action Notifier

Whether you're building for mobile users, aiming for offline-first performance, or looking to boost engagement — Rails 8 sets the foundation right.


Rails 8 embraces PWA by default with manifest, service workers, and push notifications


Rails 8 introduces **Propshaft** as the new default asset pipeline, moving away from the long-standing **Sprockets** system. The goal? A leaner, faster, and more modern way to manage and serve static assets.

### Why Propshaft?

Sprockets had a good run, but it carried a lot of legacy baggage:

- Complex preprocessing layers
- Dynamic runtime compilation
- Heavy memory usage on large apps

Propshaft is a fresh start. It strips away unnecessary features and focuses on what matters today:

- Simpler configuration
- Faster builds
- Better CDN integration
- Seamless support for modern tools like Importmap, esbuild, and Tailwind CLI

### Key Features of Propshaft

- **Digest-based Caching**: Assets are fingerprinted at build time (e.g., `application-abc123.css`), ensuring cache busting without runtime overhead.
- **No Middleware**: Assets are served as static files—no dynamic pipeline in production.
- **Manifest-driven**: A YAML-based manifest maps logical filenames to their digested counterparts.
- **Logical Paths**: You reference files by name, and Propshaft handles the digested paths.
- **Multiple Asset Paths**: Organize assets across directories like `app/assets`, `vendor/assets`, or custom folders.
- **Zero Preprocessing**: Propshaft doesn't compile SCSS, CoffeeScript, or ERB—use external tools for that.

### Benefits Over Sprockets

```code
| Feature                | Sprockets              | Propshaft                  |
| -----------------------| ---------------------- | ---------------------------|
| Preprocessing          | Built-in               | External tools (ex.esbuild)|
| Fingerprinting         | Digest + runtime logic | Static digesting           |
| Middleware(production) | Yes                    | No                         |
| CDN-friendly           | Somewhat               | Fully                      |
| Performance            | Slower in large apps   | Fast and minimal           |
```

### Example: Migrating to Propshaft

For existing apps, switch to Propshaft with:

```bash
bundle remove sprockets-rails
bundle add propshaft
rails propshaft:install
```

Update `config/application.rb`:

```ruby
config.assets.pipeline = :propshaft
```

Then use:

```erb
<%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
<%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %>
```

### Developer Experience

Propshaft is Rails-y by nature:

- No Webpack needed
- Pairs great with Importmap, esbuild, or Tailwind CLI
- Easy to debug and reason about

It’s optimized for how Rails apps are built today—where JavaScript tooling is modular and asset delivery should be fast and reliable.

### When to Stick with Sprockets?

If your app heavily depends on Sprockets features like:

- SCSS/ERB preprocessing
- Directive-based requires (`//= require`)
- Inline asset compilation in views

...then consider keeping Sprockets or migrating gradually. But for new Rails 8 apps, **Propshaft is the way to go**.

### Summary

Propshaft is Rails 8’s modern answer to a cleaner, faster, and more maintainable asset pipeline. It offloads preprocessing, streamlines serving, and embraces the current frontend landscape—no magic, just files.

### Resources

- [Propshaft on GitHub](https://github.com/rails/propshaft)
- [Upgrading from Sprockets to Propshaft](https://github.com/rails/propshaft/blob/main/UPGRADING.md)


Rails 8 replaces Sprockets with Propshaft for asset pipeline


Rails 8 quietly revolutionizes real-time features with **Solid Cable**, a new database-backed adapter for ActionCable that eliminates the need for Redis.

### Why Solid Cable?

Before Rails 8, real-time updates via ActionCable typically required Redis as the pub/sub layer. But not every app needed that complexity. Solid Cable now lets you run ActionCable using just your existing database.

### How it Works

Solid Cable stores connection and subscription state in your database, and uses polling to check for new messages to broadcast. It’s fast enough for most use cases and especially helpful when keeping deployments lean.

In `cable.yml`, simply set the adapter to `solid_cable`:

```yaml
production:
  adapter: solid_cable
  connects_to:
    database:
      writing: cable
  polling_interval: 0.1.seconds
  message_retention: 1.day
```

You can configure:

- `polling_interval` – how often to check the DB (default: 0.1s)
- `message_retention` – how long to keep messages (default: 1 day)
- `autotrim` – whether to automatically delete old messages (default: true)

### Installation

For new Rails 8 apps, it’s already there. For older versions, you can add it manually:

```bash
bundle add solid_cable
bin/rails solid_cable:install
```

This sets up:

- The `config/cable.yml` file
- A cable-specific schema in `db/cable_schema.rb`

To use a separate database for Solid Cable (recommended), add the following to `config/database.yml`:

```yaml
production:
  primary:
    <<: *default
    database: app_production
  cable:
    <<: *default
    database: app_production_cable
    migrations_paths: db/cable_migrate
```

Then run:

```bash
RAILS_ENV=production bin/rails db:prepare
```

### Single Database Setup (Optional)

If you prefer to use just one DB:

- Copy the content of `db/cable_schema.rb` into a regular migration
- Delete `db/cable_schema.rb`
- Remove `connects_to` from `cable.yml`
- Run `bin/rails db:migrate`

### Performance and Use Cases

Solid Cable performs well under most conditions — even with polling — and supports MySQL, PostgreSQL, and SQLite. It’s ideal for:

- Apps with **moderate real-time usage**
- Deployments on **Heroku**, **Fly.io**, or **serverless**
- Teams looking to reduce external dependencies

If you're building high-frequency features like chat apps or live games, Redis may still offer better throughput. But for dashboards, notifications, or UI updates, Solid Cable is more than capable.

You can even turn off `autotrim` and manually manage old messages using:

```ruby
SolidCable::TrimJob.perform_later
```

### References

- [Rails PR #52889 – Adds Solid Cable](https://github.com/rails/rails/pull/52889)
- [Rails Solid Cable Overview](https://youtu.be/bOlrHbhLzZE?si=d2csp5fzNj2tt6as)
- [Solid Cable - A database backed ActionCable adapter ](https://github.com/rails/solid_cable)

### Summary

Solid Cable makes real-time Rails easier than ever—no Redis required. It's a built-in, production-ready solution for teams who want modern UI updates without extra services or deployment complexity.


Rails 8 adds Solid Cable a database-backed ActionCable (no Redis needed)


Ruby 3.3 brings two major under-the-hood updates: the **Prism parser** and the **RJIT compiler**.

These experimental features are aimed at making Ruby faster, more consistent, and more compatible with tools like linters, syntax checkers, and future language evolution.

### What is Prism?

Prism is a new parser written in C and built with modern compiler techniques. It aims to replace the legacy `Ripper` parser and provides a full-fidelity AST (Abstract Syntax Tree).

This allows better tooling, static analysis, and possibly safer syntax-level transformations.

### What is RJIT?

RJIT (Ruby JIT) is a new in-process JIT compiler intended to eventually replace MJIT. It’s simpler, more portable, and focused on real-world production performance, especially in Rails apps.

### Why it matters

- Prism will improve RuboCop, IDEs, and dev tools
- RJIT brings runtime speed improvements
- Both are modular and future-ready
- Enables a better language server (LSP) in Ruby tooling

### Enabling RJIT

In Ruby 3.3, RJIT is experimental and off by default. Enable it with:

```bash
ruby --enable-rjit my_script.rb
```

### Resources

- [Ruby 3.3 Release Notes](https://www.ruby-lang.org/en/news/2023/12/25/ruby-3-3-0-released/)
- [GitHub - Prism](https://github.com/ruby/prism)
- [Prism Documentation](https://ruby.github.io/prism/)
- [Ruby RJIT Doc](https://docs.ruby-lang.org/en/3.3/rjit/rjit_md.html)

### Summary

Prism and RJIT mark a new era for Ruby internals — laying the foundation for faster execution, better tooling, and a smoother developer experience in future Ruby versions.


Ruby 3.3 introduces the new Prism parser and RJIT compiler


Rails 7.1 introduces support for **SQLCommenter** format in Active Record query logs — enabling developers to tag SQL queries with contextual metadata like controller, action, job name, or even custom attributes.

This feature brings improved visibility into which part of your Rails app generated a given SQL query, especially useful when inspecting logs or working with APM tools like Datadog, New Relic, or Scout.

### What it looks like

With query tagging enabled, Rails appends metadata as SQL comments at the end of the generated queries:

```sql
SELECT * FROM users
/*application='MyApp',controller='UsersController',action='index'*/
```

This makes it easier to track down expensive or unexpected queries directly to their source — be it a controller action, background job, or specific tenant.

### How to enable SQLCommenter in Rails 7.1

In `config/application.rb` (or in an environment-specific config like `production.rb`):

```ruby
config.active_record.query_log_tags_enabled = true
```

By default, Rails will include the following tags:

```ruby
config.active_record.query_log_tags = [:application, :controller, :action, :job]
```

These tags correspond to common runtime contexts — controller and action for web requests, and job for background workers.

### Adding custom query tags

You can go further and add custom tags using a Hash. For example:

```ruby
config.active_record.query_log_tags = [
  :namespaced_controller,
  :action,
  :job,
  {
    request_id: ->(context) { context[:controller]&.request&.request_id },
    job_id: ->(context) { context[:job]&.job_id },
    tenant_id: -> { Current.tenant&.id },
    static: "dashboard"
  }
]
```

These are evaluated per request or job, and Rails automatically omits tags with `nil` values.

### Other useful options

##### Cache tags per request or job

To improve performance when tags don’t change during the request lifecycle:

```ruby
config.active_record.cache_query_log_tags = true
```

##### Prepend instead of append

If you prefer seeing the comments **before** the query (instead of after), enable:

```ruby
ActiveRecord::QueryLogs.prepend_comment = true
```

### Why this matters

- Debug slow queries faster by tracing them back to controller or job.
- Enhance observability in APM dashboards with full request context.
- Simplify performance profiling and query auditing.

### Summary

Rails 7.1 makes query tracing easier with built-in SQLCommenter tagging support. Whether you're debugging locally or tracking performance in production, being able to map queries to application context is a huge win for observability. Check out [API For Active Record Query Logs](https://api.rubyonrails.org/v7.1/classes/ActiveRecord/QueryLogs.html) for more details.


Rails 7.1 tags database queries with SQLCommenter for debugging


Token-based workflows like password resets, email confirmations, and invitation flows are everywhere in Rails apps. Rails 7.1 introduces a built-in way to handle them securely and declaratively with `generates_token_for`.

This eliminates boilerplate and external gems, making token handling feel like native Rails magic.

### What is `generates_token_for`?

It's a declarative API that generates **signed, tamper-proof tokens** scoped to your models and purposes. You can also add expiration and validations.

Under the hood, it uses `ActiveSupport::MessageVerifier`.

### Basic usage

```ruby
class User < ApplicationRecord
  generates_token_for :password_reset, expires_in: 15.minutes
end
```

Generate a token:

```ruby
token = user.generate_token_for(:password_reset)
```

Find the user from token:

```ruby
user = User.find_by_token_for(:password_reset, token)
```

Raise an error instead of returning `nil` if invalid:

```ruby
user = User.find_by_token_for!(:password_reset, token)
```

### Token lifecycle and block validation

You can optionally pass a block to `generates_token_for` that defines what makes the token valid. The return value is stored in the token and checked during lookup.

```ruby
class User < ApplicationRecord
  generates_token_for :name_confirmation, expires_in: 24.hours do
    name
  end
end
```

This means if the user’s name changes, the token becomes invalid—even before expiry.

```ruby
user = User.create!(name: "John Doe")
token = user.generate_token_for(:name_confirmation)

User.find_by_token_for(:name_confirmation, token) # => user

user.update!(name: "Jane Doe")
User.find_by_token_for(:name_confirmation, token) # => nil
```

If no block is given, the token only expires after the `expires_in` duration.

### Real-world examples

#### Password Reset

```ruby
class User < ApplicationRecord
  generates_token_for :password_reset, expires_in: 30.minutes
end

url = edit_password_url(token: user.generate_token_for(:password_reset))
```

#### Invite Token

```ruby
class Invitation < ApplicationRecord
  generates_token_for :invite, expires_in: 2.days
end

url = accept_invitation_url(token: invitation.generate_token_for(:invite))
```

#### Auth Token (no expiry)

```ruby
class User < ApplicationRecord
  generates_token_for :auth_token
end

token = user.generate_token_for(:auth_token)
```

This token won’t expire and remains valid even if attributes change.

### Bonus: Expiry vs Block

```
Configuration                    | Expires?        | Invalidated on update?
---------------------------------|------------------|-------------------------
`expires_in` only                | ✅ Yes (time)     | ❌ No
Block only                       | ❌ No             | ✅ Yes
Both `expires_in` and block      | ✅ Yes (time)     | ✅ Yes
None                             | ❌ No             | ❌ No
```

### References

- [Rails 7.1 release notes](https://guides.rubyonrails.org/7_1_release_notes.html#add-activerecord-base-generates-token-for)
- [API Docs](https://api.rubyonrails.org/v7.1/classes/ActiveRecord/TokenFor/ClassMethods.html#method-i-generates_token_for)

### Summary

`generates_token_for` is a long-awaited addition that simplifies token-based workflows in Rails apps. It’s clean, secure, flexible, and comes with zero setup. Whether you're building email confirmations, one-time links, or long-lived auth tokens—this API has you covered.


Rails 7.1 adds generates_token_for for easy token generation


Rails 7.1 introduces a subtle but impactful improvement to enum handling with the addition of the `validate` option.

### The Problem Before

Enums have long been used in Rails to map symbolic values to integers — perfect for roles, states, or types. But assigning invalid enum values silently passed validation:

```ruby
class Holiday < ApplicationRecord
  enum kind: [:national, :regional]
end

holiday = Holiday.new(kind: :optional)
holiday.valid? # => true
```

In this case, `:optional` isn't even defined in the enum, yet no error is raised until it's saved, which causes an `ArgumentError`. That’s not great DX.

### What’s New in Rails 7.1

Rails 7.1 now lets you enforce value-level validations with `validate: true`:

```ruby
class Holiday < ApplicationRecord
  enum kind: [:national, :regional], validate: true
end

holiday = Holiday.new(kind: :optional)
holiday.valid? # => false
holiday.errors[:kind] # => ["is not a valid kind"]
```

No more ArgumentErrors. Just clean, predictable validation failures.

### Optional Enhancements

You can customize the validation further. For example, to allow `nil` as a valid value:

```ruby
class Holiday < ApplicationRecord
  enum kind: [:national, :regional], validate: { allow_nil: true }
end
```

Now `holiday.kind = nil` passes, but invalid values still fail validation.

### Why It Matters

This change brings enums in line with the rest of Rails' validation philosophy — **fail fast and fail clearly**.

It’s especially helpful for apps accepting enum values via API params or forms, where invalid data might sneak in.

### References

- [PR #49100 – Adds validate option for enums](https://github.com/rails/rails/pull/49100)
- [Rails 7.1 Release Notes](https://guides.rubyonrails.org/7_1_release_notes.html)

### Summary

Enums are safer now. With `validate: true`, Rails 7.1 lets your models reject invalid values before they hit the database — no surprises, just clean validations.


Rails 7.1 introduces enum validate option for stricter ActiveRecord enums


Rails 7.1 introduces `perform_all_later`—a new method in ActiveJob that lets you enqueue multiple jobs at once. This is especially useful when dispatching a high volume of background tasks, where traditional approaches could overwhelm your queue adapter.

### The problem with enqueuing many jobs individually

Previously, enqueuing jobs looked like this:

```ruby
User.find_each do |user|
  EmailNotificationJob.perform_later(user.id)
end
```

This approach is fine for small datasets, but under the hood, each `perform_later` makes a separate round trip to your queue backend (like Redis if you're using Sidekiq), which becomes inefficient at scale.

### The `perform_all_later` upgrade

Rails 7.1 now gives us:

```ruby
ActiveJob.perform_all_later([job1, job2, job3])
```

This bulk API reduces Redis chatter by utilizing the `push_bulk` feature (where supported, e.g., by Sidekiq), cutting down enqueuing time significantly.

### Real-world usage

```ruby
email_notification_jobs = users.map do |user|
  EmailNotificationJob.new(user.id)
end

ActiveJob.perform_all_later(email_notification_jobs)
```

You can also add scheduling per job:

```ruby
email_notification_jobs = users.map.with_index do |user, index|
  EmailNotificationJob.new(user.id).set(wait: index.seconds)
end

ActiveJob.perform_all_later(email_notification_jobs)
```

It even supports different job classes:

```ruby
ActiveJob.perform_all_later([
  EmailNotificationJob.new(user.id),
  SignUpNotificationJob.new(user.id)
])
```

### What to keep in mind

- If your queue adapter doesn’t support bulk enqueuing, Rails will fall back to enqueuing jobs one by one.
- No callbacks (like `before_enqueue`, `before_perform`, etc.) are run for these jobs.
- Returns `nil` instead of a job object.
- Internally uses a new event: `enqueue_all.active_job`.

### References

- [PR #46603 - Adds perform_all_later](https://github.com/rails/rails/pull/46603)
- [Rails 7.1 Release Notes](https://guides.rubyonrails.org/7_1_release_notes.html#add-perform-all-later-to-enqueue-multiple-jobs-at-once)

### Summary

`perform_all_later` is a clean and powerful API for batching background jobs. It's perfect for sending thousands of notifications, onboarding flows, or any scenario where multiple jobs need to be queued efficiently.

You get:

- Reduced latency
- Less Redis traffic
- Cleaner code

Another small but mighty addition in Rails 7.1 that makes a big difference at scale.


Rails 7.1 adds perform_all_later to enqueue multiple jobs at once


Rails 7.1 now ships with **default Docker configuration** for every new app, making containerization and deployment to production easier, faster, and consistent across environments.

### What’s included?

When you run:

```bash
rails new myapp
```

Rails will generate:

- `Dockerfile`
- `.dockerignore`
- `bin/docker-entrypoint`

These files serve as a **production-ready Docker setup** to help you ship your Rails app with confidence.

⚠️ Note: These files are optimized for deployment, **not local development**.

### Run your app with Docker

Here’s how you can containerize and run your new app using the generated config:

```bash
docker build -t blog-app .
docker volume create app-storage
docker run --rm -it -v app-storage:/rails/storage -p 3000:3000 --env RAILS_MASTER_KEY=<your-master-key> blog-app
```

Want to start a Rails console?

```bash
docker run --rm -it -v app-storage:/rails/storage --env RAILS_MASTER_KEY=<your-master-key> blog-app console
```

### Building Multi-platform Images

Deploying to Apple Silicon, Intel, or ARM? Rails makes it easy to prepare your app for any architecture:

```bash
docker login -u <your-docker-username>
docker buildx create --use
docker buildx build --push --platform=linux/amd64,linux/arm64 -t <your-user/image-name> .
```

### Bonus: Docked CLI for local dev

If you want to bootstrap a Rails app without worrying about system dependencies, try `docked`. It uses a pre-built Docker image for a smooth Rails experience:

```bash
docker volume create ruby-bundle-cache
alias docked='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle -p 3000:3000 ghcr.io/rails/cli'

docked rails new blog-app
cd blog-app
docked rails generate scaffold post title:string body:text
docked rails db:migrate
docked rails server
```

No local Ruby or Node setup needed — just Docker.

### Links

- [PR #46762 – Adds Dockerfile generation](https://github.com/rails/rails/pull/46762)
- [Rails 7.1 release notes](https://guides.rubyonrails.org/7_1_release_notes.html#generate-dockerfiles-for-new-rails-applications)

### Summary

Rails 7.1 adds first-class Docker support for new apps. You get ready-to-use Dockerfiles, production-ready entrypoints, and a cleaner path to building and deploying containerized Rails apps. Whether you're targeting Fly.io, Render, Railway, or your own VPS, you're ready to ship on day one.


Rails 7.1 generates Docker config by default for new apps


Basecamp has officially released **Kamal 1.0** (previously MRSK), solidifying it as a powerful and stable deployment tool for Ruby on Rails and other Dockerized web apps.

This 1.0 milestone marks Kamal as a **production-ready**, opinionated solution for **zero-downtime deploys** without relying on cloud-specific services or DevOps overhead.

### What’s New in 1.0?

- Improved multi-host orchestration
- Tighter support for Docker Compose and health checks
- Native support for persistent volumes and secrets
- Rolling deploys with automatic cleanup
- Simplified rollback and restart mechanisms

### Why Kamal over other tools?

```
Tool         | Pros                                 | Cons
-------------|--------------------------------------|-----------------------------
Capistrano   | Time-tested, SSH-based               | No container support, slow
Kubernetes   | Scalable, cloud-native               | Overkill for most Rails apps
Heroku       | Super simple                         | Vendor lock-in, expensive
Kamal        | Simple, Docker-native, zero-downtime | Self-hosting required
```

Kamal aims to **strike the balance** — giving you full control and performance without giving up simplicity.

### Typical Deploy Flow

1. Configure `config/deploy.yml`
2. Build and push Docker image
3. Run `kamal deploy`
4. Kamal rolls out the new release without downtime
5. Rollback instantly if needed

```bash
kamal deploy
kamal rollback
```

### Ideal For

- Rails and Dockerized apps
- Teams moving off Heroku or Render
- Self-hosted infrastructure
- Simple CI/CD pipelines

### Resources

- [Kamal GitHub Repo](https://github.com/basecamp/kamal)
- [Kamal Docs](https://kamal-deploy.org)
- [Deploying Rails with Kamal Guide](https://kamal-deploy.org/v1/docs/installation/)

### Final Thoughts

With Kamal 1.0, deploying Rails apps with Docker is finally elegant, repeatable, and reliable. Whether you're building SaaS apps, APIs, or monoliths, Kamal makes self-hosted deploys frictionless and modern.


Kamal 1.0 released – a containerized deployment tool for Rails


In Feb 2023, Basecamp released **Kamal** (formerly MRSK) — a deployment tool designed to make **zero-downtime deploys** simple, fast, and infrastructure-independent.

Kamal is opinionated, Docker-based, and avoids cloud-specific lock-in by relying on SSH and Docker Compose. It’s a modern replacement for tools like Capistrano and Heroku pipelines for self-hosted Rails apps.

### What is Kamal?

Kamal is an open-source deployment tool created by [@dhh](https://twitter.com/dhh), inspired by the simplicity of Heroku but designed for **self-hosted environments**. It focuses on:

- Zero-downtime deployments
- Simple configuration
- Docker-first approach
- No vendor lock-in
- Fast rollback

Kamal deploys your Rails app as a set of containers across one or more remote servers using SSH, Docker, and Docker Compose.

### How does Kamal work?

Here’s the basic flow:

1. You define your app and servers in a `deploy.yml` file.
2. Kamal builds a Docker image locally or remotely.
3. It pushes the image to your servers.
4. Kamal performs a rolling update using Docker containers.
5. Nginx or Traefik handles traffic routing with zero downtime.

```bash
kamal init
# Creates config/deploy.yml

kamal deploy
# Deploys your app across all defined servers
```

You can also rollback instantly:

```bash
kamal rollback
```

### Key Features

- ✅ **Zero-downtime deploys** with rolling restarts
- ✅ **Docker-native** with simple container orchestration
- ✅ **Configurable load balancing** (Nginx, Traefik, HAProxy)
- ✅ **Integrated asset building**
- ✅ **Built-in health checks**
- ✅ **Environment parity with production**

### Why Kamal?

For years, Capistrano and cloud PaaS platforms (Heroku, Render) have dominated Rails deployments. Kamal offers:

- More **control** than Heroku
- Less **complexity** than Kubernetes
- Better **developer experience** than Capistrano
- Complete **Docker parity** with local and prod

It’s great for teams who want to:

- Host Rails apps on their own servers
- Avoid cloud lock-in
- Deploy in edge or hybrid environments

### Real-World Setup Example

Your `deploy.yml` might look like this:

```yaml
service: myapp
image: myregistry.com/myapp
servers:
  web:
    hosts:
      - 192.168.0.2
      - 192.168.0.3
env:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
```

Kamal handles the build, push, and deployment process for you — all without touching AWS CLI, Terraform, or Kubernetes.

### Links

- [Kamal GitHub repo](https://github.com/basecamp/kamal)
- [Kamal documentation](https://kamal-deploy.org)
- [Announcement blog post by DHH](https://world.hey.com/dhh/introducing-kamal-9330a267)

### Summary

Kamal is a bold step forward in Rails deployment simplicity. If you’ve ever wanted Heroku-like ease without the vendor lock-in — or you're tired of fiddling with Capistrano — Kamal is worth exploring. It makes Dockerized Rails deploys predictable, fast, and production-ready with minimal overhead.


Basecamp unveils Kamal (MRSK) for zero-downtime Rails deploys


Ruby 3.2 introduces a new core class called `Data`, a lightweight way to define **immutable value objects** with less boilerplate. It’s ideal for modeling plain data structures where mutability isn’t needed and immutability is a benefit.

This addition helps Ruby stay competitive with modern language features, offering similar benefits to `Struct`, but with stricter immutability and improved pattern matching compatibility.

### What is the `Data` class?

The `Data` class is a subclass of `Object` that behaves much like `Struct`, but with **immutable attributes** and **value equality** out of the box.

Here’s how to define and use it:

```ruby
Person = Data.define(:name, :age)

john = Person.new("John", 30)

john.name
# => "John"

john.age
# => 30
```

Unlike `Struct`, trying to change `john.name` will raise an error:

```ruby
john.name = "Mike"
# => NoMethodError (undefined method `name=')
```

### Why use `Data` over `Struct`?

```code
| Feature                   | Struct            | Data                       |
| ------------------------- | ----------------- | -------------------------- |
| Mutable                   | ✅ Yes            | ❌ No (immutable)          |
| Value-based equality      | ✅ Yes            | ✅ Yes                     |
| Built-in pattern matching | ⚠️ Limited        | ✅ Fully supported         |
| Safer for modeling        | ❌ Prone to bugs  | ✅ Encourages immutability |
```

If you don’t want your object’s state to change after initialization, `Data` is the better choice. This is especially useful when you’re working with domain models, value objects, or functional-style programming.

### Pattern Matching Support

The `Data` class is **optimized for pattern matching**, a feature introduced in Ruby 2.7 and improved in later versions.

```ruby
case john
in Person(name:, age:)
  puts "Name: #{name}, Age: #{age}"
end
# => Name: John, Age: 30
```

Pattern matching works seamlessly and makes destructuring data objects intuitive.

### Real-world Use Cases

- Value objects in DDD (Domain-Driven Design)
- Lightweight DTOs (Data Transfer Objects)
- Parameters passed across service layers
- Declarative and functional code styles

### Notes

- The `Data` class is immutable and does not support custom instance methods by default.
- You can still add methods via class reopening:

```ruby
Person = Data.define(:name, :age)

class Person
  def greeting
    "Hello, #{name}!"
  end
end

john.greeting
# => "Hello, John!"
```

### Resources

- [Ruby 3.2 Release Notes](https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/)
- [Data Class Proposal](https://bugs.ruby-lang.org/issues/16122)
- [PR #6353 - Adds Data Class](https://github.com/ruby/ruby/pull/6353)

### Summary

Ruby’s new `Data` class is a welcome addition for developers who want clean, immutable, and efficient value objects with minimal syntax. It simplifies functional programming and domain modeling in Ruby, and its native support for pattern matching makes it a powerful new primitive in the language.


Ruby 3.2 introduces Data class for immutable value objects


With Ruby 3.2, developers can now compile Ruby code to WebAssembly using WASI (WebAssembly System Interface). This marks a significant step toward making Ruby applications portable across platforms like browsers, edge devices, and even serverless runtimes.

### What is WASI?

WASI stands for **WebAssembly System Interface** — a standardized set of APIs that give WebAssembly modules access to system-like features such as files, clocks, environment variables, and more. It allows WebAssembly to run in environments **outside the browser** safely and securely.

### Why Ruby in WebAssembly?

Historically, Ruby has been tightly coupled to its native system runtime. This made it difficult to run Ruby scripts in sandboxed environments like browsers or edge compute services. But with WASI support, you can now:

- Embed Ruby scripts in WebAssembly runtimes
- Run Ruby in the browser (with limited I/O)
- Deploy Ruby logic to edge functions or CDNs
- Experiment in isolated, reproducible environments

This is a foundational shift, enabling Ruby to be more portable, embeddable, and accessible in polyglot environments.

### How to Try It

The Ruby core team has created [ruby.wasm](https://github.com/ruby/ruby.wasm) — a project that compiles Ruby to WebAssembly and provides tools to run it in WASI-compatible runtimes.

Here’s how to get started:

```bash
git clone https://github.com/ruby/ruby.wasm
cd ruby.wasm
make setup
make build
```

You can also try it directly in the browser via the hosted playground:

👉 [https://livecodes.io](https://livecodes.io/?template=ruby-wasm)

Or run `.wasm` files using runtimes like Wasmtime or Wasmer:

```bash
wasmtime ruby.wasm --eval 'puts "Hello from WASI Ruby!"'
```

### Use Cases

- Interactive Ruby tutorials in the browser
- WASM-powered Ruby CLIs embedded in web UIs
- Edge deployments with tools like Fastly or Cloudflare Workers (WASI-based)
- Ruby playgrounds and sandboxes for teaching or demos

While you can’t yet run a full Rails app in WASM, this opens the door to future frameworks or mini-Rack-style implementations in the browser.

### Limitations

Ruby’s WASI support is still **experimental**. A few limitations include:

- No support for threads, sockets, or some native gems
- Limited system calls and file system access
- Only basic I/O support via stdout and stdin

Still, it's promising — especially for lightweight Ruby logic and experimentation.

### References

- [Ruby 3.2 Release Announcement](https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/)
- [GitHub Repo - ruby.wasm](https://github.com/ruby/ruby.wasm)
- [GitHub Repo - WASI (WebAssembly System Interface)](https://github.com/WebAssembly/WASI)
- [Wasmtime - A lightweight WebAssembly runtime](https://github.com/bytecodealliance/wasmtime)
- [WebAssembly (Wasm) Standard - Official Site](https://wasi.dev)
- [WebAssembly - Official Site](https://webassembly.org/)

### Final Thoughts

Ruby 3.2’s WASI support is one of the boldest moves toward modernizing Ruby’s deployment story. While still early, it represents a new era — where Ruby can live beyond servers, breaking into browsers, embedded platforms, and serverless worlds.


Ruby 3.2 adds WebAssembly (WASI) support to the Ruby VM


Ruby 3.1 introduces **YJIT** (Yet Another Ruby JIT), an **in-process just-in-time compiler** developed by Shopify, designed to boost performance for real-world Ruby applications—especially Rails.

### What is YJIT?

- Built directly into CRuby
- Uses Basic Block Versioning (BBV)
- Optimizes Ruby code incrementally, compiling only what’s needed
- Targets fast warm-up and real-world speedups
- Currently experimental and supported only on Unix-like x86-64 platforms

YJIT compiles Ruby bytecode to native machine code dynamically, giving us the speed of compiled code with the flexibility of interpretation.

### How to enable YJIT

YJIT is **disabled by default**. To turn it on:

```bash
ruby --yjit your_app.rb
```

Or check if your Ruby version supports it:

```bash
ruby --enable-yjit -v
```

### Real-world Performance

Benchmarks from the YJIT team show:

- 🚀 20% speedup on railsbench
- 🚀 37% improvement on ActiveRecord-heavy queries
- 🚀 39% boost on liquid template rendering

These wins are achieved **without any code changes**—just enable the flag.

### Example

```bash
RUBY_YJIT_ENABLE=1 ruby --yjit app.rb
```

Once enabled, your Ruby code benefits from just-in-time optimizations behind the scenes, especially in long-running apps.

### How YJIT works

YJIT starts by compiling just the beginning of a method (lazy BBV), and compiles more as it learns the types of values being passed around. This makes it fast to start and adaptive over time.

Unlike MJIT (Ruby’s older method-based compiler), YJIT doesn’t rely on an external C compiler and avoids the compilation latency that held MJIT back in production workloads.

### TL;DR: YJIT vs MJIT vs TenderJIT

```code
| Feature       | YJIT             | MJIT             | TenderJIT           |
|---------------|------------------|------------------|---------------------|
| Compiler Type | Basic Block JIT  | Method-based JIT | Ruby-based JIT (WIP)|
| Platform      | x86-64 only      | Cross-platform   | Experimental        |
| Use Case      | Real-world apps  | Benchmarks       | Research/Exploration|
| In-process    | Yes              | No(uses C compiler)| Yes               |
```

### Summary

YJIT is a huge step forward for Ruby performance. With fast warmup, real-world optimization, and seamless integration into CRuby, Ruby 3.1 becomes faster with no extra work for developers.

Just add `--yjit` and enjoy the speed boost.

### References

- [Shopify: YJIT architecture deep dive](https://shopify.engineering/yjit-just-in-time-compiler-cruby)
- [Ruby Proposal to merge YJIT](https://bugs.ruby-lang.org/issues/18229)
- [Ruby 3.1 release notes](https://www.ruby-lang.org/en/news/2021/12/25/ruby-3-1-0-released/)


Ruby 3.1 integrates YJIT compiler for faster execution


Rails has always had a mixed relationship with JavaScript. But like it or not, modern web development needs JavaScript—and Rails 7 embraces it with a new approach.

### Before: Webpacker

Since Rails 5.2, JavaScript in Rails apps was handled through [Webpacker](https://github.com/rails/webpacker/), which bundled JS using Webpack. It worked well for its time, but had some drawbacks:

- Required Node, Yarn, and a JS toolchain
- Compilation delays
- Digest-based filenames (e.g., `main-a6d26cef.js`) made caching tricky

As browsers matured and JavaScript standards evolved, the need for bundling and transpilation decreased.

### After: Importmaps + Hotwire

Rails 7 replaces Webpacker with **importmapped Hotwire** as the default JavaScript setup. No Node, no Webpack, no bundling.

#### Why this matters

- **ES6 is now widely supported**, so there's no need to transpile code for modern browsers
- **HTTP/2 removes the penalty for loading many small files**, reducing the need for giant bundles
- **Importmaps allow referencing JS modules by name**, avoiding fingerprinted filenames and recompile cycles

This results in faster boot times, leaner apps, and less infrastructure complexity.

### New Options with `rails new`

Rails 7 introduces a few new options when scaffolding an app:

- `rails new myapp`  
  Installs `importmap-rails`, `turbo-rails`, and `stimulus-rails`. No Node, Yarn, or package.json.

- `rails new myapp --skip-hotwire`  
  Includes `importmap-rails` only, without Turbo or Stimulus.

- `rails new myapp --skip-javascript`  
  No JavaScript setup at all.

- `rails new myapp --webpack`  
  Brings back the Webpack setup from Rails 6. Includes Hotwire by default.

- `rails new myapp --webpack --skip-hotwire`  
  Classic Webpack setup without Hotwire.

### References

- [PR #42999 – Adds importmaps](https://github.com/rails/rails/pull/42999)
- [Modern web apps without JavaScript bundling or transpiling](https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755)

### Summary

With importmaps and Hotwire, Rails 7 streamlines the JavaScript setup for modern apps. You get a full-featured experience without the overhead of Node or bundlers—Rails stays true to its roots of convention over configuration, while still staying modern.


Rails 7 embraces importmap for JavaScript without Node.js


Rails 7 adds `load_async`, a new ActiveRecord method that schedules SQL queries to run on a background thread pool. This allows independent queries to be executed in parallel—saving time, reducing I/O wait, and improving controller performance.

### Why it matters

In many Rails controllers, we often load multiple unrelated datasets:

```ruby
@car_types = CarType.all
@cars = Car.order(released_at: :desc)
```

These queries are executed sequentially, which means we spend time waiting on each I/O operation one after another. If each query takes 50ms, that’s 100ms total. But if performed in parallel, we could reduce that to 50ms.

### Before Rails 7

A naive attempt might involve spinning up a raw thread:

```ruby
car_types_future = Thread.new { CarType.all.to_a }
@cars = Car.order(released_at: :desc).to_a
@car_types = car_types_future.value
```

But this introduces all sorts of thread-safety concerns, especially around `CurrentAttributes`, ActiveSupport instrumentation, and request-local state. It's brittle and hard to manage.

### The Rails 7 approach

Now with `load_async`, you can do:

```ruby
@car_types = CarType.all.load_async
@cars = Car.order(released_at: :desc).load_async
```

Each query runs in a background thread from a dedicated pool. When you access the result later, Rails ensures the query has completed—either in the background or, if necessary, in the foreground.

The actual instantiation of models still happens on the main thread, so there's no risk of thread-safety issues with Rails internals.

### Summary

`load_async` makes it effortless to overlap I/O for unrelated database queries in your controllers. It’s a simple yet powerful way to improve responsiveness in Rails apps—no thread hacks, no extra gems, just built-in Rails magic. Check out this [Pull Request](https://github.com/rails/rails/pull/41372) for more details.


Rails 7 adds load_async to ActiveRecord for parallel queries


Before Rails 7, encrypting attributes in Active Record models meant relying on third-party gems like `lockbox`. While effective, these added external dependencies and complexity.

Rails 7 brings first-class **Active Record Encryption** support, letting you securely store sensitive data with minimal setup and without external gems.

### How Active Record Encryption works

You can now mark model attributes to be encrypted like this:

```ruby
class User < ApplicationRecord
  encrypts :passport_number
end
```

Once configured, Rails will automatically encrypt `passport_number` before saving it to the database and decrypt it transparently when reading.

Behind the scenes, Rails uses AES-GCM encryption (non-deterministic by default) and the new `EncryptableRecord` concern.

### Setup

To get started, you’ll need to initialize encryption keys. Run the following command:

```bash
bin/rails db:encryption:init
```

This generates keys and salts in `config/credentials.yml.enc`:

```yaml
active_record_encryption:
  primary_key: <generated-key>
  deterministic_key: <generated-key>
  key_derivation_salt: <generated-salt>
```

These secrets are required to securely encrypt and decrypt the data.

### Example in action

```ruby
user = User.create(name: "Gaurav", passport_number: "DK76FS87DF")
```

When saved, the value of `passport_number` is encrypted in the DB But when queried:

```ruby
User.last.passport_number
# => "DK76FS87DF"
```

### Features

- Built-in AES-GCM encryption
- Per-attribute encryption support
- Key rotation
- Optional deterministic mode for searchable encrypted fields
- No extra gems required

### References

- [Rails Active Record Encryption Guide](https://guides.rubyonrails.org/v7.0/active_record_encryption.html)
- [Rails PR #41659 - Adds Active Record Encryption](https://github.com/rails/rails/pull/41659)

### Summary

Rails 7 introduces native, secure encryption for Active Record attributes—making it easier than ever to protect sensitive user data like SSNs, credit card numbers, or passport IDs. It’s opinionated, flexible, and ready for production use out of the box.


Rails 7 adds Active Record Encryption for sensitive data


Rails
[Active Support](https://guides.rubyonrails.org/active_support_core_extensions.html)
provides various extensions, utilities, and helpers. It provides a collection of
utility classes and standard library extensions that are very useful.

Rails 5.1 introduced `assert_no_changes` and `assert_changes` making it easier
to observe changes. Using
[ActiveSupport::TestCase#assert_no_changes](https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_no_changes)
we can easily assert that the result of evaluating an expression has not changed
before and after calling the passed block.

To assert the expected change in the value of an object we can use
`assert_changes`.

```ruby
assert_changes -> { user.address } do
  user.update address: 'Miami'
end
```

`assert_changes` also supports `from` and `to` options.

```ruby
assert_changes -> { user.address }, from: 'San Francisco', to: 'Miami' do
  user.update address: 'Miami'
end
```

Similarly, `assert_no_changes` allows us to assert a value that is expected to
not change.

```ruby
assert_no_changes -> { user.address } do
  user.update address: 'Miami'
end
```

We can also specify an error message with `assert_no_changes`.

```ruby
assert_no_changes -> { user.address }, 'Expect the address to not change' do
  user.update address: 'Miami'
end
```

### Before

`assert_no_changes` did not support the `from` option similar to
`assert_changes`.

```ruby
assert_no_changes -> { user.address } do
  user.update address: 'Miami'
end
```

However,
[Rails 7 has added from: option to ActiveSupport::TestCase#assert_no_changes](https://github.com/rails/rails/pull/42277),
allowing us to assert on the initial value that is expected to not change.

### Rails 7 onwards

Provides the optional `from` argument to specify the expected initial value.

```ruby
assert_no_changes -> { user.address }, from: 'San Francisco' do
  user.update address: 'Miami'
end
```

Check out this [pull request](https://github.com/rails/rails/pull/42277) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-from-option-to-assert_no_changes).


Rails 7 Adds from option to ActiveSupport::TestCase#assert_no_changes


[Active Record](https://api.rubyonrails.org/v6.1.4/classes/ActiveRecord/Persistence.html)
in Rails provides various methods like `exists?`, `persisted?`, `destroyed?` and
many more. Using these methods we can easily determine if an object exists in
the database or if an object is an existing record in the database and not a new
record.

Using these methods we can quickly determine the state of an object and easily
write complex conditional statements that depend on the state of an object.
Previously we did not have a method that lets us determine if an object was a
part of the database in past but now does not exist.

However,
[Rails 7 has added previously_persisted? method to ActiveRecord](https://github.com/rails/rails/pull/42389),
which returns `true` if an object has been previously a part of the database
records but now has been destroyed.

Let’s assume we have a `User` model with the name column value `John Doe`. If
this record has been deleted from the database, we can still check if `John Doe`
was a user of our app or not in the past.

### Before

Let's say we delete the user with the name `John Doe`.

```ruby
# app/controllers/user_controller.rb
previous_user = User.find_by_name('John Doe')
previous_user.destroy!
```

Now we can check if the user exists in our database.

```ruby
# app/controllers/user_controller.rb
# check if previous_user is destroyed and is not a new user
if previous_user.destroyed? && !previous_user.new_record?
  # returns true
end
```

### Rails 7 onwards

We can use the `previously_persisted?` method on an object.

Let's delete the user with the name `John Doe`.

```ruby
# app/controllers/user_controller.rb
previous_user = User.find_by_name('John Doe')
previous_user.destroy!
```

Now we can check if the user exists in our database using the
`previously_persisted?` method.

```ruby
# app/controllers/user_controller.rb
previous_user.previously_persisted? # returns true
```

Check out this [pull request](https://github.com/rails/rails/pull/42389) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-activerecord-previously_persisted).


Rails 7 adds ActiveRecord::Base#previously_persisted?

In web applications, forms are one of the most essential interfaces for user
input and it can be tedious to write and maintain form markups with many
attributes. Rails provide
[Action View Form Helpers](https://guides.rubyonrails.org/form_helpers.html) for
generating form markup.

Using
[select](https://guides.rubyonrails.org/form_helpers.html#making-select-boxes-with-ease)
helper we can easily create select boxes in HTML with one `<option>` element for
each option to choose from.

For example, let's say we have a list of cities for the user to choose from.

```ruby
# app/views/address/new.html.erb
<%= form.select :city, ["Pune", "Mumbai", "Delhi"] %>
```

Rails will generate the following markup.

```html
<select name="city" id="city">
  <option value="Pune">Pune</option>
  <option value="Mumbai">Mumbai</option>
  <option value="Delhi">Delhi</option>
</select>
```

Previously for generating a select box for weekday select, we needed to write a
custom helper. Rails did not have anything out of the box for the weekday
selection.

However,
[Rails 7 has added weekday_options_for_select and weekday_select](https://github.com/rails/rails/pull/42979)
using which we can easily generate a dropdown field of selecting a weekday.

### Before

In Rails 6.1 we can create a dropdown field for weekday as shown here.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.select :weekly_off, I18n.t('date.day_names') %>
  </div>
<% end %>
```

Or we can do something like this.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.select :weekly_off, I18n.t('date.day_names').map.with_index.to_h %>
  </div>
<% end %>
```

Then The generated markup looks like this.

```html
<select name="user[weekly_off]" id="user_weekly_off">
  <option value="Sunday">Sunday</option>
  <option value="Monday">Monday</option>
  <option value="Tuesday">Tuesday</option>
  <option value="Wednesday">Wednesday</option>
  <option value="Thursday">Thursday</option>
  <option value="Friday">Friday</option>
  <option value="Saturday">Saturday</option>
</select>
```

Here is how it would look if we go with the second option.

```html
<select name="user[weekly_off]" id="user_weekly_off">
  <option value="0">Sunday</option>
  <option value="1">Monday</option>
  <option value="2">Tuesday</option>
  <option value="3">Wednesday</option>
  <option value="4">Thursday</option>
  <option value="5">Friday</option>
  <option value="6">Saturday</option>
</select>
```

### Rails 7 onwards

We can use the `weekday_options_for_select` or `weekday_select` helper for
generating a dropdown field for selecting a weekday.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.select :weekly_off, weekday_options_for_select("Monday", day_format: :abbr_day_names) %>
  </div>
<% end %>
```

Or we can do something like this.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.weekday_select :weekly_off, { selected: "Monday", day_format: :abbr_day_names } %>
  </div>
<% end %>
```

Then The generated markup looks like this.

```html
<select name="user[weekly_off]" id="user_weekly_off">
  <option value="Sunday">Sunday</option>
  <option selected="selected" value="Monday">Monday</option>
  <option value="Tuesday">Tuesday</option>
  <option value="Wednesday">Wednesday</option>
  <option value="Thursday">Thursday</option>
  <option value="Friday">Friday</option>
  <option value="Saturday">Saturday</option>
</select>
```

`weekday_options_for_select` accepts a few options and all of them have a
default value.

`selected` defaults to nil and if we provide this argument the value passed will
be used as the selected option.

```html
 
<option value=\"Sunday\">Sunday</option>\n
<option value=\"Monday\">Monday</option>\n
<option value=\"Tuesday\">Tuesday</option>\n
<option value=\"Wednesday\">Wednesday</option>\n
<option value=\"Thursday\">Thursday</option>\n
<option selected=\"selected\" value=\"Friday\">Friday</option>\n
<option value=\"Saturday\">Saturday</option>"
```

`index_as_value` defaults to false and if true it will set the value of each
option to the index of that day.

```html

<option value=\"0\">Sunday</option>\n
<option value=\"1\">Monday</option>\n
<option value=\"2\">Tuesday</option>\n
<option value=\"3\">Wednesday</option>\n
<option value=\"4\">Thursday</option>\n
<option value=\"5\">Friday</option>\n
<option value=\"6\">Saturday</option>"
```

`day_format` defaults to :day_names and passing this a different `I18n` key will
use different formats for the option display names and their values.

```html

<option value=\"Sun\">Sun</option>\n
<option value=\"Mon\">Mon</option>\n
<option value=\"Tue\">Tue</option>\n
<option value=\"We\">Wedn</option>\n
<option value=\"Thu\">Thu</option>\n
<option value=\"Fri\">Fri</option>\n
<option value=\"Sat\">Sat</option>"
```

Note that `:abbr_day_names` options are built into Rails but we can define your
array.

Check out this [pull request](https://github.com/rails/rails/pull/42979) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-weekday_options_for_select-and-weekday_select).

Rails 7 adds weekday_options_for_select and weekday_select


Rails 5 introduced [byebug](https://github.com/deivid-rodriguez/byebug) which is
an easy-to-use, feature-rich ruby debugger. It offers features like `Stepping`,
`Breaking`, `Evaluating`, `Tracking`.

Using [byebug](https://github.com/deivid-rodriguez/byebug) we can easily control
the execution of a program and the debug inspector for call stack navigation.
This allows us to handle and track the execution flow.

Here is
[byebug documentation](https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-byebug-gem)
and here is the [pull request](https://github.com/rails/rails/pull/14646) where
it was added.

[Rails 7 is replacing byebug with ruby/debug](https://github.com/rails/rails/pull/43187).
`debug` is Ruby’s new debugger which will be included in Ruby 3.1. To align
Rails with Ruby `debug` has been added to Rails 7.

Let's see an example of debugging with both Byebug and Debug.

### Before

Let's assume we have a `NameController`. Inside any Rails application, you can
call the debugger by calling the `byebug` method.

```ruby
# app/controllers/name_controller.rb
class NameController < ApplicationController
  def index
    name = "John Doe"
    byebug # Call to debugger
    city = "San Francisco"
  end
end
```

Then The invoked debugger results in the following.

```ruby
    [1, 7] in app/controllers/test_controller.rb
    1: class NameController < ApplicationController
    2:   def index
    3:     name = "John Doe"
    4:     byebug # Call to debugger
=>  5:    city = "San Francisco"
    6:   end
    7: end

  (byebug) name # variable call
  "John Doe"
```

### Rails 7 onwards

We can use the `binding.break` method for calling Ruby Debug.

```ruby
# app/controllers/name_controller.rb
class NameController < ApplicationController
  def index
    name = "John Doe"
    binding.break # Call to debugger
    city = "San Francisco"
  end
end
```

The invoked debugger results in the following.

```ruby
  [1, 7] in app/controllers/test_controller.rb
  1| class NameController < ApplicationController
  2|   def index
  3|     name = "John Doe"
  4|     binding.break # Call to debugger
> 5|    city = "San Francisco"
  6|   end
  7| end
>#0 NameController#index at ~/demo_app/app/controllers/name_controller.rb:5
  #1  ActionController::BasicImplicitRender#send_action(method="index", args=[])
(rdbg) name # variable call
"John Doe"
```

Check out this [pull request](https://github.com/rails/rails/pull/43187) for more details and for commands or features of Ruby Debug, please visit [Ruby-Debug](https://github.com/ruby/debug).

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-replaced-byebug-with-ruby-debug).


Rails 7 replaced byebug with ruby/debug


Rails 5.2 introduced
[ActiveStorage](https://guides.rubyonrails.org/active_storage_overview.html)
which made it possible to easily upload files to a cloud storage service like
Amazon S3, Google Cloud Storage, or Microsoft Azure Storage. It also helped in
attaching the files to active record objects.

Using `ActiveStorage` and [ImageMagick](https://www.imagemagick.org) we can
transform image uploads and extract metadata from files. For transforming image
uploads we can use [image_processing](https://www.imagemagick.org) gem with
`ActiveStorage` and create variants of an image.

Previously for creating image variants, we needed to use
[image_processing](https://www.imagemagick.org) gem with `ActiveStorage`
processor. The default processor for `ActiveStorage` is `MiniMagick`, but we can
also use [Vips](https://www.rubydoc.info/gems/ruby-vips/Vips/Image).

However,
[Rails 7 has added the ability to use pre-defined variants](https://github.com/rails/rails/pull/39135)
which provides a way to easily create variants for images.

Let's assume we have a model `Blog`. Using `has_one_attched` every record can
have one file attached to it.

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  has_one_attached :display_picture # Setup mapping between record and file
end
```

To create a `blog` with an attachment on `display_picture`.

```ruby
# app/views/blogs/new.html.erb
<%= form.file_field :avatar %>
```

```ruby
# app/controllers/blogs_controller.rb
class BlogsController < ApplicationController
  def create
    blog = Blog.create!(blog_params)
    session[:user_id] = blog.id
    redirect_to root_path
  end

  private
    def blog_params
      params.require(:blog).permit(:title, :display_picture)
    end
end
```

### Before

If we want to create variants of `display_picture`, we needed add the
[image_processing](https://www.imagemagick.org) gem to the `Gemfile`.

```ruby
# project_folder/Gemfile
gem 'image_processing'
```

Then to create variants of the image, we can call the `variant` method on the
attachment record.

```ruby
# app/views/blogs/show.html.erb
<%= image_tag blog.display_picture.variant(resize_to_limit: [100, 100]) %>
```

### Rails 7 onwards

We can use the `variants` option on `has_one_attached`.

```ruby
class Blog < ActiveRecord::Base
  has_one_attached :display_picture, variants: {
    thumb: { resize: "100x100" },
    medium: { resize: "300x300" }
  }
end
```

To display we can use the `variant` method.

```ruby
# app/views/blogs/show.html.erb
<%= image_tag blog.display_picture.variant(:thumb) %>
```

`variants` can also be used on `has_many_attached`. Check out this
[pull request](https://github.com/rails/rails/pull/39135) for more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-ability-to-use-predefined-variants).


Rails 7 adds the ability to use pre-defined variants


Rails
[Active Record Validation](https://guides.rubyonrails.org/active_record_validations.html)
provides a convenient way to validate the state of an object before it is stored
in the database. There are various built-in
[Active Record validations](https://guides.rubyonrails.org/active_record_validations.html)
like `presence`, `length`, `numericality` and `uniqueness`.

By using
[numericality validator](https://guides.rubyonrails.org/active_record_validations.html#numericality),
we can validate an attribute to only have numeric values.

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  validates :likes, numericality: true
end
```

We can also use helpers like `greater_than`, `greater_than_or_equal_to`,
`equal_to`, `less_than`, `less_than_or_equal_to`, `other_than`, `odd`, `even`
with
[numericality validator](https://guides.rubyonrails.org/active_record_validations.html#numericality)
but these work only on numbers.

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  validates :likes, numericality: { greater_than: 1 }
end
```

Previously for validating comparisons of dates we needed to write
[custom validators](https://guides.rubyonrails.org/active_record_validations.html#performing-custom-validations)
or use a gem like [date_validator](https://github.com/codegram/date_validator).

However,
[Rails 7 has added ComparisonValidator](https://github.com/rails/rails/pull/40095)
which provides a way to easily validate comparisons with another value, proc, or
attribute. Let's assume we have a model `Blog` with an `end_date` attribute.

### Before

If we want to validate the `end_date` attribute for the provided value or then
we would need to write a
[custom validator](https://guides.rubyonrails.org/active_record_validations.html#performing-custom-validations)
or use a gem like [date_validator](https://github.com/codegram/date_validator).

```ruby
# Using date_validator gem
class Blog < ApplicationRecord
  # validate against provided value
  validates :end_date, date: { after: Proc.new { Date.today } }
  # validate against another attribute
  validates :end_date, date: { after: :start_date }
end
```

### Rails 7 onwards

We can use [ComparisonValidator](https://github.com/rails/rails/pull/40095) to
validate the comparison of the `end_date` attribute for a provided value.

```ruby
class Blog < ApplicationRecord
  # validate against provided value
  validates_comparison_of :end_date, greater_than: -> { Date.today }
  # validate against another attribute
  validates :end_date, greater_than: :start_date
end
```

[ComparisonValidator](https://github.com/rails/rails/pull/40095) also provides
helpers like `greater_than`, `greater_than_or_equal_to`, `equal_to`,
`less_than`, `less_than_or_equal_to` and `other_than`.

Check out this [pull request](https://github.com/rails/rails/pull/40095) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-comparison-validator-to-active-record).


Rails 7 adds ComparisonValidator to ActiveRecord


[ActiveRecord](https://guides.rubyonrails.org/active_record_querying.html) is
one of the most powerful features in Rails. With `ActiveRecord` we can easily
query and handle database objects without writing any SQL.

By using `ActiveRecord Query Interface`, we can perform various query operations
like `Joins`, `Group`, `Find`, `Order`. We can also chain relations with
`where`, `and`, `or`, `not` but for `and` or `or` the two chaining relations
must be structurally compatible.

For any two relations to be
[Structurally Compatible](https://github.com/rails/rails/blob/c577657f6de64b743b12a21108dc9cc5cfc35098/activerecord/lib/active_record/relation/query_methods.rb#L650)
they must be scoping the same model, and they must differ only by the `where`
clause when no `group` clause has been defined. If a `group` clause is present
then the relations must differ by the `having` clause. Also, Neither relation
may use a `limit`, `offset`, or `distinct` method.

Previously for `and` or `or` query methods, we needed to make sure that the two
relations are structurally compatible otherwise `ActiveRecord` would raise an
error.

However,
[Rails 7 has added ActiveRecord::Relation#structurally_compatible?](https://github.com/rails/rails/pull/41841)
which provides a method to easily tell if two relations are structurally
compatible. We can use this method before we run `and` or `or` query methods on
any two relations.

Let's assume we have two models `Blog` and `Post` with the following relations

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  has_many :posts
end
```

```ruby
# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :blog
end
```

### Before

If we run `or` query between incompatible relations we would get an
ArgumentError.

```ruby
relation_1 = Blog.where(name: 'bigbinary blog')
relation_2 = Blog.joins(:posts).where(posts: { user_id: current_user.id})

begin
  relation_1.or(relation_2)
rescue ArgumentError
  # Rescue ArgumentError
end
```

### Rails 7 onwards

We can check the structural compatibility of the two relations.

```ruby
relation_1 = Blog.where(name: 'bigbinary blog')
relation_2 = Blog.where(user_id: current_user.id)

if relation_1.structurally_compatible?(relation_2) # returns true
  relation_1.or(relation_2)
end
```

Check out this [pull request](https://github.com/rails/rails/pull/41841/files)
for more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-active-record-relation-structurally-compatible).


Rails 7 adds ActiveRecord::Relation#structurally_compatible?


Ruby 3.0 is a landmark release that brings the language closer to real concurrency with two significant additions: **Ractors** and the **Fiber scheduler**. These features aim to improve performance and scalability, all while preserving Ruby’s friendly syntax.

### Why concurrency matters

As applications scale and hardware becomes more multi-core, concurrency becomes crucial for performance. Ruby’s traditional thread-based model is limited by the Global VM Lock (GVL), making true parallel execution difficult. Ruby 3.0 introduces abstractions to overcome this.

### Ractors: Parallelism without thread-safety headaches

**Ractor** (short for "Ruby Actor") is a new concurrency abstraction that enables parallel execution without sharing mutable state.

Key features:

- Each Ractor has isolated memory.
- Communication is done via message passing.
- Designed to work around the GVL.

```ruby
r = Ractor.new { 1 + 2 }
puts r.take # => 3
```

Ractors introduce syntax restrictions to enforce safety, but allow Ruby code to run in true parallel threads.

### Fiber Scheduler: Lightweight, non-blocking I/O

**Fiber scheduler** provides a hookable API that allows libraries like `async` to intercept blocking operations such as sleep or I/O.

This enables cooperative multitasking, where operations yield control rather than block the thread.

```ruby
require 'async'
require 'net/http'

Async do
  ["https://ruby-lang.org", "https://rails.org"].each do |url|
    Async do
      Net::HTTP.get(URI(url))
    end
  end
end
```

This code performs multiple HTTP requests concurrently, using async fibers under the hood.

### Benefits

- Better CPU utilization on multi-core systems
- No more thread-safety concerns
- Improved performance for I/O-heavy workloads
- Works with gems like `async`, `falcon`, `net/http`, and more

### Status and compatibility

- Ractors are marked as experimental.
- Fiber scheduler is opt-in and requires compatible libraries.
- Both features are evolving rapidly, and more improvements are expected in Ruby 3.1+.

### Resources

- [Ruby 3.0.0 Release Notes](https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/)
- [Fiber Scheduler Overview](https://bugs.ruby-lang.org/issues/16786)
- [Ractor documentation](https://github.com/ruby/ruby/blob/master/doc/ractor.md)

### Summary

Ruby 3.0 marks a turning point for concurrency. With Ractors enabling parallelism and Fiber scheduler unlocking non-blocking I/O, developers can write scalable, performant Ruby code while maintaining the joy and simplicity that makes Ruby shine.


Ruby 3.0 introduces Ractors and Fiber scheduler for real concurrency


In January 2021, Basecamp introduced **Hotwire** — short for **HTML Over The Wire** — a new approach to building reactive web applications with minimal JavaScript.

Hotwire is a set of complementary technologies that replaces heavy frontend JavaScript frameworks with **server-rendered HTML** updates that are pushed over the wire.

### What is Hotwire?

Hotwire is made up of two main parts:

- **Turbo**: Replaces Rails’ default UJS and makes your app feel instant.

  - Turbo Drive: Speeds up navigation
  - Turbo Frames: Updates portions of the page
  - Turbo Streams: Sends real-time HTML updates via WebSockets or polling

- **Stimulus**: A lightweight JavaScript framework for adding client-side interactivity.

Together, Turbo and Stimulus provide a complete reactive experience with almost no custom JS.

### Why Hotwire?

- Reduces JS complexity by offloading rendering to the server
- Keeps your frontend in sync with your Rails views
- Easy to debug and maintain
- Great for full-stack Rails teams

It’s ideal for applications where server-rendered HTML still makes sense, but interactivity is needed.

### Getting Started

Add Hotwire to your Rails app:

```bash
bundle add hotwire-rails
bin/rails hotwire:install
```

This installs Turbo and Stimulus, sets up your JS structure, and prepares your app to use Turbo Drive, Frames, and Streams.

### Turbo Streams Example

Here’s a sample stream that appends a message to a chat box:

```erb
<%= turbo_stream.append "messages" do %>
  <div class="message"><%= @message.body %></div>
<% end %>
```

This automatically pushes HTML to clients connected via WebSockets (if using ActionCable).

### Turbo Frame Example

Split your page into replaceable components:

```erb
<turbo-frame id="profile">
  <%= render @user %>
</turbo-frame>
```

Rails will target this frame with updates, rather than reloading the whole page.

### Performance Boost

Hotwire apps feel incredibly fast because:

- Navigation doesn't reload the full page
- Partial updates happen without re-rendering JS
- Real-time streams are simple and efficient

### Resources

- [Hotwire.dev](https://hotwired.dev)
- [Turbo GitHub](https://github.com/hotwired/turbo-rails)
- [Stimulus GitHub](https://github.com/hotwired/stimulus)
- [DHH’s Announcement Post](https://world.hey.com/dhh/the-time-is-right-for-hotwire-ecdb9b33)

### Summary

Hotwire simplifies how we build reactive Rails apps by rethinking the role of JavaScript. With Turbo and Stimulus, you can create fast, real-time features without the complexity of SPAs — keeping the Rails magic alive.


Hotwire announced Turbo & Streams for reactive Rails apps


Stimulus 2.0 brings new capabilities to your frontend controllers with the **Values API** and **Classes API**.

### Values API

Define typed properties with default values:

```javascript
export default class extends Controller {
  static values = { count: Number };

  connect() {
    console.log(this.countValue); // => 0 or passed value
  }
}
```

You can then set this value in your HTML:

```html
<div data-controller="my-controller" data-my-controller-count-value="5"></div>
```

### Classes API

Bind CSS classes to behavior:

```javascript
static classes = ["highlight"]

connect() {
  this.element.classList.add(this.highlightClass) // returns class name
}
```

You can specify the class name in your HTML:

```html
<div
  data-controller="my-controller"
  data-my-controller-highlight-class="active"
></div>
```

### Links

- [PR #202 - Adds values and classes APIs](https://github.com/hotwired/stimulus/pull/202)
- [Relevant Discussion](https://discuss.hotwired.dev/t/announcing-stimulus-2-0/1482)

### Summary

Stimulus 2.0 significantly enhances the power and flexibility of JavaScript controllers. The Values API simplifies the management of dynamic data and default configurations directly within the controller, while the Classes API provides a clean and declarative way to toggle and manage CSS classes based on controller state and actions. These additions allow for more expressive and maintainable frontend behavior without compromising Stimulus's core "modest" design principles.


Stimulus 2.0 released – new Values & Classes API for controllers


Rails 6.1 overhauls the `ActiveModel::Errors` API, making it behave more like a true object.

### What’s new?

- Errors are now objects instead of just hashes
- Improved error messages and introspection
- Easier to add and query error metadata

### Example

```ruby
user.errors.add(:email, :invalid, message: "is not a valid format")
user.errors[:email].any?           # true
user.errors[:email].first.full_message # => "Email is not a valid format"
user.errors[:email].first.attribute  # => :email
user.errors[:email].first.type       # => :invalid
```

This change improves form error handling by providing more structured error information, simplifies testing error conditions with easier introspection, and enhances serialization by allowing inclusion of error metadata in API responses.

### Summary

The new `ActiveModel::Errors` API gives developers better tools for working with validations and error messages, leading to more robust and maintainable applications.

For more details, check out the [PR #32313](https://github.com/rails/rails/pull/32313).


Rails 6.1 revamps ActiveModel Errors with a new API


Rails 6.1 introduces `delegated_type`, a cleaner and more expressive way to handle polymorphic relationships in ActiveRecord. It builds on traditional polymorphism by making it easier to work with multiple types and providing helpful querying and predicate methods.

### The Problem with Classic Polymorphism

Using polymorphic `belongs_to` often leads to awkward queries and boilerplate. Let’s say we manage two types of vehicles: `Car` and `Motorcycle`. With polymorphic associations, you'd typically do this:

```ruby
class Vehicle < ApplicationRecord
  belongs_to :vehicleable, polymorphic: true
end

class Car < ApplicationRecord
  has_one :vehicle, as: :vehicleable
end

class Motorcycle < ApplicationRecord
  has_one :vehicle, as: :vehicleable
end
```

You can query attributes via `vehicle.vehicleable`, but checking the type or fetching records by type requires manual filtering and string comparisons.

### Enter `delegated_type`

Rails 6.1 improves this pattern with `delegated_type`:

```ruby
class Vehicle < ApplicationRecord
  delegated_type :vehicleable, types: %w[Car Motorcycle]
end
```

That one line gives you:

- `vehicle.vehicleable` (just like before)
- Type-specific accessors: `vehicle.car`, `vehicle.motorcycle`
- Type predicate helpers: `vehicle.car?`, `vehicle.motorcycle?`
- Scope helpers: `Vehicle.cars`, `Vehicle.motorcycles`

### Creating Records

With `delegated_type`, you can initialize and persist both the delegator and delegatee in one go. Note that `vehicleable:` expects an instance of the associated type:

```ruby
Vehicle.create!(
  vehicleable: Car.new(interior_color: '#fff', adjustable_roof: true),
  name: 'TS78Z',
  mileage: 89
)
```

This automatically saves both the `Car` and associated `Vehicle` record.

### Querying and Type Helpers

You get handy scopes and methods out of the box:

```ruby
Vehicle.cars
# => ActiveRecord::Relation of all Vehicles with vehicleable_type: "Car"

Vehicle.motorcycles
# => ActiveRecord::Relation of all Vehicles with vehicleable_type: "Motorcycle"

vehicle = Vehicle.first
vehicle.car?        # => true or false
vehicle.car         # => Returns the Car object or nil
```

This removes the need for manual conditionals or type comparisons.

### Summary

`delegated_type` is a modern, ergonomic alternative to polymorphic associations. It gives your models cleaner APIs, less boilerplate, and better type safety — all while keeping your data normalized.

To learn more, check out the [pull request](https://github.com/rails/rails/pull/39322) that introduced it.


Rails 6.1 adds ActiveRecord delegated types for polymorphism


Rails 6.1 introduces support for `:destroy_async` on associations — enabling deferred deletion of associated records through background jobs.

### Why This Matters

Cascading deletions in complex systems can lead to slow requests and timeouts. Consider a model with deeply nested associations — using `dependent: :destroy` could block the request thread as it recursively deletes records.

Rails 6.1 solves this by introducing:

```ruby
has_many :comments, dependent: :destroy_async
```

Instead of deleting inline, Rails now **queues a job** to destroy the associated records in the background.

### Example

```ruby
class Author < ApplicationRecord
  has_many :books, dependent: :destroy_async
end

class Book < ApplicationRecord
  belongs_to :author
end
```

Now, when an `Author` is destroyed, Rails enqueues a background job to remove the associated `books`.

```bash
Performing ActiveRecord::DestroyAssociationAsyncJob
  Job ID: d5af82ac-ee53-453d-8736-541ae0f68105
  Arguments: {
    owner_model_name: "Author",
    owner_id: 1,
    association_class: "Book",
    association_ids: [1, 2, 3, 4],
    association_primary_key_column: :id
  }
```

The `Author` record is deleted immediately, and `Book` records are processed asynchronously — improving UX and system responsiveness.

### When to Use

- Large hierarchies of associated records
- Performance-sensitive delete operations
- Avoiding request timeout errors

Keep in mind: callbacks still run, just deferred in a job.

### Summary

Rails 6.1’s `:destroy_async` gives developers a native way to **offload costly association deletions** into background jobs. It’s a small change with big impact on scalability and performance.

For more details, check the [Rails PR #40157](https://github.com/rails/rails/pull/40157).


Rails 6.1 allows destroying associations asynchronously


Rails 6.1 introduces **strict loading**, a helpful feature that enforces eager loading to prevent accidental N+1 queries.

### What is strict loading?

Strict loading raises an `ActiveRecord::StrictLoadingViolationError` if an association is accessed without being eager-loaded. It’s a great tool to catch inefficient queries early in development or test environments.

### Enabling strict loading per model

You can set strict loading as the default behavior for all records of a model:

```ruby
class Article < ApplicationRecord
  self.strict_loading_by_default = true

  has_many :comments
end
```

Now, if you fetch an `Article` and try to access its `comments` without including them, Rails will raise an error:

```ruby
article = Article.strict_loading.first
article.comments # => Raises ActiveRecord::StrictLoadingViolationError
```

### Fixing the error

Simply include the associations beforehand:

```ruby
article = Article.includes(:comments).strict_loading.first
article.comments # works as expected
```

You can verify strict loading is active:

```ruby
article.strict_loading? # => true
```

You can also check if associated records respect strict loading:

```ruby
article.comments.all?(&:strict_loading?) # => true
```

### Enabling strict loading per association

You can enforce strict loading on a specific association:

```ruby
class Article < ApplicationRecord
  has_many :comments, strict_loading: true
end
```

Now, accessing `comments` without eager loading raises an error, even if the model itself isn't strict:

```ruby
article = Article.first
article.comments # => Raises ActiveRecord::StrictLoadingViolationError
```

### Enabling strict loading on queries

If you want to enforce strict loading for specific queries only, use:

```ruby
Article.strict_loading.load
```

### Enable globally

Strict loading can be enabled for all models via configuration:

```ruby
# config/application.rb
config.active_record.strict_loading_by_default = true
```

This ensures all models and their associations are protected from lazy loading.

### Logging violations instead of raising

In production, instead of raising an error, you can choose to just log violations:

```ruby
# config/environments/production.rb
config.active_record.action_on_strict_loading_violation = :log
```

This helps teams gradually adopt strict loading without immediately breaking the app.

### Summary

Strict loading in Rails 6.1 is a powerful ally against N+1 query issues. By enforcing eager loading and surfacing violations early, it improves app performance and encourages better data access patterns.

For more, check out:

- [PR #37400](https://github.com/rails/rails/pull/37400)
- [PR #38541](https://github.com/rails/rails/pull/38541)
- [PR #39491](https://github.com/rails/rails/pull/39491)
- [PR #40511](https://github.com/rails/rails/pull/40511)


Rails 6.1 introduces Strict Loading to catch N+1 queries


Rails 6.1 introduces powerful upgrades to multi-database setups — including **per-database role switching** and **horizontal sharding**, giving you more precise control over where and how queries are executed.

### Background

Rails already supported multiple databases with support for roles like `writing` and `reading`. But until now, switching between those roles applied _globally_ — affecting **all** connections across all databases.

### What’s New in Rails 6.1?

- Role and shard switching can now be applied **per connection class** (instead of globally).
- You can route queries independently across shards and replicas for each database.

To enable this, set the following config in `application.rb`:

```ruby
config.active_record.legacy_connection_handling = false
```

### Example Setup

```yaml
production:
  primary:
    database: primary_database
  primary_replica:
    database: primary_database
    replica: true
  primary_shard_one:
    database: primary_shard_one
  primary_shard_one_replica:
    database: primary_shard_one
    replica: true

  vehicles:
    database: vehicles_database
  vehicles_replica:
    database: vehicles_database
    replica: true
  vehicles_shard_one:
    database: vehicles_shard_one
  vehicles_shard_one_replica:
    database: vehicles_shard_one
    replica: true
```

### Model Structure

```ruby
# Primary DB base class
class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to shards: {
    default: { writing: :primary, reading: :primary_replica },
    shard_one: { writing: :primary_shard_one, reading: :primary_shard_one_replica }
  }
end

# Vehicles DB base class
class VehiclesRecord < ApplicationRecord
  self.abstract_class = true

  connects_to shards: {
    default: { writing: :vehicles, reading: :vehicles_replica },
    shard_one: { writing: :vehicles_shard_one, reading: :vehicles_shard_one_replica }
  }
end

class User < ApplicationRecord; end
class Car < VehiclesRecord; end
```

### Behavior: Before vs After

With `legacy_connection_handling = true` (old behavior):

```ruby
ApplicationRecord.connected_to(role: :reading, shard: :shard_one) do
  User.first # hits shard_one
  Car.first  # hits shard_one
end
```

With `legacy_connection_handling = false` (new behavior):

```ruby
VehiclesRecord.connected_to(role: :reading, shard: :shard_one) do
  User.first # still hits primary replica
  Car.first  # hits vehicles_shard_one
end
```

Each abstract class manages its own connection context!

### When to Use

- You have multiple databases with different sharding or replica strategies.
- You want to avoid side effects of global connection switching.
- You want queries to go to the _correct database/shard_ even when deeply nested.

### Summary

Rails 6.1 lets you **switch roles and shards per database**, making horizontal scaling and data isolation easier than ever. It’s a great addition for apps with growing data or high-performance needs.

For more details, check out the [PR #40370](https://github.com/rails/rails/pull/40370).


Rails 6.1 enables per-database connection switching & sharding


RSpec 4.0 brings developer-focused enhancements with an improved DSL and **seamless integration with Rails 6.1**. This version simplifies how we write, generate, and run specs — especially in modern Rails apps.

### DSL Improvements

RSpec 4.0 refines its syntax for better readability and expressiveness:

- Cleaner one-liners and metadata support
- Better introspection for matchers
- Smarter defaults in generated spec files

These changes make specs easier to read, write, and maintain — especially helpful in large projects or teams.

### Rails 6.1 Compatibility

RSpec 4.0 works out of the box with the latest features from Rails 6.1:

- **Zeitwerk autoloading** support
- Compatibility with **ActiveRecord 6.1** APIs
- Support for **ActionMailbox** and **ActionCable** testing
- Works well with **ActiveJob**, **system specs**, and **Rails generators**

### ActionMailbox + ActionCable Testing

RSpec Rails now supports mailbox and channel specs with the corresponding helpers:

```ruby
RSpec.describe InboxMailbox, type: :mailbox do
  it "marks email as delivered" do
    mail = Mail.new(subject: "[123456] ticket")
    result = process(mail)

    expect(result).to have_been_delivered
  end
end
```

And for channels:

```ruby
RSpec.describe ChatChannel, type: :channel do
  it "subscribes to a stream" do
    subscribe
    expect(subscription).to be_confirmed
    expect(streams).to include("chat_#{current_user.id}")
  end
end
```

### Generator Enhancements

Specs generated via Rails generators are now more aligned with Rails conventions:

- Uses Ruby 1.9+ hash syntax
- Defaults to **request specs** over controller specs
- New generators for system specs, mailboxes, channels, and more

### Additional Highlights

- Option to disable ActiveRecord: `config.use_active_record = false`
- Set `ActiveJob.queue_adapter` directly in system specs
- Silences Puma logs in system test output

### Links

- [RSpec 4.0 Release Notes](https://rspec.info/blog/2020/05/rspec-rails-4-0-has-been-released/)
- [RSpec Documentation](https://rspec.info/documentation/)
- [RSpec GitHub](https://github.com/rspec/rspec-core)

### Summary

RSpec 4.0 makes writing and maintaining tests more intuitive with DSL improvements, modern matchers, and Rails 6.1 compatibility. Whether you’re testing channels, mailboxes, or jobs, this version helps you stay productive and upgrade-ready.


RSpec 4.0 adds improved DSL and Rails 6.1 compatibility


Ruby 2.7 introduces **pattern matching** as an experimental feature — a powerful new control flow tool that brings deconstruction and deep matching to your Ruby code.

### What is Pattern Matching?

Pattern matching allows you to match against the structure of objects (arrays, hashes, or custom types) and extract values inline. It uses the new `case in` syntax to provide clean and expressive matching logic.

### Basic Example

```ruby
case [0, 1, 2]
in [0, x, y]
  puts "x = #{x}, y = #{y}"
end
```

This pattern matches the array `[0, 1, 2]` and destructures it: `x = 1`, `y = 2`.

### Matching Hashes and Object Types

You can use type guards with destructuring:

```ruby
case { name: "Alice", age: 30 }
in { name: String => name, age: Integer => age }
  puts "#{name} is #{age}"
end
```

This matches the hash shape, confirms the types, and binds values.

### Find Pattern Support

In Ruby 2.7 and beyond, you can match an element **within** a larger array using the splat (`*`) syntax:

```ruby
json = { name: "John", friends: [{ name: "Alex", age: 24 }, { name: "Don", age: 25 }] }

case json
in { name: "John", friends: [*, { name: "Alex", age: age }, *] }
  puts "Alex is #{age}"
end
```

This works even if the element appears in the middle of the array — thanks to the find pattern.

### Complex Matching with Arrays

You can match parts of arrays with trailing or leading elements using the splat operator:

```ruby
case ["alpha", 1, "beta", "gamma", 2, "a", "b", "c", 3]
in [*pre, String => x, String => y, *post]
  p pre   # => ["alpha", 1]
  p x     # => "beta"
  p y     # => "gamma"
  p post  # => [2, "a", "b", "c", 3]
end
```

This elegantly extracts the first matching sequence of two strings while capturing what's before and after.

### When to Use It

Pattern matching is great for:

- Cleaning up deeply nested `if`/`case` chains
- Extracting values from API responses
- Handling structured JSON-like data

### Caveats

- Pattern matching is **experimental** in Ruby 2.7 — syntax and behavior may evolve
- Only available via `case in` syntax (no standalone `in` blocks)
- Not all Ruby types and structures support pattern matching natively yet

### Resources

- [Ruby 2.7 Release Notes](https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/)
- [Pattern Matching Guide (Matz’s Ruby)](https://bugs.ruby-lang.org/issues/14912)

### Summary

Pattern matching in Ruby 2.7 opens the door to **cleaner, safer, and more expressive control flow** — especially when dealing with structured data. While still evolving, it's a game-changing addition worth exploring in your apps and experiments.


Ruby 2.7 introduces pattern matching (experimental)


RSpec 3.9 continues to improve the developer experience for large test suites with two major usability enhancements: **grouped failures** and **advanced example filtering**.

### Grouped failures

Debugging a test suite becomes easier when related failures are grouped together. RSpec 3.9 introduces structured output that organizes failing examples by file and context, making it quicker to pinpoint and address issues.

### Enhanced Example Filtering

You now have more power to target specific tests. RSpec 3.9 supports:

- **Tag-based filtering** using metadata like `:focus` or custom tags
- **Line number targeting** (e.g. run a test near a specific line)
- **Regex filtering** with `--example-matches`, which lets you run examples that match a pattern in the description

#### Example

```bash
rspec spec/models/user_spec.rb:42
```

Or use `--example-matches` for fuzzy matching:

```bash
rspec --example-matches "user updates"
```

### New: Minimalist Failure Formatter

A new formatter, `--format failure_list` (or just `-f f`), was introduced. It outputs failing specs in a clean, quick-fix-friendly format:

```bash
spec/models/user_spec.rb:15 # User validations fails with invalid email
spec/services/payment_service_spec.rb:37 # PaymentService charges card
```

Great for CI pipelines or quick copy-paste debugging.

### Behind the Scenes

Other internal improvements in RSpec 3.9 include:

- Smarter error handling when loading spec support files
- `did_you_mean` suggestions for LoadErrors
- Improved thread safety in mocks using mutexes
- Generator support for system specs, generators, and controller routes in `rspec-rails`

### Links

- [RSpec 3.9 Release Notes](https://rspec.info/blog/2019/10/rspec-3-9-has-been-released/)
- [RSpec Documentation](https://rspec.info/documentation/)
- [RSpec GitHub](https://github.com/rspec/rspec-core)

### Summary

With improved filtering, grouped failure output, and new CLI tools like `--example-matches` and `failure_list`, RSpec 3.9 makes debugging faster and more intuitive — especially in large or flaky test suites.


RSpec 3.9 adds example filtering and failure grouping


Rails 6 introduces **parameterized mailers**, which simplify mailer usage by setting instance variables shared across mail methods.

### Before

Each mail method had to receive parameters and assign them manually:

```ruby
class UserMailer < ApplicationMailer
  def welcome(user)
    @user = user
    mail(to: @user.email)
  end
end
```

### After: Parameterized Mailer

```ruby
class UserMailer < ApplicationMailer
  def welcome
    mail(to: @user.email)
  end
end

UserMailer.with(user: user).welcome.deliver_later
```

Instance variables like `@user` are automatically available, reducing duplication.

### Links

- [PR #34591 - Adds Parameterized mailer](https://github.com/rails/rails/pull/34591)
- [Rails Documentation for ActionMailer Parameterized ](https://api.rubyonrails.org/v6.0.5/classes/ActionMailer/Parameterized.html)

### Summary

Parameterized mailers reduce boilerplate and make mailer usage more consistent. This update helps keep mailer code clean and focused on delivery.


Rails 6 introduces parameterized mailers in ActionMailer


Rails 6 introduces a major shift in how JavaScript is handled by making **Webpacker** the default JavaScript compiler. This change brings modern frontend tooling to Rails by using **webpack** to bundle and serve JavaScript code.

### Before Rails 6

Prior to Rails 6, JavaScript was managed using **Sprockets**. JS files lived in `app/assets/javascripts`, and scaffold generators created CoffeeScript stubs.

Starting with Rails 5.1, Webpacker could be added manually:

```bash
rails new myapp --webpack
```

Or to integrate with an existing app:

```ruby
# Gemfile
gem 'webpacker', '~> 4.x'
```

```bash
bundle
bundle exec rails webpacker:install
```

### After Rails 6

Now, when you run `rails new`, the Webpacker gem is included by default and `webpacker:install` is automatically executed.

All JS code lives in `app/javascript`. This folder contains:

- `packs/`: Entry points for webpack (e.g. `application.js`)
- `channels/`: Action Cable setup using ES6 (not CoffeeScript)

No scaffold JS stubs are created anymore, except for Action Cable channels.

Default pack file (`application.js`) includes:

```js
require('@rails/ujs').start();
require('turbolinks').start();
require('@rails/activestorage').start();
require('channels');
```

### What is Webpacker?

**Webpacker** is a gem that integrates webpack with Rails. It makes it easy to bundle modern JS using ES6, React, Vue, or other frontend libraries. It ships with sensible defaults and provides helpers for referencing compiled assets.

### Webpacker Structure in Rails 6

```bash
app/javascript
├── channels/
│   ├── consumer.js
│   └── index.js
├── packs/
│   └── application.js
```

Only files inside the `packs/` directory are treated as webpack entry points and compiled. These packs can reference other JS modules, styles, or assets.

### Using Packs in Layouts

To include a pack in your layout:

```erb
<%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
```

If your pack imports CSS:

```erb
<%= stylesheet_pack_tag 'application' %>
```

Best practice is to organize business logic into modules within `app/javascript` and only reference them via the pack files.

### Configuring Webpacker

Webpacker’s main config file is located at:

```bash
config/webpacker.yml
```

It lets you configure source paths, pack output paths, and dev server settings.

Webpack-specific configs live inside:

```bash
config/webpack/
├── development.js
├── production.js
├── environment.js
```

### Compilation

In **development**, webpack compiles JS on the fly with each request.

In **production**, assets are compiled using:

```bash
rails assets:precompile
```

This internally calls:

```bash
rails webpacker:compile
```

Webpacker also supports hot module replacement (HMR) and live reloading with its provided binstubs.

### Links

- [PR #33079 - Adds Webpacker the default JavaScript compiler for Rails](https://github.com/rails/rails/pull/33079)
- [Rails Webpacker GitHub Repo](https://github.com/rails/webpacker)
- [Rails Documentation for Webpacker](https://edgeguides.rubyonrails.org/webpacker.html)

### Summary

By making Webpacker the default, Rails 6 embraces modern JavaScript practices while staying full-stack friendly. With ES6 modules, easy pack organization, and webpack’s flexibility, Rails developers now have first-class support for building modern frontends alongside their backend.


Rails 6 makes Webpacker the default JavaScript pipeline


Rails 6 introduces **Zeitwerk** as the new default code loader, replacing the classic autoloader. Zeitwerk provides a modern, thread-safe, and eager-loading-friendly autoloading mechanism.

### What is Zeitwerk?

Zeitwerk is a code loader gem developed by Xavier Noria. It provides:

- Autoloading of constants
- Eager loading for production
- Reloading in development
- Thread safety by design

Unlike the classic autoloader, Zeitwerk doesn’t rely on `const_missing` hooks. Instead, it registers autoload paths directly with Ruby using `Module.autoload`, aligning more closely with Ruby’s semantics.

### Why Zeitwerk?

The motivation behind Zeitwerk was to keep code DRY and remove the need for brittle `require` calls. It also improves reliability by:

- Respecting Ruby's constant resolution rules
- Using the `TracePoint` API to manage nested modules
- Reducing confusion with explicit autoload paths

Zeitwerk is available as a standalone gem, so you can also use it in non-Rails Ruby projects.

### Using Zeitwerk in a Non-Rails Project

Zeitwerk is fully independent and works in plain Ruby apps:

```ruby
require "zeitwerk"

loader = Zeitwerk::Loader.new
loader.push_dir("lib")
loader.setup
```

For gem authors, Zeitwerk offers a helper:

```ruby
require "zeitwerk"

loader = Zeitwerk::Loader.for_gem
loader.setup

module MyGem
  include MyLogger
end
```

Once setup is done, constants are ready to be referenced without manual requires.

### How Zeitwerk Works

Zeitwerk leverages Ruby’s constant resolution flow:

- `Module.nesting`
- `Module.ancestors`

It no longer relies on `Object.ancestors`, and doesn't override `const_missing`.

In the classic loader (Rails < 6), autoloading worked by overriding `Module#const_missing` and looking for matching files in `ActiveSupport::Dependencies.autoload_paths`. It depended on naming conventions:

- File must be named after the class
- Must reside in an autoload path

### Zeitwerk Mode and TracePoint

Zeitwerk uses `Module.autoload` instead. For example:

```ruby
loader.push_dir("./lib")
# Internally does:
autoload "Automobile", "lib/automobile.rb"
```

When Zeitwerk sees `class Automobile`, it triggers a TracePoint hook. It checks if a directory named `automobile/` exists, and sets up autoloads for any files inside, like `automobile/engine.rb`.

```ruby
class Automobile
  # TracePoint triggers
  # Zeitwerk autoloads ./automobile/engine.rb if needed
end
```

This design ensures that modules are loaded in a predictable, Ruby-native way.

### Reverting to classic loader in Rails

Rails handles the switch automatically, but apps using non-standard structures may need adjustments. You can temporarily revert to the classic loader with:

```ruby
config.autoloader = :classic
```

### Links

- [Relevant Commit](https://github.com/rails/rails/commit/e53430fa9af239e21e11548499d814f540d421e5)
- [Zeitwerk-Rails integration](https://github.com/rails/rails/blob/bfc9065d58508fb19dd1a4170406604dd3b3234a/activesupport/lib/active_support/dependencies/zeitwerk_integration.rb)
- [Rails Documentation for Autoloading and Reloading Constants (Zeitwerk Mode)](https://guides.rubyonrails.org/v6.0/autoloading_and_reloading_constants.html)
- [Zeitwerk GitHub Repo](https://github.com/fxn/zeitwerk)

### Summary

Zeitwerk is a significant improvement over the classical Rails code loader. It's thread-safe, efficient, and aligns with Ruby’s native constant loading behavior. With Zeitwerk, Rails apps enjoy cleaner structure, fewer manual `require` calls, and a more predictable autoloading experience.

If you're upgrading to Rails 6 or starting fresh, Zeitwerk is already baked in — no extra config needed.


Rails 6 adopts Zeitwerk autoloader by default


Rails 6 adds built-in **parallel testing**, allowing test suites to run across multiple CPUs or processes simultaneously.

### Why parallel tests?

As projects grow, test suites can become slow. By distributing tests across CPUs, parallel testing improves feedback time and productivity.

### How to enable it

```bash
rails test:parallel
```

This automatically splits the test suite into multiple workers.

You can customize the number of workers:

```bash
PARALLEL_WORKERS=4 rails test:parallel
```

### Links

- [PR #31900 - Adds Parallel testing](https://github.com/rails/rails/pull/31900)
- [Rails Documentation for Parallel Testing](https://guides.rubyonrails.org/testing.html#parallel-testing)

### Summary

Rails 6’s parallel testing feature helps developers ship faster by speeding up test feedback. It’s easy to set up and works out of the box with Minitest.


Rails 6 brings parallel testing to speed up CI


Rails 6 brings **first-class support for multiple databases**, making it much easier to manage complex applications that need **read/write separation**, **replica fallbacks**, or **domain-specific sharding** — without relying on third-party gems.

### Key Features

- Connect to **multiple primary and replica databases**
- Built-in **connection switching** middleware
- Independent **migrations and schema tracking**
- Out-of-the-box **Rails tasks** for each database

### Setting Up `database.yml`

Here’s an example configuration with a primary DB and an `animals` DB with replicas:

```yaml
production:
  primary:
    database: my_primary_database
    adapter: mysql
    user: root
  primary_replica:
    database: my_primary_database
    adapter: mysql
    user: readonly_user
    replica: true

  animals:
    database: animals_db
    adapter: mysql
    user: animals_user
    migrations_paths: db/animals_migrate
  animals_replica:
    database: animals_db
    adapter: mysql
    user: animals_readonly
    replica: true
```

A few important things to note:

- Replicas must set `replica: true`
- Use different users for primaries and replicas
- Use `migrations_paths` to isolate migrations per DB

### Connecting Models to Databases

Create an abstract base model for each custom DB:

```ruby
class AnimalsBase < ApplicationRecord
  self.abstract_class = true

  connects_to database: { writing: :animals, reading: :animals_replica }
end
```

For your default models:

```ruby
class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to database: { writing: :primary, reading: :primary_replica }
end
```

If you're using legacy roles like `:readonly`, you can override them in your config:

```ruby
config.active_record.writing_role = :default
config.active_record.reading_role = :readonly
```

### Rails Tasks for Multi-DB

Rails ships with namespaced commands for each database:

```bash
rails db:create
rails db:create:animals
rails db:migrate
rails db:migrate:animals
rails db:migrate:status:animals
```

Each database uses its own migration directory. Use `--database` when generating migrations:

```bash
rails g migration CreateDogs name:string --database animals
```

### Automatic Connection Switching

Rails includes middleware that automatically routes reads/writes:

- Writes (POST/PUT/DELETE) use the **primary**
- Reads (GET/HEAD) use the **replica**, unless a recent write occurred

Enable it in `application.rb`:

```ruby
config.active_record.database_selector = { delay: 2.seconds }
config.active_record.database_resolver = ActiveRecord::Middleware::DatabaseSelector::Resolver
config.active_record.database_resolver_context = ActiveRecord::Middleware::DatabaseSelector::Resolver::Session
```

You can even write your own resolver if you want to control switching based on cookies, headers, etc.

### Manual Connection Switching

Use `connected_to` if you want explicit control:

```ruby
ActiveRecord::Base.connected_to(role: :reading) do
  # Read-only logic here
end
```

Passing an unknown role will raise an error, so make sure it matches your config.

### Caveats

- ❌ No native **sharding** support yet
- 🔀 No built-in **replica load balancing**
- 🚫 No **cross-database joins**
- 📦 You’ll need to manually load schema caches for each DB

### Links

- [Rails Multiple Databases Guide](https://guides.rubyonrails.org/v6.0/active_record_multiple_databases.html)
- [PR #36389 – Docs for multi-DB](https://github.com/rails/rails/pull/36389)
- [PR #34137 – Adds multi-db support to `db:migrate:status`](https://github.com/rails/rails/pull/34137)
- [PR #34052 – Adds basic connection switching API](https://github.com/rails/rails/pull/34052)

### Summary

Rails 6 makes scaling your app’s data layer far more manageable with built-in multi-DB tools. Whether you're separating concerns across domains or using replicas to reduce load, Rails now gives you a clean and consistent interface to do it all natively.


Rails 6 supports multiple databases in one app


Rails 6 introduces **Action Text**, which lets developers build rich text fields with file attachments, inline images, and more using the Trix editor.

### Why Action Text?

Most rich text editors require significant setup and don’t integrate well with Rails’ asset pipeline. Action Text solves this by integrating:

- [Trix editor](https://trix-editor.org/)
- [ActiveStorage](https://guides.rubyonrails.org/v6.0.3/active_storage_overview.html) for uploads
- Embedded images and formatting

### Getting started

Run:

```bash
bin/rails action_text:install
rails db:migrate
```

In your model:

```ruby
has_rich_text :content
```

In your form/view:

```erb
<%= form.rich_text_area :content %>
```

### Links

- [PR #34873 - Adds Action Text](https://github.com/rails/rails/pull/34873)
- [Rails Documentation for ActiveStorage](https://guides.rubyonrails.org/v6.0.3/active_storage_overview.html)
- [Trix GitHub Repo](https://github.com/basecamp/trix)

### Summary

Action Text dramatically simplifies adding WYSIWYG editing to Rails apps. It brings modern UX and tightly couples with ActiveStorage and Trix out of the box.


Rails 6 adds Action Text for rich text content (Trix)


Rails 6 adds **Action Mailbox**, a framework for processing incoming emails directly in your application.

### What does it do?

Action Mailbox routes incoming emails to controller-like mailboxes in your app. It can be used for:

- Handling replies to notifications
- Creating records from emailed content
- Automating support ticket systems

### Supported ingress methods

- Postmark
- Mailgun
- Mandrill
- Exim/Sendmail
- Amazon SES

### Example usage

```ruby
class SupportMailbox < ApplicationMailbox
  def process
    SupportTicket.create!(
      email: mail.from,
      message: mail.body.decoded
    )
  end
end
```

### Resources

- [PR #34786 - Adds Action Mailbox](https://github.com/rails/rails/pull/34786)
- [Rails Documentation for Action Mailbox](https://guides.rubyonrails.org/action_mailbox_basics.html)
- [Rails 6 Action Mailbox Tryout](https://blog.saeloun.com/2019/11/11/rails-6-action-mailbox-tryout/)

### Summary

With Action Mailbox, Rails apps can become full-fledged email receivers. It brings an elegant, Rails-style approach to handling inbound messages.


Rails 6 introduces Action Mailbox for inbound emails


Ruby 2.6 ships with **MJIT (Method-based Just-In-Time compiler)** – a major performance milestone under the **Ruby 3x3** initiative aiming to make Ruby 3.0 3x faster than 2.0.

### What is the JIT?

The JIT compiler attempts to speed up Ruby programs by compiling Ruby code into native machine code at runtime. This reduces the overhead of interpretation, especially in compute-heavy programs.

### How to enable it

```bash
ruby --jit your_script.rb
```

Or set the environment variable:

```bash
RUBYOPT="--jit"
```

There are also flags for fine-tuning:

```bash
--jit-verbose=1         # See verbose compilation logs
--jit-wait              # Block execution until JIT compiles
--jit-min-calls=5       # Lower threshold for compilation
--jit-save-temps        # Keep compiled C files
```

### When Does It Help?

JIT gives noticeable performance benefits when your code includes:

- Heavy CPU-bound loops
- Repeated method calls
- Long-running or benchmarked workloads

It won’t help I/O-bound apps and may slow down short-lived scripts due to compilation overhead.

### Real World Example

A simple benchmark comparing MJIT with and without:

```ruby
# mjit.rb
require 'benchmark'

puts Benchmark.measure {
  def test_loop
    i = 0
    while i < 400_000_000
      i += 1
    end
  end

  10.times { test_loop }
}
```

Run it:

```bash
ruby --jit --jit-verbose=1 --disable-gems mjit.rb
```

Once the JIT kicks in after the 5th iteration (default threshold), performance improves dramatically — from ~0.45s to ~0.10s.

### JIT and Rails?

While MJIT shows promise in benchmarks, enabling it in Rails apps doesn’t yet yield big performance wins. Use:

```bash
RUBYOPT="--jit" bundle exec rails s
```

Benchmark carefully — gains may vary depending on app behavior and duration.

### MJIT: Present and Future

- Still **experimental** in Ruby 2.6
- Doesn’t work on Windows
- Needs more maturity and optimizations
- May adopt **LLVM** or **GCC** as backends

MJIT will continue to evolve in Ruby 2.7, 3.0 and beyond — paving the way for the performance-focused Ruby 3x3 vision.

### Resources

- [Ruby 2.6 Release Notes](https://www.ruby-lang.org/en/news/2018/12/25/ruby-2-6-0-released/)
- [MJIT Introduction by Vladimir Makarov](https://www.youtube.com/watch?v=qpZDw-p9yag&t=1655s)
- [Ruby 3x3 Performance Goal](https://developers.redhat.com/blog/2018/03/22/ruby-3x3-performance-goal)

### Summary

Ruby 2.6’s MJIT is a leap forward for performance-conscious Ruby developers. While not yet production-ready for every use case, it lays the groundwork for faster Ruby in the years ahead. Try it in compute-heavy scripts and join the performance journey.


Ruby 2.6 ships an experimental JIT compiler for speed


RSpec 3.8 introduces improvements to the test suite debugging process, particularly with the `--bisect` flag. This tool helps identify the minimal set of examples needed to reproduce a test failure caused by order dependencies.

### What is `--bisect`?

Sometimes, a spec passes when run in isolation but fails when the full suite runs. This usually means there's a hidden dependency or unintended side effect. RSpec's `--bisect` attempts to find the smallest set of specs that reproduce the failure.

### Improvements in RSpec 3.8?

The new version brings:

- Faster execution of `--bisect`
- Better diagnostics and output logs
- Smarter skipping of unrelated examples

### Example usage

```bash
rspec spec --bisect
```

RSpec will repeatedly run subsets of your suite until it finds the minimal group that causes failure.

### Why It Matters

Without `--bisect`, isolating test failures can take hours of manual digging. With the improved version in RSpec 3.8, you can:

- Debug side effects faster
- Maintain better spec hygiene
- Build more confidence in CI pipelines

### Best Practices

- Always run your suite with `--order random` to detect order-dependent specs early.
- Use `--bisect` as part of your CI debugging toolkit.
- Refactor brittle specs once you identify them.

### Links

- [RSpec 3.8 Release Notes](https://rspec.info/blog/2018/08/rspec-3-8-has-been-released/)
- [RSpec Documentation](https://rspec.info/documentation/)
- [RSpec GitHub](https://github.com/rspec/rspec-core)

### Summary

RSpec 3.8 makes the already-useful `--bisect` tool even better. If you're maintaining a large codebase or chasing flaky specs, this upgrade will save you hours of frustration — and help keep your suite solid and deterministic.


RSpec 3.8 improves test isolation with faster bisect


Rails 5.2 brings built-in support for defining **Content Security Policies (CSP)** using a clear and expressive Ruby DSL. CSP is a browser feature that restricts which resources (scripts, styles, etc.) can be loaded on your site.

### Defining a policy

You can define a policy in `app/controllers/application_controller.rb`:

```ruby
class ApplicationController < ActionController::Base
  content_security_policy do |p|
    p.default_src :self, :https
    p.font_src    :self, :https, :data
    p.img_src     :self, :https, :data
    p.object_src  :none
    p.script_src  :self, :https
    p.style_src   :self, :https
  end
end
```

### Benefits of CSP

- Mitigates XSS and injection attacks
- Restricts third-party resource loading
- Helps enforce secure coding practices

### Links

- [PR #31162 - Adds DSL for configuring Content-Security-Policy header](https://github.com/rails/rails/pull/31162)
- [Rails documentation for Content Security Policy DSL](https://guides.rubyonrails.org/v5.2/security.html#content-security-policy)

### Summary

With its new CSP DSL, Rails 5.2 allows developers to easily define and enforce strong content security policies, improving browser-side security without relying on middleware or external gems.


Rails 5.2 implements Content Security Policy DSL


Rails 5.2 introduced **Rails Credentials**, a new way to securely store secrets and application credentials using an encrypted YAML file.

### Why credentials?

Before Rails 5.2, secrets were stored in `secrets.yml`, sometimes unencrypted. This posed a risk when sharing codebases. The new credentials approach improves security and developer experience.

### Setting it up

To edit credentials:

```bash
bin/rails credentials:edit
```

This opens a YAML file that is encrypted using a master key stored in `config/master.key` or `ENV['RAILS_MASTER_KEY']`.

### Example credentials.yml.enc

```yaml
aws:
  access_key_id: 123
  secret_access_key: abc
```

You can access them via:

```ruby
Rails.application.credentials.dig(:aws, :access_key_id)
```

### Links

- [PR #30067 - Adds credentials using a generic EncryptedConfiguration class](https://github.com/rails/rails/pull/30067)
- [PR #30940 - Adds support for managing custom encrypted files from cli](https://github.com/rails/rails/pull/30940)
- [Rails documentation for custom credentials](https://guides.rubyonrails.org/v5.2/security.html#custom-credentials)

### Summary

Rails Credentials consolidate secret management into a single encrypted source, ensuring sensitive data like API keys are secure and easy to access in any environment.


Rails 5.2 rolls out Credentials for encrypted secrets


Rails 5.2 includes support for **HTTP/2 Early Hints**, an optimization technique that allows the server to send preload instructions to the browser before the full response is ready.

### What are Early Hints?

With HTTP/2, servers can send a status code `103 Early Hints` to suggest which assets the browser should start preloading. This can improve perceived performance by beginning asset fetching early.

### How it works in Rails

If you're using a server that supports Early Hints (like Puma + NGINX with proper configuration), Rails 5.2 can automatically send headers like:

```http
Link: </stylesheets/application.css>; rel=preload; as=style
```

This happens while the server is still rendering the page.

### Enable it

Early Hints are sent automatically when:

- The app is running in production
- The web server supports forwarding 103 headers
- `config.public_file_server.headers` is properly configured

To start the server with Early Hints enabled pass `--early-hints` like this:

```bash
bin/rails server --early-hints
```

### Links

- [PR #30744 - Adds HTTP/2 Early Hints for Rails](https://github.com/rails/rails/pull/30744)
- [Documentation for HTTP/2 Early Hints](https://datatracker.ietf.org/doc/html/rfc8297)

### Summary

Early Hints is a performance enhancement that takes advantage of modern browser capabilities and HTTP/2 features. Rails 5.2 makes this cutting-edge optimization available with minimal setup.


Rails 5.2 supports HTTP/2 Early Hints for faster pages


Rails 5.2 introduced native support for using Redis as a cache store with the `:redis_cache_store` option. Prior to this, developers relied on third-party gems to integrate Redis caching into Rails.

### Why Redis?

Redis is an in-memory key-value store known for its speed, simplicity, and robustness, making it a great fit for caching.

### How to configure

In `config/environments/production.rb`:

```ruby
config.cache_store = :redis_cache_store, {
  url: ENV['REDIS_URL'],
  namespace: 'cache'
}
```

You can also configure options like expiration, compression, and error handling.

### Features

- JSON and Marshal serialization
- Automatic connection pooling
- Fallbacks and rescue strategies
- Namespaced keys

### Example usage

```ruby
Rails.cache.fetch('expensive-operation', expires_in: 12.hours) do
  perform_expensive_task
end
```

### Links

- [PR #31134 - Adds Built-in Redis cache store](https://github.com/rails/rails/pull/31134)
- [Rails documentation for Redis Cache Store](https://api.rubyonrails.org/v5.2/classes/ActiveSupport/Cache/RedisCacheStore.html)

### Summary

With native Redis support, Rails developers can take advantage of Redis' powerful caching features without needing extra gems or manual wiring. It’s fast, clean, and production-ready.


Rails 5.2 adds built-in Redis Cache Store support


Rails 5.2 introduced **ActiveStorage**, a built-in solution for handling file uploads in Rails applications. This long-awaited feature brought native support for uploading files to services like Amazon S3, Google Cloud Storage, and Microsoft Azure.

### Why ActiveStorage?

Before ActiveStorage, developers often relied on third-party gems like `CarrierWave` or `Paperclip`. While powerful, they required significant configuration and integration. ActiveStorage is now part of Rails itself, providing:

- Easy setup and use
- Integration with cloud services
- Support for file variants (e.g., thumbnails)
- Direct uploads from the browser

### Setting it up

To get started, you run:

```bash
rails active_storage:install
rails db:migrate
```

This creates the necessary database tables.

In your model:

```ruby
class User < ApplicationRecord
  has_one_attached :avatar
end
```

### Uploading a file

In your form:

```erb
<%= form.file_field :avatar %>
```

Then attach it like:

```ruby
@user.avatar.attach(params[:avatar])
```

### Variants

You can process uploaded images:

```erb
<%= image_tag user.avatar.variant(resize_to_limit: [100, 100]) %>
```

### Links

- [PR #30020 - Adds Active Storage to Rails](https://github.com/rails/rails/pull/30020)
- [Rails documentation for Active Storage](https://guides.rubyonrails.org/v5.2.3/active_storage_overview.html)

### Summary

ActiveStorage modernized file uploads in Rails, giving developers a powerful and integrated toolset for managing attachments, variants, and direct cloud storage without third-party gems.


Rails 5.2 introduces ActiveStorage for file uploads


Basecamp introduced **Stimulus 1.0** as a lightweight JavaScript framework tailored for enhancing server-rendered applications—especially those built with Ruby on Rails. Unlike heavier frontend frameworks, Stimulus doesn’t aim to take over your application. Instead, it works **with** your HTML to add just the behavior you need.

### What is Stimulus?

Stimulus is a "modest" JavaScript framework that adds structure and interactivity to HTML. It observes the DOM and wires up behavior using HTML attributes like `data-controller`, `data-action`, and `data-target`.

It is part of the [Hotwire](https://hotwired.dev/) stack, designed to support fast, modern web apps without heavy JavaScript tooling.

### Why use Stimulus with Rails?

Stimulus complements the Rails philosophy:

- Embraces server-side rendering
- Minimal JavaScript setup and configuration
- Clean integration with Rails views
- Pairs naturally with Turbolinks (now Turbo)

### A simple example

Given an HTML element like this:

```html
<div data-controller="hello">
  <button data-action="click->hello#greet">Greet</button>
</div>
```

You could have a controller like:

```javascript
// hello_controller.js
import { Controller } from 'stimulus';

export default class extends Controller {
  greet() {
    alert('Hello from Stimulus!');
  }
}
```

No need for DOM selectors or event listeners in JavaScript—Stimulus handles it via declarative attributes.

### Key features of Stimulus 1.0

- **Simple and declarative**: Use HTML attributes to bind behavior.
- **Automatic lifecycle management**: Stimulus connects/disconnects controllers as elements appear or disappear.
- **Data-targets and data-values**: Use the DOM as your state tree.

### Use cases

- Form toggles
- Dynamic validation
- Real-time UI updates (when paired with Turbo)
- Alerts, counters, or light interactions

### Summary

Stimulus 1.0 is a perfect match for Rails developers who want JavaScript enhancements **without abandoning server-rendered views**. It provides structure and maintainability while keeping complexity low.

For more, visit [stimulus.hotwired.dev](https://stimulus.hotwired.dev/) or explore how Basecamp and 37signals use it in production.


Stimulus 1.0 – A modest JavaScript framework for Rails


Ruby 2.5 introduced some elegant features that make writing expressive and clean code easier. One such feature is `yield_self`, a method that brings in a functional programming flavor to Ruby’s already flexible syntax.

### What is `yield_self`?

`yield_self` is a method that passes the receiver to a block and returns the block’s result. It’s particularly useful when you want to start a chain with an object, pass it through a transformation, and continue chaining.

### How is it different from `tap`?

You might be familiar with `tap`, which also yields the receiver to a block. However, there is a key difference:

- `tap` returns the original object after yielding it.
- `yield_self` returns the **result of the block**.

### Example: `tap` vs `yield_self`

```ruby
# Using tap
10.tap { |n| puts n + 1 } # prints 11
# => 10 (returns the original object)

# Using yield_self
10.yield_self { |n| n + 1 }
# => 11 (returns the result of the block)
```

### When to use `yield_self`

Use `yield_self` when you want to apply a transformation to an object mid-chain or when you want to perform operations where each step returns a different object.

```ruby
"5".yield_self { |s| Integer(s) }.yield_self { |i| i * 2 }
# => 10
```

It’s especially useful in functional-style pipelines:

```ruby
result = user_input
  .yield_self { |s| s.strip }
  .yield_self { |s| s.downcase }
  .yield_self { |s| s.gsub(/[^a-z]/, '') }
```

### Other notable Ruby 2.5 features

- **Top-level rescue inside do/end blocks** — now you can write `begin ... rescue ... end` inline more concisely.
- **do/end blocks now return** — making multi-line lambdas easier to use.
- **Improved error backtraces** — cleaner and easier to navigate.

### Summary

`yield_self` gives Ruby developers a powerful and elegant way to chain transformations, especially in contexts where intermediate values need to be passed along in a clean and readable manner. It's a small but impactful addition to the Ruby toolbox that promotes a more functional programming style without sacrificing clarity.

For full details on Ruby 2.5, check out the [official release notes](https://www.ruby-lang.org/en/news/2017/12/25/ruby-2-5-0-released/).
