I’ve been using git for years, but to be honest, I wasn’t even aware of git worktree until I started using AI for development.

Before this, my workflow for context switching was pretty standard. If I was in the middle of something and needed to check another branch or fix a bug, I’d rely on git stash or git stash -u (to catch those untracked files). Sometimes I’d just commit what I had, knowing I would eventually “Squash and Merge” my Pull Requests anyway, so a few messy “WIP” commits didn’t really matter.

But recently, I found a new bottleneck: I have more ideas than I have open AI contexts.

We often treat AI as a faster pair programmer, but we still tend to work sequentially. We ask Cursor or Claude Code to do X, watch it generate code, review it, and then move to Y.

But what if you could implement Idea A, Idea B, and Fix C all at the same time?

Enter git worktree.

I haven’t thought about HTML in a long time, but recently came across the usage of picture tag(s). I was so impressed that I wanted to blog about it. This is nothing new, and used a lot by the web already.

The picture tag gives us a lot of control over how images are loaded, solving two main problems: efficient formats and responsive sizing.

WebP Support

We all know WebP images are smaller and faster to load, but not every browser supported them initially (though support is great now). The picture tag allows us to serve WebP to browsers that support it, while falling back to PNG or JPEG for others.

1
2
3
4
5

<picture>
  <source srcset="image.webp" type="image/webp">
  <source srcset="image.jpg" type="image/jpeg">
  <img src="image.jpg" alt="My Image">
</picture>

The browser parses the <source> tags from top to bottom. The first one with a supported type is chosen. If none match, it falls back to the standard <img> tag.

Design patterns are only useful when they help solve real world problems in ways that feel natural in your language. In Ruby, one such pattern that fits like a glove is the Builder Pattern.

You’ll find it everywhere, from constructing HTML forms in Rails to building command-line interfaces or even assembling HTTP requests.

📦 What Is the Builder Pattern?

In real world projects, we often model things as objects. The idea is that objects are instances of a common blueprint, sharing the same structure but differing in a few properties like name, age, etc. However, when there are many properties to configure and you need more control over how the final object is built, that’s where the Builder pattern becomes useful. It helps construct complex objects step by step without cluttering your code with long initializers or deeply nested logic.

The Builder Pattern is used to construct complex objects step-by-step. Rather than stuffing all parameters into a huge constructor, you build an object one piece at a time, usually using a fluent interface (method chaining).

As I was working on easyclientlog.com, building its invoice system that allows freelancers/consultants to generates PDFs. Working with PDF generating is that, its takes time and CPU cycles. But most of the time the pdf only needs to be generated once, and the content seldom changes. So rendering the same thing over and over just didn’t feel right. So I used a simple trick that I’ve followed in many of my prior Rails apps: upload the PDF on first render, store it using Active Storage, and reuse that file on the next access.

The Idea: Cache on First Render

When the PDF is generated the first time, we attach it to the record using Active Storage. This could be an invoice, report, or any other object. The next time we need to show or download the PDF, we skip the rendering step and simply serve the uploaded file.

This avoids unnecessary rendering and speeds up response times, especially for large documents or when generating in bulk.

Managing context like the current user, store, client, or request ID across controllers, models, jobs, and services in a Rails app has always been a little messy. Before Rails 5.2, you might’ve reached for Thread.current, class_attribute, or even @@class_variables to store this kind of state. But these are not thread-safe and can cause hard-to-debug issues in concurrent environments.

Rails 5.2 introduced a clean solution: ActiveSupport::CurrentAttributes.

This article covers what it is, why it exists, how it works internally, how to use it safely across web and background jobs, and how to test it properly.

📜 A Quick History

ActiveSupport::CurrentAttributes was introduced by DHH in Rails 5.2 to simplify access to per-request or per-job context in a thread-safe way. It replaced older, hackier methods like:

1
2

Thread.current[:current_user] = user
ApplicationRecord.class_attribute :current_client

These approaches were shared across threads — fine in development, dangerous in production.

CurrentAttributes changed that by giving you a dedicated, Rails-friendly API for storing context that’s isolated per request/job.