Golang

Every few months I find myself stuck on the same kind of question: what exactly is hitting my service? A reverse proxy is mangling a header, a Kubernetes ingress is rewriting a path, a webhook provider is sending a body in some shape I didn’t expect. The fastest way to answer is to point the traffic at something that will tell me, in painful detail, what arrived.

That’s why I wrote http-echo: a tiny Go server that responds to any HTTP request by dumping a structured, human-readable report of everything it saw.

Once in a while I need to throw a directory online. Share a build artifact with a colleague, expose a folder of files inside a Kubernetes cluster, mount a release directory behind an internal nginx — the kind of task where a full web server is overkill and python3 -m http.server is too primitive.

That’s the niche httpfileserver fills: a single static Go binary (or a scratch-based Docker image) that serves a directory, with the few quality-of-life features I always end up wanting.

When a service starts misbehaving, my first reflex is ping. It tells me almost instantly whether the box is up, whether latency is sane, and whether anything weird is going on at the network layer. The trouble is that for HTTP services, ping answers the wrong question. The host can answer ICMP just fine while the application returns 502s every other second.

httping-go is my Go take on the classic httping idea: a tiny CLI that hits a URL on a loop and prints status code, latency and response size. It’s the tool I reach for when I want a quick, continuous feel for how an HTTP endpoint is behaving.

Every time I needed to inspect a JWT, I ended up doing the same thing: paste it into a website I half-trust, squint at the payload, then close the tab feeling vaguely guilty. I wanted a local tool, scriptable, that could both decode tokens and mint them for testing. So I wrote jwt-cli.

I have a recurring frustration: I run a script in CI, it produces output, something fails, and I have no idea when any of it happened. Did the failure come 200ms after start or two minutes in? Was it stdout or stderr? It’s the difference between “took a minute to figure out” and “took half an hour.”

The fix is to prefix every line with a timestamp. Easy in theory, annoying in practice — especially if you want the prefix to differ between stdout and stderr, or if you want UTC, or colors, or to drop the prefix in production. So I wrote logwrap: a small Go binary you put in front of any command and it adds a configurable prefix to every line, in real time, without buffering.