Andrei Maxim

Time to Grow

2026-02-08T00:00:00Z

In the early '90s, my grandmother, who was an accountant back then, would wake up at 4 AM to work on account reconciliation. It was a long process where she'd write down with a pencil on a big piece of paper all the recorded transactions and then compare them with the receipts and invoices., then she'd use a desk calculator to sum everything up and the numbers would match. She'd sometimes make a mistake which meant going over the whole sheet and then do partial calculations to narrow down the line item that caused the issue.

A couple of years later, we bought a family PC. Instead of spending a day or more on the reconciliation, she'd spend an hour or two inputting data into an Excel spreadsheet and the computer would automatically sum everything. I remember offering to input the data she'd dictate as I was typing much faster and we'd be done in half an hour. If there was an issue with a line item, we'd find it in minutes instead of hours. Of course, sometimes we'd run into the idiosyncrasies built into Excel and that would drive us nuts, but those were rare and happened less and less often once we had more experience with the program.

I distinctly remember how magical it felt the first time I saw the autosum feature from Excel and it's surprisingly close to what I feel today when I generate code via LLMs!

In the last couple of months, I've spent probably too many hours trying to figure out what will happen with me, as a programmer, and the IT industry as a whole, in the years to come, worrying that I'll lose my job and then won't be able to provide for my family and I think I understood two things:

We are going through a global recession and it's likely to hit as just as hard as the subprime mortgage crisis. There will be a market contraction, just like there is one during every crisis, and that shall cause many people to lose their jobs.
There are always more feature requests than time allows, which is the main reason why we have so many methodologies. LLMs represent yet another technological leap that will make us be more efficient, just like the email, Excel, AutoCAD, Google and many others.

Since there are trillion-dollar companies doing their best to replace humans with a subcription to an LLM-powered plan, there is a good chance I might be wrong. On the other hand, I don't remember my grandmother ever complaining that she had to learn Excel or that she'd rather go to the old way of doing balances and reconciliations.

Adding SimpleCov to Rails

2026-01-27T00:00:00Z

I've stopped using code coverage tools a number of years ago as the effort to maintain a test suite with 100% code coverage was quite significant, but nowadays the coverage report can be a useful tool when working with LLMs.

Unfortunately, the recommended SimpleCov setup for Ruby on Rails does not work because Rails now uses a parallel test runners and SimpleCov needs to be setup accordingly, otherwise you'd get much lower coverage numbers than you'd expect.

I've landed on this approach based on the template from Rails Templates, with a sightly different setup and ignoring the CI environment variable, because it can cause discrepancies.

First, let's look at how the default Rails test/test_helper.rb file looks like:

ENV["RAILS_ENV"] ||= "test"
require_relative "../config/environment"
require "rails/test_help"

module ActiveSupport
  class TestCase
    # Run tests in parallel with specified workers
    parallelize(workers: :number_of_processors)

    # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
    fixtures :all

    # Add more helper methods to be used by all tests here...
  end
end

First, let's create a test/coverage_test.rb file with the SimpleCov setup as per the gem's instructions.

Note that the file has an early return so the rest of the code is never executed unless the correct environment variable is present (Ruby is a scripting language as well!).

return unless ENV["COVERAGE"]

require "simplecov"

SimpleCov.start "rails" do
  # Add custom groups
  # e.g. add_group "Services", "app/services"

  # Exclude files from coverage
  add_filter "/test/"
  add_filter "/config/"
  add_filter "/vendor/"
  add_filter "/lib/generators/"

  # Enable branch coverage
  enable_coverage :branch
end

Now, we need to create a concern that we'll mix into the ActiveSupport::TestCase class to ensure that SimpleCov combines the coverage results across all parallel test runners, which I've created as test/test_helpers/coverage_test_helper.rb:

module CoverageTestHelper
  extend ActiveSupport::Concern

  included do
    parallelize_setup do |worker|
      SimpleCov.command_name "#{SimpleCov.command_name}-#{worker}"
    end

    parallelize_teardown do |worker|
      SimpleCov.result
    end
  end
end

Finally, let's require the test/coverage_helper.rb file as close to the top as possible, add a line that automatically requires the files in the test/test_helpers folder and then add the mixin if the COVERAGE environment variable is set:

ENV["RAILS_ENV"] ||= "test"

require_relative "coverage_helper"
require_relative "../config/environment"
require "rails/test_help"

# Automatically load all test helpers
Dir[Rails.root.join("test", "test_helpers", "**", "*.rb")].each { |file| require file }

module ActiveSupport
  class TestCase
    # Run tests in parallel with specified workers
    parallelize(workers: :number_of_processors)
    include CoverageTestHelper if ENV["COVERAGE"]

    # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
    fixtures :all

    # Add more helper methods to be used by all tests here...
  end
end

You now see you application's test coverage by running:

COVERAGE=true bin/rails test

Alternatives to Ruby classes

2026-01-02T00:00:00Z

I've noticed that many Ruby developers tend to suffer from "classitis," as coined by John Ousterhout in his "A Philosophy of Software Design," where there is an explosion of shallow modules (or, in our case, classes) instead of having fewer deep modules.

I understand the general criticism that ActionController instances aren't really objects, but sure this can't be the best alternative:

module Bookshelf
  module Actions
    module Home
      class Show < Bookshelf::Action
        def handle(request, response)
          name = request.params[:name]

          response.body = "Welcome to Bookshelf #{name}!"
        end
      end
    end
  end
end

It gets even worse when you consider the proliferation of the ServiceObject pattern in the Ruby and Rails codebases, which often looks like this:

class BookCreator
  def self.call(*args)
    new(*args).call
  end

  def initialize(title:, description:, author_id:, genre_id:)
    @title = title
    @description = description
    @author_id = author_id
    @genre_id = genre_id
  end

  def call
    create_book
  end

  private
    def create_book
      Book.create!(
        title: @title
        description: @description
        author_id: @author_id
        genre_id: @genre_id
      )
    rescue ActiveRecord::RecordNotUnique => e
      # handle duplicate entry
    end
end

This whole class (which is basically a Factory) could have been a method:

class Book
  class << self
    def create_unique(params)
      Book.create!(params)
    rescue ActiveRecord::RecordNotUnique => e
      # handle duplicate entry
    end
  end

  # rest of the code
end

So I was pleasantly surprised when I saw Dave Thomas's talk at SFRuby on the topic of using less classes.

Below are my notes about some the arguments he is making.

When to use `module` instead of `class`

In Ruby, there are two main differences between modules and classes:

Modules are not instantiable (there isn't a Module.new method)
Modules can be mixed into other modules or classes

Or, if we frame it in a different way, you should use a module instead of a class when you need a namespace for related functions or when you need to share code between different object types.

Let's consider this class:

class Utils
  def self.date_to_string(date)
    # code
  end
end

Since it doesn't make sense to instantiate the above class at all, let's replace it with a module:

module Utils
  extend self

  def date_to_string(date)
    # code
  end
end

The extend self part makes it obvious that the Module is used as a namespace, which is a distinct advantage over classes.

A second use for Module is its ability to mix in behavior, thus allowing you to share code between objects.

Here's a common pattern I've seen in several places:

class StrategyBase
  def run
    run_setup
    perform
    run_callbacks
  end

  private
    def run_setup
      raise "Not implemented"
    end
end

class UserStrategy < StrategyBase
  private
    def run_setup
      # some user-specific setup code
    end
end

class AdminStrategy < StrategyBase
  private
    def run_setup
      # some admin-specific setup code
    end
end

The StrategyBase class actually represents a behavior which we want to mix into our UserStrategy and AdminStrategy objects, so why not be explicit about that and convert it to a Module?

module Runnable
  def run
    run_setup
    perform
    run_callbacks
  end
end

class UserStrategy
  include Runnable

  private
    def run_setup
      # some user-specific setup code
    end
end

class AdminStrategy
  include Runnable

  private
    def run_setup
      # some admin-specific setup code
    end
end

The main advantage is that adding behaviors to classes via mixins scales much better than using inheritance:

class AdminStrategy
  include Runnable, Retriable, Loggable
end

class UserStrategy
 include Runnable, Retriable, Loggable
end

class GuestStrategy
  include Runnable, Expirable
end

These different approaches can be seen in ActiveJob and Sidekiq:

class SomeJob < ActiveJob::Base
  def perform(*args)
  end
end

# vs

class SomeJob
  include Sidekiq::Job

  def perform(*args)
  end
end

The inheritance hierarchy is not a big issue in the case of ActiveJob mainly because the convention is that all files in app/jobs are expected to always be a type of job, but this might not be as clear in other parts of the codebase (e.g. app/models).

When to use a `Data` instead of `class`

Another common anti-pattern when it comes to using classes in Ruby is when the class is actually a data bag. In that case, there are two better constructs, but I'd like to single out the Data class.

So instead of:

class Person
  attr_reader :first_name, :last_name, :age

  def initialize(first_name:, last_name:, age:)
    @first_name = first_name
    @last_name = last_name
    @age = age
  end
end

it would be better (and simpler!) to use:

Person = Data.define(:first_name, :last_name, :age)

In both cases, the usage is identical:

john = Person.new first_name: "John", last_name: "Doe", age: 42

john.first_name #=> "John

The Data class can also include helper methods, but keep in mind that the object is frozen so you can't manipulate instance variables after it was created:

Person = Data.define(:first_name, :last_name, :age) do
  def full_name
    "#{first_name} #{last_name}"
  end
end

Naming classes after design patterns

Dave Thomas says that if your class is named after a design pattern, then it's a smell. While I agree that in Ruby we don't need to have a dedicated UserFactory class and just use a class method (e.g. User#build_admin), I think his advice is less applicable down when we go beyond the design patterns presented in the GoF book.

For example, I don't think it's a smell that you have a RemindersJob, or a UsersController class even though both contain the name of the pattern ("job" and "controller").

Abstract classes

I wrote my fair share of abstract classes and the logic behind it was that they provided core functionality for the classes that inherited from it (e.g. populating the model with data pulled from a specific URL).

However, looking back, I think I always got to a place where I'd had methods that would just raise some sort of NotImplementedError, or I would have to override the initialize method and I'm fairly sure that using a mix-in would have been much cleaner.

Final thoughts

I think PragDave was a bit too dramatic when he titled his talk "Stop using classes," but otherwise I highly agree with the points that he's making.

Whenever you reach for a class, you are also inviting a lot of complexity, which could be avoided by using other tools, like Module (which is stateless) or Data (which is immutable), that could be easier to reason about since they are generally simpler. Also, refactoring from a Module or Data to a Class is generally extremely trivial.

That being said, I also think there's a lot of essential complexity that you need to manage and, often, objects and classes can be extremely helpful.

Benchmarking with Ruby on Rails

2025-10-15T00:00:00Z

One of the things I really enjoy about Ruby on Rails is that it has a lot of tiny conveniences that can speed up your workflow a lot.

For example, I recently needed to quickly convert Markdown to HTML, but I wasn't sure which gem to use: a quick search revealed the venerable Redcarpet, which is mostly written in C, but also Commonmarker, which wraps a Rust library and provides some additional features.

But which one to choose?

Luckily, Rails makes it really simple to create a benchmark via a generator:

bin/rails g benchmark markdown_parsing

It should generate a markdown_parsing.rb file in the script/benchmarks folder with the following contents:

# frozen_string_literal: true

require_relative "../../config/environment"

# Any benchmarking setup goes here...

Benchmark.ips do |x|
  x.report("before") { }
  x.report("after") { }

  x.compare!
end

Then add the Redcarpet, Commonmarker and Kramdown (as a baseline) gems to your Gemfile (plus benchmark-ips if it's not already in the development group), use something like Lorem Markdown to generate a sample Markdown file, and then add the benchmark code, which would look something like this:

# frozen_string_literal: true

require_relative "../../config/environment"

md = File.read(Rails.root.join("script", "benchmarks", "sample.md"))

Benchmark.ips do |x|
  x.report("Commonmarker.to_html") { Commonmarker.to_html(md) }
  x.report("Kramdown.to_html")     { Kramdown::Document.new(md).to_html }
  x.report("Redcarpet.render")     { Redcarpet::Markdown.new(Redcarpet::Render::HTML).render(md) }
  x.compare!
end

Finally, run the benchmark using the Rails runner:

bin/rails runner script/benchmarks/markdown_parsing.rb

On my development machine, this was the output:

ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [x86_64-linux]
Warming up --------------------------------------
Commonmarker.to_html 65.000 i/100ms
Kramdown.to_html 155.000 i/100ms
Redcarpet.render 7.151k i/100ms
Calculating -------------------------------------
Commonmarker.to_html 648.281 (± 4.0%) i/s (1.54 ms/i) - 3.250k in 5.021352s
Kramdown.to_html 1.525k (± 3.5%) i/s (655.91 μs/i) - 7.750k in 5.089232s
Redcarpet.render 102.672k (±17.1%) i/s (9.74 μs/i) - 486.268k in 5.011136s

Comparison:
Redcarpet.render: 102672.4 i/s
Kramdown.to_html: 1524.6 i/s - 67.34x slower
Commonmarker.to_html: 648.3 i/s - 158.38x slower

The results are a bit surprising, especially since Kramdown is written in pure Ruby and seems to be much faster than Commonmarker, which is basically just a thin Ruby wrapper over Rust code. So I'm suspecting that Commonmarker is actually doing a lot more.

Let's run the code from the benchmark in the REPL and see what's the output for each renderer.

For example, the <h1> heading from the original Markdown file looks like this:

# Monitis velle

Here's a heading generated by Commonmarker is quite complex:

<h1>
  <a href="#monitis-velle" aria-hidden="true" class="anchor" id="monitis-velle">
  </a>
  Monitis velle
  <h1></h1>
</h1>

Kramdown only adds an ID to the heading:

<h1 id="monitis-velle">Monitis velle</h1>

The output from Redcarpet is very basic, just the HTML and nothing more:

<h1>Monitis velle</h1>

Since the output is different, this means that the comparison wasn't exactly fair, so let's improve the benchmark by making sure all renderers behave the same (as much as possible) by disabling any extra features since we're only interested in converting from Markdown to plain HTML:

# frozen_string_literal: true

require_relative "../../config/environment"

md = File.read(Rails.root.join("script", "benchmarks", "sample.md"))

PLAIN_CM_OPTS = {
  extension: {
    strikethrough: false, table: false, autolink: false, tasklist: false,
    footnotes: false, description_lists: false, shortcodes: false,
    header_ids: nil
  },
  render: {
    github_pre_lang: false, escaped_char_spans: false, sourcepos: false,
    full_info_string: false, unsafe: false
  },
  parse: { smart: false }
}

Benchmark.ips do |x|
  x.report("Commonmarker.to_html") do
    Commonmarker.to_html(
      md,
      options: PLAIN_CM_OPTS,
      plugins: { syntax_highlighter: nil }
    )
  end

  x.report("Kramdown.to_html") do
    Kramdown::Document.new(md, auto_ids: false, syntax_highlighter: nil, math_engine: nil)
      .to_html
  end

  x.report("Redcarpet.render") do
    Redcarpet::Markdown.new(Redcarpet::Render::HTML).render(md)
  end

  x.compare!
end

Now let's run the benchmark again:

bin/rails runner script/benchmarks/markdown_parsing.rb

... and here's the output:

ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [x86_64-linux]
Warming up --------------------------------------
Commonmarker.to_html 2.677k i/100ms
Kramdown.to_html 139.000 i/100ms
Redcarpet.render 7.175k i/100ms
Calculating -------------------------------------
Commonmarker.to_html 27.100k (± 2.3%) i/s (36.90 μs/i) - 136.527k in 5.040564s
Kramdown.to_html 1.561k (± 3.0%) i/s (640.50 μs/i) - 7.923k in 5.079224s
Redcarpet.render 102.521k (±19.2%) i/s (9.75 μs/i) - 487.900k in 5.102568s

Comparison:
Redcarpet.render: 102520.6 i/s
Commonmarker.to_html: 27100.1 i/s - 3.78x slower
Kramdown.to_html: 1561.3 i/s - 65.66x slower

Redcarpet is still much faster than Commonmarker, but the difference is two orders of magnitude smaller, while Kramdown is unsurprisingly the slowest.

While this is a tiny example, the main advantage of the benchmark scripts is that they load your entire application, meaning that you can easily A/B test different chunks of code from your application to check for performance regressions or improvements!

Postgres for Rails Development

2024-07-02T00:00:00Z

I've found that the best way to set up Posgres for local development is via Docker, since it has some clear benefits over using system packages on Windows (via WSL2) or Linux.

There are three steps to configure Postgres for your Rails application:

Install the Postgres server
Install Postgres libraries for development
Configure your application to connect to the Postgres container

Installing the Postgres container

After some testing, I've settled on the following command:

sudo docker run -d --restart unless-stopped \
  --name=postgres18 \
  -e POSTGRES_HOST_AUTH_METHOD=trust \
  -e POSTGRES_USER=$(whoami)\
  -p "127.0.0.1:5432:5432" \
  --shm-size=1g \
  postgres:18 -c max_locks_per_transaction=1024

Here's a short explanation of each flag:

sudo docker run -d runs the Docker container in the background (-d means daemon)
--restart unless-stopped will automatically start the Postgres service when the Docker daemon starts, unless manually stopped (which is very useful if you have a Postgre 17 instance, but you want to switch to Postgres 16 without changing the application configuration)
-e POSTGRES_HOST_AUTH_METHOD=trust basically password authentication, which is fine for local development as long as the container is only exposed to the localhost (see below)
-e POSTGRES_USER=$(whoami) sets the default user to your local OS system account (in my case it's andrei)
-p "127.0.0.1:5432:5432" binds the internal port 5432 on the Docker container, which is used by Postgres, to the same port on localhost. Since the service binds to 127.0.0.1 this means that the port will not be accessible from the outside world (e.g. if you are using a shared wifi in a cafe)
--shm-size=1g increases the default Docker container shared memory from 64MB to 1GB, otherwise Postgres might raise a "could not resize shared memory" error
-c "max_locks_per_transaction=128" increases the number of locks per transaction, which can be reached by Rails when running tests (see this Gitlab issue). This needs to be last since it's passed as a command to postgres

Install Postgres libraries for development

In order to connect to Postgres, we also need the development libraries so we can install the pg gem. This is different on every system and Linux distribution, but on Ubuntu there is an official Apt repository which offers access to the latest Postgres releases:

sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

Then install the latest client application (createdb, dropdb, pg_dump, psql, etc) and development libraries:

sudo apt install postgresql-client-17 libpq-dev

You should be able to log into the database server now:

$ psql -h 127.0.0.1
psql (18.1 (Ubuntu 18.1-1.pgdg24.04+2))
Type "help" for help.

andrei=#

Configure your application

We can simplify the config/database.yml file quite a lot when using Postgres. here's an example for a blog application:

default: &default
adapter: postgresql
encoding: unicode
# For details on connection pooling, see Rails configuration guide
# https://guides.rubyonrails.org/configuring.html#database-pooling
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 3 } %>

development:
  <<: *default
  database: blog_development

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
   <<: *default
  database: blog_test

# ActiveRecord will automatically use the `DATABASE_URL` environment
# variable for the primary database and `<NAME>_DATABASE_URL` for any
# secondary database (e.g. `REPLICA_DATABASE_URL`).
#
# If both database.yml and the environment variable contain the same values
# (e.g. host or database name), the environment variable wins.
production:
  <<: *default
  database: blog_production

Note that the host, username or password are all missing, which means that ActiveRecord will connect by default to a socket on localhost and authenticate using the current system user.

In order to override that, we need to provide the following environment variables in your local .env file or as part of .bashrc:

export PGHOST=127.0.0.1

In case you might be using a database schema different than public for your Rails application, you can set that up using an environment variable as well:

export PGOPTIONS='-c search_path=myapp,public'

Now you should have Postgres ready for your Ruby on Rails application!

RESTful Webhooks in Rails

2024-05-02T00:00:00Z

I've recently seen a code sample about working with Stripe webhooks in Rails applications and I've noticed the following code in the controller:

class StripeController < ApplicationController
  skip_before_action :verify_authenticity_token, only: [ :webhook ]

  def webhook
    # Sample code for handling Stripe webhook events
  end
end

First of all, I want to point out that creating good code examples is very hard and you always need to find a balance between good abstractions and code that is easy to understand by the reader. In this specific case, I'd argue coding best practices are secondary to clearing showing that the code we're interested is in this specific controller action.

However, I've seen cases where developers working with webhooks create controllers like in the above example, which often become the first broken windows in an otherwise RESTful Rails application.

Fortunately, it's quite easy to avoid it.

The main issue here is the language used. On the Stripe (or any other third-party service) configuration page, we enter the URL of our webhook, so naturally that specific endpoint becomes "the webhook endpoint". But the webhook is the resource we created on the third-party application, not the resource received by our endpoint, which is the event (or, in our case, the payment event) that triggers the webhook.

Now that we have identified the resource we're working with, it's much easier to name the controller and use the REST pattern:

class Payments::EventsController < ApplicationController
  skip_before_action :verify_authenticity_token, only: [ :create ]

  def create
    # Sample code for handling Stripe webhook events
  end
end

In practice, I've often found that spending a bit of time identifying the resources (which don't have to map to models!) in order to use almost exclusively RESTful endpoints greatly simplifies the controller, which is something that DHH has spoken about in the past and Derek Prior had presented at RailsConf 2017.

Instance Variable Access in Ruby

2024-04-17T00:00:00Z

Instance variables (or instance attributes) in Ruby are prefixed with an @ sign:

class Person
  def initialize(salutation: nil, first_name:, last_name:)
    @salutation = salutation
    @first_name = first_name
    @last_name  = last_name
  end

  def name
    [ @salutation, @first_name, @last_name ].compact.join(" ")
  end
end

john = Person.new first_name: "John", last_name: "Doe"
john.name # => "John Doe"

sam = Person.new salutation: "Mr.", first_name: "Sam", last_name: "Johnson"
sam.name # => "Mr. Sam Johnson"

In the above example variables are accessed using the direct variable access pattern, as described by Kent Beck in Smalltalk Best Practice Patterns and it has been my preferred style, mainly because they easily stand out when you read the code and allows you to differentiate between object methods and attributes.

The other approach is to use the indirect variable access pattern, which can be done by defining accessors:

class Person
  attr_reader :salutation, :first_name, :last_name

  def initialize(salutation: nil, first_name:, last_name:)
    @salutation = salutation
    @first_name = first_name
    @last_name  = last_name
  end

  def name
    [ salutation, first_name, last_name ].compact.join(" ")
  end
end

john = Person.new first_name: "John", last_name: "Doe"
john.name # => "John Doe"

sam = Person.new salutation: "Mr.", first_name: "Sam", last_name: "Johnson"
sam.name # => "Mr. Sam Johnson"

The side effect of defining accessors is that they are now accessible by other objects, which might not be something you want:

john.name #=> "John"
sam.salutation #=> "Mr."

The solution is to define the accessors in a private section:

 class Person
  def initialize(salutation: nil, first_name:, last_name:)
    @salutation = salutation
    @first_name = first_name
    @last_name  = last_name
  end

  def name
    [ salutation, first_name, last_name ].compact.join(" ")
  end

  private

  attr_reader :salutation, :first_name, :last_name
end

john = Person.new first_name: "John", last_name: "Doe"
john.name # => "John Doe"
john.first_name # => NoMethodError: private method `first_name' called for
                #    an instance of Person

While it may seem that the main difference between indirect variable access and direct variable access patterns is mainly stylistic, it does have an impact when using inheritance because you can override methods, but you can't override instance variables.

For example, the salutation of the members of a royal house need to start with "HRH" from "His Royal Highness" or "Her Royal Highness" and has to include the title (the naming conventions for royalty and nobility are actually quite complex). If we used direct variable access, we would need to reimplement the name method:

class Person
  def initialize(salutation: nil, first_name:, last_name: nil)
    @salutation = salutation
    @first_name = first_name
    @last_name  = last_name
  end

  def name
    [ @salutation, @first_name, @last_name ].compact.join(" ")
  end
end

class Royalty < Person
  def initialize(title:, first_name:, last_name: nil)
    @title = title
    @first_name = first_name
    @last_name = last_name
  end

  def salutation
    "HRH #{@title}"
  end

  def name
    [ salutation, @first_name, @last_name ].compact.join(" ")
  end
end

charles = Royalty.new title: "King", first_name: "Charles"
charles.name # => "HRH King Charles"

This also means that if we plan to support name suffixes later on we'll need to change the name method in both the Person and Royalty classes.

On the other hand, if we use indirect variable access, we can override the salutation attribute to always start with "HRH", while adding a suffix will require a change to the name method only on the parent Person class:

class Person
  def initialize(salutation: nil, first_name:, last_name: nil, suffix: nil)
    @salutation = salutation
    @first_name = first_name
    @last_name  = last_name
    @suffix     = suffix
  end

  def name
    [ salutation, first_name, last_name, suffix ].compact.join(" ")
  end

  private

  attr_reader :salutation, :first_name, :last_name, :suffix
end

class Royalty < Person
  def initialize(title:, first_name:, last_name: nil, suffix: nil)
    @title = title
    @first_name = first_name
    @last_name = last_name
    @suffix = suffix
  end

  def salutation
    "HRH #{title}"
  end

  private

  attr_reader :title
end

charles = Royalty.new title: "King", first_name: "Charles", suffix: "III"
charles.name # => "HRH King Charles III"

However, as you can see in this rather contrived example, it is not often that we need to override an attribute in the parent class with a method in the child class, so, at the end of the day, it's mostly a stylistic decision.

Also, as with every stylistic decision, it's much more important to be consistent, at least at the class level.