DEV Community: Syed Aslam

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.