If you’ve spent time with Go, you’ve likely heard these two proverbs: Accept interfaces, return structs. The bigger the interface, the weaker the abstraction. They’re short, a bit cryptic, but packed with wisdom. Together, they guide us to keep interfaces small and flexible while letting concrete types shine when needed. But what happens when your system has both common functionality everyone needs and specialized features unique to specific implementations?…

(Or: Making Feature States Actually Visible) Staring at bVa/2025.3.1:AFFDC01F.0.3C and trying to mentally parse which features are in testing versus production remains a challenging exercise. Comparing two version strings to understand what changed between deployments requires translating hexadecimal values back into meaningful feature states—a process that’s both time-consuming and error-prone. Visual representation solves this fundamental readability problem. QR codes provide an ideal visual grid structure that can be augmented to serve both machine and human readers simultaneously.…

Bitmaps and Reflection: A Programmer’s Quest for Cleaner Template Functions In creating my own Hugo clone, I encountered a common programming challenge: writing similar code repeatedly with slight variations. The Problem: Template Functions Are Weird Go template engine functions need exceptional flexibility. They must: Accept varying parameter counts Handle different parameter types Support optional parameters Maintain type safety Consider Hugo’s substr function. It can be called as substr("hello", 1, 3) or simply substr("hello").…

Cascading Functional Options in Go: An Elegant Pattern for API Design This is part of my series on the njones/socketio server implementation. I occasionally employ techniques that might be unconventional, and I’m curious about their prevalence in the wider Go community. If you’ve used similar approaches, please leave a comment—I’d love to gauge how common these patterns actually are. In the world of Go, functional options have become a popular pattern for configuring objects, thanks to their flexibility and readability.…

Introducing a new style of writing tests in the socketio package. This update will help writing tests for the package clean and consistent. This should allow people new to the page to quickly understand what’s going on so they can help in efforts to provide comprehensive testing. The current tests in the project usually follow the format: var tests = []struct{ name string param1 string want string }{} for _, test := range tests { t.…

(Or: How I Learned to Stop Worrying and Love the Bitmap) Quiddity quid·di·ty /ˈkwɪdɪti/ (noun) The essential nature of a thing. The “thing-ness” of a thing. What makes a thing that specific thing and not some other thing. A distinctive feature; a peculiarity. Remember that moment when you realized your versioning system was about as helpful as a chocolate teapot? That was me, as I was designing a CI/CD pipeline that needed to handle rollbacks and integrate with a feature flagging system.…

Acknowledging the “I hate if err != nil” crowd While I find it only mildly annoying to type the revered statement, I’ve researched ways to eliminate it while designing a new programming language. Once we get past this aspect, we can explore better ways to handle errors in Go. See my repo here for the code. Things have gotten better over the years Beyond the if err != nil situation, there have been discussions about improving error handling from the early days of Go.…

This is a series of blog posts about how the njones/socketio server was built. There are some things that I think are unconventional, and I would like to know if they are more popular than I think. Please leave a comment if you’ve seen these techniques before, it would be nice to see how common they are. Versioning any API is tricky. This is not the version number, but the actual application interface.…