A sanitized log from a long build-and-deploy day: shipping the fix for yesterday's admission-webhook bug, then a multi-hour battle to stand up an edge gateway in a lab so I could reproduce a memory issue. Names, tickets, and hostnames are private; the patterns transfer.
A sanitized log from a day closing out an offline-resilience investigation on a secrets gateway. The punchline: my inability to reproduce a customer's failure was itself the clue. Specifics are private; the patterns transfer.
A sanitized log from a day spent reproducing an "it fails when we're offline" report against a secrets gateway — and rediscovering that a repro is only useful if it fails the same way the customer's does. Specifics are private; the patterns transfer.
A sanitized log from a day spent chasing a spike of "credentials expired" 401s that nobody could attribute to a client, plus a responsible-disclosure detour when I noticed a CI provider's raw job logs were readable without authentication. Specifics are private; the patterns transfer.
A sanitized log from a day split between site automation, cloud-provider edge cases, certificate tooling, and a noisy gateway investigation. The details are private; the useful parts are the patterns.
An experiment: a daily, public log of what I worked on — stripped down to the parts that are actually transferable. No customer names, no internal ticket numbers, just the engineering lessons that survive being taken out of context.
Today had three things worth writing down.
Another sanitized log — the transferable parts of a day that was mostly "where exactly does this run, and is the thing I think is fixed actually fixed?". Four lessons worth keeping.
When you see too many open files in a containerized app, it’s tempting to jump straight to ulimit -n. Sometimes that’s correct. But on Linux (especially with Go apps using fsnotify), the error can also be caused by inotify limits—even if your process has a huge file-descriptor limit.
This post is a practical, copy/paste-friendly checklist to debug the problem on a real Kubernetes cluster.
During a debugging session of one of our NodeJS microservices misbehaving on a Windows Server 2019 instances, I opened the microservice log to begin investigating the faulty behavior.
A few months ago, I received a highly-anticipated 2020 32GB, 2.3 GHz Quad-Core Intel Core i7 MacBook Pro. Highly-anticipated because I already had one stolen (a 2019 version) earlier last year in a robbery in an AirBnB apartment I was renting while I was staying in Barcelona. It was quite a dramatic story but I won’t get into the details. This is a tech blog after all.