Evan Moses

My Policy on AI

Sun, 15 Feb 2026 00:00:00 +0000

All the writing on this blog is mine.

I write this blog because I enjoy writing and I’d like people to read what I’ve written¹. I’ll use LLMs to grammarand spell check, although I find they rarely do a better job than just re-reading what I’ve written.

I think I’m a reasonably good writer. I’m not against LLMs writing for me per se, but as of now they write badly and with lots of cliches, and I am against bad writing.

The illustrations on this blog are AI-generated

I think I’m a reasonably lousy visual artist. I don’t make any money off this blog. If I didn’t image-gen someillustrations I wouldn’t pay anyone to draw them for me, so there just wouldn’t be any. A good image or visual pun canpunch up an article: I think the Shelf of Despair in this postis pretty funny, and I prompted Nano Banana for a while to get it how I liked it.

I use LLMs as tools to help me write code

I’ll use them for what they’re good for. That’s changing weekly, but at the time of this writing in early 2026:

They’re excellent at generating boilerplate with my codebase or doc for reference.
They’re pretty good at mechanical refactoring
They can code up a good starting point for unit test cases
They’re perfect for getting started on a greenfield app in common languages and frameworks

In general, if the thing I’m trying to do would involve me googling doc or Stack Overflow answers and 90% of the resultwould be copy/paste from what I looked up, an LLM can do it significantly faster than I could.

I treat a coding agent like an inexperienced but sharp junior dev, but one that doesn’t learn day-to-day. You can giveit a well-defined task and it’ll give you a pretty good result, but if you ask too much of it without looking over itsshoulder you’ll end up with a real mess.

I generally review all its generated code as if I was reviewing a PR, and I’ll rewrite it or pick-and-choose from itsresults as I see fit.

When I use AI for anything non-trivial I will credit it.

Simple, easy, honest.

Ok, and because I enjoy the dopamine hit of watching the hit-counter go up, I’m human. Kinda the point, no? ↩︎

Yak Power-Shears: LLMs are pretty good at Emacs

Tue, 27 Jan 2026 00:00:00 +0000

I’ve been an Emacs user for more than 25 years, and I’d say I’ve got a reasonable handle on customizing it. I can writeelisp, and I’ve got a couple decades of accumulated tweaking cruft on display in my dotfilesrepo. I’ve writtenadvice, I bind custom functions to keys, andI’m actually writing this right now with a customized mode for Hugomarkdown that I ginned up when Iwas getting annoyed by the way fill-paragraph worked inside Hugo shortcodes.

The reason Emacs is so attractive to those of us who use it is its infinite customizibility. There’s really not muchyou can’t alter or intercept or rewrite with enough effort, and over time your editor will come to fit you like awell-worn boot.

However, there are plenty of minor annoyances that I just live with. No one’s built the exact package that I want, andlearning enough to do it myself would be shaving just oneyak too many. So I do things by hand,or use the mouse instead of having a shortcut that jumps to whatever-it-is, or I deal with the hard-to-read log outputinstead of nice syntax highlighting.

LLMs: yak power-shears

LLMs, it turns out, are pretty good at elisp. There is a ton of open-source training data and gooddocumentation. So far I’ve successfully had Gemini or Claude build me:

A tree-sitter grammar and major mode for the Cedar policy language
A function to extract backtraces from a json-formatted log that my application at work emits, and pretty-print them
Syntax highlighting for my application’s Go test logs that plays nice with go-test-mode.

Unfortunately my biggest successes have all been for work, done on work machines with AI paid for by work, so I can’tpublish them here (at some point I’ll go through channels and see if I can open source some of it), but here’s someredacted logs that show the pretty formatting I was able to achieve:

And here’s a slightly-mangled version of the code that produces it. Note most of the comments and doc comes straightfrom Gemini:

(defgroup work-log-faces nil "Faces for Work integration test logs.");; Define faces(defface work-log-timestamp  '((t :inherit font-lock-comment-face :foreground "#6c757d"))  "Face for timestamps." :group 'work-log-faces)(defface work-log-level  '((t :inherit font-lock-keyword-face :weight bold))  "Face for log levels (INFO, WARN)." :group 'work-log-faces)(defface work-log-message  '((t :inherit font-lock-string-face :foreground "#e0e0e0"))  "Face for the log message text." :group 'work-log-faces)(defface work-log-json  '((t :inherit font-lock-constant-face :height 0.9))  "Face for the JSON payload." :group 'work-log-faces);; Define the matching rules(defvar work-log-font-lock-keywords  '(("^\\([0-9T:.-]+\\)[ \t]+\\([A-Z]+\\)[ \t]+\\(.*?\\)[ \t]+\\({.*}\\)?$"     (1 'work-log-timestamp t)     (2 'work-log-level)     (3 'work-log-message)     (4 'work-log-json)))  "Regex keywords to highlight structured logs.");; 1. Define the control flag (default to nil)(defvar -work-test-highlighting-active nil  "If non-nil, apply custom log highlighting in go-test-mode.");; 2. Define the function that checks the flag(defun my:work-apply-logs-highlight ()  "Apply highlighting only if the Work test flag is active."  (when -work-test-highlighting-active    (font-lock-add-keywords nil work-log-font-lock-keywords t)));; 3. Add it to the hook;; Note: go-test usually runs in `go-test-mode` or `compilation-mode`(add-hook 'go-test-mode-hook #'my:work-apply-logs-highlight)

Specifics

So far I’ve used two primary interfaces to LLMs: Claude Code, especially Claude-code-ide forEmacs, and the Gemini web interface. For Claude I’ve been using Opus4.5, for Gemini 3 either Thinking or Pro. Keep in mind that most of the time my company is paying for tokens, so I’mnot being particularly cost-conscious (sorry, bean-counters). I haven’t done any serious comparisons of models andinterface because…all the modern models work pretty well for this sort of thing.

For both syntax highlighting and the backtraces, I was able to simply paste in a sample of the input and describe whatI’d like, and it was able to give me some elisp I could drop into my .emacs.d.

The ts grammar and mode needed a bit more back-and-forth and some actual debugging (by both myself and Gemini). I thinkif I had less elisp experience I wouldn’t have been able to vibecode the whole solution, but I’ve never really written ats grammar or a major mode before that was more than a tweak or two, and it got me 80% of what I needed.

Go forth and customize

The code that Gemini wrote for the font-locking wasn’t revolutionary. It ended up just writing a regex, some faces, andcalling font-lock-add-keywords. But I’ve barely messed withfont-lock or face definitions myself before and I didn’t know any of the relevant functions off the top of my head. Icould have figured it out, but it wouldn’t have been worth my time. The LLM shaved most of the yak for me.

So next time you’re annoyed by a missing motion command, or ugly output, or you wish you had a command that worked justa bit differently, ask Claude/Gemini/your favorite LLM to fix it for you. Not only will you fix your problem, but ifyou take just a bit of time to review the output (and you’re not gonna just blindly throw LLM code in your .emacs right?RIGHT?), you may learn about a subsystem you didn’t know before. I’m sure you can do this with Neovim or, to a lesserextent, VSCode or other editors that have reasonable extension points, so go fix them too. Your yaks will thank you come summer.

Moving My Pi to an SSD

Tue, 20 Jan 2026 00:00:00 +0000

TL;DR

After setting a project aside for 5 years, I got my RPi4 booting from an SSD and running a 64bit OS by tweakingthe USB_MSD_STARTUP_DELAY bootloader config parameter.

I run Home Assistant on a Raspberry Pi 4, using Docker Compose on Raspbian. This has worked great for me for years, andoverall been very stable, but there’s been a Sword of Damocles hanging over the project: it was all running off the SDcard. Eventually the SD Card would accumulate too many writes and fail. I had all the logging set upto use log2ram to minimize wear-and-tear, but this was a band-aid.

In 2020 the RPi got a firmware update that allowed booting from USB insteadof the SD card, which allows using an SSD with an external enclosure. In 2021 I gave a shot to moving to SSD; therewere a number of guides available on how to do this, so I bought:

A 128G SATA m.2 drive (why not NVMe? Price and it’s going over USB3 anyway)
A USB M.2 SATA enclosure off this list of working hardware
A powered USB3 hub
(later, after I had trouble) A different USB M.2 SATA enclosure off that list

And I gave a shot to copying the current SD card onto the SSD and booting up the Pi.

It didn’t work

I tried this a number of times and different ways. The SD card copied fine and if I hot-plugged the drive into therunning Pi, I was able to mount it and browse the files. I triple checked the boot order, but if I leftthe SD card in the Pi it would boot off the SD card, and if I removed the SD card and let ittry to boot…nothing.

At the time, I decided everything was working good ’nuf and I’d just restore from backup if the SD card crapped out. I put thedrive and enclosure up on the Shelf of Despair with other half-finished projects.

Whoops, I need 64 bits

So, as with many homelab projects that Just Work…I let it keep on just working and left it alone. In 2025, though,Home Assistantannouncedthat it was dropping support for 32-bit OSes, which meant if I wanted to continue getting updates for Home Assistant I’dneed to reinstall my OS. This seemed like a good time to go ahead and move to an SSD.

I started by using RPi Imager to install Raspbian 64-bit to the same SSD with the same enclosure I was using before. Itried to boot off this perfectly clean install…and it still didn’t work. Same problems as before. After diggingaround online some more, I found that there’s a relatively common problem: the SSD enclosure doesn’t power up andcome online as quickly as the bootloader is expecting, and the RPi gives up looking for a USB drive. There’s a settingthat can fix this

USB_MSD_STARTUP_DELAY
If defined, delays USB enumeration for the given timeout after the USB host controller has initialised. If a USB harddisk drive takes a long time to initialise and triggers USB timeouts then this delay can be used to give the driveradditional time to initialise. It may also be necessary to increase the overall USB timeout(USB_MSD_DISCOVER_TIMEOUT).

To see the current settings, you can run rpi-eeprom-config. I ran sudo rpi-eeprom-config --edit to update thesetting according to whatever forum post I finally landed on (followed by a reboot to install the updated firmwareconfig) and it now looks like this:

[all]BOOT_UART=0WAKE_ON_GPIO=1POWER_OFF_ON_HALT=0[all]BOOT_ORDER=0xf41USB_MSD_STARTUP_DELAY=20000USB_MSD_BOOT_MAX_RETRIES=5

The BOOT_ORDER is specified here,and the default 0xf41 means “Try SD first, followed by USB-MSD then repeat (default if BOOT_ORDER is empty)”. TheUSB_MSD_STARTUP_DELAY is the value I upped to 20s, and it, along with the max_retries, seems to have solved the problem forme. I didn’t experiment further to see if a lower value would work, but it’s definitely somewhere between 5s and 20sfor my combination of hardware.

I copied over the docker directory (which contained the MariaDB files and all my configs) from my backup to the newdrive, as well as a few other services, and now everything’s running happily again.

Git One Liners: Bulk-Amending a Branch

Fri, 25 Apr 2025 00:00:00 +0000

I made a mistake with my git config recently (I’ve updated Separating work and personal config to avoid thatmistake 😬), and ended up creating all the commits in a branch with the wrong email address. The also should have beensigned and they weren’t.

Here’s how to fix that in one go:

git rebase \--exec 'git commit --amend --no-edit -n --gpg-sign --author="Evan Moses <the.correct@email.address>"' \$(git merge-base origin/main HEAD)

Breaking it down

git rebase # Rebase some commits

--exec # And execute the following command for each commit

git commit --amend --no-edit -n # Amend the commit without changing the commit message,                                # contents, or running any git hooks

--gpg-sign --author="..."` # This is the bit I actually wanted to do differently

$(git merge-base origin/main HEAD) # This is a useful command to find the "branch point"                                   # where your current branch diverges from main.

So: this will iterate over all the commits on my current branch and amend them. Done.

Separating work and personal config

Mon, 21 Apr 2025 00:00:00 +0000

TL;DR

My dotfiles are checked into a git repo
I want to avoid checking in sensitive, work-specific config to a public git repo
I updated my git and emacs configs to check for local overrides in ~/.local

Like many folks, I check my dotfiles into a git repo to share them across multiple machines. When I set up a newmachine I can simply clone that repo, run an install script that adds some symlinks, and get to work with my happypersonalized config.

My work machine needs to have some special configuration. I’m required to use certain security tools, there are somedev tools I only use at work, plus obviously I need to use my work GitHub account. The security team at my company has(wisely) asked me to keep the work-specific configuration out of my public GitHub, in order to prevent attackers fromperforming reconnaissance on our internal tooling and network configuration. Here’s how I managed that.

Git config

Our internal git setup uses a credential helper, a tool I’ve written about at Building a custom Emacs auth-source. In order to use it, we need this in our gitconfig:

...[core]sshCommand = /usr/local/bin/awesome-security-tool ssh...[credential]helper = /usr/local/bin/awesome-security-tool helper

I added this line near the bottom of my dotfiles/git.config (which issymlinked to ~/.gitconfig). Git applies configuration in order from top to bottom, with later values overwritingearlier values, so if this were at the top, it would be overwritten by the “global” configs from your base dotfiles.

[include]    path = ~/.local/git.config

Then I moved the work-specific config to ~/.local/git.config. Git is happy to silently ignore the include ifthere’s nothing at that path, so I can safely sync this config down to any machine even if it doesn’t need any localconfiguration.

Per-repo overrides

On the other hand, when I’m working on non-work repos on my work machine, I want to use my personal configurationinstead. I also want to make sure I’m not using the fancy credential helper,because the credentials it gets won’t work with my personal account.

I recently learned you can match on the git remote URL in includeIf rather than the local directory name, so I mayupdate my includeIfs.

This can be configured on a per-repo basis in the.git/config for each repo (or by using git config without the --global flag), but git has a neat feature that willconditionally include a config file based on the path to the repo. I check out my personal repos to a particulardirectory, so I at this config at the bottom of my gitconfig¹, after the include from earlier:

[includeIf "gitdir:~/dev/github.com/emoses/"]   path = ~/.gitconfig.personal

Where .gitconfig.personal looks like

[user]        email = webmaster@emoses.org[core]        # Override the ssh command from the work-specific config back to standard        sshCommand = /usr/bin/ssh

Emacs configs

My emacs also has some work-specific customizations, which I keep in a file called work.el that used to be checked into my dotfiles repo. My routine for loading all my customizations in my .emacs looks like this (if you’re reallycurious you can find the rest here) :

(defvar my:osx (eq system-type 'darwin))(my:load-config-file '("package-bootstrap.el"       (lambda () (if my:osx "osx.el" nil))               "evil.el"                ;; A bunch more files                "work.el" ;; Whoops, this was checked in, let's fix that                ))

I added a routine to load any configs from ~/.local/emacs if they’re present.

(defconst my:LOCAL_CONFIG_PATH (file-name-concat (getenv "HOME") ".local" "emacs"))(when (file-exists-p my:LOCAL_CONFIG_PATH)    (let ((local-el-files (directory-files my:LOCAL_CONFIG_PATH t "\.elc?$")))      (dolist (local-el local-el-files)        (load local-el)        (message "Loaded local config file: %s" local-el))))

So I moved my work.el out of my dotfiles repo to ~/.local/emacs/work.el and now I’m all set.

When you use include or includeIf, git treats it as if the contents of the included file were at the pointwhere your include directive is. Since later configs override earlier configs with the same name, if you wantper-repo overrides you’ll need them to be at the bottom or they’ll simply be overwritten by the “default” configs.More info in the Git docs ↩︎

A Go Puzzle: How can this panic?

Fri, 21 Mar 2025 00:00:00 +0000

Here’s a puzzle for Go developers. How can the following code possibly panic with a nil pointer dereference?

var someThing *SomeStruct// various things happen, including possibly assigning to someThingif someThing != nil && someThing.Body != nil {    fmt.Printf("%s", someThing.Body)}

Think about it for a minute. I’ll wait.

OK are you done? I don’t want to spoil it for you.

The Answer

Here’s the definition of SomeStruct,

type SomeStruct struct {    *http.Response    OtherField string}

Now we can see the problem: we checked if someThing was nil but we implicitly referenced a field on the embeddedhttp.Response without checking if Response was nil. If Response is nil is the code will panic.

Think really hard before you embed a pointer

I came across this struct in a API client library that I won’t name. I think it was probably a bad design idea. Thestruct represented the response from that API. So it looked something like this:

type APIResponse struct {    *http.Response    // non-exported fields}func (*APIResponse) NextPage() (*APIResponse, error) {...}func (*APIResponse) HasNextPage() bool {...}

So: it wraps the actual API response, plus some extra methods for dealing with pagination. I can see whythe author thought embedding the response was a good idea: it lets the consumer treat it like a normal http responsewith some extra features.

However, it becomes a problem when you can get a non-nil APIResponse with a nil Response. If you’re going to embed apointer in a Go struct, you should do you best to make sure you never leave that pointer nil.

All in all I think this API would have been better served by just making the http response a normal struct field, andpossibly copying important fields like Status into the struct¹:

type APIResponse struct {    Response *http.Response    // And if it's really important to you that people type APIResponse.Status    // instead of APIResponse.Response.Status:    Status int    // non-exported fields}

Of course, if the response is nil, I suppose you leave Status as the zero value and let consumers figure outwhat to do with http response code 0. ↩︎

Home Assistant: using target in blueprints

Fri, 03 May 2024 00:00:00 +0000

TL;DR

Here’s a snippet for use in Home Assistant for turning an arbitrary target selector into a list of entity ids
Also here’s a low-battery warning Blueprint that uses it.

I’ve been using tykeal’s Low Batteryblueprint(github) in my Home Assistant setup forsome time, to give me an alert on any sensor batteries that need changing. There are a number of sensors marked“battery” that I don’t care to track (for example iPhone batteries), and the blueprint has a spot where you can listentities you want to exclude.

With the very exciting introduction of Labels in HA2024.4, I decidedthat, instead of listing excluded entities in the automation, I’d just tag them with a NoBatteryWarning label, and thenchoose the label in the Blueprint input. But it turns out that didn’t work: the blueprint specified you had to listentities directly. I set out to fix it and it turned out it was pretty easy.

Why doesn’t it work?

Here’s an excerpt of the original blueprint:

blueprint:  input:    exclude:      name: Excluded Sensors      description: Battery sensors (e.g. smartphone) to exclude from detection.        Only entities are supported, devices must be expanded!      default: { entity_id: [] }      selector:        target:          entity:            device_class: battery# ...   sensors: >-    {%- set result = namespace(sensors=[]) -%}    {%- for state in states.sensor | selectattr('attributes.device_class', '==', 'battery') -%}      {%- if 0 <= state.state | int(-1) < threshold | int and not state.entity_id in exclude.entity_id -%}

A selector is a thing which shows up in the UI and lets you pick from a filtered list. The target selector is thecontrol you’re used to seeing all over HA Settings pages, that looks like this:

It turns out when it’s evaluated and you consume it a as a variable, you get a map that looks like this (I wish this were in the doc but I can’t find it):

{    entity_id: [],    device_id: [],    area_id: [],    label_id: [],}

The original blueprint was only iterating over the entity_id list, so it was ignoring any other selections that youmade.

The fix: just get all the entity ids

But this isn’t really hard to fix. There are a set of functions that will give you all the entities in a label, area,or device, called unsurprisingly label_entities, area_entities and device_entities. I based the code on Thisforumpost:

  exclude: !input "exclude"  exclude_entities: >    {%- set ns = namespace(ret=[]) %}    {%- for key in ['device', 'area', 'entity', 'label'] %}      {%- set items = exclude.get(key ~ '_id', [])  %}      {%- if items %}        {%- set items = [ items ] if items is string else items %}        {%- set items = items if key == 'entity' else items | map(key ~ '_entities') | sum(start=[]) %}        {%- set ns.ret = ns.ret + [ items ] %}      {%- endif %}    {%- endfor %}    {{ ns.ret | sum(start=[]) }}    # The same snippet from above but now it refers to exclude_entities instead of exclude.entity_id  sensors: >-    {%- set result = namespace(sensors=[]) -%}    {%- for state in states.sensor | selectattr('attributes.device_class', '==', 'battery') -%}      {%- if 0 <= state.state | int(-1) < threshold | int and not state.entity_id in exclude_entities -%}

So for each of the selector types (device, area, entity, and label), we expand them into entity ids and collect theminto a list, then we have a list of all the entities.

I forked tykeal’s blueprint to my own repo, you can use it by clicking this badge:

Go Generics: Use Structs for Generic Arguments Lists

Tue, 30 Apr 2024 00:00:00 +0000

TL;DR

I wanted to build reusable code for a pattern in Go
I had to fight the type system a bit but I won in the end
We can pack argument lists into structs to make the pattern generic over different sets of arguments to functions
Skip to the end of the post for spoilers

I have a preference for functional-style programming. I tend to model algorithms in my head as data and transforms ofthat data (versus, say, objects with behaviors). When I see a pattern repeat itself in my code my first instinct is toreach for a higher-order function to abstract that pattern.

However, my day job is coding in Go. I have mixed feelings about the language and I’m not gonna start a Go flame warhere, but I don’t think it’s controversial to say that Go does not lend itself to functional patterns.

The pattern

I implemented a new, faster algorithm with to make some security calculations for our system; the details areunimportant, but if the result differed between the old code and my new algorithm, it would represent a serious problemfor our customers. To make sure my new algorithm worked correctly, my plan was to calculate it the new way and theold way, compare the two values, and return the old value, logging an error if there were differences. I added twofeature flags: UseNewAlgorithmDark enabled the new calculation with comparison and logging, and UseNewAlgorithmOnlystopped using the old calculation and just returned the result of the new one.

There are actually a few different places in the code that would be using the new code, and they did differentcalculations with it. So I now had multiple places in code that looked something like this:

func (c *Controller) GetImportantData(    ctx context.Context,    tenant *models.Tenant,    userId string,    filter *ImportantDataFilter,) (*ImportantData, error) {    useNewWay := c.HasFeature(ctx, tenant, features.UseNewAlgorithmDark)    if useNewWay {        newWayLaunched := c.HasFeature(ctx, tenant, features.UseNewAlgorithmOnly)        newWayResult, err := c.getImportantDataNewWay(ctx, tenant, userId, filter)        if err != nil {            c.Log().Error("Error getting important data new way, falling back")            return c.getImportantDataOldWay(ctx, tenant, userId, filter)        }        // If the Launched flag is on, just return the new result        if newWayLaunched {            return newWayResult, nil        }        // otherwise get the result the old way...        oldWayResult, err := c.getImportantDataOldWay(ctx, tenant, userId, filter)        if err != nil {            return nil, err        }        // ...and compare it against the result from the new way.        if !dataIsEqual(newWayResult, oldWayResult) {            // If there's a mismatch, log the error, but continue            c.Log().Error("Mismatch between old way and new way for ImportantData",                zap.String("userId", user_id),                zap.Any("filter", filter),            )        }        // and always return the old result.        return oldWayResult, nil    }    return c.getImportantDataOldWay(ctx, tenant, userId, filter)}

Importantly, not all the controller functions that used the launch feature took the same sort of arguments. There wasanother that was almost identical, but the signature looked like this:

func (c *Controller) GetDifferentData(ctx context.Context, tenant *models.Tenant,    relatedThingId string) (*DifferentData, error) { ... }

The abstraction

Beyond wanting to keep my code DRY, I wanted to codify the Dark Launch pattern so other folks on our team could reuse it.So I started with something like this:

type DarkLaunch[T any] struct {    OperationName string    DarkFlag features.FeatureFlag    LaunchFlag features.FeatureFlag    NewWay func(context.Context, *models.Tenant) (T, error)    OldWay func(context.Context, *models.Tenant) (T, error)    Cmp func(T, T) bool    Logger *zap.Logger    //features.FeatureManager is an existing interface that has HasFeature    FeatureManager features.FeatureManager}func (dl DarkLaunch[T]) Execute(ctx context.Context, tenant *models.Tenant) (T, error) {    useNewWay := dl.FeatureManager.HasFeature(ctx, tenant, dl.DarkFlag)    if useNewWay {        newWayLaunched := dl.FeatureManager.HasFeature(ctx, tenant, dl.LaunchFlag)        newWayResult, err := dl.NewWay(ctx, tenant)        if err != nil {            dl.Logger.Error(fmt.Sprintf("Error getting data new way for %s, falling back", dl.OperationName))            return dl.OldWay(ctx, tenant)        }        if newWayLaunched {            return newWayResult, nil        }        oldWayResult, err := dl.OldWay(ctx, tenant)        if err != nil {            var zero T            return zero, err        }        if !dl.Cmp(newWayResult, oldWayResult) {            dl.Logger.Error(fmt.Sprintf("Mismatch between old way and new way for %s", dl.OperationName))                // Hmmm, I'm missing context data here for logging here, aren't I 🤔            )        }        return oldWayResult, nil    }    return c.OldWay(ctx, tenant)}

And it could be consumed like so:

func (c *Controller) GetImportantData(    ctx context.Context,    tenant *models.Tenant,    userId string,    filter *ImportantDataFilter,) (*ImportantData, error) {    dl := DarkLaunch[*ImportantData]{        OperationName: "GetImportantData",        DarkFlag: features.UseNewAlgorithmDark        LaunchFlag: features.UseNewAlgorithmOnly        NewWay: func(ctx context.Context, tenant *models.Tenant) (*ImportantData, error) {            // close over extra arguments here            return c.getImportantDataNewWay(ctx, tenant, userId, filter)        }        OldWay: func(ctx context.Context, tenant *models.Tenant) (*ImportantData, error) {            // close over extra arguments here            return c.getImportantDataOldWay(ctx, tenant, userId, filter)        },        Cmp: dataIsEqual,        Logger: c.Log(),        FeatureManager: c.FeatureManager    }    return dl.Execute(ctx, tenant)}

This worked, but it was inelegant. For one thing, the only way to consume it is to make a fresh closureover the arguments each time you want to call it, which means you can’t just define a DarkLaunch somewhere andreference it. You also need to pass in related machinery (the logger and the feature manager). Finally, the genericExecute method doesn’t have access to the arguments of the NewWay/OldWay functions, so it can’t log them if thereare errors; we’d probably have to insert extra logging in the closures to log properly.

Go issues, and other languages’ solutions

The problem is that DarkLaunch isn’t generic over the arguments of the NewWay/OldWay functions. In more dynamic languages,you’d be able to just apply a function to an arbitrary set of arguments, for instance in Clojure:

(defn dark-launch [{:keys [get-feature dark-flag launch-flag old-way new-way cmp]}                    tenant & args]  (if-not (get-feature dark-flag)    (apply old-way tenant args) ;; This is the secret sauce    (let [launched (get-feature launch-flag)          new-way-result (apply new-way tenant args)] ;; Here it is again      (if launched        new-way-result        (let [old-way-result (apply old-way tenant args)] ;; And here          (when-not (cmp new-way-result old-way-result)                  (errorf "Mismatch, args: %s" args)))          old-way-result)))))(def get-important-data-dl   {     :get-feature feature-getter     :dark-flag :features/use-new-algorithm-dark     :launch-flag :features/use-new-algorithm-only     :old-way get-important-data-old-way     :new-way get-important-data-new-way     :cmp data-matches   });; It's tempting to fancier with macros and have something like defdarklaunch;; but this is a simple port of the Go code and macros would be overcomplicated here anyway.(defn get-important-data [tenant userId filter]   (dark-launch get-important-data-dl tenant userId filter))

A language with a sophisticated type system can express the same idea but with strong typing. I’m sure it can be donein Haskell ¹, but I know enough TypeScript better, so taking advantage of variadic tupletypes:

interface DarkLaunch<T, A extends any[]> {  getFeature: (f: Feature) => boolean;  darkFeature: Feature;  launchFeature: Feature;  oldWay: (ctx: Context, tenant: Tenant, ...args: [...A]) => T | undefined;  newWay: (ctx: Context, tenant: Tenant, ...args: [...A]) => T | undefined;  cmp: (a: T, b: T) => boolean;}

The TypeScript compiler will enforce that oldWay and newWay have the same number and type of arguments, which iswhat we want. And that gives us a clue to how we can solve this in Go.

A Go Solution

We don’t have a anything like Variadic Tuple Types ² in Go, but we can express the idea of a set of typesbundled together: it’s a simple struct. This requires re-writing the oldWay/newWay functions slightly to take theirarguments as a limited-use struct, but that’s not really a big deal.

The other improvement I made was to bundle the “auxiliary” members of the struct like the logger and the FeatureManagerthat are only used to actually execute the code into an Executor interface. Controller already satisfiedExecutor, so now we could bundle the whole thing into its own package. Here’s the final code:

package dark_launchtype Executor interface {Log() *zap.LoggerFeatures() features.FeatureManager}type DarkLaunch[T any, A any] struct {OperationName stringDarkFlag      features.FeatureFlagLaunchFlag    features.FeatureFlagNewWay        func(context.Context, *models.Tenant, A) (T, error)OldWay        func(context.Context, *models.Tenant, A) (T, error)Cmp           func(T, T) bool}func (dl DarkLaunch[T, A]) Execute(    ctx context.Context,    x Executor,    tenant *models.Tenant,    args A,) (T, error) {    useNewWay := x.Features().HasFeature(ctx, tenant, dl.DarkFlag)    if useNewWay {        newWayLaunched := x.Features().HasFeature(ctx, tenant, dl.LaunchFlag)        newWayResult, err := dl.NewWay(ctx, tenant, args)        if err != nil {            x.Log().Error(fmt.Sprintf("Error getting data new way for %s, falling back", dl.OperationName))            return dl.OldWay(ctx, tenant, args)        }        if newWayLaunched {            return newWayResult, nil        }        oldWayResult, err := dl.OldWay(ctx, tenant, args)        if err != nil {            var zero T            return zero, err        }        if !dl.Cmp(newWayResult, oldWayResult) {            x.Log().Error(fmt.Sprintf("Mismatch between old way and new way for ImportantData"                zap.String("tenantId", tenant.Id),                zap.Any("args", args),            )        }        return oldWayResult, nil    }    return dl.oldWay(ctx, tenant, args)}// ----- elsewhere -----type importantDataArgs struct {    userId string    filter *ImportantDataFilter}func (c *Controller) GetImportantData(    ctx context.Context,    tenant *models.Tenant,    userId string,    filter *ImportantDataFilter,) (*ImportantData, error) {    // This could be defined outside this function without much extra work, but it would    // only be a teensy efficiency gain and wouldn't add much readability.  I'd do it if    // the same args struct and getImporatantData* were re-used in a few different places.    dl := DarkLaunch[*ImportantData, importantDataArgs]{        OperationName: "GetImportantData",        DarkFlag: features.UseNewAlgorithmDark,        LaunchFlag: features.UseNewAlgorithmOnly,        NewWay: c.getImportantDataNewWay,        OldWay: c.getImportantDataOldWay,        Cmp: dataIsEqual,    }    return dl.Execute(ctx, c, tenant, importantDataArgs{userId: userId, filter: filter})}// getImporantDataNewWay and getImportantDataOldWay must be re-written to take in the args structfunc (c *Controller) getImportantDataNewWay(    ctx context.Context,    tenant *models.Tenant,    args importantDataArgs,) (*ImportantData, error) { ... }// GetDifferentData works the same, but since it only takes a single argument beyond the common args,// we don't even need a limited-use structfunc (c *Controller) GetDifferentData(ctx context.Context, tenant *models.Tenant,    relatedThingId string) (*DifferentData, error) {    dl := DarkLaunch[*DifferentData, string]{        OperationName: "GetDifferentData",        DarkFlag: features.UseNewAlgorithmDark,        LaunchFlag: features.UseNewAlgorithmOnly,        NewWay: c.getDifferentDataNewWay,        OldWay: c.getDifferentDataOldWay,        Cmp: dataIsEqual,    }    return dl.Execute(ctx, c, tenant, relatedThingId)}

Much prettier, huh? Go’s type system isn’t powerful enough to have a type argument that expresses an arbitrary-lengthbut finite list of types as parameters to a function; however we can use a product type (aka a struct) to representthe finite list ³.

Discussion

I’m not a Haskeller, suggestions welcome. Contact info in sidebar. ↩︎
That’s fun to say ↩︎
My category theory knowledge comes almost exclusively from reading intro-to-Haskell blog posts linked from theorange site. Please be pedantic at me if I got my terminology wrong. ↩︎

Emacs Tidbit: rectangle-number-lines

Wed, 24 Apr 2024 00:00:00 +0000

Emacs has so many little features that do exactly what you need in very specific circumstances. Here’s one that I justfound out about: rectangle-number-lines. I had some lines and I wanted to insert line-numbers for reference. Iwanted this

arguments list: [team8721038424565681034userfdff6f87-d876-4558-8d12-19e039e5a880afoosecretalsothisbe46e2d16-b3ba-4f84-826f-5e3031465e21]

To be this

arguments list: [ 1 team8721038424565681034 2 user 3 fdff6f87-d876-4558-8d12-19e039e5a880 4 a 5 foo 6 secret 7 alsothis 8 b 9 e46e2d16-b3ba-4f84-826f-5e3031465e21]

I started thinking about kmacros, which I rarely use but have an incrementing counter you can use for this, but I startedgoogling and lo and behold I found a Stack Overflow post with the answer. Just highlight a rectangle on the firstcolumn¹ and type C-x r N which runs rectangle-number-lines, which does exactly what Iwanted.

Discussion

Since I use evil, I just type C-v to enter visual block mode, but I looked itup for vanilla Emacs and C-x SPC to set the rectangle mark. ↩︎

No I don't want 2, Emacs

Mon, 15 Apr 2024 00:00:00 +0000

This blog, and the vast majority of the code I write, is written in Emacs withevil (a vim emulation mode). I have a nasty habit of mashing :w2<ret> when I really was trying to save the current buffer with :w<ret>. :w2 writes the current buffer to a new file called 2, which I don’t believe I have ever done on purpose.

So, I added this little gem to my .emacs, and it’s saved me any number of times:

(defun my:evil-write (&rest args)  "I constantly hit :w2<ret> and save a file named 2.  Verify that I want to do that"  (if (equal "2" (nth 3 args))      (y-or-n-p "Did you really mean to save a file named 2?")    t))(advice-add #'evil-write :before-while #'my:evil-write)

The :before-while advice lets you run a function that gets the same arguments as the advised function. If it returnsa truthy value, the advised function is run as usual, but if it returns nil, the original function is never run.

Share and enjoy.

Update Apr 16, 2024

To be clear: I’m not criticizing Emacs or evil here. To the contrary, I’ve got a personal problem, and thanks to theinfinite flexibility of Emacs I was able to craft a personal solution in 6 lines. I wish the rest of my software were soflexible.

Discussion

Representing State as interfaces in Go

Tue, 26 Mar 2024 00:00:00 +0000

I made up a neat little pattern in Go the other day. It’s a way to represent a state change in a system by exposingdifferent APIs for different states, while only holding state in a single underlying struct. I’m sure I’m not the firstperson to invent this, and it may already a name, so please let me know if you know of one [Update:apg on Lobsters pointed out thename “typestate”, which I like]. I’m goingto show an instance of the pattern first and the motivation after.

The Pattern

// You start with a Resolver, and incrementally feed it data to be looked uptype Resolver interface {    // Collect collects some piece of data and maybe extra information about it that you    // need to do resolution    Collect(someId string, someData string)    // Maybe you also need some global contextual data to do the resolve    AddContextualData(data SomeContext)    // When you're done, the resolve can send the bulk query to the executor to perform    // the lookup that you want to do    Execute(context.Context, Executor) (Resolved, error)}// Resolved is what you get back after you Execute, and it lets you access the resolved datatype Resolved interface {    // Resolve returns the result. If the result doesn't have that id, either because it    // wasn't looked up successfully during execution or because you never [Collect]ed it,    // it will return ("", false)    Resolve(id string) (string, bool)}// Executor is capable of doing the db lookup/cache lookup/service request/http request// that actually gets the data you need to gettype Executor interface {    DoTheThing(        ctx context.Context,        idsToResolve map[string][]string,        contextualData SomeContext,    ) ([]ResolveResult, error)}

So far, so boring. You’ve got a Resolver that batches up query data, an Executor that, well, executes the query,and a Resolve that lets you access the result. What’s neat about this is that Resolver and Resolved can beimplemented by the same struct:

type idResolver struct {collected map[string][]stringcontextData SomeContextresolved map[string]string}func (r *idResolver) Collect(someId string, someCategory string) {r.collected[someCategory] = append(r.collected[someCategory], someId)}func (r *idResolver) AddContextualData(data SomeContext) {r.contextData = data}func (r *idResolver) Execute(ctx context.Context, executor Executor) (Resolved, error) {result, err := executor.DoTheThing(ctx, r.collected, r.contextData)if err != nil {return nil, err}r.resolved = transformResult(result)/*** * 🪄 THE MAGIC 🪄 * Ooh look I'm just returning this struct as a Resolved! */return r, nil}func (r *idResolver) Resolve(id string) (string, bool) {res, ok := r.resolved[id]return res, ok}

Ok but why?

I was building a system to bulk-lookup names in my system by ID. But if you called Resolve before it had executed,you’d have an invalid result. And if you Collected after you executed, you’d never look up the id. So I added aboolean hasExecuted to IdResolver so that if you called Resolve before you had called Execute or Collectafter, it would check that flag and panic.

func (r *StatefulIdResolver) Collect(someId string, someCategory string) {    if r.hasExecuted {        panic("Collect called after Execute")    }r.collected[someCategory] = append(r.collected[someCategory], someId)}// Execute executes and changes state but doesn't return anything newfunc (r *StatefulIdResolver) Execute(ctx context.Context, executor Executor) error {    if r.hasExecuted {        panic("Execute called twice")    }    ...    r.hasExecuted = true    ...}func (r *StatefulIdResolver) Resolve(id string) (string, bool) {    if !r.hasExecuted {        panic("Resolve called before execute")    }res, ok := r.resolved[id]return res, ok}

This is kind of a mess, harder to read and maintain, and much easier to mess up the logic in.

When to use it

Of course the Resolver and the Resolved could be represented by different structs with their own methods. But inthis case it felt like we were really working with a single object: it collects data, operates on it, and manages theresult.

The crux of the matter is that the object has different operations that are valid in different states, and Go interfacesare a perfect way to expose that.

Update: Is this just a `Builder`?

A few folks on the internet have pointed out that this is very similar to the Builder pattern that you see prettyoften in Java/C# (and to a lesser extent in Go), and especially a multiphase Step Builder.

I don’t think there’s a fundamental difference, but Builders that I’m familar with generally have a state-change/executestep (Build()) that produces an immutable object for use somewhere else, rather than doing any sort of effectfulexecution. I think this pattern is both more general (you could certainly use it as a Builder) and has a differentpurpose.

Discussion

Minimum Age Ratings

Mon, 15 Jan 2024 00:00:00 +0000

Minimum Age ratings on games and why they’re terrible

I came across this Redditcomment todayand it explains so much:

I used to work in the toy industry - there is A LOT hidden behind age ranges on a box. Those are less about what age the game is for (except for development focused games, like HABA), and more about regulations around what age can legally be printed on the box.
Examples off the top of my head:
Telestrations is rated 12+… because it comes with a dry erase marker. That’s why. It doesn’t have to do with content or complexity, but if you put a dry erase marker in the box, you’re 12+.
Does your game use standard dice? Great, you can get 8+ rating. Do you use custom or smaller dice? That’s a 12+… unless you go through the rigorous safety testing to prove it isn’t a choking hazard. King of Tokyo is 8+ because of the energy cubes.
Does your game use miniatures? What’s the smallest piece of the miniature? Do you want to pay $10k for each unique piece to test the safety of them? No? Then you’re getting the 13+ age.
If you want to hedge your bets on content, that’s also 13/14+.

Fascinating.

I often use the printed age rating as a shortcut for judging how appropriate a game will be for my kid, and justsubtract a couple years because she’s been very comfortable with games rated for a few years above her age. But now Iknow it’s even more useless than I thought.

For actually-useful age ratings, I rely on the “Community” Age rating on BGG.

For King of Tokyo, It’s “6+”, which seems about right.

BGG Admins, if you ever come across this, please please please add a feature to filter the games list by CommunityAge, and sort by rating. I would be on that page all the time.

Building a custom Emacs auth-source

Fri, 22 Dec 2023 00:00:00 +0000

My employer, has recently been making securityimprovements to how we access all sorts of internal systems. As part of thathardening, we’ve been disallowed from using SSH keys and long-lived GitHubtokens to access our code on GitHub. In place of that, we’ve now got aninternal tool that grants us short-lived tokens on demand, after SSOing.

This is a good idea even if it adds a little friction, and means that ifyou gain access to my machine somehow you won’t automatically have my privilegesto access our code base. The way it integrates with standard git tooling isinteresting and uses a git subsystem I wasn’t previously aware of: the gitcredential helper.

This mostly Just Works™, which is pretty great. My main interaction with ourrepos is via the wonderful magit package in Emacs, and although I’m one of thevery few Emacs users in our company I didn’t have to do anything special to keepworking away.

However, another tool, forge, needed more work.It’s another package by the author of magit, which lets you create and editPRs and otherwise deal with the parts of GitHub (or other forges like Gitlabetc.) that aren’t part of git proper.

So, this being Emacs, I got out my clippers and went yak shaving.

How does this tool work anyway?

I’ve had to fix a few other of our internal tools that interact with git orGitHub, so I had already figured out how our new token-granting tool works. Itturns out this is documented quite thoroughly.

When git tooling needs credentials to communicate with a remote (for example topush, pull, etc.), it checks to see if there’s a credential.helper inthe config and executes it to retrieve credentials. When you set up our newinternal tool, it adds a line in your .gitconfig:

[credential]   helper = "/home/emoses/awesome-tool --some options"

When git or any other system needs a token, it executes/home/emoses/awesome-tool --some options get, and then the helper readsoff of stdin, expecting input like this:

protocol=httpshost=github.compath=my-company/imporantrepousername=emoses

And then goes off and does its thing (including MFA), and responds with

protocol=httpshost=github.compath=my-company/importantrepousername=emosespassword=gh_shorttermtoken1

So why doesn’t ‘forge’ work?

The forge manual has a wholesection¹about setting up tokens and storing them so forge can get it back out. Ituses auth-source, an Emacs built-in package that provides an API that wrapsa bunch of different ways to store login credentials, including old-school plaintext.netrc files, GPG-encrypted authinfo.gpg files, and APIs like the Unixsecrets API or the MacOS keychain. Notably it does not use the gitcredential helper, presumably because your git credentials (e.g. an SSH key usedto push to git remotes) aren’t usually the same type of thing as the API tokenused by a forge.

I’d followed the instructions to put a long-lived GitHub token with the rightusername and host in the MacOS keychain, and forge was happily retrieving thattoken using auth-source. But now, of course, those long-lived tokens are nolonger valid.

Let’s extend auth-source

auth-source is a generic façade, meant to retrieve tokens from all sorts ofdifferent auth backends. So how about we just write a new backend?Since communicating with the git credential helper is pretty straightforward, how hardcould that be?

Kinda hard, actually

Turns out auth-source has basically no developer documentation for writing a newbackend. But this is Emacs! Let’s dig in!

How does it work with the keychain?

I’d messed with auth-source before² and knew that you could retrieve asecret by calling (auth-source-search :user USERNAME :host HOST). The sourcesthat it uses are defined by a list called, unsurprisingly, auth-sources, whichlooks like (macos-keychain-generic macos-keychain-internet "~/.authinfo.gpg" "~/.authinfo" "~/.netrc"). So I took a look at C-h vauth-source and followed it to thesource.This lays out all the options for auth sources, but didn’t tell me what I wantedto know, so I browsed through the file some more looking for macos-keychain,and landed on auth-source-macos-keychain-search. This is the actual functionthat does the searching, but where’s it referenced? Searching for it in thefile we find thisfunction:

(defun auth-source-backends-parser-macos-keychain (entry)  ;; take macos-keychain-{internet,generic}:XYZ and use it as macOS  ;; Keychain "XYZ" matching any user, host, and protocol  ;; yadda yadda yadda, check the name of the entry [yaddas mine]      (auth-source-backend       (format "Mac OS Keychain (%s)" source)       :source source       :type keychain-type       :search-function #'auth-source-macos-keychain-search       :create-function #'auth-source-macos-keychain-create)))))(add-hook 'auth-source-backend-parser-functions #'auth-source-backends-parser-macos-keychain)

This is promising! It looks like there’s a list of parser functions that look atan entry in auth-sources and return an auth-source-backend if the entry isa string or symbol that that parser knows how to provide. For themacos-keychain, the backend has a :search-function that calls the keychainAPI. Let’s copy-paste some code and see where it gets us.

   (defun auth-source-git-credential-helper-search (&rest TODO)      "TODO"      )  (defun auth-source-backend-git-credential-helper (entry)    (when (and (stringp entry) (string-match "^git-credential-helper" entry))      (auth-source-backend       :source  "git-credential-helper"       :type 'git-credential       :search-function #'auth-source-git-credential-helper-search)))  (add-hook 'auth-source-backend-parser-functions #'auth-source-backend-git-credential-helper)

So what does auth-source-git-credentials-search need to do? It takes in a spec, which is the plist that auth-source-search takes, and returns a plist that looks like (:user USERNAME :host HOSTNAME :type 'git-credentials :secret SECRET), where SECRET is either the secret itself or a function that evaluates to the secret.

With a bit more copy-paste we have something like this:

(cl-defun auth-source-git-credential-helper-search (&rest spec                                                            &key create delete type                                                            &allow-other-keys)    (cl-assert (not create) nil "git-credential-helper doesn't support create")    (cl-assert (not delete) nil "git-credential-helper doesn't support delete")    (when (string-equal (plist-get spec :host) "api.github.com")      ;; forge appends "^forge" to the username, so get just the part before the ^      (let ((user (car (string-split (plist-get spec :user) "\\^")))            ;; Get the git credential helper from the config            (helper (ignore-errors (car (process-lines "git" "config" "credential.helper")))))        (when (and user helper)          ;; call the helper and parse its output          ))))

Let’s get parsing

We have to actually run the credential helper and get the secret back from it.Dealing with processes and pipes in Emacs was new to me. I had usedprocess-lines to run a process and get its output back, but process-linescan’t pipe data to the process’ stdin. The basic idea is that everything in Emacs is abuffer, and you use normal text-editing and buffer-navigation functions to dealwith it: you put the data you want to send in a string or a buffer, send it tothe process, and then the output of the process is written back to the buffer.

So, I’m gonna need a new buffer to collect the output, I’ll need to call thehelper function with the right args, and then process the output. We’ll usecall-prcoess-region,which can take a string as input:

(cl-defun auth-source-git-credential-helper-search (&rest spec                                                            &key create delete type                                                            &allow-other-keys)    (cl-assert (not create) nil "git-credential-helper doesn't support create")    (cl-assert (not delete) nil "git-credential-helper doesn't support delete")    (when (string-equal (plist-get spec :host) "api.github.com")      (let ((user (car (string-split (plist-get spec :user) "\\^")))            (helper (ignore-errors (car (process-lines "git" "config" "credential.helper")))))        (when (and user helper)          (let (;; The command and args need to be in a list, and we need to add                ;; the argument "get" to the end of the list                (helper-and-args (append (string-split helper " ") (list "get")))                ;; Create a temp buffer to process the output                (out-buf (generate-new-buffer "output")))            ;; unwind-protect works like a try/finally, allowing us to clean up            ;; the temp buffer if there's an error.            (unwind-protect                (progn                  ;; the first two args are the beginning and end point of a                  ;; region to send, or a string and nil to send a string, which                  ;; is what we'll do.                  (apply #'call-process-region                    (format "username=%s\nprotocol=https\nhost=github.com\n\n" user)                    nil                    (car helper-and-args)  ;; program name                    nil                    ;; DELETE, we'll ignore                    out-buf                ;; Destination buffer                    nil                    ;; DISPLAY, we'll ignore                    (cdr helper-and-args)) ;; The rest of the args                  (with-current-buffer out-buf                    ;; process the output                    (let ((processed (auth-source-git-credential-helper--process-output)))                      ;; If we've got a secret from the output, return it along                      ;; with a :type property we got from the input spec                      (and (plist-get processed :secret) (list (plist-put processed :type type))))))              (kill-buffer out-buf)))))))

And then there’s the function to process the output and return it as the plistthat auth-source expects. A couple interesting things here: we’ll take a pagefrom the keychain code and return a function that returns the secret, ratherthan the secret as a string. This defends against an attacker that might be ableto access memory from another program or a core dump, although I’m not convincedthis is actually a useful layer of hardening, since the “decryption key” is alsoin memory. Also: we have to concatenate the host and protocol from the outputinto the :host value in the result, so there’s a little extra work there. Forthe actual parsing, we use looking-at, which tests the text at the pointagainst a regexp (setting the match as other Emacs regexp functions do, seeThe MatchDatafor more information), and a small helper function to build up the result plist.

(defun auth-source-git-credential-helper--append (result key &optional filter)    "Append the value between match-end and the end of the line toplist RESULT with KEY.  If FILTER is present, call it with thematch data and any existing result at that key, and put its valueat KEY."    (let* ((data (buffer-substring-no-properties (match-end 0) (line-end-position)))           (data (if (functionp filter) (funcall filter data (plist-get result key)) data)))      (plist-put result key data)))(defun auth-source-git-credential-helper--process-output ()    (let ((ret '()))      ;; Start at the beginning      (goto-char (point-min))      ;;Loop until we're at the end      (while (not (eobp))        (cond         ;; We found password         ((looking-at "^password=")          (setq ret (auth-source-git-credential-helper--append                     ret :secret                     ;; Note: for this to work lexical-binding must be t                     (lambda (data &rest _)                       (let ((v (auth-source--obfuscate data)))                         (lambda () (auth-source--deobfuscate v)))))))         ((looking-at "^username=")          (setq ret (auth-source-git-credential-helper--append                     ret :user)))         ((looking-at "^host=")          (setq ret (auth-source-git-credential-helper--append                     ret :host                     ;; If we've already got protocol, append host                     (lambda (data &optional existing) (concat existing data)))))         ((looking-at "^protocol=")          (setq ret (auth-source-git-credential-helper--append                     ret :host                     ;; If we've already got host, prepend protocol with ://                     (lambda (data &optional existing) (concat data "://" existing))))))        (forward-line))      ret))

Let’s test it. We can make a buffer with the expected output, C-xC-b test RET:

username=evanmosesprotocol=httpshost=testthis.compassword=verysecret

We can run our function with eval-expression, M-:(auth-source-git-credential-helper--process-output) RET, and weshould see the result: (:user "evanmoses" :host "https://testthis.com" :secret (lambda nil (auth-source--deobfuscate v))). We can see if we can get oursecret back out by doing M-: (funcall (plist-get(auth-source-git-credential-helper--process-output) :secret))(that is, get the value of :secret from the plist and call it as a function),and we should see the result is “verysecret”. It worked!

Wrapping it up

All we have to do is to add our new auth source as a place to look for auth data

  (add-to-list 'auth-sources "git-credential-helper")

And now forge is happily retreiving tokens from our internal tool, and I’m back to writing my PR descriptions in Emacs. Yak shaved!

You can see the full code in my dotfilesrepo.I may try to turn this into a MELPA package, but I think it would have to begeneralized a bit, and I’ve also never built a MELPA package before, so that’s awhole ’nother yak.

This is a link to the ghub documentation, a related package, which is referencedby the forge documentation. ↩︎
Getting forge to work the first time, actually. ↩︎

Betrayal at House on the Hill - very thematic fun

Mon, 11 Nov 2013 00:00:00 +0000

I watched Tabletop’s playthrough, and decided to pick it up at my local FLGS, Gamescape. I don’t have many of this sort of heavily-thematic, strategy-light game in my collection, and it’s good to mix it up a bit. Turns out it was a good decision. Sus, A.C., and I had a ton of fun, ended up playing two games in a row, and I’m looking forward to playing another haunt sometime soon.

Description

In BaHotH, you each play one of a party of standard horror-movie archetypes: the Jock, the Professor, the Creepy Little Girl, the Prissy Teenager, etc. Each character has a name and a back-story for color, alhtough those don’t have much direct impact on the game. Your party starts out at the entrance of a creepy old house, and begins exploring.

The fun comes from the exploring mechanic. There’s no set board: instead, each room is a tile. The House on the Hill has three stories, and rooms are either on the Upper Floor, Ground Floor, or Basement. Every time one of your intrepid explorers steps through an unopened door, you pick a tile that’s appropriate for you floor off of the stack and place that tile onto the board. You might stumble into the Bloody Room, or the Creaky Hallway, or the Crypt.

Most rooms have an icon on them that indicates they contain an Event, an Item or an Omen. Items are generally beneficial, and help you on your way (weapons, armor, healing stuff, etc.). Events are mixed, and many of them require you to roll dice based on your stats. If you roll well, you can gain stats or powers, and if you roll poorly, you take damage or something else bad happens to you. Sometimes you might fall through a hole into the Basement, or discover a Secret Staircase that connects two rooms. The text on the cards is clever and thematic, and reading them aloud in a spooky voice definitely adds to the game. Omens I’ll get to in a bit.

Some rooms have special effects. As soon as you step into the Coal Chute, which can only appear on the upper or ground floors, you fall through it to the basement landing. You can’t immediately go back up to the rest of the house from the basement, you must explore the basement to find the Stairs to the Basement room. Other rooms do you damage unless you roll to avoid it (the Crypt hurts your Sanity) or give you a boost (the Library gives you one knowledge).

So, I mentioned Omens earlier. There are 13 Omens, which often are very helpful items (a Spear, “pulsing with power”, that gives you a significant attack bonus) or Companions (a Dog follows you around and gives you a stat boost, a Madman hangs around you and helps your Might [strength] but hurts your Sanity). Each time you acquire an Omen, you must make a Haunt roll. If your roll ends up less than the number of Omens that has already been found by the explorers, the Haunt begins.

The Haunt

The Haunt is what makes this game really fun and replayable. Once the Haunt begins, one of your characters snaps and starts working with the evil in the house to kill/maim/eat/sacrifice/etc. the rest of the party. Exactly which character snaps is random, and determined by which Omen was found and which room it was found in. There are 50 different Haunt scenarios that might take place, and each one specifies which character becomes the traitor, sometimes by character name, or sometimes by stat (the highest knowledge, the lowest sanity, etc). Some scenarios even have a hidden traitor, at which point the game starts to look more like Battlestar Galactica or another hidden-traitor game.

Each scenario has its own set of rules and goals for the Traitor and the Heroes (the rest of the party), detailed in a separate book. The Traitor leaves the room and studies her rules, and the Heroes can read their rules and discuss strategy. Part of the fun of the game is discovering the different scenarios and rules, so I won’t detail what happened to us, but we played two games. They were quite different from one another, and both quite enjoyable. A.C. ended up as the Traitor both times; in the second one in particular, he had no idea what we were doing as the Heroes, or how to go about stopping it. He ended up winning anyway (killing us all was quite effective).

Conclusion

All three of us enjoyed this game, enough so that we seriously considered a 3rd playthrough, even though it was late. We all thought it would be a little more fun with a few more people (up to 6 can play), especially once the Haunt begins and it’s down to only 2 Heroes versus the Traitor in a 3-player game.

This isn’t a particularly balanced or subtle game. There’s some strategy once the Haunt begins, which will be different for each Haunt, but the fun here isn’t in the strategy, it’s in the entertaining themeing (I love the Creaky Walkway, and the Collapsing Floor that sends you down to the basement) and variation you get from each Haunt.

There are 50 different Haunts, and even an optional rule for picking a different Haunt if you’ve already play the one determined by the grid. AFAIK there aren’t any official expansions, although from poking around online, there have been a number of unofficial fan Haunts. All you really need is a page for the Traitor, a page for the Heroes, and an amendment to the grid to select new Haunts, so expansions are easy to download and play. I think the game will be fairly replayable even if you end up with the same Haunt, though; even if the Traitor knows the game already, there’s still fun to be had in directing the Monsters and chasing down the Heroes.

Highly recommended for pretty much any gaming group.

Dungeon World: My first pen-and-paper RPG

Fri, 22 Feb 2013 00:00:00 +0000

To start out, I’ve got a confession to make: I’m a pretty big nerd. I know, I know, it’s hard to believe, but it’s true. I also like games, which might be a little easier to swallow. Beyond the tabletop board and card games I’ve been writing about here, I’m also a fan of video games, and in particular adventure and RPG games. Which leads me to a more legitimately shocking confession: I have never in my life played a Dungeons and Dragons style pen-and-paper role-playing game. It’s a gap in my record, a ding on my nerd score sheet, the same way that not being able to drive stick cost me man points.¹

So, when my friend Max posted that he was planning on starting up a regular game of an RPG called Dungeon World, I jumped at the chance. Given my virgin status, all comparisons I make to D&D or other RPGs are going to be based on hearsay or analogies to video games. That said, I understand that Dungeon World is less heavily rule-, dice- and stats-based than D&D, with more time spent on collaborative storytelling and world building. Stats are relatively simple, and basically only serve to modify various dice rolls. The basics of the world and characters are very similar, with familiar fantasy races (Human, Elf, Dwarf, Halfling), and character classes (Paladin, Cleric, Warrior, Ranger, Wizard, Thief, etc.) with a few minor variations, such as a Druid that’s one with the Land and able to shapeshift into that Land’s creatures. If you want more specifics, check out their website.

We were a group of Max’s friends who knew Max but didn’t necessarily know each other, so we spent a decent amount of our first session just hanging out a bit, and another hour or so creating our characters. Character creation in Dungeon world consists of choosing a class, and then making a series of multiple-choice decisions about the character. I was a Wizard named Avon, so I had to choose whether I was Elf or Human (Human), some basic physical description (sharp eyes, smooth hair, pudgy body), Alignment (Good, Neutral, Evil, I chose Neutral), which spells and gear I start with, and assigning 6 stats to 6 slots (the wizard has 16, 15, 13, 12, 9, 8 and any number can go to any stat).

Most interestingly, each character creates Bonds with the other characters. There are some canned suggestions, although you’re free to improvise. In my case, I thought that the Bard was hiding a secret, and that the forest elf Ranger was “woefully misinformed about the world; I will teach them all I can”. When Bonds are resolved in the opinion of the players and GM, they count as XP.

Three of the party members had started an adventure previously with Max, so already had their characters together, but our party of 6 (7 if you count the Ranger’s bear companion) continued it with some handwaving about how exactly we all ended up together, some of which was filled in as backstory as we went. We introduced our characters to each other, and with fairly little ceremony, we started in on our quest, arriving a heavily fortified village on the shore of a northern sea.

I won’t give a play-by-play of our whole session, but it involved a Bad Dude named Jarl Vater with his 9 immortal warriors (or are they immortal?), some scary sounding wind elementals we haven’t actually encountered yet, and strangers suspicious of our band. I spectacularly fouled up our first interaction by throwing a bad dice roll and failing to Charm the gate guard, although it was salvaged by our very intense and earnest Paladin. Our Druid was incredibly useful, turning into various animals (a cat, a seagull, a hawk), allowing us to scout by land and air, and most importantly risking herself as a hawk to stoop down and retrieve some plans that the immortal warriors were holding. Working together, we managed to kill two of the “immortals”, who didn’t live up to their name (heh).

That was as far as we got in our first session, and it was incredibly fun. Although I can’t compare him to others, Max was clearly a skilled GM: he encouraged us to fill in our characters’ stories, to interact with the NPCs and each other, moved things along when they slowed, and took plenty of time with the more adrenaline-filled bits (fights, risky moves, etc). There are mysteries to uncover: who or what is this Jarl Vater?What’s his connection, if any, to the wind sprites? There are choices to make: help the town under attack, or skitter off while the “immortals” are busy raiding it so hopefully the Jarl will be unprotected. Hopefully there’s loot to be had. I look forward to continuing the quest.

Most of all, I really enjoyed the freedom that the format has compared to cRPGs. On a computer game, you’re limited to solutions that the programmers thought of first. I’ve got a big-ass fireball, and that rabbit holding the golden key just dove under a bush, but I can’t set the bush on fire to smoke it out. In this game, you can try anything you can think of, and it’s up to you, your party-mates, and the GM to decide what happens.

I recently leveled up in that skill. Thanks Sus! ↩︎

Power Grid: It comes down to math

Thu, 24 Jan 2013 00:00:00 +0000

Last game night we sat down for a 4-way game of Power Grid, with me, Sus, A.C., and L.S., an old friend who moved to town relatively recently. We had all played the game before (some of us more recently than others), but this was the first time we played on Italy, one of the expansion maps.

Power Grid is the epitome of the loose genre known as Eurogames. There’s very little luck involved: the only random factor is the order in which the new power plants come out, and they come out in such a way that you usually have a pretty good idea of which plants will next be available. The game is exquisitely balanced. It’s set up so that the worse you’re doing, the more of an advantage you have, so that it’s nearly impossible to run away with a game. Even if you’re pretty sure you’re losing, games usually end up being fiercely contested until the last turn. On the downside, it can often end up feeling like playing a spreadsheet. You’re always running an optimization to figure out whether to spend your money on resources, power plants, or new cities, and the addition ends up consuming a lot of your brainpower. A.C. half-facetiously suggested that we all play with pen and paper, but I actually think that’s a pretty good idea, and maybe we’ll try that next time.

Playing on the Italy map definitely made a big difference. Oil and coal, usually the cheapest and most plentiful resources, are scarcer on this map. Also, the way the cities are laid out is different from the base maps: there’s a dense region in the north with many cheap connections, and a much sparser region in the south, with only a few, very expensive connections. Of course, this meant that we all thought that starting in the north was a good idea. I went first, so I figured I would grab a spot in the center of all the cheapness, and there would be enough room for me to grow until Phase II (in Phase I, only one player can build in a city, but in Phase II, a second person can build, for increased cost). Boy, was I wrong. Unsurprisingly, everyone else wanted to build in the cheap area, too, but since I was in the center of it, I ended up completely surrounded, and the two players on the southern edge of the north, L.S. and Sus, had a decisive advantage.

While A.C. (who built in the far north) and I were trying to hoard our money to expand later, Sus and L.S. quickly had us surrounded, and managed to shoot south when they built up some reserves. Even though I got lucky and ended up with a 3 Coal -> 6 house power plant very early, which should have given me a big advantage, it wasn’t enough to overcome getting boxed in. In the end, L.S. was able to build out the game-ending 17 cities while A.C. and I were still around 13. Sus would have had a good chance, but she ended up with some bad luck in the power plant bidding, and wasn’t able to recover from an underpowered mid-game.

Overall, I love Power Grid. It’s a great mid-length game that’s fun over a wide range of number of players. It’s pretty easy to teach, as well; given the balancing mechanics, it’s forgiving to new players. Beware, though: you might have trouble if you have friends who are prone to analysis paralysis, or conversely if you get annoyed when someone stares at the board for a few minutes mumbling to themselves and counting on their fingers.

Agricola: You're always losing

Fri, 21 Dec 2012 00:00:00 +0000

Last week A.C., Sus and I got together for a game of Agricola. In Agricola, you play a peasant couple starting out in a small hut on an empty farmyard, and your goal is to grow into a prosperous family with crops, animals, and a big house. It’s a worker-placement game, where players take turns choosing which actions they’ll play on each round, and more actions become available as the game progresses. However, once an action is chosen on a round, no one else can choose that action, so players are always competing for which thing they get to do. As your family grows, each child is another worker who’s able to perform actions, but also another mouth to feed, meaning you have to spend more time gathering or preparing food.

In order to do anything that will contribute toward your final score, you’ll need lots of raw materials, and you’ll need to choose certain actions at the time when you have enough of those materials to take advantage of them. For instance, adding a family member is worth 3 points (a significant amount when final scores are usually in the 30-60 range), and also increases the number of actions you can do per round. However, in order to grow your family, you first need to make a room for them in your hut, which needs 2 different types of raw materials, a “Build a Room” action, and a “Family Growth” action. Of course, all your competitors are also looking to grow their family, and you still have to gather enough food to feed your family in the meantime. The end result is that competition is fierce, and you always feel like you’ll never have enough time to do all the things you want to do.

The variation in the game comes from the two large stacks of cards called Minor Improvements and Occupations. Each player is dealt seven of each, and each card provides different bonuses and advantages. As a house rule, instead of distributing them randomly, we do a card draft: we all start with hands of 8, pick one from the hand, and pass them to the next player (the 8th card is discarded). That means that you have some chance to put a strategy together at the beginning, and it also lowers the changes that one player will end up with an amazing combo and the other players won’t.

In this game, I managed to draft a number of cards that would help me out in the later part of the game, but wouldn’t do much for me in the beginning. I knew that. It didn’t help, however, when A.C. and Sus came out with early-game killers. A.C. had an occupation that let him add a family member every time he built a room, and Sus had one that just gave her a family member, even without the room, very early in the game. That meant that for much of the early game, I had my two starting family members, Sus had 3, and A.C. had 3 and then 4.

I have to admit that at this point I started getting a bit sulky, and this wasn’t helped by the fact that turns can take a bit of time to plan. That meant that I was done with all my actions while Sus and A.C. had 3 more actions to do, and took their time choosing them while I watched, poor and impotent. I knew my hand would get better in a few rounds, but watching your opponents build large paddocks or huge houses while you’ve got a big empty yard (unused spaces are worth negative points at the end) is frustrating. It’s pretty much a guarantee that no matter how well you’re doing, your opposition will be doing better than you in some aspect. If you’ve got plentiful fields, they’ll have a stone house (upgraded building materials are worth more), or if you’ve got a barnyard full of animals, they’ll have Hearths and other improvements that are giving them surplus food.

In the end, I was able to play my cards that gave me the late-game advantage, using one that gave me food each time another player slaughtered animals for food, and another combo that gave me extra grain each time I got vegetables and a super-upgraded Hearth that gave me more food for those vegetables. I also had a discount on building clay rooms (the middle-value building material) and a card that let me add a free room. At the final score, I still lost, but it was me, 40, Sus 41, and A.C. 45, a very close game.

Don’t get me wrong, I love Agricola, and it’s a great game. Choosing your actions is difficult; specialization can bring gains, but the scoring rewards diversity, so concentrating too much on any one area isn’t fruitful. The game is quite different each time because of the variation in the Improvements and Occupations, but not so different that you can’t get a feel for the pacing and strategies. It’s very well balanced, especially with the card-drafting house rule. I’d definitely recommend it to anyone who doesn’t minds spending a bit of time with the rules at the beginning, as it’s not the easiest game in the world to pick up the first time. Just be prepared for at least one person, and possibly all of you, to feel like there’s no possible way you’ll be able to win.

Twilight Struggle: Conclusion

Mon, 10 Dec 2012 00:00:00 +0000

Unfortunately, A.C. and I didn’t have a chance to get together again before I had to clean up the games table, so there is no conclusion for our Twilight Struggle game. However, unbeknownst to him, I had the Middle East Scoring Card in hand, and was only one or two influence points away from having Control of the region. If I had manged to score while I had control, or if I had managed to Dominate and gotten one more Battleground country, I would have won the game. So it’s probably a good thing that A.C. didn’t have to come over just to play two more action rounds.

Twilight Struggle makes you stand up

Thu, 29 Nov 2012 00:00:00 +0000

I played the first half of a game of TwilightStrugglewith A.C. tonight, and it’s definitely one of my favorite games. The geeks overat Board Game Geek agreewith me, as it’s consistenly the highest rated game on the site. And before youask, it doesn’t have anything to do with sparkly vampires and tween girls.

Twilight Struggle is a two-player strategic game where two players take on the roles of the US and the USSR during the Cold War. You spend your turns playing event cards, either to trigger events that are based on actual Cold War history, or for points to let you spread your influence throughout the globe or remove your opponent’s influence. Some cards also trigger scoring in various world regions (Asia, the Middle East, etc.) according to how many countries in that region are dominated by each power. Much of the strategy comes in from being able to score regions when it’s most advantageous to you.

This is not a game for the faint of heart or short of time. A.C. and I have played 3 or 4 times now, and each time it’s taken at least 3 hours and once closer to 5. We didn’t finish tonight’s game, we just made it to the round 5 out of 10, with plans to resume when we can. I feel like we’ve just barely started to scratch the surface of the game’s strategic depth. A lot of the strategy depends on knowing what cards are out there, and there are over 100 unique cards in the deck. The right card played at the right time can cause devastating reversals, as I found out tonight: I opened a round with the Africa Scoring card, thinking my handy dominance of Africa would get me close to a game-winning 20-point lead, but A’s Missle Envy grabbed a 4-point card from me. Since he got to see my scoring card before I got to play it, he was able to use those points to dominate Africa instead, and net 4 points instead of me netting 4. I still feel like A and I are playing a very superficial game: there are a lot of chances to mislead your opponent about what cards you hold, and set up influence in regions that aren’t currently in play but soon will be, and neither of us are very good at that yet.

This time, I played the USSR and A.C. played the US, and I’ve been close to winning for most of the game (the winner is the one with the most points at the end of ten rounds, but if either player ends up 20 points ahead, or has “control” of Europe when it’s scored, they win immediately; also, if you trigger nuclear war, you lose). This was due partially to good strategy, and partially because the USSR has a decided advantage in the early game, but probably mostly because I had some great dice luck early, and A.C.’s was bad. If I don’t win soon, though, there’s a good chance I never will, since the US makes up for the USSR’s early advantage with great cards in the late game.

In spite of its length, Twilight struggle remains interesting and exciting throughout. Like Go and other territory games, you’re always fighting on multiple fronts, making feints and countering them. You’re always on the verge of being overrun by your enemy in any particular region, by virtue of a bad die roll or a fortuitous event. Unlike most of the other games I play, both A and I spend a big chunk of our time standing up around the table instead of sitting. This is partially because of the large size of the board and flatness of the pieces, but mostly because most moves makes you want to slap down a card and say “Hah!” to your opponent.

Evan Moses

My Policy on AI

All the writing on this blog is mine.

The illustrations on this blog are AI-generated

I use LLMs as tools to help me write code

When I use AI for anything non-trivial I will credit it.

Yak Power-Shears: LLMs are pretty good at Emacs

LLMs: yak power-shears

Specifics

Go forth and customize

Moving My Pi to an SSD

TL;DR

It didn’t work

Whoops, I need 64 bits

Git One Liners: Bulk-Amending a Branch

Breaking it down

Separating work and personal config

TL;DR

Git config

Per-repo overrides

Emacs configs

A Go Puzzle: How can this panic?

The Answer

Think really hard before you embed a pointer

Home Assistant: using target in blueprints

TL;DR

Why doesn’t it work?

The fix: just get all the entity ids

Go Generics: Use Structs for Generic Arguments Lists

TL;DR

The pattern

The abstraction

Go issues, and other languages’ solutions

A Go Solution

Discussion

Emacs Tidbit: rectangle-number-lines

Discussion

No I don't want 2, Emacs

Update Apr 16, 2024

Discussion

Representing State as interfaces in Go

The Pattern

Ok but why?

When to use it

Update: Is this just a Builder?

Discussion

Minimum Age Ratings

Minimum Age ratings on games and why they’re terrible

Building a custom Emacs auth-source

How does this tool work anyway?

So why doesn’t ‘forge’ work?

Let’s extend auth-source

Kinda hard, actually

How does it work with the keychain?

Let’s get parsing

Wrapping it up

Betrayal at House on the Hill - very thematic fun

Description

The Haunt

Conclusion

Dungeon World: My first pen-and-paper RPG

Power Grid: It comes down to math

Agricola: You're always losing

Twilight Struggle: Conclusion

Twilight Struggle makes you stand up

Update: Is this just a `Builder`?