Rails edge — and the upcoming 8.2 — fixes this.

Instead of…

…mixing ENV and credential lookups:

class StripeChargeService
  def initialize
    @api_key = ENV.fetch("STRIPE_API_KEY")
    @webhook_secret = Rails.application.credentials.dig(:stripe, :webhook_secret)
    @price_id = ENV.fetch("STRIPE_PRICE_ID") { Rails.application.credentials.dig(:stripe, :price_id) }
  end
end

Use…

…the combined credentials API:

class StripeChargeService
  def initialize
    @api_key = Rails.app.creds.require(:stripe, :api_key)
    @webhook_secret = Rails.app.creds.require(:stripe, :webhook_secret)
    @price_id = Rails.app.creds.require(:stripe, :price_id)
  end
end

require raises a KeyError if the key is missing from all backends. For optional values, use option:

Rails.app.creds.option(:appsignal, :push_api_key, default: nil)
# Returns nil if missing — AppSignal just won't report

To keep production secrets separate, run bin/rails credentials:edit --environment production. This creates a separate encrypted file with its own key:

config/credentials.yml.enc         ← shared (dev/test)
config/master.key                  ← decrypts the shared file

config/credentials/production.yml.enc  ← production only
config/credentials/production.key      ← decrypts production

If production.yml.enc exists, Rails uses it exclusively in production — there’s no inheritance from the shared file, so duplicate any keys you need. To decrypt in production, set RAILS_MASTER_KEY in your hosting provider to the contents of production.key.

Why?

Rails.app.creds checks ENV first, then falls back to encrypted credentials. You don’t need to know or care where a value is stored.

Nested keys like :stripe, :api_key map to double-underscored ENV names (STRIPE__API_KEY). A single key like :postmark_api_token checks ENV["POSTMARK_API_TOKEN"].

This means you can move secrets between ENV and encrypted credentials without changing application code. Deploying to a provider that injects secrets via ENV? It just works. Want to move a key into the encrypted file instead? Remove the ENV variable and add it to your credentials. Your code stays the same.

I’ve previously recommended wrapping ENV in a custom Settings object. This built-in approach is better — the same clean interface with the added fallback to encrypted credentials.

Why not?

This isn’t in a released version of Rails yet — you need Rails edge (main), and it’s expected in Rails 8.2. If you’re on 8.1 or older, a custom Settings wrapper still works well.

Other Considerations

You can also create development.yml.enc and test.yml.enc, but I think the shared file plus a production override is clearer — and you shouldn’t be calling real APIs in your test environment anyhow.

Keep separate encryption keys for each environment. You could share one, but a leaked development key shouldn’t expose production secrets.

Mea Culpa

I originally published this post saying Rails.app.creds had shipped in Rails 8.1. It hasn’t — it’s on Rails main and is expected in 8.2. I’ve been running Rails edge on a couple of projects and assumed this had already been released. Apologies for the confusion, and thanks to everyone who pointed it out.

Instead of…

…accepting Rails’s best guess at a plural:

"criterion".pluralize  #=> "criterions"
"matrix".pluralize     #=> "matrices"  # this one Rails knows!

Use…

…inflect.irregular to teach Rails the correct pair:

# config/initializers/inflections.rb
ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.irregular "criterion", "criteria"
end

Now:

"criterion".pluralize  #=> "criteria"
"criteria".singularize #=> "criterion"

Why?

Give irregular the singular and plural forms and Rails handles both directions—pluralize and singularize both work correctly.

A Criterion model will look for a criteria table. resources :criteria will route to CriteriaController. Association names, fixtures, and factory names all follow suit.

class Criterion < ApplicationRecord
  # table: criteria
end

class Survey < ApplicationRecord
  has_many :criteria  # works as expected
end

You can declare as many as you need:

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.irregular "criterion", "criteria"
  inflect.irregular "goose", "geese"
end

Although, unless you’re building some kind of flighted animal tracker, you probably won’t need that second one.

Rails already knows a handful of irregular plurals: person/people, man/men, child/children, sex/sexes, move/moves, and—crucially—zombie/zombies are built in. Rails’s pluralisation rules are regex-based, so the (m)an → (m)en pattern also covers woman/women. But that’s it—words like tooth/teeth, foot/feet, mouse/mice, and goose/geese are not handled by default. Check the default inflections to see what’s already covered.

See the ActiveSupport::Inflector::Inflections documentation for details.

Why not?

Before adding an irregular inflection, check whether Rails already knows the word. Try it in a console:

"person".pluralize  #=> "people"  — already works
"axis".pluralize    #=> "axes"    — already works

If it’s already correct, adding it to your initialiser is just noise.

If the word never appears as a model or resource name, there’s no reason to declare it.

For words that don’t change between singular and plural (like “sheep” or “metadata”), you need inflect.uncountable. For casing issues with acronyms like API or CSV, look at inflect.acronym.

Instead of…

…fighting Rails when it pluralises words that shouldn’t change:

"staff".pluralize    #=> "staffs"
"metadata".pluralize #=> "metadatas"
"feedback".pluralize #=> "feedbacks"

Use…

…inflect.uncountable to tell Rails these words stay the same:

# config/initializers/inflections.rb
ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.uncountable %w[staff metadata feedback]
end

Now:

"staff".pluralize    #=> "staff"
"metadata".pluralize #=> "metadata"
"staff".singularize  #=> "staff"

Why?

Table names, route helpers, association names, and autoloading all depend on correct inflection. When Rails gets it wrong, you end up with a staffs table or metadatas_path route helpers.

Declaring a word as uncountable fixes this everywhere at once. The Staff model maps to the staff table. resources :staff generates the routes you’d expect.

Words worth declaring uncountable: staff, metadata, feedback, analytics, aircraft, software. You only need to add ones you’re actually using as model or resource names. You can pass a single string or an array.

Rails already handles some common uncountable words—equipment, information, rice, money, species, series, fish, sheep, jeans, and police work out of the box. Check the default inflections to see the full list before adding your own.

See the ActiveSupport::Inflector::Inflections documentation for details.

Why not?

Uncountable words make associations slightly less intuitive. has_many :staff reads naturally, but Staff.all returning multiple records from a staff table can briefly confuse developers expecting a staffs table.

If the word is domain-specific jargon your team invented, a regular plural might actually be clearer. Reserve uncountable for genuinely uncountable English words, not as a shortcut to avoid a table name you don’t like.

This only affects pluralisation. For casing issues with acronyms like API or CSV, that’s inflect.acronym. For words with non-standard plurals like criterion/criteria, that’s inflect.irregular.

Every Rails app generates config/initializers/inflections.rb to let you customise this behaviour. Most developers leave it empty. Then one day you namespace a controller under API and Rails starts generating Api::UsersController instead of API::UsersController.

Instead of…

…accepting the wrong casing in your class names:

# app/controllers/api/users_controller.rb
class Api::UsersController < ApplicationController
end

Use…

…inflect.acronym to teach Rails the correct casing:

# config/initializers/inflections.rb
ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "API"
end

Now Rails expects API::UsersController. The file path stays lowercase (app/controllers/api/), but the class name uses the acronym:

# app/controllers/api/users_controller.rb
class API::UsersController < ApplicationController
end

Why?

The acronym method tells ActiveSupport’s inflector to preserve the casing you specify. It affects camelize, underscore, classify, and titleize—which means it also affects autoloading and URL helpers.

"api".camelize        #=> "API"
"API".underscore      #=> "api"
"api/users".camelize  #=> "API::Users"

Without the acronym declaration, you get Api instead:

"api".camelize  #=> "Api"

Unlike irregular plurals and uncountable words, Rails ships with no built-in acronyms—every one you need, you have to declare yourself. Common ones worth adding: API, SMS, CSV, HTML, PDF. You need one call per term:

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "API"
  inflect.acronym "SMS"
  inflect.acronym "CSV"
end

This also works for mixed-case words like GraphQL or GitHub. inflect.acronym "GraphQL" ensures "graphql".camelize returns "GraphQL" rather than "Graphql".

See the ActiveSupport::Inflector::Inflections documentation for details.

Note that because these changes are in an initializer, you’ll need to restart your Rails server after making changes.

Why not?

Keep the list short. Every entry changes how camelize, titleize, humanize, and underscore behave for the specified words across your entire app. Only add acronyms you’re actively using—whether in class names, attribute labels, or view helpers.

This only affects casing, not pluralisation. For words with non-standard plurals like criterion/criteria, you’ll want inflect.irregular. For words that don’t pluralise at all, the method to look at is inflect.uncountable.

Instead of…

…repeating conditions across multiple validations:

class Article < ApplicationRecord
  validates :title, presence: true, if: :published?
  validates :body, length: { minimum: 100 }, if: :published?
  validates :author, presence: true, if: :published?
end

Use…

…the with_options method to group common configurations:

class Article < ApplicationRecord
  with_options if: :published? do
    validates :title, presence: true
    validates :body, length: { minimum: 100 }
    validates :author, presence: true
  end
end

Works well in controllers too:

class AdminController < ApplicationController
  with_options only: [:edit, :update] do
    before_action :require_admin
    before_action :set_audit_trail
  end
end

And associations:

class User < ApplicationRecord
  with_options dependent: :destroy do
    has_many :posts
    has_many :comments
    has_many :likes
  end
end

Why?

with_options merges the given options into every method call inside the block. In the validation example, if: :published? gets added to each validates call automatically.

This syntax groups related configuration visually—it’s immediately clear these rules only apply to published articles. If you have to change the condition; it is only once, not three times.

This also works in routes.rb too:

with_options controller: "admin/reports" do
  get "daily", action: :daily
  get "weekly", action: :weekly
  get "monthly", action: :monthly
end

See the with_options documentation for details.

Why not?

With only two items, the block adds more lines than it saves. Three or more is where with_options starts to pay off.

Nesting multiple with_options blocks gets hard to follow. If you find yourself nesting, reconsider.

Instead of…

…exposing IDs in your URLs:

redirect_to article_path(@article)
# => "/articles/42"

Use…

…the to_param method to return a slug instead:

class Article < ApplicationRecord
  before_save { self.slug = title.parameterize }

  def to_param = slug
end

redirect_to article_path(@article)
# => "/articles/understanding-rails-extensions"

Then find records by slug in your controller:

def set_article
  @article = Article.find_by!(slug: params[:id])
end

For reliable lookups with readable URLs, prefix the slug with the ID:

def to_param
  "#{id}-#{title.parameterize}"
end

# => "/articles/42-understanding-rails-extensions"

The ID lookup just works—"42-understanding-rails-extensions".to_i returns 42, so Article.find(params[:id]) needs no parsing.

Why?

Rails URL helpers call to_param automatically when generating URLs. Override it to create cleaner, more descriptive paths without changing controller code.

Descriptive URLs are easier to read in logs, analytics, and when shared. They give users context about content before clicking. For content-heavy sites, slug-based URLs can help with SEO.

Hiding IDs also keeps URLs stable if you ever migrate databases or change ID schemes.

Why not?

Pure slug URLs require uniqueness on the relevant column, an index in the database, and method changes everywhere you find the model. If slugs can change, you’ll need redirects for old URLs.

For production apps, consider friendly_id—it handles slug generation, duplicates, history tracking, and scoped slugs. Or try prefixed_ids for Stripe-style encoded IDs like user_5vJjbzXq9KrLEMm32iAnOP0xGDYk6dpe that hide sequential IDs without needing slugs.

The ID-prefixed approach avoids uniqueness issues but still exposes the ID. Hiding IDs entirely means extra complexity in exchange for security through obscurity—a trade-off worth considering carefully.

Active Support also adds an inquiry method to String so you can use this same pattern in your own code.

Instead of…

…comparing strings with ==:

class Writing < ApplicationRecord
  # category is a string: "story", "nursery_rhyme", "song", "article", "social_post"

  def online?
    category == "article" || category == "social_post"
  end
end

Use…

…the inquiry method to ask questions of your string attributes:

class Writing < ApplicationRecord
  def category = super.to_s.inquiry

  def online? = category.article? || category.social_post?
end

The overridden category getter calls super to get the original value, then wraps it in a StringInquirer via .to_s.inquiry. Now calling .article? checks whether the string equals "article".

Why?

The code reads like English. “Is the category an article?” becomes category.article? rather than category == "article".

This is the same pattern Rails uses internally. When you write Rails.env.production?, you’re calling a predicate method on a StringInquirer. Applying the pattern to your own code feels natural.

It works well with dynamic data such as API responses or CSV imports where defining an enum upfront isn’t practical.

status = api_response["status"].to_s.inquiry
status.pending?   #=> true if status == "pending"
status.complete?  #=> true if status == "complete"

Why not?

If your values are a known, fixed set, prefer Rails enums:

class Writing < ApplicationRecord
  enum :category, %w[story nursery_rhyme song article social_post].index_by(&:itself)
end

writing.article?       # same predicate methods
Writing.social_post    # scopes for free
writing.song!          # and bang assignment methods

Enums give you database-backed validation and automatic scopes. Use StringInquirer when the values are too dynamic for an enum, or when you’re working with external data you don’t control.

Extra nuances

You might sometimes want a bare attribute call to return nil. With a StringInquirer it will always be "". Either adjust checks to look for .blank? rather than .nil? or modify the implementation using the lonely operator:

def category = super.presence&.inquiry

However, this requires safe navigation (&.) when calling predicates, category&.news?, so you’re exchanging more database-accurate nilness for ugly calls.

Instead of…

…reading your conditions backwards with include?:

nsync = ["Justin", "JC", "Chris", "Joey", "Lance"]

if nsync.include?(candidate)
  puts "#{candidate} is in the band"
end

# Or inline
if ["Justin", "JC", "Chris", "Joey", "Lance"].include?(member)
  puts "#{member} can join the inevitable reunion tour"
end

Use…

…Rails’s in? method for more natural reading:

nsync = ["Justin", "JC", "Chris", "Joey", "Lance"]

if candidate.in?(nsync)
  puts "#{candidate} is in the band"
end

# Reads naturally even inline
if member.in?(["Justin", "JC", "Chris", "Joey", "Lance"])
  puts "#{member} can join the inevitable reunion tour"
end

Why?

The in? method reads like English. “Is Justin in NSYNC?” becomes "Justin".in?(nsync). Compare that to nsync.include?("Justin"), which reads as “Does NSYNC include Justin?”—grammatically correct but less intuitive.

The in? method works with anything that responds to include?: arrays, ranges, sets, and strings.

"JC".in?("JC Chasez")                            #=> true
5.in?(1..10)                                     #=> true
:harmony.in?(Set[:melody, :harmony, :rhythm])   #=> true

It also handles nil gracefully, returning false rather than raising an error:

"Justin".in?(nil)  #=> false

Why not?

If you’re not using Rails, you’d need to add activesupport as a dependency. For a single method, that’s probably overkill.

Some teams prefer sticking with Ruby’s standard library to avoid “magic” methods that might confuse developers unfamiliar with Rails conventions. If your collection is already in a well-named variable, nsync.include?(name) reads fine.

Performance is identical—in? simply calls include? on the collection—so choose whichever reads better in context. For inline collections or when the subject of your conditional matters more than the collection, in? wins.

The Setup

Changes to four files, plus one more step if you want plugins.

Gemfile

gem "jekyll-tailwind", group: [:jekyll_plugins]

Run bundle install to fetch the gem. The jekyll-tailwind gem handles everything. No separate build pipeline, no PostCSS config, no watching for changes. It hooks into Jekyll’s build process.

Under the hood, it uses tailwindcss-ruby—the same gem that powers Tailwind in Rails.

_config.yml

plugins:
  - jekyll-tailwind

tailwind:
  input: assets/css/app.css
  minify: true

Point it at your CSS file and enable minification for production builds.

Tailwind Plugins (optional)

If you want Tailwind plugins like Typography or Forms, install them with npm:

npm install @tailwindcss/typography @tailwindcss/forms

This requires Node.js on your system. If you’re only using core Tailwind utilities, skip this step.

For blogs, @tailwindcss/typography is particularly useful. It provides prose classes that style your markdown content with sensible defaults for headings, paragraphs, lists, code blocks, and blockquotes:

<article class="prose prose-lg">
  <p>...</p>
</article>

assets/css/app.css

@import "tailwindcss";
/* @plugin "@tailwindcss/typography"; */
/* @plugin "@tailwindcss/forms"; */

@theme {
  --font-serif: "Georgia", serif;
  --breakpoint-sm: 400px;
  --breakpoint-md: 600px;
  --breakpoint-lg: 800px;
}

This is where Tailwind 4’s changes shine. The @theme block replaces tailwind.config.js. Custom fonts, breakpoints, colors, spacing—all defined in CSS.

Plugins use the @plugin directive instead of being listed in a JavaScript config.

_layouts/default.html

Include the stylesheet in your layout’s <head>:

<link href="/assets/css/app.css" rel="stylesheet">

Why This Works

The jekyll-tailwind gem runs Tailwind’s CLI during Jekyll’s build. When you run bundle exec jekyll serve, it:

1. Processes your input CSS file
2. Scans your templates for Tailwind classes
3. Generates optimized CSS
4. Outputs to _site/assets/css/app.css

Hot reload works. Change a class in a template, save, and the CSS rebuilds.

Why Not?

If you need complex PostCSS plugins beyond what Tailwind provides, you might want a separate build pipeline. But for most Jekyll sites, this setup handles everything.

Instead of…

…reversing the array or using reverse_each to find from the end:

numbers = [2, 2, 3, 4, 6, 7, 8]

numbers.reverse.find(&:odd?)
#=> 7

# or
numbers.reverse_each.find(&:even?)
#=> 8

Use…

…Ruby 4.0’s rfind method:

numbers = [2, 2, 3, 4, 6, 7, 8]

numbers.rfind(&:odd?)
#=> 7

# with a block
numbers.rfind { it.even? }
#=> 8

Why?

The rfind method iterates backwards from the last element, returning the first element that matches the given condition. It’s the reverse of find, which starts from the beginning.

This is more efficient than reverse.find or reverse_each.find because it doesn’t create an intermediate reversed array or enumerator in memory. For large arrays, this can make a noticeable difference.

You might wonder why this was added to Array specifically rather than Enumerable. The Enumerable module relies on the #each method, which only works in the forward direction. The only way to scan backwards generically would be to convert to an array first, defeating the purpose. However, arrays can be traversed in either direction efficiently by the nature of their implementation in the Ruby VM.

Why not?

If you’re not yet on Ruby 4.0, you’ll need to stick with reverse_each.find for now. It’s not a dramatic difference, but rfind is cleaner and more intentional.

For very small arrays, the performance difference is negligible, so the main benefit is readability—your intent is clearer when you use rfind.

Did you know?

In the same changeset, Kevin Newton also added a specific implementation of Array#find (and its alias #detect) rather than relying on the Enumerable version. This is a performance improvement for arrays.

January—February

Ten years ago, I was looking at the prices of T-shirt printing machines and figuring out the best way to manage stock and postal services. I’ve always wanted to have a place to exercise my design eye and this year I launched Ruby T-shirts.

I use a mix of Shopify and Printful and add designs whenever they come to me. I don’t have the headspace to manage stock and posting things myself, so this setup “just” (read mostly) works. From a financial perspective it just about breaks even: I’ve had over 100 orders this year and the relatively low cost cost of running a Shopify store combined with the low margins means it’s probably bought me a few negronis over the 12 months. But as an outlet for something I’ve always wanted to do, it scratches an itch. I absolutely love it.

It was also a good place to put the first ever Brighton Ruby T-shirt. Having struggled with socks a couple of years ago, I didn’t fancy printing 500 T-shirts of which only 30 were going to get used and 100 would remain in my loft in either very large or very small sizes.

Best T-shirts? Probably “_why Foxes Recreated”. Also the stylised text designs: the famous Beatles T-shirt, but for full stack Rails. Or perhaps “My Heart is Ruby”.

At CoverageBook, we welcomed our newest junior Darcy: the third year in a row of hiring from Le Wagon. It really feels like our hiring process has been a massive success, optimising for curiosity, responsibility and ambition. This is above any specific Ruby skills (other than an inkling of Ruby-ish-ness in the coding test). In 12 weeks on a hard, but by no means complete, introduction to programming web apps if you’re hiring for anything other than the human you’re doing it wrong.

March—April

Late March, while on a short countryside break, I was introduced, painfully, to the concept of a “re-root canal” which, after a bunch of very strong painkillers and anti-inflammatories, finally happened in April. Would not recommend.

We also, on a bit of a whim, went to look at a house with the idea that we’d look and immediately discount the idea of moving (as we had done in years past). Except this time… we didn’t, and I’m now writing this post from that very house.

CoverageBook projects for the year were foundational. Removing costs, re-envisioning our data collection to scale further than the 10x it’s currently doing from when I first built the current version. Also moving everything back into the main application; the separation has served its purpose.

2025 was about making everything clearer, more straightforward and more maintainable with our ambitious small team.

Plus we shipped a bunch of cool (smaller) features and platforms throughout the year.

May—June

Brighton Ruby: this year’s lineup was a massive hit with everyone who attended. Attendance was where it has been the last few years, around 450 people.

A small team of folks helped me out: Olly, Olivia and Ella from my team at CoverageBook pitched in on the day. My secret weapon for the last couple of years has been Anne-Marie from Eve Tribe, who manages the back of house so I can lark about on stage.

July—August

A big chunk of July I spent in the south of France, as has been the case the last few years, with a mixture of visiting friends, drama camp for the kids, and enormous amounts of excellent pastries ordered with my functional “shop French”.

Mostly stayed in Brighton for August in preparation for moving house. Lots of boxes, loft clearing and last-minute wobbles.

It was also around this time that I got stuck into properly exploring LLM-based tools to assist with coding. Initially using Claude Code fairly unsuccessfully in our many-year-old codebase, but gradually adding some process based on Brian Casel’s work on AgentOS and seeing other uses such as Gary beginning to vibe code some prototypes for the next iteration of CoverageBook in an extremely useful way.

September—October

September took me back to Amsterdam for Rails World (two words!) again. Amanda put on an incredible show and it’s a great opportunity for me to spend time hanging out with folks who otherwise I wouldn’t see but I consider to be my friends. Such is life in a globally spread community of programmers.

Unfortunately, every hour I spent in Amsterdam was an hour less I had to prepare to move the following week.

After 13 years living in one spot in Brighton, we moved 15 minutes across town, much closer to the sea, much closer to the marina, feeling closer to the sky and the curve of the Earth.

Definitely feeling the weather more as we’re super exposed to the prevailing winds. Moving to an older house from a new build has increased the amount of maintenance and challenge as we plan to take on a fairly significant building project next year to make the place truly our own.

The kids can now walk to school and this has certainly made life mechanically a bit easier, but I’m not going to lie: my head’s been quite full of all of the things required. New windows. Insulation. Architect. Builders. Plumbers. The weight of the impending cost and disruption of having our downstairs non-functional for weeks.

Half term was two trips! Pompeii, which mostly thrilled me and Jo historically. Only the gelato and pasta truly engaged the kids.

Then a train journey the length of the country and a couple of days eating pies and gingerbread, wandering the hills of the Lakes. England truly has its moments.

November—December

Gary’s prototypes really came into focus over the last couple of months of the year. As did my use of AI tools as an extra junior or two in my team, and in “Andy’s stupid side projects” world. The tools being built by Every and Conductor seem to be a real boost, alongside the release of the latest model from Anthropic. Scope and style are still a challenge. But “what to build”, as always, is the biggest challenge of all.

Seems I’ve been building the skills to manage code review and product review for the last decade in my career. It really feels like product-focused engineers have nothing to fear but their own capacity in the new world of LLM-based coding. It’s got much quicker to put boxes inside boxes on the Internet in the last six months.

The open source release of Fizzy has provided a real insight into ways to use Rails. Perhaps I and other larger teams have strayed from these patterns over the years, but an effort to be more vanilla was underway before that. So I feel like we’re on the right course from a maintenance perspective and, with prototypes from Gary, it’s going to be quite an interesting year to come.

This perspective on the new world of coding (via Justin) seems to capture why I dont feel the dread of the change in my day-to-day work. Aside from the obvious financial bubble, false promises and rapacious spending of the AI industry (“aside” doing a lot of work in that sentence) we’re going to be left with an entirey new set of useful tools once this era all shakes out and we learn how to hold everything properly.

Health

Locked into a metronomic Monday, Wednesday, Friday—before work—gym routine based on the Minimalift programme. Plus took up Vets football a little more seriously toward the back half of the year. Also PB’d my local parkrun at under 23 minutes, having previously believed 25 minutes was beyond me.

Want to try and both extend the distance I can go at “slow speed” and improve my 5k time, while trying to stay (self-inflicted) injury-free: which is easier said than done at 46.

Watched & Loved

Slow Horses, Andor, Arcane, The Traitors and its nation-gripping spin-off Celebrity Traitors, plus (with the kids) a rewatch of Brooklyn Nine-Nine.

Sean Combs: The Reckoning was fascinating and horrifying (did he? Yes, he definitely did).

Movie-wise, highlights were mostly rewatches. Saw the original Star Wars trilogy at the Duke of York’s with the kids; Aliens at the IMAX. Spent a good deal of the year introducing the kids to various classics: Jaws, The Sixth Sense, The Matrix, Die Hard, Four Weddings and a Funeral, and Endgame-ing the MCU.

I enjoyed A Real Pain, Anatomy of a Fall, A Complete Unknown, The Ballad of Wallis Island, Conclave, Sly Lives!, and (same as everyone else) One Battle After Another. And I double-featured Wicked the evening it came out with my daughter. No, you’re crying.

Played

Completed (!) Thank Goodness You’re Here, which must have mystified any non-British folk who stumbled into it. Played a ways into Arco, before its combat got merciless. Enjoyed a bit of Prince of Persia: The Lost Crown before falling out of its scale. Lonely Mountains: Downhill and Geometry Wars: Retro Evolved are pick-up-and-play marvels.

A summer Switch 2 purchase meant more Mario Kart and playing some previously janky Switch 1 titles at 60 FPS.

Replaying The Last of Us before I commit to the TV show. More Fortnite; the Simpsons season was a highlight.

Gleefully enjoyed the nineties stylings of Terminator 2D: No Fate once I’d broken up for Xmas.

Read

Continued the pure pleasurable nonsense of a handful of Reacher books, plus inhaled some “space” Brandon Sanderson. Really enjoyed Babel and Yellowface, only realising they were by the same author once I’d finished the second book.

2026

Brighton Ruby #14 is already selling tickets.

Expecting to somewhat up my “side project” game with the assistance of my robot army. Using Rails continued to grow throughout the year, one of those side projects that ticks along nicely.

Really looking forward to personally coaching some of those “small projects we won’t get to” at work to fruition. The team’s focus, which I’ll be on top of (but staying out of the critical path) is a major (PR industry-transforming) feature push informed by the prototyping Gary’s been doing.

Failed wildly to get What The Stack off the ground and fell off the writing train with the house move. I will be attempting to get back on a more regular cadence in 2026.

Closed the manual matching process for First Ruby Friend in August; hoping to relaunch with a proper automated platform in the new year.

Instead of…

…skipping all validations in your controller:

class Admin::UsersController < ApplicationController
  def create
    @user = User.new(user_params)
    if @user.save(validate: false)  # Skips ALL validations!
      redirect_to admin_users_path
    else
      render :new
    end
  end
end

…or using methods that bypass Active Record entirely:

class User < ApplicationRecord
  def self.admin_create(attributes)
    user = new(attributes)
    user.save
    user.update_columns(attributes)  # No validations, no callbacks
  end
end

This example uses a class method on the model, but you might see similar code in something like a UserFactory or UserCreationService in your application.

Use…

class User < ApplicationRecord
  validates :birthday, presence: true, except_on: :admin_create
end

# Admin creates user without birthday
user = User.new(name: "Jane")
user.save(context: :admin_create) # => true

# Regular save still requires birthday
user.save # => false

You can also stack multiple contexts:

validates :email, 
  format: { with: URI::MailTo::EMAIL_REGEXP },
  except_on: [:admin_create, :bulk_import]

Extending this to callbacks

Validation callbacks get the same treatment in Rails 8.1.

before_validation :normalize_email, except_on: :quick_signup
after_validation :check_email_uniqueness, except_on: [:admin_create, :bulk_import]

Now your callbacks follow the same pattern as your validations. Consistency wins.

Why?

Your admin interface needs to create users without complete data. Your data import skips some business rules. Perhaps your API has different requirements than your web forms.

Previously, you’d handle this with dangerous workarounds, seperate “factory” objects, or repetitive code.

Why not?

Every skipped validation is a possible data integrity issue. But that’s also true of the other approaches.

Real database constraints can act as your safety net for true data consistency.

A form object or separate model might make more sense for your application or team but you might be fighting the framework.

If you are skipping validations (even conditionally) you should also take a moment to consider whether the validation is really required. Does your application break when there’s no data in that attribute or not? If it doesn’t then is there a need to validate at all?

except_on can keep validations concise while making intent clear: “validate everywhere except here.” Just remember: with great power comes great responsibility. And some folks will hate this as much as they hate callbacks.

Had a day mostly to myself in Amsterdam on Wednesday, drinking coffee, eating chocolates, meeting friends, visiting the Anne Frank House and generally enjoying the vibe of the city while avoiding its insalubrious corners.

I even mananged a run around the city before the conference.

David kicked off with a typical combative mixture of what’s new in Rails, his current enthusiasms and accidental set ups for Aaron’s punchlines in the closing keynote.

Omarchy seems very appealing and I do have an urge to buy a Framework machine. The independence from exploitative gatekeepers (e.g. Apple) is a theme that I can get behind. That is the ongoing, upstart, driven, energy that an established framework like Rails really benefits from.

I also deleted all the system tests for CoverageBook in 2018, so I’m well ahead on that curve.

He performs the stage role of “50% more DHH” incredibly well during the keynote, and then puts in an additional extraordinary amount of energy and personal human-time talking to folks in the hallways over the next couple of days. Not sure I ever saw a moment when he wasn’t in intense conversation with an attendee, or likely more.

I enjoyed the more “depth on new features” talks that followed David’s keynote: Rosa (offline) Joe (Hotwire Native) Adrianna (Events) Mike & Donal (even more DB/SQLite). Plus Marco’s work on the view layer is innovative, super-useful, and a huge upgrade. And the quality was as good as it’s ever been. And the talks I wanted to see, but missed through being in a different track or getting caught up in conversation will be there for me on YouTube.

The MCs, Harriet and Chris, made a great success of what is actually a horrible job: they’re “on” all day, under huge pressure and barely even get to see the talks. The after party was incredibly cool, much too cool for me really but had a good time anyway. Food good. Coffee plentiful. Sponsors friendly.

My main takeaway from this year’s event was the imperceptible additional smoothness and polish where things weren’t even wrong in the previous two editions.

Those improvements are the hallmark of a great event organiser. Which is what we are fortunate to have in Amanda Perino.

She arrived to some scepticism in parts of our community. But her positivity energy and enthusiasm have created a festival where we can all meet. Plus I genuinely—even as a conference organiser of over a decade—have no idea how she makes it so shiny and brilliant. I do know she breaks herself a little bit so we can all enjoy ourselves.

As always, some of the best parts of the conference were catching up with long-term friends. I’ve been doing this work-related socialisation thing for so long that it’s an aching hole in my year if I don’t see folks for a few days.

I don’t know how to list it really. Every conversation always seems too brief or sometimes doesn’t happen because you only see someone in passing despite all being in the same three rooms. But there’s always next year or another conference and now I have my Ruby Passport that I need to pack with stamps.

Look out for an embassy at Brighton Ruby next year.

Also, given that apparently 1999 was the peak of web development: I made a 88x31 badge.

I was pointed at Enumerable#partition (by Brandon, Michael, Piotr & Kasper) which would avoid two of the four loops in the previously “best” solution.

I was also nudged to benchmark my initial “loops” solution by Dave, because straightforward loops are often extremely well optimised at the language level.

So… here’s all the benchmarks for that.

require 'benchmark/ips'

n = 100
a = Array.new(n) { |i| rand(1_000_000) }
b = Array.new(n) { |i| rand(1_000_000) }

Benchmark.ips do |x|
  # Pre-filter by odd/even, then compute products
  x.report('odd & even') do
    (a.select(&:odd?).product(b.select(&:even?)) +
      b.select(&:odd?).product(a.select(&:even?)))
    .uniq
  end
  # Alternatives: compute all products, then filter by sum
  x.report('full product, +') do
    a.product(b).select { (_1 + _2).odd? }.uniq
  end
  x.report('full product, sum') do
    a.product(b).select { _1.sum.odd? }.uniq
  end
  x.report('loops') do
    results = []
    a.each do |x|
      b.each do |y|
        if ((x + y) % 2) == 1
          results << [x, y]
        end
      end
    end
    results.uniq
  end
  x.report('partition') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    (odd_as.product(even_bs) + odd_bs.product(even_as)).uniq
  end

  x.compare!
end

Here’s the results:

Calculating -------------------------------------
          odd & even      1.347k (± 2.2%) i/s  (742.59 μs/i) -      6.850k in   5.089081s
     full product, +    785.253  (± 1.5%) i/s    (1.27 ms/i) -      3.952k in   5.034013s
   full product, sum    719.042  (± 2.1%) i/s    (1.39 ms/i) -      3.650k in   5.078324s
               loops    893.864  (± 1.3%) i/s    (1.12 ms/i) -      4.488k in   5.021755s
           partition      1.370k (± 1.8%) i/s  (729.79 μs/i) -      6.900k in   5.037264s

Comparison:
           partition:     1370.3 i/s
          odd & even:     1346.6 i/s - same-ish: difference falls within error
               loops:      893.9 i/s - 1.53x  slower
     full product, +:      785.3 i/s - 1.74x  slower
   full product, sum:      719.0 i/s - 1.91x  slower

Further improvements were suggested.

If we use a more apt method for combining arrays, like | or union we may see a performance improvement as we avoid the additional uniq loop through the final array of results.

require 'benchmark/ips'

n = 100
a = Array.new(n) { |i| rand(1_000_000) }
b = Array.new(n) { |i| rand(1_000_000) }

Benchmark.ips do |x|
  x.report('odd & even') do
    (a.select(&:odd?).product(b.select(&:even?)) +
      b.select(&:odd?).product(a.select(&:even?)))
    .uniq
  end
  x.report('odd & even union') do
    a.select(&:odd?).product(b.select(&:even?)).union(
        b.select(&:odd?).product(a.select(&:even?)))
  end
  x.report('odd & even |') do
    a.select(&:odd?).product(b.select(&:even?)) |
      b.select(&:odd?).product(a.select(&:even?))
  end
  x.report('loops') do
    results = []
    a.each do |x|
      b.each do |y|
        if ((x + y) % 2) == 1
          results << [x, y]
        end
      end
    end
    results.uniq
  end
  x.report('loops |') do
    results = []
    a.each do |x|
      b.each do |y|
        if ((x + y) % 2) == 1
          results | [x, y]
        end
      end
    end
    results
  end
  x.report('partition') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    (odd_as.product(even_bs) + odd_bs.product(even_as)).uniq
  end
  x.report('partition union') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    odd_as.product(even_bs).union(odd_bs.product(even_as))
  end
  x.report('partition |') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    odd_as.product(even_bs) | odd_bs.product(even_as)
  end

  x.compare!
end

The results are pretty much a wash for the partition and odd & even cases.

Calculating -------------------------------------
          odd & even      1.375k (± 0.4%) i/s  (727.08 μs/i) -      6.987k in   5.080142s
    odd & even union      1.334k (± 0.4%) i/s  (749.77 μs/i) -      6.700k in   5.023541s
        odd & even |      1.339k (± 0.4%) i/s  (746.81 μs/i) -      6.700k in   5.003743s
               loops    896.130 (± 0.9%) i/s    (1.12 ms/i) -      4.500k in   5.022004s
             loops |      1.416k (± 1.1%) i/s  (706.43 μs/i) -      7.100k in   5.016274s
           partition      1.378k (± 0.8%) i/s  (725.47 μs/i) -      6.900k in   5.006093s
     partition union      1.349k (± 0.6%) i/s  (741.43 μs/i) -      6.834k in   5.067094s
         partition |      1.346k (± 0.4%) i/s  (742.74 μs/i) -      6.834k in   5.075995s

Comparison:
             loops |:     1415.6 i/s
           partition:     1378.4 i/s - 1.03x  slower
          odd & even:     1375.4 i/s - 1.03x  slower
     partition union:     1348.7 i/s - 1.05x  slower
         partition |:     1346.4 i/s - 1.05x  slower
        odd & even |:     1339.0 i/s - 1.06x  slower
    odd & even union:     1333.7 i/s - 1.06x  slower
               loops:      896.1 i/s - 1.58x  slower

However, the performance of the “straightforward” loop solution is still significantly the worst, but when using the| operator in the depths of the loop, it leaps to becoming marginally better performing than all the other implementations.

One last thing. Ruby has a lazy evaluation feature which can be used to avoid overheads of creating intermediate arrays in large datasets, but it’s only available on certain methods on Enumerable.

One of those rewritten methods is uniq, does making the uniqueness loop a “lazy” enumerator affect performance? You can also use lazy with each in the “looping” example.

How do these new additions to the benchmark fare?

require 'benchmark/ips'

n = 100
a = Array.new(n) { |i| rand(1_000_000) }
b = Array.new(n) { |i| rand(1_000_000) }

Benchmark.ips do |x|
  x.report('odd & even') do
    (a.select(&:odd?).product(b.select(&:even?)) +
      b.select(&:odd?).product(a.select(&:even?)))
    .uniq
  end
  x.report('odd & even lazy') do
    (a.select(&:odd?).product(b.select(&:even?)) +
      b.select(&:odd?).product(a.select(&:even?)))
    .lazy.uniq
  end
  x.report('loops') do
    results = []
    a.each do |x|
      b.each do |y|
        if ((x + y) % 2) == 1
          results << [x, y]
        end
      end
    end
    results.uniq
  end
  x.report('loops |') do
    results = []
    a.each do |x|
      b.each do |y|
        if ((x + y) % 2) == 1
          results | [x, y]
        end
      end
    end
    results
  end
  x.report('loops | lazy') do
    results = []
    a.lazy.each do |x|
      b.lazy.each do |y|
        if ((x + y) % 2) == 1
          results | [x, y]
        end
      end
    end
    results
  end
  x.report('partition') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    (odd_as.product(even_bs) + odd_bs.product(even_as)).uniq
  end
  x.report('partition lazy') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    (odd_as.product(even_bs) + odd_bs.product(even_as)).lazy.uniq
  end
  x.report('partition |') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    odd_as.product(even_bs) | odd_bs.product(even_as)
  end

  x.compare!
end

It looks like the lazy version of uniq is a lot faster than the non-lazy versions, or the improved “loops with |” example, according to this test.

Calculating -------------------------------------
          odd & even      1.351k (± 2.5%) i/s  (740.37 μs/i) -      6.834k in   5.063314s
     odd & even lazy      6.145k (± 1.1%) i/s  (162.74 μs/i) -     31.263k in   5.088472s
               loops    917.432 (± 0.7%) i/s    (1.09 ms/i) -      4.641k in   5.058882s
             loops |      1.481k (± 2.7%) i/s  (675.29 μs/i) -      7.446k in   5.032326s
        loops | lazy      1.466k (± 0.3%) i/s  (682.27 μs/i) -      7.436k in   5.073396s
           partition      1.373k (± 0.5%) i/s  (728.15 μs/i) -      6.936k in   5.050569s
      partition lazy      5.224k (± 1.0%) i/s  (191.41 μs/i) -     26.180k in   5.011751s
         partition |      1.339k (± 0.7%) i/s  (746.74 μs/i) -      6.732k in   5.027289s

Comparison:
     odd & even lazy:     6144.7 i/s
      partition lazy:     5224.3 i/s - 1.18x  slower
             loops |:     1480.9 i/s - 4.15x  slower
        loops | lazy:     1465.7 i/s - 4.19x  slower
           partition:     1373.3 i/s - 4.47x  slower
          odd & even:     1350.7 i/s - 4.55x  slower
         partition |:     1339.2 i/s - 4.59x  slower
               loops:      917.4 i/s - 6.70x  slower

Is there some magic behind the scenes that makes the lazy version of uniq faster than the non-lazy version? Sadly, no. The lack of a performance difference between the lazy and non-lazy “loop” versions should be the clue here.

uniq processes the entire array immediately and returns a new array with duplicates removed. It has to examine every element to determine uniqueness.

lazy.uniq returns a Enumerator::Lazy that doesn’t do any work until you start consuming elements from it! In order for this to be a fair comparison the code would have to be:

  # e.g.
  x.report('partition lazy') do
    odd_as, even_as = a.partition(&:odd?)
    odd_bs, even_bs = b.partition(&:odd?)
    (odd_as.product(even_bs) + odd_bs.product(even_as)).lazy.uniq.to_a
  end

The results bear this out:

Calculating -------------------------------------
             loops |      1.436k (± 2.6%) i/s  (696.42 μs/i) -      7.191k in   5.011518s
        loops | lazy      1.424k (± 1.4%) i/s  (702.40 μs/i) -      7.228k in   5.078029s
           partition      1.359k (± 1.7%) i/s  (735.93 μs/i) -      6.885k in   5.068374s
      partition lazy    814.193  (± 2.9%) i/s    (1.23 ms/i) -      4.116k in   5.060084s

Comparison:
             loops |:     1435.9 i/s
        loops | lazy:     1423.7 i/s - same-ish: difference falls within error
           partition:     1358.8 i/s - 1.06x  slower
      partition lazy:      814.2 i/s - 1.76x  slower

What have we learned from this wild goose chase of nerd-sniping?

1. It’s ok to optimise for readability.
2. It’s important to accurately benchmark your code when you’re trying to optimize.
3. Ruby is delightful.
4. I sometimes can’t let go.

So I decided to benchmark the solutions to find out.

require 'benchmark/ips'

n = 10
a = Array.new(n) { |i| rand(1_000_000) }
b = Array.new(n) { |i| rand(1_000_000) }

Benchmark.ips do |x|
  # Mine: pre-filter by odd/even, then compute products
  x.report('odd & even check') do
    (a.select(&:odd?).product(b.select(&:even?)) +
      b.select(&:odd?).product(a.select(&:even?)))
    .uniq
  end
  # Alternatives: compute all products, then filter by sum
  x.report('full product, +') do
    a.product(b).select { (_1 + _2).odd? }.uniq
  end
  x.report('full product, sum') do
    a.product(b).select { _1.sum.odd? }.uniq
  end

  x.compare!
end

In the testing script I set a variable (n) for the size of the generated arrays. I presumed that for small arrays there’d be very little difference it would be more noticeable as the arrays grew larger. Intuitively, I’d expect the performance to be worse when using the full product approach, as the memory allocation of the intermediate array would be much larger.

Here’s the results when n = 10:

Warming up --------------------------------------
    odd & even check     9.686k i/100ms
     full product, +     7.030k i/100ms
   full product, sum     6.911k i/100ms
Calculating -------------------------------------
    odd & even check     97.138k (± 0.7%) i/s   (10.29 μs/i) -    493.986k in   5.085694s
     full product, +     74.138k (± 1.8%) i/s   (13.49 μs/i) -    372.590k in   5.027459s
   full product, sum     69.031k (± 0.9%) i/s   (14.49 μs/i) -    345.550k in   5.006096s

Comparison:
    odd & even check:    97137.7 i/s
     full product, +:    74137.7 i/s - 1.31x  slower
   full product, sum:    69031.3 i/s - 1.41x  slower

A surprising difference in comparative performance, given the small size of the array, but the individual runtimes are very small; in the microseconds.

And for n = 1_000:

Warming up --------------------------------------
    odd & even check     1.000 i/100ms
     full product, +     1.000 i/100ms
   full product, sum     1.000 i/100ms
Calculating -------------------------------------
    odd & even check     12.568 (± 8.0%) i/s   (79.57 ms/i) -     63.000 in   5.023134s
     full product, +      6.891 (± 0.0%) i/s  (145.12 ms/i) -     35.000 in   5.091415s
   full product, sum      6.369 (± 0.0%) i/s  (157.00 ms/i) -     32.000 in   5.029184s

Comparison:
    odd & even check:       12.6 i/s
     full product, +:        6.9 i/s - 1.82x  slower
   full product, sum:        6.4 i/s - 1.97x  slower

And for n = 10_000:

Warming up --------------------------------------
    odd & even check     1.000 i/100ms
     full product, +     1.000 i/100ms
   full product, sum     1.000 i/100ms
Calculating -------------------------------------
    odd & even check      0.054 (± 0.0%) i/s    (18.57 s/i) -      1.000 in  18.574282s
     full product, +      0.021 (± 0.0%) i/s    (46.66 s/i) -      1.000 in  46.663944s
   full product, sum      0.022 (± 0.0%) i/s    (45.83 s/i) -      1.000 in  45.833142s

Comparison:
    odd & even check:        0.1 i/s
   full product, sum:        0.0 i/s - 2.47x  slower
     full product, +:        0.0 i/s - 2.51x  slower

The main surprise, which I didn’t initially consider, is how quickly the performance degrades with any of the approaches as the array sizes increase.

It makes sense, as that’s a factor of O(n²) (or near enough) in all solutions. Thousand element arrays mean one million pairs to evaluate. Whereas ten thousand element arrays is one hundred million pairs: a 100x increase! The use of .product ends up creating large intermediate arrays which increase memory usage.

In reality, for small arrays—as suggested in the original question—the performance difference is negligible, so picking the most readable solution is the most important decision. As the arrays get beyond the thousands of elements, were we to execute this task in a typical web request, none of the solutions are going to scale well.

For truly large datasets we might consider streaming, lazy evaluation or parallelization, but that’s outside the scope of this code golfing exercise.