Coder Legion - Recent posts tagged ruby

What Is Idempotency?

Fri, 30 Oct 2026 09:28:35 +0000

🚀 What Happens When Your API Receives the Same Request Twice?

Imagine a customer clicks “Pay Now” twice because the page freezes.

Or a payment gateway retries a request because it never received your response.

💥 Without proper protection, your application might charge the customer twice!

This is where Idempotency becomes essential.

🔍 What Is Idempotency?

Idempotency means that performing the same operation multiple times produces the same result as performing it once.

For example, if a client retries a payment request, the system should return the original result instead of creating another payment.

🛠️ How Do We Implement It in Ruby on Rails?

A common approach is using an Idempotency-Key.

The client sends a unique key with the request:

POST /api/v1/payments
Idempotency-Key: order-123-payment

Rails can use that key to identify duplicate requests.

Step 1: Add a database constraint

add_index :payments, :idempotency_key, unique: true

Step 2: Store the key with the payment

Payment.create!(
  idempotency_key: idempotency_key,
  amount: amount,
  status: "pending"
)

Important: This is only a simplified example. A production implementation must handle duplicate-key exceptions, concurrent requests, and retries safely.

You should also define what happens when the same key is reused with different request parameters.

For payment APIs, store and return the original result for a matching key rather than processing the payment again.

💎 Why Is Idempotency Important?

✅ Prevents Duplicate Payments — Avoid charging customers twice when requests are retried.

✅ Makes Retries Safer — Network failures become easier to handle.

✅ Improves API Reliability — Clients can retry requests without accidentally repeating business operations.

✅ Protects Background Jobs — Prevent duplicate emails, orders, or other side effects when jobs run more than once.

✅ Supports Distributed Systems — Helps manage unreliable networks and repeated messages.

⚠️ One Important Detail

Idempotency is not just checking whether a request has been received before.

You must handle concurrent requests, database transactions, unique constraints, and external service calls carefully.

For example, a database transaction alone cannot guarantee that an external payment provider won't charge a customer twice.

💡 The goal is simple: make retries safe, even when failures happen.

Because in real-world applications, requests will fail, networks will time out, and background jobs will retry.

Your architecture should be ready for it!

💬 How do you handle duplicate requests in your Rails applications?

RubyOnRails #API #Idempotency #BackendDevelopment #SoftwareArchitecture #DistributedSystems #WebDevelopment #SoftwareEngineering

Building RAG on PostgreSQL with Pgvector and Ruby on rails

Fri, 16 Oct 2026 18:17:18 +0000

🧠 Your Database Is Already a Vector Database

Most RAG tutorials start the same way: "First, spin up a vector database."

But Stop.

If you're on Rails, you already have PostgreSQL.
With the pgvector extension it can store and search embeddings and for most applications, that's the whole answer.

🐘 Setup is one migration

`enable_extension "vector"

add_column :document_chunks, :embedding, :vector, limit: 1536`

💎 And one line in your model

Gemfile

gem "neighbor"

class DocumentChunk < ApplicationRecord has_neighbors :embedding, dimensions: 1536, normalize: true end

🔍 Searching is just ActiveRecord

DocumentChunk .where(tenant: Current.tenant) .nearest_neighbors(:embedding, query_vector, distance: "cosine") .limit(6)

Scoped, chainable, joinable. A normal Rails query.

🚀 Why this beats a separate vector DB

1️⃣ No new infrastructure
Nothing extra to deploy, monitor, back up, or upgrade.

2️⃣ Transactional consistency
Embeddings commit in the same transaction as the record. Two systems can't drift apart.

3️⃣ Authorization you already trust
This is the big one. Retrieval almost always needs scoping by tenant, project, or permission. In Postgres that's a WHERE clause. In an external store it's metadata filtering you have to keep in sync with your auth model.
Get it wrong, and one customer's documents land in another customer's LLM prompt.

4️⃣ Real joins
Chunks plus their documents, authors, and timestamps in one query.

⚠️ Three things that will bite you

❌ Index opclass mismatch
vector_cosine_ops goes with cosine distance. Mismatch them and Postgres silently skips your index and sequential-scans the table.

❌ No similarity floor
Nearest neighbours are nearest, not relevant. Without a threshold, an unrelated question still returns chunks — which the model will happily use to hallucinate.

❌ Pure vector search
Embeddings are weak at exactly what users type literally: error codes, SKUs, invoice numbers. ERR_4012 and ERR_4013 are nearly identical in vector space.
Fix: hybrid search — pgvector + Postgres full-text, fused with Reciprocal Rank Fusion.

🎯 When to actually leave Postgres

Past roughly 5–10 million chunks, or when the vector workload starves your transactional workload for memory.
Until then, a dedicated vector database buys you one more service to operate and a second place for your authorization logic to be wrong.

Your database stays the source of truth. The vector index is a lookup layer on top of it.

💬 If you've shipped RAG in Rails — what pushed you off Postgres, if anything?

Elasticsearch with Ruby on Rails

Fri, 09 Oct 2026 06:22:39 +0000

🚀 Elasticsearch + Ruby on Rails: Beyond Database Queries

Ever noticed how searching millions of records can become slow and frustrating?

When your application needs fast, advanced, and intelligent search, Elasticsearch can make a real difference.

🔍 What is Elasticsearch?

Elasticsearch is a distributed search and analytics engine built on Apache Lucene. It helps applications search, filter, and analyze large amounts of data efficiently.

Unlike traditional database queries, it offers powerful full-text search, relevance scoring, and flexible filtering.

🛠️ How do we use it with Ruby on Rails?

Imagine you're building an e-commerce platform with thousands of products.

Users expect to search by product name, description, category, or even partial keywords — and get relevant results quickly.

With Rails, you can integrate Elasticsearch using gems such as elasticsearch-rails or searchkick.

For example, using Searchkick:

# Gemfile
gem "searchkick"

class Product < ApplicationRecord
  searchkick

  def search_data
    {
      name: name,
      description: description,
      category: category
    }
  end
end

Search products with:

Product.search("wireless headphones")

Instead of relying only on basic SQL matching, Elasticsearch can provide relevance-based results, typo tolerance, and advanced filtering.

Note: Elasticsearch must be installed and configured, and the data must be indexed before searching.

💡 Why use Elasticsearch?

✅ Faster Search — Search large datasets efficiently.

✅ Better Relevance — Rank results based on how closely they match the query.

✅ Typo Tolerance — Help users find results even when they misspell a word.

✅ Advanced Filtering — Combine full-text search with categories, prices, and other filters.

✅ Analytics & Aggregations — Analyze search trends and summarize large datasets.

⚠️ One important architectural decision

Elasticsearch is not a replacement for your primary database.

Use PostgreSQL or MySQL as your source of truth, and Elasticsearch as your search engine.

When Rails data changes, keep the search index synchronized — often through background jobs with Sidekiq — and account for indexing delays and failed jobs.

The goal isn't to replace SQL. It's to give your application a search experience that SQL alone may struggle to deliver at scale.

API Architecture

Mon, 05 Oct 2026 08:01:11 +0000

Here’s a concise LinkedIn-ready article focused on practical API architecture in Rails.

API Architecture: It’s More Than Just Endpoints

A well-designed API isn't simply about creating routes like:

GET /users
POST /orders

The real challenge is designing an architecture that remains secure, scalable, maintainable, and easy to integrate as the application grows.

️ How I approach API architecture with Ruby on Rails

A typical Rails API can be structured around clear layers:

Client → Routes → Controllers → Services → Models → Database

For example:

POST /api/v1/orders

The controller should handle the HTTP request and response, while the business logic can live in a Service Object.

Orders::Create.call(
  user: current_user,
  params: order_params
)

This keeps controllers thin and business logic easier to test and reuse.

Important architecture decisions

Versioning

/api/v1/...

API versioning allows you to evolve the API without immediately breaking existing clients.

Authentication & Authorization

Use mechanisms such as JWT, OAuth2, or token-based authentication, combined with authorization rules.

Consistent Responses

Define predictable JSON structures for:

Success responses
Validation errors
Authentication failures
API errors

Background Processing

Heavy operations shouldn't block the API request.

Rails + Sidekiq + Redis can move tasks such as emails, notifications, and data processing into background jobs.

Caching

Frequently requested data can be cached with Redis to reduce database load and improve response time.

Why good API architecture matters

A good architecture makes it easier to:

✅ Scale the application
✅ Add new API versions
✅ Integrate third-party systems
✅ Test business logic
✅ Maintain clean controllers
✅ Improve security
✅ Reduce technical debt

The goal isn't to build more endpoints.

The goal is to build an API that can evolve without becoming a bottleneck for the entire system.

RubyOnRails #Ruby #API #APIDesign #SoftwareArchitecture #BackendDevelopment #WebDevelopment #RESTAPI #SoftwareEngineering

One Rails App, Multiple Customers

Mon, 05 Oct 2026 08:00:48 +0000

Why Multi-Tenancy Matters

Imagine you are building a SaaS application.

You have 100 companies, but you don't want to deploy and maintain 100 separate applications.

That's where Multi-Tenancy comes in.

What is Multi-Tenancy?

Multi-tenancy allows a single application to serve multiple customers — called tenants — while keeping each tenant's data isolated.

For example:

                    Rails Application
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
       Tenant A         Tenant B         Tenant C
       Company A        Company B        Company C
          │                │                │
       Users/Data       Users/Data       Users/Data

Each company uses the same application, but should only be able to access its own data.

How can we implement it with Rails?

A common approach is adding a tenant_id to tenant-owned tables:

class User < ApplicationRecord
  belongs_to :tenant
end

Then queries are scoped to the current tenant:

current_tenant.users

For larger systems, another approach is database-per-tenant, where each customer gets a separate database.

The right strategy depends on your scale, security requirements, infrastructure, and operational complexity.

Why use Multi-Tenancy?

1️⃣ Lower Infrastructure Costs

One application can serve many customers instead of running separate deployments.

2️⃣ Easier Maintenance

Deploy features and bug fixes once instead of updating every customer environment.

3️⃣ Faster Scaling

You can scale application servers and background workers as the customer base grows.

4️⃣ Better SaaS Architecture

Multi-tenancy fits naturally with subscription-based products where many businesses share the same platform.

5️⃣ Centralized Development

One codebase means consistent features, security updates, and improvements across tenants.

⚠️ The important part

Multi-tenancy isn't simply adding a tenant_id.

You need to think about:

Data isolation
️ Authorization
️ Database architecture
⚡ Caching
Background jobs
Reporting
Tenant-aware integrations

A single missing tenant filter can become a serious data-isolation problem.

How you zip larger files in ruby

Mon, 03 Aug 2026 21:42:38 +0000

Easy way that compress files in ruby is using zip lib.

Zip::File.open('./compress.zip', create: true) do |zip|
  zip.get_output_stream("./stuff_to_ziped.pdf") do |f|
    f.puts File.read("./stuff_to_zip.pdf")
   end
end

When you need to zip larger files or when you need to perform any task that requires opening many files, good practice is to avoid loading all files into memory. To achieve this, you can use stream operations available in IO classes.

Let's look at the code above again but with a thread that monitory the memory for us.

Thread.new do
  loop do
    print "\r memory: %d MB" % "#{`ps -o rss= -p #{Process.pid}`.to_i/1024}\t"
  end
end

Zip::File.open('./compress.zip', create: true) do |zip|
  zip.get_output_stream("./stuff_to_ziped.pdf") do |f|
    f.puts File.read("./stuff_to_zip.pdf")
   end
end

Now you can see how much memory the program consumis until done. The method File.read load all bytes of file in memory. Lets see other implementation.

Thread.new do
  loop do
    print "\r memory: %d MB" % "#{`ps -o rss= -p #{Process.pid}`.to_i/1024}\t"
  end
end


Zip::File.open('./compactados.zip', create: true) do |zip|
	10.times do |i|
		zip.get_output_stream("./copy_#{i}.pdf") do |f| 
			input = File.new("./copy_#{i}.pdf")
			while !input.eof?
				f.puts(input.gets)
			end
		end
	end
end

Web "Hello World" in Ruby without RoR!

Mon, 03 Aug 2026 21:41:20 +0000

If you want to understand how things work beyond what's under the hood, the first good step is to try to write something from scratch. So, in this post, I will show you how to write a 'hello world' app for the web in pure Ruby. Above, you'll find the simple 'Hello World' code example.

class MyApp
 def say_hello
   "Hello World"
 end
end
MyApp.new.say_hello

Now we need to turn this code into a Rack app. Rack is an interface for developing web applications in Ruby. The structure of a Rack app looks like this:

run do |env|
  [200, {}, ["Hello World"]]
end

In this case, the code works like this:

class MyApp
 def say_hello
   "Hello World"
 end
end

myapp = proc do |env|
  [200, {'Content-Type' => 'text/plain'}, [MyApp.new.say_hello]]
end
run myapp

Run this using the rackup gem or another supported web server.(read more here)

rackup myapp.ru
--> Puma starting in single mode...
--> * Version 4.2.0 (ruby 2.6.5-p114), codename: Distant Airhorns
--> * Min threads: 0, max threads: 16
--> * Environment: development
--> * Listening on tcp://127.0.0.1:9292
--> * Listening on tcp://[::1]:9292
--> Use Ctrl-C to stop

You can access the app by typing in your browser. 127.0.0.1:9292.

Skip the RSpec examples you don't need: rspec-tracer 2.0 in pre-release

Tue, 12 May 2026 17:28:12 +0000

A ground-up rewrite of test-skip caching for RSpec, with pluggable storage, Rails-aware tracking, and a per-example tracks: DSL.

You change one model. You run bundle exec rspec. Twenty minutes later, every test in the suite has run again — including the 1,800 examples that don't touch that model.

This is the problem rspec-tracer solves. Cold run of a suite: everything runs. Second run with no edits: nothing runs. Edit one file: only the examples that depend on that file re-run.

The 1.x line has been on RubyGems since 2021. I just shipped a 2.0 pre-release after a 4-year gap and a 17-day rebuild. This post is the field guide for what changed and how to test it.

Install

Pre-releases require explicit opt-in. In your Gemfile:

# 2.0 is in pre-release. Pin to the pre-release version explicitly;
# switch to '~> 2.0' once 2.0.0 final ships.
gem 'rspec-tracer', '= 2.0.0.pre.1', group: :test, require: false

Or one-shot:

gem install rspec-tracer --pre

Then in your spec_helper.rb or rails_helper.rb, before any application code:

require 'rspec_tracer'
RSpecTracer.start

That's it for the basic install. Run your suite twice; the second run skips everything that didn't change.

What changed since 1.x

The 2.0 surface is rebuilt around an explicit input-taxonomy model (every test is a pure function of its inputs; cache invalidation is input-digest mismatch). What that translates to for users:

1. Pluggable storage

# Default: JSON (preserves 1.x layout)
storage_backend :json

# SQLite: single-file DB, MRI-only
storage_backend :sqlite

For large suites (5,000+ examples) the SQLite backend cuts cache-load time substantially. JRuby falls back to :json automatically with a one-time warn.

2. Pluggable remote cache (for CI)

The 1.x line had S3-only remote cache. 2.0 ships three backends:

# S3 (preserves the 1.x layout, including LocalStack support)
remote_cache_backend :s3, bucket: 'my-cache', prefix: 'rspec-tracer'

# Local filesystem (NFS / shared mount / dev cache)
remote_cache_backend :local_fs, path: '/mnt/shared-cache'

# Redis (with optional per-key TTL + PR-branches sidecar)
remote_cache_backend :redis,
  url: ENV['REDIS_URL'],
  ttl: 7 * 24 * 3600,
  prefix: 'rspec-tracer'

The CI flow (rake rspec_tracer:remote_cache:download / :upload) is preserved bit-for-bit. The only thing that changes is the backend you point at.

3. Per-example `tracks:` DSL

This is the headline new surface. RSpec metadata key:

RSpec.describe AdminController,
               tracks: { files: 'app/policies/**/*.rb', env: 'ROLE_CONFIG' } do
  it 'gates on the feature flag' do
    # ...
  end
end

Use cases the tracker can't auto-observe:

Config files baked at boot — Oj-loaded JSON / YAML that's read once and mmap'd; the IO hooks won't see runtime reads, so declared globs are the escape hatch.
Env-var branches — code that does if ENV['FEATURE_X'] == 'on'; flipping the env should invalidate the example.
Pre-compiled Ruby constants — values baked at boot that the per-example coverage delta can't see.

Cascade is union (parent + child both contribute), unlike RSpec's default metadata cascade which clobbers on shared keys.

4. `track_env(*names)` config DSL

Symmetric to track_files but for env vars every test depends on:

# In .rspec-tracer
track_env 'AUTH_TOKEN', 'DATABASE_URL', 'RAILS_*', '*_API_KEY'

Single-wildcard patterns supported: 'PREFIX_*', '*_SUFFIX', bare '*'. Patterns are expanded against the live ENV at config-load time; the persisted env_snapshot.json carries concrete keys only.

5. Rails preset

For Rails projects, the tracker has to attach inputs Coverage doesn't observe — views, locales, fixtures, factories, helpers, config YAML, schema. The preset handles this:

# In .rspec-tracer
track_rails_defaults

Opt out per category:

track_rails_defaults except: [:views, :locales]

Plus auto-detection: when ::Rails::VERSION is defined at RSpecTracer.start time, the engine attaches an ActionView template subscriber + an opt-in AR schema subscriber.

The ERB/Slim/Jbuilder tracking via render_template.action_view was the most-requested missing 1.x feature. It's the canonical path now: a view edit invalidates exactly the examples that rendered the partial.

6. `bin/rspec-tracer` CLI

Five sub-commands, all opt-in:

$ rspec-tracer doctor
OK   ruby:        ruby 3.3.10 (2026-04-18)
OK   rspec-tracer: 2.0.0.pre.1
OK   root:        /Users/me/projects/my-app
OK   cache_path:  /Users/me/projects/my-app/rspec_tracer_cache
INFO SimpleCov:   not loaded (this is fine; SimpleCov is optional)
OK   Rails:       7.2.0.1
OK   schema:      v3 (matches gem)
INFO remote_cache: not configured (skip)

$ rspec-tracer cache:info
Cache size: 14.4 MiB · last run: 2026-05-06T14:13:22Z · 12 runs retained

$ rspec-tracer cache:clear
Removed: rspec_tracer_cache/, rspec_tracer_coverage/, rspec_tracer_report/

$ rspec-tracer report:open
Opening rspec_tracer_report/index.html ...

$ rspec-tracer explain spec.foo_spec.rb_42
Example: spec/foo_spec.rb:42 - "GET /admin returns 403 for unauthenticated"
Status: re-run scheduled
Reason: Files changed (app/controllers/admin_controller.rb)
Dependencies (12):
  - app/controllers/admin_controller.rb [changed since cache]
  - app/policies/admin_policy.rb
  - config/locales/en.yml
  - ...

The CLI is opt-in for local dev convenience; the rake rspec_tracer:remote_cache:* tasks remain first-class for CI integration.

7. HTML + JSON reporters

The 1.x line had a single HTML reporter. 2.0 adds a JSON reporter for CI dashboards and a terminal-summary reporter that fires after every run:

rspec-tracer: 1887 examples tracked · 5 re-run · 1882 skipped (99% cached)
by reason: 5 Files changed
cache: /path/to/rspec_tracer_cache (14.4 MiB; +6.7 KiB vs prev run)
report: /path/to/rspec_tracer_report/report.json

For parallel_tests users: 1.x emitted reports per worker, then purge_worker_dirs! deleted them — leaving users with no usable output. 2.0 emits ONCE at the merged top-level location after all workers finish.

8. SimpleCov branch coverage now works

The 1.x caveat ("SimpleCov would not report branch coverage results even when enabled") is gone. The coverage-stack rewrite decoupled rspec-tracer's line-only emission from SimpleCov's branch tracking. Users who turned enable_coverage :branch off when adopting rspec-tracer 1.x can re-enable in 2.0.

9. Boot-time warns

For two common user-trust traps:

SimpleCov loaded but not started before RSpecTracer.start (load-order is part of the documented contract; the warn surfaces it instead of silently bolting onto a Coverage already in flight).
track_ar_schema_notifications enabled with use_transactional_fixtures defaulting to true (per-example BEGIN/COMMIT fires sql.active_record and attributes db/schema.rb to every AR-touching example; the warn points at the README "Narrow AR-schema attribution" guidance).

10. Schema-version field + Rails 8.0 + CI recipes

Schema-version field in last_run.json for explicit cross-version cache validation. Cache-shape changes bump the field; mismatched caches refuse-to-load with an info-level "cold run" log line.

Rails 8.0 is CI-gated (Ruby 3.2+). docs/CI_RECIPES.md translates the GitHub Actions cache pattern to CircleCI / GitLab CI / Buildkite / Heroku CI — the 4-component cache-key (runner.os + .ruby-version + lib/rspec_tracer/version.rb + Gemfile-hash) translates 1:1 across providers.

Migration from 1.x

The full guide is in UPGRADING.md. Headlines:

Ruby ≥ 3.1 is the floor (1.x supported Ruby 2.5+). Ruby 3.2 / 3.3 / 3.4 / 4.0 + JRuby 9.4 are CI-gated. Rails 7.0 / 7.1 / 7.2 / 8.0 + RSpec 3.12 / 3.13 are CI-gated.
Cache schema bump — first run on 2.0 is cold; warm caches resume on subsequent runs. Existing CI integration (the rake tasks, env vars, rspec_tracer_cache/ directory contracts) is preserved bit-for-bit.
Deprecated — four configs continue to work with one warn line each, slated for removal in 3.0: reports_s3_path / use_local_aws config DSL, and RSPEC_TRACER_REPORTS_S3_PATH / RSPEC_TRACER_USE_LOCAL_AWS env vars.
Removed — cucumber feature-file integration suite (contributor-facing only), Ruby ≤ 3.0 / Rails ≤ 6.x support, Windows.

Why pre-release

A 2.0 of a gem people use in their CI deserves a real testing window. The pre-release is on RubyGems with --pre opt-in; 2.0.0 final is targeted in ~2 weeks once the observation-window feedback is incorporated.

If you're a 1.x user: the migration is bundle update rspec-tracer after pinning the pre-release version, plus optionally adopting track_rails_defaults if you're on Rails. The first run is cold (cache schema cut); subsequent runs return to warm.

If you're new to rspec-tracer: try the cookbook recipes; the Quick start gets a fresh project running in ~5 minutes.

Where to send feedback

GitHub Discussions: the pre-release thread for usage questions, install reports, rough edges.
Issues: open one for bugs. Add the 2.0-feedback label if applicable.
Migration questions: comment on the discussion thread; I'll answer in the open so others see.

I'll cut a pre.2 if pre.1 surfaces blockers; otherwise 2.0.0.rc.1 in ~2 weeks, then 2.0.0 final after a final review window.

Repo: https://github.com/avmnu-sng/rspec-tracer
Release: https://github.com/avmnu-sng/rspec-tracer/releases/tag/v2.0.0.pre.1
Discussion: https://github.com/avmnu-sng/rspec-tracer/discussions/180

Thanks for reading. Bug reports + thoughts welcome.

I Built a Bash Script That Traces Code Faster Than Your IDE (And Saves AI Tokens)

Thu, 26 Mar 2026 17:19:50 +0000

You're debugging a Rails app. The bug is somewhere in process_payment. You could:

A) Open your IDE, wait for LSP to index, click through 12 files.

B) Paste the whole service into ChatGPT. Hope it doesn't hallucinate the call graph.

C) Run one command:

codetracer process_payment . --mode flow --scope

In under a second: where it's defined, every call site with enclosing method, every assignment, every place the return value goes — across all files.

I chose option C. So I built it.

What is codetracer?

A single-file bash script (~1400 lines) that traces symbols across Ruby and JavaScript/TypeScript codebases. No IDE, no LSP, no AI agent.

Requirements: bash 4+ (or zsh 5+) and ripgrep. That's it.

# Install
curl -fsSL https://raw.githubusercontent.com/mirzalazuardi/codetracer/main/codetracer.sh \
  -o /usr/local/bin/codetracer && chmod +x /usr/local/bin/codetracer

The Killer Feature: Case-Variant Expansion

Type a symbol in any naming convention. codetracer finds all forms automatically:

Input: processPayment

Searches simultaneously:
  process_payment      (snake_case)
  PROCESS_PAYMENT      (SCREAMING_SNAKE)
  processPayment       (camelCase)
  ProcessPayment       (PascalCase)
  process-payment      (kebab-case)

All these commands produce identical results:

codetracer process_payment
codetracer processPayment
codetracer ProcessPayment

No more "I searched for process_payment but the JS file uses processPayment" moments.

Five Modes for Different Questions

1. Where is it defined?

codetracer PaymentService . --mode def

Finds def, class, module, function, const =, async function, etc.

2. Who calls it?

codetracer send_email . --mode call --scope

Every call site with full scope chain:

app/services/order_service.rb:42:    send_email(user, receipt)
  scope -> mod Billing > cls OrderService > def complete_order:38

3. How does data flow?

codetracer current_user . --mode flow

Tracks: assignments, passed as argument, returned/yielded, mutations.

4. Which files touch it?

codetracer stripe_key . --mode file

File map with hit counts per file.

5. Everything at once

codetracer order_total . --mode full --scope

NEW: Rails Route Tracing

Just shipped this week. Trace a route through the full request lifecycle:

codetracer --action "OrdersController#refund" ./app

Output:

━━━ ROUTE TRACE: OrdersController#refund ━━━

OrdersController (app/controllers/orders_controller.rb)
├── before_action :authenticate_user!          :23  [ApplicationController]
├── before_action :set_order                   :8
├── def refund                                 :67
│   ├── params: :reason                        :68  [query]
│   ├── if @order.refundable?                  :69
│   │   ├── call: RefundService.call           :70
│   │   └── enqueue: RefundNotificationJob     :75  [async]
│   └── else                                   :77
│       └── render json: errors                :78
└── after_action :log_refund_attempt           :10

Callbacks, conditionals, params access, service calls, Sidekiq jobs — all in one tree. Perfect for understanding unfamiliar Rails controllers or creating sequence diagrams.

Trace directly from your curl files

Got a directory of curl scripts for testing your API? Point codetracer at them:

# Your existing curl file
cat api_tests/refund.sh

curl -X POST "http://localhost:3000/orders/123/refund?notify=true" \
  -H "Content-Type: application/json" \
  -d '{"reason": "damaged", "amount": 50.00}'

# Trace it
codetracer --route api_tests/refund.sh ./app

codetracer automatically:

Extracts the HTTP verb (POST) and path (/orders/:id/refund)
Converts numeric IDs to :id (123 → :id)
Extracts query params (notify) and JSON body keys (reason, amount)
Shows expected params in the trace output

Expected params from curl:
  query: notify
  body: reason amount

├── def refund
    ├── params: :reason    [query]  ← matches!

No more wondering "does this endpoint actually use the params I'm sending?"

Why Not Just Use AI?

I use AI daily. But every question you ask about code structure — "where is this defined?", "who calls this?" — costs tokens, takes seconds, and might be wrong.

codetracer gives those answers instantly, deterministically, for free.

Save Tokens When You Do Use AI

Instead of pasting 500-line files, extract only what matters:

# Get 60 focused lines instead of 2000+ raw lines
codetracer process_payment . --mode flow --scope 2>&1 | head -60

That's a 30x reduction in tokens.

The Scope Chain

This is my favorite feature. Every match shows its full nesting context:

codetracer process_payment . --mode call --scope

fixture_payment_service.rb:40:        process_payment(order, order.amount)
  scope -> mod Billing:5 > cls PaymentService:6 > def batch_process:38 > blk each:39

You instantly know: this call happens inside an each block, inside batch_process method, inside PaymentService class, inside Billing module.

No clicking through files. No mental stack tracing.

Works on macOS and Linux

Tested on:

macOS with bash 4+ or zsh 5+
Ubuntu/Debian
Arch Linux

# macOS
brew install ripgrep

# Ubuntu
sudo apt install ripgrep

# Optional: fzf for interactive mode, ctags for precise indexing
brew install fzf universal-ctags

Interactive Mode with fzf

codetracer render . --inter

Fuzzy-pick any match, preview context, press Enter to open in your editor.

Real Workflow Example

Debugging an unknown bug:

# 1. Where does this symbol exist?
codetracer process_payment . --mode file

# 2. Read the definition
codetracer process_payment . --mode def --ctags

# 3. Find callers and their context
codetracer process_payment . --mode call --scope

# 4. Trace data through the system
codetracer process_payment . --mode flow --scope --ctx 4

Four commands. Full picture. No IDE required.

Try It

# One-liner install
curl -fsSL https://raw.githubusercontent.com/mirzalazuardi/codetracer/main/codetracer.sh \
  -o /usr/local/bin/codetracer && chmod +x /usr/local/bin/codetracer

# Try it
codetracer YourClassName ./your-project --mode def

Links

GitHub: github.com/mirzalazuardi/codetracer

If this looks useful, I'd appreciate a star. And if you have feature requests or find bugs, issues and PRs are welcome.

Built for engineers who prefer a terminal over a GUI and a shell script over a language server.

Favourite IDE for Ruby Work?

Mon, 08 Dec 2025 01:33:41 +0000

Hey everyone!

Quick question for the Ruby folks here — what’s your IDE or editor of choice for day-to-day Ruby/Rails work?

Do you swear by RubyMine? Live inside VS Code with a handful of extensions? Or are you one of the brave souls still hacking away in Vim/Neovim? I’m curious not just what you use, but why you chose it. Speed? Tooling? Habit? Muscle memory?

It’d be great to hear the range of setups people rely on. Always interesting to see how different developers shape their workflow.

My Editor Journey: From Heavy IDEs to Plain Old Vim

Sun, 23 Nov 2025 23:27:42 +0000

I’ve been through a long parade of editors and IDEs over the years, and each phase almost feels like a snapshot of where I was as a developer at the time. Back at university the big names were NetBeans and Eclipse—heavy, clunky, but they got the job done and felt “proper” in an academic setting.

When I moved into the Ruby world, the tool everyone raved about was RubyMine (a JetBrains product). And for good reason: it did everything for you—refactors, navigation, inspections. For a while, it felt like the most grown-up way to write Ruby.

But I kept bumping into these YouTube videos of people practically gliding through code in Vim or Emacs. No mouse, no ceremony, just pure speed. They made it look like wizardry. Eventually curiosity got the better of me, and I decided to teach myself Vim. It was painful at first—when you start, you genuinely don’t know how to quit, which feels like a metaphor for the entire learning curve.

But once the modal editing philosophy clicked, something shifted. I started shaping my own config instead of relying on someone else’s mega-distribution. Every keybind had a purpose, every plugin earned its place, and over the years it became a tool that fit my hands perfectly. Today, for Ruby, I wouldn’t use anything else. Vim just feels like an extension of my brain.

That said, IDEs still have their place. If I’m writing Java, for example, a full JetBrains IDE is undeniably better for certain kinds of refactoring and analysis. Some languages just benefit more from all the tooling an IDE can provide.

But for my day-to-day coding, Vim is home.
Curious to hear what everyone else here is using—and what brought you to it.

How We Solved “Unable to Get Certificate CRL” in Rails: A Debugging Story

Thu, 13 Nov 2025 11:53:55 +0000

If you’ve been around Rails long enough, you’ve probably battled your fair share of SSL demons. But this one? This one had personality.

It was a Seahorse::Client::NetworkingError that failed only on macOS — yet worked perfectly inside Docker. The kind of “it works on my container” bug that makes you question every life choice leading up to this point.

So here’s the story of how we chased down a ghostly SSL error, only to discover that the real culprit was… OpenSSL itself.

⚠️ The Error

Seahorse::Client::NetworkingError
SSL_connect returned=1 errno=0 peeraddr=[...]
state=error: certificate verify failed (unable to get certificate CRL)

This popped up whenever our Rails app tried connecting to AWS S3 using the aws-sdk-ruby gem.

The Contradiction That Made No Sense

From the get-go, the bug refused to play by any rules of logic.

❌ It failed locally but
✅ Worked flawlessly in Docker

That told us one thing: the problem wasn’t our code. It was the environment. macOS and Docker’s Linux setup were behaving differently.

The “Wait, What?” Moment

We decided to test the SSL connection manually, expecting it to fail the same way:

openssl s_client -connect 52.219.66.109:443 -servername s3.ap-south-1.amazonaws.com < /dev/null

Result?

Verify return code: 0 (ok)

So, macOS’s OpenSSL tool had no problem verifying the certificate. But Rails (and the AWS SDK) still choked on it.

At this point, confusion levels were high. Coffee consumption was higher.

The Real Test — Inside the Rails Console

To rule out any system-level differences, we went straight into rails c:

require 'aws-sdk-s3'
s3 = Aws::S3::Client.new(region: 'ap-south-1')
s3.list_buckets

Result:

certificate verify failed (unable to get certificate CRL)

Boom. So the system OpenSSL was fine, but Ruby’s built-in OpenSSL (via Net::HTTP) was throwing a tantrum.

The Root Cause — A Policy Change in OpenSSL

That cryptic message — “unable to get certificate CRL” — turned out to be the key.

A CRL (Certificate Revocation List) is basically a “blacklist” for certificates that have been revoked. The problem? The AWS certificate didn’t actually have a CRL defined.

We checked with:

openssl s_client ... | openssl x509 -noout -text | grep "CRL Distribution Points"

Result:

X509v3 CRL Distribution Points:
# (empty)

Comparing environments made things click:

Environment	OpenSSL Version	Result
macOS (failing)	3.4.0 (new)	❌ Fails
Docker (working)	3.0.11 (stable)	✅ Works

Turns out, OpenSSL 3.4.0 introduced stricter validation rules. It now treats missing CRL entries as fatal errors — whereas the 3.0.x series simply shrugged and moved on.

So no, your Mac isn’t broken — it’s just being too helpful.

The Fixes — Two Paths to Sanity

After a lot of trial (and some error), we landed on two solid fixes.

Fix 1: The Local-Only (Insecure but Practical) Workaround

Since this issue only showed up in development, one quick way to move on is to tell AWS SDK to skip SSL verification locally.

Create: config/initializers/aws_ssl_workaround.rb

# WARNING: LOCAL DEVELOPMENT ONLY
# OpenSSL 3.4.0 enforces stricter CRL policies, so skip verification here.
if Rails.env.development?
  Aws.config.update(ssl_verify_peer: false)
end

✅ Pros:

Works instantly
Doesn’t affect production

⚠️ Cons:

Insecure (but fine for local development)

Fix 2: Match Environments (I tried this one!)

The better long-term solution is to make your local OpenSSL match Docker’s version.

Install an older OpenSSL (3.0.x):
```
brew install openssl@3.0
```

Reinstall Ruby:

rbenv uninstall 3.2.2
RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@3.0)" rbenv install 3.2.2

Reinstall gems:
```
gem install bundler
bundle install
```

Now your local Ruby is linked against OpenSSL 3.0 — just like Docker and peace is restored.

Confirmation & References

Turns out, we weren’t the only ones haunted by this ghost:

openssl/openssl#28758 — CRL verification failures in OpenSSL 3.6.0
ruby/openssl#949 — Net::HTTP failing due to stricter CRL rules

Takeaway

SSL errors can feel like black magic, but more often than not, they’re version mismatches in disguise.

So next time something works in Docker but not on your laptop, remember: sometimes it’s not your code, it’s just your OpenSSL being extra.

Thanks for reading! If you found this helpful, share it with a fellow developer who’s currently staring at an SSL error and losing their mind.

What’s your current Ruby setup?

Thu, 13 Nov 2025 01:44:02 +0000

Hey everyone!

Thought we’d kick things off with some introductions.

What’s your experience been like working with Ruby or Rails so far? Are you deep in a legacy app, or running shiny Rails 8 with all the trimmings?

I’ll start: I’ve been working with Ruby (on Rails) for over 10 years now — from scrappy greenfield startup apps to large-scale corporate systems. I’m curious to hear what versions (and horror stories!) you’ve got to share.

And if you’ve built something cool, show it off — we’d love to see it!

The && Fallacy: How --command Fixed VS Code Extensions in a Declarative Nix Shell

Tue, 21 Oct 2025 02:40:26 +0000

In the last article, we discussed the evolution of my development setup, focusing on how it became reproducible over time. It was originally written to document the process for my own amusement. Surprisingly, the stats tell a different story — apparently it resonated with enough people sharing the same pain. Over time, revisions were made alongside new discoveries, and I figured the journey was worth a retelling. Read on to find out about an unexpected milestone related to this very blog.

Cute illustration on the topic, by Microsoft Copilot

Up until the last article, we managed to get a rather consistent setup with home-manager to manage development tools, and subsequently retired tools like pyenv and rbenv with the use of nix-develop. Little did I know, it wasn’t the end of the story. This time, we are tackling a new issue — the lack of nix-develop support of the Visual Studio Code extensions for development work in Ruby.

Forcing the ruby-lsp extension to source an external Gemfile as detailed was a hackish solution. Although it worked for a bit, most of the time the extension failed to initialize the language server. Observing how inconsistent the behavior is, something must be wrong. On the other hand, setup seems impeccable, tests were passing, and projects were building fine too.

Unfortunately, not much luck with the team’s desired formatter.

It wouldn’t work in the editor.

A type checker extension called sorbet is also common, and that too wouldn’t work at all. Considering the team doesn’t type annotate the code, I quickly dismissed and deactivated the extension. Combining this with the previous problem where ruby-lsp failed to work, the itch grew as time passes on.

Photo by Abu Saeid on Unsplash

Worse still, a formatter that doesn’t work at all times yields errors in the automated checks on every push.

Something was definitely wrong, was it because of VSCode failing to pick up the environment in a nix-develop session? My initial attempts to fix the flake file to include a command to activate the language server properly as shared. Still, none of them seemed to work reliably.

How To: Use vscode-ruby-lsp with flake.nix based dev enviroment · Issue #1851 · Shopify/ruby-lsp

After hitting walls enough times, I decided to post my setup to the discussion board to seek for help.

The Log Line That Clicked Differently

A problem can only be solved if we can clearly define it. We know the setup is failing, but what caused it? Interestingly enough, achieving the problem definition is a series of unlikely coincidences. It almost felt like solving a jigsaw puzzle, where each seemingly unrelated piece ultimately leads to the solution. So what are the missing pieces stalling our progress in understanding what went wrong?

Let’s start with the discovery of previously unused --command argument for nix-develop.

Initially, the gemini-generated flake file for the nix-develop sessions contained some commands to start my favorite fish shell. The snippet on starting a new shell was taken out from the previous discussion as it was somewhat unrelated. It was rather complicated and bound to fail because I was expecting it to work differently in different scenarios. Naturally, I wanted to simplify it somewhat, and eventually I learned about the --command argument.

Instead of relying on a clever (or dumb, depending on how you perceive it) detection logic, I could start a new fish shell session with

nix develop /path/to/flake/dir --command fish

Besides a shell, it could also run any command in the environment defined by the flake file. Discovering this was a crucial step toward fixing the launch of the ruby-lsp language server in the editor.

Remember I posted an SOS message on the discussion board? Luckily, it caught the attention of Vinicius Stock, the project owner. Helpfully enough, he pointed out that an external Gemfile is not necessary, and asked me to check if the language server is launched properly. With that, I checked the log and found this line

2025-07-27 16:56:30.669 [info] (ship_it) Running command: `nix develop /Users/jeffrey04/Projects/home-manager/devenvs/ruby-3.3 && ruby -EUTF-8:UTF-8 '/Users/jeffrey04/.vscode-oss/extensions/shopify.ruby-lsp-0.9.31/activation.rb'` in /Users/jeffrey04/Projects/ship_it using shell: /Users/jeffrey04/.nix-profile/bin/bash

Despite seeing the log multiple times before, now that I know about the --command argument, the same line clicked differently. Does the ruby command after the && operator run in the nix-develop session? Validating in this case is rather easy, just run

nix develop /path/to/flake/dir && ruby --version

Oops, why am I being dropped to a new shell session? Let me exit the session, and sure enough, the ruby command refers to the version offered by the operating system.

❯ nix develop ~/Projects/home-manager/devenvs/ruby-3.3 && ruby --version
warning: updating lock file "/Users/jeffrey04/Projects/home-manager/devenvs/ruby-3.3/flake.lock":
• Added input 'nixpkgs':
    'github:NixOS/nixpkgs/544961dfcce86422ba200ed9a0b00dd4b1486ec5?narHash=sha256-EVAqOteLBFmd7pKkb0%2BFIUyzTF61VKi7YmvP1tw4nEw%3D' (2025-10-15)
(nix:ruby-3.3-env) wukong:ib-vpn jeffrey04$
exit
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.x86_64-darwin24]

Photo by Matias Malka on Unsplash

Clearly, the assumption that the command following the && operator is flawed from the very beginning. With this revelation, we can finally define what the problem is — the language server is not properly launched. In this case, all we need to do is to replace the boolean AND operator into --command.

Easy to say, but implementation is a challenge for someone who has no experience with vscode extension development like myself.

And this is exactly when vibe-coding is useful, with a clear problem definition and goal, the solution was just a prompt or two away with the help of gemini-cli. As expected, the patch worked flawlessly.

Firstly, add a new enum entry to ManagerIdentifier in vscode/src/ruby.ts

export enum ManagerIdentifier {
  Asdf = "asdf",
  Auto = "auto",
  Chruby = "chruby",
  Rbenv = "rbenv",
  Rvm = "rvm",
  Shadowenv = "shadowenv",
  Mise = "mise",
  RubyInstaller = "rubyInstaller",
  NixDevelop = "nix-develop", # add this line
  None = "none",
  Custom = "custom",
}

Then a new case in the runManagerActivation method

case ManagerIdentifier.NixDevelop:
  await this.runActivation(
    new NixDevelop(this.workspaceFolder, this.outputChannel, this.context, this.manuallySelectRuby.bind(this)),
  );
  break;

Followed by a new module at vscode/src/ruby/nixDevelop.ts that contains the activation logic:

import * as vscode from "vscode";

import { VersionManager, ActivationResult } from "./versionManager";

export class NixDevelop extends VersionManager {
  async activate(): Promise<ActivationResult> {
    const customCommand = this.customCommand();
    const command = `nix develop ${customCommand} --command ruby`;
    const parsedResult = await this.runEnvActivationScript(command);

    return {
      env: { ...process.env, ...parsedResult.env },
      yjit: parsedResult.yjit,
      version: parsedResult.version,
      gemPath: parsedResult.gemPath,
    };
  }

  private customCommand() {
    const configuration = vscode.workspace.getConfiguration("rubyLsp");
    const customCommand: string | undefined =
      configuration.get("customRubyCommand");

    return customCommand || "";
  }
}

Lastly, enable the option forrubyVersionManager in vscode/package.json

        "rubyLsp.rubyVersionManager": {
          "type": "object",
          "properties": {
            "identifier": {
              "description": "The Ruby version manager to use",
              "type": "string",
              "enum": [
                "asdf",
                "auto",
                "chruby",
                "none",
                "rbenv",
                "rvm",
                "shadowenv",
                "mise",
                "nix-develop", // add this line
                "custom"
              ],

Don’t forget about the actual config (omit the rubyLsp.customRubyCommand if flake.nix is in the workspace)

"rubyLsp.rubyVersionManager": {
    "identifier": "nix-develop"
},
"rubyLsp.customRubyCommand": "/Users/jeffrey04/Projects/home-manager/devenvs/ruby-3.3",

The patch is definitely not perfect, and it is reusing the optional customRubyCommand configuration item to define where the directory containing the flake file is. Yet, considering this likely affects only a small group of users, I don’t see a need to introduce a new configuration field for the purpose. Contributions are definitely welcome at the submitted pull request, as it has been stalling for months.

For the sorbet part, I managed to get it working one day out of boredom. Most of the Ruby code I have access for now is not type-annotated, so the effort is purely for fun. A quick and dirty way to do so, is building the language server application directly, and configure vscode as follows

"sorbet.enabled": true,
"sorbet.selectedLspConfigId": "without-bundler",
"sorbet.userLspConfigs": [
    {
        "id": "without-bundler",
        "name": "sorbet",
        "description": "Launch locally compiled sorbet",
        "command": ["/path/to/sorbet", "typecheck", "--lsp", "--dir=/path/to/project"]
    }
]

For some reason I needed to --disable-watchman flag in the command too, but as there’s no real need for now I am not going to dig further.

There you have it, with simplified flake files (removing the detection logic to start fish shell) and invoking fish shell explicitly with --command, and patches and hacks to enable the ruby toolings, we finally have a functional setup for development work in Ruby. Seeing the pull request being stalled for months (and their bot closed my PR recently due to inactivity) does make me upset for a little bit. Moving forward I may need to consider maintaining a fork for it as it does affect my work.

Stalled PR, Sudden Payoff: The Two Timelines

Photo by engin akyurt on Unsplash

Patches to the ruby-lsp were submitted in the late July, and I was hoping to start drafting this article when it received a review. Unfortunately, that didn’t happen. I was caught up with my new job and several major family issues while waiting on the PR. Things finally settled down for a little bit, and I should be back to a relatively more predictable routine. Hopefully this translates to a more consistent publishing schedule for KitFu Coda.

As for the unexpected milestone teased in the beginning, it is about a talk I am about to deliver during the upcoming PyCon Malaysia. My mentor encouraged me to submit for the CFP and it somehow went through. If you are interested in applying AsyncIO in projects, do feel free to drop by and say Hi. For reference, it is based on the articles I published earlier, as linked below.

I also discussed briefly with my supervisor in one of our 1 on 1 sessions, mainly to check on any necessary approvals or conflict of interest. He was incredibly supportive about it and offered some tips on presenting ideas to a wider audience. As I am new to Ruby, he also briefly explained how the language approaches asynchronous programming. On a lighter note, he’s even been checking on my preparation progress (zero so far), especially in recent sessions!

With this article checked off in my TODO, I can finally allocate some time on the preparation work. I sometimes feel like I’m running on an energy tank whose maximum capacity depletes as we age. These days, even finding time to game is a challenge. I feel bad for my character in Xenoblade X and I wonder if I’ll ever have time for the new Pokémon Legends Z-A game I’m about to purchase.

Finally, I would like to thank everyone for the support, especially to everyone who reads my work here. Though I have not been publishing much, since starting this technical writing project opens up fascinating new opportunities. Besides scoring a new job, I also started exploring scripted video making, and now a talk. I am thankful and hope to inspire more people through this trying time.

Thanks again for reading, I shall write again soon.

Throughout this journey, Gemini served as a valuable editorial companion, helping refine my prose. However, the voice and code remain entirely my own. I welcome your feedback and recommendations in the comments below, and invite you to subscribe to my Medium for more content on my development adventures!

Welcome to the Ruby & Rails Community

Wed, 01 Oct 2025 23:12:42 +0000

Hey everyone. Welcome to our brand-new Ruby & Rails group! This is a space for anyone working with Ruby — whether you’re wrangling ActiveRecord callbacks, crafting APIs, or pushing the edges of what Rails can do in 2025.

The goal here is simple: share articles, swap stories, and learn from each other. If you’ve got a question, an aha-moment, or just something cool you built, drop it in — chances are someone else will benefit (or at least laugh in sympathy).

We want a community where all Rubyists feel at home — from those hacking together their first Sinatra app to folks scaling Rails to handle thousands of requests per second. The only rule: be helpful, be respectful, and bring your curiosity.

So grab your favourite editor (yes, even if it’s VS Code — we’ll only judge you quietly ) and let’s start building a Ruby community worth being part of. Welcome aboard!

Feature Flags | Controlled Chaos in Production

Tue, 09 Sep 2025 19:51:24 +0000

Feature flags are a way of life when developing software. They let you deploy code to production without immediately exposing it to users — like flipping a switch without blowing the fuse.

In practice, they're used to:

Ship features incrementally
Test changes in production with internal users
Run A/B tests or multivariate experiments
Deliver bespoke functionality to specific customers (not my favourite approach, but hey, sometimes we have to pick our battles)

Feature flags introduce flexibility — but also the responsibility to manage them well. Left unchecked, they can become a tangle of forgotten toggles, quietly rotting your codebase from within.

Let’s take a look at one of the more robust feature flag services out there.

LaunchDarkly

One of the more popular services (at least in my limited experience) is LaunchDarkly. It allows you to create and manage feature flags, define targeting rules (e.g., which users get what), and view flag usage analytics — including which flags are no longer being used.

That last bit is more useful than it sounds. Stale flags can linger for months or even years, adding dead weight to your app and making the logic harder to follow. Being able to identify and prune them is a big plus.

Here’s a basic integration pattern for using LaunchDarkly in a Rails app:

module FeatureFlag
  class << self
    def for(entity)
      @entity = entity
      self
    end

    def feature_a? = check_for("feature-a", default: true) # this default will make sense shortly
    def feature_b? = check_for("feature-b")
    def feature_c? = true # hard-coded flag (sometimes needed)

    private

    attr_reader :entity

    def check_for(flag_name, default: false)
      return false unless entity.present?

      ld_client.variation(flag_name, entity_context(entity), default)
    end

    def ld_client
      @ld_client ||= Rails.configuration.ld_client
    end

    def entity_context(entity)
      LaunchDarkly::LDContext.create(
        {
          key: entity.identifier, # a unique identifier for the entity
          kind: entity.type       # usually "user", but could be "account", etc.
        }
      )
    end
  end
end

This pattern gives you a central place to check feature availability in your app. You might wire this into your controllers, services, or views like so:

if FeatureFlag.for(current_user).feature_a?
  render :new_feature_version
else
  render :legacy_version
end

It’s readable, testable, and keeps your flag logic out of the weeds.

Handling Flags in Test and Development Environments

Since LaunchDarkly is an external service that communicates via HTTP, you definitely don’t want your test suite making live requests every time it runs. That’s just asking for flakiness and slow feedback loops.

Instead, we can use a mock client in the test environment to simulate feature flag behavior without hitting the actual API. Here’s a simple example I popped into our lib folder:

module LaunchDarkly
  class MockLdClient
    def initialize(*) = true

    def initialized? = true

    def variation(_key, _user, default) = default
  end
end

This mock client always returns the default value passed into the variation method — making it trivial to control feature behaviour explicitly in your tests.

But wait — why not just put LaunchDarkly into "offline" mode in the test environment, like we do below for development?

Good question. While offline: true does prevent real network calls, it still requires the full LaunchDarkly SDK to be initialized — which adds unnecessary overhead and dependencies to your test suite. By using a lightweight mock client instead, you get a few key benefits:

Faster tests — no SDK initialization, no config loading, just a plain Ruby object
Zero external dependencies — the mock removes the need to load the LaunchDarkly gem at all in tests
Simpler control — it's easier to stub or extend the mock for edge cases if needed
Isolation — your tests won't break due to SDK upgrades or changes in default behaviours

In short, the mock client keeps your test environment lean and focused. It’s a small abstraction that pays for itself in speed and stability.

With that in place, in your LaunchDarkly initializer (config/initializers/launch_darkly.rb), you can wire it in like so:

require "#{Rails.root}/lib/launch_darkly/mock_ld_client.rb"

case Rails.env
when "test"
  Rails.configuration.ld_client = LaunchDarkly::MockLdClient.new("FAKE API KEY")
when "development"
  config = LaunchDarkly::Config.new(offline: true)
  Rails.configuration.ld_client = LaunchDarkly::LDClient.new(ENV['LD_KEY'], config)
else
  Rails.configuration.ld_client = LaunchDarkly::LDClient.new(ENV['LD_KEY'])
end

In the test environment, we avoid any HTTP calls by using the mock client.

In development, we set LaunchDarkly into offline mode. This disables all outbound network traffic and ensures your app doesn't hang or fail due to a misconfigured API key. You can still control the outcome of flags by setting the default values in your FeatureFlag methods — which is usually more than enough for local dev.

This setup gives you full control and isolation in non-prod environments, with zero reliance on external calls. Win-win.

Some Other Options

While this post focuses on LaunchDarkly, there are plenty of other options — some open-source, some more opinionated, and some simpler to get going with.

Here are a few worth considering:

Flipper – Powerful, flexible, and actively maintained. Can use a variety of backends (Redis, ActiveRecord, etc.) and integrates with a slick UI via Flipper Cloud.
Rollout – A battle-tested gem that’s been around for a while. Simpler API, great for percentage rollouts and user targeting.
Flipflop – Great for toggling features via a web UI. Good for admin-driven flags or feature previews.

Which one to use depends on your needs — whether you want self-hosted vs. SaaS, need advanced targeting and analytics, or just want a simple way to toggle features in development.

Parting Thoughts

Feature flags give you control, flexibility, and faster feedback loops — but like anything powerful, they need to be managed responsibly. Treat them like temporary scaffolding, not permanent fixtures. Set reminders to clean them up. Document what each flag does and who owns it. And when possible, limit the number of active flags in your system at a given time.

If you’ve had war stories with forgotten flags or misconfigured rollouts, I’d love to hear them. Otherwise, happy toggling.

Better Sidekiq Classes

Thu, 28 Aug 2025 23:31:09 +0000

Sidekiq is pretty much the go-to solution for enqueuing jobs for background processing when working on a Ruby-based project. It's simple to implement, has a clear DSL, and is well-supported by common testing frameworks like RSpec. That being said, and I may be nitpicking, but the standard implementation examples do add a little extra overhead if you wish to be more flexible with your job business logic, and additional test setup is required.

The "normal" way

Given we want a little background job that updates a user's name and any other business logic needed (to keep the example simple), we could create a standard Sidekiq job with that logic and call it from our code as such:

class UpdateUserJob
  include Sidekiq::Job

  def perform(user_id, name)
    user = User.find(user_id)
    user.update!(name: name)
    # .. additional business logic here
  end
end

UpdateUserJob.perform_async(1, "bob") # perform the job as soon as possible
UpdateUserJob.perform_in(5.minutes, 1, "bob") # delay the processing by 5 minutes

This is simple enough. But what if we want to test the logic being performed inside this job? Firstly, we'd need to update our spec_helper to let it know what to do with a job. If you're using RSpec, you might even need to add the rspec-sidekiq gem for additional configuration and matcher options. A classic-looking spec for this job might look something like this:

it "updates the user" do
  UpdateUserJob.perform_async(1, "bob")
  expect(UpdateUserJob.jobs.size).to eq(1)
  UpdateUserJob.drain
  expect(User.find(1).name).to eq("bob")
end

We need to drain the job before we can test the result of its work. Alternatively, we could wrap the test inside one of the Sidekiq testing helper methods:

it "updates the user" do
  Sidekiq::Testing.inline! do
    UpdateUserJob.perform_async(1, "bob")
    expect(User.find(1).name).to eq("bob")
  end
end

This does work as expected however it does leave a little to be desired. We have to remember to do this whenever testing job logic (the number of times I've had to search through previous specs to remind myself of the syntax), it adds a few extra lines to the tests which are not necessary and there is a spec performance hit as well.

The "use case" way

So, what options do we have? Well, the first option would be to extract the logic performed by the job into a class which we would then pass the job attributes to for processing. That way we can independently test the business logic without having to mess with background workers and the like. I have used various names for these classes, Use Case, Resource, or Library to name a few (use whatever best suits you and your conventions). Our new job would look something like this:

class UpdateUserJob
  include Sidekiq::Job

  def perform(user_id, name)
    UpdateUserUseCase.new(user_id, name).call
  end
end

class UpdateUserUseCase
  def initialize(user_id, name)
    @user_id = user_id
    @name = name
  end

  def call
    user = User.find(@user_id)
    user.update!(name: @name)
    # .. additional business logic here
  end
end

Now, when it comes to testing, we could just forgo testing the actual job class as it does nothing except pass on some arguments to a plain old Ruby object. We can just test the class directly. Sidekiq is also already extensively tested so there is little point in testing whether the jobs on the queue have increased or not unless you are expecting new jobs to be created as a knock-on effect of your business logic.

it "updates the user" do
  UpdateUserUseCase.new(1, "bob").call
  expect(User.find(1).name).to eq("bob")
end

The added benefit to doing it this way is that you have a plain old Ruby object that you can call independently and inline in your code elsewhere should the need arise. For instance, you may want to defer the processing to the background when handling a mass import of data, however, when being performed as a single HTTP request to your API, you could wish to do it inline.

The downside to this is that we now, however, have had to create an additional class to provide this flexibility. That means, if we wish to keep this convention going, for each Job class, there would be a corresponding UseCase class. What if we could take this idea one step further? What if we could turn our Job class into a plain old Ruby object right from the start? Let's rewrite our UpdateUserJob class.

The "runner" way (with POROs)

Let's pretend you had never heard of Sidekiq or background queues, and you want to write some code to perform a specific task. For the sake of convention, I have ended the following class name with "Job" to match previous examples however by syntax definition, it is no longer what we would call a classic "job". It is now just a Plain Old Ruby Object (PORO; identical to our previous UpdateUserUseCase).

class UpdateUserJob
  def initialize(user_id, name)
    @user_id = user_id
    @name = name
  end

  def call
    user = User.find(@user_id)
    user.update!(name: @name)
    # .. additional business logic here
  end
end

With that in place, we need to set up some sort of mechanism to have this code be run by Sidekiq in our background queue. We can introduce a simple class to wrap the sidekiq calls, allowing us to inject our custom job class with its arguments. To not conflict with the Sidekiq namespace, I have created the Runners module which will run this code for me (side note: no matter what project I've worked on in the past, I always seem to use these "runner" style classes for various things).

 # Cannot figure out why this code block fails to format correctly here on CoderLegion
module Runners
  class Sidekiq
    include ::Sidekiq::Job

    sidekiq_options(retry: 3, backtrace: true, queue: "default")

    def perform(job_class_name, *args)
      Kernel.const_get(job_class_name).new(*args).call
    end

    def run(job_class, *args)
      self.class.perform_async(job_class.to_s, *args)
    end

    def run_in(delay_in_seconds, job_class, *args)
      self.class.perform_in(delay_in_seconds, job_class.to_s, *args)
    end
  end
end

And with that, we have everything we need to be able to throw plain old Ruby classes into the background for processing. If we wish to run our business logic inline, we simply run

UpdateUserJob.new(1, "bob").call

but if we want to delegate the processing to the background queue, we can send it off immediately or delay it

Runners::Sidekiq.new.run(UpdateUserJob, 1, "bob") # perform the job as soon as possible
Runners::Sidekiq.new.run_in(5.minutes, UpdateUserJob, 1, "bob") # delay the processing by 5 minutes

Bells & Whistles

Now that we have our lovely Sidekiq runner class, we can embellish it with a couple final bells and whistles. We might want to add / override the sidekiq_options on demand instead of being stuck with the previous hard-coded options. Perhaps we prefer using keyword arguments in our method definitions for the added clarity and ability to insert the arguments in any order. And maybe, we would like the job names in the Sidekiq UI to be a little more descriptive as to the actual job they are running so that we don't have to go digging through the arguments list to find specific jobs.

 # Cannot figure out why this code block fails to format correctly here on CoderLegion
module Runners
  class Sidekiq
    include ::Sidekiq::Job

    DEFAULT_OPTIONS = { retry: 3, backtrace: true, queue: "default" }

    def perform(job_class_name, *args)
      if args in [Hash]
        # This handles the case of keyword arguments
        job_class_name.constantize.new(**args.first.symbolize_keys!).call
      else
        # This handles the case of basic arguments
        job_class_name.constantize.new(*args).call
      end
    end

    def initialize(options = {})
      self.class.sidekiq_options(DEFAULT_OPTIONS.merge(options))
    end

    def run(job_class, *args)
      update_display_class(job_class)
      self.class.perform_async(job_class.to_s, *args)
    end

    def run_in(delay_in_seconds, job_class, *args)
      update_display_class(job_class)
      self.class.perform_in(delay_in_seconds, job_class.to_s, *args)
    end

    private

    def update_display_class(job_class)
      self.class.sidekiq_options.merge!("display_class" => "#{job_class} [#{self.class.name}]")
    end
  end
end

In essence, you can now define your background job classes as basic Ruby objects, execute them inline, or transfer them to Sidekiq for background processing via our Runner. The main requirement is maintaining a consistent DSL with your job classes, such as implementing a mandatory call (or equivalent: perform or execute) method. (Kudos to my friend Kris for the original idea.)

Scaling Sidekiq in Ruby on Rails: Best Practices, War Stories, and WTF Moments

Mon, 25 Aug 2025 00:27:16 +0000

Imagine that your Rails application is running smoothly. Users are satisfied, payments are processed, emails are sent out, and reports are produced. Sidekiq feels like magic.

Then one Friday evening (because production issues always happen on Fridays), you check the Sidekiq dashboard ????

Jobs are piling up faster than your interns can say, “Did we forget to add sidekiq_options retry: false again?”

Welcome to Sidekiq at scale—where background jobs stop being background and start being your entire life.

Here are some lessons I've learned from implementing Sidekiq at scale in production, along with metrics and real-world examples.

1. Keep Jobs Small and Fast

Jobs should be atomic and quick. A 5–10 second job is already too long in most production systems.

Bad example:

class ReportJob
  def perform(user_id)
    user = User.find(user_id)
    generate_pdf(user)          # CPU-heavy
    upload_to_s3(user)          # I/O-heavy
    send_email(user)            # External API
  end
end

If this fails halfway, the entire job retries.

✅ Better:

class GeneratePdfJob < ApplicationJob
  def perform(user_id)
    PdfGenerator.call(User.find(user_id))
  end
end

class UploadReportJob < ApplicationJob
  def perform(file_path)
    S3Uploader.call(file_path)
  end
end

class SendReportJob < ApplicationJob
  def perform(user_id, report_id)
    ReportMailer.with(user_id:, report_id:).deliver_now
  end
end

Chain jobs with callbacks or Sidekiq batches.

2. Idempotency is Non-Negotiable

Jobs will run at least once, sometimes more. If jobs aren’t idempotent, you’ll double-charge customers or send duplicate emails.

Instead of:

order.mark_as_paid!
send_receipt(order)

Do:

order.update!(status: "paid") unless order.paid?
ReceiptMailer.send(order).deliver_later unless order.receipt_sent?

3. Use Queues Strategically

Don’t dump everything into default. Separate workloads:

critical → user-facing (emails, webhooks, payments)
default → normal jobs (notifications, syncs)
low → heavy, non-urgent (reports, exports, ETL)

sidekiq.yml:

:queues:
  - [critical, 5]
  - [default, 3]
  - [low, 1]

4. Monitor Everything

Visibility is critical at scale:

Sidekiq Web UI for queue depth & retries

SQL snippet to monitor retries:

SELECT count(*)
FROM sidekiq_jobs
WHERE queue = 'default'
AND retry = true;

5. Control Concurrency

More threads ≠ better throughput. High concurrency can overwhelm Postgres or external APIs.

✅ Start with concurrency = 2–5x your CPU cores.

:concurrency: 15

6. Redis is Your Heartbeat

Redis is the single point of truth for Sidekiq.

Use dedicated Redis (not shared with cache/session store)
Monitor memory & latency

7. Smart Retries Only

Default retries (up to 25) can flood your system. Customize them.

class MyJob
  sidekiq_options retry: 3

  def perform
    ExternalService.call!
  rescue ExternalService::InvalidCredentials
    # Don’t retry, just fail fast
    raise Sidekiq::Shutdown
  end
end

8. Deploy with Process Separation

Don’t run one mega Sidekiq instance. Separate by queue type.

bundle exec sidekiq -q critical,5 -q default,2
bundle exec sidekiq -q low

9. Dead Jobs are Zombie Failures

Dead jobs = silent failures.

bundle exec sidekiqctl clean --all

Or query them in Redis:

Sidekiq::DeadSet.new.size

10. Autoscale or Suffer

In Kubernetes, ECS, or Heroku, autoscale workers on queue latency:

Scale up if latency > 30s
Scale down if latency < 5s

11. Chain Jobs for External API Pagination

Sometimes, the firehose comes from outside your app. A classic case: syncing a huge dataset from a third-party API that only gives you paginated results.

If you naively fetch all pages in one job, you’ll hit rate limits, blow up memory, and make retries a nightmare.

✅ Better: chain jobs page by page. Each job handles one page, then enqueues the next, until the API says you’re done. That way:
Jobs stay tiny and idempotent.

Failures retry gracefully without restarting the whole sync.
You respect API rate limits with backoff and jitter.

You can fan out each page’s items to dedicated jobs for massive throughput.

Example:

class SyncExternalPage
  include Sidekiq::Worker
  sidekiq_options queue: :sync, retry: 10

  def perform(cursor = nil)
    response = ExternalClient.fetch_page(cursor: cursor)

    response[:items].each do |raw|
      UpsertExternalItem.perform_async(raw) # idempotent per item
    end

    if response[:next_cursor]
      # Chain the next page
      self.class.perform_in(1, response[:next_cursor])
    else
      Rails.logger.info("Sync complete ✅")
    end
  end
end

class UpsertExternalItem
  include Sidekiq::Worker

  def perform(raw)
    ExternalRecord.upsert(
      { external_id: raw["id"], name: raw["name"] },
      unique_by: :index_external_records_on_external_id
    )
  end
end

This pattern lets you chew through millions of external records without drowning your system in retries or hitting API bans.

Conclusion

Sidekiq is incredibly robust, but at scale, you need production-grade practices:

Keep jobs small, fast, idempotent
Prioritize with queues
Monitor latency & retries
Tune concurrency & Redis
Use autoscaling to survive traffic spikes
Chain jobs for external API pagination to handle massive datasets gracefully

With these practices, you can confidently handle millions of jobs per day without breaking a sweat.

✍️ Your turn: what’s your worst Sidekiq horror story? Did you also accidentally email your entire user base at 3am?

JuggleBee’s Great Leap – Data Migration, ActiveStorage, and Production Readiness (Part 2)

Sun, 24 Aug 2025 10:52:32 +0000

Now that we had a deployable app, I set up a staging server using my new favourite provider, Hetzner (not a sponsor, lol), spun it up, and witnessed a “fully functional” skeleton of JuggleBee. Stage 1 of the migration plan was complete.

Now came the real meat and potatoes of the project — actually hydrating the new app with all of its production data. We’re talking over 50,000 images, countless database records, and security credentials… the works. This is the part where a missed step could mean broken listings, missing files, or downtime. No pressure.

In case you missed Part 1, we covered:

Why I started fresh on Rails 8 instead of doing incremental upgrades.

Migrating core models/controllers/services to modern Rails conventions.

Swapping Sprockets for importmaps and modernizing the JavaScript setup.

Replacing Sidekiq + Redis + whenever with ActiveJob + SolidQueue.

Moving deployments to Kamal 2 with Traefik and Let’s Encrypt.

Catch up on it here: JuggleBee’s Great Leap – Rebuilding a Rails 4 App in Rails 8 (Part 1)

Now—back to the post.

The Daunting Database Migration

Legacy JuggleBee had been coasting along happily on Postgres 9.6 — which, back in 2016, was the latest and greatest. Fast forward to today and it’s long past its sell-by date, with official support ending in November 2021. Upgrading wasn’t just about keeping up with the times; Postgres 17.5 brings some serious perks:

Native JSON field type support.
Incremental backups with pg_basebackup --incremental, slashing backup time and storage usage.
Noticeable performance gains from better memory management, indexing, and partitioning.
Improved observability via enhanced EXPLAIN options and richer stats views.
…and more.

It was a no-brainer to upgrade, but the version gap meant one wrong move could corrupt thousands of user, auction, and invoice records. That made reliable backups non-negotiable before touching a single byte. Luckily, I already had a manual backup process baked into my deploy routine. Here’s the script (feel free to steal any of the scripts in my posts):

#!/bin/bash

DB_CONTAINER=($(sudo docker ps | grep postgres | awk '{print $NF}'))
BACKUP_NAME=dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql
BACKUP_FOLDER=db_backups
KEEP=10

# Dump the database into a backup sql file
echo "Creating the database dump..."
docker exec -t $DB_CONTAINER pg_dumpall -c -U postgres > $BACKUP_NAME
echo "Database dump created."

echo "Moving database backup to backup folder..."
mkdir -p $BACKUP_FOLDER
mv $BACKUP_NAME $BACKUP_FOLDER
echo "Backup moved to backup folder."

echo "Deleting old releases..."
(cd $BACKUP_FOLDER && (ls -t | head -n $KEEP; ls) | sort | uniq -u | xargs rm -rf)
echo "Backup stored."

One catch: pg_dumpall (used above) tries to dump everything — including Postgres cluster-wide settings — which can be version-specific and cause headaches on import. For a major version jump, you want pg_dump, which targets a single database and avoids the version mismatch landmines.

For the migration, I only needed to change the docker command we executed - with the added ENV vars, that is:

DB_USER=db_user
DB_PASSWORD=db_password
DATABASE_NAME=database_name

# ...

docker exec -e PGPASSWORD=$DB_PASSWORD -t $DB_CONTAINER \
    pg_dump -U $DB_USER $DATABASE_NAME > $BACKUP_NAME

With the new backup in hand, importing into Postgres 17.5 went off without a hitch — no edits, no drama. Honestly, I was braced for a fight given the version gap, but the data was simple enough (and avoided fancy Postgres features) that it just… worked. A rare and pleasant surprise in a project full of moving parts.

Listing Image Migration

Unlike the data migration before it, migrating all the listing images (just shy of 50,000!) came with its own set of headaches. The legacy setup used CarrierWave with a custom uploader and fixed S3 paths, which worked fine at the time but wasn’t exactly future-proof. Since I was already upgrading to Rails 8, it made sense to tackle this technical debt head-on and move to ActiveStorage — effectively retiring these gems:

carrierwave
fog-aws
mini_magick

… and replacing them with image_processing for post-processing.

In the old days, uploads required creating an “Uploader” class and mounting it on a model. For example:

# app/models/image.rb
class Image < ActiveRecord::Base
  mount_uploader :aws, ImageUploader
end

# app/uploaders/image_uploader.rb
class ImageUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick
  storage :fog

  process resize_to_fill: [850, 850]

  version :thumb do
    process resize_to_fill: [280, 280]
  end

  def store_dir
    "listings/#{model.listing_id}/#{model.id}"
  end
end

With ActiveStorage, uploaders and hard-coded S3 paths are gone. You simply declare the attachment in your model (after setting up config/storage.yml):

class Image < ApplicationRecord
  has_one_attached :file do |attachable|
    attachable.variant :thumb, resize_to_limit: THUMB_DIMENSIONS, preprocessed: true
  end
end

That takes care of future uploads — but what about migrating the 50,000+ legacy images stored in the old bucket? The image.aws field plus CarrierWave’s store_dir gave me the exact file path to each image. I then wrote a script to:

Download each image from the legacy bucket.
Re-upload it through ActiveStorage so it generates its own hashed storage path.
Skip already-migrated images to allow safe re-runs.

Here’s the script in all its glory (run synchronously to avoid AWS rate limits — which meant a cool 4 hours of migration time):

#!/usr/bin/env ruby

require_relative '../config/environment'
require 'aws-sdk-s3'
require 'stringio'

OLD_S3_BUCKET = Rails.application.credentials.dig(:old_aws, :bucket)
OLD_S3_REGION = Rails.application.credentials.dig(:old_aws, :region)
OLD_S3_ACCESS_KEY_ID = Rails.application.credentials.dig(:old_aws, :s3_key)
OLD_S3_SECRET_ACCESS_KEY = Rails.application.credentials.dig(:old_aws, :s3_secret)

# Optional: skip already migrated images
SKIP_EXISTING = true

s3 = Aws::S3::Client.new(
  region: OLD_S3_REGION,
  access_key_id: OLD_S3_ACCESS_KEY_ID,
  secret_access_key: OLD_S3_SECRET_ACCESS_KEY
)

puts "Starting image migration..."

Image.find_each do |image|
  begin
    if SKIP_EXISTING && image.file.attached?
      puts "Skipping Image #{image.id} (already attached)"
      next
    end

    # Construct old S3 key from uploader logic - your path here
    key = "listings/#{image.listing_id}/#{image.id}/#{File.basename(image[:aws].to_s)}"

    obj = s3.get_object(bucket: OLD_S3_BUCKET, key: key)

    image.file.attach(
      io: StringIO.new(obj.body.read),
      filename: File.basename(key),
      content_type: obj.content_type || 'image/jpeg'
    )

    puts "Migrated Image #{image.id} (Listing #{image.listing_id})"
  rescue Aws::S3::Errors::NoSuchKey => e
    warn "Image #{image.id} missing in old bucket: #{key}"
  rescue => e
    warn "Failed to migrate Image #{image.id}: #{e.class} - #{e.message}"
  end
end

puts "Migration script finished"

Four hours later, we were in business — all images were now managed by ActiveStorage.
Future uploads are handled automatically, thumbnails are generated on demand, and the whole setup is cleaner and easier to maintain.

Credentials & Security

You might have noticed the use of Rails.application.credentials in the previous script. That’s new territory — Rails encrypted credentials didn’t exist back in 4.2.

Back then we had secrets.yml, which stored everything in plain text and was meant to be excluded from Git. In theory, you’d inject it during deploy with whatever tooling you used. In practice… I was lazy. My deploys were manual, the repo was private, and I just checked them straight in. Big no-no. Thankfully, Bitbucket never got hacked — but let’s just say this setup wouldn’t pass any kind of security audit.

Rails 5.2 introduced encrypted credentials — finally, a way to store secrets in plain text locally while Rails encrypts them with a master key. That master key stays out of Git and gets injected during deploy. Much better.

Fast forward to today, and Kamal (my de facto deployment tool) takes it a step further with built-in support for pulling secrets straight from password managers like Bitwarden, 1Password, or LastPass. That means my Rails master key, database credentials, and other environment variables can live safely in Bitwarden, and Kamal just grabs them during deploy. No manual copying, no “where did I put that key?” moments, and no plain-text secrets hanging around in the repo.

Here’s an example using Bitwarden via the CLI. This snippet fetches all secrets and assigns them to variables in .kamal/secrets:

SECRETS=$(kamal secrets fetch --adapter bitwarden-sm all)

KAMAL_REGISTRY_PASSWORD=$(kamal secrets extract KAMAL_REGISTRY_PASSWORD $SECRETS)
RAILS_MASTER_KEY=$(kamal secrets extract RAILS_MASTER_KEY $SECRETS)
POSTGRES_USER=$(kamal secrets extract POSTGRES_USER $SECRETS)
POSTGRES_PASSWORD=$(kamal secrets extract POSTGRES_PASSWORD $SECRETS)

The only catch: you’ll need to have the Bitwarden CLI installed and authenticated on every machine you deploy from. It’s a one-time setup, but totally worth it for the peace of mind of never having to worry about leaked secrets again.

Lessons Learned

Looking back, a few big takeaways stood out:

Scripts are your best friend. Whether it’s a database dump, image migration, or credentials setup, having a repeatable script means you can run it, tweak it, and run it again without reinventing the wheel. It also removes a ton of mental overhead when you’re juggling multiple moving parts.
Test migrations in staging — thoroughly. Moving to PostgreSQL 17.5 could have been a disaster if I’d gone straight into production. Running the full migration end-to-end in a safe environment gave me confidence and caught subtle issues before they ever touched live data.
Expect the cleanup phase. Even after the “big ticket” migrations were done, staging revealed a laundry list of smaller fixes — broken image links, JavaScript load order issues, outdated gem calls, and other gremlins. None of these were major individually, but together they took nearly two weeks to iron out. Build that buffer into your timeline.
Take the opportunity to ditch technical debt. CarrierWave, fog-aws, Sidekiq, Redis… all of these had served me well for years, but replacing them with ActiveStorage and SolidQueue means fewer dependencies to maintain, fewer services to monitor, and a cleaner architecture.
Security deserves equal billing with features. Rails encrypted credentials plus Bitwarden CLI integration finally dragged my secrets management into the modern age. No more plain-text secrets in Git. Enough said.
Modern Rails is worth the leap. From importmaps to Kamal, the tooling around Rails 8 makes deployment, scaling, and maintenance dramatically simpler than what I was doing in 2015.

Closing thoughts

And with that, JuggleBee officially joined the modern Rails era.

This wasn’t just a version bump — it was a full-stack rejuvenation.
The app runs faster, the infrastructure is leaner, and I finally have a deployment pipeline I can trust at 2 a.m. without crossing my fingers.

Was it worth skipping incremental upgrades? Absolutely. Starting fresh on Rails 8 gave me a clean slate to rebuild only what mattered, using tools that will keep JuggleBee humming for years to come.

If you’ve been sitting on a legacy Rails app, staring down the upgrade path and wondering if it’s worth the effort — it is. Just plan your migrations, test them in staging, and embrace the opportunity to shed some old weight while you’re at it.

JuggleBee’s now live on Rails 8 / Ruby 3.4.3 / PostgreSQL 17.5, with ActiveStorage handling thousands of images, Bitwarden keeping our secrets safe, and Kamal making deployments a one-command affair.

Now it’s time to step away from the terminal, grab a cold beer, and actually enjoy the thing I’ve been rebuilding over the last month — until the next big upgrade comes along.

JuggleBee’s Great Leap - Rebuilding a Rails 4 App in Rails 8 (Part 1)

Thu, 21 Aug 2025 08:06:05 +0000

JuggleBee was born in 2015. It was Namibia's first online auction platform and is still one of the biggest today. I built it with Ruby on Rails 4.2 on Ruby 2.2. It sat there, rock-solid and stubbornly stable, only needing the occasional dust-off and minor tweak over the years. At various points in time, I thought about upgrading the various versions; however, I was stuck between a rock and a hard place — in order to upgrade Ruby, I had to upgrade Rails, and vice versa. The idea of incremental upgrades felt like a nightmare — two battlefronts to fight on, Ruby on one side and Rails on the other.

Fast forward to 2025. With the arrival of my daughter, I acquired a smattering of free time interspersed with sleepless nights. The perfect time to finally bite the bullet, bring JuggleBee into the 21st century (you know what I mean), and get these upgrades done. After much pondering and planning, only one realistic option remained... incremental upgrades would take months with constant patching between every version bump; I would have to take the leap from Rails 4.2 straight to Rails 8, with Ruby hopping from 2.2 to 3.4.3. It was quite the journey, and what follows is a breakdown of the challenges and learnings I made along the way.

Starting Fresh

Not to blow my own horn or anything, but I was in a pretty good place with this migration plan. The codebase of JuggleBee was intentionally built with self-contained business logic components, defining a clear separation of concerns. The models and controllers were not overly bloated, with liberal usage of "service objects" performing the more complicated logic, and an added separation of logic between my controllers and views using the "view decorator" pattern. This architecture made the copy-pasta approach almost… dare I say… fun. But let’s not kid ourselves — a jump from Rails 4.2 to 8 is no walk in the park.

As part of the rails new process (after installing the latest Ruby and necessary Rails gems), and before the true code migration could begin, I just needed an empty, runnable project with the necessary gems installed. I appended my old Gemfile with the auto-generated one, removing all locked versions to ensure the latest compatible versions were installed. I also identified irrelevant and dead gems, removing those and replacing them with alternatives where necessary (more detail on this later).

Reading into each of the default gems specified by the rails new generator gave me a good understanding of what the current Rails stack looks like. I didn’t need all of it, so some were commented out, but I did take some of the new suggestions into account. Puma, for example, replaced Unicorn, which I was previously using. I could also get rid of God, in the non-divine sense, as I no longer needed to monitor my server state manually. All in all, this whole process didn’t take more than an hour or so.

Models, Controllers, Services & Views (in that order)

These being purely Ruby code made it the easiest place to start. Even though we jumped up from Ruby 2.2 to 3.4.3, not all that much in the core language changed. Twas Rails that was the most behind. For example, JuggleBee was developed before the abstract ApplicationRecord class made its way into the Rails architecture!

Models

The models were the easiest to migrate over, as they already had a smattering of unit tests behind them. First, though, we had to get the database up and running. Spoiler alert: I was also updating our Postgres version from 9.6 to 17.5 as part of this big update. The old migration files were fossils — brittle, outdated, and utterly unfit for a modern Rails 8 app. The simplest solution was to drop a pg_dump of the current database (just on my local copy of the now legacy JuggleBee) and import it, generating the schema.rb. I could now copy across my models and test them out in the rails console.

Some of the updates required to get things up and running were:

belongs_to is now a required atribute. I have a home-grown version of polymorphism which allows a Listing to be either a Product or Auction and the belongs_to on these associations are optional, so I had to update these associations accordingly (*side note: a refactor waiting to happen*). So,
```
belongs_to :auction
belongs_to :product
```
becomes
```
belongs_to :auction, optional: true
belongs_to :product, optional: true
```
I had a couple of instances of update_attributes (very selective. Given they bypass validations, they were used with extreme caution) which is now deprecated and had to be changed to update.
Deprecated validation methods such as validates_presence_of :name needed updating to validates :name, presence: true sort of changes.

As for the views, the gems I used (haml-rails, redcarpet, simple_form, cocoon, etc) are all still actively maintained and required no changes at all — a very pleasant surprise.

Controllers

Next up were the controllers. Thanks to my use of service objects for the bulk of complex logic, migrating controllers was mostly painless. Rails 8 is stricter, and that’s where most of my changes were required. While bringing over controllers, I also began migrating the service objects they called upon, which are POROs and required almost no changes.

The main updates included:

Params passed to background jobs now must be valid JSON. This was especially relevant for controllers triggering email or background tasks.
Controller filters were renamed to actions (before_filter → before_action).
Controller hooks like before_action should come after the method they reference, not at the top of the file (a style guideline enforced in modern Rails apps).
redirect_to :back was replaced with redirect_back fallback_location: root_path (or an appropriate fallback path).
The responders gem is no longer included in Rails, so respond_with calls were rewritten using respond_to blocks.

All in all, the MVC migration was more about cleaning things up and embracing modern Rails conventions rather than fighting major incompatibilities.

JavaScript Modernization

This is where things started to get spicy — the kind of spicy where you wonder if you just bit off more than you can chew. So much has changed in the front-end assets side of things. JuggleBee leverages jQuery (thankfully I dodged the CoffeeScript bullet) with Sprockets as the asset pipeline. Modern Rails favours importmaps as the default asset manager and pipeline, and keeping with the spirit of rejuvenating JuggleBee and bringing it up to speed, I signed up to it too. This allowed me to replace a bunch of gems which added various front-end features, such as chartkick, masonry and bootstrap with the importmaps pin alternative. Some libraries had to remain as CDN imports in my layout file, due to the order at which these JavaScripts got initialized and loaded by the DOM.

My suite of JavaScript classes also needed a bit of love and attention. The Sprockets

//= require

statements were replaced with

import

and my classes now had to export themselves so that they could be loaded as ES modules. All the files had to be relocated from app/assets/javascripts/ to app/javascript/. The way we add our JavaScript base file into our application view layout also had to change slightly, going from

<%= javascript_include_tag "application" %>

<%= javascript_importmap_tags %>

Even though jQuery is considered a bit long in the tooth, given the plethora of really solid UI frameworks like Vue and React, I opted to keep my reliance on it for the time being. It still works, is actively maintained, and trying to replace it now would be a whole new kettle of fish. An adventure for another day.

Background Jobs & Scheduling

This area was one of the biggest wins in the entire migration. JuggleBee had the “classic” background processing setup: Sidekiq + Redis + whenever (for cron). It worked fine for years, but it always felt a little… heavy, like lugging around a toolbox just to tighten a single screw. Sidekiq required its own container, Redis was a hungry beast that always felt like it was asking for more memory, and whenever meant fiddling with cron jobs and ensuring everything stayed in sync across deploys. It worked, but it was yet another moving part in an already aging stack.

Enter SolidQueue — a gem that ships with Rails 8, built to replace Sidekiq-like setups with something that is both simpler and more tightly integrated with ActiveJob. The real beauty? No Redis. SolidQueue uses the same database you already have (Postgres in our case) to manage job queues, which meant I could drop an entire service and reclaim a chunk of server memory.

Here’s what this meant for JuggleBee:

No more Sidekiq configuration, container management, or Redis headaches.
The whenever gem (used for cron scheduling) could be thrown out too, thanks to SolidQueue’s built-in recurring.yml.
Background jobs now feel like a natural part of Rails — no extra glue required.

To put it in perspective, my stack went from:

Rails App + Sidekiq + Redis + whenever + cron

to:

Rails App + SolidQueue

That’s it. Beautiful, minimal, and a lot less to maintain.

Another chef’s kiss moment was how little code I had to change. Most jobs migrated over with minimal tweaks — the biggest adjustment being that job arguments must be JSON-serializable. This meant replacing keyword arguments with hashes like:

EmailJob.perform("MyEmailClass", {"from" => current_user.name, "subject" => "Hello there"})

instead of:

EmailJob.perform("MyEmailClass", from: current_user.name, subject: "Hello there")

It was one of those rare upgrades where less really is more. Dropping Redis and cron alone made this whole migration feel worth it.

Infrastructure & Deployment

For years, deployment was powered by a custom shell script I wrote. It wasn’t flashy, but it was reliable and got the job done. It handled atomic releases, cleaned up old deployments, built Docker images, restarted containers, and even maintained a cache for faster updates. For a single-developer project like JuggleBee, it was the perfect balance of simplicity and control.

Here’s the core of that script:

#!/bin/bash

branch=${1:-master}
cwd=/home/ubuntu
repo_url=your_repo_here
revision=master
keep=5
timestamp=$(date +%s)
cache=$cwd/.git_cache
releases=$cwd/releases
mkdir -p $releases
previous=$releases/$(ls $releases/ -t | head -n 1)
release=$releases/$timestamp

if [ ! -d $cache ] ; then
        git clone $repo_url $cache
fi

echo "downloading latest source code from $branch..."
mkdir -p $release
(cd $cache && git gc --prune=now && git remote prune origin && git fetch origin && git reset --hard origin/$branch && git archive $revision | tar -x -c $release)

echo "release timestamp is: $timestamp ($release)"

echo 'building docker images...'
/bin/bash -c "(cd $release && docker compose -f docker-production.yml build)"

if [ $? -eq 0 ]
then
        if [[ $previous != "" ]] ; then
                echo 'stopping previous containers...'
                /bin/bash -c "(cd $previous && docker compose -f docker-production.yml stop && docker ps -a -q --filter='status=exited' | xargs docker rm)"
        fi

        echo 'restarting application...'
        /bin/bash -c "(cd $release && docker compose -f docker-production.yml up -d)"

        echo 'deleting old releases...'
        (cd $releases && (ls -t | head -n $keep; ls) | sort | uniq -u | xargs rm -rf)

        echo 'creating symlink.'
        rm $cwd/current-release
        ln -s $release $cwd/current-release

        echo 'deploy complete.'
fi

Honestly, this script could have kept soldiering on for years… until Kamal walked in like the cool new kid who makes your old tricks look ancient. It wasn’t broken — far from it — but Kamal is like having a personal DevOps engineer in your terminal. It takes all the things I cared about (Dockerized deploys, atomic releases, rollbacks) and adds extra superpowers I didn’t even realize I needed.

Introducing Kamal 2

Kamal is a server provisioning and deployment tool built specifically (but not limited to) Rails apps. It automates a ton of tasks that my script didn’t — and one of the most significant changes? No more Nginx.

Kamal ships with a built-in Traefik proxy that handles all your routing and SSL certificates out of the box. No more tinkering with nginx.conf files or restarting a separate webserver. One less dependency chewing through RAM and one less thing to break at 2 am.

Here’s what Kamal brings to the table:

kamal setup: installs Docker, Git, and all required dependencies on your server.
kamal deploy: builds your Rails app into a Docker image, pushes it to your registry, and runs it on the server.
Traefik proxy with SSL (via Let’s Encrypt): you get HTTPS without lifting a finger.
Accessory management: want Postgres or Redis? Kamal spins them up as Docker containers.
Scaling: need more capacity? add another container in deploy.yml and Kamal will route traffic automatically.

The impact of this was huge. I went from managing Docker builds, old release directories, and an Nginx webserver, to just running one command. There’s something almost unsettling about how smooth it is — I felt like I was missing steps at first, like forgetting my keys when leaving the house.

Wait, that’s it? Did I actually deploy? Did I forget something? Oh… it’s done already. Huh.

This wasn’t just a convenience win — it was a dependency detox. Between dropping Nginx here and killing Redis with SolidQueue earlier, my infrastructure got a lot lighter, faster, and cheaper to run. Kamal didn’t just evolve my old script — it rendered half of its logic unnecessary.

Half Way There

With the new Rails 8 foundation in place, JuggleBee has already shed a lot of its old skin. We’ve modernized the models and controllers, swapped out a creaky asset pipeline for importmaps, retired Sidekiq, Redis, and cron in favor of SolidQueue, and traded a homegrown deployment script (solid as it was) for the convenience and power of Kamal 2. The app is lighter, faster to deploy, and much easier to maintain — but we’re not done yet.

Getting the Rails 8 app running and deployable was only half the battle. Now comes the rest of the journey:

Migrating data from a legacy PostgreSQL 9.6 database to a fresh PostgreSQL 17.5 instance.
Replacing CarrierWave with ActiveStorage and migrating all user-uploaded files into a new S3 bucket.
Locking down credentials with Rails encrypted secrets and Bitwarden CLI.
Cleaning up leftover code smells, finalizing test coverage, and polishing the overall performance of the new stack.

That’s some of what Part 2 will cover — all the finishing touches, the unexpected hurdles, and the final steps that took JuggleBee from a Rails 4 relic to a lean, modern, and production-ready Rails 8 app.

Stay tuned for Part 2, where the migration story continues.

Getting Started with Ruby & Rails on Windows

Sat, 02 Aug 2025 05:51:11 +0000

If you're on Windows, you can still develop with Ruby and Rails . Let's walk through your options and the steps involved.

There are two main options:

️ Option A: Use WSL (Recommended)

WSL stands for Windows Subsystem for Linux — it lets you run a full Linux environment on Windows without dual-booting or using a virtual machine.

Best for: Developers who want a smooth Rails experience and compatibility with Linux tools.

Steps to Set Up Rails with WSL

Install WSL
```
wsl --install
```
This will install Ubuntu by default.

Update and install dependencies inside Ubuntu terminal

sudo apt update && sudo apt upgrade
sudo apt install curl git build-essential libssl-dev libreadline-dev zlib1g-dev

Install Ruby (using a version manager like rbenv or rvm)

curl -fsSL https://github.com/rbenv/rbenv-installer/raw/main/bin/rbenv-installer | bash
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

rbenv install 3.3.0
rbenv global 3.3.0

Install Rails
```
gem install rails
```
Verify installations
```
ruby -v
rails -v
```

️ Option B: Use RubyInstaller for Windows (Native Ruby)

If you don’t want to use WSL, you can install Ruby directly in Windows.

Steps for Native Windows Setup

Download Ruby Installer
Go to: https://rubyinstaller.org

Download a version like Ruby+Devkit 3.3.X.
Run the Installer
- Make sure you check the box that says “Add Ruby executables to your PATH”.
- Choose to run ridk install after installation (this installs DevKit, MSYS2).
Install Rails
Open Command Prompt or PowerShell and run:
```
gem install rails
```
Check Versions
```
ruby -v
rails -v
```

Note: Some gems (e.g., pg for PostgreSQL) can be tricky to install on native Windows due to compilation issues. That’s why WSL is highly recommended.

Database Setup for Windows

SQLite is supported out of the box.
PostgreSQL: Download from https://www.postgresql.org/download/windows/
You’ll need to install the dev libraries if using native Ruby (which can be difficult).

Common Tools

Tool	Windows Option
Ruby	RubyInstaller OR rbenv via WSL
Rails	`gem install rails`
Git	Git for Windows
Code Editor	VS Code
Terminal (WSL)	Ubuntu app from Microsoft Store

Summary: Which Setup is Best?

Setup	Pros	Cons
WSL	Most compatible, Linux-like environment	Slightly more setup effort
RubyInstaller	Simple to install, native Windows	Compatibility issues with some gems/tools

Recommendation: Use WSL + Ubuntu for the best Rails development experience on Windows.

Beyond rbenv and pyenv: Achieving Reproducible Dev Setups with Nix

Sun, 20 Jul 2025 18:59:08 +0000

Setting up a development environment is a painful process, as I discussed previously when detailing how mine evolved to the combination of home-manager and Ubuntu Make. Little did I know, the article gained significant traction and likely resonated with many fellow developers. Coincidentally, I got into a new job earlier in the month, and this necessitated a revision to the setup on a MacOS environment. How did it go? Turbulent would be an appropriate adjective to describe the whole experience, as you may expect.

From Dotfile Hacks to Open Source: My Development Environment Evolution

A cute illustration from Copilot

The macOS Catalyst: A New Job, A New Challenge

Replicating a development setup over multiple machines can be a hard problem, and ensuring it works on different operating systems significantly increases that complexity. As we delve deeper into the topic, you will see how I shoot myself in the foot repeatedly, and the corresponding steps to recover.

Why a Mac?

Photo by Claudio Schwarz on Unsplash

Before starting my new role, I was asked if I would prefer a Linux machine or a Mac for work. Though I am relatively comfortable with a Linux machine, I picked Mac as I reckoned it is easier to get enterprise apps whenever necessary. I also reiterated this same reason when my coworker and I were pairing up for a task.

Despite working mostly with Ubuntu, I do have a Intel iMac for video calls and functioning as a second screen for documentation and web project previews. A minimal home-manager setup worked mostly fine, and I assumed expansion of the setup for development would be as painless.

Oh, how wrong I was.

As the assigned MacBook Pro became my primary device for work, all the minor problems surfaced. First, my shells were not initialized properly in the terminal emulator. After getting that fixed, I got adventurous and decided to retire rbenv to manage Ruby versions. Coupled with the struggle to set up my code editor, I was amazed how my feet survived all the gunshots.

Diving into the Rabbit Holes: macOS and Interpreter Woes

How hard can it be?

Photo by Nachristos on Unsplash

If one is looking for a statement to best represent underestimation, that would be it. Looking back, the problems look very trivial, but each was a great learning opportunity. Hang on tight, as we are going into a deep dive into all the rabbit holes I fell into with the revised setup, and to learn how to overcome them.

Compared to Windows, macOS offers a more familiar environment for developers with experience in Linux. We can interact with the system through a similar command-line interface. With a package manager, we can even add different shells not shipped with the operating system, like my favourite fish shell. Trying to configure an iTerm2 profile for fish is exactly the first hole I fell into.

Why would macOS not source .profile in a graphical session?

Unlike Ubuntu, macOS does not source .profile in a graphical session. Most of the time, the script updates the PATH variable, making locally installed applications discoverable. Subsequently, shell initialization scripts (like .bashrc for bash and config.fish for fish) then set up individual application based on the environment defined in .profile.

Multiple variations was attempted, until I stumbled upon a Q&A on superuser. Thinking it would be useful, I sent the proposed answer to Gemini and asked if it would be applicable for my case. Turns out I only needed a little tweak.

/bin/sh -lc "exec -l /path/to/fish"

This is a breakdown of the command:

/bin/sh: This specifies that the command should be executed by the Bourne shell, launching a new instance of this basic shell.
/bin/sh -l: this tells the shell to launch as a login shell, ensuring it sources standard login files like .profile.
/bin/sh -c: This tells the shell to execute the command provided in the string that follows.
exec: This crucial command tells the shell to replace the current /bin/sh process with a new process (in this specific case, the fish shell).
exec -l: This tells the new shell (e.g., fish) to launch as a login shell itself.
/path/to/fish: This is the full path to your fish shell executable. With the -l flag in the exec command, this fish shell will then source its own login initialization configuration file (e.g., config.fish).

Similarly, the command can be adapted to work with byobu, my preferred terminal multiplexer. The -l flag is omitted for the exec command as byobu is not a shell.

/bin/sh -lc "exec /path/to/byobu new-session"

For completeness’ sake, the setup for a bash profile is a lot simpler, as it sources .profile and .bashrc properly when launched as a login shell -l itself.

/path/to/bash -l

What a ride.

Shifting from Python to Ruby as my main development language presented an opportunity to review the toolings involved. Previously I relied on pyenv to provide isolated Python interpreters for individual projects. Eventually, the functionality was replaced by uv, which also manages pre-built CPython distributions as well. Unfortunately, I wasn’t aware of an alternative for Ruby, and had to continue relying on rbenv for the purpose.

One of the main goals of using home-manager, as discussed in the previous article, was to achieve idempotency and to isolate dev packages from the system package manager (such as apt in Ubuntu). Thus, we need to first define the packages in the home-manager flake file, as shown below:

packages = with pkgs; [
    ...
    # dev libraries
    openssl
    zlib-ng
    bzip2
    readline
    sqlite
    ncurses
    xz
    tcl
    tk
    xml2
    xmlsec
    libffi
    libtool
    libyaml
    libxml2
    libxslt
  ];

Essentially, this yields an isolated filesystem namespace that is unrecognized by the operating system. In order to get the compiler to utilize the pulled development package, we need to tell rbenv where to look for them, as shown in the shell script below:

#!/usr/bin/env sh

export CPPFLAGS="-I$HOME/.nix-profile/include $CPPFLAGS"
export CFLAGS="-I$HOME/.nix-profile/include $CFLAGS"
export LDFLAGS="-L$HOME/.nix-profile/lib $LDFLAGS"
export PKG_CONFIG_PATH=$HOME/.nix-profile/lib/pkgconfig:$HOME/.nix-profile/share/pkgconfig:$PKG_CONFIG_PATH
export C_INCLUDE_PATH=$HOME/.nix-profile/include:$C_INCLUDE_PATH
export INCLUDE_PATH=$HOME/.nix-profile/include:$INCLUDE_PATH
export LIBRARY_PATH=$HOME/.nix-profile/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=$HOME/.nix-profile/lib:$LD_LIBRARY_PATH

$HOME/.nix-profile/bin/rbenv install -vf 3.3.5

It worked fine, though I always found this a dirty hack, as it required explicitly defining the flags and include paths. There has to be a better way.

The Nix Pivot: Discovering a Declarative Path

If not rbenv, then how do we approach Ruby version management? Turns out we can use another feature provided by Nix to build a development environment through a declarative manner. So how is this relevant to the problem we are looking at though?

Photo by Jonathon B. Carreño on Unsplash

A friend of mine had been hinting for a while that I could completely replace rbenv with Nix but I didn’t explore deeper. That changed when I saw the announcement of the gemini-cli app. In the installation guide, it called for npx, but the tool was not available as a Nix package. After some exchanges with Gemini, it suggested I look into nix shell, and the conversation quickly evolved into an introductory session on nix develop.

Just a side note, gemini-cli was already packaged not long after the announcement, no need for npx. If I were to follow the installation guide, npx could be made available through a nix shell -p nodejs session. In case you missed how this could be related to our original problem, the equivalent for Ruby would be nix shell -p ruby.

What if I need to install gems that require some special dev libraries?

You just unlocked the reason the conversation turned into an introduction to nix develop. Like home-manager, the input for the command is a flake file, written in the Nix programming language, declaring the development environment setup. Naturally, this added complexity made me hesitant to commit to this strategy. I was still trying to get more comfortable with home-manager and wanted to take more conservative baby steps in adopting additional features offered by Nix.

Essentially, there are two important components to be declared in the flake: the list of packages and an initialization shell script. For example, we can define a development environment sporting Ruby 3.3 with the list of packages like so:

buildInputs = with pkgs; [
  # fish is kept so that fish-specific completions from
  # packages can be made available.
  fish
  # Git is needed for fetching gems from git repositorie
  git
  # The Ruby interpreter (3.3.8 as the time of writing)
  ruby
  # Bundler for managing Ruby gems.
  bundler
  # Common dependencies for building native extensions.
  cmake
  gcc
  gnumake
  # Libraries often required by gems.
  openssl
  pkg-config
  libmysqlclient
  shared-mime-info
  re2
  readline
  zlib
] ++ lib.optionals stdenv.isDarwin [
  # Add macOS-specific dependencies.
  libiconv
];

Secondly, the initialization script definition

shellHook = ''
  # Ruby-specific setup
  export FREEDESKTOP_MIME_TYPES_PATH="${pkgs.shared-mime-info}/share/mime/packages/freedesktop.org.xml"

  echo "Ruby dev environment activated for ${system}!"
'';

Incorporating these into the flake file makes nix develop a superior method to set up a development environment. Compared to just listing packages in nix shell, the shellHook component allows more control and further manipulation, enabling us to set up proper environment variables and run initialization commands. Additionally, the declarative nature of a flake file also means it is highly reproducible and can be easily shared.

A Harmonious Setup: Validation and Reflection

Remember I needed to redefine library path and compiler flags to compile Ruby interpreters? That problem eventually came back while I was installing gems for work projects. Long story short, I gave in and adopted nix develop. Does it work out of the box? Does the adoption of nix develop stop me from shooting myself in the foot?

In order to be cautious, I replicated and adapted the flake for my bigmeow side project, which is still managed by Poetry, and hence relied on pyenv. Fortunately, a satisfactory outcome was achieved after a few iterations. On the other hand, direnv also offers some integration with nix develop. Automated activation of a development environment can be achieved by adding one line to the respective .envrc:

use flake /path/to/folder # the folder that contains the flake.nix declaration

Photo by Sigmund on Unsplash

Applying the Ruby counterpart also went rather smoothly. There were some problems in the earlier iterations, but they were mostly trivial, and all it took was a regeneration by Gemini. Compared to the relatively smooth sailing in environment setup, taming my code editor to work with it was a lot more frustrating.

In recent years, most extensions bridging the code and development tools would often bundle the tool together. For instance, if I install an extension to format Python code with ruff formatter in Visual Studio Code, it would bundle ruff itself in the package. This saves the developer from needing to declare ruff as a dependency of the project.

Likely due to the highly modular design, the experience was a lot more complicated in the Ruby world. One of my work projects defined an ancient version of the Rubocop formatter, and none of the editor extensions offered in the marketplace would work with it. Forcing the extension to use the bundled gem would fail, because it wouldn’t work with the equally outdated rubocop extension gems (rubocop-rails, rubocop-minitest) installed in the project.

Updating the lock file is not a practical solution and I was stuck there for a while. Thankfully a coworker shared that I could explore the ruby-lsp extension. Apparently, this extension makes it possible to refer to an alternative Gemfile, i.e. I could have a Gemfile for all the development tools saved outside of the project. In this particular case, I could have a Gemfile like this

source "https://rubygems.org"

gem "ruby-lsp"
gem "rubocop", "1.26.1"
gem "rubocop-rails"
gem "rubocop-minitest"

Solving that yields an functional setup that I was happy enough for work. Looking back, everything seemed rather trivial, but in reality I was stuck for a couple of days. Despite the added complexity, getting all these parts working together felt like putting together puzzle pieces. Getting them configured correctly is giving the same satisfaction as solving a complex jigsaw puzzle.

Is this increased complexity worth the effort? Would there be a better alternative strategy out there? I am curious to know about them and am open to recommendations and corrections. Meanwhile, I do find the revision to retire version managers a fruitful learning experience. Another part I liked about the current implementation is the elimination of explicit declaration of dev packages to build the interpreters. If you ask me, I would say replacing the version managers and removing dev packages for interpreter compilation with nix develop flake files is totally worth the effort.

Rails releases security updates for ReDoS vulnerabilities—upgrade now to the latest versions for optimal protection!

Tue, 15 Oct 2024 09:14:00 +0000

Critical Rails Security Updates: Patch Your Apps Now!

Attention all Ruby on Rails developers! The Rails team has released Rails versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, which address several critical security vulnerabilities, most notably ReDoS (Regular Expression Denial of Service) risks. If your application is running on Ruby 3.1 or earlier, it’s crucial to take action now to keep your app secure and performing optimally.

Key Security Vulnerabilities Addressed:

1. CVE-2024-47887: ReDoS Vulnerability in HTTP Token Authentication

This vulnerability affects HTTP token authentication in Action Controller. It allows malicious users to perform Denial of Service (DoS) attacks by exploiting regular expressions used in token validation.

2. CVE-2024-41128: ReDoS Vulnerability in Query Parameter Filtering

Action Dispatch is vulnerable due to a regular expression flaw in query parameter filtering. Attackers can send crafted requests, leading to performance degradation.

3. CVE-2024-47888: ReDoS Vulnerability in `plain_text_for_blockquote_node` in Action Text

A regular expression flaw in the Action Text `plain_text_for_blockquote_node` method could allow attackers to slow down or crash an application.

4. CVE-2024-47889: ReDoS Vulnerability in `block_format` in Action Mailer

The `block_format` method in Action Mailer has a regular expression vulnerability that can expose applications to ReDoS attacks under certain conditions.

Why You Should Upgrade Immediately

1. Ruby 3.1 Nearing End of Life for Security Updates

If your application runs on Ruby 3.1 or below, these versions will no longer receive security updates. To avoid the risk of new vulnerabilities and performance issues, it is essential to upgrade to Ruby 3.2 or later.

2. Avoid Performance Degradation and Downtime

Without these updates, your application could suffer from slowdowns or potential outages. ReDoS attacks can significantly slow down your app by exhausting server resources with malicious input patterns. Preventive updates keep your app running smoothly.

3. Security and Compliance

Staying updated ensures your app meets security standards and compliance requirements. Running outdated software increases the risk of security breaches, which can lead to significant legal and financial repercussions.

What This Means for Your Project

1. Older Ruby Versions Are Vulnerable

If you're still using Ruby 3.1 or below, it’s highly recommended to upgrade to Ruby 3.2 or later. These newer versions offer improved security, performance, and long-term stability.

2. Extended Support for Rails 6.1

For projects running Rails 6.1, even though it’s officially past its maintenance window, version 6.1.7.9 is part of an extended support release. This gives you a grace period to safely migrate your app to newer versions of Rails.

Code Example: Implementing Secure HTTP Token Authentication

Here’s a snippet demonstrating a more secure way to handle HTTP Token Authentication in Action Controller after upgrading Rails:


class ApplicationController < ActionController::Base
  before_action :authenticate

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # Ensure the token follows a safe and secure pattern to avoid ReDoS risks
      return false unless token.match(/\A[A-Za-z0-9\-_]+\z/)
      User.find_by(token: token)
    end
  end
end

Explanation: In this example, we use a safer regular expression to validate the token, ensuring that it only contains alphanumeric characters, dashes, and underscores. This minimizes the risk of malicious patterns being used in an attack.

Steps to Upgrade Your Rails Application

Update Rails and Ruby Versions
Update your Gemfile to specify the latest versions of Rails and Ruby:
```
gem 'rails', '7.2.1.1'
```
Then run:
```
bundle update rails
```
Test for Compatibility
Run your test suite to ensure your application works correctly with the updated versions. You can use:
```
bundle exec rspec
```
Or:
```
bundle exec rails test
```
Check for Deprecations
Review deprecation warnings to anticipate any breaking changes in future versions.
Deploy
Once the tests pass, deploy the updated app to your staging environment first, monitor for issues, and then deploy to production.

Conclusion

Upgrading to the latest Rails and Ruby versions is essential for keeping your application secure and stable. With critical vulnerabilities like ReDoS affecting core components such as Action Controller, Action Dispatch, Action Text, and Action Mailer, failing to update can expose your app to attacks that compromise performance and security.

If your app is still running on Ruby 3.1 or earlier, migrating to Ruby 3.2 or later is highly recommended. The latest versions bring improvements in both performance and security, giving you peace of mind as you continue to develop and scale your application.

If you're not sure how to proceed with the upgrade or need help navigating the transition, feel free to contact us. We’re here to assist you in keeping your app secure and high-performing.

Coder Legion - Recent posts tagged ruby

What Is Idempotency?

🔍 What Is Idempotency?

🛠️ How Do We Implement It in Ruby on Rails?

💎 Why Is Idempotency Important?

⚠️ One Important Detail

RubyOnRails #API #Idempotency #BackendDevelopment #SoftwareArchitecture #DistributedSystems #WebDevelopment #SoftwareEngineering

Building RAG on PostgreSQL with Pgvector and Ruby on rails

Gemfile

Elasticsearch with Ruby on Rails

🔍 What is Elasticsearch?

🛠️ How do we use it with Ruby on Rails?

💡 Why use Elasticsearch?

⚠️ One important architectural decision

API Architecture

️ How I approach API architecture with Ruby on Rails

Important architecture decisions

Why good API architecture matters

RubyOnRails #Ruby #API #APIDesign #SoftwareArchitecture #BackendDevelopment #WebDevelopment #RESTAPI #SoftwareEngineering

One Rails App, Multiple Customers

What is Multi-Tenancy?

How can we implement it with Rails?

Why use Multi-Tenancy?

⚠️ The important part

How you zip larger files in ruby

Web "Hello World" in Ruby without RoR!

Skip the RSpec examples you don't need: rspec-tracer 2.0 in pre-release

Install

What changed since 1.x

1. Pluggable storage

2. Pluggable remote cache (for CI)

3. Per-example tracks: DSL

4. track_env(*names) config DSL

5. Rails preset

6. bin/rspec-tracer CLI

7. HTML + JSON reporters

8. SimpleCov branch coverage now works

9. Boot-time warns

10. Schema-version field + Rails 8.0 + CI recipes

Migration from 1.x

Why pre-release

Where to send feedback

I Built a Bash Script That Traces Code Faster Than Your IDE (And Saves AI Tokens)

What is codetracer?

The Killer Feature: Case-Variant Expansion

Five Modes for Different Questions

1. Where is it defined?

2. Who calls it?

3. How does data flow?

4. Which files touch it?

5. Everything at once

NEW: Rails Route Tracing

Trace directly from your curl files

Why Not Just Use AI?

Save Tokens When You Do Use AI

The Scope Chain

Works on macOS and Linux

Interactive Mode with fzf

Real Workflow Example

Try It

Links

Favourite IDE for Ruby Work?

My Editor Journey: From Heavy IDEs to Plain Old Vim

How We Solved “Unable to Get Certificate CRL” in Rails: A Debugging Story

⚠️ The Error

The Contradiction That Made No Sense

The “Wait, What?” Moment

The Real Test — Inside the Rails Console

The Root Cause — A Policy Change in OpenSSL

The Fixes — Two Paths to Sanity

Fix 1: The Local-Only (Insecure but Practical) Workaround

Fix 2: Match Environments (I tried this one!)

Confirmation & References

Takeaway

What’s your current Ruby setup?

The && Fallacy: How --command Fixed VS Code Extensions in a Declarative Nix Shell

The Editor’s Blind Spot: Nix vs. VS Code Extensions

The Log Line That Clicked Differently

Stalled PR, Sudden Payoff: The Two Timelines

Welcome to the Ruby & Rails Community

3. Per-example `tracks:` DSL

4. `track_env(*names)` config DSL

6. `bin/rspec-tracer` CLI