hlfshell Keith Chester

golang

scaffold + toolbox: local environments as Go services

Scaffold logo

About a year ago I updated docker-harness, a tool I’ve used in several of my golang projects in order to generate realistic integration tests by making it easy to create complex environmental stacks locally. The idea was simple - at some point you have to test the SQL you write against a real database. Or the network call against the real service. If you can self host it easily in a reusable wrapper, why not?

After updating it, I realized that maybe I could take it from a test-focused library to a generic environmental one, where I dive deeper on the unique idea I kind of played with in docker-harness. Maybe it could be a useful enough tool that local clones of environments could be quickly deployable?

So I started playing with the idea, extending the idea of a set of stacks that are modular and composable; a common theme across my work apparently. The result is scaffold - a Go library for composing environments and stacks out of smaller pieces / services. A service has a small lifecycle: create it, clean it up, and read its logs. A stack groups those services into an environment an application or developer tool can manage. I’ve been using it to emulate a super complicated distributed microservice platform with lots of disparate pieces to unlock easy local development for my coworkers.

scaffold-toolbox was created as an addendum, supplying premade stacks to build from. Each toolbox entry is its own Go module. View it as a LEGO set to start building your quick launch envs.

sandboxed

sandboxed logo

The most common theme in most of my golang libraries is - “I needed it for another larger project”. Queue a side quest and boom, new library. sandboxed is no different.

sandboxed is a Go virtual filesystem for storing untrusted data as encrypted chunks. The original project driving the need for this is still too early; I’ll talk more about it when I have something substantial to share. I wanted the ability to download arbitrary binary data and protect the system from it.

This might make a few of you go “why the hell would you want to do that?”; well, wait for the other project. Others might point out that a virtual machine would be a great way to isolate the payload. No argument here. I have my reasons for wanting to avoid virtualization here.

So what does sandboxed do? It presents an fs interface for use in golang where a manifest file tracks individual files within the “file system”. Every file is streamed through a per file encryption buffer when writing data to disk. The encryption is less about security of data exfiltration and more about unpredictable scrambling of potentially malicious payloads.

You are still susceptible to malicious payloads at time of reading (or, and please don’t do this, execution) but that can be handled with care towards what you’re handling at any point.

sandboxed is mostly about protecting the host system from at-rest data triggering exploits from scanning / read attacks.

Updated SafeStop

About five years ago (ok, that hurt to type. The days are long but the years are short…) I wrote SafeStop. I had made it to coordinate proper shutdown protocols across multiple services running in a large monolith application.

I decided to renew it, modernize it, and added some dependency features (so service B can shutdown after service A is shutdown, etc).

Another product of my recent golang kick.

structured-parse release

Just released structured-parse, a multi-language parser for block labeled LLM output. It’s based on the parser I had built for arkaine.

Here’s what I mean by “block labeleled” output:

Thought: I need to search for information about robots
Action: search
Action Input: {"query": "robots and why they're so cool", "max_results": 5}

This output is not only more human readable, but also easier for LLMs to produce. But there’s a catch - LLMs tend to still introduce nondeterministic volatility towards these outputs; humans are just good about reading through that. structured-parse is a robust parser that can deal with this, allowing LLMs to reliably follow instructions and allowing your code to parse it into clean, typed data structures.

structured-parse is written in Go with exports to TypeScript/JavaScript and Python via WebAssembly; so it’s all golang at its core.

Give it a try!

docker-harness got a mini-makeover

Just pushed a pretty significant update to docker-harness. It was a tool I created originally to power some of my Docker containerized database tests.

I pulled out the dependencies for each database to modularize it a bit. Each database module (MySQL, PostgreSQL, Redis, Memcached) now has its own go.mod and go.sum, which means you only pull in the dependencies for the databases you actually need.

Also added some dependency updates, taking out old dependencies that weren’t needed anymore, while also ensuring that anything that has been deprecated or abandoned wasn’t being used.

go-arkaine-parser

Back when I was working on coppermind at the heyday of GPT3.5’s initial world shattering release, I had… difficulty finding good ways to deal with parsing the stochastic LLM outputs.

I got better at this when I started work on arkaine, eventually developing a pretty useful and reliable parsing pattern.

With an idea that would be best served as a golang app requiring interacting with LLMs I decided to do a quick port of the parser to an idiomatic golang module.

So if you need AI parsing for your golang project, check out go-arkaine-parser.

Golang Docker Harness

tldr; Sometimes you just need to call out to a database instead of mocking it; to that end I created this module to allow one to quickly create and dispose of docker containers for tests. The Problem Generally when writing unit or …

Read article →