Dawid Zbinski

It started with a hiking route. I wanted to send a friend a trail on Skye and the link was well over a hundred characters of ?ref=, t_s=referral and t_cid=route_share glued to the end of it. Every link I share these days looks like that. Someone else's marketing department riding along in my message. So I did what everyone does and pasted it into a URL shortener. Sign up first. Then a dashboard. Then click analytics I never asked for, an interstitial with an ad, and a short domain I don't control that will happily die or start redirecting somewhere else the day the company pivots. I got mad enough to build my own.

The requirements were short. One URL in, one short link out, a QR code for the same link, and absolutely nothing else. No accounts, no cookies, no analytics, no ads. Links expire on their own so there is never anything to prune. And it has to run anywhere with one command, because the whole point is that you host it, not me.

shortr is a Go 1.27 API on Fiber v3 that serves the JSON endpoints, the redirects and a plain TypeScript client bundled by esbuild. One binary, one image. The image is distroless, around 15 MB, built for amd64, arm64 and armv7, so it runs on a VPS as well as on the Raspberry Pi in the drawer. docker run -d -p 8080:8080 dawidzbinski/shortr:latest and you're done. The client is one page with two tabs, Shorten URL and QR code. It remembers which one you used last, the result is copied to your clipboard the moment it appears (the QR as a PNG), and the whole thing works from the keyboard.

Privacy is the reason it exists, so it's the part I spent the most time on. Codes are 12 characters from crypto/rand, drawn without modulo bias, roughly 71 bits, so nobody can enumerate your links. Every response carries noindex, nofollow, noarchive, robots.txt disallows everything, and known crawlers get a 403 on the client and the API. Strict CSP, no inline scripts, no external requests at runtime, fonts self-hosted. The API is rate limited per client IP; the redirects never are, because a link that stops working under load is worse than no link at all.

Storage sits behind one interface with four methods: SaveURL, FindURL, Ping, Close. Each adapter validates its own environment variables, so the core config knows nothing but the adapter's name, and adding a new backend is one file plus one case in a switch. Three ship today. memory is the default and keeps links in the process, perfect for trying it out and for a container you don't mind restarting. redis writes url:<code> with SET NX EX and lets Redis own the expiry, which is what you want when running more than one replica. And file, which is the one with a story.

I deployed the memory adapter to my own server, shortened a handful of links, and then redeployed. The links were gone, obviously. My first instinct was to snapshot memory to a mounted file every few seconds, a backup for the in-memory map. Then I asked myself why the links had to live in RAM at all. I briefly considered SQLite, since it's basically the same problem and I didn't want to reinvent a database. But the popular driver needs cgo, which kills the static distroless build, and the pure Go port adds several megabytes to a binary that is currently tiny, all for a query language I would use on a single-key lookup. bbolt won. It's a pure Go B+tree in a single file, a lookup reads exactly one key without touching the rest of the file, every shorten is one transaction that is durable the moment it returns, and the database is opened under an exclusive lock so a second process fails fast instead of corrupting it. Mount a volume on /data, set URL_PERSISTER=file, and your links now survive restarts without a Redis next to them. While I was at it I replaced the raw JSON 404 for expired links with a proper page, because the first thing people see from your shortener should not be an error blob.

Releases are boring on purpose. Every commit that lands on main and passes CI gets tagged, released and pushed to Docker Hub as a multi-arch image. The version comes from the commit subjects since the last tag: feat bumps minor, breaking bumps major, everything else is a patch. I never push an image by hand.

What's next: a Postgres adapter is the obvious candidate, and the interface makes it a small job. Otherwise the plan is to keep it small. A URL shortener that grows features is how you end up with the thing I was running away from.

It's free for noncommercial use under the PolyForm Noncommercial license. Check it out on GitHub, read the docs at flyrell.github.io/shortr, or grab the image from Docker Hub.

Like many devs, I forget to log daily activities. End of the month comes and I'm scratching my head trying to remember what I worked on three Tuesdays ago. It started as a simple branch-tracking tool — just to remember what I was doing each day. Then I realized: why not keep all hours logged locally in a git-like format and export them at the end of each month?

My first approach was post-checkout hooks with custom commits. Every time you switched branches, a hook would fire and create a tracking commit. Seemed clever until I learned post-checkout hooks are unreliable — they don't fire on all checkouts, can be skipped entirely, and conflict with other hooks people already have set up. Dead end.

Then it hit me: git reflog already records every checkout. Every single one. The data was always there — I just needed to parse it. The pivot to reflog parsing changed everything. More reliable, zero setup friction, no hook conflicts. You install hourgit, and it works with your existing repos immediately.

The current trade-off is memory. I haven't found the optimal fs reading approach yet, so all entries load into memory. But I benchmarked it and ~10,000 entries come out to roughly 200KB with the fs read taking about 0.3–0.5s. Good enough for now. I'll optimize when it actually becomes a problem.

What it can do today: automatic time attribution from checkouts, manual logging for meetings and standups, interactive reports with inline editing (vim-like hjkl navigation), multi-project support with per-project schedules (including rrules), PDF export, shell completions, and full cross-platform support.

What's next: rounding logged time to configurable intervals, using commits between checkouts as time block descriptions for better context, and export integrations to Jira, Tempo, and Clockify.

It's free, GPLv3. Check it out on GitHub or visit hourgit.com.