Kevin's Ramblings

The name and inspiration for this post comes from an excellent resource I’ve had to the pleasure of knowing for several years. Nick, I’ve shamelessly stolen it. I’ve been building dashboards for nearly twenty years. Some were good. Some were terrible. Most were somewhere in between. If you’ve built dashboards in an IT environment, you’ve probably had the same experience. So, this isn’t a shame…

I’ve spoken about documentation and the growing divide between the systems we design and the end users consuming such systems, but there’s something almost ephemeral that bridges the two: learning how to break down a story. I’ve always had a passion for learning different things – outside those that are part of my career – and that’s helped me build up a generous thesaurus of analogies. I’ve…

If you read Communities Fail When They’re Treated Like Features, you already know the problem. Treat community like a feature and it will behave like one: temporary. This is the hands-on playbook. This is the stuff you can use tomorrow. I wrote this from the inside. I was a community manager, a product manager for products discussed on that community before that, and a member as a customer…

Let’s be blunt: building a community and checking boxes look the same on a roadmap. Both get resources assigned, both get line items, both can be marked “done.” But they are not the same thing. A community is a living system. It grows, it needs food, it gets sick, and it thrives when people care for it. Treat it like a feature – something you ship, measure by a single metric, and forget – and it…

Logs are often treated as if they’re complete, atomic truths: a line appears, something happened, and that’s the end of the story. But anyone who has ever tried to build real observability knows that a single log line rarely tells you anything meaningful. Logs are fragments. Observability is the reconstruction of what those fragments actually mean. The difference between the two is…

There’s a quiet truth in every technical organization: documentation is the product. Not the UI. Not the API. Not the architecture diagram. Documentation is the thing that determines whether people can actually use what we built. But we rarely treat it that way. We treat documentation like a side quest. It’s something we’ll “get to later,” something that’s “nice to have,” something that exists…

Picture it: You’ve spent weeks and weeks building a new observability stack.  Everything is in there: metrics from servers, traces from various applications, details about APIs, synthetic transactions, even NetFlow.  You’ve reached monitoring nirvana – everything is in there and it looks beautiful.  You present it to the management, the application owners, the other teams, and… crickets.  Until…

At some point, reading about observability stops being enough. You actually have to build something. In my case, that turned into building not one, but two different stacks that I’m running side by side. One built around Elastic, the other taking a different approach with Prometheus. The goal is not to pick a winner. It is to understand how they behave in the real world. Which has been……

In part 1 I wrote about why I built this. In part 2, I wrote about some design decisions. In this part I’ll explain why I wanted Docker as the platform. Docker Was a Product Decision Docker isn’t just packaging—it’s User Experience (UX). The goal was: “You can deploy this in under a minute.” With Docker, that becomes: docker run -p 4278:4278 kmsigma/utm-qrcodes:latest No SDKs. No installs.…

I cut my teeth with PowerShell ISE and still have fond memories of it. But VS Code now rules my world – and that’s ok. Moving forward is progress. But one of the annoyances I’ve had since moving my PowerShell coding from the ISE to VS Code is the lack of the original snippets. In truth the PowerShell snippets that ship with VS Code are (generally) vastly superior and I use them all the time. But…

It's my 10 year anniversary on Tumblr 🥳

Preamble Building a PowerShell module should not be too hard. In fact, on the surface it’s pretty simple. Collect a bunch of functions, classes, enumerations, (whatever else you want), bundle them together and provide a wrapper in the form of a PSD1/PSM file. My go-to reading and guidance material for this is PowerShell Scripting in a Month of Lunches. Building a module should be straightforward…