Part 3 – Passenger, Nginx and the Request Lifecycle (deep dive)

Overview / Goal

In Part 3 we explain how Passenger sits behind Nginx in an API-only Rails app, where caching belongs in the stack, how to safely cache API responses (or avoid caching sensitive ones), and how to verify behavior. This part covers Passenger role, request lifecycle, and API response caching strategy.


1) Passenger’s role in a Rails API app โ€” what it is and how it plugs into Nginx

What is Passenger?
Passenger (Phusion Passenger) is an application server that runs Ruby apps (Rails) and integrates tightly with web servers such as Nginx. It manages application processes, handles spawning, lifecycle, zero-downtime restarts, and serves Rack apps directly without a separate reverse-proxy layer.

Why using Passenger in your stack matters:

  • Nginx serves static files directly (fast).
  • If a request cannot be served as a static file, Nginx hands it to Passenger, which invokes your Rails app (API).
  • Passenger takes care of Ruby processes, workers, memory limits, restarts, etc., reducing operational complexity compared to orchestrating your own Puma cluster + systemd.

Typical nginx + passenger snippet (conceptual)

server {
  listen 443 ssl http2;
  server_name api.mydomain.com www.mydomain.com;
  root /apps/mydomain/current/public;

  passenger_enabled on;
  passenger_ruby /apps/mydomain/shared/ruby;
  passenger_min_instances 2;
  passenger_max_pool_size 6;
  passenger_preload_bundler on;

  # static + caching rules here ...
  location / {
    # fallback: handover to passenger (Rails)
    passenger_enabled on;
  }
}

Passenger is enabled per-server or per-location. Static files under root are resolved by nginx first โ€” Passenger only gets requests that do not map to files (or that you explicitly route to Passenger).


2) Request lifecycle (browser โ†’ Nginx โ†’ Passenger โ†’ Rails API)

A canonical sequence for a request to your site:

  1. Browser requests https://www.mydomain.com/some/path (or /vite/index-ABC.js, or /api/v1/products).
  2. Nginx checks if the request maps to a static file under root /apps/mydomain/current/public.
    • If file exists โ†’ serve it directly and attach headers (Cache-Control, etc.).
    • If not โ†’ pass the request to Passenger.
  3. Passenger receives the request and dispatches it to a Rails process.
  4. Rails API processes the request (controllers -> models -> DB) and produces a response JSON or status.
  5. Rails returns the response to Passenger โ†’ Passenger returns it to Nginx โ†’ Nginx returns it to the browser.

Key layers where caching can occur:

  • Client-side (browser) โ€” controlled by Cache-Control returned from server.
  • Reverse-proxy or CDN โ€” e.g., Cloudflare, Fastly, CloudFront; caching behavior influenced by s-maxage and surrogate headers.
  • Application caching (Rails/Redis) โ€” memoization or precomputed JSON payloads to reduce DB cost.
  • Nginx (edge) caching โ€” possible for static assets; less common for dynamic Rails responses when using Passenger (but possible with proxying setups).

3) Where API caching should sit (principles)

Because your Rails app is API-only, you should carefully control caching:

  • Static assets (JS/CSS/fonts/images) = Nginx (1-year for hashed assets).
  • API responses (JSON) = usually short-lived or uncached unless content is highly cacheable and non-sensitive. If cached:
    • Prefer caching at CDN layer (s-maxage) or using application-level caching (Rails + Redis).
    • Use cache validation (ETag, Last-Modified) to enable conditional requests and 304 responses.
  • Sensitive endpoints (auth, user-specific data) = never cached publicly. Use Cache-Control: no-store, private.

4) Cache-Control and related headers for APIs โ€” recommended practices

Important response headers and their recommended usage

  • Cache-Control:
    • no-store โ€” do not store response anywhere (safest for sensitive data).
    • no-cache โ€” caches may store but must revalidate with origin before use (useful if you want caching but require revalidation).
    • private โ€” response intended for a single user; shared caches (CDNs) must not store it.
    • public โ€” response may be stored by browsers and CDNs.
    • max-age=SECONDS โ€” TTL in seconds.
    • s-maxage=SECONDS โ€” TTL for shared caches (CDNs); supersedes max-age for shared caches.
    • must-revalidate / proxy-revalidate โ€” force revalidation after expiration.
    • stale-while-revalidate / stale-if-error โ€” allow stale responses while revalidation or in case of errors (good for resilience).
  • ETag:
    • Strong validator; server generates a value representing resource state. Client includes If-None-Match on subsequent requests. Server returns 304 Not Modified if ETag matches.
  • Last-Modified and If-Modified-Since:
    • Based on timestamp; less precise than ETag but simple.
  • Vary:
    • Tells caches that responses vary by certain request headers (e.g., Vary: Accept-Encoding or Vary: Authorization).

Example header patterns

  • Public, CDN cacheable API (e.g., public product listings): Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=30 ETag: "abc123" Vary: Accept-Encoding
    • Browser caches for 60s. CDN caches for 300s. Meanwhile allow stale while revalidate.
  • User-specific / sensitive responses: Cache-Control: private, no-store, no-cache, must-revalidate
    • Prevents sharing.
  • No caching (strict): Cache-Control: no-store

5) How to add caching headers in a Rails API controller (practical examples)

Because you run an API-only app, prefer setting headers in controllers selectively for GET endpoints you consider safe to cache.

Basic manual header (safe and explicit):

class Api::V1::ProductsController < ApplicationController
  def index
    @products = Product.popular.limit(20)
    # set short-lived cache for 60 seconds for browsers
    response.set_header('Cache-Control', 'public, max-age=60, s-maxage=300, stale-while-revalidate=30')
    render json: @products
  end
end

Using conditional GET with ETag / Last-Modified:

class Api::V1::ProductsController < ApplicationController
  def show
    product = Product.find(params[:id])
    # This helps return 304 Not Modified if product hasn't changed
    if stale?(etag: product, last_modified: product.updated_at)
      render json: product
    end
  end
end

Notes: stale? and fresh_when are provided by ActionController::ConditionalGet. In an API-only app these helper methods are normally available, but confirm by checking your ApplicationController inheritance; if not, you can use response.set_header('ETag', ...) directly.

Setting ETag manually:

etag_value = Digest::SHA1.hexdigest(product.updated_at.to_i.to_s + product.id.to_s)
response.set_header('ETag', "\"#{etag_value}\"")
# then Rails will respond with 304 if If-None-Match matches


6) Important rules for API caching

  • Only cache GET responses. Never cache responses to POST, PUT, PATCH, DELETE.
  • Do not cache user-specific or sensitive info in shared caches. Use private or no-store.
  • Prefer CDN caching (s-maxage) for public endpoints. Use s-maxage to instruct CDNs to keep content longer than browsers.
  • Use ETags or Last-Modified for validation to reduce bandwidth and get 304 responses.
  • Consider short TTLs and stale-while-revalidate to reduce origin load while keeping content fresh.
  • Version your API (e.g., /api/v1/) so you can change caching behavior on new releases without conflicting with old clients.

7) Nginx + Passenger and caching for API endpoints โ€” what to do (and what to avoid)

  • Avoid using Nginx proxy cache with Passenger by default. Passenger is not a reverse proxy; it’s an app server. Nginx can use proxy_cache for caching upstream responses, but that pattern is more common when you proxy to a separate Puma/Unicorn backend via proxy_pass. With Passenger, it’s simpler and safer to set cache headers in Rails and let CDNs or clients respect them.
  • If you want edge caching in Nginx, it is technically possible to enable fastcgi_cache/proxy_cache patterns if you have an upstream; use caution โ€” caching dynamic JSON responses at the web server is tricky and must be carefully invalidated.

Recommended: set caching headers in Rails (as shown), then let a CDN (Cloudflare/Fastly/CloudFront) apply caching and invalidation; Passenger remains the process manager for Rails.


8) Example: making a public, cacheable endpoint safe and CDN-friendly

class Api::V1::PublicController < ApplicationController
  def top_offers
    data = Offer.top(10) # expensive query
    response.set_header('Cache-Control', 'public, max-age=120, s-maxage=600, stale-while-revalidate=30')
    # Optionally set ETag
    fresh_when(etag: Digest::SHA1.hexdigest(data.map(&:updated_at).join(',')))
    render json: data
  end
end

  • max-age=120 โ†’ browsers cache for 2 minutes
  • s-maxage=600 โ†’ CDN caches for 10 minutes
  • stale-while-revalidate=30 โ†’ CDN/browsers may serve stale for 30s while origin revalidates

9) Passenger vs Puma โ€” quick comparison (for API deployments)

Passenger

  • Pros:
    • Tight nginx integration (simpler config).
    • Auto-manages application processes; zero-downtime restarts are straightforward (passenger-config restart-app).
    • Good defaults for concurrency and memory management.
  • Cons:
    • Less flexible for custom proxy patterns (compared to running Puma behind nginx).
    • Some advanced caching/proxy setups are easier with a dedicated reverse-proxy architecture.

Puma (common alternative)

  • Pros:
    • Lightweight, highly configurable; often used behind nginx as reverse proxy.
    • Works well in containerized environments (Docker/Kubernetes).
    • Easy to pair with systemd or process managers and to horizontally scale workers.
  • Cons:
    • Requires extra process management & reverse proxying (nginx proxy_pass) configuration.
    • Slightly more operational overhead vs Passenger.

For an API-only Rails app with static assets served by nginx, Passenger is a great choice when you want fewer moving pieces. Puma + nginx gives more flexibility if you need advanced proxy caching or plan to run in a container orchestration platform.

I’ll continue with Part 4 covering Redis caching (optional), invalidation strategies, testing, debugging, commands, examples of common pitfalls and a final checklist.


Part 2: Caching Strategy for Vue + Rails API with Nginx

In Part 1, we explored the request flow between Nginx, Vue (frontend), and Rails (API backend). We also covered how Nginx routes traffic and why caching matters in such a setup.

Now in Part 2, we’ll go deeper into asset caching strategies โ€” specifically tailored for a Rails API-only backend + Vue frontend deployed with Nginx.

๐Ÿ”‘ The Core Idea

  • HTML files (like vite.html) should never be cached. They are the entry point of the SPA and change frequently.
  • Hashed assets (like /vite/index-G34XebCm.js) can be cached for 1 year safely, because the hash ensures cache-busting.
  • Non-hashed assets (images, fonts, legacy JS/CSS) should get short-term caching (e.g., 1 hour).

This split ensures fast repeat visits while avoiding stale deploys.

๐Ÿ“‚ Example: Files in public/vite/

Your build pipeline (via Vite) outputs hashed assets like:

vite/
  index-G34XebCm.js
  DuckType-CommonsRegular-CSozX1Vl.otf
  Allergens-D48ns5vN.css
  LoginModal-DR9oLFAS.js

Notice the random-looking suffixes (G34XebCm, D48ns5vN) โ€” these are hashes. They change whenever the file content changes.

โžก๏ธ That’s why they’re safe to cache for 1 year: a new deploy creates new filenames, so the browser will fetch fresh assets.

By contrast, files like:

assets/
  15_minutes.png
  Sky_background.png

do not have hashes. If you update them, the filename doesn’t change, so the browser might keep showing stale content if cached too long. These need shorter cache lifetimes.


๐Ÿ› ๏ธ Final Nginx Caching Configuration

Here’s the Nginx cache snippet tuned for your setup:

# =====================
# HTML (always no-cache)
# =====================
location = /vite.html {
    add_header Cache-Control "no-cache";
}

location ~* \.html$ {
    add_header Cache-Control "no-cache";
}

# ==============================
# Hashed Vue/Vite assets (1 year)
# ==============================
location ^~ /vite/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# ==================================================
# Other static assets (non-hashed) - 1 hour caching
# ==================================================
location ~* \.(?:js|css|woff2?|ttf|otf|eot|jpg|jpeg|png|gif|svg|ico)$ {
    add_header Cache-Control "public, max-age=3600";
}

๐Ÿ” Explanation

  • location = /vite.html โ†’ explicitly disables caching for the SPA entry file.
  • location ~* \.html$ โ†’ covers other .html files just in case.
  • location ^~ /vite/ โ†’ everything inside /vite/ (all hashed JS/CSS/images/fonts) gets 1 year caching.
  • Final block โ†’ fallback for other static assets like /assets/*.png, with only 1-hour cache.

โš ๏ธ What Happens If We Misconfigure?

  • If you cache .html โ†’ new deploys wonโ€™t show up, users may stay stuck on the old app shell.
  • If you cache non-hashed images for 1 year โ†’ product images may stay stale even after updates.
  • If you donโ€™t use immutable on hashed assets โ†’ browsers may still revalidate unnecessarily.

๐Ÿ—๏ธ Real-World Examples

  • GitLab uses a similar strategy with hashed Webpack assets, caching them long-term via Nginx and Cloudflare.
  • Discourse does long-term caching of fingerprinted JS/CSS, but keeps HTML dynamic with no-cache.
  • Basecamp (Rails + Hotwire) fingerprints all assets, leveraging 1-year immutable caching.

These projects rely heavily on content hashing + Nginx headers โ€” exactly what we’re setting up here.

โœ… Best Practices Recap

  1. Always fingerprint (hash) assets in production builds.
  2. Cache HTML for 0 seconds, JS/CSS hashed files for 1 year.
  3. Use immutable for hashed assets.
  4. Keep non-hashed assets on short lifetimes or rename them when updated.

This ensures smooth deploys, lightning-fast repeat visits, and no stale content issues.

๐Ÿ“Œ In Part 3, we’ll go deeper into Rails + Passenger integration, showing how Rails API responses fit into this caching strategy (and what not to cache at the API layer).


The Complete Guide to Rails Database Commands: From Basics to Production

Managing databases in Rails can seem overwhelming with all the available commands. This comprehensive guide will walk you through every essential Rails database command, from basic operations to complex real-world scenarios.

Basic Database Commands

Core Database Operations

# Create the database
rails db:create

# Drop (delete) the database
rails db:drop

# Run pending migrations
rails db:migrate

# Rollback the last migration
rails db:rollback

# Rollback multiple migrations
rails db:rollback STEP=3

Schema Management

# Load current schema into database
rails db:schema:load

# Dump current database structure to schema.rb
rails db:schema:dump

# Load structure from structure.sql (for complex databases)
rails db:structure:load

# Dump database structure to structure.sql
rails db:structure:dump

Seed Data

# Run the seed file (db/seeds.rb)
rails db:seed

Combined Commands: The Powerhouses

rails db:setup

What it does: Sets up database from scratch

rails db:setup

Equivalent to:

rails db:create
rails db:schema:load  # Loads from schema.rb
rails db:seed

When to use:

  • First time setting up project on new machine
  • Fresh development environment
  • CI/CD pipeline setup

rails db:reset

What it does: Nuclear option – completely rebuilds database

rails db:reset

Equivalent to:

rails db:drop
rails db:create
rails db:schema:load
rails db:seed

When to use:

  • Development when you want clean slate
  • After major schema changes
  • When your database is corrupted

โš ๏ธ Warning: Destroys all data!

rails db:migrate:reset

What it does: Rebuilds database using migrations

rails db:migrate:reset

Equivalent to:

rails db:drop
rails db:create
rails db:migrate  # Runs all migrations from scratch

When to use:

  • Testing that migrations run cleanly
  • Debugging migration issues
  • Ensuring migration sequence works

Advanced Database Commands

Migration Management

# Rollback to specific migration
rails db:migrate:down VERSION=20240115123456

# Re-run specific migration
rails db:migrate:up VERSION=20240115123456

# Get current migration version
rails db:version

# Check migration status
rails db:migrate:status

Database Information

# Show database configuration
rails db:environment

# Validate database and pending migrations
rails db:abort_if_pending_migrations

# Check if database exists
rails db:check_protected_environments

Environment-Specific Commands

# Run commands on specific environment
rails db:create RAILS_ENV=production
rails db:migrate RAILS_ENV=staging
rails db:seed RAILS_ENV=test

Real-World Usage Scenarios

Scenario 1: New Developer Onboarding

# New developer joins the team
git clone project-repo
cd project
bundle install

# Set up database
rails db:setup

# Or if you prefer running migrations
rails db:create
rails db:migrate
rails db:seed

Scenario 2: Production Deployment

# Safe production deployment
rails db:migrate RAILS_ENV=production

# Never run these in production:
# rails db:reset        โŒ Will destroy data!
# rails db:schema:load  โŒ Will overwrite everything!

Scenario 3: Development Workflow

# Daily development cycle
git pull origin main
rails db:migrate          # Run any new migrations

# If you have conflicts or issues
rails db:rollback         # Undo last migration
# Fix migration file
rails db:migrate          # Re-run

# Major cleanup during development
rails db:reset           # Nuclear option

Scenario 4: Testing Environment

# Fast test database setup
rails db:schema:load RAILS_ENV=test

# Or use the test-specific command
rails db:test:prepare

Environment-Specific Best Practices

Development Environment

# Liberal use of reset commands
rails db:reset              # โœ… Safe to use
rails db:migrate:reset      # โœ… Safe to use
rails db:setup              # โœ… Safe for fresh start

Staging Environment

# Mirror production behavior
rails db:migrate RAILS_ENV=staging  # โœ… Recommended
rails db:seed RAILS_ENV=staging     # โœ… If needed

# Avoid
rails db:reset RAILS_ENV=staging    # โš ๏ธ Use with caution

Production Environment

# Only safe commands
rails db:migrate RAILS_ENV=production     # โœ… Safe
rails db:rollback RAILS_ENV=production    # โš ๏ธ With backup

# Never use in production
rails db:reset RAILS_ENV=production       # โŒ NEVER!
rails db:drop RAILS_ENV=production        # โŒ NEVER!
rails db:schema:load RAILS_ENV=production # โŒ NEVER!

Pro Tips and Gotchas

Migration vs Schema Loading

# For existing databases with data
rails db:migrate          # โœ… Incremental, safe

# For fresh databases
rails db:schema:load      # โœ… Faster, clean slate

Data vs Schema

Remember that some operations preserve data differently:

  • db:migrate: Preserves existing data, applies incremental changes
  • db:schema:load: Loads clean schema, no existing data
  • db:reset: Destroys everything, starts fresh

Common Workflow Commands

# The "fix everything" development combo
rails db:reset && rails db:migrate

# The "fresh start" combo  
rails db:drop db:create db:migrate db:seed

# The "production-safe" combo
rails db:migrate db:seed

Quick Reference Cheat Sheet

CommandUse CaseData SafetySpeed
db:migrateIncremental updatesโœ… SafeMedium
db:setupInitial setupโœ… Safe (new DB)Fast
db:resetClean slateโŒ Destroys allFast
db:migrate:resetTest migrationsโŒ Destroys allSlow
db:schema:loadFresh schemaโŒ No data migrationFast
db:seedAdd sample dataโœ… AdditiveFast

Conclusion

Understanding Rails database commands is crucial for efficient development and safe production deployments. Start with the basics (db:create, db:migrate, db:seed), get comfortable with the combined commands (db:setup, db:reset), and always remember the golden rule: be very careful with production databases!

The key is knowing when to use each command:

  • Development: Feel free to experiment with db:reset and friends
  • Production: Stick to db:migrate and always have backups
  • Team collaboration: Use migrations to keep everyone in sync

Remember: migrations tell the story of how your database evolved, while schema files show where you ended up. Both are important, and now you know how to use all the tools Rails gives you to manage them effectively.


The Complete Guide to Cookie Storage in Rails 7: Security, Performance, and Best Practices

Cookies are fundamental to web applications, but choosing the right storage method can make or break your app’s security and performance. Rails 7 offers multiple cookie storage mechanisms, each with distinct security properties and use cases. Let’s explore when to use each approach and why it matters.

The Cookie Storage Spectrum

Rails provides four main cookie storage methods, each offering different levels of security:

# 1. Plain cookies - readable and modifiable by client
cookies[:theme] = 'dark'

# 2. Signed cookies - readable but tamper-proof
cookies.signed[:discount_code] = 'SAVE10'

# 3. Encrypted cookies - hidden and tamper-proof
cookies.encrypted[:user_preferences] = { notifications: true }

# 4. Session storage - server-side with encrypted session cookie
session[:current_user_id] = user.id

1. Plain Cookies: When Transparency is Acceptable

Use for: Non-sensitive data where client-side reading/modification is acceptable or even desired.

# Setting a plain cookie
cookies[:theme] = 'dark'
cookies[:language] = 'en'
cookies[:consent_given] = 'true'

# With expiration
cookies[:temporary_banner_dismissed] = {
  value: 'true',
  expires: 1.day.from_now
}

Security implications:

  • โœ… Fast and simple
  • โŒ Completely readable in browser dev tools
  • โŒ User can modify values freely
  • โŒ No protection against tampering

Best for:

  • UI preferences (theme, language)
  • Non-critical flags (banner dismissal)
  • Data you want JavaScript to access easily

2. Signed Cookies: Tamper-Proof but Visible

Signed cookies prevent modification while remaining readable. Rails uses HMAC-SHA1 with your secret_key_base to create a cryptographic signature.

# Setting signed cookies
cookies.signed[:discount_code] = 'SAVE10'
cookies.signed[:referral_source] = 'google_ads'

# Reading signed cookies
discount = cookies.signed[:discount_code]  # Returns 'SAVE10' or nil if tampered

How it works:

# Rails internally does:
# 1. Create signature: HMAC-SHA1(secret_key_base, 'SAVE10')
# 2. Store: Base64.encode64('SAVE10--signature')
# 3. On read: verify signature matches content

Security implications:

  • โœ… Tamper-proof – modification invalidates the cookie
  • โœ… Prevents privilege escalation attacks
  • โš ๏ธ Content still visible (Base64 encoded)
  • โŒ Not suitable for truly sensitive data

Real-world example from our codebase:

# lib/session/cookie_discount_accessor.rb
def discount_code
  # Prevents users from changing 'SAVE10' to 'SAVE50' in browser
  @cookies.signed[:discount] && DiscountCode.find_by(name: @cookies.signed[:discount])
end

def set_discount_code(code)
  @cookies.signed[:discount] = {
    value: code.name,
    expires: code.expiration || 30.days.from_now
  }
end

Best for:

  • Discount codes
  • Referral tracking
  • Non-sensitive IDs that shouldn’t be modified
  • Data integrity without confidentiality requirements

3. Encrypted Cookies: Maximum Security

Encrypted cookies are both signed and encrypted, making them unreadable and tamper-proof.

# Setting encrypted cookies
cookies.encrypted[:credit_card_last4] = '4242'
cookies.encrypted[:user_preferences] = {
  notifications: true,
  marketing_emails: false
}

# Reading encrypted cookies
preferences = cookies.encrypted[:user_preferences]

Security implications:

  • โœ… Content completely hidden from client
  • โœ… Tamper-proof
  • โœ… Suitable for sensitive data
  • โš ๏ธ Slightly higher CPU overhead
  • โš ๏ธ Size limitations (4KB total per domain)

Best for:

  • Personal information
  • Financial data
  • Complex user preferences
  • Any data you’d store in a database but need client-side

4. Session Storage: Server-Side Security

Rails sessions are encrypted cookies by default, but the data is conceptually server-side.

# Session storage
session[:current_user_id] = user.id
session[:shopping_cart] = cart.to_h
session[:two_factor_verified] = true

# Configuration in config/application.rb
config.session_store :cookie_store, key: '_myapp_session'

Security implications:

  • โœ… Encrypted by default
  • โœ… Automatic expiration handling
  • โœ… CSRF protection integration
  • โš ๏ธ 4KB size limit
  • โš ๏ธ Lost on cookie deletion

Best for:

  • User authentication state
  • Shopping carts
  • Multi-step form data
  • Security-sensitive flags

Security Best Practices

1. Choose the Right Storage Method

# โŒ Don't store sensitive data in plain cookies
cookies[:ssn] = '123-45-6789'  # Visible to everyone!

# โœ… Use appropriate security level
cookies.encrypted[:ssn] = '123-45-6789'  # Hidden and protected
session[:user_id] = user.id              # Server-side, encrypted

2. Set Proper Cookie Attributes

# Secure cookies for HTTPS
cookies[:theme] = {
  value: 'dark',
  secure: Rails.env.production?,  # HTTPS only
  httponly: true,                 # No JavaScript access
  samesite: :strict              # CSRF protection
}

3. Handle Cookie Tampering Gracefully

def current_discount_code
  code_name = cookies.signed[:discount]
  return nil unless code_name

  DiscountCode.find_by(name: code_name)&.tap do |code|
    # Remove if expired or invalid
    cookies.delete(:discount) unless code.usable?
  end
end

4. Use Expiration Strategically

# Short-lived sensitive data
cookies.signed[:password_reset_token] = {
  value: token,
  expires: 15.minutes.from_now,
  secure: true,
  httponly: true
}

# Long-lived preferences
cookies.encrypted[:user_preferences] = {
  value: preferences.to_json,
  expires: 1.year.from_now
}

Advanced Patterns

1. Cookie Accessor Classes

Create dedicated classes for complex cookie management:

class Session::CookieDiscountAccessor
  def initialize(cookies)
    @cookies = cookies
  end

  def discount_code
    @cookies.signed[:discount] && DiscountCode.find_by(name: @cookies.signed[:discount])
  end

  def set_discount_code(code)
    @cookies.signed[:discount] = {
      value: code.name,
      expires: code.expiration || 30.days.from_now
    }
  end

  def remove_discount_code
    @cookies.delete(:discount)
  end
end

2. Validation and Cleanup

class Session::CheckAndRemoveDiscountCode
  def initialize(cookies:)
    @accessor = Session::CookieDiscountAccessor.new(cookies)
  end

  def run
    # Remove referral conflicts
    @accessor.referral_code && @accessor.remove_discount_code && return
      
    # Remove expired codes
    discount_code = @accessor.discount_code
    @accessor.remove_discount_code if discount_code && !discount_code.usable?
  end
end

3. Error Handling for Corrupted Cookies

def safe_read_encrypted_cookie(key)
  cookies.encrypted[key]
rescue ActiveSupport::MessageVerifier::InvalidSignature,
       ActiveSupport::MessageEncryptor::InvalidMessage
  # Cookie was corrupted or created with different secret
  cookies.delete(key)
  nil
end

Performance Considerations

Cookie Size Limits

  • Total limit: 4KB per domain
  • Individual limit: ~4KB per cookie
  • Count limit: ~50 cookies per domain

CPU Overhead

# Benchmark different storage methods
require 'benchmark'

Benchmark.bm do |x|
  x.report("plain")     { 1000.times { cookies[:test] = 'value' } }
  x.report("signed")    { 1000.times { cookies.signed[:test] = 'value' } }
  x.report("encrypted") { 1000.times { cookies.encrypted[:test] = 'value' } }
end

# Results (approximate):
#                user     system      total        real
# plain      0.001000   0.000000   0.001000 (  0.001000)
# signed     0.010000   0.000000   0.010000 (  0.009000)
# encrypted  0.050000   0.000000   0.050000 (  0.048000)

Configuration and Security Headers

Session Configuration

# config/application.rb
config.session_store :cookie_store,
  key: '_myapp_session',
  secure: Rails.env.production?,
  httponly: true,
  expire_after: 14.days,
  same_site: :lax

Security Headers

# config/application.rb
config.force_ssl = true  # HTTPS in production

# Use Secure Headers gem
SecureHeaders::Configuration.default do |config|
  config.cookies = {
    secure: true,
    httponly: true,
    samesite: {
      lax: true
    }
  }
end

Testing Cookie Security

# spec/lib/session/coupon_code_spec.rb
RSpec.describe Session::CouponCode do
  describe 'cookie tampering protection' do
    it 'handles corrupted signed cookies gracefully' do
      # Simulate tampered cookie
      cookies.signed[:discount] = 'SAVE10'
      cookies[:discount] = 'tampered_value'  # Direct manipulation

      accessor = Session::CookieDiscountAccessor.new(cookies)
      expect(accessor.discount_code).to be_nil
    end
  end
end

Migration Strategies

Upgrading Cookie Security

def upgrade_cookie_security
  # Read from old plain cookie
  if (old_value = cookies[:legacy_data])
    # Migrate to encrypted
    cookies.encrypted[:legacy_data] = old_value
    cookies.delete(:legacy_data)
  end
end

Handling Secret Key Rotation

# config/credentials.yml.enc
secret_key_base: new_secret
legacy_secret_key_base: old_secret

# In application
def read_with_fallback(key)
  cookies.encrypted[key] || begin
    # Try with old secret
    old_verifier = ActiveSupport::MessageEncryptor.new(
      Rails.application.credentials.legacy_secret_key_base
    )
    old_verifier.decrypt_and_verify(cookies[key])
  rescue
    nil
  end
end

Quick Decision Matrix

Data TypeSensitivityClient Access NeededRecommended Storage
Theme preferencesLowYesPlain cookies
Discount codesMediumNoSigned cookies
User settingsMediumNoEncrypted cookies
AuthenticationHighNoSession
Credit card dataHighNoDatabase + session ID
Shopping cartMediumNoSession or encrypted
CSRF tokensHighLimitedSession (built-in)

Common Pitfalls to Avoid

  1. Don’t mix storage types for the same data
   # โŒ Inconsistent
   cookies[:user_id] = user.id        # Sometimes
   cookies.signed[:user_id] = user.id # Other times

   # โœ… Consistent
   session[:user_id] = user.id        # Always
  1. Don’t store large objects in cookies
   # โŒ Will hit 4KB limit
   cookies.encrypted[:full_user] = user.to_json

   # โœ… Store reference
   session[:user_id] = user.id
  1. Don’t forget expiration
   # โŒ Never expires
   cookies.signed[:temp_token] = token

   # โœ… Proper expiration
   cookies.signed[:temp_token] = {
     value: token,
     expires: 1.hour.from_now
   }

Conclusion

Cookie storage in Rails 7 offers a rich toolkit for different security and performance needs. The key is matching the storage method to your data’s sensitivity and access patterns:

  • Plain cookies for non-sensitive, client-accessible data
  • Signed cookies when you need tamper protection but not confidentiality
  • Encrypted cookies for sensitive data that must remain client-side
  • Session storage for server-side state with automatic encryption

Remember: the best cookie strategy combines appropriate storage methods with proper security headers, validation, and graceful error handling. When in doubt, err on the side of more security rather than less.

The Rails cookie system is designed to make secure defaults easyโ€”take advantage of it to build applications that are both performant and secure.


Ruby Meta-programming: Understanding class_eval, instance_eval, eval, define_method, and method_missing

๐Ÿ” Introduction

Ruby’s meta-programming capabilities let you write code that writes code, opening doors to DSLs (Check my post on DSL), dynamic behaviours, and DRY abstractions. In this two-part series, we’ll explore:

  • Part 1: class_eval, instance_eval, eval, define_method, and method_missing
  • Part 2: Additional metaprogramming methods like define_singleton_method, module_eval, send, and more

๐Ÿท๏ธ Part 1: Core Metaprogramming Methods

๐Ÿ”จ 1. What is class_eval?

class_eval is a method that allows you to evaluate a block of code or a string within the context of a class. It’s part of Ruby’s metaprogramming toolkit and is inherited from the Module class.

Basic Syntax

class MyClass
  # class definition
end

MyClass.class_eval do
  # code executed in the context of MyClass
  def new_method
    puts "Hello from class_eval!"
  end
end

Key Features

1. Context Execution

The code inside class_eval is executed as if it were written directly inside the class definition:

class Example
  def existing_method
    puts "I exist"
  end
end

Example.class_eval do
  def dynamic_method
    puts "I was added dynamically!"
  end
end

# Now you can use the new method
obj = Example.new
obj.dynamic_method  # => "I was added dynamically!"

2. String Evaluation

You can also pass a string instead of a block:

class MyClass
end

MyClass.class_eval("def hello; puts 'Hello!'; end")

3. Access to Class Variables and Constants

The evaluated code has access to the class’s variables and constants:

class Calculator
  OPERATIONS = [:add, :subtract, :multiply, :divide]
end

Calculator.class_eval do
  OPERATIONS.each do |op|
    define_method(op) do |a, b|
      case op
      when :add then a + b
      when :subtract then a - b
      when :multiply then a * b
      when :divide then a / b
      end
    end
  end
end

Common Use Cases

1. Dynamic Method Creation

class User
  attr_accessor :name, :email
end

# Dynamically add validation methods
User.class_eval do
  [:name, :email].each do |field|
    define_method("validate_#{field}") do
      !send(field).nil? && !send(field).empty?
    end
  end
end

2. Plugin Systems

class Plugin
  def self.register(plugin_name, &block)
    class_eval(&block)
  end
end

Plugin.register(:logger) do
  def log(message)
    puts "[LOG] #{message}"
  end
end

3. Configuration DSLs

class Config
  def self.configure(&block)
    class_eval(&block)
  end
end

Config.configure do
  def database_url
    "postgresql://localhost/myapp"
  end

  def api_key
    ENV['API_KEY']
  end
end

Differences from instance_eval

  • class_eval: Executes code in the context of the class (like being inside the class definition)
  • instance_eval: Executes code in the context of an instance of the class
class Example
  def self.class_method
    puts "I'm a class method"
  end

  def instance_method
    puts "I'm an instance method"
  end
end

# class_eval - can define class methods
Example.class_eval do
  def self.new_class_method
    puts "New class method"
  end
end

# instance_eval - can define instance methods
Example.instance_eval do
  def new_instance_method
    puts "New instance method"
  end
end

Security Considerations

โš ๏ธ Warning: Using class_eval with user input can be dangerous:

# DANGEROUS - don't do this with user input
user_code = gets.chomp
MyClass.class_eval(user_code)  # Could execute malicious code

Performance Notes

  • class_eval with blocks is generally faster than with strings
  • The block version is also safer and more readable
  • Use string evaluation only when you need to evaluate dynamic code

Real-World Example

Here’s how you might use class_eval in a practical scenario:

class ActiveRecord
  def self.has_many(association_name)
    class_eval do
      define_method(association_name) do
        # Implementation for has_many association
        puts "Fetching #{association_name} for #{self.class}"
      end
    end
  end
end

class User < ActiveRecord
  has_many :posts
end

user = User.new
user.posts  # => "Fetching posts for User"

class_eval is a powerful tool for meta-programming in Ruby, allowing you to dynamically modify classes at runtime. It’s commonly used in frameworks like Rails for creating DSLs and dynamic method generation.


๐Ÿ› ๏ธ 2. What is instance_eval?

instance_eval is a method that allows you to evaluate a block of code or a string within the context of a specific object instance. It’s inherited from the BasicObject class and is available on all Ruby objects.

Basic Syntax

class MyClass
  def initialize(name)
    @name = name
  end
end

obj = MyClass.new("Alice")

obj.instance_eval do
  # code executed in the context of this specific object
  puts @name  # Can access instance variables
end

Key Features

1. Instance Context Execution

The code inside instance_eval is executed as if it were an instance method of the object:

class Person
  def initialize(name, age)
    @name = name
    @age = age
  end

  def introduce
    puts "Hi, I'm #{@name}"
  end
end

person = Person.new("Bob", 30)

person.instance_eval do
  puts "Name: #{@name}"      # => "Name: Bob"
  puts "Age: #{@age}"        # => "Age: 30"
  introduce                  # => "Hi, I'm Bob"
end

2. Access to Instance Variables

You can read and modify instance variables:

class BankAccount
  def initialize(balance)
    @balance = balance
  end
end

account = BankAccount.new(1000)

account.instance_eval do
  puts "Current balance: #{@balance}"  # => "Current balance: 1000"
  @balance += 500                      # Modify instance variable
  puts "New balance: #{@balance}"      # => "New balance: 1500"
end

3. String Evaluation

You can also pass a string instead of a block:

class Example
  def initialize(value)
    @value = value
  end
end

obj = Example.new("test")
obj.instance_eval("puts @value")  # => "test"

Common Use Cases

1. Testing Private Methods

class Calculator
  private

  def secret_calculation(x, y)
    x * y + 42
  end
end

calc = Calculator.new

# Access private method in tests
result = calc.instance_eval { secret_calculation(5, 3) }
puts result  # => 57

2. Dynamic Property Access

class Config
  def initialize
    @settings = {}
  end

  def set(key, value)
    @settings[key] = value
  end
end

config = Config.new
config.set(:api_url, "https://api.example.com")
config.set(:timeout, 30)

# Access settings dynamically
config.instance_eval do
  puts @settings[:api_url]   # => "https://api.example.com"
  puts @settings[:timeout]   # => 30
end

3. Object Inspection and Debugging

class ComplexObject
  def initialize
    @data = { a: 1, b: 2, c: 3 }
    @metadata = { created: Time.now }
  end
end

obj = ComplexObject.new

obj.instance_eval do
  puts "All instance variables:"
  instance_variables.each do |var|
    puts "#{var}: #{instance_variable_get(var)}"
  end
end

4. DSL (Domain Specific Language) Implementation

class Builder
  def initialize
    @result = []
  end

  def build(&block)
    instance_eval(&block)
    @result
  end
end

builder = Builder.new
result = builder.build do
  @result << "item1"
  @result << "item2"
  @result << "item3"
end

puts result  # => ["item1", "item2", "item3"]

Differences from class_eval

Featureinstance_evalclass_eval
ContextObject instanceClass
SelfPoints to the objectPoints to the class
Method DefinitionDefines instance methodsDefines instance methods
AccessInstance variables, private methodsClass methods, constants
class Example
  def initialize
    @value = "instance value"
  end

  @@class_var = "class variable"
end

obj = Example.new

# instance_eval - context is the object
obj.instance_eval do
  puts @value        # => "instance value"
  puts self.class    # => Example
end

# class_eval - context is the class
Example.class_eval do
  puts @@class_var   # => "class variable"
  puts self          # => Example
end

Advanced Examples

1. Method Chaining with instance_eval

class QueryBuilder
  def initialize
    @conditions = []
  end

  def where(field, value)
    @conditions << "#{field} = '#{value}'"
    self
  end

  def build
    @conditions.join(" AND ")
  end
end

query = QueryBuilder.new.instance_eval do
  where("name", "John")
  where("age", 25)
  build
end

puts query  # => "name = 'John' AND age = '25'"

2. Configuration Objects

class AppConfig
  def initialize
    @config = {}
  end

  def configure(&block)
    instance_eval(&block)
  end

  def database(url)
    @config[:database] = url
  end

  def api_key(key)
    @config[:api_key] = key
  end

  def get_config
    @config
  end
end

config = AppConfig.new
config.configure do
  database "postgresql://localhost/myapp"
  api_key ENV['API_KEY']
end

puts config.get_config

3. Object Serialization

class Serializable
  def to_hash
    result = {}
    instance_eval do
      instance_variables.each do |var|
        key = var.to_s.delete('@').to_sym
        result[key] = instance_variable_get(var)
      end
    end
    result
  end
end

class User < Serializable
  def initialize(name, email)
    @name = name
    @email = email
  end
end

user = User.new("Alice", "alice@example.com")
puts user.to_hash  # => {:name=>"Alice", :email=>"alice@example.com"}

Security Considerations

โš ๏ธ Warning: Like class_eval, using instance_eval with user input can be dangerous:

# DANGEROUS - don't do this with user input
user_code = gets.chomp
obj.instance_eval(user_code)  # Could execute malicious code

Performance Notes

  • instance_eval with blocks is faster than with strings
  • The block version is safer and more readable
  • Use string evaluation only when necessary for dynamic code

Real-World Usage

instance_eval is commonly used in:

  • Testing frameworks (RSpec, Minitest)
  • Configuration systems (Rails initializers)
  • Builder patterns (ActiveRecord queries)
  • DSL implementations (Rake tasks, Capistrano)
# RSpec example
describe User do
  it "has a name" do
    user = User.new("John")
    expect(user.instance_eval { @name }).to eq("John")
  end
end

instance_eval is a powerful tool for metaprogramming that allows you to execute code in the context of any object, making it invaluable for testing, debugging, and creating flexible APIs.


โšก 3. What is eval?

Ruby’s eval method, which is the most powerful and potentially dangerous meta-programming tool in Ruby.

eval is a method that evaluates a string as Ruby code in the current context. It’s inherited from the Kernel module and is available everywhere in Ruby. Unlike class_eval and instance_eval, eval executes code in the current binding (the current execution context).

Basic Syntax

# Basic eval usage
eval("puts 'Hello from eval!'")

# With variables
x = 10
y = 20
result = eval("x + y")
puts result  # => 30

Key Features

1. Current Context Execution

eval executes code in the current binding (local variables, methods, etc.):

def calculate(a, b, operation)
  eval("#{a} #{operation} #{b}")
end

puts calculate(10, 5, "+")   # => 15
puts calculate(10, 5, "*")   # => 50
puts calculate(10, 5, "-")   # => 5

2. Access to Local Variables

name = "Alice"
age = 25
city = "New York"

eval("puts \"#{name} is #{age} years old and lives in #{city}\"")
# => "Alice is 25 years old and lives in New York"

3. Dynamic Method Calls

class Calculator
  def add(x, y)
    x + y
  end

  def multiply(x, y)
    x * y
  end
end

calc = Calculator.new
method_name = "add"
args = [5, 3]

result = eval("calc.#{method_name}(#{args.join(', ')})")
puts result  # => 8

Common Use Cases

1. Configuration Files

# config.rb
APP_NAME = "MyApp"
DEBUG_MODE = true
DATABASE_URL = "postgresql://localhost/myapp"

# Loading configuration
config_content = File.read('config.rb')
eval(config_content)

puts APP_NAME      # => "MyApp"
puts DEBUG_MODE    # => true

2. Dynamic Calculations

class MathEvaluator
  def self.evaluate(expression)
    eval(expression)
  rescue => e
    "Error: #{e.message}"
  end
end

puts MathEvaluator.evaluate("2 + 3 * 4")        # => 14
puts MathEvaluator.evaluate("Math.sqrt(16)")    # => 4.0
puts MathEvaluator.evaluate("10 / 0")           # => "Error: divided by 0"

3. Template Processing

class Template
  def initialize(template)
    @template = template
  end

  def render(binding)
    eval("\"#{@template}\"", binding)
  end
end

template = Template.new("Hello <%= name %>, you are <%= age %> years old!")
name = "Bob"
age = 30

result = template.render(binding)
puts result  # => "Hello Bob, you are 30 years old!"

4. Code Generation

class CodeGenerator
  def self.generate_method(method_name, body)
    eval("
      def #{method_name}
        #{body}
      end
    ")
  end
end

class MyClass
  CodeGenerator.generate_method(:greet, "puts 'Hello, World!'")
  CodeGenerator.generate_method(:calculate, "2 + 2")
end

obj = MyClass.new
obj.greet        # => "Hello, World!"
puts obj.calculate  # => 4

Advanced Examples

1. Dynamic Class Creation

class DynamicClassCreator
  def self.create_class(class_name, methods = {})
    eval("
      class #{class_name}
        #{methods.map { |name, body| "def #{name}; #{body}; end" }.join("\n")}
      end
    ")
  end
end

DynamicClassCreator.create_class("Person", {
  greet: "puts 'Hello!'",
  age: "25"
})

person = Person.new
person.greet  # => "Hello!"
puts person.age  # => 25

2. Expression Parser

class ExpressionParser
  def self.parse(expression, variables = {})
    # Create a safe binding with variables
    binding_obj = binding
    variables.each do |key, value|
      binding_obj.local_variable_set(key, value)
    end

    eval(expression, binding_obj)
  end
end

result = ExpressionParser.parse("x * y + z", { x: 5, y: 3, z: 10 })
puts result  # => 25

3. Configuration DSL

class AppConfig
  def self.load_from_string(config_string)
    eval(config_string)
  end
end

config_string = "
  APP_NAME = 'MyApplication'
  DEBUG = true
  DATABASE = {
    host: 'localhost',
    port: 5432,
    name: 'myapp'
  }
"

AppConfig.load_from_string(config_string)
puts APP_NAME  # => "MyApplication"
puts DATABASE[:host]  # => "localhost"

Security Risks and Dangers

โš ๏ธ CRITICAL WARNING: eval is extremely dangerous when used with untrusted input!

Dangerous Examples:

# NEVER do this with user input!
user_input = gets.chomp
eval(user_input)  # User could input: system('rm -rf /')

# Dangerous with file input
file_content = File.read('user_provided_file.rb')
eval(file_content)  # Could contain malicious code

Safe Alternatives:

# Instead of eval, use safer alternatives
class SafeCalculator
  def self.calculate(expression)
    # Use a math library or parser instead
    case expression
    when /^\d+\s*\+\s*\d+$/
      # Safe addition
      eval(expression)
    else
      raise "Unsafe expression"
    end
  end
end

Binding and Context

1. Custom Binding

def create_binding(variables = {})
  binding_obj = binding
  variables.each do |key, value|
    binding_obj.local_variable_set(key, value)
  end
  binding_obj
end

my_binding = create_binding(x: 10, y: 20)
result = eval("x + y", my_binding)
puts result  # => 30

2. Different Contexts

class ContextExample
  def initialize(value)
    @value = value
  end

  def evaluate_in_context(code)
    eval(code)
  end
end

obj = ContextExample.new("test")
result = obj.evaluate_in_context("@value")
puts result  # => "test"

Performance Considerations

  • eval is slower than direct code execution
  • The string must be parsed every time
  • No compile-time optimization
  • Use sparingly and only when necessary

Best Practices

1. Avoid When Possible

# Bad - using eval
method_name = "calculate"
eval("result = #{method_name}(5, 3)")

# Good - using send
result = send(method_name, 5, 3)

2. Whitelist Allowed Operations

class SafeEvaluator
  ALLOWED_OPERATIONS = %w[+ - * /]

  def self.evaluate(expression)
    operation = expression.match(/(\d+)\s*([+\-*/])\s*(\d+)/)
    return "Invalid expression" unless operation

    op = operation[2]
    return "Operation not allowed" unless ALLOWED_OPERATIONS.include?(op)

    eval(expression)
  end
end

3. Use Sandboxing

class SandboxedEval
  def self.safe_eval(code, timeout: 1)
    Timeout::timeout(timeout) do
      eval(code)
    end
  rescue Timeout::Error
    "Execution timed out"
  rescue => e
    "Error: #{e.message}"
  end
end

Real-World Usage

eval is used in:

  • Template engines (ERB, Haml)
  • Configuration systems (Rails initializers)
  • Code generators (Rails generators)
  • REPLs (Interactive Ruby shells)
# ERB template example
require 'erb'

template = ERB.new("Hello <%= name %>!")
name = "World"
result = template.result(binding)
puts result  # => "Hello World!"

Summary

eval is the most powerful metaprogramming tool in Ruby, but also the most dangerous. Use it only when:

  • You have complete control over the input
  • No safer alternative exists
  • You understand the security implications
  • You implement proper validation and sandboxing

For most use cases, prefer safer alternatives like send, method_missing, or dedicated parsing libraries.


โœ๏ธ 4. What is define_method?

Ruby’s define_method, which is a powerful meta-programming tool for dynamically creating methods at runtime.

define_method is a method that allows you to dynamically define instance methods on a class or module. It’s inherited from the Module class and is a key tool for meta-programming in Ruby.

Basic Syntax

class MyClass
  define_method :dynamic_method do |*args|
    puts "Hello from dynamic method with args: #{args}"
  end
end

obj = MyClass.new
obj.dynamic_method("test", 123)  # => "Hello from dynamic method with args: [\"test\", 123]"

Key Features

1. Dynamic Method Creation

class Calculator
  # Define methods dynamically based on operations
  [:add, :subtract, :multiply, :divide].each do |operation|
    define_method operation do |a, b|
      case operation
      when :add then a + b
      when :subtract then a - b
      when :multiply then a * b
      when :divide then a / b
      end
    end
  end
end

calc = Calculator.new
puts calc.add(5, 3)      # => 8
puts calc.multiply(4, 2)  # => 8
puts calc.divide(10, 2)   # => 5

2. Access to Instance Variables

class Person
  def initialize(name, age)
    @name = name
    @age = age
  end

  # Create getter methods dynamically
  [:name, :age].each do |attribute|
    define_method attribute do
      instance_variable_get("@#{attribute}")
    end
  end
end

person = Person.new("Alice", 25)
puts person.name  # => "Alice"
puts person.age   # => 25

3. Method with Parameters

class DynamicAPI
  define_method :api_call do |endpoint, params = {}|
    puts "Calling #{endpoint} with params: #{params}"
    # Simulate API call
    "Response from #{endpoint}"
  end
end

api = DynamicAPI.new
api.api_call("/users", { id: 1 })  # => "Calling /users with params: {:id=>1}"

Common Use Cases

1. Attribute Accessors

class Model
  def self.attr_accessor(*attributes)
    attributes.each do |attribute|
      # Define getter
      define_method attribute do
        instance_variable_get("@#{attribute}")
      end

      # Define setter
      define_method "#{attribute}=" do |value|
        instance_variable_set("@#{attribute}", value)
      end
    end
  end

  attr_accessor :name, :email, :age
end

user = Model.new
user.name = "John"
user.email = "john@example.com"
puts user.name   # => "John"
puts user.email  # => "john@example.com"

2. Validation Methods

class User
  def initialize(attributes = {})
    attributes.each do |key, value|
      instance_variable_set("@#{key}", value)
    end
  end

  # Create validation methods dynamically
  [:name, :email, :age].each do |field|
    define_method "validate_#{field}" do
      value = instance_variable_get("@#{field}")
      case field
      when :name
        !value.nil? && !value.empty?
      when :email
        value =~ /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
      when :age
        value.is_a?(Integer) && value > 0 && value < 150
      end
    end
  end
end

user = User.new(name: "Alice", email: "alice@example.com", age: 25)
puts user.validate_name   # => true
puts user.validate_email  # => true
puts user.validate_age    # => true

3. API Method Generation

class APIClient
  def initialize(base_url)
    @base_url = base_url
  end

  # Generate API methods for different resources
  [:users, :posts, :comments].each do |resource|
    define_method "get_#{resource}" do |id = nil|
      endpoint = id ? "#{resource}/#{id}" : resource
      puts "GET #{@base_url}/#{endpoint}"
      # Actual HTTP request would go here
    end

    define_method "create_#{resource.singularize}" do |data|
      puts "POST #{@base_url}/#{resource}"
      puts "Data: #{data}"
      # Actual HTTP request would go here
    end
  end
end

api = APIClient.new("https://api.example.com")
api.get_users           # => "GET https://api.example.com/users"
api.get_users(123)      # => "GET https://api.example.com/users/123"
api.create_user(name: "John")  # => "POST https://api.example.com/users"

4. Database Query Methods

class ActiveRecord
  def self.has_many(association_name)
    define_method association_name do
      puts "Fetching #{association_name} for #{self.class}"
      # Actual database query would go here
      []
    end
  end

  def self.belongs_to(association_name)
    define_method association_name do
      puts "Fetching #{association_name} for #{self.class}"
      # Actual database query would go here
      nil
    end
  end
end

class User < ActiveRecord
  has_many :posts
  belongs_to :company
end

user = User.new
user.posts    # => "Fetching posts for User"
user.company  # => "Fetching company for User"

Advanced Examples

1. Method with Dynamic Logic

class DynamicCalculator
  def self.create_operation(operation_name, &block)
    define_method operation_name do |*args|
      instance_eval(&block)
    end
  end

  create_operation :custom_add do
    args = method(__method__).parameters.map { |_, name| local_variable_get(name) }
    args.inject(:+)
  end

  create_operation :power do
    base, exponent = method(__method__).parameters.map { |_, name| local_variable_get(name) }
    base ** exponent
  end
end

calc = DynamicCalculator.new
puts calc.custom_add(1, 2, 3, 4)  # => 10
puts calc.power(2, 3)             # => 8

2. Conditional Method Definition

class FeatureToggle
  def self.define_feature_method(feature_name, enabled = true)
    if enabled
      define_method feature_name do
        puts "Feature #{feature_name} is enabled"
        # Feature implementation
      end
    else
      define_method feature_name do
        puts "Feature #{feature_name} is disabled"
        # Fallback or no-op
      end
    end
  end

  define_feature_method :new_ui, true
  define_feature_method :beta_feature, false
end

app = FeatureToggle.new
app.new_ui        # => "Feature new_ui is enabled"
app.beta_feature  # => "Feature beta_feature is disabled"

3. Method with Different Signatures

class FlexibleAPI
  def self.define_flexible_method(method_name)
    define_method method_name do |*args, **kwargs, &block|
      puts "Method: #{method_name}"
      puts "Arguments: #{args}"
      puts "Keyword arguments: #{kwargs}"
      puts "Block given: #{block_given?}"

      # Process based on arguments
      if block_given?
        block.call(args.first)
      elsif !kwargs.empty?
        kwargs.values.first
      else
        args.first
      end
    end
  end

  define_flexible_method :process
end

api = FlexibleAPI.new
api.process("hello")                    # => "hello"
api.process(data: "world")              # => "world"
api.process("test") { |x| x.upcase }    # => "TEST"

4. Method Aliasing

class MethodAliaser
  def self.create_aliases(base_method, *aliases)
    aliases.each do |alias_name|
      define_method alias_name do |*args, &block|
        send(base_method, *args, &block)
      end
    end
  end

  def original_method
    puts "Original method called"
  end

  create_aliases :original_method, :alias1, :alias2, :alternative_name
end

obj = MethodAliaser.new
obj.alias1              # => "Original method called"
obj.alternative_name    # => "Original method called"

Performance Considerations

1. Method Definition Timing

class PerformanceExample
  # Methods defined at class definition time (faster)
  define_method :static_method do
    puts "Static method"
  end

  def self.create_dynamic_methods
    # Methods defined at runtime (slower)
    1000.times do |i|
      define_method "dynamic_method_#{i}" do
        puts "Dynamic method #{i}"
      end
    end
  end
end

2. Memory Usage

class MemoryEfficient
  # More memory efficient - methods defined once
  METHODS = [:method1, :method2, :method3]

  METHODS.each do |method_name|
    define_method method_name do
      puts "Called #{method_name}"
    end
  end
end

Best Practices

1. Use Meaningful Names

# Good
define_method :calculate_total do
  # implementation
end

# Bad
define_method :m1 do
  # implementation
end

2. Handle Errors Gracefully

class SafeMethodDefiner
  def self.define_safe_method(method_name, &block)
    define_method method_name do |*args|
      begin
        instance_eval(&block)
      rescue => e
        puts "Error in #{method_name}: #{e.message}"
        nil
      end
    end
  end
end

3. Document Dynamic Methods

class DocumentedClass
  # Dynamically creates getter methods for attributes
  # @param attributes [Array<Symbol>] list of attribute names
  def self.create_getters(*attributes)
    attributes.each do |attr|
      define_method attr do
        instance_variable_get("@#{attr}")
      end
    end
  end

  create_getters :name, :email
end

Real-World Usage

define_method is commonly used in:

  • Rails ActiveRecord (associations, validations)
  • RSpec (dynamic test methods)
  • Configuration systems (dynamic setters/getters)
  • API clients (dynamic endpoint methods)
  • ORM frameworks (dynamic query methods)
# Rails-like example
class ActiveRecord
  def self.validates_presence_of(*attributes)
    attributes.each do |attribute|
      define_method "validate_#{attribute}_presence" do
        value = send(attribute)
        value.nil? || value.to_s.empty?
      end
    end
  end
end

class User < ActiveRecord
  validates_presence_of :name, :email
end

define_method is a powerful tool for creating flexible, dynamic APIs and reducing code duplication through meta-programming.


๐ŸŒ€ 5. What is method_missing?

Ruby’s method_missing, which is a powerful meta-programming tool that allows you to handle calls to undefined methods dynamically.

method_missing is a special method in Ruby that gets called automatically when an object receives a message (method call) for a method that doesn’t exist. It’s inherited from the BasicObject class and is a key component of Ruby’s dynamic nature.

Basic Syntax

class MyClass
  def method_missing(method_name, *args, &block)
    puts "Method '#{method_name}' called with args: #{args}"
    # Handle the missing method call
  end
end

obj = MyClass.new
obj.undefined_method("hello", 123)  # => "Method 'undefined_method' called with args: [\"hello\", 123]"

Key Features

1. Automatic Invocation

class DynamicHandler
  def method_missing(method_name, *args, &block)
    puts "Trying to call: #{method_name}"
    puts "Arguments: #{args}"
    puts "Block given: #{block_given?}"

    # Return a default value or handle the call
    "Handled by method_missing"
  end
end

obj = DynamicHandler.new
result = obj.some_random_method("arg1", "arg2") { puts "block" }
puts result
# Output:
# Trying to call: some_random_method
# Arguments: ["arg1", "arg2"]
# Block given: true
# Handled by method_missing

2. Method Name and Arguments

class FlexibleAPI
  def method_missing(method_name, *args, **kwargs, &block)
    puts "Method: #{method_name}"
    puts "Arguments: #{args}"
    puts "Keyword arguments: #{kwargs}"

    # Handle different method patterns
    case method_name.to_s
    when /^get_(.+)$/
      "Getting #{$1}"
    when /^set_(.+)$/
      "Setting #{$1} to #{args.first}"
    else
      "Unknown method: #{method_name}"
    end
  end
end

api = FlexibleAPI.new
puts api.get_user_info     # => "Getting user_info"
puts api.set_name("Alice") # => "Setting name to Alice"
puts api.random_method     # => "Unknown method: random_method"

Common Use Cases

1. Dynamic Property Access

class DynamicProperties
  def initialize
    @data = {}
  end

  def method_missing(method_name, *args)
    method_str = method_name.to_s

    if method_str.end_with?('=')
      # Setter method
      property_name = method_str.chomp('=')
      @data[property_name] = args.first
    else
      # Getter method
      @data[method_str]
    end
  end
end

obj = DynamicProperties.new
obj.name = "Alice"
obj.age = 25
obj.city = "New York"

puts obj.name  # => "Alice"
puts obj.age   # => 25
puts obj.city  # => "New York"

2. API Method Generation

class APIClient
  def initialize(base_url)
    @base_url = base_url
  end

  def method_missing(method_name, *args)
    method_str = method_name.to_s

    case method_str
    when /^get_(.+)$/
      resource = $1
      puts "GET #{@base_url}/#{resource}"
      # Actual HTTP GET request
    when /^post_(.+)$/
      resource = $1
      data = args.first || {}
      puts "POST #{@base_url}/#{resource}"
      puts "Data: #{data}"
      # Actual HTTP POST request
    when /^put_(.+)$/
      resource = $1
      data = args.first || {}
      puts "PUT #{@base_url}/#{resource}"
      puts "Data: #{data}"
      # Actual HTTP PUT request
    when /^delete_(.+)$/
      resource = $1
      puts "DELETE #{@base_url}/#{resource}"
      # Actual HTTP DELETE request
    else
      super
    end
  end
end

api = APIClient.new("https://api.example.com")
api.get_users           # => "GET https://api.example.com/users"
api.post_user(name: "John")  # => "POST https://api.example.com/user"
api.put_user(1, name: "Jane")  # => "PUT https://api.example.com/user"
api.delete_user(1)      # => "DELETE https://api.example.com/user"

3. Configuration DSL

class Configuration
  def initialize
    @config = {}
  end

  def method_missing(method_name, *args)
    method_str = method_name.to_s

    if method_str.end_with?('=')
      # Setter
      key = method_str.chomp('=')
      @config[key] = args.first
    else
      # Getter
      @config[method_str]
    end
  end

  def to_hash
    @config
  end
end

config = Configuration.new
config.database_url = "postgresql://localhost/myapp"
config.api_key = ENV['API_KEY']
config.debug_mode = true

puts config.database_url  # => "postgresql://localhost/myapp"
puts config.to_hash       # => {"database_url"=>"postgresql://localhost/myapp", ...}

4. Builder Pattern

class HTMLBuilder
  def initialize
    @html = []
  end

  def method_missing(tag_name, *args, &block)
    content = args.first || ""
    attributes = args.last.is_a?(Hash) ? args.last : {}

    if block_given?
      @html << "<#{tag_name}#{format_attributes(attributes)}>"
      @html << yield
      @html << "</#{tag_name}>"
    else
      @html << "<#{tag_name}#{format_attributes(attributes)}>#{content}</#{tag_name}>"
    end

    self
  end

  private

  def format_attributes(attributes)
    return "" if attributes.empty?
    " " + attributes.map { |k, v| "#{k}=\"#{v}\"" }.join(" ")
  end

  def to_s
    @html.join("\n")
  end
end

builder = HTMLBuilder.new
html = builder.html do
  builder.head do
    builder.title("My Page")
  end
  builder.body(class: "main") do
    builder.h1("Hello World")
    builder.p("This is a paragraph", class: "intro")
  end
end

puts html
# Output:
# <html>
# <head>
# <title>My Page</title>
# </head>
# <body class="main">
# <h1>Hello World</h1>
# <p class="intro">This is a paragraph</p>
# </body>
# </html>

Advanced Examples

1. Method Caching with respond_to_missing?

class CachedMethodHandler
  def initialize
    @cache = {}
  end

  def method_missing(method_name, *args)
    method_str = method_name.to_s

    # Check if we should handle this method
    if method_str.start_with?('cached_')
      cache_key = "#{method_str}_#{args.hash}"

      if @cache.key?(cache_key)
        puts "Returning cached result for #{method_name}"
        @cache[cache_key]
      else
        puts "Computing result for #{method_name}"
        result = compute_result(method_str, args)
        @cache[cache_key] = result
        result
      end
    else
      super
    end
  end

  def respond_to_missing?(method_name, include_private = false)
    method_name.to_s.start_with?('cached_') || super
  end

  private

  def compute_result(method_name, args)
    # Simulate expensive computation
    sleep(1)
    "Result for #{method_name} with #{args}"
  end
end

handler = CachedMethodHandler.new
puts handler.cached_expensive_calculation(1, 2, 3)  # Slow
puts handler.cached_expensive_calculation(1, 2, 3)  # Fast (cached)
puts handler.respond_to?(:cached_expensive_calculation)  # => true

2. Dynamic Delegation

class Delegator
  def initialize(target)
    @target = target
  end

  def method_missing(method_name, *args, &block)
    if @target.respond_to?(method_name)
      @target.send(method_name, *args, &block)
    else
      super
    end
  end

  def respond_to_missing?(method_name, include_private = false)
    @target.respond_to?(method_name, include_private) || super
  end
end

class User
  def initialize(name, email)
    @name = name
    @email = email
  end

  def display_info
    "Name: #{@name}, Email: #{@email}"
  end
end

user = User.new("Alice", "alice@example.com")
delegator = Delegator.new(user)
puts delegator.display_info  # => "Name: Alice, Email: alice@example.com"

3. Method Chaining with method_missing

class QueryBuilder
  def initialize
    @conditions = []
    @order_by = nil
    @limit = nil
  end

  def method_missing(method_name, *args)
    method_str = method_name.to_s

    case method_str
    when /^where_(.+)$/
      field = $1
      value = args.first
      @conditions << "#{field} = '#{value}'"
      self
    when /^order_by_(.+)$/
      field = $1
      direction = args.first || 'ASC'
      @order_by = "#{field} #{direction}"
      self
    when /^limit$/
      @limit = args.first
      self
    when /^execute$/
      build_query
    else
      super
    end
  end

  private

  def build_query
    query = "SELECT * FROM table"
    query += " WHERE #{@conditions.join(' AND ')}" unless @conditions.empty?
    query += " ORDER BY #{@order_by}" if @order_by
    query += " LIMIT #{@limit}" if @limit
    query
  end
end

query = QueryBuilder.new
result = query.where_name("John")
              .where_age(25)
              .order_by_created_at("DESC")
              .limit(10)
              .execute

puts result
# => "SELECT * FROM table WHERE name = 'John' AND age = '25' ORDER BY created_at DESC LIMIT 10"

4. Event Handling

class EventHandler
  def initialize
    @handlers = {}
  end

  def method_missing(event_name, *args)
    method_str = event_name.to_s

    if method_str.end_with?('=')
      # Register event handler
      handler_name = method_str.chomp('=')
      @handlers[handler_name] = args.first
    else
      # Trigger event
      handler = @handlers[method_str]
      if handler
        handler.call(*args)
      else
        puts "No handler registered for event: #{method_str}"
      end
    end
  end
end

handler = EventHandler.new

# Register event handlers
handler.on_click = ->(x, y) { puts "Clicked at (#{x}, #{y})" }
handler.on_hover = ->(element) { puts "Hovered over #{element}" }

# Trigger events
handler.on_click(100, 200)  # => "Clicked at (100, 200)"
handler.on_hover("button")  # => "Hovered over button"
handler.on_keypress         # => "No handler registered for event: on_keypress"

Important Considerations

1. respond_to_missing?

Always implement respond_to_missing? when using method_missing:

class ProperHandler
  def method_missing(method_name, *args)
    if method_name.to_s.start_with?('dynamic_')
      "Handled: #{method_name}"
    else
      super
    end
  end

  def respond_to_missing?(method_name, include_private = false)
    method_name.to_s.start_with?('dynamic_') || super
  end
end

obj = ProperHandler.new
puts obj.respond_to?(:dynamic_method)  # => true
puts obj.respond_to?(:real_method)     # => false

2. Performance Impact

class PerformanceExample
  def method_missing(method_name, *args)
    # This gets called for EVERY undefined method
    # Can be slow if called frequently
    puts "Handling #{method_name}"
  end
end

# Better approach: Define methods when first called
class BetterExample
  def method_missing(method_name, *args)
    if method_name.to_s.start_with?('dynamic_')
      # Define the method for future calls
      self.class.define_method(method_name) do |*method_args|
        "Handled: #{method_name} with #{method_args}"
      end

      # Call the newly defined method
      send(method_name, *args)
    else
      super
    end
  end
end

3. Debugging

class DebuggableHandler
  def method_missing(method_name, *args, &block)
    puts "DEBUG: method_missing called for #{method_name}"
    puts "DEBUG: arguments: #{args}"
    puts "DEBUG: block given: #{block_given?}"

    # Your handling logic here
    super
  end
end

Real-World Usage

method_missing is commonly used in:

  • Rails ActiveRecord (dynamic finders)
  • RSpec (dynamic matchers)
  • Sinatra (dynamic route handlers)
  • Configuration systems (dynamic setters/getters)
  • API clients (dynamic endpoint methods)
# Rails-like example
class ActiveRecord
  def method_missing(method_name, *args)
    method_str = method_name.to_s

    if method_str.start_with?('find_by_')
      field = method_str.sub('find_by_', '')
      value = args.first
      puts "Finding record where #{field} = #{value}"
      # Actual database query
    else
      super
    end
  end
end

class User < ActiveRecord
end

User.find_by_name("Alice")  # => "Finding record where name = Alice"
User.find_by_email("alice@example.com")  # => "Finding record where email = alice@example.com"

method_missing is a powerful tool for creating flexible, dynamic APIs, but should be used carefully with proper implementation of respond_to_missing? and consideration for performance.


๐Ÿท๏ธ Part 2: Other Metaprogramming Tools

Ruby provides many more hooks for dynamic behavior:

๐Ÿ”— 1. define_singleton_method

Creates a method on a single object, similar to instance_eval + def.

str = "hello"
def str.shout; upcase + '!'; end
# vs.
str.define_singleton_method(:whisper) { downcase + '...' }

๐Ÿ“ฆ 2. module_eval / module_exec

Like class_eval but in a moduleโ€™s context, useful to mix in behavior.

module Mixin; end
Mixin.module_eval do
  def helper; "I'm mixed in"; end
end

๐Ÿงฉ 3. send / public_send

Invoke methods by name, bypassing visibility with send, or respecting it with public_send.

obj.send(:private_method)
obj.public_send(:public_method)

Both send and public_send in Ruby allow you to dynamically call methods on an object by name (as a symbol or string).
But the difference lies in method visibility (public, private, protected).

Key Difference

MethodCan call private/protected methods?Example Usage
sendโœ… Yes"hello".send(:upcase)
public_sendโŒ No (only public methods)"hello".public_send(:upcase)

Example

class MyClass
  def public_method
    "I'm public"
  end

  private
  def secret_method
    "I'm private"
  end
end

obj = MyClass.new

puts obj.send(:public_method)      # โœ… Works: "I'm public"
puts obj.public_send(:public_method) # โœ… Works: "I'm public"

puts obj.send(:secret_method)      # โœ… Works (can access private method)
puts obj.public_send(:secret_method) # โŒ Raises NoMethodError

? Why this matters

  • send is very powerful (and dangerous) because it ignores method visibility. Itโ€™s often used in metaprogramming (e.g., ActiveRecord uses it internally).
  • public_send is safer because it respects encapsulation. Use this when you donโ€™t want to accidentally call private methods.

Best Practice

  • Use public_send whenever possible (especially if the method name comes from user input) to avoid security issues.
  • Use send only when you explicitly need access to private methods (e.g., in testing or metaprogramming).

๐Ÿท๏ธ 4. Constant Manipulation (const_get, const_set)

Dynamically read or write constants on classes or modules.

Object.const_set('DynamicClass', Class.new)
klass = Object.const_get('DynamicClass')

๐Ÿ› ๏ธ 5. Alias & Removal (alias_method, undef_method, remove_method)

Alias existing methods or remove definitions at runtime.

def foo; :bar; end
alias_method :baz, :foo
undef_method :foo

๐Ÿ“ฅ 6. Instance Variable Access (instance_variable_get, instance_variable_set)

Read or write any objectโ€™s internal state.

obj.instance_variable_set(:@data, 123)
puts obj.instance_variable_get(:@data) # => 123

๐Ÿ”ฎ 7. Eigenclass & class << obj

Open the singleton class to define methods or mixins.

class << obj
  def special; 'only me'; end
end

๐Ÿ“ก 8. autoload / require_relative

Delay loading of modules until first reference.

autoload :Parser, 'parser'

๐Ÿ“ 9. respond_to_missing?

Complement method_missing to accurately report capabilities.

def respond_to_missing?(m, include_private=false)
  @target.respond_to?(m) || super
end

๐Ÿ”€ 10. Refinements

Scoped monkey-patching without global impact.

module StringExtensions
  refine String do
    def shout; upcase; end
  end
end

using StringExtensions
puts 'hi'.shout # => HI

โœ… Conclusion

Ruby’s metaprogramming toolbox is vastโ€”from the core five methods in Part 1 to the advanced techniques in Part 2. By mastering these, you can write highly dynamic, DRY, and expressive code, but always balance power with clarity and maintainability.

Happy Ruby coding! ๐Ÿš€


๐Ÿ” 1. Why Use class_eval and instance_eval?

Ruby classes and objects are open, meaning you can modify them at runtime.

  • class_eval lets you inject instance methods into a class after itโ€™s defined.
  • instance_eval lets you add singleton methods or access private state on a single object.

โœจ Dynamic Method Generation

When you donโ€™t know ahead of time what methods youโ€™ll needโ€”say youโ€™re reading an external schema or configurationโ€”you canโ€™t handโ€‘write every method. Metaprogramming with class_eval/instance_eval generates them on the fly.

๐Ÿ”ง Building DSLs

Internal DSLs (e.g. Railsโ€™ routing or configuration blocks) rely on evaluating blocks in the right context:

# routes.rb
Rails.application.routes.draw do
  resources :users do
    resources :posts
  end
end

Here, instance_eval on the routing object makes resources available inside the block.

If you know all your methods at design time, define them normally. Lean on metaprogramming when you need flexibility, DRY generation, or want to craft a clean DSL.


๐Ÿ› ๏ธ 2. When to Use define_method?

define_method is Rubyโ€™s blockโ€‘based way to dynamically add methods in a class or moduleโ€”safer than eval and can close over local variables:

class Serializer
  %i[name age email].each do |attr|
    define_method("serialize_#{attr}") do |user|
      user.public_send(attr).to_s
    end
  end
end

  • Ideal for generating many similar methods (attribute serializers, dynamic finders).
  • Keeps code DRY without string interpolation.

๐Ÿ“ฆ 3. Rubyโ€™s *arg and **arg Operators

โญ Single Splat: *args

  • Definition: Packs extra positional args into an array, or unpacks an array into individual arguments. def foo(a, *others) p a # first arg p others # rest as an array end foo(1, 2, 3) # a=1, others=[2,3] foo(*[4,5,6]) # same as foo(4,5,6)

โœจ Double Splat: **kwargs

  • Definition: Packs extra keyword args into a hash, or unpacks a hash into keyword arguments. def bar(x:, **opts) p x # required keyword p opts # other keywords in a hash end bar(x: 10, y: 20, z: 30) # opts={y:20, z:30} bar(**{x:1, y:2}) # same as bar(x:1, y:2)

๐Ÿ“š 4. What Is a DSL? Main Ruby DSLs in Rails

A DSL (Domainโ€‘Specific Language) is an internal API that reads like its own language, tailored to a task. Rails ships with many:

๐Ÿšฆ Routing DSL

Rails.application.routes.draw do
  resources :users
end

๐Ÿ—๏ธ ActiveRecord Query DSL

User.where(active: true)
    .order(created_at: :desc)
    .limit(10)

๐Ÿ—„๏ธ Migrations DSL

class CreateProducts < ActiveRecord::Migration[8.0]
  def change
    create_table :products do |t|
      t.string :name
      t.decimal :price
    end
  end
end

๐Ÿ’ฌ Validation DSL

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
end

๐Ÿ”„ Callback DSL

class Order < ApplicationRecord
  before_save :calculate_total
  after_commit :send_confirmation_email
end

โœ”๏ธ These meta-programming techniques and splat operators power Ruby’s flexibilityโ€”and underpin the expressive DSLs that make Rails code so readable.


Enjoy Ruby! ๐Ÿš€

Rails 7+ API error handling that scales โš–๏ธ

A solid API error strategy gives you:

  • Consistent JSON error shapes
  • Correct HTTP status codes
  • Separation of concerns (domain vs transport)
  • Observability without leaking internals

Below is a practical, production-ready approach that covers controller hooks, controllers, models/libs, background jobs, and moreโ€”illustrated with a real scenario from Session::CouponCode.

Core principles

  • Keep transport (HTTP, JSON) in controllers; keep domain logic in models/libs.
  • Map known, expected failures to specific HTTP statuses.
  • Log unexpected failures; return a generic message to clients.
  • Centralize API error rendering in a base controller.

1) A single error boundary for all API controllers

Create a base Error::ApiError and rescue it (plus a safe catchโ€‘all) in your ApiController.

# lib/error/api_error.rb
module Error
  class ApiError < StandardError
    attr_reader :status, :details
    def initialize(message, status = :unprocessable_entity, details: nil)
      super(message)
      @status  = status
      @details = details
    end
  end
end
# app/controllers/api_controller.rb
class ApiController < ActionController::Base
  include LocaleConcern
  skip_forgery_protection

  impersonates :user,
               ......

  # Specific handlers first
  rescue_from Error::ApiError,                          with: :handle_api_error
  rescue_from ActionController::ParameterMissing,       with: :handle_bad_request
  rescue_from ActiveRecord::RecordNotFound,             with: :handle_not_found
  rescue_from ActiveRecord::RecordInvalid,              with: :handle_unprocessable
  rescue_from ActiveRecord::RecordNotUnique,            with: :handle_conflict

  # Catchโ€‘all last
  rescue_from StandardError,                            with: :handle_standard_error

  private

  def handle_api_error(e)
    render json: { success: false, error: e.message, details: e.details }, status: e.status
  end

  def handle_bad_request(e)
    render json: { success: false, error: e.message }, status: :bad_request
  end

  def handle_not_found(_e)
    render json: { success: false, error: 'Not found' }, status: :not_found
  end

  def handle_unprocessable(e)
    render json: { success: false, error: e.record.errors.full_messages }, status: :unprocessable_entity
  end

  def handle_conflict(_e)
    render json: { success: false, error: 'Conflict' }, status: :conflict
  end

  def handle_standard_error(e)
    Rollbar.error(e, path: request.fullpath, client_id: try(:current_client)&.id)
    render json: { success: false, error: 'Something went wrong' }, status: :internal_server_error
  end
end
  • Order matters. Specific rescue_from before StandardError.
  • This pattern avoids duplicating rescue_from across controllers and keeps HTML controllers unaffected.

2) Errors in before actions

Because before_action runs inside controllers, the same rescue_from handlers apply.

Two patterns:

  • Render in the hook for simple guard clauses:
before_action :require_current_client

def require_current_client
  return if current_client
  render json: { success: false, error: 'require_login' }, status: :unauthorized
end
  • Raise a domain/auth error and let rescue_from handle JSON:
# lib/error/unauthorized_error.rb
module Error
  class UnauthorizedError < Error::ApiError
    def initialize(message = 'require_login') = super(message, :unauthorized)
  end
end

before_action :require_current_client

def require_current_client
  raise Error::UnauthorizedError unless current_client
end

Prefer raising if you want consistent global handling and logging.

3) Errors inside controllers

Use explicit renders for happy-path control flow; raise for domain failures:

def create
  form = CreateThingForm.new(params.require(:thing).permit(:name))
  result = CreateThing.new(form: form).call

  if result.success?
    render json: { success: true, thing: result.thing }, status: :created
  else
    # Known domain failure โ†’ raise an ApiError to map to 422
    raise Error::ApiError.new(result.message, :unprocessable_entity, details: result.details)
  end
end

Common controller exceptions (auto-mapped above):

  • ActionController::ParameterMissing โ†’ 400
  • ActiveRecord::RecordNotFound โ†’ 404
  • ActiveRecord::RecordInvalid โ†’ 422
  • ActiveRecord::RecordNotUnique โ†’ 409

4) Errors in models, services, and libs

Do not call render here. Either:

  • Return a result object (Success/Failure), or
  • Raise a domainโ€‘specific exception that the controller maps to an HTTP response.

Example from our scenario, Session::CouponCode:

# lib/error/session/coupon_code_error.rb
module Error
  module Session
    class CouponCodeError < Error::ApiError; end
  end
end
# lib/session/coupon_code.rb
class Session::CouponCode
  def discount_dollars
    # ...
    case
    when coupon_code.gift_card?
      # ...
    when coupon_code.discount_code?
      # ...
    when coupon_code.multiorder_discount_code?
      # ...
    else
      raise Error::Session::CouponCodeError, 'Unrecognized discount code'
    end
  end
end

Then, in ApiController, the specific handler (or the Error::ApiError handler) renders JSON with a 422.

This preserves separation: models/libs raise; controllers decide HTTP.

5) Other important surfaces

  • ActiveJob / Sidekiq
  • Prefer retry_on, discard_on, and jobโ€‘level rescue with logging.
  • Return no HTTP here; jobs are async.
class MyJob < ApplicationJob
  retry_on Net::OpenTimeout, wait: 10.seconds, attempts: 3
  discard_on Error::ApiError
  rescue_from(StandardError) { |e| Rollbar.error(e) }
end
  • Mailers
  • Use rescue_from to avoid bubbleโ€‘ups crashing deliveries:
class ApplicationMailer < ActionMailer::Base
  rescue_from Postmark::InactiveRecipientError, Postmark::InvalidEmailRequestError do
    # no-op / log
  end
end
  • Routing / 404
  • For APIs, keep 404 mapping at the controller boundary with rescue_from ActiveRecord::RecordNotFound.
  • For HTML, config.exceptions_app = routes + ErrorsController.
  • Middleware / Rack
  • For truly global concerns, use middleware. This is rarely necessary for controller-scoped API errors in Rails.
  • Validation vs. Exceptions
  • Use validations (ActiveModel/ActiveRecord) for expected user errors.
  • Raise exceptions for exceptional conditions (invariants violated, external systems fail unexpectedly).

6) Observability

  • Always log unexpected errors in the catchโ€‘all (StandardError).
  • Add minimal context: client_id, request.fullpath, feature flags.
  • Avoid leaking stack traces or internal messages to clients. Send generic messages on 500s.

7) Testing

  • Unit test domain services to ensure they raise Error::ApiError (or return Failure).
  • Controller/request specs: assert status codes and JSON shapes for both happy path and error path.
  • Ensure before_action guards either render or raise as intended.

Applying this to our scenario

  • /lib/session/coupon_code.rb raises Error::Session::CouponCodeError on unknown/invalid discount values.
  • /app/controllers/api_controller.rb rescues that error and returns JSON:
  • { success: false, error: e.message } with a 422 (or via Error::ApiError base).

This converts prior 500s into clean API responses and keeps error handling centralized.

When to generalize vs. specialize

  • Keep a catchโ€‘all rescue_from StandardError in ApiController to prevent 500s from leaking internals.
  • Still add specific handlers (or subclass Error::ApiError) for known cases to control the correct status code and message.
  • Do not replace everything with only StandardErrorโ€”you’ll lose semantics and proper HTTP codes.

โ€”

  • Key takeaways
  • Centralize APIโ€wide error handling in ApiController using specific handlers + a safe catchโ€‘all.
  • Raise domain errors in models/libs; render JSON only in controllers.
  • Map common Rails exceptions to correct HTTP statuses; log unexpected errors.
  • Prefer Error::ApiError as a base for consistent message/status handling across the API.

๐Ÿ”ฎ The Future of Ruby: Is It Still Relevant in 2025 and Beyond?

Ruby, the language that brought joy back into programming, is now over two decades old. It revolutionized web development through Rails and championed a developer-first philosophy. But in the era of AI, server-less, and systems programming, is Ruby still relevant? With Python dominating AI, Go owning the backend space, and Elixir praised for concurrency โ€” where does Ruby stand?

Let’s explore Ruby’s current state, the challenges it faces, and what the future might hold.


๐Ÿงฑ What Ruby Still Does Exceptionally Well

1. Web Development with Rails

Ruby on Rails remains one of the fastest and most pleasant ways to build web applications. Itโ€™s productive, expressive, and mature.

  • Companies like GitHub, Shopify, Basecamp, and Hey.com still use Rails at scale.
  • Rails 8 introduced modern features like Turbo, Hotwire, and Kamal (for zero-downtime deploys).
  • It’s still a top pick for startups wanting to build MVPs quickly.

2. Developer Happiness

The principle of “developer happiness” is deeply embedded in Ruby’s philosophy:

  • Intuitive syntax
  • Expressive and readable code
  • A community that values elegance over boilerplate

Ruby continues to be one of the best languages for teaching programming, prototyping ideas, or building software that feels joyful to write.


โš ๏ธ Challenges Facing Ruby Today

1. Performance Limitations

Rubyโ€™s performance has improved dramatically with YJIT, MJIT, and better memory handling. But it still lags behind languages like Go or Rust in raw speed, especially in CPU-bound or concurrent environments.

2. Concurrency and Parallelism

  • Ruby has a Global Interpreter Lock (GIL) in MRI, which limits real parallelism.
  • While Fibers and async gems (async, polyphony, concurrent-ruby) help, itโ€™s not as seamless as Goโ€™s goroutines or Elixirโ€™s lightweight processes.

3. Ecosystem Narrowness

Rubyโ€™s ecosystem is tightly tied to Rails.

  • Unlike Python, which powers AI, data science, and automationโ€ฆ
  • Or JavaScript, which rules the browser and serverless spaceโ€ฆ

Ruby hasnโ€™t made significant inroads outside web development.

4. Enterprise Perception

Many large enterprises shy away from Ruby, viewing it as either:

  • A “legacy startup language“, or
  • Too dynamic and flexible for highly-regulated or enterprise-scale environments.

๐Ÿ› ๏ธ How Can Ruby Improve?

๐Ÿ’ก 1. Concurrency and Async Programming

  • Embrace the shift toward non-blocking IO, async/await patterns.
  • Invest in the ecosystem around async, falcon, and evented web servers.

๐Ÿ’ก 2. AI/ML Integration

  • Ruby doesn’t need to compete with Python in AI, but it can bridge to Python using gems like pycall, pybind11, or ruby-dlib.
  • Better interop with other platforms like JRuby, TruffleRuby, or even WebAssembly can unlock new domains.

๐Ÿ’ก 3. Broaden Ecosystem Use

  • Encourage usage outside web: CLI tools, static site generation, scripting, DevOps, etc.
  • Frameworks like Hanami, Roda, Dry-rb, and Trailblazer are promising.

๐Ÿ’ก 4. Stronger Developer Outreach

  • More documentation, YouTube tutorials, free courses, and evangelism.
  • Encourage open source contribution in tools beyond Rails.

๐Ÿ“‰ Will Rails Usage Decline?

Not disappear, but become more specialized.

Rails is no longer the hottest framework โ€” but it’s still one of the most productive and complete options for web development.

  • Startups love it for speed of development.
  • Mid-sized businesses rely on it for stability and maintainability.
  • But serverless-first, JavaScript-heavy, or cloud-native stacks may bypass it in favor of Next.js, Go, or Elixir/Phoenix.

The challenge is staying competitive in the face of frameworks that promise better real-time capabilities and lightweight microservices.

๐ŸŒŸ Why Ruby Still Matters

Despite all that, Ruby still offers:

  • ๐Ÿง˜โ€โ™‚๏ธ Developer productivity
  • ๐Ÿงฉ Readable, expressive syntax
  • ๐Ÿš€ Fast prototyping
  • โค๏ธ A helpful, mature community
  • ๐Ÿงช First-class TDD culture

It’s a joy to write in Ruby. For many developers, that alone is enough.


๐Ÿ”š Final Thoughts: The Joyful Underdog

Ruby is no longer the main character in the programming language race. But that’s okay.

In a world chasing performance benchmarks, Ruby quietly reminds us: “Programming can still be beautiful.

The future of Ruby lies in:

  • Focusing on what it does best (developer experience, productivity)
  • Expanding into new areas (concurrency, scripting, interop)
  • And adapting โ€” not by competing with Go or Python, but by embracing its unique strengths.

Go with Ruby! ๐Ÿš€

๐Ÿƒโ€โ™‚๏ธ Solving LeetCode Problems the TDDย Way (Test-First Ruby): Minimum Size Subarray Sum

Welcome to my new series where I combine the power of Ruby with the discipline of Test-Driven Development (TDD) to tackle popular algorithm problems from LeetCode! ๐Ÿง‘โ€๐Ÿ’ป๐Ÿ’Ž Whether you’re a Ruby enthusiast looking to sharpen your problem-solving skills, or a developer curious about how TDD can transform the way you approach coding challenges, you’re in the right place.

๐ŸŽฒ Episode 7: Minimum Size Subarray Sum

###########################################################
# #209
# Given an array of positive integers nums and a positive integer target, return the minimal length of a subarray
# whose @sum is greater than or equal to target. If there is no such subarray, return 0 instead.
#
# Example 1:
#
# Input: target = 7, nums = [2,3,1,2,4,3]
# Output: 2
# Explanation: The subarray [4,3] has the minimal length under the problem constraint.
# Example 2:
#
# Input: target = 4, nums = [1,4,4]
# Output: 1
# Example 3:
#
# Input: target = 11, nums = [1,1,1,1,1,1,1,1]
# Output: 0
#
#
# Constraints:
#
# 1 <= target <= 109
# 1 <= nums.length <= 105
# 1 <= nums[i] <= 104
#
###########################################################

๐Ÿ”ง Setting up the TDD environment

mkdir minimum-size-subarray-sum
touch minimum-size-subarray-sum/subarray_sum_min_size.rb
touch minimum-size-subarray-sum/test_subarray_sum_min_size.rb

Github Repo: https://github.com/abhilashak/leetcode/tree/main/minimum_size_subarray_sum

โŒ Red: Writing the failing test

Test File:

# โŒ Fail
# frozen_string_literal: true

#######################################################
# #209
# Given an array of positive integers nums and a positive integer target, return the minimal length of a subarray
# whose sum is greater than or equal to target. If there is no such subarray, return 0 instead.
#
#######################################################
require 'minitest/autorun'
require_relative 'subarray_sum_min_size'

class TestSubArraySumMinSize < Minitest::Test
  def set_up; end

  def test_array_of_length_one
    assert_equal 0, SubArray.new([2], 3).min_size
    assert_equal 1, SubArray.new([2], 2).min_size
    assert_equal 0, SubArray.new([3], 4).min_size
  end
end

Source Code:

# frozen_string_literal: true

# disable rubocop GuardClause for better readability in the code
###########################################################
# #209
# Given an array of positive integers nums and a positive integer target, return the minimal length of a subarray
# whose @sum is greater than or equal to target. If there is no such subarray, return 0 instead.
# ............
#
###########################################################
class SubArray
   def min_size
   end
end
โœ—  ruby test_subarray_sum_min_size.rb
Run options: --seed 5914

# Running:

E

Finished in 0.000386s, 2590.6736 runs/s, 0.0000 assertions/s.

  1) Error:
TestSubArraySumMinSize#test_array_of_length_one:
ArgumentError: wrong number of arguments (given 2, expected 0)
    test_subarray_sum_min_size.rb:16:in 'BasicObject#initialize'
    test_subarray_sum_min_size.rb:16:in 'Class#new'
    test_subarray_sum_min_size.rb:16:in 'TestSubArraySumMinSize#test_array_of_length_one'

1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
โžœ  minimum-size-subarray-sum git:(main) โœ—

โœ… Green: Making it pass

# Pass โœ… 
# frozen_string_literal: true

###########################################################
# #209
# Given an array of positive integers nums and a positive integer target, return the minimal length of a subarray
# whose sum is greater than or equal to target. If there is no such subarray, return 0 instead.
#
# Example 1:
#........
#
###########################################################
class SubArray
  def initialize(nums, target)
    @nums = nums
    @target = target
  end

  def min_size
    0 if @nums.length == 1 && @nums.first < @target
  end
end
โœ— ruby minimum-size-subarray-sum/test_subarray_sum_min_size.rb
Run options: --seed 52896

# Running:
.

Finished in 0.000354s, 2824.8588 runs/s, 2824.8588 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

โ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆ.โคต โ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆ..

# frozen_string_literal: true
# .........
require 'minitest/autorun'
require_relative 'subarray_sum_min_size'

class TestSubArraySumMinSize < Minitest::Test
  def set_up; end

  def test_array_of_length_one
    assert_equal 0, SubArray.new([2], 3).min_size
    assert_equal 1, SubArray.new([2], 2).min_size
    assert_equal 0, SubArray.new([3], 2).min_size
  end

  def test_array_of_length_two
    assert_equal 0, SubArray.new([2, 2], 5).min_size
    assert_equal 0, SubArray.new([1, 2], 10).min_size
    assert_equal 2, SubArray.new([2, 2], 4).min_size
    assert_equal 2, SubArray.new([3, 5], 8).min_size
  end
end
# Solution for upto 2 Array Input Length โœ… 

# frozen_string_literal: true
###########################################################
# .............
###########################################################
class SubArray
  def initialize(nums, target)
    @nums = nums
    @target = target
  end

  def min_size
    if @nums.length == 1
      return (@nums.first == @target ? 1 : 0)
    end

    @nums.sum == @target ? 2 : 0
  end
end

โ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆ.โคต โ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆ..

# frozen_string_literal: true

#######################################################
# ..........
#######################################################
require 'minitest/autorun'
require_relative 'subarray_sum_min_size'

class TestSubArraySumMinSize < Minitest::Test
  def set_up; end

  def test_array_of_length_one
    assert_equal 0, SubArray.new([2], 3).min_size
    assert_equal 1, SubArray.new([2], 2).min_size
    assert_equal 0, SubArray.new([3], 4).min_size
  end

  def test_array_of_length_two
    assert_equal 0, SubArray.new([2, 2], 5).min_size
    assert_equal 0, SubArray.new([1, 2], 10).min_size
    assert_equal 2, SubArray.new([2, 2], 4).min_size
    assert_equal 2, SubArray.new([3, 5], 8).min_size
  end

  def test_array_of_length_three
    assert_equal 0, SubArray.new([2, 3, 4], 10).min_size
    assert_equal 1, SubArray.new([12, 3, 9], 10).min_size
    assert_equal 2, SubArray.new([2, 3, 4], 7).min_size
    assert_equal 1, SubArray.new([2, 3, 4], 4).min_size
  end

  def test_array_of_length_five
    assert_equal 0, SubArray.new([2, 3, 4, 1, 9], 20).min_size
    assert_equal 2, SubArray.new([2, 3, 9, 1, 0], 10).min_size
    assert_equal 4, SubArray.new([2, 3, 4, 6, 4], 17).min_size
    assert_equal 5, SubArray.new([2, 3, 4, 12, 10], 31).min_size
  end
end
# Solution for upto 5 Array Input Length โœ… 
# frozen_string_literal: true

# disable rubocop GuardClause for better readability in the code
# rubocop:disable Style/GuardClause
###########################################################
# ...............
###########################################################
class SubArray
  def initialize(nums, target)
    @nums = nums
    @target = target
    @min_length = 0 # default 0 -> solution not found
    @left_pos = 0
    @right_pos = 0
    @sum = nil
  end

  def min_size
    while @right_pos < @nums.length
      # first position where left and right positions are at starting point
      @sum = if @left_pos.zero? && @right_pos.zero?
               @nums[@right_pos]
             else
               # add elements inside the window
               @nums[@left_pos..@right_pos].sum
             end

      if solution_found?
        update_min_length

        return 1 if @min_length == 1 # best scenario found, stop here
      else
        @right_pos += 1 # increase window size by 1
      end
    end

    @min_length
  end

  private

  def update_min_length
    new_length = @right_pos - @left_pos + 1

    if min_length_empty? || min_or_equal_length?(new_length)
      @min_length = new_length
      @left_pos += 1
    end
  end

  def solution_found?
    @sum >= @target
  end

  def min_length_empty?
    @min_length.zero?
  end

  # if new length of subarray found is less than already found min length
  # or new length found is equal to previous min length (should decrease window size
  # by increasing left pos to find the less length subarray)
  def min_or_equal_length?(new_length)
    new_length <= @min_length
  end
end

โ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆ.โคต โ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆโ€ฆ..

# Test Cases with Original LeetCode examples, Edge Cases, Additional test cases
# frozen_string_literal: true

#######################################################
# ..........
#######################################################
require 'minitest/autorun'
require_relative 'subarray_sum_min_size'

class TestSubArraySumMinSize < Minitest::Test
  def set_up; end

  def test_array_of_length_one
    assert_equal 0, SubArray.new([2], 3).min_size
    assert_equal 1, SubArray.new([2], 2).min_size
    assert_equal 0, SubArray.new([3], 4).min_size
  end

  def test_array_of_length_two
    assert_equal 0, SubArray.new([2, 2], 5).min_size
    assert_equal 0, SubArray.new([1, 2], 10).min_size
    assert_equal 2, SubArray.new([2, 2], 4).min_size
    assert_equal 2, SubArray.new([3, 5], 8).min_size
  end

  def test_array_of_length_three
    assert_equal 0, SubArray.new([2, 3, 4], 10).min_size
    assert_equal 1, SubArray.new([12, 3, 9], 10).min_size
    assert_equal 2, SubArray.new([2, 3, 4], 7).min_size
    assert_equal 1, SubArray.new([2, 3, 4], 4).min_size
  end

  def test_array_of_length_five
    assert_equal 0, SubArray.new([2, 3, 4, 1, 9], 20).min_size
    assert_equal 2, SubArray.new([2, 3, 9, 1, 0], 10).min_size
    assert_equal 4, SubArray.new([2, 3, 4, 6, 4], 17).min_size
    assert_equal 5, SubArray.new([2, 3, 4, 12, 10], 31).min_size
  end

  # Original LeetCode examples
  def test_leetcode_example1
    # Input: target = 7, nums = [2,3,1,2,4,3]
    # Output: 2 (subarray [4,3])
    assert_equal 2, SubArray.new([2, 3, 1, 2, 4, 3], 7).min_size
  end

  def test_leetcode_example2
    # Input: target = 4, nums = [1,4,4]
    # Output: 1 (subarray [4])
    assert_equal 1, SubArray.new([1, 4, 4], 4).min_size
  end

  def test_leetcode_example3
    # Input: target = 11, nums = [1,1,1,1,1,1,1,1]
    # Output: 0 (no subarray sums to >= 11)
    assert_equal 0, SubArray.new([1, 1, 1, 1, 1, 1, 1, 1], 11).min_size
  end

  # Edge cases
  def test_empty_array
    assert_equal 0, SubArray.new([], 5).min_size
  end

  def test_target_zero
    assert_equal 1, SubArray.new([1, 2, 3], 0).min_size
  end

  def test_target_equals_single_element
    assert_equal 1, SubArray.new([5, 2, 3], 5).min_size
  end

  def test_target_equals_array_sum
    assert_equal 3, SubArray.new([1, 2, 3], 6).min_size
  end

  def test_target_greater_than_array_sum
    assert_equal 0, SubArray.new([1, 2, 3], 10).min_size
  end

  # Additional test cases
  def test_consecutive_ones
    assert_equal 3, SubArray.new([1, 1, 1, 1, 1], 3).min_size
    assert_equal 5, SubArray.new([1, 1, 1, 1, 1], 5).min_size
    assert_equal 0, SubArray.new([1, 1, 1, 1, 1], 6).min_size
  end

  def test_large_numbers
    assert_equal 1, SubArray.new([100, 1, 1, 1], 50).min_size
    assert_equal 2, SubArray.new([50, 50, 1, 1], 100).min_size
  end

  def test_window_shrinking
    # Test that the algorithm properly shrinks the window
    # [1, 4, 4] with target 4 should return 1, not 2
    assert_equal 1, SubArray.new([1, 4, 4], 4).min_size
  end

  def test_multiple_valid_subarrays
    # [2, 3, 1, 2, 4, 3] with target 7
    # Valid subarrays: [2,3,1,2] (sum=8), [4,3] (sum=7), [3,1,2,4] (sum=10)
    # Should return 2 (shortest: [4,3])
    assert_equal 2, SubArray.new([2, 3, 1, 2, 4, 3], 7).min_size
  end

  def test_all_elements_equal
    assert_equal 2, SubArray.new([3, 3, 3, 3], 6).min_size
    assert_equal 3, SubArray.new([3, 3, 3, 3], 9).min_size
    assert_equal 0, SubArray.new([3, 3, 3, 3], 13).min_size
  end
end
# Solution 1 โœ… 
# frozen_string_literal: true

# disable rubocop GuardClause for better readability in the code
# rubocop:disable Style/GuardClause
###########################################################
# #209
#  .............
###########################################################
class SubArray
  def initialize(nums, target)
    @nums = nums
    @target = target
    @min_length = 0 # default 0 -> solution not found
    @left_pos = 0
    @right_pos = 0
    @sum = nil
  end

  def min_size
    while @right_pos < @nums.length
      @sum = calculate_sum

      if solution_found?
        update_min_length

        return 1 if @min_length == 1 # best scenario found, stop here
      else
        @right_pos += 1 # increase window size by 1
      end
    end

    @min_length
  end

  private

  def calculate_sum
    # first position where left and right positions are at starting point
    return @nums[@right_pos] if @left_pos.zero? && @right_pos.zero?

    # add elements inside the window
    @nums[@left_pos..@right_pos].sum
  end

  def update_min_length
    new_length = @right_pos - @left_pos + 1

    if min_length_empty? || min_or_equal_length?(new_length)
      @min_length = new_length
      @left_pos += 1
    end
  end

  def solution_found?
    @sum >= @target
  end

  def min_length_empty?
    @min_length.zero?
  end

  # if new length of subarray found is less than already found min length
  # or new length found is equal to previous min length (should decrease window size
  # by increasing left pos to find the less length subarray)
  def min_or_equal_length?(new_length)
    new_length <= @min_length
  end
end
# Solution 2 โœ… 
# frozen_string_literal: true

# disable rubocop GuardClause for better readability in the code
###########################################################
# #209
# .............
###########################################################
class SubArray
  def initialize(nums, target)
    @nums = nums
    @target = target
    @min_length = 0 # default 0 -> solution not found
    @left_pos = 0
    @right_pos = 0
    @sum = nil
  end

  def min_size
    while @right_pos < @nums.length
      @sum = calculate_sum

      if solution_found?
        update_min_length

        return 1 if @min_length == 1 # best scenario found, stop here
      else
        @right_pos += 1 # increase window size by 1
      end
    end

    @min_length
  end

  private

  def calculate_sum
    # first position where left and right positions are at starting point
    return @nums[@right_pos] if @left_pos.zero? && @right_pos.zero?

    # add elements inside the window
    @nums[@left_pos..@right_pos].sum
  end

  def update_min_length
    new_length = @right_pos - @left_pos + 1

    @min_length = new_length if min_length_empty? || min_length_greater?(new_length)
    @left_pos += 1
  end

  def solution_found?
    @sum >= @target
  end

  def min_length_empty?
    @min_length.zero?
  end

  # if new length of subarray found is less than already found min length
  # or new length found is equal to previous min length (should decrease window size
  # by increasing left pos to find the less length subarray)
  def min_length_greater?(new_length)
    @min_length > new_length
  end
end

๐Ÿงฎ Algorithm Complexity Analysis

Time Complexity: O(nยฒ)

Our current algorithm has quadratic time complexity due to the calculate_sum method:

def calculate_sum(nums, left_pos, right_pos)
  # This line causes O(n) complexity in each iteration
  nums[left_pos..right_pos].sum
end

Why O(nยฒ)?

  • Outer loop: while right_pos < nums.length โ†’ O(n)
  • Inner operation: nums[left_pos..right_pos].sum โ†’ O(n)
  • Total: O(n) ร— O(n) = O(nยฒ)

Solution: We should change this logic of repeated addition of numbers that are already added before. We can add the next Number (Right position) and substract the Left Number that is out of the window.

Space Complexity: O(1)

  • Only uses a constant number of variables regardless of input size
  • No additional data structures that grow with input

๐Ÿš€ Optimized Version (O(n) Time):

Here’s how to make it linear time complexity:

Let’s Try to Optimize our solution with the Solution given above:

# frozen_string_literal: true

# disable rubocop GuardClause for better readability in the code
###########################################################
# ..................
###########################################################
class SubArray
  def initialize(nums, target)
    @nums = nums
    @target = target
    @min_length = 0 # default 0 -> solution not found
    @left_pos = 0
    @right_pos = 0
    @sum = 0
  end

  def min_size
    while @right_pos < @nums.length
      # Add the new element at right_pos to the current sum
      @sum += @nums[@right_pos]

      update_min_length if solution_found?

      @right_pos += 1 # always move right pointer
    end

    @min_length
  end

  private

  def update_min_length
    new_length = @right_pos - @left_pos + 1

    @min_length = new_length if min_length_empty? || min_length_greater?(new_length)

    # Shrink the window from the left as much as possible while maintaining sum >= target
    while @left_pos < @right_pos && (@sum - @nums[@left_pos]) >= @target
      @sum -= @nums[@left_pos]
      @left_pos += 1
      new_length = @right_pos - @left_pos + 1
      @min_length = new_length if min_length_greater?(new_length)
    end
  end

  def solution_found?
    @sum >= @target
  end

  def min_length_empty?
    @min_length.zero?
  end

  # if new length of subarray found is less than already found min length
  # or new length found is equal to previous min length (should decrease window size
  # by increasing left pos to find the less length subarray)
  def min_length_greater?(new_length)
    @min_length > new_length
  end
end

๐Ÿ“Š Complexity Comparison:

VersionTime ComplexitySpace ComplexityWhy
Your CurrentO(nยฒ)O(1)Recalculates sum each time
OptimizedO(n)O(1)Maintains running sum

Key Optimization:

Instead of recalculating the sum each time:

# Your approach (O(n) each time)
nums[left_pos..right_pos].sum

# Optimized approach (O(1) each time)
current_sum += num        # Add new element
current_sum -= nums[left] # Remove old element

Our algorithm works correctly but can be optimized from O(nยฒ) to O(n) time complexity!

LeetCode Submission (simplified version of 0(n)):

# @param {Integer} target
# @param {Integer[]} nums
# @return {Integer}
def min_sub_array_len(target, nums)
  return 0 if nums.empty?

  min_length = Float::INFINITY
  left = 0
  sum = 0

  nums.each_with_index do |num, right|
    sum += num

    # Shrink window from left as much as possible while maintaining sum >= target
    while sum >= target && left <= right
      min_length = [min_length, right - left + 1].min
      sum -= nums[left]
      left += 1
    end
  end

  min_length == Float::INFINITY ? 0 : min_length
end

The Problem: https://leetcode.com/problems/minimum-size-subarray-sum/description/

The Solution: https://leetcode.com/problems/minimum-size-subarray-sum/description/?submissionId=1712728937

https://leetcode.com/problems/minimum-size-subarray-sum/submissions/1712728937/


Happy Algo Coding! ๐Ÿš€

Introduction to Software Development Methodologies ๐Ÿ“Š: Part 1

Software development is not just about writing code; it’s about building high-quality, maintainable, and scalable systems that deliver value to users. To achieve this consistently, teams follow structured approaches known as software development methodologies. These methodologies provide a roadmap for planning, designing, developing, testing, and delivering software.

In this three-part blog series, we’ll explore key methodologies and best practices in software development, using Ruby and Ruby on Rails examples wherever appropriate.

๐ŸŒ What Are Software Development Methodologies?

Software development methodologies are structured processes or frameworks that guide the planning and execution of software projects. They help teams manage complexity, collaborate effectively, reduce risk, and deliver projects on time.

Common Goals of Any Methodology:

  • Define clear project scope and goals
  • Break down work into manageable tasks
  • Encourage communication among team members
  • Track progress and measure success
  • Deliver working software iteratively or incrementally

๐Ÿ’ผ Why Methodologies Matter

Without a methodology, software projects often suffer from unclear requirements, missed deadlines, buggy releases, or scope creep. A good methodology:

  • Increases team productivity
  • Ensures better quality and maintainability
  • Reduces time-to-market
  • Improves customer satisfaction

In Ruby and Rails projects, where rapid development is a key feature, following a methodology keeps things under control and makes collaboration more effective.

๐Ÿ“– A Brief Overview of Popular Software Development Methodologies

We’ll explore these in detail in Part 2, but here are the major ones:

1. Waterfall

A linear approach where each phase (Requirements โ†’ Design โ†’ Implementation โ†’ Testing โ†’ Deployment) happens one after another.

2. Agile

An iterative and incremental model that encourages adaptive planning, early delivery, and continuous improvement.

3. Scrum

A popular Agile framework that structures work in sprints and emphasizes team roles, ceremonies, and artifacts.

4. Kanban

A flow-based Agile method that uses visual boards to manage work and improve process efficiency.

5. Extreme Programming (XP)

Focuses on engineering excellence, including practices like pair programming, TDD, and continuous integration. Ruby and Rails communities highly embrace XP.

6. DevOps

Combines software development and IT operations to shorten the development lifecycle and deliver high-quality software continuously.

โœจ Ruby On Rails: A Natural Fit for Agile and XP

Ruby and Rails were built with developer happiness and productivity in mind. They naturally complement Agile and XP methodologies.

Example:

  • Ruby on Rails encourages convention over configuration, which speeds up development.
  • It supports Test-Driven Development (TDD) out of the box via tools like RSpec and Minitest.
  • Features like scaffolding align well with the iterative nature of Agile.

๐Ÿ”น Coming Up in Part 2

In the next part of this series, I’ll do a deep dive into each of the above methodologies, with pros, cons, and real-world use cases. I’ll also show examples of how Rails developers apply these in practice.


Stay tuned! ๐Ÿš€

Rails 8 + ActiveAdmin: The Propshaft vs Sprockets Dilemma ๐Ÿ˜ตโ€๐Ÿ’ซ

ActiveAdmin traditionally requires Sprockets, but there are actually several alternatives and modern approaches. Let me break down your options:

ActiveAdmin Asset Pipeline Options:

Current Status (2025):

  • ActiveAdmin 3.x still primarily designed for Sprockets
  • It has SCSS files with imports, mixins, and variables that need preprocessing
  • The gem’s CSS compilation expects Sprockets’ asset compilation pipeline

Alternative Approaches:

1. Keep Sprockets (Current Choice)

Pros:

  • โœ… Fully supported, zero configuration issues
  • โœ… All ActiveAdmin features work out-of-the-box
  • โœ… Stable and well-tested

Cons:

  • โŒ Older, slower asset pipeline
  • โŒ More complex than Propshaft
  • โŒ Goes against Rails 8 defaults

2. Hybrid: Propshaft + Manual CSS for ActiveAdmin

We could try keeping Propshaft for our main app and handling ActiveAdmin CSS manually:

ActiveAdmin traditionally requires Sprockets, but the landscape is evolving. Here are your realistic options in 2025:

Current Situation:

ActiveAdmin 3.x: Requires Sprockets (stable)
ActiveAdmin 4.0 beta: Propshaft support is experimental/problematic
Rails 8 default: ๐Ÿ†• Propshaft (faster, simpler)

https://github.com/activeadmin/activeadmin/releases

Our Options:

Option 1: Stay with Sprockets โญ (Recommended for now)

Pros:

  • โœ… Zero configuration issues
  • โœ… All ActiveAdmin features work perfectly
  • โœ… Battle-tested and stable

Cons:

  • โŒ Slower than Propshaft
  • โŒ More complex asset pipeline
  • โŒ Goes against Rails 8 defaults

Option 2: ActiveAdmin Assets Gem (Simplest alternative)

The activeadmin_assets gem was mentioned as a simple solution! Let me add this option:

# Add to Gemfile
gem 'activeadmin_assets'

Pros:

  • โœ… Zero Node.js dependency
  • โœ… Works with Propshaft
  • โœ… Pre-compiled ActiveAdmin assets
  • โœ… Simple one-line installation

Cons:

  • โŒ Can’t customize ActiveAdmin styles
  • โŒ Community-maintained (not official)

Option 3: ActiveAdmin 4.0 Beta + Propshaft โš ๏ธ (Experimental)

Based on the GitHub discussions, this is possible but complex:

# Rails 8 setup with Propshaft + ActiveAdmin v4 beta
rails new myapp -a propshaft
bundle add activeadmin -v=4.0.0beta15
bundle add cssbundling-rails -v "1.4.1"
bundle add tailwindcss-ruby -v "~> 3.4.17"
yarn add tailwindcss@^3.4.17  # ActiveAdmin uses TailwindCSS v3
rails generate active_admin:install
rails css:install:tailwind
yarn add @activeadmin/activeadmin@4.0.0-beta15
npm pkg set scripts.build:css="tailwindcss -i ./app/assets/stylesheets/active_admin.css -o ./app/assets/builds/active_admin.css --minify -c tailwind-active_admin.config.js"
./bin/dev  # Instead of rails server

Pros:

  • โœ… Modern asset pipeline (Propshaft)
  • โœ… ActiveAdmin v4 features

Cons:

  • โŒ Complex setup with many steps
  • โŒ Requires Node.js/Yarn (defeats the purpose)
  • โŒ Beta software (unstable)
  • โŒ TailwindCSS v3/v4 compatibility issues

Option 4: ๐Ÿ”„ Alternative Admin Gems

If you want to avoid the ActiveAdmin complexity entirely:

RailsAdmin:

gem 'rails_admin'
  • โœ… No asset pipeline issues
  • โœ… Works with Propshaft out of the box
  • โŒ Less customizable than ActiveAdmin

Trestle:

gem 'trestle'
  • โœ… Modern Bootstrap-based admin
  • โœ… Better Rails 8 compatibility
  • โŒ Smaller community

Adminterface (Deprecated):

  • ๐Ÿšซ No longer maintained (as shown in search results)

๐Ÿ† My Recommendation:

For our production app: Stick with Sprockets + ActiveAdmin 3.x

Why?

  1. Stability – Battle-tested combination
  2. Zero configuration issues
  3. Full feature set available
  4. Easy maintenance

The performance difference between Propshaft and Sprockets won’t significantly impact your admin interface, which is typically used by a small number of internal users.

๐Ÿ”ฎ Future Outlook:

  • ActiveAdmin v4 will eventually have better Propshaft support
  • Rails community is working on solutions
  • Node.js dependency trend for complex CSS is becoming standard anyway

Bottom Line: Don’t let the asset pipeline take over the application preferences. Our current Sprockets setup is perfectly fine for an admin interface! ๐ŸŽฏ

The Reality Check:

We completely replaced Propshaft with Sprockets for the entire application.

Current State:

  • โŒ Propshaft: Completely removed
  • โœ… Sprockets: Handles ALL assets (main app + admin)
  • โœ… Importmaps: Still working (unaffected)
  • โœ… Hotwire/Turbo: Still working (unaffected)

๐Ÿ—๏ธ How ActiveAdmin Works:

ActiveAdmin is NOT a Rails Engine. It integrates directly into your app:

  1. Routes: ActiveAdmin.routes(self) adds /admin routes to your app
  2. Assets: ActiveAdmin’s CSS/JS becomes part of your asset pipeline
  3. Controllers: ActiveAdmin generates controllers in your app’s namespace

It’s tightly coupled to your application, not isolated.

๐Ÿคทโ€โ™‚๏ธ So What Are Our Real Options?

Option 1: Accept Current Setup

What we have:

  • Modern Rails 8 with Importmaps + Hotwire โœ…
  • Sprockets instead of Propshaft โŒ (but works fine)
  • Full-featured admin interface โœ…

Option 2: Use activeadmin_assets Gem

# Replace current ActiveAdmin setup
gem 'activeadmin_assets'  # Pre-compiled assets
gem 'propshaft'           # Back to Rails 8 default
  • โœ… Get Propshaft back
  • โœ… Keep Rails 8 defaults
  • โŒ Can’t customize admin styles

Option 3: Build Custom Admin

Keep your Rails 8 purity but build admin from scratch:

  • โœ… Pure Rails 8
  • โŒ Weeks of development time

๐Ÿ” What activeadmin_assets Actually Does:

The activeadmin_assets gem doesn’t replace ActiveAdmin – it provides pre-compiled static assets for ActiveAdmin to work with Propshaft.

But here’s the critical issue for you:

๐Ÿšจ activeadmin_assets = NO Customization

If you use activeadmin_assets, you get:

  • โœ… ActiveAdmin functionality
  • โœ… Propshaft compatibility
  • โŒ ZERO ability to customize styles/interface

The assets are pre-compiled and frozen – you can’t modify colors, layouts, or styling.

Since We Want Customization:

We’re actually in the BEST setup possible right now!

Our Current Setup Gives You:

  • โœ… Full ActiveAdmin customization (styles, layouts, themes)
  • โœ… Modern Rails 8 (Importmaps, Hotwire, Turbo)
  • โœ… All ActiveAdmin features (filters, actions, forms)
  • โŒ Sprockets instead of Propshaft (minor trade-off)

Customization Examples We Can Do:

  • Custom CSS themes and colors
  • Layout modifications
  • Custom JavaScript behaviors
  • Brand styling and logos
  • Advanced form customizations

๐ŸŽฏ Reality Check:

There’s no solution that gives us:

  1. Full ActiveAdmin customization AND
  2. Propshaft AND
  3. Zero complexity

We have to pick 2 out of 3.

๐Ÿ’ก My Honest Last Decision:

Keep our current setup! We’re already using:

  • Modern Rails 8 patterns (95% of your codebase)
  • Importmaps and Hotwire (exactly as intended)
  • Sprockets only affects asset serving (invisible to users)

The Propshaft vs Sprockets difference won’t affect your product’s success, but losing admin customization will limit our UX.