DEV Community: Syed Aslam

Git Worktrees: Multiple Branches Without the Checkout Shuffle

Syed Aslam — Wed, 22 Jul 2026 21:39:00 +0000

Working on more than one Git branch often creates an awkward routine:

Stop what you are doing.
Stash incomplete changes.
Check out another branch.
Investigate or fix something.
Switch back.
Restore the stash and hope nothing was misplaced.

This gets especially painful with stacked pull requests, urgent fixes, long-running test suites, or reviews that require comparing several versions of the same code.

Git worktrees offer a cleaner approach. They let you check out multiple branches from one repository into separate directories at the same time.

I first paid attention to worktrees after noticing AI coding tools using them to run multiple agents against the same repository in parallel, each in its own checkout, without overwriting the others’ working files, with no need to push anything to the cloud just to isolate it. That was reason enough to learn how the mechanism actually works.

I put them to real use during a stacked-branch repair: a parent branch needed fixing, and a child branch built on top of it needed rebasing afterward. I was running AI coding tools alongside my own changes, and repeatedly stashing and switching made it increasingly difficult to track which branch and working-tree state I was looking at. Moving the parent and child into their own worktrees, leaving my original checkout, including its untracked review notes, untouched, made the rebase far easier to reason about.

The mental model

A normal Git repository combines two kinds of state:

Shared repository state: commits, branches, tags, remote references, and repository configuration by default.
Checkout state: the current branch, working files, staged changes, and in-progress operations.

A worktree adds another checkout while continuing to use the same shared repository data.

Each worktree has its own checked-out files, index, and HEAD. Commits and branch references remain shared.

This means one directory can remain on a base branch while another contains a feature branch and a third contains its dependent child branch. There is no need to stash or repeatedly switch between them.

A simple example

Suppose a repository lives in a directory named project, and a feature branch needs to be inspected without disturbing the current checkout.

First, refresh the remote references:

git fetch origin

Then add a worktree for an existing local branch:

git worktree add ../project-feature feature-branch

The resulting directories might look like this:

workspace/
├── project/          main checkout
└── project-feature/  feature branch checkout

The ../ is what keeps it a sibling. Drop it and run git worktree add project-feature feature-branch from inside project, and Git will happily create the new worktree nested inside your current directory instead, where it then shows up as an untracked folder in project's own git status.

Both directories belong to the same Git repository, but each has independent working files.

Alternatively, to create a new local branch from a remote branch while setting up a worktree in a dedicated directory:

git worktree add \
  -b repair/feature \
  ../project-repair \
  origin/feature-branch

Now enter the new directory and work normally:

cd ../project-repair
git status
git log --oneline --decorate -10
bundle exec rake test # or npm test

Commits created there are immediately available to the other worktrees because they share the same Git object database.

Inspecting active worktrees

List the registered worktrees with:

git worktree list

Typical output looks like this:

/path/to/project          1a2b3c4 [main]
/path/to/project-feature  5d6e7f8 [feature-branch]

For scripts or detailed troubleshooting, use the machine-readable form:

git worktree list --porcelain

What is shared and what is isolated?

Understanding the boundary prevents most surprises.

State	Shared between worktrees?
Commits and Git objects	Yes
Local branch references	Yes
Remote references	Yes
Tags	Yes
Repository configuration	Shared by default
Stash list	Yes
Current branch and `HEAD`	No
Checked-out files	No
Staging index	No
Untracked files	No
In-progress rebase or merge	No
Build output inside the directory	No

The shared stash list is easy to overlook. Running git stash stashes uncommitted changes from the current worktree, but the stash entry is stored in the shared Git repository state. This means git stash list, git stash apply, and git stash pop operate on the same shared stash stack from every worktree. Using descriptive messages helps avoid popping a stash into the wrong branch:

git stash push -m "feature branch before conflict resolution"

Repository configuration is shared by default. Git can also maintain worktree-specific settings when extensions.worktreeConfig is enabled and values are written using git config --worktree.

Untracked files are the other easy thing to overlook, and the one that stalls a new worktree the fastest. A worktree only contains files Git tracks; anything ignored or generated locally has to be created again. In a Rails app, that often includes config/master.key, .env, local database.yml overrides, node_modules, and any worktree-local bundle path such as vendor/bundle:

cd ../project-feature
cp ../project/config/master.key config/master.key
cp ../project/.env .env
bundle install

Symlinking instead of copying keeps credentials and environment files in sync automatically, which is useful when every worktree should run against the same local environment. A relative symlink target resolves from the symlink's own directory, not from your shell's current directory, so config/master.key and .env need different numbers of ../ to reach the same place. Use an absolute path instead to avoid that arithmetic:

PROJECT_ROOT="$(cd ../project && pwd)"

ln -s "$PROJECT_ROOT/config/master.key" config/master.key
ln -s "$PROJECT_ROOT/.env" .env

Only symlink files you want shared. A worktree deliberately testing a different .env or database configuration should keep its own copy instead.

The most important restriction

Git generally prevents the same branch from being checked out in two worktrees simultaneously.

Attempting it produces an error similar to:

fatal: 'feature-branch' is already checked out at '/path/to/project-feature'

This restriction protects the branch from being moved independently by two checkouts. When a branch is already checked out elsewhere, you have four main options: use that existing worktree, create another branch, use a detached worktree for inspection, or remove the obsolete worktree.

When another view of the same commit is needed, create a detached worktree:

git worktree add --detach ../project-inspect origin/feature-branch

Detached worktrees are useful for inspection and testing. If commits are created there, attach them to a branch before relying on them:

git switch -c investigation/result

Why worktrees are useful for stacked pull requests

Consider a stack with a base branch, a parent feature, and a child feature. The child must be rebased after correcting the parent.

Without worktrees, the process often becomes:

stash → switch to parent → repair → test → switch to child
      → rebase → resolve → test → restore previous work

With worktrees, each branch remains available in its own directory:

workspace/
├── project-base/
├── project-parent/
└── project-child/

A practical workflow is:

Repair and test the parent in its worktree.
Commit and push the corrected parent.
Rebase the child in its own worktree.
Consult the parent directory while resolving conflicts.
Test the exact child commit intended for push.
Repeat for the next descendant.

This is safer than repeatedly switching branches because the corrected parent remains visible throughout conflict resolution. It also reduces the chance of accidentally restoring stale code from the child, while eliminating the repeated dependency and build churn caused by switching a single directory between different branches.

A reusable stacked-branch setup

Create dedicated worktrees for a parent and child branch:

git fetch origin

git worktree add \
  -b parent-branch \
  ../project-parent \
  origin/parent-branch

git worktree add \
  -b child-branch \
  ../project-child \
  origin/child-branch

After repairing and committing the parent, rebase the child:

cd ../project-child
git rebase parent-branch

During conflicts, the parent worktree remains available as a trustworthy reference. After resolving and testing, the rewritten child branch can be pushed safely:

git push --force-with-lease origin child-branch

Parallel testing and investigation

Worktrees are also useful when no branch rewrite is involved.

They make it possible to:

Run a long test suite on one branch while editing another.
Compare generated output between two branches.
Review a pull request without disturbing unfinished work.
Keep a production hotfix separate from feature development.
Test multiple dependency or framework upgrade branches.
Open parent and child implementations side by side in an editor.

Each worktree has separate filesystem output, so test artifacts and build products do not overwrite those in another worktree unless they use an external shared service or cache.

Because branches live in separate directories, you can also use standard terminal diffing tools to compare implementations directly across worktrees:

# Compare specific files between parent and child worktrees
diff -u ../project-parent/src/service.rb ../project-child/src/service.rb

Databases, Redis instances, containers, ports, and global caches are not automatically isolated merely because the source directories are separate. Parallel test environments may still need distinct database names, ports, or namespaces.

Merging a worktree's branch back

Merging only picks up what's committed, so confirm the feature worktree is clean first:

cd ../project-feature
git status

Commit or stash anything outstanding. An uncommitted change sitting in the feature worktree won't be part of the merge, and it's easy to assume it was included just because the branch was.

While still in the feature worktree, rebasing onto main first keeps the merge itself trivial, often a fast-forward instead of a merge commit:

git rebase main

Resolve any conflicts here, in the feature worktree, rather than during the merge itself.

Because commits and branch references are shared across worktrees, merging one worktree's branch into another doesn't require pushing or fetching first. From the worktree that has the target branch checked out, commonly the main worktree, merge directly:

cd ../project
git switch main
git merge feature-branch

When the workflow goes through a pull request instead, push the branch, merge on GitHub, then run git pull in the worktree tracking main to bring the merge commit in locally.

Once the branch is merged, its worktree has done its job and can be removed.

Removing a worktree safely

Before removing a worktree, check for local changes:

cd ../project-feature
git status

Then move to another worktree and remove it through Git:

cd ../project
git worktree remove ../project-feature

Using git worktree remove is preferable to deleting the directory manually because Git also removes its internal registration.

Removing the worktree doesn't delete the branch it had checked out. Branches are shared repository state, not checkout state. Once a branch is merged and its worktree is gone, delete the branch itself if it's no longer needed:

git branch -d feature-branch

If a directory was deleted outside Git, clean up stale metadata with:

git worktree prune

Force removal is available, but it can discard modified and untracked files:

git worktree remove --force ../project-feature

Use it only after confirming that nothing in the worktree needs to be preserved.

Worktrees are not clones

A second clone also provides another checkout, but it duplicates repository objects and has independent local branches, tags, stashes, and configuration. Keeping those clones synchronized requires additional fetching and coordination.

A worktree is lighter and more tightly connected:

Objects are stored once.
New commits are immediately visible everywhere.
Local branches and tags are shared.
Repository configuration is shared by default.

Use separate clones when true repository-level isolation is required. Use worktrees when the goal is simply to work with multiple branches from the same repository at once.

A note on project layout: Bare repositories

While the examples in this post place worktrees in sibling directories (../project-parent), developers who use worktrees heavily often clone repositories as bare repositories instead:

mkdir project
cd project

git clone --bare git@github.com:user/project.git .bare

git --git-dir=.bare config remote.origin.fetch \
  '+refs/heads/*:refs/remotes/origin/*'
git --git-dir=.bare fetch origin

git --git-dir=.bare worktree add main main
git --git-dir=.bare worktree add feature feature-branch

A bare clone places the remote's branch heads directly under local branches and does not create the ordinary origin/* remote-tracking references on its own. The explicit fetch refspec above restores that familiar layout, which the git fetch origin and origin/feature-branch references used earlier in this post depend on.

The resulting layout keeps all worktree checkouts cleanly separated under a single workspace folder:

project/
├── .bare/
├── main/
└── feature/

Unlike a normal clone, a bare repository has no default working tree of its own, acting purely as the shared repository storage for linked worktrees.

Practical safety rules

A few habits make worktrees predictable:

Use clear directory names that identify the branch or task.
Run git status before rebasing, resetting, or removing a worktree.
Run git worktree list before deleting or renaming branches.
Remember that branch references are shared: committing, resetting, rebasing, or otherwise moving a branch in one worktree is immediately visible from the others.
Avoid manually deleting worktree directories.
Keep important backup branches until rewritten branches have been pushed and verified.
Test from the worktree containing the exact commit intended for push.
Isolate external services when running worktrees concurrently.
Open each worktree in its own editor or IDE window so language server (LSP) indexes remain isolated.
Remove finished worktrees so the workspace does not become cluttered.

Final takeaway

A worktree is another independent checkout of the same Git repository, allowing multiple branches to remain open simultaneously without cloning the repository multiple times.

It replaces the repeated stash-and-switch routine with a stable directory per branch. That makes reviews, stacked pull requests, difficult rebases, parallel testing, and urgent fixes easier to reason about and much less likely to disturb unrelated work.

For many multi-branch workflows, the most useful first commands are simply:

git worktree add ../project-feature feature-branch
git worktree list
git worktree remove ../project-feature

Once that mental model clicks, worktrees become one of Git's most practical tools.

Why present? Can Hide SQL in Rails

Syed Aslam — Fri, 24 Apr 2026 13:46:00 +0000

A lot of Rails performance problems do not start with obviously expensive code, but with code that looks harmless.

For example:

if order.line_items.present?
  # ...
end

That reads like a simple boolean check, ordinary Ruby. and not like a database operation. But on an unloaded Active Record association, that line may issue SQL.

That is what makes it dangerous. Not the cost of one call, but the mismatch between how the code reads and what the system actually does.

In Rails, some predicates are not purely local questions. They can cross the database boundary to answer what looks like an in-memory check.

Once you see that, a lot of "mysterious" performance issues stop looking mysterious.

Why this is easy to miss

The method name is the trap.

present? sounds like a lightweight predicate. In most Ruby code, that intuition is fine. You ask a question about a value that already exists in memory, and you get an answer.

Associations break that expectation.

When you call:

order.line_items.present?

Rails may be able to answer from memory if line_items is already loaded. If not loaded, Rails has to hit the database to decide whether the association is empty.

The same line can behave differently depending on context the line itself does not show. That is a real problem.

Where this becomes expensive

One hidden query usually doesn't matter. A hundred do.

orders.each do |order|
  next unless order.line_items.present?
  # ...
end

Nothing about the loop looks suspicious. There is no where, no find_by, no explicit query call. The code reads cleanly. But if line_items has not been preloaded, that can turn into one query per order.

This is one reason N+1 issues survive in Rails applications. The expensive part often hides behind method calls that do not advertise that they might perform I/O.

What is happening under the hood

The exact implementation details are less important than the shape of the behaviour.

present? delegates to blank?. In an association, answering whether it is blank eventually depends on whether it is empty. If the association is not loaded, Active Record has to query the database to answer that question.

So the issue is not really present? versus blank?. The real issue is that predicate-like code can quietly depend on the database.

What to write instead

The fix is on intent. If your real question is "do related records exist in the database?", write that directly:

order.line_items.exist?

That makes the boundary explicit. A reader immediately knows this line may hit the database.

If your real intention is to use the records in memory, preload them first:

orders = Order.includes(:line_items)

orders.each do |order|
  next unless order.line_items.present?
  # ...
end

Now the check is operating on already-loaded data. The code reads more honestly.

That is the standard I keep coming back to: if a line might hit the database, it should either say so directly or sit inside a structure that makes the loading strategy visible.

This is bigger than `present?`

present? is just an easy example. Rails has other methods with the same shape. any?, empty?, and sometimes size can all blur the line between in-memory logic and database-backed behaviour when they are called on associations.

The details vary, but the lesson does not.

If a method looks local but depends on load state, it is worth pausing before scattering it through hot paths.

The habit that helps

In long-lived Rails systems, I try to make query boundaries visible.

Not because convenience methods are bad. But, because hidden I/O makes code harder to reason about. They hide costs and make reviews weaker, and let performance issues pass as innocent object logic.

present? is fine when the data is already in memory. It becomes a smell when it hides the moment your code stops being local.

present? and the Hidden Query Boundary

Syed Aslam — Fri, 27 Feb 2026 00:00:00 +0000

This looks harmless:

if order.line_items.present?
  # ...
end

It reads like a pure boolean check. In ActiveRecord associations, it sometimes isn't.

Under the hood, present? delegates to blank?, which for un-loaded associations cascades down to empty?. When empty? is called, ActiveRecord may hit the database to determine if records exist. The method name suggests a local predicate. The behavior sometimes crosses the database boundary.

Without preloading, this simple check can become surprisingly expensive in aggregate:

orders.each do |order|
  next unless order.line_items.present?
  # ...
end

In a loop, it becomes one query per order. It scales with record count. It doesn’t look like I/O at the call site.

In long-lived systems, I try to make database boundaries obvious in code. If a predicate can hit the database, I want that to be visible. Using exists? makes the I/O explicit. Alternatively, preloading the association upfront ensures that present? remains a purely in-memory check. Being explicit about these access patterns removes ambiguity.

Convenience helpers are useful. But when they conceal I/O, they also conceal cost. In small systems, that rarely matters. In mature ones, it adds up.

This pattern appears frequently when diagnosing performance in long-lived Rails systems.

When ||= Betrays Your Memoization

Syed Aslam — Sat, 21 Feb 2026 10:42:42 +0000

Memoization in Ruby often looks harmless:

def active?
  @active ||= compute_active_flag
end

It’s clean. It’s idiomatic. It avoids duplicate work.

For years, this pattern feels safe.

But ||= does not mean “if unset.”
It means “if falsey.”

And in long-lived systems, that difference matters.

The subtle behavior

This:

@active ||= compute_active_flag

means Ruby assigns only when @active is nil or false.

So, since nil and false are the only falsey values in Ruby:

@active is nil -> compute
@active is false -> compute
@active is truthy -> reuse

Memoization with ||= is only reliable when the memoized value is guaranteed to become truthy.

How this causes confusion over time

In one system I worked on, a boolean flag was memoized exactly like this.

At first, the flag was effectively “unset or true,” and everything worked.

Later, the domain evolved. false became an explicit, meaningful result based on new business rules.

That’s when it got strange:

the method recomputed unexpectedly, silently destroying performance if compute_active_flag was expensive
tests became noisy and inconsistent
code readers assumed memoization was happening, because the syntax looked memoized

The code looked correct.
The semantics weren’t.

That gap is where long-lived systems accumulate friction.

Why this happens

As systems mature:

flags gain new states
defaults become explicit
“maybe missing” becomes “intentionally false” (or sometimes intentionally nil)

But ||= never changes its behavior. It keeps encoding a truthiness assumption that may no longer fit your domain.

This isn’t a Ruby flaw.
It’s a reminder that convenience operators carry semantics.

Safer patterns

If false is valid, but nil still means “unset”:

def active?
  return @active unless @active.nil?
  @active = compute_active_flag
end

If both false and nil are legitimate cached values, guard on definition instead using defined? (which is slightly faster, as it's evaluated by the parser rather than as a method call) or instance_variable_defined?:

def active?
  return @active if defined?(@active)
  @active = compute_active_flag
end

Now false and nil are preserved as cached results, and behavior matches intent.

It’s a few more characters.
It’s also semantically honest.

The broader lesson

Most issues in long-running systems aren’t dramatic failures.

They’re small mismatches between yesterday’s assumptions and today’s domain.

||= is a perfect example: convenient, idiomatic, and excellent in the right context.

But when false or nil becomes meaningful, tiny semantics compound.

Explicitness costs a little now.
It usually saves much more later.

References

Stimulus Is Boring — and That’s Why It Works

Syed Aslam — Tue, 03 Feb 2026 13:44:10 +0000

People expect their frontend tools to feel powerful. They want velocity, elegance, leverage—some sense that a new layer will unlock a faster future. In that context, Stimulus can feel underwhelming. It’s small. It’s constrained. It doesn’t promise much.

That gap between expectation and experience can feel like a warning. In a hype-driven ecosystem, “boring” reads like failure.

But that boredom isn’t a flaw. It’s the point.

When people call Stimulus boring, they often mean it as a dismissal. But “boring” in this context doesn’t mean outdated or weak. It means it has a limited surface area. It prefers explicit behavior over cleverness. Its failure modes are predictable. And it’s easy to delete.

That last one matters more than most people admit. Tools you can remove without regret are tools that age well.

The problem Stimulus is actually solving isn't the one people expect. Most Rails apps are not SPAs. Most UI behavior isn’t a complex state machine. It’s forms, toggles, modals, progressive enhancements. Most teams want fewer moving parts, lower cognitive load, and onboarding that doesn’t require a front-end renaissance.

Stimulus isn’t trying to “win the frontend.” It’s trying to get out of the way.

That’s why it shines in mature codebases. In long-lived Rails apps. In teams with mixed skill levels and shifting ownership. In systems optimized for correctness and change safety. In places where deleting code matters more than adding features.

Stimulus keeps JavaScript close to the HTML it enhances. That sounds small until you’re in the middle of a refactor, or hunting a production bug, or triaging an incident. Keeping behavior near the markup makes the whole system easier to reason about when it matters most. No benchmarks needed. Just judgment earned over years of maintaining real systems.

None of this is a dismissal of modern frontend frameworks. React, Vue, and friends solve different problems. They optimize for expressiveness, for building rich, interactive experiences where the client is the product. Stimulus optimizes for longevity.

Most Rails apps don't fail because the frontend wasn't powerful enough. They fail because the system became too hard to reason about.

That difficulty compounds over time. Dependency churn. Tooling fatigue. Cognitive overhead. Frontend rewrites no one budgets for. Stimulus's strength is that it rarely forces a rewrite. It doesn't create a parallel universe inside your app. It can be incrementally removed. It quietly resists the kind of complexity that only shows its cost years later.

That doesn't make it a universal choice. Stimulus is the wrong tool for highly interactive, state-heavy UIs. It's the wrong choice when your primary complexity is client-side, or when your team is intentionally betting on frontend specialization. It doesn't pretend otherwise, and neither should we.

What it offers instead is something durable: the quiet value of boring tools. They survive trends. They age without ceremony. They reward teams who plan to be around.

Stimulus isn’t exciting. It’s dependable. And in mature systems, that’s usually the harder thing to build.

Escaping the AMS Trap: How We Benchmarked Our Way to Alba

Syed Aslam — Tue, 20 Jan 2026 12:35:00 +0000

If you are running a Rails application that is more than a few years old, there is a very high probability that you are using ActiveModel::Serializers (AMS).

You also probably know that AMS is "dead". The repository has been archived, maintainers have moved on, and 0.10.x is effectively the final version.

Yet, despite this well-known fact, AMS remains one of the most deployed gems in the ecosystem. Why? Because migration is terrifying. Serialization is the final mile of your API; getting it wrong breaks mobile apps, frontends, and third-party integrations. Furthermore, AMS, specifically when configured with caching, is surprisingly fast. It’s hard to justify a rewrite when the "dead" code is still serving requests in sub-millisecond time.

We recently faced this dilemma. Our AMS implementation was working, but it was a dead end. We wanted to move to something modern, maintained, and standards-compliant, but we couldn't afford to regress on performance.

Here is the story of how we pitted the incumbents against the challengers and why we ultimately chose Alba.

The Contenders

We narrowed our search to three primary options:

ActiveModel::Serializers (The Incumbent)

Pros: Deeply integrated, supports view caching, "it just works."
Cons: Unmaintained, memory-heavy, implicit behavior ("magic").
Variants Tested: We tested both "Standard" (instantiating new serializers per request) and "Cached" (fetching pre-computed JSON strings from Memcached).

Blueprinter

Pros: Declarative, widely used, good documentation.
Cons: Syntax is slightly different from the "Rails way," performance is good but generally trails Alba.

Alba

Pros: Modern, explicitly designed for speed, highly compatible with the Oj JSON library.
Cons: Newer ecosystem, requires strict definition of resources.

The Benchmark: Real World Data, Not "Hello World"

Micro-benchmarks are often misleading. Serializing a simple User object with a name and email is easy for any library.

To make an informed decision, we created a benchmark representing our heaviest real-world scenario: a full E-commerce Order.

Our test setup involved:

1 Order
100 Fulfillment Groups (shipments)
100 Line Items (spread across groups)
Associated Data: Adjustments (taxes/promotions), Payments, Customers, and Addresses.

This is a heavy payload. It heavily exercises the serializer's ability to handle associations (has_many, belongs_to) and nested logic.

The Code

We implemented the exact same JSON structure across all three libraries.

The Alba Implementation: Notice how Alba feels familiar to AMS users but with more explicit control.

class OrderAlbaSerializer
  include Alba::Resource
  include Alba::Serializer

  attributes :id, :state, :total, :subtotal, :created_at
  # Relationships are explicit
  many :fulfillment_groups, resource: FulfillmentGroupAlbaSerializer
  many :line_items, resource: LineItemAlbaSerializer
  one :venue

  # Computed attributes use a clean block syntax
  attribute :seat_description do |order|
    "#{order.section.name} - #{order.row.name}"
  end
end

The Results

We ran the benchmarks using benchmark-ips (iterations per second). The results were illuminating.

(Note: Relative performance figures based on our internal testing)

AMS (Cached): ~3,500 i/s 🏆
Alba (with Oj): ~2,800 i/s 🥈
Blueprinter: ~2,100 i/s
AMS (Uncached): ~600 i/s 🐢

The "Caching" Elephant in the Room

The most striking data point is that AMS with Caching was the fastest.

This explains why so many apps are stuck on AMS. When you cache the entire JSON string of a serializer, you are effectively bypassing the serialization work entirely on subsequent hits. It’s hard to beat "fetching a string from RAM."

However, Alba (backed by the Oj gem) came dangerously close, without caching.

Alba + Oj was nearly 4-5x faster than standard, uncached AMS. It was so fast that it fundamentally changed our engineering calculus.

The Decision: Why We Chose Alba

If AMS Cached is faster, why switch?

1. Speed Without Complexity

Caching is hard. Cache invalidation is one of the two hardest problems in computer science (along with naming things and off-by-one errors).

With AMS, we relied on caching to get acceptable performance. If the cache missed, the user felt it (dropping to 600 i/s).

With Alba, the baseline performance is exceptional. We get ~2,800 i/s every single time. We don't need to manage complex cache keys. We can simplify our architecture by removing the view caching layer entirely for most endpoints.

2. The Oj Factor

Alba is designed to leverage Oj (Optimized JSON), a C-extension for Ruby that is incredibly fast. By setting:

# config/initializers/alba.rb
Alba.backend = :oj

Alba bypasses much of the Ruby object allocation overhead that slows down other serializers.

3. Safety and Maintenance

AMS 0.10.x is a ghostly dependency. It might break with the next major Rails upgrade. Alba is active, standard-compliant, and its codebase is easy to read and understand.

The Caching Gap (and How We Fixed It)

There was one catch: Alba does not support caching out of the box.

This is by design. The creators of Alba (and indeed, many in the API community) believe that serialization logic should remain pure, and caching should be handled at the HTTP layer or application boundary. (See Rails Issue #41784).

For us, however, fragment caching is critical. We have complex objects (like venues with thousands of seats) where re-serializing everything, even with Alba's speed, is wasteful.

The Solution: A Lightweight Concern

Since Alba is just Ruby, adding caching back in was surprisingly trivial. We didn't need the heavy "Cache Adapter" machinery of AMS. We just needed a decorator.

We wrote a simple AlbaCaching concern that wraps the serialize method:

module AlbaCaching
  extend ActiveSupport::Concern

  class_methods do
    def cache(options = {})
      @cache_options = options
    end
    def cache_options
      @cache_options
    end
  end

  def serialize(root_key: nil, meta: {})
    return super unless self.class.cache_options
    # Construct a cache key from the object and serializer name
    key_base = object.respond_to?(:cache_key) ? object.cache_key : "#{object.class.name.underscore}/#{object.id}"
    cache_key = "#{key_base}/#{self.class.name.underscore}"

    ttl = self.class.cache_options[:expires_in] || 1.hour
    Rails.cache.fetch(cache_key, expires_in: ttl) do
      super
    end
  end
end

Now, we can just mix this into any serializer that needs it:

class HeavyVenueSerializer
  include Alba::Resource
  include AlbaCaching

  cache expires_in: 30.minutes

  attributes :id, :name, :capacity
end

This gave us the best of both worlds: the raw speed of Alba/Oj for 90% of our requests, and the ability to selectively cache heavy fragments where needed, without the bloat of AMS.

Automating the Migration

With the decision made and the caching gap bridged, we faced one final hurdle: the sheer volume of code. We had dozens of serializers to convert.

Rewriting them by hand was too much work.

(Note: If you are on Ruby 3.1+, you should check out the excellent alba_migration gem, which handles much of this automatically. Since our application was still running on an older Ruby version, we had to roll our own solution.)

We wrote a simple "bootstrapping" script (bin/alba_bootstrap.rb) to handle the syntax-swapping drudgery.

It wasn't an AST parser or a complex transpiler. It was just simple Ruby string manipulation:

# bin/alba_bootstrap.rb
def convert_file(file_path)
  content = File.read(file_path)

  # 1. Swap Inheritance for Include
  content.gsub!(/< ActiveModel::Serializer/, '')
  content.sub!(/class (.*?)(\n|$)/) { "class #{$1}\n  include Alba::Resource\n" }

  # 2. Convert Associations
  content.gsub!(/has_many/, 'many')
  content.gsub!(/has_one/, 'one')

  # 3. Prompt for Manual Logic Review
  content.gsub!(/def (.*?)\n(.*?)\n  end/m) do |match|
    "# TODO: Convert method '#{$1}' to attribute block\n#{match.gsub(/^/, '# ')}"
  end
  File.write(file_path, content)
end

This script didn't produce perfect code, but it got us 80% of the way there. It handled the boilerplate, leaving us to focus on the interesting parts: converting complex custom methods into Alba's clean attribute blocks.

Conclusion

Leaving ActiveModel::Serializers feels like leaving an old apartment. It had its quirks, but it was home.

However, the move to Alba has been a breath of fresh air. We traded a complex, unmaintained caching strategy for raw, highly optimized serialization throughput. The code is cleaner, the benchmarks are solid, and we sleep better knowing our API layer is future-proof.

If you are still holding onto AMS because "it works," I highly recommend creating a benchmark with your heaviest model and giving Alba a spin. You might find that you don't need that cache as much as you thought.

Rails Removed Email Obfuscation. Here's How I Brought It Back with Stimulus

Syed Aslam — Thu, 08 Jan 2026 14:10:00 +0000

I recently needed to add a simple contact email to my footer. It sounds trivial: just use a mailto: link, right? But in 2024, putting a raw email address in your public HTML is basically an invitation for spam.

I remembered that Rails used to handle this for us. The mail_to helper had a handy encode: "hex" option that would scramble the email address to confuse harvesters. I went to the docs, ready to use it, only to find it was removed in Rails 4.0. The suggested alternative? "Install a gem."

I didn't want to add a dependency just to render one link. And frankly, the old JavaScript-based obfuscation techniques (like document.write or eval) are now blocked by modern Content Security Policies (CSP).

So I decided to build a modern solution. I wanted the best of both worlds:

Zero Spam: The email address should effectively not exist in the DOM.
Great UX: To the user, it should behave exactly like a normal link.

Here is how I solved it using Stimulus.

The goal became simple: The email address should not exist in the DOM until the user actually asks for it.

If a bot scans the source code, it should see nothing useful. If a human hovers over the icon, it should work instantly.

This is a perfect job for Stimulus.

The Approach

Instead of writing the email into the href, we split it up and hide it in data attributes:

<a
  href="#"
  data-controller="mail-obfuscator"
  data-mail-obfuscator-user-value="hello"
  data-mail-obfuscator-domain-value="ayatflow.com"
>
  <!-- Icon -->
</a>

To a bot, this is a link to nowhere (#). It contains the strings "hello" and "ayatflow.com", but without the @ or the mailto: context, it's just noise.

The Magic (Stimulus Controller)

We need a controller that assembles these pieces only when the user interacts with the link.

// app/javascript/controllers/mail_obfuscator_controller.js
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  static values = { user: String, domain: String };

  connect() {
    // Ensure it's dead on arrival
    this.element.href = "#";
  }

  reveal() {
    // Assemble only when needed
    this.element.href = `mailto:${this.userValue}@${this.domainValue}`;
  }

  reset() {
    // Cover your tracks
    this.element.href = "#";
  }
}

The Ruby Helper

To make this reusable, I wrapped it in a helper that feels just like the old mail_to:

# app/helpers/application_helper.rb
def obfuscated_mail_to(email, options = {}, &block)
  user, domain = email.split('@')

  options[:data] ||= {}
  options[:data].merge!(
    controller: "mail-obfuscator",
    mail_obfuscator_user_value: user,
    mail_obfuscator_domain_value: domain,
    # The secret sauce: Trigger on everything
    action: "mouseover->mail-obfuscator#reveal focus->mail-obfuscator#reveal mouseout->mail-obfuscator#reset blur->mail-obfuscator#reset click->mail-obfuscator#reveal"
  )
  options[:href] ||= "#"

  link_to(options[:href], options, &block)
end

The "Reset" Trick

You might notice the reset() action mapped to mouseout and blur.

This is my favorite part. As soon as your mouse leaves the link, it reverts back to href="#". If you try to "Right Click -> Copy Link Address" without hovering directly (or if you move your mouse away too fast), you get nothing.

It makes the window of opportunity for scraping extremely small, without impacting the UX for a genuine user who just wants to say hello.

Conclusion

Sometimes the best solutions aren't about complex encryption, but just being a little bit slippery. This approach is lightweight, CSP-compliant, and keeps my inbox just a little bit cleaner.

Code is available in this Gist.

Formatting ActiveSupport::Duration Objects in Rails

Syed Aslam — Sun, 17 Aug 2025 00:00:00 +0000

Rails’ ActiveSupport::Duration objects don’t include a straightforward way to output clean, human-readable strings. By default, you’re left with #inspect, which is limited and lost locale support after Rails 5.1.

A Manual Helper

You could roll your own helper in a view:

def duration_as_sentence(duration)
  parts = duration.parts
  units = [:days, :hours, :minutes]
  map   = {
    days:    { one: :d },
    hours:   { one: :h, other: :hrs },
    minutes: { one: :m, other: :mins }
  }

  parts.
    sort_by { |unit, _| units.index(unit) }.
    map { |unit, val| "#{val} #{val == 1 ? map[unit][:one] : map[unit][:other]}" }.
    to_sentence
end

This works, but it’s limited, not very configurable, and ignores localization.

Introducing duration_in_words

To address this, I built a small gem called duration_in_words.
It provides a view helper that formats ActiveSupport::Duration objects into concise, localized strings like:

include ActionView::Helpers::DurationHelper

>> duration = 2.hours
>> duration_in_words(duration)
=> "2h"

>> duration = 1.day + 2.hours + 30.minutes
>> duration_in_words(duration)
=> "1d 2h and 30m"

Formatting Options

:format option

Two formats are supported: :compact (default) and :full.

de:
  duration:
    in_words:
      format:
        compact:
          hours:
            one: "%{count}Std."
            other: "%{count}Std."
          minutes:
            one: "%{count}Min"
            other: "%{count}Min"
          seconds:
            one: "%{count}s"
            other: "%{count}s"
          support:
            words_connector: " "
            two_words_connector: " und "
            last_word_connector: " und "

Usage:

duration = 1.day + 2.hours + 30.minutes

duration_in_words(duration, locale: :de)
# => "1T 2Std. und 30s"

duration_in_words(duration, format: :full, locale: :de)
# => "1 Tag, 2 Std., und 30 Sekunden"

Wrap-up

When you need to report durations in a user-friendly way, duration_in_words provides a clean, configurable, and locale-aware solution. It’s a big improvement over the default #inspect output and saves you from reinventing formatting helpers.

DEV Community: Syed Aslam

Git Worktrees: Multiple Branches Without the Checkout Shuffle

The mental model

A simple example

Inspecting active worktrees

What is shared and what is isolated?

The most important restriction

Why worktrees are useful for stacked pull requests

A reusable stacked-branch setup

Parallel testing and investigation

Merging a worktree's branch back

Removing a worktree safely

Worktrees are not clones

A note on project layout: Bare repositories

Practical safety rules

Final takeaway

Why present? Can Hide SQL in Rails

Why this is easy to miss

Where this becomes expensive

What is happening under the hood

What to write instead

This is bigger than present?

The habit that helps

present? and the Hidden Query Boundary

When ||= Betrays Your Memoization

The subtle behavior

How this causes confusion over time

Why this happens

Safer patterns

The broader lesson

References

Stimulus Is Boring — and That’s Why It Works

Escaping the AMS Trap: How We Benchmarked Our Way to Alba

The Contenders

ActiveModel::Serializers (The Incumbent)

Blueprinter

Alba

The Benchmark: Real World Data, Not "Hello World"

The Code

The Results

The "Caching" Elephant in the Room

The Decision: Why We Chose Alba

1. Speed Without Complexity

2. The Oj Factor

3. Safety and Maintenance

The Caching Gap (and How We Fixed It)

The Solution: A Lightweight Concern

Automating the Migration

Conclusion

Rails Removed Email Obfuscation. Here's How I Brought It Back with Stimulus

The Approach

The Magic (Stimulus Controller)

The Ruby Helper

The "Reset" Trick

Conclusion

Formatting ActiveSupport::Duration Objects in Rails

A Manual Helper

Introducing duration_in_words

Formatting Options

Wrap-up

This is bigger than `present?`