Live Coding Journal - Apr 15, 2026

Notes from Today’s Live Coding Session

Coordinator and Concurrency

This stream was mostly focused on transitioning to the new Projector design, where the DomainProjector is responsible for both caching its state (this speeds up handling new events) and tracking changes, or “delta” (so changes in its state can be easily persisted). It brought up some issues around what code is responsible for initializing the projector, i.e., loading its initial state. In the “old” ProjectionCoordinator, this was done in its constructor. I didn’t care for doing so much work in the constructor, i.e., catching up on possibly thousands of events if the projector is new, but it worked. Now that the ProjectionCoordinator seems to be dissolving, the initialization will move to some Factory-like class, so that it can be called by Configuration as well as from tests.

I’ve been concerned about the potential concurrency issues with the NewDomainProjector’s flush() method–where it has to return both the delta and the Checkpoint value in one call (now as a CheckpointedDelta record), but as I continued to work on other aspects, I wonder if that’s an actual problem. The question about concurrency brought up by viewer @postmodernusturup (around 54m48s in the video) triggered deeper thought into this area.

Reverse-Olive Maneuver

You may be familiar with what I call an “Olive Test”, i.e., a test that fails, but for the (predicted) correct reason. In today’s stream, I did the reverse (inverse?) of this (around 2h00m): modifying the code (changing it or commenting it out) and successfully predicting how the test would fail. It’s very much like mutation testing but focused on a specific piece of code and just a test or two. The underlying principle is the same: making sure we understand how the code behaves and how the tests are checking that behavior.

Repurposing Tests as Specification

I also showed (around 2h04m) how sometimes you can use tests against one implementation (ProjectionCoordinator) as a specification for a different implementation (NewProjectionCoordinator), but that it isn’t TDD. Though you will likely enable one new test at a time (vs. trying to get the implementation to pass all the specification tests at once), you’re no longer using the tests to drive the exploration of the design space.

Next Steps

I’ll finish moving the initialization of the Projector, wire it up to the Spring configuration, and check if everything still works. Then it’s probably time to see if we like the new design and, if so, get rid of the old implementations.

Join me on my next stream, which I usually do Monday through Thursday, starting at 19:00 UTC on Twitch: https://jitterted.stream.