I did that maybe four times in a week before I got annoyed enough to stop. The whole thing now lives at qrcode.ferbass.xyz, it took an evening, and it cost me nothing to run.

The part that actually bothered me

The ads are the obvious complaint, but they are not the real problem. The real problem is that a lot of these sites quietly hand you a dynamic QR code: instead of encoding your URL, they encode a short link on their domain that redirects to your URL. It looks identical. It scans fine in the demo.

And it means someone else owns the thing you just printed on a slide. They can count every scan, and if the free tier lapses or the company folds, your code stops working. For a throwaway test that is merely distasteful. For anything that outlives the afternoon, it is a genuine trap.

A static QR code has none of that. The URL is in the black and white squares. Nothing to expire, nobody in the middle.

QR codes do not need a server

Here is the thing that makes this an evening project rather than a product: generating a QR code is pure computation. Text goes in, a grid of dark and light modules comes out. There is no lookup, no registry, no network call anywhere in the process.

Which means the entire tool can run in the browser. Mine does. There is no backend, no API, no database, and no request leaving the page — the Wi-Fi password you type never goes anywhere except into a canvas element. That is not a privacy feature I bolted on, it is just what happens when you stop over-thinking the problem.

I used Project Nayuki’s QR library for the encoding itself. It is MIT licensed and genuinely well written, and I have no interest in implementing Reed-Solomon error correction by hand. I compiled it from its TypeScript source and vendored the result into the repo rather than pulling it from a CDN, so there is no third party to trust and nothing to break when someone else’s bucket disappears.

The actual product is the payload formats

Encoding text is the solved part. What makes a QR generator useful is knowing what text to encode, because a QR code that joins you to a Wi-Fi network is not magic — it is a plain string in a format your phone’s camera app recognises:

WIFI:T:WPA;S:my-network;P:hunter2;;

That is the whole trick. Same story everywhere else:

So the tool has a tab per format and builds the string for you. Six of them: text/URL, Wi-Fi, email, SMS, phone, and contact card. That covers essentially everything I have ever needed.

The bug I would definitely have shipped

Look at the Wi-Fi format again and notice that ; and : are structural. Now ask what happens when the password contains a semicolon.

The format’s answer is backslash escaping, for \ ; , : " — and if you skip it, you get a QR code that generates perfectly, looks perfectly normal, and silently fails to join the network. The failure is invisible right up until you are standing in front of someone whose Wi-Fi will not connect.

const escWifi = (s) => s.replace(/([\\;,:"])/g, "\\$1");

Which raises the question of how you test a QR code. Rendering one and eyeballing it tells you nothing — every QR code looks correct. So I did the obvious thing and closed the loop: encode a payload with my code, then decode the resulting matrix with a completely different library (jsQR), and assert the string that comes back out is byte-for-byte what went in.

That caught what I wanted it to catch. The suite runs a network name and password stuffed with ; and :, a multi-line email body, a vCard with a comma in the company name, Japanese text with an emoji, and a 1200-character blob for good measure. All of them round-trip. The generator I would have shipped without that test would have looked identical and been wrong.

Where it lives

I run this blog on Google App Engine, and it turns out adding a subdomain to an existing project is almost free. A small app.yaml declares a static service, one routing entry points the hostname at it, and that is the entire infrastructure. Because it scales to zero and serves nothing but static files, the running cost rounds to zero — which is the right price for a tool that exists so I never have to close a newsletter popup again.

I did briefly wonder whether this deserved its own repository. It does not. The file that routes hostnames to services already lives in the blog repo, so a separate repo would have meant two deploys that need to stay in sync, in exchange for nothing.

Worth an evening

There is a category of tool where the free web version is worse than what you could build yourself in an evening, and QR codes sit right in the middle of it. The hard part — the encoding — is a library someone else already wrote and gave away. What is left is a form, some string formatting, and knowing that ; needs escaping.

The result is a page I control, that works offline, that does not phone home, and that will still generate the same codes in five years. Most of the small tools I use every day could be that, and I keep forgetting it until something makes me annoyed enough to check.

This post was written with the help of AI (Claude by Anthropic).

None of that stops you from publishing. But once you are publishing regularly, the small rough edges start to bug you. So I spent a few evenings tuning the place up. No single change here is impressive on its own. Together they make the blog feel cared for, which is the whole point.

Here is what I changed and why.

The reading experience

This is where most of the work went, because it is what readers actually feel.

Dark mode. The big one. It follows your operating system preference by default, and there is a small toggle in the nav if you want to override it. Your choice sticks between visits, and a tiny inline script applies the theme before the page paints so there is no white flash on load. Getting a dev blog to look right in dark mode is mostly about the code blocks, so I spent the most time there making the syntax colors readable on a dark background.

Reading time. Every post now shows an estimate next to the date. It is a rough word count divided by a normal reading speed, nothing clever, but it sets expectations before someone commits to a wall of text.

Copy buttons on code blocks. Most of what I write is commands and config. Asking people to carefully select a multi line block is rude when a button can do it. Every code block now has one that copies the whole thing and confirms it worked.

Anchor links on headings. Hover a section heading and a small link appears so you can grab a direct URL to that exact spot. Handy for the cheatsheet style posts where people want to link a single section.

Navigation. Posts now have previous and next links at the bottom so you do not dead end. Tags are visible and clickable, with a page to browse everything by topic. The home page is grouped by year instead of being one endless list.

URLs that do not embarrass me

My old setup put post categories into the URL. That meant a post lived at something like /homelab/networking/2026/05/28/some-post.html, and the casing was inconsistent across posts. Worse, categories end up in the URL means that renaming a category breaks the link forever.

I switched to clean, stable URLs based only on the date and title. The catch with changing URLs is that any existing link to the old address breaks. So for the handful of posts that were already live, I added permanent redirects from the old path to the new one. Old links keep working, new links are clean, nobody notices the seam.

SEO that stops fighting me

This was the surprising one. I own a few domains that all pointed at the same blog. I assumed more domains meant more reach. It is closer to the opposite. Search engines see the same content on several addresses and have to guess which one is the real one, splitting whatever ranking signal the content earned across all of them.

There is no dramatic penalty for this, but it is wasted potential. The fix is to pick one canonical domain and send everything else to it with permanent redirects, so all the signal consolidates in one place. That is what I did. One home, every other domain forwards to it.

While I was in there I also bumped the RSS feed to carry more posts, since it was only exposing the ten most recent. If you read via a feed reader, the feed is there and now reaches further back.

The boring part that makes the rest possible

The blog builds and deploys itself. I push to the main branch, a workflow builds the static site and ships it, and the change is live a minute later without me touching a server. I wrote about that pipeline before, but I tightened it here: it now fingerprints the built site and skips the deploy entirely when nothing actually changed, so a typo fix in a draft does not trigger a pointless redeploy. I also pulled my dependencies up to current versions while I had the hood open.

None of this is visible to a reader. That is exactly why it is easy to put off, and exactly why it is worth doing once so you never think about it again.

What I took away from it

The pattern across all of these is that the unglamorous changes compound. Dark mode gets the attention, but the clean URLs, the redirects, the feed, and the deploy guardrails are what make the blog feel like a real, maintained thing instead of an abandoned one. Each change took an evening at most. None of them required rebuilding anything from scratch.

If your own blog has gone quiet, the lesson from the last post was to remove whatever stops you from writing. The lesson from this one is the follow up: once you are writing again, spend a little time making the place worth landing on. Small wins, one evening at a time.

This post was written with the help of AI (Claude by Anthropic).

Then this year it woke up. In the last few weeks I have shipped more posts than in the previous three years combined. The thing that changed was not discipline or a new year resolution. It was figuring out how to use AI to remove the parts of writing that kept stopping me.

What actually kept me from writing

It was never the ideas. I always had things I wanted to write about: a homelab fix, a transcoding tweak, a tmux habit, something I learned the hard way. The ideas pile up. What I did not have was the runway between “I know this” and “this is a finished post someone can read.”

That runway is full of small frictions. Staring at a blank file. Deciding how to structure something I understand in my head but have never put in order. Second-guessing whether my English reads cleanly, since it is not my first language. Doing the boring last mile of fixing a code block, checking a command, tidying a front matter block. None of these are hard. All of them are enough to make me close the tab and do something else.

A finished post was never one big task. It was twenty tiny ones, and any of them could be the one that made me quit for the night.

If you read my old posts you can see this plainly. They are full of grammar mistakes and misspellings, the kind that slip past you when English is not your first language. I would publish something, then notice a typo days later and go back to fix it, then notice another one, and another. It was a slow drip of small corrections, and honestly it was frustrating. Not enough to make me stop, but enough to take some of the joy out of hitting publish.

Where AI fits, and where it does not

The trap is to think AI writes the post for you. It does not, and you do not want it to. A post that is fully generated reads like nobody was home, and the whole point of a personal blog is that someone is home. The voice is the value.

So I do not ask it to write. I ask it to clear the runway.

I talk through an idea out loud and have it pull the shape out of my rambling, so I start from an outline instead of an empty file. I write the ugly first draft myself, in my own words, and then ask where it drags or where I left a gap a reader would trip on. I lean on it to catch the grammar mistakes I will always make as a non-native speaker, without letting it sand my sentences into the same smooth paste every AI tool reaches for. I have it sanity check a command or a code block before I publish something wrong. And when a post is done, I lean on the workflow I already wrote about, where a scheduled agent handles the mechanical parts of getting words from my head to the site.

The judgment stays with me. What to write, what I actually think, which opinions are mine to defend. AI just removes the friction between me and that judgment. Same trick I use for everything else: automate the gathering and the drafting, keep the thinking.

Keeping it sounding like me

This only works if the output still sounds like a person, and left alone these tools do not. They reach for em dashes, for “in summary”, for the same three transition words, for a confident flatness that belongs to no one. So I push the opposite into every prompt. Write plainly. No em dashes. Short words over long ones. If a sentence sounds like a press release, cut it.

I also read every line before it ships. If a paragraph does not sound like something I would actually say out loud, it does not go in. That is the real filter. The AI can hand me ten versions of a sentence, but I am the one who knows which one is mine.

Was it worth it

The honest measure is not quality, it is volume of finished work. Posts that used to die at eighty percent now cross the line. The backlog of “I should write that down” is finally shrinking instead of growing. And the posts still sound like me, because the part that is me is the part I never handed off.

If you have a blog asleep somewhere, this is the unglamorous advice: do not ask AI to write for you. Ask it to remove whatever specific thing keeps stopping you. For me that was the blank page, the structure, and the grammar I was self-conscious about. Once those were gone, it turned out I had plenty to say.

The blog is awake again. Let us see how long I can keep it that way.

This post was written with the help of AI (Claude by Anthropic).

The problem with unsigned commits

Git trusts whatever you put in user.name and user.email. That is it. There is no verification. Anyone with push access — or who briefly gets it — can write commits that claim to be from you. An attacker who compromises an account, a CI bot misconfigured, even a curious contractor with too much access can all author commits under your name. Git will not blink.

Signing a commit ties it to a GPG private key only you hold. GitHub shows a green Verified badge on every signed commit. Unverified commits still work, but they are a yellow flag in a security audit. And some repos enforce it: with “require signed commits” on in branch protection, unsigned pushes are rejected outright.

The practical reasons are:

• Traceability: you can prove, cryptographically, that a release contains only commits made by known developers.
• Non-repudiation: a signed commit cannot be plausibly disowned.
• Consistent protection rules: one environment with approval requirements is easier to manage than scattered workarounds. Same idea: centralize trust, enforce it in one place.

Setting it up

Install gnupg:

brew install gnupg

Generate a key — RSA 4096 is a safe default, just follow the prompts:

gpg --full-generate-key

Find your key ID:

gpg --list-secret-keys --keyid-format LONG
# sec   rsa4096/ABCD1234EFGH5678 2026-06-16 [SC]

The long hex after rsa4096/ is your key ID. Tell git to use it and to sign every commit automatically:

git config --global user.signingkey ABCD1234EFGH5678
git config --global commit.gpgsign true

Export your public key and add it to GitHub under Settings → SSH and GPG keys → New GPG key:

gpg --armor --export ABCD1234EFGH5678 | pbcopy

Your next git commit will prompt for your passphrase in the terminal and GitHub will show the Verified badge from then on.

To lock or not to lock

When you generate the key, GPG asks for a passphrase. You have three real options:

No passphrase: the key is protected only by filesystem permissions. Fast, zero friction, and fine if your machine is encrypted and you are the only user. The risk is that anyone who gets access to your disk (stolen laptop, compromised account) can sign commits as you with no additional barrier.

Passphrase, cached forever: you type it once after boot and the agent holds it until you restart. This is what most people end up with. You get the security benefit of the passphrase existing without the daily friction of typing it.

Passphrase, cached for N seconds: the agent forgets the passphrase after a timeout and asks again. This is the right choice if you step away from your machine often or work in shared environments.

Setting the cache timeout

The gpg-agent controls how long a passphrase stays cached. Edit (or create) ~/.gnupg/gpg-agent.conf:

default-cache-ttl 3600
max-cache-ttl 86400

default-cache-ttl is how long after the last use before the agent forgets the passphrase (3600 means one hour of inactivity). max-cache-ttl is the hard ceiling regardless of activity (86400 is one day). After that the agent always asks again, even if you have been committing non-stop.

Apply the change without restarting:

gpgconf --kill gpg-agent

The agent restarts automatically on the next use. If you want it gone immediately until next prompt, you can also clear the cache manually:

gpg-connect-agent reloadagent /bye

My setup is one hour idle, one day hard limit. I commit in bursts and I do not want to type my passphrase every ten minutes, but I also do not want a long unattended session to silently sign things without me knowing. That balance feels right. If you are on a shared or remote machine, tighten it down.

The amend escape hatch

If a commit slips through unsigned — an agent that was not running, a non-interactive shell — you can retroactively sign it and re-push:

git commit --amend --no-edit -S
git push --force-with-lease

Minor friction, worth the tradeoff for knowing every commit with your name actually came from you.

This post was written with the help of AI (Claude by Anthropic).

This post is a tour of the tools I reach for, built around a real example from last week: I had a nice app icon with an AI watermark stuck in the corner, and I wanted it gone without opening an editor.

The two tools

You only need two things, and on a Mac you already have one of them.

• ImageMagick is the swiss army knife. The modern command is magick (older systems call it convert). Install it with brew install imagemagick.
• sips (Scriptable Image Processing System) ships with macOS. It is less powerful than ImageMagick but it is always there, which makes it perfect for quick resizes inside a script you do not want to add dependencies to.

I mix them freely. The rule of thumb: sips for a quick resize, ImageMagick for anything that involves cropping, compositing, or thinking.

Looking before you leap

Before touching an image, find out what it is. Width, height, format:

# ImageMagick
magick identify butterfly.png
# butterfly.png PNG 1024x1024 1024x1024+0+0 8-bit sRGB 1097747B

# sips, on macOS
sips -g pixelWidth -g pixelHeight butterfly.png

That 1097747B at the end is the file size in bytes — just over 1 MB, which already tells me this image is too heavy for what it is.

Resizing

The single most common operation. Scale the longest side to 600 pixels and keep the aspect ratio:

# ImageMagick: the > means "only shrink, never enlarge"
magick butterfly.png -resize '600x600>' butterfly-600.png

# sips: -Z resizes the longest edge, preserving aspect ratio
sips -Z 600 butterfly.png --out butterfly-600.png

A small trick worth knowing: if you are downscaling something with fine detail, render or resize bigger than you need and then scale down. The extra pixels give the resampler more to average from, so edges come out cleaner. I do this constantly with anything destined for a share card.

Chasing a file size

Here is a problem I actually hit. I wanted this icon to show up as the preview image when the page is shared on WhatsApp. WhatsApp is famously fussy and tends to ignore preview images much over ~300 KB. My PNG was 1 MB.

The fix is mostly resolution. A share thumbnail does not need to be 1024px:

# Drop to 480px and check the new size in one line
sips -Z 480 icon.png --out icon.png
magick identify -format '%B bytes\n' icon.png
# 267516 bytes

That alone took it from 1 MB to 260 KB — comfortably under the limit, with no visible quality loss at the size it is actually displayed. If you need to squeeze further without resizing, pngquant --quality=65-90 in.png does excellent lossy palette compression on PNGs, and for photos a JPEG at -quality 82 is usually indistinguishable from the original at a fraction of the size.

Cropping, and using it to inspect

-crop WxH+X+Y cuts a rectangle: width by height, offset X pixels from the left and Y from the top. The +repage afterwards resets the virtual canvas so the crop becomes a clean standalone image.

# Pull out a 260x260 square starting at (764, 764) — the bottom-right corner
magick butterfly.png -crop 260x260+764+764 +repage corner.png

I use crop not just to produce final images but to look at things. When I suspected there was a watermark in the corner, I cropped that corner out and blew it up so I could see exactly where it was and how big:

There it is — the little four-point sparkle an image generator stamps in the corner.

The interesting part: removing the watermark

Here is the icon, watermark and all:

The naive approach is to paint a white box over the sparkle. That fails the moment the background is not flat — and this one has a subtle grey gradient toward the edges, so a white patch leaves an obvious bright square.

My first real attempt was to clone a clean patch from just above the sparkle and composite it on top:

magick icon.png \
  \( -clone 0 -crop 140x140+884+744 +repage \) \
  -geometry +884+884 -compose over -composite cleaned.png

Closer, but the patch I copied came from higher up where the gradient is a shade lighter, so it also left a faint square. The background varies vertically, so copying vertically can never match.

The trick that actually worked: the gradient is symmetric left to right, so the clean bottom-left corner is the perfect donor. Copy it, flip it horizontally with -flop, and drop it over the bottom-right:

magick icon.png \
  \( -clone 0 -crop 140x140+0+884 +repage -flop \) \
  -geometry +884+884 -compose over -composite cleaned.png

-flop mirrors horizontally (-flip would mirror vertically). Because the donor is the mirror image of where it lands, the gradient lines up exactly and the seam disappears:

And the corner, before and after, side by side — the sparkle is gone and you cannot tell anything was touched:

The lesson is less about ImageMagick and more about the approach: when you patch over something, steal from the place whose background already matches. For a symmetric backdrop, the mirror is free.

Bonus: turning an SVG into a PNG

The other thing I did that week was take an SVG favicon and produce a raster share image from it. SVGs are vectors, so you can render them at any size — the move is to rasterise at high density and scale down for clean edges:

magick -background none -density 1200 favicon.svg -resize 1200x1200 robot.png

Then I gave it some breathing room by centring it on a dark card. -extent grows the canvas to a fixed size and -gravity center keeps the subject in the middle:

magick robot.png -resize 470x470 \
  -background "#2b2b2b" -gravity center -extent 600x600 card.png

That is the whole pipeline that produced the share image for this very blog, in two commands and no editor.

Why bother

Because it is repeatable. Once a command works, it is in my shell history forever, it goes into scripts, and it runs the same on my laptop as it does in CI. The first time you figure out the incantation it feels slower than dragging sliders. Every time after that, it is a single line you paste and forget. For the boring 90% of image work, that is exactly the trade I want.

This post was written with the help of AI (Claude by Anthropic).

Original icon designed by a friend back in 2012. New icon created with the help of AI.

In 2012 I shipped my first App Store app: SplashCam, a camera app that applied a real-time colour splash effect, turning everything grey except a chosen hue. It worked, people used it, and then it quietly sat in a drawer for over a decade while iOS changed around it.

Earlier this year I decided to bring it back, but not just fix it. I wanted to rethink it. The live camera approach got scrapped in favour of a photo editor powered by Apple’s on-device ML, and the result can do something the original never could: understand what is in the photo, not just what colour it is.

A quick disclosure before going further: I started this revival on my own, but at some point I began leaning on AI to speed up the mechanical parts. Translating deprecated API calls, scaffolding test cases, looking up Vision and CoreImage signatures I hadn’t touched before. The architecture, the decisions about what to keep and what to cut, the shader work and the detection pipeline are mine. AI mostly made the typing faster.

One more thing worth mentioning upfront: I kept Objective-C. The codebase is from 2012, most of the original structure was still worth preserving, and I genuinely like the language. What changed is everything around it. The old third-party frameworks are gone, modern APIs replace every deprecated call, and the new ML pipeline uses the same Vision and CoreImage headers you’d reach for in a fresh Swift project. It feels current because the APIs are current, not because it was rewritten for its own sake.

What the Original Looked Like

The project was started in April 2012, back when UIAlertView was still the way you showed a dialog and @synthesize was something you typed on every property.

The colour splash effect

The core trick was a GLSL fragment shader running on OpenGL ES. Given a camera frame as a texture, it computed the hue of every pixel and compared it against up to six target hues. Pixels whose hue fell within a threshold kept their colour; everything else was pushed to greyscale using the classic luminance formula (0.30R + 0.59G + 0.11B).

// SplashColor.fsh (2012) - OpenGL ES fragment shader
precision highp float;
uniform sampler2D s_texture;
uniform float target_hue[6];
uniform float threshold[6];
varying vec2 v_texCoord;

void main() {
    vec4 color = texture2D(s_texture, v_texCoord);
    float hue = atan2(sqrt3*(color.g - color.b),
                      dot(color.rgb, vec3(2.0, -1.0, -1.0)));
    float br = 0.0;
    for (int i = 0; i < 6; ++i) {
        float dHue = abs(hue - target_hue[i]);
        dHue = min(dHue, 2.0*pi - dHue);
        br += clamp(threshold[i] - dHue, 0.0, 1.0);
    }
    br = clamp(br * 100.0, 0.0, 1.0);
    float gray = dot(color.rgb, vec3(0.3, 0.59, 0.11));
    gl_FragColor = mix(vec4(gray), color, br);
}

The rendering layer was XBImageFilters, an OpenGL ES camera filtering framework written by a friend of mine (xissburg). The framework was bundled directly in the repo as a compiled binary, alongside Crashlytics and Flurry. Dependency management in 2012.

What else was in there

• ShareViewController: a custom share screen for posting to Facebook (bundled SCFacebook.m wrapping the old Facebook iOS SDK) and Twitter (via MGTwitterEngine + OAuth, another ~30 files committed to the repo)
• FlurryAnalytics and Crashlytics: both as static .a blobs or binary frameworks
• ColorRangeGroupView: a custom colour picker with swipe and pan gesture recognisers, wired up through IBOutlets in a storyboard
• The entire camera, shader, gesture handling, colour state, and share flow lived in one SplashCamViewController, around 1 300 lines

The fundamental limitation

The hue approach works well for something vivid and isolated, like a red dress against a neutral background. But it breaks down fast. A yellow sunset and a yellow taxi share the same hue. A green tree and a green jacket are indistinguishable to the shader. The effect was cute, but you were always fighting the physics of colour rather than selecting the thing you actually cared about.

What Had to Go First

Before any new features, the project needed to compile on a modern SDK. That meant:

• Removing OpenGL ES: deprecated since iOS 12 and gone from simulators
• Ripping out all the bundled frameworks: Facebook SDK, Twitter+OAuth, MGTwitterEngine, Flurry, Crashlytics, XBImageFilters (~15 000 lines of third-party code deleted)
• Replacing UIAlertView, MediaPlayer, and other deprecated APIs with their modern counterparts
• Switching from a storyboard-driven flow to a programmatic one using a modern AppDelegate and UIButtonConfiguration

The code stayed in Objective-C throughout. Modern Objective-C with full nullability annotations (NS_ASSUME_NONNULL_BEGIN, _Nullable, _Nonnull), @available checks, NS_UNAVAILABLE on initialisers that shouldn’t be called. It reads nothing like the 2012 original, even though it compiles to the same language.

The Pivot: Drop the Live Camera, Use ML Instead

Once the codebase was clean, I started rebuilding the camera: Metal shader, AVFoundation pipeline, a logarithmic zoom wheel modelled on Apple Camera, AE/AF lock, macro mode on supported devices. It all worked. And then I decided to throw most of it out.

The live camera filter had the same problem as the original: it was still hue-based. You could splash red, green, or blue in real time, but you still couldn’t say “keep the dog in colour, grey out everything else.” The effect is most compelling when it acts on a recognisable subject, not an arbitrary band of the colour wheel.

Apple’s Vision framework gained VNGenerateForegroundInstanceMaskRequest in iOS 17. It uses an on-device ML model to detect every distinct foreground subject in an image and return a per-pixel mask for each independently: person, animal, object, whatever the model can segment. That changes the question from “what hue do you want?” to “which thing do you want?”

So the app became a photo editor. The home screen has two buttons:

• Take Photo: opens the system camera, captures the photo, and immediately hands it to the editor
• Choose from Library: opens PHPickerViewController and does the same

Neither path shows a live filtered preview. Both feed a still image into SCGalleryEditorViewController and let the ML do the work.

The Detection Pipeline

The interesting part is in SCSubjectSplashProcessor, which turns a CIImage into a set of independently selectable per-subject masks. It runs a sequence of Vision requests, each covering a different class of subject (a fifth, objectness-based stage was added during the pre-launch polish described later).

Stage 1: Person segmentation (iOS 15+)

VNGeneratePersonSegmentationRequest *personReq =
    [[VNGeneratePersonSegmentationRequest alloc] init];
personReq.qualityLevel = VNGeneratePersonSegmentationRequestQualityLevelBalanced;
personReq.outputPixelFormat = kCVPixelFormatType_OneComponent8;

This runs first and its result isn’t immediately added to the instance list. Instead, it becomes a reference mask used in stage 2 to split mixed instances. It also acts as a standalone fallback: if the foreground instance detector misses a person, the person mask is added on its own after deduplication.

Stage 2: Foreground instance segmentation (iOS 17+)

VNGenerateForegroundInstanceMaskRequest *fgReq =
    [[VNGenerateForegroundInstanceMaskRequest alloc] init];

This is the primary detector. It returns VNInstanceMaskObservation.allInstances, an NSIndexSet of 1-based Vision instance indices. For each index, generateScaledMaskForImageForInstances:fromRequestHandler:error: produces a per-pixel CVPixelBufferRef at source resolution.

Each mask then passes through the person-split step.

Person/object split

A lot of interesting photos involve a person holding or interacting with something: a musician with an instrument, someone holding a flower. Vision’s instance detector often groups the person and the held object into a single mask. The person-split checks whether an instance mask straddles that boundary:

CGFloat ratio = [self _areaOfMask:intersection] / instanceArea;

static const CGFloat kLowSplit  = 0.15;
static const CGFloat kHighSplit = 0.85;
if (ratio <= kLowSplit || ratio >= kHighSplit) {
    return @[instanceMask]; // clearly one thing, don't split
}

CIImage *personPart  = [self _intersectMask:instanceMask withMask:alignedPerson];
CIImage *objectPart  = [self _subtractMask:instanceMask withMask:alignedPerson];

If 15-85% of the instance overlaps the person mask, it’s treated as mixed and split into two pieces. Outside that window it’s clearly a whole person or a whole object and returned as-is. Pieces smaller than 0.3% of the source area are discarded as noise. The result is that “person holding phone” becomes two separately selectable items in the editor’s thumbnail strip.

The mask arithmetic uses CoreImage compositing filters:

• Intersection (CIMultiplyCompositing): treating both masks as luminance images, multiply is a soft AND
• Subtraction: multiply A by the CIColorInvert of B to get A minus B

Stage 3: Animal recognition (iOS 13+)

VNRecognizeAnimalsRequest *animalReq = [[VNRecognizeAnimalsRequest alloc] init];

This returns VNRecognizedObjectObservation bounding boxes, not tight pixel masks. A bounding box around a cat that includes the sofa behind it is useless for compositing. So for each detected animal bounding box, the code crops the source image to that region, runs a fresh foreground instance scan on just that crop, then translates the resulting masks back to source coordinates:

// Crop to CI coordinate space, shift to origin, run instance detector,
// translate masks back to source position.
CIImage *cropped  = [source imageByCroppingToRect:ciRect];
CIImage *shifted  = [cropped imageByApplyingTransform:
                        CGAffineTransformMakeTranslation(-ciRect.origin.x,
                                                         -ciRect.origin.y)];
// ... run VNGenerateForegroundInstanceMaskRequest on `shifted` ...
CIImage *positioned = [mask imageByApplyingTransform:
                           CGAffineTransformMakeTranslation(ciRect.origin.x,
                                                            ciRect.origin.y)];

This detect-then-refine approach gives the animal detection the same per-pixel mask quality as the foreground instance detector, without needing to have been explicitly trained to distinguish animal species.

Stage 4: Saliency fallback

VNGenerateAttentionBasedSaliencyImageRequest *salReq =
    [[VNGenerateAttentionBasedSaliencyImageRequest alloc] init];

Only runs if stages 1-3 found nothing at all. The saliency model identifies regions a person would naturally look at, returning salientObjects as normalised bounding boxes. The same crop-and-refine approach from the animal stage produces tight masks from those boxes.

Deduplication across stages

Running four detectors on the same image risks returning the same subject multiple times. Every mask candidate is compared against everything already in the cache using IoU (intersection over union) computed on 64x64 downscaled probes:

for (int i = 0; i < 64 * 64; i++) {
    BOOL inA = bufA[i] > 64;
    BOOL inB = bufB[i] > 64;
    if (inA && inB) intersection++;
    if (inA || inB) unionCount++;
}
return (CGFloat)intersection / (CGFloat)unionCount;

Any candidate with IoU > 0.6 against an existing mask is dropped. The 64-pixel probe is intentionally coarse; it keeps the check cheap (a single CGBitmapContextCreate per mask) while still catching genuine duplicates.

The total instance list is capped (12 after the pre-launch tuning below) regardless of how many stages fire, so group shots don’t blow up memory or clutter the thumbnail strip.

Tap to Select

When the user taps the image, the editor maps the tap point from UIKit’s top-left coordinate space to CoreImage’s bottom-left space and samples a single pixel from each cached mask:

CGFloat ciY = floor(mask.extent.size.height - point.y - 1.0);
CGRect roi  = CGRectMake(floor(point.x), ciY, 1.0, 1.0);
// render 1x1 pixel from the mask -> grey value -> [0, 1]

The mask with the highest value above 0.5 wins. Tapping the same subject again deselects it. Multiple subjects can be selected at once and their masks are unioned before compositing.

The Compositing Pipeline

renderCIImage produces the final splash output as a CIImage without touching the GPU until something actually reads pixels:

// 1. Greyscale using the same luminance formula as the 2012 shader, via CIColorMatrix
CIImage *gray = [self grayscaleImageFromSource:source];

// 2. Union the selected instance masks
CIImage *combinedMask = [self combinedMaskForSelectedInstances];

// 3. Punch holes where the user has drawn exclusions:
//    finalMask = combinedMask x (1 - unionOfExclusions)
if (unionExclusion) {
    CIImage *inverted = [unionExclusion imageByApplyingFilter:@"CIColorInvert"];
    CIFilter *mult    = [CIFilter filterWithName:@"CIMultiplyCompositing"];
    [mult setValue:combinedMask forKey:kCIInputImageKey];
    [mult setValue:inverted    forKey:kCIInputBackgroundImageKey];
    combinedMask = mult.outputImage;
}

// 4. Blend: colour where mask is white, grey where mask is black
CIFilter *blend = [CIFilter filterWithName:@"CIBlendWithMask"];
[blend setValue:source       forKey:kCIInputImageKey];
[blend setValue:gray          forKey:kCIInputBackgroundImageKey];
[blend setValue:combinedMask  forKey:kCIInputMaskImageKey];

The greyscale step replicates the 2012 shader formula using CIColorMatrix with the same R/G/B weights, just expressed as CoreImage vectors instead of a GPU dot product. The visual feel of the effect is the same; only how the subject gets selected changed.

Corrections with Lasso and Eraser

ML segmentation isn’t perfect. Edges bleed, similar-looking regions get merged, a bright shirt merges with the bright wall behind it. Two tools let the user fix this — one additive, one subtractive:

Lasso (additive): circle a region the automatic pass missed and the editor re-runs detection scoped to that area, clipping the result to the outline you drew. It adds a new selectable subject rather than removing one. The details — and the bug where it used to select a rectangle — are in the pre-launch section below.

Eraser (subtractive): paint strokes that accumulate into exclusion polygons on the fly via a UIPanGestureRecognizer. The editor converts each polygon to a CIImage mask at source resolution and appends it to the processor’s exclusion list. Those pixels get subtracted from the final composited mask via the (1 - exclusion) multiply step above.

Each exclusion is independently toggleable in the thumbnail strip, so you can turn one off to check whether it was actually needed before committing.

Metadata Preservation

The old app discarded every byte of EXIF when saving. The new one reads the source image’s metadata via CGImageSourceCopyPropertiesAtIndex, merges it with the output JPEG, and only overwrites the fields that actually changed: orientation, pixel dimensions, and the software tag. GPS coordinates, camera make/model, and capture date survive the edit.

Tooling

The 2012 project had no CI. You built locally, archived in Xcode, and uploaded through Application Loader.

The rewrite has:

• GitHub Actions: a workflow_dispatch pipeline (manual trigger) that runs on macos-latest
• Fastlane with Match for certificate and provisioning profile management via a private git repo
• App Store Connect API key authentication with no Apple ID password in CI

By the Numbers

Pre-Launch Polish: Hardening the Detection

The pipeline above worked, but the last pass before submitting to the App Store was about the cases where it didn’t. A handful of real photos exposed three rough edges, and fixing them turned out to be the most interesting work of the whole revival.

A dense test image made the problems obvious: a tray of ~40 apples, packed edge to edge, in five rows.

Left: the original. Right: the splash. A group of apples keeps its colour while the rest of the tray is cut cleanly from its neighbours and turned grey, with no rectangular blocks.

Problem 1: square colour blocks

The animal, saliency, and a newly-added objectness stage all share the same trick from Stage 3: take a bounding box, crop, and re-run foreground-instance segmentation to get a tight mask. But when Vision can’t isolate a subject inside the crop (busy scene, no clear figure/ground), it returns a mask that fills almost the entire rectangle. Composited, that reads as an ugly square block of colour.

The fix is a solidity guard: measure how much of its own bounding box a mask actually fills, and reject anything that behaves like a filled rectangle.

// active pixels / area of the mask's own tight bounding box.
// A solid rectangle approaches 1.0; an inscribed circle ~0.79;
// an irregular subject is lower.
- (CGFloat)_solidityOfMask:(CIImage *)mask { /* 64x64 probe */ }

static const CGFloat kSCMaxMaskSolidity = 0.90;
// ...inside the crop refiner:
if ([self _solidityOfMask:positioned] > kSCMaxMaskSolidity) return; // drop it

A round apple fills roughly π/4 ≈ 0.79 of its bounding box and passes; a failed isolation sits near 1.0 and is dropped. The guard only applies to the box-based refinement stages — the primary foreground-instance detector is left untouched, so a genuinely rectangular subject (a book, a sign) still works.

Problem 2: subjects that touch each other

VNGenerateForegroundInstanceMaskRequest segments foreground vs background, so objects of the same kind that touch — a row of apples — collapse into one blob. To recover them I added an objectness-based saliency stage (VNGenerateObjectnessBasedSaliencyImageRequest), which returns one bounding box per salient object. Running the crop-and-refine trick inside each box, then deduplicating, splits clusters the primary detector merged.

I also tried something more aggressive: a distance-transform watershed to cut a single large blob into one mask per object. It worked on paper but produced arbitrary, angular Voronoi chunks that didn’t line up with the fruit, so it got reverted. The honest limitation: with a hard cap on instances, a grid of forty identical touching objects can’t be cleanly separated into forty individual masks. But each detected subject now comes out cleanly cut from its neighbours — pick any of them and it splashes on its own, with sharp edges and no square block (above). For the realistic case — a few distinct subjects — objectness separation is plenty. The instance cap was raised from 8 to 12 to give clustered scenes more room.

Problem 3: the lasso selected a rectangle

The manual lasso was supposed to let you re-scan a region the global pass missed, but it fed Vision the bounding rectangle of your stroke. Circle one apple in a dense grid and you’d get a square of its neighbours. The rework keeps the “force a fresh scan in this area” behaviour but clips the result to what you actually drew:

// foreground detected in the circled area (existing instances
// unioned with a fresh crop re-scan) ... intersected with the
// rasterised lasso outline. Never the bounding rectangle.
CIImage *result = [self _intersectMask:drawnShape withMask:foreground];

One subtlety only a real device exposed: when you pinch-zoom into an all-subject area and lasso, a fresh crop has no background for Vision to segment against and finds nothing. Intersecting with the already-detected foreground (computed at full frame, where background was visible) makes it reliable regardless of zoom. The drawn outline is rasterised with the same path-to-mask converter the eraser already used, which guaranteed the two coordinate systems lined up.

Testing this required a real device

None of this is verifiable in the simulator — VNGenerateForegroundInstanceMaskRequest simply returns nothing there. The regression tests for the apple split and the lasso clip run the real Vision pipeline on a bundled fixture image and only pass on hardware, wired into the same scheme so they build from the command line.

What’s Next

The editing experience works well for portraits and clearly-defined objects. The main thing I want to push next is performance. The CoreImage pipeline re-renders on every selection change, and at full resolution on older devices that starts to feel sluggish with multiple exclusion masks active. A Metal-native compositing pass would collapse the mask union, exclusion subtract, and colour-swap into a single render pass.

The Android migration branch is also in progress, same concept, different stack. That’s a post for another day.

A Note on Bringing Back the Live Camera

The live camera might still come back. The Metal pipeline I built and then shelved is still in the repo, and the more I think about it, the more I think the answer isn’t really “use ML instead of hue”. It’s to use hue better, with the lessons the 2012 version taught me.

The original shader’s problem wasn’t that it relied on colour. It was that it relied on raw RGB hue, which is a fragile signal once you leave a controlled lighting setup. Most of its failure modes have well-known fixes:

Work in HSV, not RGB. RGB tangles colour identity with brightness, so a red shirt in shadow and a red shirt in sunlight read as different colours. HSV (or HSL) splits “what colour is this” from “how bright is it,” so you can keep a narrow threshold on Hue while letting Saturation and Value vary. That’s closer to what you actually want for “this red thing, under any lighting.”

Handle the hue wrap-around. Hue is a circle, not a line. Red sits at both 0° and 360°, so a naive abs(hue - target) < threshold misses half the reds in any image. The 2012 shader’s min(dHue, 2π - dHue) trick was already doing this correctly, but on its own it isn’t enough.

Gate on brightness and saturation. In deep shadow or blown-out highlights, hue stops meaning anything: a black pixel has no colour, a glare pixel has every colour. A minimum Value and Saturation cutoff keeps the splash from leaking into dark backgrounds and white walls, which were two of the original’s most obvious failure modes.

Normalise for white balance. iPhone auto white balance shifts the whole hue distribution scene-to-scene, which is why a “red” threshold tuned indoors falls apart outdoors. A grey-world pass (or sampling a known reference card) before selection gives you a stable colour space to threshold against.

None of this needs ML. A live HSV selector with brightness gating and white-balance normalisation would already be a real step up from the 2012 version, and it runs comfortably at 60fps in a Metal compute shader. The ML editor handles “select the dog”. A smarter live camera could handle “splash everything red in this room”. The two would complement each other rather than compete.

So it isn’t abandoned. Just queued for a future post.

The loud “crunching” sounds, the occasional buffering wheel, and the overall sluggishness of the NAS are all symptoms of a severe I/O bottleneck. Mechanical hard drives (HDDs) are great for sequentially reading large video files, but they are terrible at handling the thousands of rapid, random read/write operations required for live video transcoding.

I recently set out to fix this by offloading all that heavy lifting to an M.2 NVMe SSD. Here is how I bypassed Synology’s artificial software locks to build a dedicated Plex transcode buffer.

The Problem: Synology’s NVMe Lock

Many modern Synology units (like my DS920+) come with dual M.2 NVMe slots on the bottom. The catch? Synology’s operating system (DSM) officially restricts these slots to be used only as a read/write cache, not as an independent storage volume (unless you buy their wildly overpriced, proprietary Synology-branded SSDs).

Using standard NVMe drives as a standard cache doesn’t actually solve the Plex transcoding issue. We need a dedicated, addressable volume where we can tell Plex to dump its temporary files.

On top of that, I wasn’t using the M.2 slot as a read/write cache anyway. My workload doesn’t involve the kind of frequent, repeated random access that a cache actually accelerates, so dedicating the slot to caching would have left that NVMe drive sitting there doing nothing useful. Turning it into a dedicated transcode volume puts it to far better use.

The Solution: Bypassing the Lock via Terminal

Thankfully, the homelab community is incredible. A developer named 007revad maintains a set of scripts that safely patches DSM’s database to allow any standard NVMe drive to be used as a standard storage pool.

Here is the step-by-step process I took to get it working.

Step 1: Run the Creation Script via SSH

First, SSH into the NAS and switch to the root user:

sudo -i

Next, run the dedicated M.2 volume creation script:

bash <(curl -sL https://raw.githubusercontent.com/007revad/Synology_M2_volume/main/syno_create_m2_volume.sh)

The script is interactive. When prompted, I selected:

1. Basic (since I only installed one M.2 drive).
2. Multi Volume (This is crucial: it allows you to slightly under-provision the drive later to extend the SSD’s lifespan under heavy write loads).

The script automatically bypassed the UI locks and built the underlying storage pool.

Step 2: Finalize in Storage Manager

With the terminal work done, I jumped back into the Synology DSM web interface.

1. Opened Storage Manager.
2. Selected the newly created Storage Pool and clicked Create > Create Volume.
3. Formatted it as Btrfs.
4. Went to the Storage Pool settings and enabled SSD TRIM (highly recommended to keep the drive healthy).

Just like that, I had a lightning-fast Volume 2 ready to go.

Step 3: Route Plex to the SSD

With the volume mounted, the final step was telling Plex to use it.

1. In File Station, I created a new shared folder on Volume 2 called PlexTranscode. (I made sure the internal system user PlexMediaServer had Read/Write permissions).
2. Inside the Plex Web App, I navigated to Settings > Transcoder.
3. Under Transcoder temporary directory, I pointed it to the new path: /volume2/PlexTranscode.
4. Saved the changes.

The Results: Night and Day

While I didn’t run synthetic benchmarks, the real-world improvements were immediate and massive:

• Zero Drive Thrashing: Because the high-stress, random read/write chunks are now being dumped onto the NVMe drive, the HDDs just quietly spin and serve the main video file. The NAS is essentially silent during a transcode.
• Instant Scrubbing: Skipping forward or rewinding a transcoded stream used to take a few seconds to catch up. Now, it happens almost instantaneously.
• Responsive NAS: Previously, a heavy 4K transcode would make navigating the DSM web interface or browsing files feel sluggish. By removing the I/O bottleneck, the system feels snappy again regardless of what Plex is doing.
• Less Wear and Tear: Mechanical drives aren’t built for non-stop random writes. Shifting that abuse to an SSD (which is literally designed for it) will likely extend the lifespan of my bulk storage drives.

If you have an unused M.2 slot on your Synology and host Plex for your friends and family, this is hands-down one of the best upgrades you can do. It transforms the user experience from “good enough” to incredibly smooth.

Keeping track of a homelab gets complicated fast. Which port does that service run on? Why did I configure Pi-hole that way? What was the fix for that weird networking issue six months ago? Writing it down somewhere persistent saves a lot of pain later. This post covers how I set up a private Jekyll blog, hosted on my home server, that auto-deploys from a GitHub repo whenever I push a new post.

The Setup

The stack is intentionally simple:

• Jekyll for static site generation
• GitHub to store the source and posts
• GitHub Actions to build and deploy on every push
• nginx running in Docker on CasaOS to serve the built site
• Nginx Proxy Manager for HTTPS with a wildcard Let’s Encrypt cert
• Tailscale to let GitHub Actions reach the home server securely

The result is a site at https://docs.yourdomain.com reachable from any device on the local network, with a real trusted certificate.

Why Jekyll

Jekyll builds a static site from Markdown files. No database, no PHP, no runtime to maintain. The output is just HTML and CSS served by nginx. It is fast, simple, and the source files are plain text that live comfortably in git.

For internal documentation, the content model maps well too. Posts for dated notes and writeups, and a custom _services collection for living documentation about each running service.

Repo Structure

internal-blog/
├── _config.yml
├── _posts/
│   └── 2026-05-28-homelab-setup.md
├── _services/
│   ├── sonarr.md
│   ├── radarr.md
│   ├── pihole.md
│   └── ...
├── _layouts/
│   ├── default.html
│   ├── post.html
│   ├── page.html
│   └── service.html
├── assets/css/style.css
├── index.html
├── services.html
└── .github/workflows/deploy.yml

The _services collection is the most useful part. Each service gets its own Markdown file with frontmatter for the URL, port, and status:

---
title: Sonarr
layout: service
url_local: https://sonarr.yourdomain.com
port: 8989
status: running
description: TV series management and download automation
---

TV show manager. Monitors RSS feeds and downloads episodes automatically.

## Notes

- Connected to Prowlarr for indexer management
- Downloads go to /mnt/Storage1/Media/TV

For Jekyll to treat _services as a collection, declare it in _config.yml:

collections:
  services:
    output: true

Without this, the files in _services are ignored. Once declared, the homepage and services page loop over the collection to render a table of all services with their URLs and status. It becomes a quick reference for anything running on the server.

The Deployment Problem

GitHub Actions runners are on the public internet. The home server is on a private LAN. They cannot reach each other directly.

The fix is Tailscale. The home server already runs Tailscale, and the GitHub Actions workflow connects the runner to the same Tailscale network using an auth key before running rsync. From that point the runner can reach the server at its Tailscale IP as if it were on the same local network.

The GitHub Actions Workflow

name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: "4.0"
          bundler-cache: true

      - name: Build Jekyll site
        run: bundle exec jekyll build
        env:
          JEKYLL_ENV: production

      - name: Connect to Tailscale
        uses: tailscale/github-action@v3
        with:
          authkey: $
          version: latest

      - name: Deploy via rsync
        env:
          SSH_KEY_B64: $
          DEPLOY_HOST: $
        run: |
          mkdir -p ~/.ssh
          echo "$SSH_KEY_B64" | base64 -d > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          rsync -avzr --delete \
            -e "ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=no" \
            _site/ \
            user@${DEPLOY_HOST}:/home/user/docs-site/

A few things worth calling out:

The SSH key is stored base64-encoded. GitHub Actions can mangle multiline secrets when they are retrieved in a shell script. Encoding the private key as a single base64 line and decoding it in the workflow avoids the issue entirely. This tripped me up for a while before I found it.

Tailscale connects before rsync runs. The runner joins your Tailscale network as an ephemeral node, runs the deploy, then disappears. No persistent node, no cleanup needed.

rsync with --delete keeps the served directory in sync with exactly what Jekyll built. Files removed from the repo are removed from the server on the next deploy.

Secrets Required

Generate the deploy key on the server and add the public key to authorized_keys:

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/github_deploy_key -N ""
cat ~/.ssh/github_deploy_key.pub >> ~/.ssh/authorized_keys

Then encode the private key for the GitHub secret:

base64 -w 0 ~/.ssh/github_deploy_key

Paste that single line as the DEPLOY_SSH_KEY secret value.

Serving with nginx

The built site lands at /home/user/docs-site/ on the server. A lightweight nginx container serves it:

docker run -d \
  --name docs \
  --restart unless-stopped \
  -p 8899:80 \
  -v /home/user/docs-site:/usr/share/nginx/html:ro \
  nginx:alpine

Nginx Proxy Manager handles the HTTPS layer, routing docs.yourdomain.com to port 8899 with the wildcard *.yourdomain.com certificate.

One gotcha: bind the container to 0.0.0.0:8899 not 127.0.0.1:8899. NPM runs in its own Docker container and cannot reach the host loopback. Use the server LAN IP as the forward host in NPM instead of 127.0.0.1.

Services Table

All services are documented in the _services collection and rendered as a table:

Writing Workflow

Once everything is set up, adding a post is just:

vim _posts/2026-05-31-some-topic.md
git add . && git commit -m "add post" && git push

The site updates in about 30 seconds. No SSH, no server management, no manual steps.

For quick notes, the GitHub web editor works too. Edit a file directly on github.com and the deploy triggers automatically.

This post was written with the help of AI (Claude by Anthropic).

Why Fish

Bash and zsh are fine, but fish gives me good defaults out of the box. Syntax highlighting as I type, autosuggestions from history, and a sane scripting language. It is not POSIX, which means I cannot paste random shell snippets and expect them to work, but for daily interactive use I prefer it.

Fish lives at /opt/homebrew/bin/fish (installed via Homebrew) and is set as the shell in my Alacritty config.

Auto attach to tmux

The first thing my config does after loading Homebrew is jump straight into tmux:

if status is-interactive
and not set -q TMUX
    exec tmux new -As0
end

tmux new -As0 either attaches to session 0 if it exists, or creates it. Combined with exec, the fish process is replaced by tmux, so I do not have a stray shell hanging around outside the session.

The check on TMUX is important. Without it, every pane fish opens inside tmux would try to start tmux again.

Greeting and basics

set fish_greeting

Empty greeting. I do not need fish to tell me hello every time.

set -gx GPG_TTY (tty)
set -U EDITOR nvim

GPG_TTY is required for GPG signing to prompt for the passphrase. I sign commits, so this matters. EDITOR is universal so git, fzf and anything else that calls into $EDITOR picks neovim.

Version managers

I have a few language version managers installed. They are gated on status --is-interactive so they do not slow down non interactive sessions:

# rbenv
if status --is-interactive
  set -x PATH $PATH "$(brew --prefix)/shared/rbenv"
  rbenv init - | source
end

# pyenv
if status --is-interactive
  set -Ux PYENV_ROOT $HOME/.pyenv
  set -U fish_user_paths $PYENV_ROOT/bin $fish_user_paths
  pyenv init - fish | source
  pyenv virtualenv-init - | source
end

I also have tfenv on PATH (for Terraform) and sdkman for the JVM languages, set up through a conf.d snippet that ships with the sdkman fish plugin.

Locale

I set every LC_* variable to en_US.UTF-8. Worth being explicit because some tools (ruby, postgres, certain ssh setups) will silently fall back to C locale otherwise, which breaks UTF-8 handling:

set -gx LANG "en_US.UTF-8"
set -gx LC_ALL "en_US.UTF-8"
# ...and the rest

PATH and SDK paths

Android SDK, JDK 17 include path for native builds, libomp for compiling some Python wheels, and a few extras:

set -gx ANDROID_HOME /Users/ferbass/Library/Android/sdk
set -gx PATH $ANDROID_HOME/tools $ANDROID_HOME/platform-tools $PATH
set -gx CPPFLAGS "-I/opt/homebrew/opt/openjdk@17/include"
set -gx LDFLAGS "-L/opt/homebrew/opt/libomp/lib"

Plus ~/.local/bin and ~/.tfenv/bin near the front of PATH.

Disable Homebrew analytics

set -gx HOMEBREW_NO_ANALYTICS 1

Small thing, but I do not need Homebrew sending usage data.

Aliases

I keep aliases short and few:

alias assume="set -x GRANTE_SAML true; source /opt/homebrew/bin/assume.fish"
alias tns="tmux new -d -s"

• assume is for the granted AWS credential tool. The env var puts it in SAML mode.
• tns foo creates a detached tmux session named foo. Handy when I want to spin up a background workspace without leaving the current one.

Functions

These live in fish/functions/. Each function gets its own file, which fish auto loads on first call.

function cat
    bat $argv
end

cat is shadowed by bat for the syntax highlighting and line numbers.

function ls --wraps='eza --icons --group-directories-first'
    eza $argv --icons --group-directories-first
end

ls is shadowed by eza for icons and directories first.

function vim
    if type -q nvim
        command nvim $argv
    else
        echo "nvim is not installed"
    end
end

vim runs nvim if it is installed. Keeps muscle memory working.

A couple of small utilities:

function myip
    curl ifconfig.me
end

function lockscreen --description '[macOS] Lock your screen without Log out the user'
    pmset displaysleepnow
end

I also have a few git helpers like default_branch <url> (uses ls-remote --symref to pull the default branch name) and ensure_remote <name> <url> (adds or updates a remote).

Tmux + AI status icon

When I run claude or gemini inside tmux, I want a robot icon to appear in the tmux window name so I can see at a glance which window has an AI session running. Fish has fish_preexec and fish_postexec events that fire before and after every command:

function __tmux_ai_preexec --on-event fish_preexec
    if set -q TMUX
        set cmd (string split ' ' $argv[1])[1]
        switch $cmd
            case claude claude-personal
                tmux set-option -p @ai_running "🤖"
            case gemini
                tmux set-option -p @ai_running "🤖"
        end
    end
end

function __tmux_ai_postexec --on-event fish_postexec
    if set -q TMUX
        tmux set-option -pu @ai_running
    end
end

The tmux side picks this up through a window name format that reads @ai_running. The result is a small robot icon next to the window title while the command is running.

Keybindings

In conf.d/keybindings.fish:

bind \e. history-token-search-backward

This gives me Alt+. to paste the last token from the previous command, which is the readline behaviour I am used to from bash and zsh. Fish does not ship it by default, so I add it back.

Prompt

I use a small custom prompt in functions/fish_prompt.fish. It shows the current directory (shortened), the git branch, and the exit code in red if the last command failed. Two lines, so the command always starts at column 1.

Local secrets

Last line of the config sources a gitignored file for anything machine specific:

if test -f ~/.config/fish/config.local.fish
    source ~/.config/fish/config.local.fish
end

That is where any API tokens or credentials live, so they never end up in the dotfiles repo.

Plugins

Managed by fisher. The fish_plugins file lists what is installed:

jorgebucaran/fisher
reitzig/sdkman-for-fish@v2.0.0

I keep the plugin list short on purpose. Most of what other people use plugins for, fish already does natively or I have a small function for.

That is it

If you want to copy any of this, it all lives in my dotfiles repo under fish/.

This post was put together with help from an AI assistant.

Why Alacritty

I want a terminal that opens fast, scrolls fast, and gets out of my way. Alacritty does that. It is GPU accelerated, has no built in tabs or splits (I let tmux handle those), and the config is plain TOML so it is easy to read and to put in a dotfiles repo.

Theme

I use the Argonaut theme. The themes repo is cloned as a submodule under ~/.config/alacritty/themes and pulled in with a single import line:

[general]
import = ["~/.config/alacritty/themes/themes/argonaut.toml"]

Using ~ rather than the full path means the file is portable across machines.

Font

Hack Nerd Font at size 16. Hack has clean glyphs at small sizes and the Nerd Font version includes icons that work well in tools like fish, lazygit, or my neovim file tree.

[font]
size = 16

[font.normal]
family = "Hack Nerd Font"
style = "Regular"

[font.bold]
family = "Hack Nerd Font"
style = "Bold"

[font.italic]
family = "Hack Nerd Font"
style = "Italic"

[font.bold_italic]
family = "Hack Nerd Font"
style = "Bold Italic"

I had Bold style set to Regular for a long time without noticing. If you ever wonder why your bold text does not look bold, that is the first place to check.

Window

[window]
option_as_alt = "OnlyLeft"
decorations = "Buttonless"
padding = { x = 8, y = 8 }

A few small things that make a big difference:

• option_as_alt = "OnlyLeft" makes the left Option key behave like Alt. This is what lets things like Alt+. in fish or Alt+1..9 in tmux actually fire. The right Option key keeps the macOS behavior so I can still type accented characters.
• decorations = "Buttonless" keeps the traffic light buttons but drops the rest of the title bar. Cleaner look without losing the close button.
• A bit of padding so text does not touch the window edge.

Scrollback

[scrolling]
history = 10000

10k lines. Enough to scroll up after a long build without losing things.

Selection and Mouse

[selection]
save_to_clipboard = true

[mouse]
hide_when_typing = true

Selecting text automatically copies it to the system clipboard, so I do not need cmd+c every time. And the mouse cursor disappears while I type, which is small but nice.

Cursor

[cursor]
style = { shape = "Beam", blinking = "On" }

Beam cursor that blinks. Easier to spot than a block when I am scanning the screen.

Shell

[terminal.shell]
program = "/opt/homebrew/bin/fish"

Fish, installed through Homebrew. Post about my fish setup is coming separately.

That is it

The whole config fits on one screen, which I like. If you want to copy parts of it, the file is in my dotfiles repo under alacritty/alacritty.toml.

This post was put together with help from an AI assistant.

So I spent a weekend wiring up a set of scheduled AI agents to handle the boring parts. Not chatbots I poke at, but jobs that run on a cron in the cloud, do a specific task, and get out of the way. Here is what I built and, more usefully, what I learned doing it.

AI is not just for writing code

Almost all of the AI conversation right now is about coding. Autocomplete, agents that open pull requests, tools that refactor a file while you watch. That is great, and I lean on it. But it quietly ignores the other half of the job: the reading, the summarizing, and the keeping everyone in the loop. That part never ships a feature, so it gets no hype, and it is exactly where a model that is good at distilling text earns its keep. Summarization is not the consolation prize. For me it has been the highest leverage use of AI this year, and none of the three jobs below writes a single line of production code.

The three jobs

Slack digests. A few times a day an agent reads the channels I care about, keeps only what happened in that window, and posts one tidy summary to a private channel of mine. Each bullet that came from a thread I was part of gets a small link back to the thread, so I can jump in if I need to. I stopped scrolling and started skimming.

A review drafter. Every hour during the workday, an agent looks for pull requests waiting on my review, reads the diff, and leaves a pending (draft) review with inline comments. It never submits anything. I open the PR, the comments are already there waiting, I edit what I disagree with and hit submit. Reviews that used to sit for a day now start in minutes.

A weekly write-up. Every Monday an agent looks back over the last seven days across our repositories, figures out the major changes, possible issues, and things worth watching, and publishes a post to a small internal site. It opens with genuine credit to the people who shipped, includes a little contributor leaderboard, and ties code back to the tickets it closed. The team gets a readable record of the week without anyone writing it by hand.

How it is glued together

All of this rides on Claude Code’s scheduled remote agents, which it calls routines. A routine is just a saved Claude Code setup, a prompt plus the repositories and connectors it needs, packaged once and run automatically. The trigger can be a schedule, an on-demand API call, or a GitHub event, and it all runs on Anthropic’s cloud rather than my laptop. I set each one up through a short scheduling flow: give it a name, a cron expression, a prompt, and the model to use. The cron is in UTC with a one hour minimum, so I do the timezone math from where I live, and for the weekday jobs I add a small guard at the top of the prompt that checks the local day and bails out on weekends.

Routines are the path of least resistance for me because I already live in Claude Code, but there is nothing magic about them. The same idea works with a plain cron job on a server you own, or a scheduled GitHub Actions workflow that calls a model on a timer. What you are actually building is an agent with a good prompt and something that fires it on schedule. The routine just spares me from babysitting a box or a YAML file, and it runs in the cloud so nothing breaks when my machine is asleep.

When a routine fires, it spins up a fresh, isolated session in Anthropic’s cloud. The session gets its own git checkout of whatever repositories I point it at, plus the usual tools: a shell, file read and search, git, and web fetch. It starts with zero memory of previous runs, which is exactly why the prompt has to be completely self-contained. The prompt is the real product here. Everything the agent knows about the task lives inside it, so I spend most of my time wording the steps precisely: what to gather, what to skip, what “done” looks like, and what never to do.

External services come in through MCP connectors. Slack, GitHub, and the issue tracker each connect once, and then any routine can use them. GitHub comes through an MCP server authenticated as me, so the agents can search pull requests, read diffs, and leave draft reviews. The weekly write-up goes further and uses plain git in the session to clone a repo, commit a new post, and push it, with a rebase first so it never trips over commits that landed in the meantime. No tokens pasted into prompts, no secrets in the repo.

The decision that mattered most was picking the model per routine. Pure summarizing runs on the cheapest fast model. Code review runs on the strongest one, because that is where quality actually shows up. The weekly analysis sits in the middle, on a mid model with a medium effort setting I spell out in the prompt. Matching the model to the job kept the cost sane without making the output worse where it counts.

What a routine actually looks like

There is not much to one. It is a schedule plus a prompt. Here is a trimmed, genericized version of my review drafter, the routine that taught me the most:

# schedule: 0 0-9,23 * * *   (hourly, ~8am to 6pm my time, weekdays)
# model:    the strongest one, since this is code review

You review pull requests for my GitHub account. You run hourly on
weekdays. Use the GitHub tools (you are authenticated as me). There is
no gh CLI; use the GitHub MCP tools.

STEP 0  Run `TZ=<my zone> date +%u`. If it is Saturday or Sunday, stop
        and do nothing.

STEP 1  Find open PRs that request my review across my org. If there
        are none, stop.

STEP 2  For each PR, list its existing reviews.
        - If I already left a real review, skip the PR.
        - If a previous run left an EMPTY draft, delete it and redo.
        Also read my recent Slack posts and skip any PR already
        announced, so the hourly run never posts the same one twice.

STEP 3  Read the diff. Draft concrete inline comments (path, line,
        severity label, body). Create a PENDING review and attach the
        comments. Do NOT submit it.
        VERIFY: re-read the pending review and confirm it really has
        comments. If it came out empty, delete it and mark the PR as
        failed. Never report a draft that is not actually there.

STEP 4  Post one short Slack summary, listing only PRs that got a real,
        non-empty draft. Link each author to their GitHub profile.
        No em dashes. Write like a person.

The cron is the easy half. The prompt is where all the behavior lives, including every mistake I had to learn the hard way. That empty-draft check in step 3 exists because of a solid week of empty drafts.

What I actually learned

The plumbing was the easy part. The lessons were in the failure modes.

Make the agent verify its own work. My proudest moment was also my most embarrassing one. The review drafter happily reported “drafts ready” for a week while leaving completely empty reviews behind. It had created the review shell and never attached the comments. Now every agent that claims it did something has to re-read the result and prove it, and it is only allowed to report success when the thing is actually there.

Ground everything in real data. An early version pulled ticket IDs out of PR titles with a regex and cheerfully linked to issues that did not exist, because some titles carried leftover placeholder text. The fix was to stop trusting text that looks like an ID and only reference things the issue tracker confirms are real. An accurate post with fewer links beats a confident one full of dead ones.

Write like a person. Left alone, these tools reach for em dashes, “in summary”, and the same three transition words. I bake the opposite into every prompt. I also scale the praise in the weekly post to how much actually shipped, so a quiet week reads honest instead of inflated.

Respect idempotency and timezones. An hourly job that does not remember what it already did will spam you. A daily one that ignores the clock will skip a post because a static site generator quietly refuses to publish anything dated in the future. Both cost me a confused hour.

Was it worth it

Yes, and not because it is clever. It is worth it because the busywork is gone and the judgment stayed with me. I still decide what a review means and whether the week went well. The agents just remove the friction between me and that decision. That is the whole trick: automate the gathering and the drafting, keep the thinking.

If you try this, start with the most repetitive, lowest-stakes task you have, make it verify itself, and only then let it touch anything that other people will see.

This post was written with the help of AI (Claude by Anthropic).

General

Window Navigation & Resize

Visual Mode

Telescope (Fuzzy Finder)

LSP (active when a language server attaches)

File Explorer & Startify

Startify bookmarks:

Search & Replace (Spectre)

Git

Peekup (Register Preview)

Copilot (Insert Mode)

Tab is not used (g.copilot_no_tab_map = true).

Useful Defaults Worth Remembering

• Clipboard is unified with system (clipboard=unnamedplus) — yank/paste goes through pbpaste/pbcopy.
• New splits open below (splitbelow) and to the right (splitright).
• Smart case search — lowercase pattern matches case-insensitively, mixed case is sensitive.
• Trailing whitespace is stripped automatically before leaving insert mode.
• Yanked text briefly highlights.
• Filetype detection: Fastfile → ruby, *.tfvars → hcl.

Many shortcuts below use Alt+key — these require Alacritty’s window.option_as_alt = "OnlyLeft". Use the left Option key. Right Option still types ≥ ñ © ….

Custom Bindings (My Config)

Prefix-Free (no Ctrl-b needed)

Prefix-Based

Shell Shortcuts (Fish)

Default Bindings Worth Knowing

Sessions

Windows (tabs)

Panes (splits inside a window)

Resize Panes (hold prefix)

Copy Mode

Misc

Plugins (TPM)

Installed via tmux-plugins/tpm:

• tmux-resurrect — save / restore session state.
• tmux-continuum — auto-save every 15 minutes, restore on start.

TPM controls

Resurrect

Server-Wide Settings (Reference)

• default-shell → /opt/homebrew/bin/fish
• default-terminal → xterm-256color
• escape-time → 10ms (low so Alt sequences feel snappy)
• mouse → on (click panes/windows, drag to resize)
• automatic-rename → on; format shows current directory basename, with optional AI tool prefix.

Reloading Config

tmux source ~/.config/tmux/tmux.conf   # soft reload
tmux kill-server                        # hard reload (kills all sessions)

This post covers how to get from that situation to having clean URLs like https://sonarr.yourdomain.com that work on every device in your house, with a real trusted HTTPS certificate.

What You Need

• A domain name (something like yourdomain.com)
• Pi-hole running on your home network
• Nginx Proxy Manager (NPM) running as a Docker container
• A DNS provider with an API (this guide uses Google Cloud DNS, but Cloudflare works just as well)

The idea is simple: Pi-hole handles local DNS so your devices know that sonarr.yourdomain.com points to your server’s local IP. NPM sits on port 80/443 and routes incoming requests to the right service based on the hostname. Let’s Encrypt handles the certificate via DNS challenge so you get real HTTPS without exposing your server to the internet.

Step 1: Set Up Pi-hole Local DNS

Pi-hole v6 stores custom DNS entries in /etc/pihole/pihole.toml under the dns.hosts array. If you are running Pi-hole in Docker, that path is inside your mounted volume.

Open your pihole.toml and find the [dns] section. Add your entries to the hosts field:

[dns]
  hosts = [
    "192.168.50.116 sonarr.yourdomain.com",
    "192.168.50.116 radarr.yourdomain.com",
    "192.168.50.116 bazarr.yourdomain.com",
    "192.168.50.116 prowlarr.yourdomain.com",
    "192.168.50.116 pihole.yourdomain.com",
    "192.168.50.116 portainer.yourdomain.com",
    "192.168.50.116 qt.yourdomain.com",
    "192.168.50.116 npm.yourdomain.com"
  ] ### CHANGED, default = []

Replace 192.168.50.116 with your server’s actual local IP. After saving, restart Pi-hole:

docker restart pihole

Make sure your router uses Pi-hole as its DNS server so all devices on your network pick up these custom entries automatically.

A Note on Pi-hole v6

If you are upgrading from Pi-hole v5, the old custom.list file is no longer read by v6. You have to use the pihole.toml approach above. The custom.list file will silently be ignored.

Also, set listeningMode to ALL in pihole.toml so Pi-hole accepts queries from all your local devices:

listeningMode = "ALL"

If you run Pi-hole in Docker with bridge networking, you may hit an issue where the Docker UDP proxy does not properly relay DNS queries from external clients. The fix is to run Pi-hole with host networking:

docker run -d \
  --name pihole \
  --network host \
  --restart unless-stopped \
  -e TZ=America/New_York \
  -e WEBPASSWORD=yourpassword \
  -v /path/to/pihole/etc-pihole:/etc/pihole \
  -v /path/to/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \
  pihole/pihole:latest

With host networking, Pi-hole binds directly to your server’s network interface and DNS works correctly from all devices.

If you switch Pi-hole to host networking, its web interface will try to use port 80, which may conflict with NPM. Change the web port in pihole.toml first:

[webserver]
  port = "8800o"

Step 2: Set Up Nginx Proxy Manager

NPM is the reverse proxy that sits in front of all your services. It accepts requests on ports 80 and 443 and routes them to the right backend based on the domain name in the request.

One gotcha: if you run Tailscale on the same machine, it binds to all interfaces including [::]:443, which blocks NPM from binding to 0.0.0.0:443. The fix is to bind NPM specifically to your LAN IP:

docker run -d \
  --name nginxproxymanager \
  --restart unless-stopped \
  -p 0.0.0.0:80:80 \
  -p 0.0.0.0:81:81 \
  -p 192.168.50.116:443:443 \
  -v /path/to/npm/data:/data \
  -v /path/to/npm/letsencrypt:/etc/letsencrypt \
  jc21/nginx-proxy-manager:latest

Replace 192.168.50.116 with your server’s LAN IP. Access the NPM admin UI at http://your-server-ip:81.

Step 3: Get a Wildcard Let’s Encrypt Certificate

Here is the part that makes everything work on every device without installing any custom certificates. Let’s Encrypt can issue a wildcard cert for *.yourdomain.com using a DNS challenge, where it asks you to prove ownership by adding a TXT record to your domain’s public DNS.

The catch with .dev domains (and several others like .app) is that browsers enforce HTTPS for them no matter what. This is called HSTS preloading. So you cannot use plain HTTP even for local services. You need a real certificate.

Set Up GCP Cloud DNS

This guide uses Google Cloud DNS, but the same approach works with Cloudflare or any DNS provider that has an API.

1. Create a public zone for your domain in the GCP Cloud DNS console.
2. Note the four nameservers GCP assigns (they look like ns-cloud-c1.googledomains.com).
3. In your domain registrar, update the nameservers to the four GCP ones.

Wait a few minutes for propagation, then verify:

dig NS yourdomain.com @8.8.8.8

Create a Service Account for DNS Challenge

acme.sh needs permission to temporarily add TXT records to your domain during certificate issuance.

# Create service account
gcloud iam service-accounts create acme-dns-challenge \
  --display-name="ACME DNS Challenge" \
  --project=your-project-id

# Grant DNS Admin role
gcloud projects add-iam-policy-binding your-project-id \
  --member="serviceAccount:acme-dns-challenge@your-project-id.iam.gserviceaccount.com" \
  --role="roles/dns.admin"

# Download the key
gcloud iam service-accounts keys create ~/gcp-dns-key.json \
  --iam-account=acme-dns-challenge@your-project-id.iam.gserviceaccount.com \
  --project=your-project-id

Copy the key to your server:

scp ~/gcp-dns-key.json user@your-server:/home/user/gcp-dns-key.json

Issue the Certificate with acme.sh

Install acme.sh on your server:

curl https://get.acme.sh | sh -s email=you@example.com

Since the built-in dns_gcloud plugin requires the gcloud CLI, you can write a small Python helper that calls the GCP Cloud DNS API directly using your service account key. Save this as /home/user/gcp_dns_helper.py:

#!/usr/bin/env python3
import json, base64, time, urllib.request, urllib.parse, sys
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.backends import default_backend

KEY_FILE = "/home/user/gcp-dns-key.json"

def get_token():
    key = json.load(open(KEY_FILE))
    header = base64.urlsafe_b64encode(json.dumps({"alg":"RS256","typ":"JWT"}).encode()).rstrip(b"=")
    now = int(time.time())
    claims = base64.urlsafe_b64encode(json.dumps({
        "iss": key["client_email"],
        "scope": "https://www.googleapis.com/auth/cloud-platform",
        "aud": "https://oauth2.googleapis.com/token",
        "exp": now+3600, "iat": now
    }).encode()).rstrip(b"=")
    msg = header + b"." + claims
    priv = serialization.load_pem_private_key(key["private_key"].encode(), password=None, backend=default_backend())
    sig = base64.urlsafe_b64encode(priv.sign(msg, padding.PKCS1v15(), hashes.SHA256())).rstrip(b"=")
    jwt = msg + b"." + sig
    data = urllib.parse.urlencode({"grant_type":"urn:ietf:params:oauth:grant-type:jwt-bearer","assertion":jwt.decode()}).encode()
    req = urllib.request.Request("https://oauth2.googleapis.com/token", data=data)
    return json.loads(urllib.request.urlopen(req).read())["access_token"]

def api(method, url, token, body=None):
    data = json.dumps(body).encode() if body else None
    req = urllib.request.Request(url, data=data, method=method,
        headers={"Authorization":f"Bearer {token}", "Content-Type":"application/json"})
    try:
        return json.loads(urllib.request.urlopen(req).read())
    except urllib.error.HTTPError as e:
        return json.loads(e.read())

def find_zone(token, project, domain):
    r = api("GET", f"https://dns.googleapis.com/dns/v1/projects/{project}/managedZones", token)
    for z in r.get("managedZones", []):
        dns = z["dnsName"].rstrip(".")
        if domain == dns or domain.endswith("."+dns):
            return z["name"]
    return None

def set_txt(action, domain, value):
    key = json.load(open(KEY_FILE))
    project = key["project_id"]
    token = get_token()
    zone = find_zone(token, project, domain)
    if not zone:
        print(f"ERROR: no zone found for {domain}", file=sys.stderr); sys.exit(1)

    base_url = f"https://dns.googleapis.com/dns/v1/projects/{project}/managedZones/{zone}"
    fqdn = domain if domain.endswith(".") else domain+"."

    try:
        existing = api("GET", f"{base_url}/rrsets/{urllib.parse.quote(fqdn)}/TXT", token)
        old_rrdatas = existing.get("rrdatas", [])
    except:
        old_rrdatas = []

    quoted = f'"{value}"'
    new_rrdatas = list(set(old_rrdatas + [quoted])) if action == "add" else [r for r in old_rrdatas if r != quoted]

    change = {"additions": [], "deletions": []}
    if old_rrdatas:
        change["deletions"].append({"name": fqdn, "type": "TXT", "ttl": 60, "rrdatas": old_rrdatas})
    if new_rrdatas:
        change["additions"].append({"name": fqdn, "type": "TXT", "ttl": 60, "rrdatas": new_rrdatas})

    result = api("POST", f"{base_url}/changes", token, change)
    print(f"Change status: {result.get('status', result)}")

if __name__ == "__main__":
    set_txt(sys.argv[1], sys.argv[2], sys.argv[3])

Then create a custom acme.sh DNS plugin at ~/.acme.sh/dnsapi/dns_gcpcloud.sh:

#!/usr/bin/env bash
dns_gcpcloud_add() {
  fulldomain=$1; txtvalue=$2
  python3 /home/user/gcp_dns_helper.py add "$fulldomain" "$txtvalue"
}
dns_gcpcloud_rm() {
  fulldomain=$1; txtvalue=$2
  python3 /home/user/gcp_dns_helper.py remove "$fulldomain" "$txtvalue"
}

chmod +x ~/.acme.sh/dnsapi/dns_gcpcloud.sh

Now issue the wildcard certificate:

~/.acme.sh/acme.sh --issue \
  --dns dns_gcpcloud \
  -d "yourdomain.com" \
  -d "*.yourdomain.com" \
  --server letsencrypt \
  --dnssleep 30

acme.sh will add a TXT record, wait 30 seconds for propagation, Let’s Encrypt verifies it, and the cert is issued. The TXT record is removed automatically after.

Certs live in ~/.acme.sh/yourdomain.com_ecc/.

Step 4: Upload the Certificate to NPM and Add Proxy Hosts

In the NPM admin UI at http://your-server-ip:81:

1. Go to SSL Certificates and add a custom certificate using the files from ~/.acme.sh/yourdomain.com_ecc/:
   • Certificate: fullchain.cer
   • Private Key: yourdomain.com.key
   • Intermediate: ca.cer
2. Go to Proxy Hosts and add one entry per service. For each one:
   • Domain: sonarr.yourdomain.com
   • Scheme: http
   • Forward Host: 127.0.0.1 (or your server’s LAN IP)
   • Forward Port: 8989
   • SSL tab: select your wildcard certificate, enable Force SSL

Repeat for each service with its correct port:

Auto-Renewal

acme.sh installs a cron job during setup that checks for renewal daily. Certificates are renewed automatically about 30 days before expiry. You will want a deploy hook that pushes the renewed cert to NPM when renewal happens. The NPM API supports uploading custom certificates, so you can script this part and register it as an acme.sh deploy hook.

Result

Every device on your local network can now reach your services by name:

• https://sonarr.yourdomain.com
• https://radarr.yourdomain.com
• https://pihole.yourdomain.com

No port numbers, no certificate warnings, no installing custom CAs on each device. Works in any browser, on any operating system, including phones and tablets.

This post was written with the help of AI (Claude by Anthropic).

O diálogo ocorre entre Golan Trevize e Janov Pelorat nos primeiros momentos de sua jornada interestelar. Trevize se preocupa com a possibilidade de a nave estar equipada com um hipertransmissor, o que comprometeria a privacidade deles.

Primeiro, Pelorat pergunta:

[…]

— Ah, entendo. Quero dizer, não entendo. O que é um hipertransmissor?

Trevize responde de forma direta:

[…]

— Bom, deixe-me explicar, Janov. Estou em comunicação com Terminus. Ou melhor, posso me comunicar quando quiser, e Terminus pode, reversamente, se comunicar conosco. Eles sabem a localização da nave, pois observaram sua trajetória. Mesmo se não tivessem observado, poderiam nos localizar ao escanear o espaço próximo à procura de massas, o que os alertaria sobre a presença de uma nave ou, talvez, de um meteoroide.

O diálogo avança mais um pouco:

[…]

— Me parece, Golan — afirmou Pelorat —, que o avanço da civilização não é nada além de um exercício na limitação da privacidade.

O diálogo avança mais um pouco e em seguida, uma conclusão inusitada:

[…]

Não haveria nenhum lugar na Galáxia onde poderíamos nos esconder e nenhuma combinação de Saltos pelo hiperespaço possibilitaria nossa evasão dos instrumentos à disposição deles.

— Mas, Golan — disse Pelorat suavemente —, nós queremos a proteção da Fundação, não?

— Sim, Janov, mas apenas quando a requisitarmos. Você disse que o avanço da civilização significava a contínua restrição de nossa privacidade. Bom, não quero algo tão avançado assim. Quero ter a liberdade de me locomover como bem entender, sem ser detectado, a não ser que eu deseje proteção ou precise dela. Portanto, eu me sentiria melhor, muito melhor, se não houvesse um hipertransmissor a bordo.

Open Source Software has been around for over three decades, and by now, we’re all familiar with what it means in terms of licensing, access, and freedom. Open Source Software is defined by a few key principles: transparency, collaboration, community-driven development, and shared ownership. These characteristics ensure that users can inspect, modify, and distribute the code freely, fostering innovation, reducing costs, and promoting trust in software.

It is important to remember that there are Organizations behind Open Source, these organizations ensure that Open Source Software remains ethical, secure, and sustainable, while helping users navigate the complexities of licensing, attribution, and contribution guidelines.

So, how about AI? Like I mentioned before, if you access HuggingFace you will see millions of models, but are those models Open Source? What does define an AI model to be Open Source?

An Open Source AI model is defined by principles similar to those of Open Source Software, but with additional considerations specific to AI, such as:

• Training methodology: This includes the algorithms, hyperparameters, frameworks, and optimization techniques used during training.
• Training data provenance: This covers the sources, licenses, curation processes, and ethical considerations (bias, fairness, and data privacy) of the training data.
• Documentation: Comprehensive documentation should accompany the model, including access to source code, pre-trained weights, and step-by-step instructions for reproducibility.
• Ethical and legal compliance: The model must adhere to Open Source licenses like MIT, Apache, and address ethical concerns such as bias audits, data privacy, and transparency in model behavior.
• Community and governance: Clear governance structures, maintainer roles, and collaboration processes (contribution guidelines, version control) should be established to ensure ongoing development and accountability.

In Open Source AI, the source code must be freely accessible and distributed under permissive Open Source Licenses such as MIT, Apache, or similar. Also, these models require full disclosure of the training methodology, the origins and composition of the training data, and ethical considerations.

This is not just my own wish list. In October 2024 the Open Source Initiative published the Open Source AI Definition (OSAID), the first official attempt to say what “Open Source” actually means for an AI model. One detail worth calling out: OSAID does not demand that you release the entire training dataset. It asks for enough information about the data, its sources, and how it was processed that someone could recreate a similar model. That single choice is what makes the messy reality below possible.

Sounds great right? Well, despite these definitions and requirements, the reality of Open Source AI today is different. Many models do share access to pre-trained weights, while full source code is often not available. Training data is rarely disclosed, even when models are Open Source. This could be due to a combination of licensing constraints, legal risks (data privacy laws like GDPR), and ethical concerns like protecting sensitive or personal information in the data. Also, these models require Petabytes of data, and as you can imagine, sharing such massive datasets is not practical. One more thing to consider is that training these models isn’t simple. We are talking about tons of GPUs, which are super expensive, hard to come by, and take forever to run. For big companies, this is less of a problem, they have the budget and the infrastructure. But for smaller teams, universities, or Open Source collaborations, this could be challenging.

So, while the idea of Open Source AI sounds great, the reality is that people are stuck balancing transparency with the messy, real world stuff: legal risks, data ethics, and size of the datasets. It’s tricky, but it’s also a chance to rethink how we do AI responsibly without sacrificing progress.

Open Source AI isn’t dead, and it’s definitely not bad. In fact, it’s out there, and it’s doing some seriously cool stuff. You can download models, run them on your local machine or a dedicated server, fine-tune them, or even use them with your own private data (like with RAG). It’s all about customization, and that’s where the magic happens.

Projects like Open WebUI, Hugging Face, Ollama, and others are making this possible. They’re acting like the ‘bridge’ between the big, fancy AI models (that require mountains of GPUs and cash) and the rest of us. These tools let you pick and choose models that actually fit your needs whether you’re a student, a small team, or a nonprofit.

Check my previous post about Running your local LLM on MacOS using Docker and Ollama.

If you want to know more about Open Source and Open Source AI:

• Linux Foundation – AI & Data Foundation
• Open Source AI Foundation (OSAIF)
• Hugging Face
• Open Source Initiative (OSI)

That’s all for this post, I’m planning to keep exploring posts related to AI, so stay tuned.

First, why run an LLM locally?

• Privacy: Your data remains on your machine, reducing the risk of data leaks.
• Cost: Avoiding cloud costs associated with API calls.
• Speed: Local inference can be faster than making API call (small-scale).

Prerequisites

Everything I’m showing here was tested on MacOS 15.x with a M4 Pro cpu, but it should work on other versions as well.

• Brew : Ensure you have Homebrew installed. If not, you can install it by running the following command in your terminal:

  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
  

  • access https://brew.sh for more information.

• Docker: Ensure you have Docker installed and running on your Mac. You can download it from Docker’s official site.

  • Docker-compose

Get started

First of all, by the time I’m writing this, Docker for MacOS does not support GPU acceleration, and because I want to leverage on the GPU capabilities of my M4 chip, I’ll be running Ollama server outside of the Docker container and use Docker only for OpenWebUI, which is a web-based interface for interacting with LLMs.

Install Ollama

What is Ollama? You can think about Ollama as a package manager for LLms, which allows you to run and manage LLMs locally. It provides a simple command-line interface to download, run, and interact with various LLMs.

• Check Ollama’s website for more information.

To install Ollama, you can use Homebrew. Open your terminal and run the following command:

brew install ollama

Once installed, you can verify the installation by running:

ollama --version

This should display the version of Ollama you have installed.

To verify if Ollama is running you can check the status of the service:

brew services info ollama

You should see that the service is running like the output below:

ollama (homebrew.mxcl.ollama)
Running: ✔
Loaded: ✔
Schedulable: ✘
User: ferbass
PID: 75692

if the service is not running you can start it with:

brew services start ollama

Ok, now that you have Ollama installed and running we can download our first model to test. For this example I’ll be using qwen3:4b which is a 4 billion parameter model that should run smoothly on M4 chips.

To download the model, run the following command:

ollama run qwen3:4b

This command will pull and run the Qwen3 model right after downloading it. Alternatively, you can use the ollama pull command to download the model without running it immediately.

After download the model and run it, you should see an input interface on your terminal to interact with the model. Go ahead and try a few prompts to see how it responds. For example, you can ask it:

❯ ollama run qwen3:4b
>>> What is the capital of France?
Thinking...
Okay, the user is asking for the capital of France. Let me start by recalling what I know. France is a country in Europe, and I remember that its capital is Paris. But wait, I should
make sure I'm not confusing it with another city. Let me think... Paris is definitely the capital. I think it's also the largest city in France. But maybe I should double-check.
Sometimes people might confuse other major cities like Lyon or Marseille, but those are not the capitals. The capital is Paris, right? Yes, that's correct. So the answer is Paris. I
should present that clearly.
...done thinking.

The capital of France is **Paris**.

>>>

Cool, now that we have Ollama running and a model downloaded, we can move on to the next step: setting up OpenWebUI.

Install OpenWebUI

OpenWebUI is a self-hosted, open-source chat interface for LLMs. It gives you a web-based experience similar to ChatGPT — but fully local, private, and customizable. It’s designed to work out-of-the-box with backends like Ollama, LM Studio, or OpenAI-compatible APIs, making it perfect for macOS setups running LLMs natively. I’ll not go into details about OpenWebUI in this post, but you can check their GitHub repository for more information.

To run OpenWebUI, we will use Docker. First, ensure you have Docker installed and running on your Mac.

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
    volumes:
      - ${HOME}/open-webui-data:/app/backend/data
    restart: unless-stopped

volumes:
  open-webui-data:

docker-compose up -d

This command will start the OpenWebUI service in detached mode.

If everything goes well, you should see be able to access http://localhost:3000 and interact with OpenWebAI via your web browser using the model you downloaded earlier.

what is next

Now that you have a local LLM running using Ollama and OpenWebUI, I encorage you to explore more models and settings and try to see which one works best for you. You can find more models on the Ollama.

So far on my tests using a MacBook M4 Pro with 48GB of RAM, I was able to run models size up to 8B parameters without any issue.

I encorage you explore different models, settings, and try to play around with Knowledge Base, Tools and Function which I will explore in future posts.

Thanks

That is all. I just wanted to share my feelings and how inspiring RubyKaigi is for me and many other Rubyists

One more thing: I would like to share a book by my friend Guilherme Orlandini Heurich, an Anthropologist who has studied the Ruby community for the past few years and has released the book called CODESPEAK.

Thank you

#rubykaigi #rubykaigi2025 #inspiration

First find the key you want to change the password

$ gpg --list-keys

I particularly like to use --list-keys with --keyid-format LONG parameter, to get the long key id, which is easier to work with.

$ gpg --list-secret-keys --keyid-format LONG
[keyboxd]
---------
sec   rsa4096/87C6D385122B1669 2017-12-04 [SC]
      7D30FFF3FC256153A59AEA698726DF85922B8669
uid                 [ultimate] Fernando Bass (no comments) <xyz@mail.com>
ssb   rsa4096/7A822B866BD5E7D1 2017-12-04 [E]

In this case, the key id is 87C6D385122B1669.

Now lets change the password

$ gpg --edit-key 87C6D385122B1669

This will open the gpg console, where you can change the password

gpg> passwd

If your key is protected, you will be asked to enter the current password, after that a prompt asking to type the new password and confirmation will be displayed.

If everything goes well, you should be redirect to the gpg console, where you can save the changes.

gpg> save

Thats it, after save your changes you can start using your GPG Key with the new password.

Thank you

The part nobody warns you about

Here is the thing nobody tells you when you move from engineering into management. The day you take the job, you stop shipping code, and your output stops being your output. It becomes whatever your team ships. That sounds obvious until you live it. Your instinct is still to open the editor and fix the bug yourself, because that is what you are good at and it feels productive. But every hour you spend doing your old job is an hour you are not doing the new one.

The hardest part is technical credibility. You earned your spot because you were a good engineer, and you can still read the pull request and see the better way to do it. The question is whether you should. Jumping in and rewriting someone’s code proves you are smart and teaches them nothing. Most of the time the right move is to ask a question and let them get there themselves, even if it is slower, even if it is not how you would have done it. Letting go of the keyboard is most of the job, and it is much harder than it sounds.

And yes, the question every engineer asks: do I keep coding? My answer is a little, on things that are not on the critical path, so you do not lose touch with the tools your team lives in. But the moment your coding becomes a blocker for someone else, you drop it. Your job is now to make the team fast, not to be the fastest person on it.

First of all, if you are a manager or in a management position, you have to remember that delivering the project is the goal, but to get there you have to manage people. And people are not robots. They have feelings, they have personal problems, they have their own goals, and you have to understand that. You can read tons of books on how to manage teams or projects, but dealing with people is not something you learn from a book. You learn it through the relationships you build over time.

A successful manager is the one who can listen to their team, understand their needs, and help them achieve their goals. Not the one who is there only to create Gantt charts and burndowns and keep asking for daily reports. A true manager trusts their team. If you do not trust your team, you have to reconsider something. And most important of all, a manager who has the team on their side can achieve the impossible.

What trusting your team actually looks like

Trust is easy to say and hard to do. In practice it means handing people a problem instead of a task, and letting them own the solution. It means removing the blockers in their way and then getting out of the way. It means a one on one that is about them, their growth and what is frustrating them, not a status update you could have read in the ticket. And it means taking the hit publicly when something goes wrong, and giving them the credit publicly when it goes right.

Do those things and you will not need to ask for daily reports. You already know how your team is doing, because you actually talk to them.

To finish, if you are a manager or want to become one, be ready to make decisions when they are needed, even when you do not have all the information you would like. Someone who cannot make a decision and take responsibility for it should never become a manager.

A manager’s job is not to receive orders, ask for status updates, and keep a spreadsheet up to date. If your job is all about checking the backlog and creating reports, then I am sorry, but you are not a manager. You are a bureaucrat.

Further reading

This post is my opinion, not a manual. If you want to go deeper and learn from people who have written proper books on the subject, these are the ones worth your time:

• James Stanier, Become an Effective Software Engineering Manager — the most direct answer to “I am an engineer, now what do I do as a manager?”.
• Camille Fournier, The Manager’s Path — the path from tech lead to senior leadership, stage by stage.
• Will Larson, An Elegant Puzzle: Systems of Engineering Management — for the systems and structure side of the job.
• Andrew S. Grove, High Output Management — the old classic, still the best on leverage and output.
• Kim Scott, Radical Candor — on caring about people while still being direct with them, which is most of what I wrote about above.
• Will Larson, Staff Engineer: Leadership Beyond the Management Track (2021) — the reminder that management is not the only way up. You can lead as a senior engineer without ever managing people.

This post was written with the help of AI (Claude by Anthropic).