Live Coding Journal - Feb 10, 2026

Notes from Today’s Live Coding Session

Another Precursor to Primitive Obsession

In the ConcertStartedProcessor, the alarms() query method now returns a Map<ConcertId, ConcertAlarm>, but refactoring from the previous map type of Map<ConcertId, LocalDateTime> was made difficult because the “primitive” Map type (I define primitive as a type that is not constrained, such as a long, String, or collection class) rippled throughout the tests, whereas creating a domain-specific Alarms class that encapsulated the Map would have prevented the rippling.

What I call “second-level thinking” is also important when determining who’s responsible for a certain behavior. For example, with the cancelAlarm() command method, should the caller check whether the alarm is in the map before attempting to cancel it, or should cancelAlarm() ignore the call if the concert isn’t in the map. In this case, operations like “cancel” should be idempotent, meaning that if a caller happens to call it twice, (or many times), the result is that the alarm is canceled, and further calls should be ignored.

Using OLIVE Tests as Stepping Stones to Green

I really like calling the tests that are “failing, but for the right reason” as “olive”, because it means I can treat it as a “passing” test when doing things like refactoring. See the video timestamp around 1h35m for an example.

Date-Time Math is Hard

And how. Converting a future date (the concert’s show date and time, which uses the Java Date/Time API) into a delay amount with time units (Java Concurrent’s way of specifying a Duration) is harder than it should be. Time zones made it harder, but after extracting out the date-time factory methods into a separate class, and letting it use the Clock interface to define what “now()” is, made it easier.

Tedbits

Clever is often not better. When implementing the cancelAlarm() method, I originally tried to use the computeIfPresent() method, where I could cancel the ScheduledFuture, and then return null to have the map remove the entry, and while that worked, the straightforward if-null check on the remove() method was simpler. These are the two options:

 private void cancelAlarm(ConcertId concertId) {
    alarmMap.computeIfPresent(
            concertId,
            (_, concertAlarm) -> {
                concertAlarm.cancel();
                return null;
            }
    );
}

vs.

 private void cancelAlarm(ConcertId concertId) {
    ConcertAlarm removedAlarm = alarmMap.remove(concertId);
    if (removedAlarm != null) {
        removedAlarm.cancel();
    }
}

We all agreed that the second option was much easier to read.

Next Steps

In my next live coding stream, I’ll fix the last edge case that @Suigi suggested, where a concert rescheduled from the future to the past should cancel the alarm. Then I’ll work on the actual Runnable task that will be passed to the ScheduledExecutorService, which will require the StopTicketSalesCommand to be implemented.

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