I recently cloned a repository and noticed it was 486MB. The actual source code? About 6MB. That’s a 98.7% overhead. Here’s how I found the bloat and fixed it.

At the company where I currently work, we run a multi-brand e-commerce platform with stores in around 60 countries per brand. This year we started moving off AWS to self-hosted bare metal servers that we manage ourselves, spread across multiple providers (Hetzner, OVH, and others) for resilience. We have three regions: EU (primary), AU (Sydney), and SG (Singapore). Reads and writes happen locally on the server closest to each user.

I was tasked to investigate our AU server randomly being slower compared to EU. Not always, just sometimes. The same pages that rendered in under 100ms on EU would take over a second on AU.

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).