Pipelines
Code coverage is one of those underrated indicators of quality. Recently, I had a Scala-based job opportunity and decided to build a REST API over the well-known DVD Rental database. For me, tests aren't just about correctness — they're about risk. If you need 10,000 tests for one function (a touch of exaggeration), maybe it's time to refactor.
Scala's Scoverage tool showing test coverage metrics - click to view full size
Scala's coverage tool, Scoverage, worked nicely, and getting it running inside my Gitea pipelines was straightforward. There are plenty of pre-built actions, or you can roll your own in Go if you prefer a hands-on approach. Over two weeks, I could see my coverage graphs climb — a satisfying sight.
Pipeline execution showing automated testing and coverage collection
Scala reminded me a little of Rust: powerful, expressive, occasionally uncompromising. My only regret? Not containerizing it. Didn't get the job — perhaps they wanted a LeetCode wizard. I'm more of a make-things-work person. Oh, and I also spent time with Scala.js — all I can say is gosh.
OpenTel
In a previous role, I lived inside Microsoft Application Insights, but the landscape has shifted — OpenTelemetry now wears the crown, and I think that's fantastic. Combined with Honeycomb, the visibility is superb.
OpenTelemetry traces showing distributed requests across multiple gRPC services
To really understand it, I built gRPC services across five languages —
I expected Rust to be the hardest, but it turned out surprisingly smooth. Comparing languages side by side was rare and rewarding. For me, observability isn't an afterthought — deciding what to measure early shapes how well you can support what you build later. It's not just about writing code; it's about ensuring it lives well in production.
Grafana
Whenever I use a service, I like to implement it myself — it gives me perspective on what's under the hood. After working with Honeycomb, I decided to roll my own observability stack using Grafana, Prometheus, and Loki.
Home lab Grafana dashboard monitoring Postgres, MySQL, Redis, Wiki, Gitea, and more
It's remarkable how easily you can get meaningful data from an app into a dashboard these days. I run Postgres, MySQL, Redis, Wiki, Gitea, Postfix, and Dovecot (to name a few). Monitoring has always been part of my workflow — I've run Linux since 1997, and back then top and syslog were my Grafana.
Grafana's clean separation between data collection and visualization feels elegant. Not all tools in the ecosystem are perfect — Promtail can be flaky — but its successor, Alloy, looks promising.
Containerization
Containers have been a gift for my home network. Most of my services — Wiki, Webmail, Elasticsearch — now run in Kubernetes. The first setup wasn't smooth (Webmail gave me a few grey hairs), but since then it's been rock solid.
The best part? I upgrade Grafana when I choose, not when Ubuntu's repositories decide. It's not necessary, but it's satisfying — the same way running your own infrastructure keeps you sharp.
Back when I was a PM, everyone worried about whether the hardware matched production exactly. Containers have completely solved that. Now, you can have n environments instead of just Prod, UAT, and your laptop. Done well, containerization doesn't just make deployment easier — it tightens security and simplifies the whole lifecycle.
The 25% Truth
"Writing code is maybe 25% of building production systems. The other 75% is making sure it works, scales, and stays working."
Anyone can write a function that works on their laptop. The real craft is in building systems that work reliably in production, scale gracefully under load, fail predictably, and can be debugged at 3 AM when everything's on fire.
That's where pipelines, observability, monitoring, and containerization come in. They're not just nice-to-haves — they're what separates hobby projects from production systems that people actually depend on.