Software and Other Shenanigans

Category: Go

  • Building a local RAG in Go

    I had to go through an “AI” course recently for work, which included a couple of homework assignments. The intent was that these would be company-specific, but because 1 of these had to be posted on GitHub1, I have a version without internal data. That was the RAG assignment (probably the closest thing the “AI” hype has to a redeeming value). In theory, this would seem academically dishonest, but 1) I had to make the repo public to submit it, 2) it wasn’t really “graded” so much as “checked to see you did it at all,” 3) assumed that everyone was just slopping it out as a vibe coding exercise anyways. Since they didn’t really seem to care if learned anything, I don’t really care about posting the answer. For people who do want to learn and do it themselves, this isn’t really that complicated, and can be done in your spare time over a weekend.

    (more…)

  • The curious case of the unrun defer

    Over the course of learning Go, I’ve come to like some aspects of the language. 1 of those is the defer statement. For those that aren’t familiar with the language, defer queues up a function call for just before your current function exits. I’ve found it similar in purpose to a finally statement in Java, a keyword that helps ensure that some piece of code is run. It’s just that defer can be put right next to the thing I want to clean up, instead of trying to remember to include it at the very end of a wrapper around everything. As part of testing what I write by just running the code, I’m setting up a databases for test packages, and using defer to clean them up once the package tests are done. Except…the defer wasn’t running. So, what gives?

    (more…)

  • Simple and easy HTML validation in Go

    I didn’t spend as much time in 2025 working on my gift registry, so all I really have is a login flow and profile management. I am building out a test suite that seems to do a pretty good job of validating the code works (I’ve only had a couple of bugs the automated tests didn’t catch, but did after a quick update, and more than a few that the tests did catch) – mostly because I’m just running the code when I test. It’s a server-side rendered app, using Go’s html/template package, so validating the output has been more difficult than reading JSON data like you would in a traditional web app. I tried Playwright, and that was really handy, but also slower than I wanted, so I abandoned it1, and wound up just writing a quick-and-dirty depth-first DOM search that does the validation that I really need, which wound up being a lot easier than I thought.

    (more…)

  • If you’re going to just run the code, just run the code

    I’m very pro “just running the code” when it comes to testing software. But while just spinning up containers does actually “work” – in the sense that the test runs and completes without error. But you very quickly realize that’s clearly not how these things are supposed to work. I’ve been using testcontainers to test the gift registry app I’ve been working on, and it’s been great. I’ve implemented a basic passwordless login setup, and I can test every part of this using live code with the sole exception of actually sending an email via a simple make test. But this was very obviously not the best way to go about it, as you can see from the test output:

    (more…)

  • You can just run the code

    So I haven’t made as much progress on the actual gift registry I wanted to write this year, although I do have a Go web application that connects to a Postgres database, with an endpoint that gets the database stats, collects telemetry data, pipes it all to an OpenTelemetry stack, and returns an HTML page with the health check results (server-side rendering is a much more pleasant experience than trying to wrangle Javascript frameworks). I also have tests that confirm this is working. That took a lot longer to set up than I anticipated, but I’m really happy with what I’ve been able to do.

    (more…)