Forem: Takashi SAKAGUCHI

released: active_record_compose 1.0.0 — Wrap multiple models with an ActiveModel interface

Takashi SAKAGUCHI — Thu, 25 Sep 2025 12:09:59 +0000

I just released version 1.0.0 of my gem active_record_compose. 🎉

hamajyotan/active_record_compose (GitHub)

As mentioned in my previous post, this gem has been continuously improved.
Today, I'm excited to announce version 1.0.0!

If you’re curious, here’s my previous post:
Smart way to update multiple models simultaneously in Rails

ActiveRecord Compose is a Ruby gem that implements the form object pattern, allowing you to combine multiple ActiveRecord models into a single, unified business interface.
It goes beyond simple form objects: for example, handling user registration that spans multiple tables. With this approach, complex business operations become easier to write, validate, and maintain. It is built on top of ActiveModel::Model, leveraging the existing Rails infrastructure.

Example:

class Foo < ApplicationRecord
  validates :name, presence: true
end
class Bar < ApplicationRecord
  validates :age, presence: true
end

class Baz < ActiveRecordCompose::Model
  def initialize(attributes)
    @foo = Foo.new
    @bar = Bar.new
    models << foo << bar
    super(attributes)
  end

  delegate_attribute :name, to: :foo
  delegate_attribute :age, to: :bar

  private attr_reader :foo, :bar
end

baz = Baz.new(name: "qux", age: nil)
baz.attributes  #=> {"name" => "qux", "age" => nil}

baz.save  #=> false  # validation from Bar propagates to Baz
baz.errors.to_a  #=> ["Age can't be blank"]

baz.age = 36
baz.save  #=> true

[Foo.count, Bar.count] #=> [1, 1]

Sample Application

https://github.com/hamajyotan/active_record_compose-example

This is a simple micro-blogging application. The app/models/ directory serves as an example of how to use this gem.

Would love feedback or real-world use cases if you try it out!

Rails View Helper Scope and the include_all_helpers Option

Takashi SAKAGUCHI — Fri, 19 Sep 2025 11:36:22 +0000

About the Scope of Default View Helpers

In this article, I’ll explain what scope the methods defined in Rails view helpers apply to,
how to change this scope, and a reasonable step-by-step procedure for safely changing the scope in an existing application.

Methods Defined in Helpers Can Be Called from Any View

For example, suppose you have UsersHelper#display_name defined like this:

# app/helpers/users_helper.rb
module UsersHelper
  def display_name(user)
    "#{user.lastname} #{user.firstname}"
  end
end

This method can be used not only in views rendered by UsersController, but also in views rendered by other controllers:

# app/controllers/posts_controller.rb
class PostsController
  def index
    @posts = Post.all
  end
end

<% # app/views/posts/index.html.erb %>
<% @posts.each do |post| %>
  <p><%= post.content %></p>
  <small><%= display_name(post.user) %></small> <!-- display_name is usable -->
<% end %>

In other words, methods defined in view helpers are basically usable in any view.

You might just accept this as “that’s the spec,” but because the scope is so broad, there are concerns.
Some issues include:

To confirm that a helper method is unused, you must check the entire application.
It’s difficult to predict behavior when methods with the same name are defined in different helpers.

Rails provides an option to address such concerns.

The `config.action_controller.include_all_helpers` Option

As noted above, by default Rails controllers load all helpers.
This behavior depends on the setting of config.action_controller.include_all_helpers.

https://guides.rubyonrails.org/configuring.html#config-action-controller-include-all-helpers

Configures whether all view helpers are available everywhere or are scoped to the corresponding controller.

The default value is true.

So, if you set this option in config/application.rb, the behavior changes:

 module Example
   class Application < Rails::Application # Initialize configuration defaults for originally generated Rails version.
     config.load_defaults 8.0
+
+    config.action_controller.include_all_helpers = false

With this setting, a method like display_name defined in UsersHelper
can no longer be called from a view rendered by PostsController:

# app/helpers/users_helper.rb
module UsersHelper
  def display_name(user)
    "#{user.lastname} #{user.firstname}"
  end
end

# app/controllers/posts_controller.rb
class PostsController
  def index
    @posts = Post.all
  end
end

<% # app/views/posts/index.html.erb %>
<% @posts.each do |post| %>
  <p><%= post.content %></p>
  <!-- Cannot be called! -->
  <small><%= display_name(post.user) %></small> <!-- undefined method 'display_name' for ... -->
<% end %>

How Is the Applicable Helper Determined?

Suppose we have the following controller and helper inheritance structure:

app/
├── controllers
│ ├── admin
│ │ ├── application_controller.rb
│ │ └── users_controller.rb
│ ├── application_controller.rb
│ ├── posts_controller.rb
│ └── users_controller.rb
└── helpers
├── admin
│ ├── application_helper.rb
│ └── users_helper.rb
├── application_helper.rb
├── posts_helper.rb
└── users_helper.rb

class ApplicationController < ActionController::Base; end

class UsersController < ApplicationController; end

class PostsController < ApplicationController; end

class Admin::ApplicationController < ApplicationController; end

class Admin::UsersController < Admin::ApplicationController; end

In the context of UsersController, the following helpers are included:

UsersHelper
ApplicationHelper (always)

This depends on controller inheritance.
UsersController automatically includes UsersHelper, and ApplicationController includes ApplicationHelper.
Thus, UsersController has both UsersHelper and ApplicationHelper methods available.

As another example, in the context of Admin::UsersController, the included helpers are:

Admin::UsersHelper
Admin::ApplicationHelper
ApplicationHelper

This aligns with the inheritance chain:
Admin::UsersHelper, Admin::ApplicationHelper, and then ApplicationHelper.

This behavior is the same as the template lookup inheritance mechanism used for rendering templates and partials:
https://guides.rubyonrails.org/layouts_and_rendering.html#template-inheritance

Migrating an Existing Application to `include_all_helpers = false`

This setting is very useful.
Here’s a migration path for existing applications.

First Step

The first step is, of course, to set config.action_controller.include_all_helpers = false:

 module Example
   class Application < Rails::Application # Initialize configuration defaults for originally generated Rails version.
     config.load_defaults 8.0
+
+    config.action_controller.include_all_helpers = false

With this alone, you’ll get errors in places where helper methods “happened to be available.”
As a temporary measure, include all helpers in ApplicationHelper to maintain existing behavior:

# app/helpers/application_helper.rb
module ApplicationHelper
  include Admin::ApplicationHelper
  include Admin::UsersHelper
  include PostsHelper
  include UsersHelper
end

(In many apps, all controllers ultimately inherit from ApplicationController, so ApplicationHelper is available in every view.)

Narrowing Things Down Gradually

From here, reduce dependencies step by step.
For example, if everything under Admin::\* inherits from Admin::ApplicationController, group them there:

# app/helpers/application_helper.rb
module ApplicationHelper
  include Admin::ApplicationHelper
  include PostsHelper
  include UsersHelper
end

# app/helpers/admin/application_helper.rb
module Admin::ApplicationHelper
  include Admin::UsersHelper
end

Then, remove helpers from ApplicationHelper if they’re only used in a specific controller:

 module ApplicationHelper
   include Admin::ApplicationHelper
-  include PostsHelper
   include UsersHelper
 end

On the other hand, for utility methods used across multiple contexts, move them into ApplicationHelper:

 module ApplicationHelper
   include Admin::ApplicationHelper
-  include UsersHelper
+
+  def very_useful_helper_method(user)
+    #
+  end
 end

 module UsersHelper
-  def very_useful_helper_method(user)
-    #
-  end
 end

By making these adjustments, you can converge toward a scope that is “only available where needed.”

When Helper Methods from Gems Stop Working

This may surface with gems like font-awesome-rails.

That gem provides the view helper method fa_icon.
But when config.action_controller.include_all_helpers = false, you must explicitly include it.
Simply include it in ApplicationHelper, and you’re done.
This makes usage more explicit, which is a good thing for maintainability:

# app/helpers/application_helper.rb
module ApplicationHelper
  include FontAwesome::Rails::IconHelper
end

Related issue

Summary

By default, methods defined in view helpers can be called from any controller’s view.
Setting config.action_controller.include_all_helpers = false restricts loaded helpers to those corresponding to the controller (and its inheritance chain).
ApplicationHelper is always included regardless of the setting, making it a good place for common methods.
For migration, the safe path is: “collect everything in ApplicationHelper first → then gradually move and reduce.”

Disclaimer

The content in this article was verified with Rails 8.0.2.1,
but the behavior is basically the same in many past versions.
(Strictly speaking, this assumes Rails 3.1 or later, when include_all_helpers was introduced.)

Avoiding Symbol Block-Pass (&:to_s) in Ruby and Choosing More Readable Alternatives

Takashi SAKAGUCHI — Thu, 18 Sep 2025 00:51:40 +0000

In Ruby, it’s common to see the shorthand syntax using symbols as block arguments, such as &:to_s.
While this looks concise and elegant, it can be confusing for beginners and isn’t always well supported by IDEs or refactoring tools.

Recently, more intuitive options like it and _1 have been introduced, which raises the question: should teams start unifying their style around them?

This article explores the idea of intentionally avoiding the symbol block-pass syntax and shows a practical approach using RuboCop.

The Evolution of Block Parameters

Ruby has gone through several stages of block parameter evolution.

# All of the following return ["1", "2", "3"]

# The most primitive style
[1, 2, 3].map { |i| i.to_s }

# Since Ruby 1.9
[1, 2, 3].map(&:to_s)

# Since Ruby 2.7 (Numbered Parameters)
[1, 2, 3].map { _1.to_s }

# Since Ruby 3.4 (it parameter)
[1, 2, 3].map { it.to_s }

The primitive style

The classic way requires explicitly naming a block parameter:

[1, 2, 3].map { |i| i.to_s }

Even though the variable name doesn’t matter, you still need to provide one.

Symbol#to_proc style

Ruby 1.9 introduced the shorthand using Symbol#to_proc:

[1, 2, 3].map(&:to_s)

Internally, :to_s.to_proc behaves like this:

sym = :to_s
blk = sym.to_proc

# Roughly equivalent to:
# ->(obj, *args, **kwargs, &block) { obj.public_send(:to_s, *args, **kwargs, &block) }

blk.call(1)  # => "1"

When passed as a block (&:to_s), Ruby implicitly calls to_proc and executes the method.

Numbered Parameters and `it`

Later came Numbered Parameters (_1) in Ruby 2.7, and the it shorthand in Ruby 3.4, both expressing the idea that “the name doesn’t matter.”

[1, 2, 3].map { _1.to_s }
[1, 2, 3].map { it.to_s }

Other languages also have similar constructs, like Kotlin’s it or Scala’s _.

Why Avoid Symbol Block-Pass?

The motivation behind these newer syntaxes is to make the “namelessness” of the parameter explicit.
Both _1 and it solve this issue, and personally, I prefer it—it reads naturally, it’s the newest addition, and it aligns with current Ruby trends.

The problem with Symbol#to_proc is that non-Ruby developers often struggle to understand it at a glance.
Ruby is fun because it offers multiple ways to write the same thing, but if we want Ruby to stay beginner-friendly and appealing, readability matters.

Also, _1 and it integrate better with IDEs and refactoring tools.

That’s why I believe Symbol#to_proc should be limited to code golf or niche cases, and we should stop using it in everyday production code.

A Custom RuboCop Cop

To enforce this idea, here’s a custom RuboCop cop.
It flags usages like array.map(&:to_s) and suggests replacing them with it (or _1).

It works like the inverse of Style::SymbolProc.

# To enable this custom cop, add the following to `.rubocop.yml`:
#
# require:
#   - path/to/custom/cop/avoid_symbol_block_pass.rb
#
# Custom/AvoidSymbolBlockPass:
#   Enabled: true
#
# --- Offense (NG) ---
# array.map(&:to_s)
# users.each(&:destroy)
#
# --- Allowed (OK) ---
# array.map { it.to_s }
# users.each { it.destroy }

class RuboCop::Cop::Custom::AvoidSymbolBlockPass < RuboCop::Cop::Base
  MSG = "Avoid using Symbol#to_proc (`&:to_s`). Consider using `it` or `_1` instead."

  def on_block_pass(node)
    return unless node.children.first&.sym_type?

    add_offense(node)
  end
end

Conclusion

Ruby provides multiple block syntaxes, each with historical context.
Symbol#to_proc (&:to_s) is concise, but not beginner-friendly and not IDE-friendly.
Prefer clearer alternatives like it (or _1).
Use a RuboCop custom cop to enforce this style within your team.

By shifting away from the symbol block-pass syntax, we can make Ruby codebases more approachable, consistent, and easier to maintain.

How to Get More Detailed Information When RSpec Tests Fail

Takashi SAKAGUCHI — Tue, 16 Sep 2025 12:06:15 +0000

When an RSpec test fails, of course, the first thing we do is try to figure out why.
In a local environment, you might stop the process with binding.b (using byebug, pry, etc.) and investigate directly in the console. But what about those flaky tests that only fail on CI? Debugging them can be far more challenging.

In this article, I’ll share a small but useful technique: customizing failure messages in RSpec. This trick can help you even when debugging is hard in CI environments.

The second argument of `expect(...).to matcher, message`

You’ve probably written something like this before:

expect(actual).to eq(expected)

What’s less known is that the .to method actually takes a second argument for a failure message:

expect(actual).to eq(expected), "Not matching"

If the expectation fails, "Not matching" will be shown.
Even better—you can pass a block instead of a plain string:

expect(actual).to eq(expected), -> { "Not matching: actual=#{actual.inspect}" }

This block is evaluated only when the matcher fails, which means you can embed state information into the failure message—almost like custom logging.

Useful for debugging flaky tests in CI

Tests that fail only on CI are especially tricky since reproducing them locally can be impossible.
That’s where this technique shines. You can embed contextual data directly into the failure message:

expect(result).to eq("success"), -> {
  <<~MSG
    Result did not match.
    Actual value: #{result.inspect}
    User ID: #{user.id}
    Request params: #{params.inspect}
  MSG
}

With this in place, the CI logs themselves may contain enough information for you to figure out what went wrong.

How it works

The mechanism comes from the second argument (message) of RSpec::Expectations::ExpectationHelper.handle_failure.

You can see the relevant code here:
https://github.com/rspec/rspec-expectations/blob/v3.13.3/lib/rspec/expectations/handler.rb#L32-L34

What about `.not_to` and `raise_error`?

This technique works with .not_to and even expect { ... }.to raise_error.
That’s because all RSpec matchers eventually go through RSpec::Expectations::ExpectationHelper.handle_failure.

Conclusion

By passing a second argument or a block to RSpec’s .to method, you can fully customize failure messages.
This isn’t just about changing the wording—it’s also a powerful way to leave debugging information in CI logs, especially for flaky tests that are hard to reproduce locally.

The next time you encounter a hard-to-track bug, try this technique—you might get much closer to the root cause.

Helpful Settings When Running RSpec with parallel_tests

Takashi SAKAGUCHI — Wed, 03 Sep 2025 01:55:55 +0000

This article describes a few settings that are useful when running tests with parallel_tests, especially for reproducing and investigating failures that occur during CI runs.

`parallel_tests`

In CI environments, we often run RSpec in parallel to speed things up.

For that, there’s a gem called parallel_tests.

It’s very handy for utilizing multi-core CPUs efficiently.

While the README covers setup well enough, debugging becomes trickier when parallel execution introduces flaky tests.

In this post, I’ll share a few TIPS for handling flaky tests when running RSpec with parallel_tests in CI.

TIPS

Fix the seed across all processes

Using RSpec’s seed is helpful for reproducing failures with the same test order.

When running tests in parallel, each process gets its own seed value.

For debugging, though, it’s more efficient if all processes share the same seed.

This doesn’t mean always running with a fixed seed — rather, you generate a random number once and pass it explicitly to all processes.

Without --seed, RSpec decides the seed internally here:

https://github.com/rspec/rspec-core/blob/v3.13.2/lib/rspec/core/ordering.rb#L147-L152

It uses rand(0xFFFF). So, by passing the same value via --seed, you can align all processes.

Example:

$ ruby -e "puts rand(0xffff)"
22357
$ ruby -e "puts rand(0xffff)"
7574
$ ruby -e "puts rand(0xffff)"
11717

Then run your tests like this:

$ bundle exec parallel_rspec -- --seed $(ruby -e "puts rand(0xFFFF)") -- spec/

For more about using --seed to deal with flaky tests in RSpec, I wrote another article:
https://dev.to/hamajyotan/tame-your-flaky-rspec-tests-by-fixing-the-seed-ffl

See which files each process is responsible for

When you run parallel_rspec, test files are distributed across processes.
However, by default, you can’t tell which process is handling which files from the output.

To make this visible, you can use RSpec’s before(:suite) hook:

# spec/rails_helper.rb
RSpec.configure do |config|
  config.before(:suite) do
    files = config.files_to_run
    normalized = files.map { Pathname.new(File.absolute_path(it)).relative_path_from(Rails.root) }
    banner = "PID (#{Process.pid}) #{normalized.count} files to run:"
    puts [banner, *normalized].join("\n\t")

    # ...
  end

  # ...
end

Docs:
https://github.com/rspec/rspec-core/blob/v3.13.2/lib/rspec/core/configuration.rb#L1094-L1098

Now each process will output something like:

PID (1075695) 5 files to run:
    spec/controllers/bars_controller_spec.rb
    spec/controllers/foos_controller_spec.rb
    spec/models/bar_spec.rb
    spec/models/baz_spec.rb
    spec/models/foo_spec.rb

PID (1075696) 4 files to run:
    spec/controllers/bazs_controller_spec.rb
    spec/controllers/hoges_controller_spec.rb
    spec/controllers/root_controller_spec.rb
    spec/models/hoge_spec.rb

See the execution order of files in each process

Sometimes failures depend on the execution order of test files.
With the previous TIPS, you know which seed and which file set was assigned to a process, but not the actual execution order.

Suppose CI shows this failure:

PID (1075695) 5 files to run:
    spec/controllers/bars_controller_spec.rb
    spec/controllers/foos_controller_spec.rb
    spec/models/bar_spec.rb
    spec/models/baz_spec.rb
    spec/models/foo_spec.rb

Randomized with seed 54242

You could reproduce it locally like this:

bundle exec rspec --seed 54242 \
    spec/controllers/bars_controller_spec.rb \
    spec/controllers/foos_controller_spec.rb \
    spec/models/bar_spec.rb \
    spec/models/baz_spec.rb \
    spec/models/foo_spec.rb

Of course, this works fine, but what if the CI execution log looked like the following?
(Here I’m using the progress format)

...F...........

Somehow, you can guess that spec/models/foo_spec.rb was executed relatively early.
Even if your future self knows that this file was actually the second one to run, at this point you’d still need to include all five files in order to reproduce the failure.
(Of course, there’s always the “cheat” of relying on an experienced developer’s intuition…)

That’s why, if you can see the actual execution order of the test files, you can streamline the reproduction steps.
Let’s update the earlier code as follows:

 RSpec.configure do |config|
   config.before(:suite) do
-    files = config.files_to_run
+    files = config.world.ordered_example_groups.map { it.file_path }
     normalized = files.map { Pathname.new(File.absolute_path(it)).relative_path_from(Rails.root) }
     banner = "PID (#{Process.pid}) #{normalized.count} files to run:"
     puts [banner, *normalized].join("\n\t")

     # ...
   end

   # ...
 end

After making the above adjustments, the output will appear as follows.
The order of the files has changed, hasn't it?

PID (1075695) 5 files to run:
    spec/controllers/foos_controller_spec.rb
    spec/models/foo_spec.rb
    spec/models/bar_spec.rb
    spec/models/baz_spec.rb
    spec/controllers/foos_controller_spec.rb

Then, RSpec proceeds with the tests in the order they are output here.
Also, since the failing test was in spec/models/foo_spec.rb, you don't need to run anything after that to reproduce the issue.
This shows that the following is sufficient for local reproduction. The reproduction steps are significantly streamlined!
This saves a lot of time.

bundle exec rspec --seed 54242 \
    spec/controllers/foos_controller_spec.rb \
    spec/models/foo_spec.rb

⚠️ Note: Both world and ordered_example_groups are private APIs:

So be aware they may change without notice.

Conclusion

parallel_tests is excellent for speeding up CI, but its parallelism often makes debugging flaky tests more challenging.
With the TIPS outlined above, reproducing and investigating such failures becomes much more manageable.

Even if your test results look messy at first, with the right setup you can methodically trace the root cause — and keep your CI pipeline stable.

Tame Your Flaky RSpec Tests by Fixing the Seed

Takashi SAKAGUCHI — Wed, 23 Jul 2025 12:49:18 +0000

About This Article

Have you ever experienced tests that occasionally fail when running your RSpec test suite on CI? These are what we call flaky tests.

Simply re-running the test until it passes and calling it a day is a missed opportunity. Let’s take a more sustainable approach to fixing them.

Enable `config.order` and `Kernel.srand`

The key idea here is simple: enable the following configuration in your RSpec settings file, which is generated by default but commented out.

# spec/spec_helper.rb
  # Run specs in random order to surface order dependencies. If you find an
  # order dependency and want to debug it, you can fix the order by providing
  # the seed, which is printed after each run.
  #     --seed 1234
  config.order = :random

  # Seed global randomization in this process using the `--seed` CLI option.
  # Setting this allows you to use `--seed` to deterministically reproduce
  # test failures related to randomization by passing the same `--seed` value
  # as the one that triggered the failure.
  Kernel.srand config.seed
=end

Once enabled, this lets you reproduce random test failures deterministically using the seed printed after each test run.

These lines are typically wrapped in =begin and =end comments when generated, so make sure to move them out to enable them.

Reference:
https://github.com/rspec/rspec-core/blob/v3.13.2/lib/rspec/core/project_initializer/spec/spec_helper.rb#L86-L97

=begin
  These lines
  # are all comments
=end

A Hands-On Example of Dealing with Flaky Tests

Let’s walk through an example to see how flaky tests can be identified and fixed.

Setup from rails new

# Create a new Rails app
$ rails new --skip-test rspec-rails-test
$ cd rspec-rails-test/

# Add and set up rspec-rails
$ bundle add rspec-rails --group development,test
$ rails generate rspec:install

Now activate the config.order and Kernel.srand settings by moving them outside of the comment block.

   config.profile_examples = 10
+=end

   config.order = :random
   Kernel.srand config.seed
-=end
 end

Confirm RSpec runs successfully with zero examples:

$ bundle exec rspec
No examples found.

Randomized with seed 37597

Create a Model and Write a Test

Let’s create a simple model named YearMonth with year and month attributes, and some basic validations.

# app/models/year_month.rb

class YearMonth
  include ActiveModel::Model
  include ActiveModel::Attributes

  attribute :year, :integer
  attribute :month, :integer

  validates :year, numericality: { only_integer: true }
  validates :month, numericality: { only_integer: true, in: (1..12) }
end

Now, add a basic test to confirm that the model is valid.

# spec/models/year_month_spec.rb

require "rails_helper"

RSpec.describe YearMonth do
  subject { YearMonth.new(attributes) }

  let(:attributes) { { year:, month: } }
  let(:year) { rand(2100) }
  let(:month) { rand(12) }

  it do
    expect(subject.valid?).to be_truthy
  end
end

Run the Test

$ bundle exec rspec
Randomized with seed 54242
.

Finished in 0.0191 seconds
1 example, 0 failures

If you were unlucky and saw a failure like this, just re-run the test and confirm it eventually passes:

Randomized with seed 30925
F

Failures:

  1) YearMonth is expected to be truthy
     Failure/Error: expect(subject.valid?).to be_truthy

       expected: truthy value
            got: false

Observe Occasional Failures

Actually, this test sometimes fails.
After several runs, you should see an abnormal termination as shown below.

It is like a CI that is terminating normally and cheerfully in the product code, but sometimes notifies you of a failure.

$ bundle exec rspec

Randomized with seed 30925
F

Failures:

  1) YearMonth is expected to be truthy
     Failure/Error: expect(subject.valid?).to be_truthy

       expected: truthy value
            got: false
     # ./spec/models/year_month_spec.rb:11:in 'block (2 levels) in <top (required)>'

Finished in 0.01313 seconds (files took 0.50544 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/models/year_month_spec.rb:10 # YearMonth is expected to be truthy

Randomized with seed 30925

$

In real-world projects, it's useful to automate the test run in a loop and go grab lunch. Here’s a sample shell script:

#!/bin/bash
set -euxo pipefail

i=0
while true
do
  i=$((i + 1))
  bundle exec rspec
done

Reproduce the Failure

The key detail is this line in the output:

Randomized with seed 30925

You can reproduce the exact test order and failure using this seed:

$ bundle exec rspec --seed 30925

Debug the Failure

Now that it’s reproducible, debugging is straightforward. Add a puts statement to inspect the attributes:

   it do
+    puts "attributes: #{subject.attributes.inspect}"
     expect(subject.valid?).to be_truthy
   end

$ bundle exec rspec --seed 30925
attributes: {"year" => 1913, "month" => 0}
F

The month is 0 — that’s not valid. The issue is with rand(12), which generates values from 0 to 11.

let(:month) { rand(12) }

> 10000.times.map { rand(12) }.uniq.sort
=> [0, 1, ..., 11]

Fix the Root Cause

Fix the range to 1..12 instead of 0..11:

-  let(:month) { rand(12) }
+  let(:month) { rand(1..12) }

> 10000.times.map { rand(1..12) }.uniq.sort
=> [1, 2, ..., 12]

Now commit and push your fix:

git commit -m 'fix flaky test'

Summary

Enabling config.order = :random and Kernel.srand config.seed in spec/spec_helper.rb helps identify and debug flaky tests.
Use the printed seed value and --seed option to reliably reproduce failures.
Don’t leave flaky tests lying around — fix them to ensure your CI surfaces real issues, not noise.

Ephemeral Design Manifesto

Takashi SAKAGUCHI — Wed, 04 Jun 2025 04:56:27 +0000

Purpose

In a world where software must evolve or perish, we embrace a principle often overlooked:
The value of things that are designed to disappear.

Ephemeral Design is a mindset that encourages developers to build systems with impermanence in mind—favoring modularity, replaceability, and minimal long-term baggage.

Principles

Favor deletion over preservation.
Removing outdated or unused components should feel natural—not painful.
Design with a clear exit strategy.
Temporary features and experiments should always come with a built-in plan for removal or replacement.
Ephemeral Design Manifesto
Keep experimental or low-confidence components loosely coupled to reduce unintended dependencies.
Be honest about what might disappear.
Make it clear—by convention, structure, or documentation—which parts are meant to be transient.
Optimize for change, not permanence.
Code should support the present, not fossilize the past.

Practice Hints

Modularize everything: small parts are easier to remove or replace.
Isolate experimental features from the core domain logic.
Document the lifespan of components, especially if temporary.
Avoid over-engineering for uncertain features.
Use structure or conventions to indicate ephemerality (e.g., separate directories, metadata, flags)—but balance clarity with elegance.

Cultural Impact

Adopting Ephemeral Design doesn’t mean building carelessly.
It means building intentionally, with the courage to discard what no longer serves.

Teams that embrace this mindset:

Move faster by reducing fear of technical debt
Feel safer experimenting and iterating
Write more honest, sustainable software

Closing Thought

Everything is temporary—especially in code.
By designing with this in mind, we create systems that are not just flexible, but free.

How to Run a Rails Application on GitHub Codespaces

Takashi SAKAGUCHI — Tue, 29 Apr 2025 02:40:08 +0000

In this article, I’ll guide you through my experience running a Rails application on GitHub Codespaces.

Although there are still a few hurdles to overcome, I hope that by sharing the issues I encountered and how I addressed them, others can have a smoother experience when trying it themselves.

Summary First

To run a Rails application on GitHub Codespaces, using rails new with the --devcontainer option generally works, but there are a few caveats.
General caveats (not specific to Codespaces):
- Since the access will be through a domain name rather than localhost, you need to adjust config.hosts.
Codespaces-specific issues (as of 2025/04/29):
- POST requests cannot be processed.
  - The application fails the origin check based on the HTTP Origin header, so you need to set config.action_controller.forgery_protection_origin_check to false.
- Port forwarding in GitHub Codespaces does not work by default.
  - You need to apply one of the following workarounds:
    - Change the port visibility from Private → Public → Private. For some reason, switching back enables Private access (accessible only by yourself).
    - Replace the docker image from the Rails-provided one to a Microsoft-provided image.
    - Disable the forwardPorts setting in .devcontainer/devcontainer.json.

What is GitHub Codespaces?

GitHub Codespaces is a cloud-based development environment provided by GitHub.
https://github.com/features/codespaces

It allows you to start developing with just a browser.
Note that the browser-based VS Code (github.dev) is mainly a code editor and does not provide a full runtime environment for applications. In contrast, GitHub Codespaces offers not only an editor but also a complete environment where you can run applications.

GitHub users are provided with a free monthly allowance of 15 GB storage and 120 core hours.
GitHub Pro users receive 20 GB storage and 180 core hours per month.

Additionally, a codespace becomes idle after 30 minutes of inactivity and is deleted after 30 days of inactivity.
You can change these timeout settings at: https://github.com/settings/codespaces

For more details:
https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-codespaces

Running a Rails Application on GitHub Codespaces

The `--devcontainer` Option

The rails new command, which is used to generate a new Rails application, has an option called --devcontainer.
When you run rails new with this option, it automatically generates several files under the .devcontainer/ directory.

$ rails new sample --devcontainer
$ cd sample/
$ ls .devcontainer/
compose.yaml  devcontainer.json  Dockerfile

With these files, you can open the development environment inside a VS Code dev container.
Although the detailed explanation of these files is omitted here, you will also use this setup when launching the environment on GitHub Codespaces.

Opening the Project in GitHub Codespaces

After running rails new, make your first commit and push the code to a GitHub repository.
Then, you can access the following URL to open it in GitHub Codespaces:

https://codespaces.new/OWNER/REPO

You will see a screen confirming that the Codespace is being created.
As a side note, you can also add a link directly in your README.md by including the following snippet:

[![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/OWNER/REPO)

This will display a badge like the one below:

NOTE: Please replace OWNER and REPO with the appropriate values for your repository.

Operations on Codespace

After launching the Codespace and waiting a short while, you will notice that bin/setup --skip-server is automatically executed in the console.
You can find the setting for this behavior in the files generated when you run rails new with the --devcontainer option.

.devcontainer/devcontainer.json

  // Use 'postCreateCommand' to run commands after the container is created.
  "postCreateCommand": "bin/setup --skip-server"

Once setup is complete, you can start the Rails server manually by running:

rails s

...However, you still won't be able to access the application just yet. There's a bit more to do!

Issue with Port Forwarding Settings on Codespace

GitHub Codespaces provides a port forwarding feature that allows external access to a Rails server running inside the Codespace at http://localhost:3000.

You can find more information here:
https://docs.github.com/en/codespaces/developing-in-a-codespace/forwarding-ports-in-your-codespace

By default, ports are set to Private, which means you can access them directly from your browser as long as you are logged in to GitHub with your account.
...However, currently, you need to make some change before you can actually access it — otherwise, access won't work for some reason.
Even though the default setting is Private, to make it work while keeping it Private, you need to manually change it to Public and then back to Private.

NOTE:
I have reported this behavior — where port forwarding does not work unless a manual change is made — in the following discussions:

https://github.com/orgs/community/discussions/156546

https://github.com/rails/devcontainer/issues/83

Depending on how this issue is resolved, this workaround may become unnecessary in the future.

Workarounds Other Than Manual Toggling

As mentioned above, by manually changing the port visibility from Private → Public → Private, port forwarding will function properly while maintaining the intended Private setting.
If you don't mind doing this manually, that's fine. However, if you want the port visibility to work correctly immediately after startup, there are a few other methods available.

(That said, from the perspective of "being able to start developing right after running rails new and opening a Codespace," I personally think these methods are not ideal. I hope this situation will improve in the future.)

Replacing the Docker Image

When you run the rails new --devcontainer command, it generates a devcontainer configuration with the following content:

.devcontainer/Dockerfile

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
ARG RUBY_VERSION=3.4.2
FROM ghcr.io/rails/devcontainer/images/ruby:$RUBY_VERSION

By default, the Docker image used is ghcr.io/rails/devcontainer/images/ruby, maintained by the Rails team.
You can replace this with the Ruby image provided by Microsoft: mcr.microsoft.com/devcontainers/ruby.
To do so, modify the Dockerfile like this:

.devcontainer/Dockerfile

 # Make sure RUBY_VERSION matches the Ruby version in .ruby-version
 ARG RUBY_VERSION=3.4.2
+FROM ghcr.io/rails/devcontainer/images/ruby:$RUBY_VERSION
-FROM mcr.microsoft.com/devcontainers/ruby:3.4

With this change, the port forwarding issue is avoided, and you can start development with proper Private port visibility working out of the box.

Remove `forwardPorts`

When you run rails new with the --devcontainer option, the generated .devcontainer/devcontainer.json file includes the following line:

This setting automatically forwards the specified ports from the container to the host machine.
However, if you disable this and rely on automatic port detection when port 3000 is actually used, you can avoid the issue and start with a properly functioning Private port forwarding setting.

   // Use 'forwardPorts' to make a list of ports inside the container available locally.
-  "forwardPorts": [3000],
+  // "forwardPorts": [3000],

Solve the "Blocked hosts" Error

At this point, if you try to access the application from your browser, you will encounter an error.

Blocked hosts: symmetrical-spoon-6vxqqgxx4cr6qq-3000.app.github.dev
To allow requests to these hosts, make sure they are valid hostnames (containing only numbers, letters, dashes and dots), then add the following to your environment configuration:
    config.hosts << "symmetrical-spoon-6vxqqgxx4cr6qq-3000.app.github.dev"

For more details view: the Host Authorization guide

To resolve this, as indicated in the error message, you need to add the host to config.hosts.
We will use environment variables set when running in GitHub Codespaces.

config/environments/development.rb


Rails.application.configure do
  if ENV["CODESPACES"] == "true"
    # Add the Codespace domain to the list of allowed hosts.
    # Alternatively, if you prefer simplicity, you could `config.hosts.clear` instead.
    #
    codespaces_port_forwarding_domain = ENV["GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN"]
    codespace_name = ENV["CODESPACE_NAME"]
    host = "#{codespace_name}-3000.#{codespaces_port_forwarding_domain}"

    config.hosts << host
  end

  # (Other settings omitted...)
end

After editing config/environments/development.rb, stop the currently running rails s server, restart it, and then refresh your browser.
You should now be able to access the application without issues.

POST Requests Cannot Be Handled

Following the steps so far, your Rails application will run in GitHub Codespaces.
However, at this point, only GET requests are handled successfully - POST requests will still fail.
You will encounter this issue when implementing features that use forms, for example.

ActionController::InvalidAuthenticityToken (HTTP Origin header (http://localhost:3000) didn't match request.base_url (https://symmetrical-spoon-6vxqqgxx4cr6qq-3000.app.github.dev)):

This error occurs because the HTTP Origin header does not match the actual request URL.

(ruby) request.base_url
"https://symmetrical-spoon-6vxqqgxx4cr6qq-3000.app.github.dev"
(ruby) request.origin
"http://localhost:3000"
(rdbg)

However, from the browser's perspective, the Origin header is correctly being set based on the currently accessed domain.

It seems that somewhere within the network layer that GitHub Codespaces uses to expose ports externally, the Origin header is being rewritten.
I have reported this issue, so the situation might change in the future. (If it does, I will update this article.)
https://github.com/orgs/community/discussions/156532

Allowing POST Requests to Work in GitHub Codespaces

NOTE:
I have reported the issue regarding the rewriting of the Origin header here:
https://github.com/orgs/community/discussions/156532

Depending on how this issue is resolved, the workaround described below might become unnecessary in the future.

The check that causes the error is controlled by the Rails configuration setting config.action_controller.forgery_protection_origin_check.

3.9.8 config.action_controller.forgery_protection_origin_check (Rails Guides)

Configures whether the HTTP Origin header should be checked against the site's origin as an additional CSRF defense.

Ideally, we would like to respect the default value as much as possible.
However, to get Rails applications working in GitHub Codespaces, I adjusted the configuration to disable this setting only when running in Codespaces.

config/environments/development.rb


 Rails.application.configure do
   if ENV["CODESPACES"]
     codespaces_port_forwarding_domain = ENV["GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN"]
     codespace_name = ENV["CODESPACE_NAME"]
     host = "#{codespace_name}-3000.#{codespaces_port_forwarding_domain}"

     config.hosts << host
+
+    warn "Disabling the CSRF protection Origin header check in GitHub Codespaces"
+    config.action_controller.forgery_protection_origin_check = false
   end

With this change, POST requests now work as expected!

Summary & Promotion

GitHub Codespaces is a great choice for easily experiencing a sample application development environment directly in your browser.
Of course, you can also use it for actual development.

As explained earlier, several adjustments are needed to run a Rails application smoothly.
Also, you need to be aware of some points regarding port forwarding settings, but there are workable solutions for them.

As a related note, I have created a Ruby gem called active_record_compose,
which provides a way to compose multiple ActiveRecord models and treat them as if they were a single model.

I have prepared a sample application environment to try it out directly on GitHub Codespaces — feel free to check it out!

I also wrote an article about the gem here:

Smart way to update multiple models simultaneously in Rails - DEV Community

Smart way to update multiple models simultaneously in Rails

Takashi SAKAGUCHI — Wed, 23 Oct 2024 16:28:06 +0000

I created a gem called active_record_compose, which helps keep your Rails application clean. Below is a brief guide on how to use it.
If you are interested, please use it.

complexity rails

Designing a resource that adheres to RESTful principles and creating CRUD operations for it is something that Rails excels at. You can see how easily this is expressed by looking at the controllers generated by the scaffold command.

However, things get a bit more complicated when you need to update multiple models simultaneously from a single controller. For example, below is an example of an action that updates both the User and Profile models at the same time.

create_table :users do |t|
  t.string :email, null: false
  t.timestamps
end

create_table :profiles do |t|
  t.references :user, index: { unique: true }, null: false
  t.string :display_name, null: false
  t.integer :age, null: false
  t.timestamps
end

# app/models/user.rb
class User < ApplicationRecord
  has_one :profile
  validates :email, presence: true
end

# app/models/profile.rb
class Profile < ApplicationRecord
  belongs_to :user
  validates :display_name, :age, presence: true
end

On the other hand, let's define an action called UserRegistrationsController#create to handle the user registration process for the system.

# config/routes.rb
# Omit the previous and following.
  resource :user_registration, only: %i[new create]

Additionally, once the registration is successfully completed, let's send a thank-you email notification.

# app/controllers/user_registrations_controller.rb
class UserRegistrationsController < ApplicationController
  def new
    @user = User.new.tap { _1.build_profile }
  end

  def create
    @user = User.new(user_params)
    @profile = @user.build_profile(profile_params)

    result =
      ActiveRecord::Base.transaction do
        saved = @user.save && @profile.save
        raise ActiveRecord::Rollback unless saved
        true
      end

    if result
      UserMailer.with(user: @user).registered.deliver_later
      redirect_to user_registration_complete_path, notice: "registered."
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def user_params
    params.require(:user).permit(:email)
  end

  def profile_params
    params.require(:profile).permit(:display_name, :age)
  end
end

<!-- app/views/user_registrations/new.html.erb -->
<% content_for :title, "New user registration" %>

<h1>New user registration</h1>

<%= form_with(model: @user, url: user_registration_path) do |form| %>
  <% if @user.errors.any? || @user.profile.errors.any? %>
    <div style="color: red">
      <h2>
        <%= pluralize(@user.errors.count + @user.profile.errors.count, "error") %>
        prohibited this user_registration from being saved:
      </h2>

      <ul>
        <% @user.errors.each do |error| %>
          <li><%= error.full_message %></li>
        <% end %>
        <% @user.profile.errors.each do |error| %>
          <li><%= error.full_message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>

  <div>
    <%= form.label :email, style: "display: block" %>
    <%= form.text_field :email %>
  </div>

  <%= fields_for :profile do |profile_form| %>
    <div>
      <%= profile_form.label :display_name, style: "display: block" %>
      <%= profile_form.text_field :display_name %>
    </div>
    <div>
      <%= profile_form.label :age, style: "display: block" %>
      <%= profile_form.number_field :age %>
    </div>
  <% end %>

  <div><%= form.submit %></div>
<% end %>

Although the above implementation works, there are some bugs and issues. Let's go over them.

Code Issues

Some `errors` Are Missing

Controller Code Excerpt

        saved = @user.save && @profile.save

Both @user and @profile are being saved, but if @user's #save fails, @profile is not evaluated. As a result, nothing is stored in @profile.errors.

Ideally, all fields email, display_name, and age should be required. In this case, if none of them are filled in, the error details should be stored in @user.errors[:email], @profile.errors[:display_name], and @profile.errors[:age] respectively. (Otherwise, error messages cannot be displayed in the view.)

While some leniency may be acceptable, to be strict...

        saved = [@user.save, @profile.save].all?

Thus, we may need to be careful not to be shortchanged in our evaluation.

Controllers and Views Are Too Aware of the Model Structure Details

User and Profile have a has_one relationship, and the controller is aware of this structure. It uses user.build_profile and defines user_params and profile_params separately.

  def new
    user = User.new.tap { _1.build_profile }

  def create
    @user = User.new(user_params)
    @profile = @user.build_profile(profile_params)

  def user_params
    params.require(:user).permit(:email)
  end

  def profile_params
    params.require(:profile).permit(:display_name, :age)
  end

Additionally, when assigning individual parameters in this controller, you can write it as follows by using form.fields_for instead of fields_for in the view.

The accepts_nested_attributes_for declaration is required in the User model, but it simplifies attribute assignment in the controller.

app/models/user.rb

 class User < ApplicationRecord
   has_one :profile
   validates :email, presence: true
+  accepts_nested_attributes_for :profile
 end

app/controllers/user_registrations_controller.rb

 class UserRegistrationsController < ApplicationController
   def new
     @user = User.new.tap { _1.build_profile }
   end

   def create
     @user = User.new(user_params)
-    @profile = @user.build_profile(profile_params)

-    result =
-      ActiveRecord::Base.transaction do
-        saved = @user.save && @profile.save
-        raise ActiveRecord::Rollback unless saved
-        true
-      end
-
-    if result
+    if @user.save
       UserMailer.with(user: @user).registered.deliver_later
       redirect_to user_registration_complete_path, notice: "registered."
     else
       render :new, status: :unprocessable_entity
     end
   end

   private

   def user_params
-    params.require(:user).permit(:email)
+    params.require(:user).permit(:email, profile_attributes: %i[display_name age])
   end
-
-  def profile_params
-    params.require(:user).permit(profile_attributes: %i[display_name age])
-  end
 end

app/views/user_registrations/new.html.erb

-  <%= fields_for :profile do |profile_form| %>
+  <%= form.fields_for :profile do |profile_form| %>

At first glance, it looks more streamlined, but parameters like profile_attributes suddenly appear.
Additionally, fields_for, which is exposed in the view, cannot be avoided in any case.
Furthermore, in this approach, associations such as has_one or has_many must be explicitly defined between models. This means it cannot be used for updating models that do not have a direct association.

Controllers Should Handle a Single Model

As mentioned above, the situation where the controller and view are aware of the model structure can lead to complex processing. Here, we are illustrating with two models that have a simple relationship, but if we consider more nested relationships and the need to update them all at once in a single controller, it becomes clear why the controller can become complicated.

Form object

A common pattern is to extract this series of processes into a form object.

# app/models/user_registration.rb
class UserRegistration
  include ActiveModel::Model
  include ActiveModel::Validations::Callbacks
  include ActiveModel::Attributes

  attribute :email, :string
  attribute :display_name, :string
  attribute :age, :integer

  validates :email, presence: true
  validates :display_name, :age, presence: true

  def initialize(attributes = {})
    @user = User.new
    @profile = @user.build_profile
    super(attributes)
  end

  before_validation :assign_attributes_to_models

  def save
    return false if invalid?

    result =
      ActiveRecord::Base.transaction do
        user.save!
        profile.save!
        true
      end
    !!result
  end

  attr_reader :user, :profile

  private

  def assign_attributes_to_models
    user.email = email
    profile.display_name = display_name
    profile.age = age
  end
end

In addition, adjusting the controller and view based on the above form object would result in the following example.

# app/controllers/user_registrations_contrller.rb
class UserRegistrationsController < ApplicationController
  def new
    @user_registration = UserRegistration.new
  end

  def create
    @user_registration = UserRegistration.new(user_registration_params)

    if @user_registration.save
      UserMailer.with(user: @user_registration.user).registered.deliver_now
      redirect_to user_registration_complete_path, notice: "registered."
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def user_registration_params
    params.require(:user_registration).permit(:email, :display_name, :age)
  end
end

<!-- app/views/user_registrations/new.html.erb -->
<% content_for :title, "New user registration" %>

<h1>New user registration</h1>

<%= form_with(model: @user_registration, url: user_registration_path) do |form| %>
  <% if @user_registration.errors.any? %>
    <div style="color: red">
      <h2>
        <%= pluralize(@user_registration.errors.count, "error") %>
        prohibited this user_registration from being saved:
      </h2>

      <ul>
        <% @user_registration.errors.each do |error| %>
          <li><%= error.full_message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>

  <div>
    <%= form.label :email, style: "display: block" %>
    <%= form.text_field :email %>
  </div>
  <div>
    <%= form.label :display_name, style: "display: block" %>
    <%= form.text_field :display_name %>
  </div>
  <div>
    <%= form.label :age, style: "display: block" %>
    <%= form.number_field :age %>
  </div>

  <div><%= form.submit %></div>
<% end %>

This form object is just one example, but it typically contains User and Profile and updates them within a transaction using #save.

However, those who have tried creating such form objects know that there are quite a few considerations involved. For instance, it can be redundant to write the same validations in both the model and the form. If validations are defined only in the model, how should the errors be structured when validation errors occur? When aiming for a user experience similar to ActiveModel, it often becomes quite cumbersome.

Designing a Model that Contains Other Models

As mentioned above, when designing a model that contains (N) ActiveRecord models, it is desirable for that object to have a user experience similar to ActiveRecord. If this requirement is met, it can be expressed in a way that closely resembles the code generated by the scaffold for controllers and views.

Specifically, the desired behavior would be as follows:

The model should be able to save using #update(attributes) and return the result as true or false.
If the save fails, accessing #errors should provide information about the cause.
It should be possible to pass the model to the model option of form_with in the view.
To achieve the above, it should respond to methods like #to_param, #to_key, and #persisted?.

Additionally, considering that multiple models can be updated simultaneously, the following behaviors are also desired:

With database transaction control, multiple models can be updated atomically.
When designing a model that encapsulates two models, A and B, for example, if there are attributes attribute_a in model A and attribute_b in model B, it should be possible to transparently access each attribute using model.assign_attributes(attribute_a: 'foo', attribute_b: 'bar').

active_record_compose

The gem active_record_compose resolves the challenges mentioned above.
https://github.com/hamajyotan/active_record_compose

# Gemfile
gem 'active_record_compose'

# app/models/user_registration.rb
class UserRegistration < ActiveRecordCompose::Model
  def initialize(attributes = {})
    @user = User.new
    @profile = @user.build_profile
    models << user << profile
    super(attributes)
  end

  delegate_attribute :email, to: :user
  delegate_attribute :display_name, :age, to: :profile

  after_commit :send_registered_mail

  private

  attr_reader :user, :profile

  def send_registered_mail = UserMailer.with(user:).registered.deliver_now
end

The controllers and views that handle the models defined above would look as follows. The code does not require knowledge of the relationship between User and Profile, nor does it require understanding of the models themselves from the controllers and views.

# app/controllers/user_registrations_controller.rb
class UserRegistrationsController < ApplicationController
  def new
    @user_registration = UserRegistration.new
  end

  def create
    @user_registration = UserRegistration.new(user_registration_params)

    if @user_registration.save
      redirect_to user_registration_complete_path, notice: "registered."
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def user_registration_params
    params.require(:user_registration).permit(:email, :display_name, :age)
  end
end

<!-- app/views/user_registrations/new.html.erb -->
<% content_for :title, "New user registration" %>

<h1>New user registration</h1>

<%= form_with(model: @user_registration, url: user_registration_path) do |form| %>
  <% if @user_registration.errors.any? %>
    <div style="color: red">
      <h2>
        <%= pluralize(@user_registration.errors.count, "error") %>
        prohibited this user_registration from being saved:
      </h2>

      <ul>
        <% @user_registration.errors.each do |error| %>
          <li><%= error.full_message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>

  <div>
    <%= form.label :email, style: "display: block" %>
    <%= form.text_field :email %>
  </div>
  <div>
    <%= form.label :display_name, style: "display: block" %>
    <%= form.text_field :display_name %>
  </div>
  <div>
    <%= form.label :age, style: "display: block" %>
    <%= form.number_field :age %>
  </div>

  <div><%= form.submit %></div>
<% end %>

models collection

Let's take a look inside the definition of UserRegistration. The following code encapsulates the objects that will be saved simultaneously in the models. These objects are designed to be saved within a single database transaction when #save is executed.

    models << user << profile

You can also write it as follows:

    models.push(user)
    models.push(profile)

This may be a bit off-topic, but it can also handle cases where one model executes #save while another model executes #destroy.

    # User is saved and Profile is destroyed by executing UserRegistration#save.
    models.push(user)
    models.push(profile, destroy: true)

If you want to execute destroy only under certain conditions and save otherwise, you can pass the method name as a symbol to make the determination, as shown below.

    # User is saved and Profile is destroyed by executing UserRegistration#save.
    models.push(user)
    models.push(profile, destroy: :profile_field_is_blank?)
    # ...

  private

  def profile_field_is_blank? = display_name.blank? && age.blank?

delegate_attribute

delegate_attribute works similarly to Module#delegate defined in Active Support. In other words, it defines the methods UserRegistration#email and UserRegistration#email=, while delegating the implementation to user.

  delegate_attribute :email, to: :user
  delegate_attribute :display_name, :age, to: :profile

Not only does it simply delegate, but when a validation error occurs, the content of the error is reflected in the errors.

user_registration = UserRegistration.new(email: nil, display_name: nil, age: 18)
user_registration.valid?  #=> false
user_registration.errors.to_a
=> ["Email can't be blank", "Display name can't be blank"]

Furthermore, the content is also reflected in #attributes.

user_registration = UserRegistration.new(email: 'foo@example.com', display_name: 'foo', age: 18)
user_registration.attributes  #=> {"email" => "foo@example.com", "display_name" => "foo", "age" => 18}

database transaction callback

ActiveRecordCompose::Model is fundamentally an ActiveModel::Model.

user_registration = UserRegistration.new
user_registration.is_a?(ActiveModel::Model)  #=> true

However, it does more than that; it also supports transaction-related callbacks such as after_commit that are provided by ActiveRecord.

  after_commit :send_registered_mail

Additionally, the after_commit and after_rollback callbacks in ActiveRecord behave as expected even when nested; that is, after_commit is triggered only when the entire transaction succeeds and is committed. The same behavior is defined in ActiveRecordCompose::Model.

class User < ApplicationRecord
  after_commit -> { puts 'User#after_commit' }
  after_rollback -> { puts 'User#after_rollback' }
end

class Wrapped < ActiveRecordCompose::Model
  attribute :raise_error_flag, :boolean, default: false

  def initialize(attributes = {})
    super(attributes)
    models << User.new
  end

  after_save ->(model) { raise 'not saved!' if model.raise_error_flag }
  after_commit -> { puts 'Wrapped#after_commit' }
  after_rollback -> { puts 'Wrapped#after_rollback' }
end

model = Wrapped.new(raise_error_flag: true)
model.save! rescue nil
# User#after_rollback
# Wrapped#after_rollback

model = Wrapped.new(raise_error_flag: false)
model.save! rescue nil
# User#after_commit
# Wrapped#after_commit

Summary

In Rails, updating multiple models from a single controller action tends to be complex.
To address this, I created a gem called active_record_compose. This was a brief introduction to its usage.

Routing definition using only the actions generated by resources

Takashi SAKAGUCHI — Mon, 11 Mar 2024 18:33:38 +0000

REST

The scaffold feature in Rails is a fantastic capability. Beyond just generating code to manipulate CRUD operations on a database table, it imparts crucial lessons in building applications. While scaffold automatically generates seven actions (index, show, new, edit, create, update, destroy) to handle CRUD operations, many applications find additional actions unnecessary and even believe they shouldn't be created.

Within REST, there is a concept called Uniform Interface. It standardizes the operations provided for a URI that represents a resource through HTTP methods. The following one-line declaration in Rails' config/routes.rb makes it easy to implement this concept.

resources :users

The Feature You're Building Isn't That Special

Determine your resources, define routing with resources for everything, and provide everything in your application through the seven actions it offers. Is it possible to build an application under these constraints? In most cases, I believe it is. You might say, "But my application is a bit unique and challenging!" However, I often think that the difficulty arises from design issues related to identifying the "resources."

For instance, let's consider a scenario in a certain application, contemplating operations like user withdrawal for registered users.

# config/routes.rb
resources :users do
  post :resign
end

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def resign
    # resign process.
  end
end

It is possible to achieve this by defining an action named #resign in the UsersController.

However, as you can see, the routing involves a non resources declaration, specifically post :resign. Ideally, it is desirable for the structure to consist only of actions generated by the scaffold, avoiding such deviations.

To address this, it might be beneficial to identify a separate noun (resource) such as "Resignation" and consider CRUD operations for it. Additionally, organizing within a namespace, like users/, in the current controller can enhance clarity.

# config/routes.rb
resources :users do
  resource :resignation, only: %i[create], module: 'users'
end

class Users::ResignationsController < ApplicationController
  def create
    # resign process.
  end
end

Considering the assumption that the user is uniquely identified and anticipating the potential growth of sub-resources in the future, it would be beneficial to define Users::ApplicationController as follows. This allows for the centralization of the assignment to @user.

class Users::ApplicationController < ApplicationController
  before_action :set_user

  private

  def set_user
    @user = User.find(params[:user_id])
  end
end

class Users::ResignationsController < Users::ApplicationController
  def create
    # resign process for @user
  end
end

For example, if you later want to add actions for listing and displaying details of "login history for that user," it would be as follows.

# config/routes.rb
resources :users do
  resource :resignation, only: %i[create], module: 'users'
  resources :login_histories, only: %i[index show], module: 'users'

  # If you think it's redundant, use scope to summarize it.
  # scope module: 'users' do
  #   resource :resignation, only: %i[create]
  #   resources :login_histories, only: %i[index show]
  # end
end

class Users::LoginHistoriesController < Users::ApplicationController
  before_action :set_login_history, only: %i[show]

  def index
    @login_histories = @user.login_histories
  end

  def show
  end

  private

  def set_login_history
    @login_history = @user.login_histories.find(params[:id])
  end
end

These are, of course, simple cases that can be prepared in advance. However, even in the face of unknown challenges that may arise in the future, gaining insights by identifying "nouns" rather than "verbs" for the events that occur there often surprisingly leads to successful solutions.

Forem: Takashi SAKAGUCHI

released: active_record_compose 1.0.0 — Wrap multiple models with an ActiveModel interface

I just released version 1.0.0 of my gem active_record_compose. 🎉

Example:

Sample Application

Rails View Helper Scope and the include_all_helpers Option

About the Scope of Default View Helpers

Methods Defined in Helpers Can Be Called from Any View

The config.action_controller.include_all_helpers Option

How Is the Applicable Helper Determined?

Migrating an Existing Application to include_all_helpers = false

First Step

Narrowing Things Down Gradually

When Helper Methods from Gems Stop Working

Summary

Disclaimer

Avoiding Symbol Block-Pass (&:to_s) in Ruby and Choosing More Readable Alternatives

The Evolution of Block Parameters

The primitive style

Symbol#to_proc style

Numbered Parameters and it

Why Avoid Symbol Block-Pass?

A Custom RuboCop Cop

Conclusion

How to Get More Detailed Information When RSpec Tests Fail

The second argument of expect(...).to matcher, message

Useful for debugging flaky tests in CI

How it works

What about .not_to and raise_error?

Conclusion

Helpful Settings When Running RSpec with parallel_tests

parallel_tests

TIPS

Fix the seed across all processes

See which files each process is responsible for

See the execution order of files in each process

Conclusion

Tame Your Flaky RSpec Tests by Fixing the Seed

About This Article

Enable config.order and Kernel.srand

A Hands-On Example of Dealing with Flaky Tests

Setup from rails new

Create a Model and Write a Test

Run the Test

Observe Occasional Failures

Reproduce the Failure

Debug the Failure

Fix the Root Cause

Summary

Ephemeral Design Manifesto

Purpose

Principles

Practice Hints

Cultural Impact

Closing Thought

How to Run a Rails Application on GitHub Codespaces

Summary First

What is GitHub Codespaces?

Running a Rails Application on GitHub Codespaces

The --devcontainer Option

Opening the Project in GitHub Codespaces

Operations on Codespace

Issue with Port Forwarding Settings on Codespace

Workarounds Other Than Manual Toggling

Replacing the Docker Image

Remove forwardPorts

Solve the "Blocked hosts" Error

POST Requests Cannot Be Handled

Allowing POST Requests to Work in GitHub Codespaces

Summary & Promotion

Smart way to update multiple models simultaneously in Rails

complexity rails

Code Issues

Some errors Are Missing

Controllers and Views Are Too Aware of the Model Structure Details

Controllers Should Handle a Single Model

Form object

Designing a Model that Contains Other Models

active_record_compose

models collection

The `config.action_controller.include_all_helpers` Option

Migrating an Existing Application to `include_all_helpers = false`

Numbered Parameters and `it`

The second argument of `expect(...).to matcher, message`

What about `.not_to` and `raise_error`?

`parallel_tests`

Enable `config.order` and `Kernel.srand`

The `--devcontainer` Option

Remove `forwardPorts`

Some `errors` Are Missing