Ted M. Young's Confident Coding Blog

Live Coding Journal - Apr 15, 2026

2026-04-15T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

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.

Live Coding Journal - Apr 13, 2026

2026-04-13T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

Notes from Today’s Live Coding Session

Today’s stream was mostly mundane (and a bit frustrating) refactoring. At one point (around 1h32m) I did a revert to redo the refactoring as I had painted myself in a bit of a corner.

One thing I did realize is that while the flush() method in the “new” Domain Projector returns the “delta” state, that state should not include the Checkpoint. The Checkpoint is a property of the Projector, not the state, so instead it should return Delta+Checkpoint, aka CheckpointedDelta.

public abstract class NewDomainProjector<STATE, DELTA extends ProjectionDelta>
        extends EventHandler {

  public abstract STATE currentState();

  /**
   * Returns any uncommitted changes in the projection,
   * clearing it as a result.
   *
   * @return uncommitted changes since the last time flush was called,
   * or since the projector was instantiated
   */
  public abstract DELTA flush();

  /**
   * Checkpoint for the most recent event sequence processed by this projector.
   *
   * @return the last event sequence processed, or Checkpoint.INITIAL if none have been processed
   */
  public abstract Checkpoint checkpoint();
}

Next Steps

Finish up the “new” projection coordinator persistence and then see what’s left to do before (finally!) returning to work on the TDD Game online version.

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

Live Coding Journal - Apr 7, 2026

2026-04-07T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

Notes from Today’s Live Coding Session

Moving Away from Aggregate-Focused Types

I started the stream innocently enough, renaming EventConsumer to the better-named EventStreamConsumer, since it is responsible for handling a potential Stream of Events, as shown by its interface:

public interface EventStreamConsumer {
    void handle(Stream<? extends Event> eventStream);
}

This better separates its responsibility from EventHandler, which is responsible for implementing individual handle() methods for specific Event types.

You may have noticed that I dropped the generic EVENT type, replacing it with ? extends Event). This is a step in moving away from an Aggregate-centric view of things, where a hierarchy of events relates to specific Aggregates. For example, where ConcertEvent, associated with the Aggregate Concert, is the parent class of ConcertScheduled, TicketsSold, etc., and CustomerEvent (for Customer) is the parent of CustomerRegistered, TicketsPurchased, etc. As I continue to move towards an Event-centric view, the generic type gets in the way, since, for example, we may have EventStreamConsumers that want to consume both ConcertScheduled and CustomerRegistered (for whatever reason). Eventually this will ripple out so that there is only one EventStore instance, instead of having one per Aggregate, e.g., EventStore<Concert,...> and EventStore<Customer,...>.

EventStore Subscription for Desired Events

My main goal this stream was to have all EventStreamConsumer subscriptions to the EventStore specify their desired events to improve performance, as well as making it clear in the code which events it wants:

void subscribe(EventStreamConsumer eventStreamConsumer,
               Set<Class<? extends Event>> desiredEvents);

and deprecating the existing subscribe(EventStreamConsumer) method.

An “Olive” Failure Moment (1h01m)

During test-driving this change, Predictive TDD (predicting precisely how a test would fail) once again saved the day. In my test, I was using my MakeEvents builder to set up the events for the test, and then passed those events to the EventStore’s save(ID aggregateId, Stream<EVENT> uncommittedEvents) method. However, instead of expecting the test to fail by sending all events to the consumer (as I hadn’t yet implemented the filtering), no events were sent at all. This was surprising, because I had thought that save() method would send the events along to any consumers. It turns out, the save(AGGREGATE aggregate) method (that takes an entire Aggregate) is what sends events on to consumers. The save(ID, Stream<Event>) is more of an internal method, but because it is currently public, I had a misunderstanding of its responsibility. Once I changed the test to use save(AGGREGATE), the test failed as expected (aka an “Olive”), which allowed me to move forward on implementing the filtering.

TDD Heuristic: Use Test Failures to Examine Your Design

As I said in today’s stream, “TDD is not about writing tests. It’s about exploring the design space.” Tests fail, but it’s when they fail for the wrong reason (or perhaps don’t fail at all), that it’s a good opportunity to step back and examine why that happened.

The New Projection Coordinator (2h28m)

With the Event Store supporting filtering events for consumers, it was time to migrate the ProjectionCoordinator to use filtering for both the catch-up portion (asking the Event Store for all events after a checkpoint event sequence) and for the subscription. This wasn’t a trivial migration, though, since the NewDomainProjector is now stateful, vs. the stateless/functional implementation in the (old) DomainProjector. This means that the NewDomainProjector not only holds onto the projection (like a cache), but also needs to track the Checkpoint (latest event sequence processed). In addition, to prevent race conditions, the projector has to return the projection and the checkpoint as part of the flush() method’s return value.

Next Steps

Next time I’ll finish the NewProjectionCoordinator and NewDomainProjector so that the coordinator lets the projector handle the cache of the projection and the checkpoint.

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

Live Coding Journal - Apr 6, 2026

2026-04-06T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

Notes from Today’s Live Coding Session

Splitting EventConsumer

It turned out that in trying to make the single EventConsumer interface apply to both Projectors and the ProjectionCoordinator didn’t quite fit. Pure Domain Projectors need to advertise the events they want (“desired events”), and do so by implementing one or more handle() methods with a specific event type. However, the Projector needs the persistence and catch-up support provided by the ProjectionCoordinator. I couldn’t figure out a way to make it work without doing delegation of the handle() methods, which makes no sense. Solved this by splitting it into an EventConsumer (perhaps a better name is EventStreamConsumer), which implements a handle(Stream<? extends Event> events) method and EventHandler, which is where the specific handle() methods would be implemented, and provides a Set<Class<? extends Event>> handledEventTypes() that uses reflection to collect the desired events.

Now, ProjectionCoordinator implements EventConsumer and is in charge of (among other things), catching up with the event store and subscribing to new events. Once EventStore supports desired events for subscribe, ProjectionCoordinator could do this on startup:

var desiredEvents = domainProjector.handledEventTypes();
// the following now works across all event store implementations
Stream<EVENT> eventStream = eventStore.allEventsAfter(cachedCheckpoint, desiredEvents);
updateProjection(eventStream);

// we'll do this next time
eventStore.subscribe(this, desiredEvents);

New Domain Projector Design

Since the Projector implements individual event handle() methods instead of routing all events through a single method, it is no longer a stateless/functional implementation. It has to retain state across (potentially) multiple invocations of the various handle() methods, but that’s fine. Squinting a bit, this change makes a Projector look a lot like the current Aggregate implementations, where the initial state is loaded from the event store, events are applied to evolve the state, and we can ask for new “uncommitted” events that are generated. And now a Projector gets its initial state loaded from persistence, events are applied via the “handle” methods, and we want to ask it for changes to its state. This is good, as Aggregates have always been a projection of events, centered around the properties of the Aggregate.

Once I realized that, I wanted to change the Domain Projector’s method that returns the delta (changes) to uncommittedChanges(), but unlike Aggregates which get thrown away once they’ve done their job, Projectors cache their Projections in memory. This meant I needed to “reset” the changes, so I initially thought I’d need a separate flush() method that would clear it, and added it (but didn’t implement it!) while test-driving (2h17m46s in the video). However, this could lead to issues where the changes were retrieved, but the flush was never called, potentially corrupting the persisted projection. @Suigi suggested returning the changes as part of the flush() and get rid of uncommittedChanges() and that’s what I did instead. Even though this violates Command-Query Separation (CQS), it turned out to be a better match for supporting persistence. And I’d argue that this is one of the rare exceptions to CQS, much like a Stack’s pop() both modifies the stack and returns a value.

Moving Away from Aggregates – Someday

I’ve been dropping the generic EVENT during these changes, since the original intention of that generic type was to capture the base class for events related to a specific Aggregate, e.g., ConcertEvent that is the parent of all Concert-specific events. As I move away from this Aggregate-centric way of looking at things, the generic type gets in the way and, instead, we use the event filtering (“desired events”) to capture the events that Projectors, Processors, and (eventually) Aggregates are interested in.

Next Steps

Finish the conversion of the ProjectionCoordinator to use the NewDomainProjector, and update the Event Store’s subscribe() method to accept desired events. Then I’ll convert the AvailableConcertsProjector to this new model and see how it fits.

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

Live Coding Journal - Apr 2, 2026

2026-04-02T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

Notes from Today’s Live Coding Session

Consuming Only Desired Events

I finally started on a big optimization, mainly for Projectors that need to catch up on lots of events (because they’re new or changed), where Event Consumers only fetch/receive events that they’re interested in. For example, the AvailableConcerts projector only needs to know about events relating to availability of customers to buy tickets. There’s no point in it fetching or receiving events like TicketsSold or event CustomerRegistered, especially since the large majority of events would be about ticket sales. The question was: how do consumers “publicize” which events they want?

The options were:

Have an interestedIn() method that all consumers must implement, returning a list of event classes they want.
Register desired events when the consumer registers itself with the Event Store
Like #1, but using a code generator to generate the method (and other boilerplate, like the switch block for handling the events)
Similar to #1, but using Annotations
Have the Event Consumer create handle() methods, overloaded for each desired event, which reflection can find.

I decided to go with #5, as it’s straightforward to do, and unlike #1/#3, does not repeat the same information, which could lead to forgetting to publicize a desired event. I didn’t like #2, because as above, it’s easy to forget to update the configuration when desired events change, especially since configuration is in a separate file. I generally don’t like annotations, but #4 suffers from the same problem as above: having to update the annotation to indicate desired events.

Using reflection also allows me to handle implementation problems such as methods that might be handle() methods, but perhaps were misspelled (e.g., handel(ConcertScheduled event)), or if no methods handle events at all. I also added in extra checks for the case where somehow the consumer is getting events that it wasn’t interested in, which would indicate a bug elsewhere.

Moving to selective event consuming also means dropping the generic type from the NewEventConsumer, which helps as I continue to move away from an aggregate-focused design.

`Void` vs. `void`

This was a (not) fun troubleshooting session, took a long time to figure out why I couldn’t use MethodHandle.lookup().findVirtual() for the handle methods that return void. It turns out, Void.class is not the same as void.class (yes, a class from the “primitive” void)! After struggling through the rest of reflection to get the methods and try out invoking them, I got the prototype to work. However, it was much more painful and frustrating than it should have been thanks to docs that aren’t great.

Background Thoughts on Projection Design

Over the weekend, I’ve been thinking about Projections and how I’m currently caching them in memory to make updating their state fast. I was reminded of earlier thoughts where some Projections could use the database to perform the summary calculations (e.g., the Sales Projection). This is another reason in favor of consolidating the Projection persistence into the Projection code itself instead of the current “wrapper” way that I’m currently doing in the ProjectionCoordinator. Not only that, the persisting of the projection might be different depending on how “risky” it is to have it catch up if the system crashes or needs to restart. On the other hand, I want to implement a deferred-write mechanism for persisting projections, so having a standard way to deal with deferred writes (after a timeout or deferred data exceeds a threshold) might be easier with a ProjectionCoordinator design.

Next Steps

With the NewEventConsumer completed, I’ll be working on converting the RegisteredCustomersProjector to use it. If time allows, I’ll also convert the AvailableConcertsProjector.

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

Live Coding Journal - Mar 30, 2026

2026-03-30T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

Notes from Today’s Live Coding Session

Clarifying Event in Event-Sourcing

Once again I caught myself not being clear (to myself!) about what an event is in event-sourcing. Not only is it something that has happened (a “fact”), but it must be related to some “thing”. Whether that thing is an Aggregate (Concert, Customer), or an Entity (Ticket?), or some other concept, in order for it to be a fact, it must be related to something identifiable. This is why an event like “CalendarDayEnded” makes no sense for event-sourcing: which thing are we talking about? What thing’s state has changed as a result? (If no state has changed, then it can’t be an event in event-sourcing!)

It’s fine for “CalendarDayEnded” to be a Collaboration Event, i.e., for communicating information across processes. In that case it might trigger a “Translator” to:

Do a query for all Concerts that have a show date of the day that ended, and
For each Concert (only one for our single-venue system), issue a Command to the Concert to “close”.

Then we’d end up with a “ConcertClosed” event (with the ID for that particular Concert), but only because of the Command that was issued by the Translator.

“Event Must Have ID” Heuristic

Any event that represents a change in state, i.e., an event in an event-sourcing system, must have some identifier that associates the change in state with the “entity” or value that changed (the identifiable state). Events without an identifier can exist, but they must be some other type of event, e.g., Collaboration or Integration event that communicates information across process boundaries.

Separating “Tickets On Sale” from “Concert Scheduled”

In the current implementation, tickets become available for purchase as soon as the concert is scheduled. In the real world, this is not always (or even often?) the case. This will give me an opportunity to explore event (or “schema”) evolution when adding a new feature, especially when it’s modifying the contents of an event. In this case, we’ll need to add the “on-sale” date and time to the ConcertScheduled event. This is the somewhat easier case, since we’re only adding new properties to an existing event (vs. changing or removing properties, which is harder). As is typical for adding new properties, we need good defaults to “fill in” values for events created prior to this change.

Improving Catch-Up Processing via Filtering Event Types

Since “on sale” is very similar to “stop sales”, in that both require a future alarm to be set for when that date/time come around, I looked at the ConcertStartedProcessor to see what would need to change. As I examined how the alarms get set, I realized that since the alarms are not persisted, the Processor needs to catch up from the beginning of the entire event stream every time. Since it only cares about scheduling and rescheduling concerts and stopping ticket sales, that would be fast, except for the fact that the EventStore doesn’t support asking for events of specific types, only the parent class that relates to each aggregate, i.e., Customer and Concert. This means in addition to the ~hundreds of ConcertScheduled events that we care about, we’d get thousands (or hundreds of thousands) of TicketsSold events that would be ignored. In one of my sets of sample data, where there were ~5MM events, this took over 2 minutes to load! (Yes, there are probably some improvements to make that faster.) However, we end up ignoring almost all of them, making it extremely wasteful.

When I hacked in this change, it took 4 seconds to load and process 101,000 events for the RegisteredCustomers Projector, significantly faster and much less wasteful than loading 5MM.

Redesign of EventConsumer Interface

I spent around 90 minutes (around 17m to 1h47m in the video) adding the ability to specify specific events to load through the event store’s allEventsAfter() method. Once I proved that it would drastically increase performance (that 4 minutes is now around 2 seconds), I looked at how that would fit with the design of the EventConsumer interface, which both Projectors and Processors implement. The main question is: how should an event consumer signal that it’s only interested in specific events? I think there are only two options:

When the consumer registers/subscribes with whatever publishes the events (EventStore in this case), it sends a list of events along with the subscription.
The EventConsumer interface defines a List<Event> interestedEvents() method that gets called from the publisher when the consumer is registered.

The problem with option 1 is that this happens during startup and separates where the consumer is registered with the EventStore (in configuration) from where they’re processed (in the consumer). While I’m not fond of callbacks like this, I’m less fond of having this knowledge of the events separated.

`ProjectionCoordinator` Disappears?

Looking at redesigning EventConsumer led to an exploration of the ProjectionCoordinator design. The coordinator is a persistence “wrapper” and cache around the actual projection code (a DomainProjector) that does the actual processing of events (and has no state itself). It works nicely, because the DomainProjector doesn’t need to know about peristence (or caching of the projection), or even that persistence is happening, other than returning changes since the previous time it ran (the Delta), which makes the persistence easier. However, since a Projection is a Cache of computed values, maybe the cached projection should be inside the Projector? In other words, turn it inside out. This would mean the ProjectionPersistencePort would be injected into the Projector, and the ProjectionCoordinator would go away.

Next Steps

Since it’s unclear which design (wrapper vs. injecting persister into the projector) is better, next time I’ll try out the injection into a new PersistedProjector for the Registered Customers and Scheduled Concerts projectors and see which one looks better.

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

Live Coding Journal - Mar 25, 2026

2026-03-25T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:
- Mar 23, 2026
- Mar 24, 2026

Notes from Today’s Live Coding Session

Avro Encoding Dead-End

I spent almost 2 hours working on serializing events using Avro instead of JSON in the hope that it’d increase performance. It was a bit of a frustrating process, especially the requirements for a no-arg constructor for events, which I didn’t really want to add. After running some simple benchmarks, I realized that the JSON (de)serialization itself is probably not the performance bottleneck, and so gave up on the Avro spike. I’ll revisit performance at some point by doing more profiling of the application, but for now I need to focus on functionality that extends my learning around event-sourcing.

ConcertCompleted: Not Real? Projection = Cache

I decided to look at what it would take to add a new event, to see what the process now looks like so I can simplify it if necessary. It turns out, the event I wanted to add, ConcertCompleted, may not make any sense. I spent almost an hour thinking out loud about it and decided that it seemed a bit “fake” to create a whole Use Case (a Screen/UI, a Command, and an Event) just to basically “evict” the (now completed) Concert from the “Scheduled Concerts” Projection. Since Projections are cached queries against the entire event stream, spending effort to remove an entry–when there will only be on the order of hundreds of entries–just isn’t worth it. If I need to “garbage collect” the concerts that are no longer in the future, I can just regenerate the projection or check if I need to drop old concerts whenever a new one is added (this was option #4 on my list of ways to deal with this). Once Projections can query for specific event types (e.g., ConcertScheduled and ConcertRescheduled, instead of all events after a checkpoint), this becomes much more feasible.

Heuristic

I think it’s important to ensure that ID-based projections don’t grow completely unbounded, i.e., there should be some event that “evicts” entries. For Summary Projections (those that do some kind of summing or aggregation across events), this doesn’t apply, since they’re like a “reduce” and would not grow nearly as fast. However, even for a Summary Projection like the Concert Sales Projection, there’s probably no business reason to keep sales information for a 3-year-old concert. (Unless you want to forecast sales of the same band for a future concert, in which case it’s fine to have it stick around.)

The thought process did reveal the biggest issue with my event-sourcing infrastructure: the focus on Aggregate IDs. I wanted to try having an “end-of-day event” generator that Projections could consume to do things that are calendar related, but saving an event (through the EventStore) requires an ID (which becomes a primary key in the database table). This leads to the question of, what ID would I use for such a general event? Does this kind of event make sense from an event-sourcing system? I think not, or at least it should not be persisted. It might be fine if it’s treated as a Command/Trigger/Action, but such a Command would need to be executed against one (or more) actual Concerts to generate ConcertCompleted events.

Since I didn’t feel like that would be a useful next step, from either a learning or functionality standpoint, I decided to table it and move on to something else.

Next Steps

I decided to implement a new feature: the ability to set an “on sale” date/time for tickets, instead of them going on sale as soon as the concert is scheduled. This will be interesting, not only because it’s a change in behavior, but also (as @Suigi mentioned), all of the existing scheduled concerts need to be dealt with. And the AvailableConcerts projection (the one used to show customers what concerts they can buy tickets for) will need to change, further separating it from the ScheduledConcerts projection that is used to detect scheduling conflicts.

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

Live Coding Journal - Mar 24, 2026

2026-03-24T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:
- Mar 23, 2026

Notes from Today’s Live Coding Session

Exception vs. Result Pattern

Today I reviewed my decision (around 10min into the video) to use an Exception for when there’s a scheduling conflict for concerts (trying to schedule a concert on a date where one was already scheduled) by looking at what the code would for something like Vavr’s Try (“Result” pattern) vs. a normal try..catch. I think an Exception is just as readable and, since this isn’t in a tight processing loop, any performance implications of throwing an Exception are irrelevant since the result is an HTTP response (redirect). If we were validating hundreds or thousands of lines of input, then there might be some noticeable impact, but that’s not the case here.

External Validation: Scheduling Conflicts

Once I figured out where the scheduling validation check should go (sketching the call in the Commands.createScheduleCommand() method), I determined (around 24m) that the (cached) projection state (ScheduledConcerts record) has the knowledge to execute the conflict-check query. Having the cached projection state execute the query is fine if there aren’t thousands of concerts to check. For something like email uniqueness where there may be many thousands (or millions?) of entries, we would want to run a query against the database, though we could optimize using a Bloom filter if we wanted. However, even in a production system, there wouldn’t be a problem with this cache unless the system was handling tickets for many venues (vs. just one). A nice benefit of the conflict check inside a simple record is that TDDing the implementation was straightforward.

Value Objects: Smallest Consistency Boundary?

At 2:51:20 in the video I ponder the common code ensureNoConflictFor(showDateTime) between the validation for Schedule New Concert and Reschedule Existing Concert actions:

public CommandWithParams<ConcertId, RescheduleParams> createRescheduleCommand() {
    return commandExecutorFactory.wrapWithParams(
            (concert, reschedule) -> {
                LocalDateTime showDateTime = reschedule.showDateTime();
                ensureNoConflictFor(showDateTime);
                concert.rescheduleTo(
                        showDateTime,
                        reschedule.doorsTime());
            });
}

public CreateWithParams<ConcertId, ScheduleParams> createScheduleCommand() {
    return commandExecutorFactory.wrapForCreation(
            scheduleParams -> {
                LocalDateTime showDateTime = scheduleParams.showDateTime();
                LocalTime doorsTime = scheduleParams.doorsTime();
                ensureNoConflictFor(showDateTime);
                return Concert.schedule(
                        ConcertId.createRandom(),
                        scheduleParams.artist(),
                        scheduleParams.ticketPrice(),
                        showDateTime,
                        doorsTime,
                        scheduleParams.capacity(),
                        scheduleParams.maxTicketsPerPurchase());
            });
}

With Command-Consistency Boundaries replacing Aggregates, the question is: what is the smallest consistency boundary that makes sense? It seems like Value Objects are the minimum boundary, as anything smaller probably wouldn’t need to change simultaneously. For example, there’s no need for one user to make a change to a Concert’s “Doors Time” at the same time as another user making a change to the “Show Time”. Both of those are linked (there’s even validation for Doors Time that depends on the Show Time, as I implement later in the stream), so that’s the minimal consistency boundary. Similarly for an address, there’s no point in allowing changes to the City by one user and the State for another user. An Address is a Value Object and is a complete unit of consistency.

Next Steps

With the validation out of the way, the next step is to try Avro as a serialization format and see how performance compares with the current JSON implementation.

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

Live Coding Journal - Mar 23, 2026

2026-03-23T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last stream

Notes from Today’s Live Coding Session

I’m back from my break! I was at DevNexus in Atlanta, where I gave a talk on automated refactorings in IntelliJ IDEA. Last week I attended the always awesome JavaOne conference a few miles down the road in Redwood Shores, California. I mentioned a few of the talks that I encourage folks to watch out for when they appear on YouTube.

Consistency Boundaries

After getting back into the JitterTicket codebase (and upgrading to the newly released JDK 26), I continued my thought process around Aggregates in event-sourcing vs. DCB (Dynamic Consistency Boundaries). I’ve decided to use the term “Command Consistency Boundaries” instead of DCB, because the boundary isn’t all that dynamic, it is based on the needs of each command. (See around 41:00 in the video.) This comes into play with the validation I’m adding for the Scheduling Concert. There are generally three kinds of validations/rules that are evaluated when deciding to execute a command:

Parameter validation: are the parameters in range (parse 'em into Value Objects to make sure!) and internally consistent (across multiple parameters, such as City+State+Postal Code matching)
Internal validation: often these are the Domain Rules that use the state of the entity, e.g., does the Concert have sufficient tickets available to fulfill the number of tickets being purchased?
External validation: requires information from outside of the entity, possibly even outside of the process (system), e.g., is this email address unique, does this concert date conflict with one already scheduled, or does this user have authorization to take this action in the first place?

What I find so interesting about the CCB (command-consistency boundary) is that we can gather precisely (no more, no less) the inputs required for all these decisions to be made, instead of loading more information than we might need (via an Aggregate) and then, separately, getting the external information (e.g., query a database for email addresses). (See around 2:50:00 in the video.)

Heuristics for Missing Events

I came up with a couple of heuristics that might indicate missing events. One is if a projection requires access to the current date or other out-of-process information that’s not in any event. An example here (around 1:35 in the video) is discarding concerts that already took place in the past when projecting Scheduled Concerts (to be used when looking for scheduling conflicts). In this case, I’m missing a ConcertCompleted event that would drop the concert from the projection of scheduled concerts. After all, there’s no need to look for conflicts when scheduling a new concert against concerts that happened in the past, since you can’t schedule a new concert in the past!

The second is if you find the projection having unbound growth, mainly that nothing ever gets deleted/removed from the projection. This is a weaker heuristic, because for things like Customer Emails, it will obviously grow as long as your adding more customers. However, there will be customers who close their accounts or change their emails, so if you’re not removing emails from the projection, you might be missing a CustomerEmailChanged or CustomerAccountClosed.

Event Serialization (Encoding)

In our book club, we’re reading Designing Data-Intensive Applications, and we just finished the chapter that explored different ways of serializing (encoding) in-memory data structures to disk. I had done some profiling on JitterTicket and found that a fair amount of time is being spent on decoding the JSON to Event objects, so I’m going to try encoding the event using Avro to see how much of a difference it makes.

Next Steps

We’ll implement the external validation for scheduling concerts and then work on Avro encoding for event payloads.

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

Live Coding Journal - Feb 19, 2026

2026-02-19T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from the last two weeks of streams:

Notes from Today’s Live Coding Session

Spring Boot 4.0.3 Upgrade

Before doing any more functional work, I wanted to (finally!) upgrade from Spring Boot 3.5.9 to 4.0.3.

I wanted to try out using the Arconia CLI to drive the OpenRewrite migration scripts. I ran it, but nothing seemed to happen. Apparently I missed the fact that you needed to type arconia help to get the list of commands and options. I think this is a poor starting user experience as -h, --help, typical options for CLI tools, produced stack traces, where I expected to see some sort of help. Most CLI tools will at least display something when you run them, so it’s strange that Arconia doesn’t display anything at all.

Following the migration guide, before doing the actual upgrade, I did a minor upgrade to 3.5.11, the latest in the 3.5.x series, and made sure all the tests passed (they did). What was confusing for a bit was that I had an override property to ensure that I was using JUnit 5.14, as I was using the recent Parameterized Classes feature. I removed the override thinking that Spring Boot 3.5.11 had a recent enough version of JUnit, but it only had 5.12.2, which wasn’t recent enough.

Once I got that cleared up, I ran the Arconia migration scripts and, unsurprisingly, code relating to how I configure the Jackson (JSON) ObjectMapper no longer worked. I say unsurprising because Spring Boot 4.0.x uses Jackson 3 instead of Jackson 2, where enough has changed that the migration scripts currently don’t handle all the necessary changes. The biggest annoyance was figuring out how to configure INCLUDE_SOURCE_IN_LOCATION, which was way more difficult to solve than it should have been. I’ll be writing up a deeper post on this, with perhaps some ideas for additional OpenRewrite recipes to cover the situation.

Once I got past the compilation issues, I ran all the tests and noticed a failure in the CSV tests that were sensitive to changes in JSON serialization. Apparently, the default way that dates and times are serialized in Jackson 3 is ISO-8601, which is a much better format, but different from the previous default. I was glad that tests caught this, but dismayed that it was only caught as a part of a CSV test instead of a dedicated serialization test. I wrote the missing serialization test as a characterization test, and then fixed the failing CSV tests to use the new date/time format.

After finishing the Jackson migration, all the Spring-related tests failed with a weird NoSuchMethodException for computeIfAbsent in the SpringExtension. I quickly realized that I had forgotten to take out the JUnit version property, which was now forcing an old version (5.14.0) instead of letting Spring Boot pull in the 6.0.3 that it needed.

Projection Misconfiguration

Once I got the application running again, I realized there was a problem with the concerts shown on the “On-Sale Events” page (around 1h12m into the stream). The problem was that one of the concerts shown should not have been on sale because its show date/time was in the past. I realized that I had miswired the projection when plugging in the “All Concerts” projection in a previous stream (to fix the event viewer). Because both the “All Concerts” and “Available Concerts” projections use the same types for the projection contents (I took a shortcut by reusing AvailableConcerts for both), I didn’t realize I was injecting the wrong projection into the on-sale page. It wasn’t a difficult fix, but in a production system, I would have been more disciplined about making sure that the two projections used completely separate types.

Extending CommandExecutorFactory for Creation

I thought adding the “creation” command type to the CommandExecutorFactory was going to be complex, but it turned out to be straightforward once I realized that calling a static method (to do the creation) was no different than calling an instance method. Once again, getting my head wrapped around the generics needed for the wrap and the command execution took a bit of time, but was happy with the result:

public CreateWithParams<ConcertId, ScheduleParams> wrapForCreation(
        CreateWithParams<Concert, ScheduleParams> command) {
    return scheduleParams -> {
        Concert concert = command.execute(scheduleParams);
        concertEventStore.save(concert);
        return concert.getId();
    };
}

with the concrete “schedule” command defined like this:

public CreateWithParams<ConcertId, ScheduleParams> createScheduleCommand() {
    CreateWithParams<ConcertId, ScheduleParams> command =
            commandExecutorFactory.wrapForCreation(
                    scheduleParams -> Concert.schedule(
                            ConcertId.createRandom(),
                            scheduleParams.artist(),
                            scheduleParams.ticketPrice(),
                            scheduleParams.showDateTime(),
                            scheduleParams.doorsTime(),
                            scheduleParams.capacity(),
                            scheduleParams.maxTicketsPerPurchase()));
    return command;
}

The expectation is that any creation command is going to return the ID of the created aggregate, since the client doesn’t supply the ID but would need to know it. For example, we probably want to display the created aggregate to confirm that the creation worked, so we need the ID to use as part of an HTTP redirection. I ended up not bothering with that, since this is an example app, and so simply redirected back to the on-sale concerts page.

The Test Fixture is Inside the Controller!

With the “inside” of the schedule functionality complete, I test-drove the UI to wire it up. On the way, instead of putting the test fixture for the ScheduleConcertController in the test, @Suigi suggested going the Nullables route. At first, I didn’t think it’d work, because the test needed access to the EventStore Test Double as well as the controller, and Java doesn’t have a way to return multiple values. The way I typically do this in the test context is to use Extract Method, and then IntelliJ IDEA creates a record containing the objects the test needs as the return value. However, there’s no reason not to do this in the production controller class! Test code in a production class? Blasphemy, I know.

Here’s what it looks like:

static Fixture createForTest() {
    var concertEventStore = InMemoryEventStore.forConcerts();
    ScheduleConcertController scheduleConcertController =
            new ScheduleConcertController(new Commands(CommandExecutorFactory.create(concertEventStore)).createScheduleCommand());
    return new Fixture(concertEventStore, scheduleConcertController);
}

record Fixture(EventStore<ConcertId, ConcertEvent, Concert> concertEventStore,
               ScheduleConcertController controller) {}

So now the test can call createForTest() and access the in-memory EventStore as well as the controller:

@Test
void postScheduleNewConcertCreatesConcert() {
    var fixture = ScheduleConcertController.createForTest();

    String redirect = fixture.controller().scheduleNewConcert(
            new ScheduleConcertController.ScheduleForm("Daylight Noise", 35, "2026-03-14", "19:00", "18:00", 75, 2));

    assertThat(redirect)
            .isEqualTo("redirect:/concerts");
    assertThat(fixture.concertEventStore().allEventsAfter(Checkpoint.INITIAL))
            .hasExactlyElementsOfTypes(ConcertScheduled.class);
}

And if a test doesn’t need to see the EventStore, it can just ignore it.

Projection vs. Read-Model vs. Query and Validation

At around 3h35 in the stream, I discussed the similarities and differences in the terms “Projection”, “Read Model”, and “Query”, especially as it relates to Event Modeling. It’s a bit confusing, because I see “Query” as a major component and none of the Event Models I see incorporate it. This was all part of figuring out the next feature, which is validating the Schedule Concert to ensure that we’re not double-booking artists for the same date.

Next Steps

Next time we’ll dig into implementing the validation, as I think it’s important functionality that I haven’t tackled yet in this event-sourcing example application.

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

Live Coding Journal - Feb 18, 2026

2026-02-18T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:

Notes from Today’s Live Coding Session

Refactoring to Granular Reader and Writer

On today’s stream, I spent some time refactoring the use case/command/application layer code, i.e., the command and query for rescheduling concerts. Instead of the typical case where I’d pass in a service class, or perhaps a full Repository (or in this case, the entire EventStore), I now pass in more specific interfaces for doing a query for concerts (read) and the command object for rescheduling it (write). Before the refactoring, the code looked like this:

@GetMapping("/reschedule/{concertId}")
public String rescheduleConcertView(@PathVariable("concertId") String concertId,
                                    Model model) {
    Concert concert = concertEventStore
            .findById(new ConcertId(UUID.fromString(concertId)))
            .orElseThrow(() -> new RuntimeException("Could not find concert with id: " +  concertId));
    model.addAttribute("concert", ConcertView.from(concert));
    model.addAttribute("rescheduleForm", RescheduleForm.from(concert));
    return "reschedule-concert";
}

@PostMapping("/reschedule/{concertId}")
public String rescheduleConcert(@PathVariable("concertId") String concertId,
                                RescheduleForm rescheduleForm) {
    CommandExecutorFactory commandExecutorFactory = CommandExecutorFactory.create(concertEventStore);
    var command = commandExecutorFactory.wrapWithParams(
            (concert, reschedule) ->
                    concert.rescheduleTo(
                            reschedule.showDateTime(),
                            reschedule.doorsTime()));
    Reschedule rescheduleParams = new Reschedule(
            rescheduleForm.newShowLocalDateTime(),
            rescheduleForm.newDoorsLocalTime());
    command.execute(new ConcertId(UUID.fromString(concertId)),
                    rescheduleParams);

    return "redirect:/reschedule/" + concertId;
}

After the refactoring, which included adding a factory method to ConcertId that takes a UUID as string, it now looks like this:

@GetMapping("/reschedule/{concertId}")
public String rescheduleConcertView(@PathVariable("concertId") String concertId,
                                    Model model) {
    ConcertId id = ConcertId.from(concertId);
    Concert concert = concertQuery.concertQueryFind(id);
    model.addAttribute("concert", ConcertView.from(concert));
    model.addAttribute("rescheduleForm", RescheduleForm.from(concert));
    return "reschedule-concert";
}

@PostMapping("/reschedule/{concertId}")
public String rescheduleConcert(@PathVariable("concertId") String concertId,
                                RescheduleForm rescheduleForm) {

    rescheduleCommand.execute(ConcertId.from(concertId),
                              rescheduleForm.asCommandParams());

    return "redirect:/reschedule/" + concertId;
}

So much cleaner! And just as easy to test as before, if not easier, because the ConcertQuery has a single method that’s easier to replace with a test double if needed.

I moved the creation of the command object to a new class, Commands, where all new command objects will live:

public class Commands {

  private final CommandExecutorFactory commandExecutorFactory;

  public Commands(CommandExecutorFactory commandExecutorFactory) {
      this.commandExecutorFactory = commandExecutorFactory;
  }

  public CommandWithParams<ConcertId, Reschedule> createRescheduleCommand() {
      CommandWithParams<ConcertId, Reschedule> command = commandExecutorFactory.wrapWithParams(
              (concert, reschedule) ->
                      concert.rescheduleTo(
                              reschedule.showDateTime(),
                              reschedule.doorsTime()));
      return command;
  }
}

I still have some package reorganization to do, but I’m pretty happy with how this is set up.

All Concert Aggregates Projection

I then (around 3h04m) worked on fixing the problem where my event viewer was only showing Concert objects that were available, i.e., tickets can be purchased. That’s fine for showing the list of concerts to a customer, but for viewing the underlying events, I want to see all Concert aggregates that ever existed. For that, I needed a new projection. It’s almost exactly like the AvailableConcertsProjection, so I cheated a bit and copied it, leaving only the event it cares about: ConcertScheduled. It’s tempting to reuse the same projection for different situations, but since projections are cheap to code and create, it’s better to avoid potentially dangerous coupling. I didn’t even bother test-driving it, since the code I extracted it from was well tested. After updating the configuration to use the AllConcertsProjection, everything just worked.

Event Modeling Tool Tryout

I’ve been using tldraw.com for my diagramming, which is a great tool, but since it’s a generic drawing tool, it can be a bit painful to create more structured diagrams, such as event models. I spent about 90 minutes (starting around 1h30m into the video) trying out two tools: one was from @Suigi (aka Daniel Ranner), who create a tool called Slicr. Like PlantUML and Mermaid, it uses the text-to-diagram method, where you type structured text and the diagram is drawn from that description. I think it’s so much better to create diagrams that way, since they’re much easier to make global changes to and easily diff between revisions. It turns out LLMs are pretty good at it too, since it’s “just text”. I built out the Purchase Tickets slice of JitterTicket (you can see it at 2h20m) and once I got the syntax down (though it uses YAML, sigh), it was straightforward to use.

I then (around 2h32m) looked at Ismael Celis’ EventLanes app. (It was neat to report a bug on stream and have Ismael fix it right away!) Event Lanes is in beta, but has some really nice features around schemas that define the data elements used in read models, commands, and UIs. I also created the Purchase Tickets slice and added the Concert Started Processor to the diagram (see 3h02m). The tool itself is event-sourced, so you can look at the history and time-travel to see what the diagram was at any point. It’s also multi-user and (like many tools these days) has an MCP Server so an LLM can control it more directly. I look forward to spending more time with this tool, especially when looking at how to use the diagram text for code generation.

Next Steps

I want to add some concert scheduling validation, where the system ensures that you can’t schedule two concerts for the same date. This will need yet another projection, but those are straightforward to create. That will require implementing the “creator” command, which will be tricky because creation happens via static methods, so I’m unsure how to fit that into the current code.

Before I do any of that, however, I’ll be upgrading (finally!) to Spring Boot 4.0.3.

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

Live Coding Journal - Feb 16, 2026

2026-02-16T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:

Notes from Today’s Live Coding Session

Olive Tests = Test List?

Today I realized that the way I use Olive Tests, where the test fails as predicted, as I take small steps to get it to fail in a new, but still expected, way, is very much like Kent Beck’s Test List. However, Instead of spreading the steps across multiple tests, I’m spreading it across multiple assertions and using the idea of an Olive Test to allow me to know when to move forward to get the next assertion to pass.

Concert Started Processor is Doing its Job

When I ran all the tests for the first time since last week, I was initially confused by a test failure that checked available concerts in the sample data, where it found 9 instead of the 10 that the sample data populator creates. It turned out to be the ConcertStartedProcessor that I finished last week was doing its job by stopping ticket sales on one of the sample concert events, and therefore no longer appeared in the list of “available concerts”!

Reschedule Concert Use Case Complete

I finished the UI for “Reschedule Concert” and as is often the case, when I ran the application, it just worked. I did cheat a bit and reused an existing screen by adding a “reschedule” link to the “Concerts” view page, and after a Reschedule Concert is submitted, I redirect back to the Reschedule page instead of creating a new confirmation page. It’s not the way I’d do things if this were a production app, but this is an example learning app—despite its ever-increasing scope—so I’m OK with such shortcuts.

Design Aspects of Command Execution

I really like the way command method invocations are wrapped in a “unit of work”, like this code from the RescheduleConcertController’s POST handler:

@PostMapping("/reschedule/{concertId}")
public String rescheduleConcert(@PathVariable("concertId") String concertId,
                                RescheduleForm rescheduleForm) {
    CommandExecutorFactory commandExecutorFactory = 
            CommandExecutorFactory.create(concertEventStore);

    var command = commandExecutorFactory.wrapWithParams(
            (concert, reschedule) ->
                    concert.rescheduleTo(
                            reschedule.showDateTime(),
                            reschedule.doorsTime()));

    Reschedule rescheduleParams = new Reschedule(
            rescheduleForm.newShowLocalDateTime(),
            rescheduleForm.newDoorsLocalTime());

    command.execute(new ConcertId(UUID.fromString(concertId)),
                    rescheduleParams);

    return "redirect:/reschedule/" + concertId;
}

This code needs to be refactored, but the issue I’m struggling with is where the command creation (which is a stateless command object) would go. I don’t have a general design pattern for this kind of code, usually I have a “service” or “application” layer class that would handle the infrastructure work for multiple different commands. For example, see EnsembleService#joinAsParticipant()) in my Ensembler application. Note that even there I refactored to an “execute around” method (see line 179 in the same file), so that aspect isn’t new to me.

It seems like this controller method should map directly to one of those command objects, requiring some (“service”) class needs to provide a way to get the “Reschedule” command object, which would encapsulate the create() and wrapWithParams() that I’m doing above. Maybe the RescheduleForm would encapsulate the command, since it already has the information needed (new show date/time, etc.). I’ll start playing with some ideas for refactoring this on the next stream.

Deciders vs. Processors

After doing all this event-sourcing work with JitterTicket, I’m starting to get more precise about how I think and talk about the concepts. For example (at timestamp 3:04:50), I describe a Decider as something that takes existing State (projected from a series of events), makes a Decision using the state as input, and outputting an Event. I think of this as a Stateful Decider because it requires the input State in order to make a decision (am I allowing this command to succeed?). I haven’t (yet) come across a Stateless Decider, where the decision doesn’t require existing State, but that’s not to say it couldn’t exist. (If you know of an example, please share it with me!)

It’s possible a command that creates an entity (say, registering a new customer) is a Stateless Decider, but I think of it more explicitly as a Creator. However, if its creation has rules (e.g., customer email must be unique), then State is required (again from some projection, e.g., all active customer emails), so does that make it a Stateful Decider? From an event-sourcing point of view, creation is no different from any other event, so maybe it is?

A Stateless Processor on the other hand, takes an Event as input, and uses that to make a decision, and outputs a Command.

And I guess a Projector takes an event (or stream of events) and outputs a Projection, i.e., State. It might persist the previous state as a cache, but I see that as a Snapshot for optimization, something that Stateful Deciders could do as well, especially since a Stateful Decider is a Projection plus a Decider.

Next Steps

We’ll refactor the Reschedule command object and then create an “All Concert Aggregates” Projector to use when examining the underlying events with the event viewer. We need this because the current event viewer uses the “Available” concerts projection, which drops concerts that we might want to examine.

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

Live Coding Journal - Feb 12, 2026

2026-02-12T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:

Notes from Today’s Live Coding Session

Don’t Use an SDK When a POST Will Do

I spent far too long trying to replace the email service in my Ensembler tool from SendGrid (who started charging even for minimal usage) to Brevo. It was a terrible experience, with inconsistent documentation, a vendor-supplied Java SDK with many problems, a third-party SDK that was overkill, and a support chat LLM that provided completely wrong information. I really should have looked closer at what I needed, because a single HTTP POST would have been sufficient. However, I’m extremely displeased at Brevo’s use of LLM for support chat, since it is well known that they provide wrong answers. It’s likely I’ll try out Postmark (using straight HTTP requests) unless Brevo decides to kick the LLM chatbot off the site—I refuse to support companies that waste my time in that way.

Generics and Lambdas Break My Brain

The main task for the rest of the stream was to expand the use of lambda-based Command Objects for executing command methods against the Concert aggregate. I had a nice wrap method that returned a “unit of work” composed object:

public Command<ConcertId> wrap(Command<Concert> concertCommand) {
    return concertId -> {
        List<ConcertEvent> concertEvents = concertEventStore.eventsForAggregate(concertId);
        Concert concert = Concert.reconstitute(concertEvents);
        concertCommand.execute(concert);
        concertEventStore.save(concert);
    };
}

However, this was only for methods (like .stopTicketSales()) that take no parameters. I wanted to implement the Reschedule Concert command similarly, but it takes two parameters, and it took a surprising amount of time for me to get that working. Around 1:47:42 is when the struggle began and, after a number of false starts, @Suigi comes through (again) and reminds me to revert the lambda I was trying to write into an anonymous inner class. That made everything so much more clear, and was able to get where I wanted:

public CommandWithParams<ConcertId, Reschedule> wrapWithParams(CommandWithParams<Concert, Reschedule> command) {
  return (concertId, reschedule) -> {
    List<ConcertEvent> concertEvents = concertEventStore.eventsForAggregate(concertId);
    Concert concert = Concert.reconstitute(concertEvents);
    command.execute(concert, reschedule);
    concertEventStore.save(concert);
  };
}

I wasn’t ready to ship it yet, because (around 2:28:40) as I was writing a test for the code (a rare code-first episode) I started to realize something was wrong with the unit work of work code wrapping the command, i.e., reconstituting the Concert by loading the events and calling the .reconstitute() static method: if the Concert didn’t exist, we’d try to reconstitute it from an empty list of events! Oops, that won’t work, and, in fact, that’s an important missing validation in the reconstitute() method! I added a quick validation for that:

public static Concert reconstitute(List<ConcertEvent> concertEvents) {
  if (concertEvents.isEmpty()) {
    throw new IllegalArgumentException("Can not reconstitute from an empty list of ConcertEvents.");
  }
  return new Concert(concertEvents);
}

I then updated the code to properly call the event store’s findById() method instead:

public CommandWithParams<ConcertId, Reschedule> wrapWithParams(CommandWithParams<Concert, Reschedule> command) {
  return (concertId, reschedule) -> {
    Concert concert = concertEventStore
            .findById(concertId)
            .orElseThrow(() -> new IllegalArgumentException("Could not find Concert with ID " + concertId));
    command.execute(concert, reschedule);
    concertEventStore.save(concert);
  };
}

Once again, thinking through things to predict how the test would fail revealed a problem even before I had a failing test, but then the test still failed in a different way, which revealed a problem with the test.

One thing I hadn’t realized until I was writing these notes is that I need to go back and fix the no-arg wrap() to also use findById()!

Event Modeling for Reschedule Concert

Around 3:00:30, I do a quick event model for rescheduling concerts, and then decide not to build a completely new UI for it. The list of concerts to display for scheduling is the same as the list of concerts for purchasing, so I decided to just add another button for “reschedule”. Then I did the usual test-driving of a new UI endpoint, though it had been a while since I wrote one of those, so I made some silly mistakes. I ended the stream with an Olive test (fails as expected) that I’ll pick up on the next stream.

Next Steps

For next time, I’ll:

Fix wrap() to use findById()
Finish the Olive test for the reschedule controller
Look at a tool for doing event-modeling?
Maybe figure out in which package the CommandExecutorFactory should live
Generify CommandExecutorFactory so I can use it with the Customer aggregate
And maybe look at how to design aggregate-slices (Deciders) that can leverage the command objects, which might help in converting the PurchaseTicketsUseCase to use the CommandExecutorFactory

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

Live Coding Journal - Feb 11, 2026

2026-02-11T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:

Notes from Today’s Live Coding Session

Today I finished the final piece of the ConcertStartedProcessor where the Concert.stopTicketSales() command method is called as a result of the ScheduledFuture being executed by the ScheduledExecutorService. It took a bit of sketching code to figure out what the types should be for the nested lambdas (you might be amused to find me writing some old skool anonymous inner classes!), which turned out to be very much like defining partial functions. The three levels of nesting of the lambdas didn’t make things any easier.

Command Executor Factory

This is where I ended up with the CommandExecutorFactory, which is a “Unit of Work Composer”:

The outermost lambda is the Runnable that is passed to the ScheduledExecutorService when scheduling the “alarm” that will be executed at the concert’s show date and time.
The next level is the “infrastructure” or “unit of work” wrapper that does the work of loading the Concert aggregate from the event store, calling the inner lambda, and the persisting any changes back to the event store.
The innermost level is the command method, in this case the literal method handle Concert::stopTicketSales.

And this is what it looks like in the code when creating one of these wrappers for testing purposes:

// create the factory configured with the event store for Concerts
CommandExecutorFactory factory = CommandExecutorFactory.create(concertEventStore);
// create the innermost lambda that executes the desired command method on Concert
Command<Concert> command = Concert::stopTicketSales;
// ask the factory to wrap (compose) the method-level command with the infrastructure handling code
Command<ConcertId> commandExecutor = factory.wrap(command);

Now, when I want to wrap any Concert command method that needs the infrastructure to handle persistence, everything is the same except for the innermost Command<Concert>.

This is what the ConcertStartedProcessor does when scheduling that command in the scheduleAlarm method:

ScheduledFuture<?> scheduledFuture = scheduledExecutorService
        .schedule(() -> commandExecutorFactory
                          .wrap(Concert::stopTicketSales)
                          .execute(concertId),
                  delayFromNowInMinutes(showDateTime),
                  TimeUnit.MINUTES
        );

where that first parameter is the outermost lambda—a Runnable—that will invoke the unit of work to stop ticket sales.

I still have work to do to generalize this command-method invocation, because stopTicketSales doesn’t take any parameters, but the other command methods (e.g., schedule, reschedule) need at least a couple of parameters. I’ll also need to deal with the different unit of work around command methods that do “creation” of the aggregate, e.g., Concert.schedule() and Customer.register(), since neither one has an aggregate to load from persistence (they still need to save, of course).

Tedbits

After some weirdness with resetting the database so I could create sample data that would demonstrate that the scheduled futures actually get executed, I was able to see the processor doing its job, because a concert that started 10 seconds after the application started no longer appeared in the “Available Concerts” projection. This was actually a problem because my event viewer for Concerts was using the same projection! Oops, I’ll have to create another projection that has all Concerts ever scheduled. Luckily they’re straightforward to write now that the infrastructure wrapper for them (the ProjectionCoordinator) exists.

We had some good side discussions about James Shore’s “Nullables” and how they might seem to violate the “don’t put test code in production code” rule. As I said on the stream:

“The reason why you want to put these creation methods in the production code is the production code knows more about what it needs [and what its dependencies need] and is more resilient in the face of refactorings.”

Next Steps

Besides the new projection for all Concerts, and the further generalization of the CommandExecutorFactory, I want to add a UI for both the Schedule Concert and Reschedule Concert use cases. I hadn’t needed them when my focus was on figuring out Event-Sourcing, but it’ll be good to get the entire process implemented to see where I might have holes in the implementation. (This is the downside of doing inside-out development, you don’t know what might be needed by the outer layers of the application until they’re implemented.)

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

Live Coding Journal - Feb 10, 2026

2026-02-10T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:

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.

Live Coding Journal - Feb 9, 2026

2026-02-09T10:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:
- Feb 4th, 2026
- Feb 5th, 2026

Notes from Today’s Live Coding Session

Aggregates, Deciders, and Projections

I continued to refine my mental model around Aggregates as a bundle of related Deciders that use an internal Projection to use as the input state to the domain logic when executing a Command. For example, when the Concert aggregate is loaded, it replays all events having to do with that specific aggregate (scheduled, rescheduled, tickets sold, ticket sales stopped), even if the Command being executed (say, rescheduling) only needs part of the Concert’s state, e.g., just the Show Date & Time. We could break down the Aggregate into Deciders, which have the minimal state needed to make the decision, which therefore means playing back (processing) fewer events. As a long time DDD and OOP developer, I’m not sure I’d like having to handle Deciders as more granular objects, but I’ll experiment with it at some point to explore how it feels.

Processor vs. Aggregate (Decider)

I’m still trying to figure out the heuristic for when to use a Processor to execute a Command (and therefore generate an Event) vs. using the Aggregate to handle the decision-making and generate the Event. It feels similar to Domain Services vs. Aggregates in that Domain Services are used when state from multiple Aggregates is needed to make a decision, or the state change affects multiple Aggregates. It’s still unclear to me how I would implement the functionality of refunding tickets to all customers that purchased tickets to a Concert that was then canceled. It could certainly be done with the Use Case (or Command Object, see below), but I could also see it being done with a Processor, especially since it doesn’t have to be done synchronously with the cancellation process.

Two Types of Projections?

After thinking about Processors vs. Aggregates (around the 12-minute mark in the video), it really seems like there are two types of Projections: those that are used as “read (only) models”, e.g., for reporting or display on a UI, and those that are used as input state for automated decision-making, i.e., for Processors. It also led me to think about Processors that make decisions solely on the input Event, which turns out to be what some folks call “Translators”. I think it’s really useful to separate those two, as Processors need the Projections as “accumulated state”, whereas Translators are truly functional and require no state.

Use Case vs. Command Object

I’ve been implementing the Application-level Use Cases as stateless service objects, but when I started thinking about the implementation for the next use case (around the 2h56m mark in the video), stopping ticket sales, I realized that the structure of that code follows the same pattern:

Load the Concert Aggregate from the Concert Event Store.
Invoke the Command method on the Concert
Have the Concert Event Store persist the generated Events (if any).

Creating a Command class that follows the Composite pattern where it takes the event store and the Concert ID would be very handy. I also decided that a Command Factory configured with the Event Store would make it easier to create Commands for a specific Concert, as I wouldn’t have to pass the Event Store each time I want a Command. It also means fewer generics to deal with for the Command itself.

ConcertStartedProcessor

I made good progress on the ConcertStartedProcessor, test-driving the implementation step-by-step, handling a new event each time around the TDD loop. I also implemented ignoring Concerts that had a Show Date & Time in the past, as there’s no reason to track them as they’ve already happened. The refactoring along the way was interesting, because I went from an ugly if block to a switch statement, then to a switch expression, but then back to a switch statement as I fleshed out the events that it handles. At the end of the refactoring, I noticed that I had two methods:

private void cancelAlarm(ConcertId concertId) {
    alarmMap.remove(concertId);
}

private void scheduleAlarm(ConcertId concertId, LocalDateTime showDateTime) {
    if (showDateTime.isAfter(LocalDateTime.now())) {
        alarmMap.put(concertId, showDateTime);
    }
}

This triggered my mental “Primitive Obsession” heuristic, because both methods (which are command methods) take the same parameter, ConcertId. Any time I see a pattern like that, I consider creating a wrapper object that encapsulates the parameter and provides those command methods on the new object. Something like ConcertAlarm.scheduled(LocalDateTime showDateTime) and ConcertAlarm.cancel() are what I’d want instead.

I didn’t do that refactoring, because I already had in mind a ConcertAlarm class, but I’m not yet sure what else it would contain, so I’ll delay the refactoring until I know more.

Precursor to Primitive Obsession

When multiple methods take the same parameter, that’s a sign that there you’re missing a wrapper object that encapsulates the parameter and provides those methods.

I talk about this in-depth in my online presentation “Stop Obsessing About Primitives”

Next Steps

In my next live coding stream, I’ll dig into the actual scheduling of the alarms, using Java’s ScheduledExecutorService. I still need to figure out the right “seam” for separating the I/O (which are the ScheduledFutures) from the processor logic.

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

Live Coding Journal - Feb 5, 2026

2026-02-05T12:00:00Z

All the code I’m working on in my live coding stream is available at https://github.com/jitterted/jitterticket-event-sourced.
Notes from previous streams:
- Feb 4th, 2026

Notes from Today’s Live Coding Session

Pumpkins

Today I introduced the idea of saying the word “pumpkin” during my stream so that when I write these notes, I can easily search through the text transcription of the stream for all instances of where I say “pumpkin”. This way, when I have an aha moment, or mention something I want to note here, including mistakes, learnings, etc., I can easily find them by searching for “pumpkin” as the marker or anchor. I loved this so much, I’m now calling these highlights “pumpkins”. So, enjoy today’s pumpkins!

Testing A Tiny Feature the Wrong Way

At around the 1-hour mark, I was working on adding a small feature to the Concert aggregate, where I could stop ticket sales for the concert by calling a command method stopTicketSales(). However, I temporarily forgot that I was using event-sourcing, so when I wrote the test like this:

@Test
void stopTicketSalesGeneratesTicketSalesStopped() {
    Concert concert = ConcertFactory.createConcert();

    concert.stopTicketSales();

    assertThat(concert.canSellTickets())
            .isFalse();
}

and was about to start writing the code to make it pass, I realized I was testing the non-event-sourced way! (And that’s despite the fact that the test name specifically says the event I expect to be generated!) Sigh. I quickly realized my mistake and changed the assertion to check that the TicketSalesStopped was generated:

@Test
void stopTicketSalesGeneratesTicketSalesStopped() {
    Concert concert = ConcertFactory.createConcert();

    concert.stopTicketSales();

    assertThat(concert.uncommittedEvents())
            .containsExactly(
                    new TicketSalesStopped(concert.getId(), null));
}

I predicted that the test would fail because I didn’t write the code to generate the event yet, but it failed for the wrong reason! Once again, “calling my shot” (predicting precisely how the test would fail) saved me from a bad test.

TDD Prediction Principle:

It’s not good enough to just have a failing test, it has to fail for precisely the right reason, i.e., because the code doesn’t implement the behavior that you want to add, not because of some other problem (such as the wrong test setup or a misunderstanding of the codebase’s current behavior).

The problem here is that the ConcertFactory.createConcert() helper method creates an unsaved Concert object, which means that when I check the uncommittedEvents(), it isn’t empty, but instead has the ConcertScheduled event. Oops. Changing the test setup to create a “reconstituted” Concert object fixed the problem:

@Test
void stopTicketSalesGeneratesTicketSalesStopped() {
    Concert concert = Concert.reconstitute(
            List.of(
                    ConcertFactory.Events.scheduledConcert()
            ));

    concert.stopTicketSales();

    assertThat(concert.uncommittedEvents())
            .containsExactly(
                    new TicketSalesStopped(concert.getId(), null));
}

Lesson Learned: The test setup and assertions for the events is still a bit clunky, despite the factory methods and builders that I have. At some point I need to move to a higher level of abstraction for the setup and assertions. One way to go is to use strings to describe the events, but that loses compile-time safety, and more importantly, doesn’t let me auto-complete. Likely the next thing I try is some nested builders, but I need to do more experimentation to find the right structure that helps with autocomplete, but is also readable.

Red Test Does Not Mean New Test

Something I often talk about in my TDD courses (as well as on my stream) is that the “red” (failing test) in “Red-Green-Refactor” (the high-level TDD cycle) doesn’t require a new test. In fact, probably 20–30% of the time, my first failing test is a modification of an existing test that is currently passing.

I think most often this happens when I’m adding functionality to a class, like when I added the ability to stop ticket sales to the Concert aggregate. Before I could implement the functionality of stopping the ticket sales, I had to make sure that the behavior for a new Concert was that ticket sales were allowed. I didn’t need a new test, I already had the concertScheduledUpdatesConcertDetails() test, so I just needed to add an assertion to check that the canSellTickets() method returned true. (This was technically the “zero” case in the Zero/One/Many guideline, aka ZOMBIES.)

Feature Envy Trap

After I added the stopTicketSales() method, and the internal canSellTickets boolean, I realized that I had a code smell heuristic that I hadn’t articulated before (around the 1h33m point):

Precursor to Feature Envy Heuristic

If an entity has state that it’s not using internally to make decisions, then why is it holding onto that state? If it’s only exposing it and not using it, that’s just ripe for future feature envy, where a client of the entity uses that information to make a decision.

Resolution: either the entity needs to use that state internally, or it should be removed (or moved) to an entity that needs it to make a decision.

Once I noticed this (awareness of these things is 90% of the battle!), I realized I was missing a necessary business rule where if tickets sales were stopped, we should not allow the sellTickets() command method to succeed. (I decided not to implement that yet, since I wanted to get to the core of the Concert Sales Processor.)

Who’s Job Is It? Processor vs. Aggregate

My main goal for today’s stream was to build my first Event Sourced Processor and had chosen the idea of a separate “Processor” whose job was to track ticket sales. When a concert sells its last ticket, the processor would invoke the stopTicketSales() command on the Concert aggregate. After some back-and-forth thinking out loud and discussion with the stream viewers (thanks chillMute!), I realized that I was about to design a Processor that needed information that the Concert aggregate already had! Concert already knows about ticket sales and precisely when the last ticket is sold (via the sellTickets() command method).

I admit to being a bit disappointed that there was no need for the “Concert Sold Out Processor”, but I’m still learning about this aspect of Event Sourcing, and the discussion of “who’s responsible” was really useful. Luckily, I already had other Processors that I wanted to implement.

We dug into the details of the “Concert Started Processor”, which would be responsible for tracking when a concert starts (based on its Show Date/Time), and invoke stopTicketSales() on Concert when that time comes around. Figuring out how to implement this took us down a few dead-ends (e.g., Spring’s scheduling support was not the right mechanism), and ended up deciding to use Java’s built-in ScheduledExecutorService to schedule the stopping of ticket sales along with a Map<ConcertId, ScheduledFuture> to keep track of the concerts (so we can reschedule the futures if the concert itself gets rescheduled). It’s annoying that ScheduledExecutorService doesn’t have an easy way to specify a specific date/time to execute the task (it requires a duration from “now”), but it’s just a bit of simple date math to figure this out.

Next Steps

We ended with a failing test for the new ConcertStartedProcessor, and a design plan for how it’ll probably be implemented, along with a few tests (a Test List!) that we’ll start with.

I hope you’ll join me on my next stream, usually starting at 20:00 UTC on Monday thru Thursday on Twitch: https://jitterted.stream.

Live Coding Journal - Feb 4, 2026

2026-02-04T12:00:00Z

Notes from Today’s Live Coding Session

I’m back from vacation and resumed my live coding streams where I’m working on “JitterTicket”, an example Event Sourcing application in the Concert Ticketing domain. (Code is at https://github.com/jitterted/jitterticket-event-sourced.)

I’ve been working on the “available concerts” projection, which is used (as a read model) to show customers what concerts are available for ticket purchase. Before my vacation, we decided on a new event, “ConcertCompleted” that would stop ticket sales. Today I decided that this event name was too broad, so instead used TicketSalesStopped. The creation of that event was mostly mechanical, especially since it doesn’t need anything other than the Concert ID (which is already inherited from the base ConcertEvent).

I’m glad I did the work manually (instead of letting the Junie LLM do the work) as I discovered some weirdness with creating an otherwise “empty” event class. (Mostly on code-generating the equals and hashcode.)

I was also taking notes on the process so that in the future, I can create a code generator (no point in using an LLM for something that’s basically a template) for adding new events, since there’s more than just the event classes that need to be created.

Adding the new event was a straightforward TDD process, though the first “failing test” was a “fail to compile” due to the pattern-matching switch statements that I use. It had been a while since the last time I added a new event and forgot that I had JSON round-trip tests, which failed—thankfully! Adding the new event and the appropriate Jackson “mix in” classes was also mechanical.

Once the event itself was in place, it was time to update the “Available Concerts” projector to drop concerts from the projection when it sees a “TicketSalesStopped” event.

Since I was doing bottom-up development, i.e., creating the event first, and then adding behavior elsewhere, I decided not to modify Concert (the aggregate generating the TicketSalesStopped event and having a “canSellTickets” state), as I wanted to focus on the projection first.

Side note: Every time I think about a boolean state, I’m always thinking, is this really a boolean, or is it really a state machine with multiple states? Or maybe it’s an effective timestamp? I’ll have to write that up at some point.

With the event work done, I moved on to the first new (failing!) test of the projector (which is so easy to test as it’s stateless code): If there’s already a concert available in the projection (cache), stopping ticket sales removes it, leaving the Available Concerts empty.

The code for that was easy, but then things got tricky as I had to handle the catch-up projection scenario, where ConcertScheduled and TicketSalesStopped already happened for a concert, so the projection needs to just ignore that concert. What makes this complicated is the projector produces two results: a new projection cache as well as a “delta”, which is used for persistence and split into upserts & deletes.

Before the TicketSalesStopped event came on the scene, I didn’t worry about deletions, but also internally tracked inserts and updates in a single upserts map. However, I couldn’t tell when to put a concert into the “deletions” list because Scheduled and Rescheduled looked alike.

They’re not! If I see a Scheduled+TicketSalesStopped in the list of events being handled, it’s a no-op (cache remains the same, delta is empty). A Rescheduled+Stopped, however, is a deletion (because a Scheduled already happened some time in the past).

I ended up doing a refactor to split the internal upsert map into two lists to track inserts (Scheduled) and updates (Rescheduled) separately. I got the tests to continue passing, but it was clear that lists were the wrong data structure, so replaced them with maps (much nicer).

I’m pretty happy with my current design of the Projectors as it made tests relatively easy to write. I am feeling the pain of generating the stream of test events, so that’s something I’ll focus on once I work on the last component of the app: Processors.

I stream for 3–4 hours starting at 20:00 UTC on Monday thru Thursday, unless I’m at a conference or otherwise occupied, so I hope you’ll tune in at https://jitterted.stream to watch, help me out, ask questions, or even heckle.

What Project Should I Work On?

2024-07-09T10:00:00Z

Improving Your Skills

Just about every week on my live-coding stream, I get asked “how do I learn Java/Spring Boot/etc.”? Often this is asked by someone relatively new to coding, but I also hear it from experienced folks who are unsure how to learn something new. For example, they’re good at Python, but now want to learn Java and Spring Boot.

My response is always: work on a Learning Project.

Learning Projects

Q: What is a Learning Project?

A: It’s a project that starts very small and is one you will add to over time (not a “one and done”).

I coach lots of developers where you’ll learn skills as they come up as needed by what you want the application to do.

If possible, make it useful for you or your family. That way you’ll be motivated to work on it and get real-world feedback for things to change/add.
Focus on interesting BEHAVIOR. Why “behavior”? Well, it depends on what kinda of work you like, but for me, I like rich and interesting domains (hence my fondness for domain-driven design), vs. just integrating things (valuable for sure!). Some projects are just about data, which is a good start, but doesn’t build up skills in working on code that’s at the core of complex business (or game or industrial) processes.

For that, you need something “meaty”. Writing a To-Do app? That’s fine! But what can it do for you? Do you want it to remind you of things as well? I know I heavily rely on reminders. That’ll pull in the (dreaded) Date and Time aspects (how will you test that??).

Dependencies between items? Or things that you do in one place (like shopping)? Hey, a shopping list! A shopping list organized by grocery aisle! Maybe there are certain items you buy on a regular basis, that’s behavior, too.

There’s a whole class of “bespoke” or just-for-you apps waiting to be written. It’s only for you, so only needs to satisfy you. I created a whole app that just manages my son’s virtual “piggy bank” (cuz we were tired of scraps of paper and a spreadsheet that wasn’t easy to use on the phone). I learned so much by creating that. And 4+ years later, it’s STILL running and being used.

Change One Thing

See https://twitter.com/kchironis/status/1569108508507009025

Mash Up

My take:

Great advice! Also applies to learning coding in general: take that tutorial you just followed and change one thing. Then another thing. Add something personal or funny. Invert/reverse what the thing does. Make it your own. Mash up two tutorials (tic-tac-toe + to-do list?).

Playing to Learn Predictive TDD

2024-02-20T10:00:00Z

Playing the Game

The Video

On the Agile Lunch & Learn channel, I gave a talk about “Predictive” Test-Driven Development as an introduction to JitterTed’s TDD Game. I describe Predictive TDD, give a bit of history of the game, and then demonstrate playing the game itself.

Thanks to Mark Shead and the AgileLnL community for hosting me!

https://www.youtube.com/live/P8eRY2c8NFY

Download the Slides

Click here to download the slides from the presentation.

Discuss

Want to talk about the presentation, TDD, or the game? Have questions? Join us on the Discord.

Your Classes are Too Big (Talk)

2023-05-30T19:00:00Z

Slide from the Primitive Obsession presentation

The Video

Recently at the Seattle Software Crafters meetup (remote), I gave a new version of my talk on Primitive Obsession. I show how you can easily (almost mechanically) split your large classes by identifying where it’s suffering from Primitive Obsession.

Thanks to Steve Kuo, Paige Watson and the Seattle Software Crafters community for hosting me and asking great questions!

https://youtu.be/hcx6DUjU24A

Download the Slides

Click here to download the slides from the presentation.

Discuss

Want to talk about the presentation? Have questions? Join us on the Discord.

Make sure to sign up for my newsletter (see below), so you don’t miss future Ted Talks!

I'm Done with Unit and Integration Tests

2023-04-02T10:00:00Z

Does 'No' sound good to you?

I’m Done with Unit and Integration Tests

I’ve been writing developer tests for a very long time. Lately, I’ve been reflecting on the types of tests I write, and why some are easier than others. When teaching and coaching others how to write tests, I almost always explain what I mean by “Unit Tests” and “Integration Tests”: Unit Tests don’t touch hardware, don’t do I/O, etc.^[1], and test against a single object or group of objects^[2]. I’d then demonstrate what I meant, like this:

@Test
public void fullDeckHas52Cards() {
    Deck deck = new Deck();

    assertThat(deck.size())
            .isEqualTo(52);
}

@Test
public void drawCardFromDeckReducesDeckSizeByOne() {
    Deck deck = new Deck();

    deck.draw();

    assertThat(deck.size())
            .isEqualTo(51);
}

These are both “unit” tests (neither touch hardware nor do I/O) and are Solitary (the tests only reference the Deck class).

Later on, we’d need to write tests against code that may do I/O, often a database or an external service (usually over the network). I’d explain that those were “Integration Tests”, because we were integrating our code with someone else’s code (the database code or the other service’s code) through I/O. However, calling someone else’s code that’s supplied as a library (e.g., a JAR file) that doesn’t do I/O (such as Caffeine, a caching library) can also be considered integration. Even using Java’s Collection classes (e.g., ArrayList) is using someone else’s code, though we don’t usually think of that as integration.

Hard to Redefine Terms With Lots of Baggage

Over the past few years, I’ve become more frustrated with the terms “unit” and “integration” because:

I have to explain what Unit and Integration mean before I can use them
Everyone has their own internal definition of what they mean, which is often different from mine and other folks in the room
Differences in definitions often led to long discussions^[3] that aren’t useful
Folks don’t remember how I define it, and fall back to their own definitions

I finally decided to do something about it, and come up with different names. But first, I had to answer the question: why does it matter? What about Unit (doesn’t do I/O) and Integration (may do I/O?) is important for the way I approach development?

No I/O = Predictable & Fast

If you create an object, and call a method that only accesses internal properties (fields) and any parameters to the method, it must be predictable. Any logic or calculations the code is doing is deterministic. What makes code not predictable? I/O. Accessing a file is unpredictable, because the file could’ve changed without you knowing, the drive could fail intermittently, could be out of space, etc. Accessing a remote service involves not only the network (unreliable), but also the remote service (unpredictable). I include access to anything outside of memory, such as random number generation and the current date & time as I/O, because they are also unpredictable. By eliminating all I/O, you make the code under test, and therefore the test, deterministic.

Not accessing I/O also means your tests will run extremely fast^[4], with most of the time spent getting the tests ready to run: compiling, starting, etc. Everything else, from instantiating objects to running the code, is almost instantaneous. There’s no reason you can’t have many thousands of tests run in a few seconds. By the way, this speed is critical for doing test-driven development, which is why I focus on these kinds of tests.

Now when it comes to code that does interact with the outside world, such as getting the current date & time, or fetching information from a database or external service, I still want tests that don’t do I/O. This is where Test Doubles come into play. In Hexagonal Architecture, that might mean a Stub or a Fake in place of a concrete Adapter, or I might use Nullable Infrastructure Wrappers, which is Stub-like implementation embedded in your production code.

The idea is that we’re still not touching I/O, so everything is still Predictable & Fast. These are a form of Sociable tests, where we’re testing a larger set of collaborating classes, but explicitly not testing the I/O itself.

I want 80-90% of my tests to be these kinds of tests. Of course, it’ll vary widely depending on how much your system is doing things vs. integrating with other things.

I/O = Unpredictable & Slower

At some point, though, you want to have some sort of test that touches I/O. Things like:

Check the database schema is valid
Ensure the ORM can read and write from the database and create well-formed objects
Call an external service API and ensure you get a valid response

These are hard to write, because, like I said, they’re unpredictable. Databases are often managed (“owned/defined”) by the application, so those can use tools like Docker and Testcontainers to allow your tests to use real databases. They’re slower, but you won’t be running them nearly as often as the other tests.

When it comes to calling external services, if it’s a service that you can run inside a container (maybe it’s Kafka, or it’s a custom service created by another team that provides an executable), then you can do the same thing as with the database above. But if it’s a public service (like GitHub or Google), or any service that you can’t run locally or in a container, you’re not going to be able to run automated tests that are predictable. Yes, you could run against a “sandbox” environment, but for me that falls under “unpredictable” based on my experiences (maybe yours work better?). So, if I write these tests, I run them manually, or have other ways of checking that my code works (like good monitoring and observability in production).

Naming Attempts

Naming is hard, as we all know. Trying to find a name that is descriptive and memorable, but with little or no baggage, is quite a task.

First Attempt

During a discussion of the problem with Willem Larsen, he proposed using words from a different language (e.g., Japanese) for the same terms (or at least what they meant to me). However, not being able to speak Japanese, I had to rely on less than perfect translation systems. Not only did I want to find a word or phrase that had the intent I wanted, but it also had to be relatively short. For months, I played with different translations, but wasn’t happy with the results, so I shelved the idea.

Pure and Impure

In Functional Programming, the terms “Pure” and “Impure” have somewhat similar meanings to my usage of “Unit” and “Integration”. In FP, a pure function is a function that doesn’t cause any side effects, and always produces the same output for a given input. I tried using this terminology for a while, but it had two problems:

I still had to define “pure” as not accessing I/O
I got objections from FP folks, because of the misuse of the term “pure” in the context of testing stateful object-oriented code (methods accessing internal state could never be “pure”)

Honestly, #1 was the more annoying aspect for me, though it did have the benefit of not coming with much baggage (except for folks familiar with FP).

I do use the term “purify” when I’m talking about the process of separating the I/O code from the logic, e.g., “let’s purify this code, making it I/O-Free”.

I/O-Free and I/O-Dependent

So here we are. The two main kinds of tests I write. The majority are I/O-Free tests, and when I hit the I/O boundary and need to test against some real external service, I use I/O-Dependent tests (or I/O-Based).

I further split I/O-Free tests into Domain, Application, and other buckets, depending on the application architecture (e.g., Domain tests never have Test Doubles), but that’s another article.

What do you think? Let me know on my Discord, on Mastodon, or on Twitter.

This should sound familiar to some of you, as it’s the same idea as the set of unit testing rules by Michael Feathers written in 2005. ↩︎
I use the terms Sociable and Solitary to differentiate between the different kinds of “unit” tests, as defined by Jay Fields in Working Effectively with Unit Tests, with an excerpt found here. ↩︎
If I have one more debate over what “unit” means, I’m gonna scream. It’s especially annoying, since I don’t think defining a “unit” is a useful exercise. ↩︎
Yes, there is code that performs lengthy calculations that run completely in memory, but I’m not talking about that. ↩︎

More Testable Code with Hexagonal Architecture (Talk)

2023-02-21T10:00:00Z

Slide from the presentation

The Video

Recently at PhillyXP (remote), I gave an updated version of my talk on how Hexagonal Architecture—primarily its separation of concerns—helps make code more testable. If you’ve seen past versions of this, you’ll want to see this one. I’ve shifted the focus a bit to focus more on tests and what we want out of them. I’m also using my new language for describing tests: I/O-Free Tests (sometimes known as unit tests) and I/O Tests (sometimes matches what people call integration tests). I’ll be writing more about the difference, because I think we often get too hung up on “what’s a unit?” instead of “what kind of test would be useful here?”

Thanks to Anthony and the PhillyXP community for hosting me and asking great questions!

https://youtu.be/NLCp_fUrqf8

The Course

There’s only so much I can fit in an hour or so, and so I built a 15+ hour course that dives deep into all aspects of making code more testable and refactoring to Hexagonal Architecture. Sign up here to find out when the course is on sale again.

Download the Slides

Click here to download the slides from the presentation.

Discuss

Want to talk about the presentation? Have questions? Join us on the Discord.

Top Five "Forever" Books for Coders

2022-09-07T10:00:00Z

Introduction

On my live coding stream, the question often comes up: “what books would you recommend?” about various topics. Since it’s such a common question, I decided to set aside time on my stream to pull together my recommendations and discuss them with my viewers. At first, I was going to write one of those standard “Top 10” lists, but I realized my recommendations are more nuanced than that (and that I have way more than 10 that I want to mention), so I’m dividing the “top” list into several, more focused lists. As we were discussing the book candidates on the stream, I realized there are “classics” that I think are required reading for any coder who wants to really step up their ability to write more maintainable and testable code, so those are the books in this first list: the “Forever” Books.

This list has books that have been around for 15-20 years and will likely apply for 15-20 more. They came out during the “golden” period of 1995-2005 when Design Patterns, Refactoring, and eXtreme Programming (XP) broke through and started becoming well-known. Future lists will cover more recent books on developer testing, object-oriented design, and tech-specific books (e.g., Java, Spring framework, etc.).

How to Read

Instead of just listing the books, I provide a recommendation on how I’d read the book, since some of them, like the 883-page xUnit Test Patterns book, are quite large (and heavy if you have the physical book), and you don’t need to read every page. Even if they’re not that long, not all of these books are meant to be read cover-to-cover and serve as cookbook-like references. These books also have quite a bit of code and I tend to skip over most of that on my first read-through. Unlike most people it seems, I actually enjoy reading the Preface and Introduction chapters of books and since they often provide their own “how to read this book” advice, it’s worth taking the extra time to read.

If you can, read these books as part of a Study Group. I was lucky to be part of a group (the Silicon Valley Patterns Group) that met weekly to discuss these books (and many more), chapter by chapter, and followed the patterns described here. We were also lucky enough to get access to the in-progress books (such as WELC and DDD) and provide feedback to the authors.

Disclaimer

This list has affiliate links where I might make a few cents on your purchase, but in addition to the typical Amazon links, I’ve included links (IndieBound) that would help support local and independent bookstores, without which the world would be a poorer place. You can also buy from indie bookstores online by following the link to BookShop.

The Forever List

And now, on to the list! These are my Top 5 “forever” (aka “classic”) books that I strongly recommend folks buy and have on their shelf. They are not in any particular order, so I’m not numbering them. Except for eXtreme Programming eXplained, they’re not books that are meant to be read linearly all the way through, but contain a catalog of recipes to be slowly learned over time.

“Working Effectively with Legacy Code” by Michael Feathers

This is the book that most people reference when discussing dealing with legacy code, which, let’s be honest, is probably all of us. Usually referred to by the initialism WELC.

Read Chapters 1-4
Skip Chapter 5 (Tools)
Read Chapter 6 (I Don’t Have Much Time and I Have to Change It)
Skim the rest of the book, that way you’re aware of techniques to use when you run into those situations. Or maybe you’re already in those situations? If so, read on!

Buy WELC on IndieBound Buy WELC on Amazon

“xUnit Test Patterns” by Gerard Meszaros

This book’s subtitle is “Refactoring Test Code”, but I think it’s much more than that, as it got me to really think about how I write and structure automated tests.

Read Introduction through Chapter 6. No really, read the Introduction.
Skip Chapter 7 if you know JUnit/xUnit etc.
Skip Chapters 8, 9 on Fixture Management – I don’t think it’s as important as other chapters.
Read Chapter 10 for how to verify (assert) – you might be surprised what you learn from this chapter.
Read Chapter 11 at least twice(!) about “Test Doubles”
- Forget everything you knew about mocks and learn this terminology.
- Eventually this will become second-nature, but if you overuse mocks in your current codebases, learning the different kinds of Test Doubles will help you wean off of them.
Skip Chapters 12-14, unless you’re really not sure how to organize your tests. Not that it’s not important, it’s more that this isn’t the main problem that I see in teams that I coach and train.
Skim the rest of the Chapters for Test Code Smells (Chapter 15ff) and Test Strategy Patterns (Chapter 18ff).

Buy xUnit on IndieBound Buy xUnit on Amazon

“Refactoring: Improving the Design of Existing Code” by Martin Fowler

There are two editions of this book: the First Edition, from 1999, uses Java, whereas the Second Edition came out in 2018 and switched to JavaScript for the code examples (as well as being tailored towards JavaScript idioms, such as using function instead of method). There are obviously more significant changes than just the code, as described by Martin here.

So which edition to buy? If you’re not a Java developer, then the Second Edition is what you want. However, if you are a Java developer, then maybe both? The First Edition is available used for around US$15-20 used, and the Second Edition is about US$30, so I don’t think that’s too much to spend on one of the most valuable books you can get. The First Edition is nice to have available to see the refactorings in a more familiar language, and the Second Edition has improved and updated the “code smells” and principles text.

Read Chapters 1, 2
Skim Chapter 3 (identifies code smells)
Can skip Chapter 4 (Test)
Skim through the list of Refactorings (Chapter 6 through to the end) – this is the refactoring “catalog”

Buy Refactoring 1st Edition on Biblio Buy Refactoring 1st Edition on Amazon

Buy Refactoring 2nd Edition on IndieBound Buy Refactoring 2nd Edition on Amazon

“Domain-Driven Design” by Eric Evans

I use the patterns and the principles from this book all the time. If you’ve ever heard me speak in person or on stream, you’ll hear me use terms such as “ubiquitous language” and “context boundary” and “repository pattern” quite a bit. This is not the easiest book to understand, not because it’s poorly written, but because there’s a lot packed into it, and it’s written in a certain Pattern Language style that can take a bit of getting used to. The main point that you should take away is thinking about your applications Domain First (what should the system be doing) instead of Data[base] First (what data are we keeping track of). The more you try to use these concepts and patterns, the more you’ll start to see ways of applying them – it’s a virtuous cycle.

Read all the way through
On your second read-through, start with Part IV “Strategic Design” and work your way, Part by Part towards the beginning of the book.

Buy Domain-Driven Design on IndieBound Buy Domain-Driven Design on Amazon

5. “eXtreme Programming Explained” by Kent Beck

This book (also known as XP Explained) had such a huge impact on the way I, and soon enough the teams I worked with, developed software. The idea of pair programming was mind-blowing for me, and the emphasis on developer testing, something I was doing anyway, was reassuring. The flattening of the “Cost of Change” curve was also surprising as it went against what I had learned about project management of software development projects: earlier is better, later is badder. That assumption is wrong and is the cause of premature flexibility (You Ain’t Gonna Need It, aka YAGNI) that makes software less flexible rather than more.

Note: The links are for the 2nd Edition, which is almost a full rewrite of the 1st, but retains the overall thrust of XP:

XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine.

Read the whole thing
Discuss with your colleagues
Read it again
Repeat on a regular basis

Buy eXtreme Programming Explained 2nd Ed. on IndieBound Buy eXtreme Programming Explained 2nd Ed. on Amazon

Event Bus: Inside or Outside the Hexagon?

2022-07-29T10:00:00Z

Hexagonal Architecture: The Hexagon

Q. In Hexagonal Architecture, where does a Message/Event Bus belong?

A. It depends! (Because of course it does.)

In Hexagonal Architecture, we can often rely on the question of: “does it do I/O to support its work or run out-of-process?” If not, then it can live inside the Hexagon, otherwise it’s on the outside (in adapters). Note that you need to include all of its dependencies when answering this question.

Examples

In-Process EventBus

You want to use a library to do lightweight Domain Events publishing. The code is in a single EventBus Jar^[1], and it doesn’t do any I/O, nor any out-of-process communication. All events are “broadcast” to listeners by calling methods defined in a Listener interface (aka the Observer Pattern) as they happen. As long as it is easy to instantiate and Test-Double the EventBus (for testability, of course!), then it can go inside the Hexagon.

Spring Framework’s Event Publisher

You want to take advantage of Spring’s Application Event support. In order to publish an event, you need a reference to an ApplicationEventPublisher, which is in Spring’s context module. This brings in the Spring Framework as a dependency, and, well, that means it cannot go inside the Hexagon.

Async Job Runner

What about JobRunr? It’s a dedicated library for running jobs asynchronously, on a regular schedule, etc. Usually you would use it with a real database (for persistence and potential scaling), but you can run it with an InMemoryStorageProvider. Technically, you might be able to run it within the Hexagon, but it’s complex enough—and deals with concurrency/threads—that I’d push it outside the Hexagon. I’d use an Outbound Port to initiate scheduling jobs, and an Inbound Adapter to handle execution of scheduled jobs. Since a mere configuration change could cause it to depend on a real database, that would completely eliminate it from running inside the Hexagon.

Note: Guava’s EventBus is now recommended not to be used. I found this out when I was looking at using an in-memory/in-process event bus. See the EventBus API page for details. ↩︎

Removing a Feature is a Change in Behavior

2022-07-21T10:00:00Z

On my Discord, @Oye recently asked about removing a feature from a codebase using Test-Driven Development (TDD). I love this question, because it hits the heart of one of the misunderstandings about that I see:

TDD is only good for adding features by adding new, failing tests and adding code to make them pass.

In fact, TDD is great for making any behavior change in your code. Adding and removing behavior are all changes.

If you’ve read my article on Clarifying the Goal of Behavior Change, you’ll see that the first thing I do when starting my TDD process is define:

What should the application do?
How will you know it did it?

When removing behavior, you can negate these statements:

What does it currently do that it should stop doing?
How will you know it’s no longer doing it?

But really, it’s the same thing!

For example, if your application currently shows an option to “ship today”, but the business says that’s too expensive (and unlikely to be solved soon), it needs to go. The next step is to answer those two questions:

It should stop showing the “Ship Today” option.
The test against the UI or API should ensure “Ship Today” doesn’t show up.

If you TDD’d the original implementation, then there should be a test that was written when the “Ship Today” option was first added. Go into that test, and instead of asserting that it is there, assert that it’s not there.

If you didn’t originally TDD it, or you never wrote a test for that behavior, now’s the time to do so. Write a test that looks at all the options for shipping and asserts that “Ship Today” is not there.

Cascading Deletes

To get that (now) failing test to pass, you’ll likely delete code. Propagate those deletions until everything is passing. It’ll also mean you’ll change other tests as you follow the code across different objects and layers. The goal is to stay out of the situation where a lot of tests are failing, and it’s taking a long time to delete/change the code to get them all passing.

As you finish removing the feature, you may find that the “negative” tests are all that’s left of the feature. You can decide to remove those (treat them as scaffolding), or, if there’s risk that the behavior might resurface in some way, then leave them. Or, it could be left in the test code as a useful trail of documentation.

Sometimes you may find that entire objects are no longer needed, depending on how large the feature is. And then, of course, entire test classes for those objects can also be deleted. As @Suigi says in the Discord, if an entire endpoint is going away, then remove it—and the test that then fails—and look for unused code. Delete that, and “cascade” that delete until all unused code (and tests) is removed.

Removal is Change

Again, there’s little difference in the TDD process for removing, because removing something is a change in behavior as much as adding something. Your tests define the behavior you want, then you change the code to make that test pass. Whether you add code or delete code, all that matters is getting that test to pass.

Improving Perceived Performance, Hexagonally

2022-07-11T10:00:00Z

Why Ensembler is Slow

I’ve been trying to figure out how to make Ensembler, my scheduling application for group programming sessions (aka MobReg), more responsive. It’s an MPA (Multi-Page App, aka old-school web app), so when you click a button, the server does some work, then redirects you to a new page to see the result. I want that work to not take any time (or at least not hold up the redirect), unless it must be completed in order to display the results on the next page.

Member view of Ensembles

For Members (users of Ensembler), the main buttons they can click are Accept and Decline (to accept or decline attending a scheduled Ensemble session). The time spent on the back-end here is mostly sending a single confirmation email (after an Accept), which is around 100-300ms (depending on the response time of SendGrid). The time to persist their RSVP takes almost no time.

Admin view of Ensembles, with a Create Ensemble form

However, for me, the admin, it can take several seconds to do actions, such as “create a new Ensemble” due to blocking delays in two places:

Sending emails to members: When a new Ensemble is scheduled, Ensembler doesn’t send an email in bulk to every member. Instead, it sends a customized email to each member so it contains the date/time of the Ensemble in their time zone^[1]. This means it’s linear to:

number of members * ~200ms

There are currently ~15 members, which will only grow, so this is the biggest time sink.
Creating the Zoom meeting: only done once. Takes about 500ms.

Neither of those actions needs to be completed to return a refreshed administration page, so they can both be async. That is, both the email sending and Zoom meeting creation can run on a background thread, while the server returns from the HTTP request. The persistence (via ensembleRepository.save()) of the newly scheduled Ensemble needs to be synchronous (otherwise I might not see what I just scheduled!), but it takes less than 50ms, so it’s fine.

Completable Futures to the Rescue

To make the two actions happen “in the background”, I figured I could wrap those actions in CompletableFuture^[2] objects, which makes it easy to run a fragment of code on a separate thread^[3], without having to write complex exception-handling code.

To do this, I’d change the application service (EnsembleService) so that the calls to the Notifier^[4] and the VideoConferenceScheduler^[5] are wrapped in CompletableFutures using the runAsync() method. Like this:

CompletableFuture.runAsync(
        () -> notifier.ensembleScheduled(
                ensemble,
                URI.create("https://mobreg.herokuapp.com/"))
);

Easy to do, but I worried that tests checking for a method call (using a pre-programmed Mock) might not see it, as the whole point is to return from the method before the action was complete. In other words, the test might finish before the async action had a chance to complete. I was right. It turns out the ensembleScheduledWithMeetingLinkThenScheduledNotificationIsSent test fails:

org.opentest4j.AssertionFailedError: 
        [ensembleScheduled() should have been called 1 time,
         but was called 0 times.]

at com.jitterted.mobreg.application
    .EnsembleServiceEnsembleScheduledNotificationTest$MockEnsembleScheduledNotifier
    .verify(EnsembleServiceEnsembleScheduledNotificationTest.java:85)
at com.jitterted.mobreg.application
    .EnsembleServiceEnsembleScheduledNotificationTest
    .ensembleScheduledWithMeetingLinkThenScheduledNotificationIsSent
    (EnsembleServiceEnsembleScheduledNotificationTest.java:59)

Adding a Thread.sleep(10) before the test verifies the method call is enough to get it to pass (yes, only 10ms!), but that is the Wrong Way to verify async behavior in a test (any Thread.sleep() is a test smell). There are various Right Ways to do this: inject the executor, get access to the CompletableFuture (so you can .join() it), etc.

Violating Hexagonal Architecture?

In a way, though, it feels like I’ve violated Hexagonal Architecture. Why does the EnsembleService take so long to do its job? Because of infrastructure (calls to remote services). If we make the Outbound Adapters return immediately (and do their work on a separate thread, perhaps leveraging Spring’s @Async, or Futures), then the problem goes away.

Or does it? 🤔

What if I need the Zoom meeting information returned by the API call in order to include it in the emails I send? Then I can’t let the ZoomScheduler do its work later, on a separate thread. In that case, I need to wait on the answer in order to send the emails with the link. Obviously, I also need to save the Zoom link in the database, so I have to wait for it anyway, but that doesn’t need to hold up the redirect (so doesn’t affect perceived performance).

It seems like this is a decision that the Application Services Layer might need to make, and possibly even the Domain Layer. In order to make it possible for the App or Domain layers to use the information, whether they run in the background would be left up to them.

If we define the Port interface so that the methods wrap the return value in a CompletableFuture, e.g., instead of:

public interface Notifier {
    void ensembleScheduled(Ensemble ensemble, URI registrationLink);
}

We do:

public interface Notifier {
    CompletableFuture<Void> ensembleScheduled(Ensemble ensemble, URI registrationLink);
}

And we can ignore the return value (it’s just void), letting it run and finish in the background. Or, we can do a .join() to block until the notifier completes.

For the Zoom meeting creation, we can change:

public interface VideoConferenceScheduler {
    ConferenceDetails createMeeting(Ensemble ensemble);
}

to be:

public interface VideoConferenceScheduler {
   CompletableFuture<ConferenceDetails> createMeeting(Ensemble ensemble);
}

And then use supplyAsync() and .thenAccept() to update the meeting link in the Ensemble object^[6].

CompletableFuture.supplyAsync(
    () -> videoConferenceScheduler.createMeeting(ensemble))
    .thenAccept(conferenceDetails -> {
                    // update ensemble with info from details
                })
    .join();

Application Services Coordinate & Orchestrate

Doing this means the service only has to coordinate those futures, but doesn’t need to execute them—they’re already running on their own thread. Coordination is hard enough, so letting the Outbound Adapter implementation decide how it’s going to run seems like the right split. I think that’s more in the spirit of Hexagonal Architecture.

This will be one of the things I implement on a future Live Coding stream on Twitch.

What do you think? Are there other ways to handle time-consuming operations in your infrastructure without blocking? Let me know on Twitter or my Discord.

Yes, there are ways to do this in a single API call, but let’s assume there isn’t, or the time for the API call to return is linear to the number of emails. ↩︎
See the API docs: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html ↩︎
It will either create and manage a new Thread for you, or use the ForkJoinPool.commonPool(). ↩︎
An Outbound Port interface implemented by SendGridNotifier to send emails via SendGrid’s Java SDK. ↩︎
A different Outbound Port interface implemented by ZoomScheduler to create meetings via Zoom’s API. ↩︎
Of course, you would have to use a separate transaction to update the Ensemble’s information. ↩︎

Tightening Our Assertions

2022-06-22T10:00:00Z

Really Squeeze 'Em

Specifying, or Over-specifying?

Last time, we were test-driving our Blackjack game. We got all the tests to pass, but there were questions around the precision of our assertion. Here’s the test we ended with:

@Test
public void playerWithTwoCardsDrawsCardResultsInThreeCards() {
    Game game = new Game();
    game.initialDeal();
    
    game.playerDrawCardFromDeck();
    
    assertThat(game.playerCards())
        .hasSize(3);
}

Alternative Solution

Last time, our solution:

public void playerDrawCardFromDeck() {
   playerHand.add(deck.draw());
}

was copied from the implementation in the initialDeal() method:

public void initialDeal() {
    // player gets card first due to rules of Blackjack
    playerHand.drawCardFrom(deck);
    dealerHand.drawCardFrom(deck);
    
    // everyone gets two cards, so deal another round
    playerHand.drawCardFrom(deck);
    dealerHand.drawCardFrom(deck);
}

What if we didn’t already have a copy-and-paste solution? What would’ve been the least effort implementation? How about:

public void playerDrawCardFromDeck() {
    playerHand.add(null);
}

That would still get the test to pass, as there would be 3 entries in the player’s list of cards. How? Well, null counts as a card!^[1] This certainly isn’t what we want in our game, though. Perhaps we’re missing some assertions? Let’s look back at our original specification:

Given a PLAYER with a HAND containing 2 CARDs,

When the PLAYER DRAWs a CARD from the DECK,

Then the HAND should have 3 CARDs.

The highlighted part of “from the DECK” is something that we’re not asserting. We’re also not ensuring the cards in the player’s hand are valid instances, without any nulls. So let’s fix that.

Tightening Our Assertions

Sometimes “loose” assertions are fine, as they specify just enough of the behavior we need to get a failing test, like we did by asserting the hand had 3 things in it. Then we can use our professional judgment of the implemented code to determine if the assertions are appropriate.

In this case, we see that our “add null” implementation passes the test, but isn’t what we want^[2]. Let’s adjust that by going through a “tightening phase”, ratcheting up the precision of the assertions one at a time. Note that each tightening step will still follow the Red-Green part of the TDD cycle.

Hand Should Have 3 (Non-Null) Cards

First, let’s make sure that what’s in the player’s list of cards are all actually instances of Card. We could examine each element to see if it’s an instance of Card, but since the list can only hold Card objects (yay generics), we can get away with just making sure there are no nulls in the list. Here we’ll use AssertJ’s handy doesNotContainNull() assertion^[3]:

assertThat(game.playerCards())
    .doesNotContainNull()
    .hasSize(3);

Since we’ve changed what this test asserts, according to Predictive TDD, we need to state our failure prediction precisely:

This test will fail, because there is indeed a null in the list, and we assert there aren’t any.

java.lang.AssertionError:
Expecting actual:
[Card {suit=♠, rank=A}, Card {suit=♦, rank=2}, null]
not to contain null elements

Success! It fails as expected. Now let’s get the test to pass by writing the least effort code^[4]:

public void playerDrawCardFromDeck() {
    playerHand.add(new Card("♦", "8"));
}

Creating a Card out of thin air is allowed, and certainly requires little effort. We know it’ll be temporary, but if the test passes, then we know the test is doing its job enforcing the list to have no null object references.

We can now predict the test will pass, and it does.

Even Tighter: Card Comes From the Deck

Let’s make our assertions even more precise and enforce the requirement that the newly added Card actually comes from the Deck (no cheating by pulling a card out of your sleeve!). How do we do this? The Game code does not provide a way to directly access the Deck object, nor a way to pass it into its constructor^[5]. This is not a test problem, but a code (possibly design) problem. At this point, we have three choices:

Just change the implementation to take a Card from the Deck instead of instantiating a new Card.
Add a new public query method that returns either:

a) The Deck instance, where we can assert that its size has been reduced by 1, or,

b) Just the size of the deck, since we don’t need any other information about the deck.
Add a Game constructor that takes a Deck instance, which allows us the option of asserting .

Option 1: Just change it

This might seem like skipping a step, but we are allowed to use our professional judgment. We can look at the code, see that it would be correct, and make the change. It’s one line of code, and we’re replacing something “fake” (directly instantiating a Card) with something real (drawing the Card from a Deck). We don’t always have to have a failing test when doing something obvious (in our judgment) like this^[6]. With this option, we would replace new Card("♦", "8") with deck.draw(), run the test (which would pass) and call it done.

Option 2: Add test-specific methods

Options 2a and 2b seem wrong, because we’d add public methods purely for testing. It might be appropriate as a stepping stone towards improving the overall design, but by itself it means the state is changing somewhere that we’re not able to observe. What’s worse, even with that information, we still wouldn’t know for sure that the Card drawn from the Deck was added to the player’s hand. The following implementation would make it seem (to an outside observer, like our test) that the right thing happened:

public void playerDrawCardFromDeck() {
     deck.draw(); // reduces the number of cards in the Deck
     playerHand.add(new Card("♦", "8")); // adds a different card
}

Again, we could use our professional judgment and decide we wouldn’t do something silly like that. So we could add a method to Game:

public int deckSize() {
     return this.deck.size();
}

and assert in our test that this is the expected size, like this:

assertThat(game.deckSize())
        .isEqualTo(52 - 4 - 1);
         // 52: original size of the `Deck`
         // subtract 4: 2 cards dealt each to player & dealer
         // subtract 1: the player drew a card from the deck

However, providing a test-only query method like this is a code smell^[7].

Option 3: Inject `Deck` into `Game`

Option 3 is ultimately the better way to go. We can provide Game with a Deck that we construct in our test, so that we know that the Card in the player’s hand is the one that came directly from the Deck.

We’ll see how to do this next time, leveraging some automated refactorings that IntelliJ IDEA provides. We’ll also dismantle our null-checking scaffolding once it’s done serving its purpose.

Even though the hand is a genericized List that only holds Card instances, null is allowed. ↩︎
And possibly not even a reasonable implementation, despite it being “least effort code”. ↩︎
Interested in learning more about AssertJ’s powerful—and seemingly unending—set of assertions? Let me know on Twitter or on my Discord. ↩︎
Using a “literal” is almost always the least effort code. I consider new Card("♦", "8") to be a literal, because it’s not computed and no logic is used in its creation, and the Suit and Rank that make it up are themselves literals. You could call it a constant, but I often associate that with a named constant, e.g. MAX_CACHE_SIZE. ↩︎
That’s right, dependency injection, a fancy way to say “pass in an object as a parameter to the constructor”. ↩︎
As GeePaw Hill says, “Always suspect ‘always’ and ‘never’”. ↩︎
And no, adding some annotation like @VisibleForTesting on the deckSize() method does not help. We might do this as scaffolding (a temporary helping structure) to get us to somewhere better, but only if there’s no other way to go. ↩︎

How I Think About Builders

2022-06-19T10:00:00Z

For the GoF Builder, use the KDL language as the “director” and then implementations that can create an HTML document, a PDF, or even JSON.

Bloch Builder For Configuration

Pardon the Clutter

2022-05-19T10:00:00Z

Welcome to The New TED.DEV

If you’ve stopped by here before, you may have noticed that the domain TED.dev no longer redirects to tedmyoung.com, which is my old (and non-responsive, yucky) website. In fact, if you stopped by in the past couple of weeks, you might’ve noticed a single, lonely article, and nothing else. That’s because I redirected the domain thinking that I’d have the site ready quickly. Yep. 🤷‍♂️

Static Site Generation

A long time ago, I used WordPress, but always thought it was too awkward and slow. I moved to Publii (which is what tedmyoung.com is still running on as of June 2022), which churns out HTML, so is fast, but it was also awkward. I played with Gridsome, which is based on Vue.js, but is not actively developed and hasn’t gotten to a 1.0 release. I also don’t (yet?) need the power of a front-end framework like Vue. I’ve tried Hugo many times over the years, but something about it didn’t work for me. (It isn’t at 1.0 either, but is actively developed.)

I’ve had my eye on 11ty (“Eleventy”) for a while, and with its recent 1.0 release, I decided to give it a closer look. I had learned a lot about it from Andy Bell’s “Learn Eleventy from Scratch” course, which is now open source. And while Andy ported his 11ty-based site back into WordPress, I like the simplicity and control I now have with 11ty^[1].

Goodbye Substack

My goal is to gather all the various (and dead) sites I’ve left strewn about the internet, and put them here. However, the main impetus behind the move is two-fold:

Get my content off of Substack: I’m very much a believer in “own your platform” when it comes to content, and Substack was meant to be temporary anyway. Mainly, I needed to consolidate my email list to prepare for…
Launching my self-paced course: “Refactoring to Hexagonal Architecture”! Shh! I haven’t officially announced it. To stay updated, subscribe to my newsletter here.

Not having a pleasant website for my writing has also meant I’ve been less motivated to write. Now I can write more, including about new courses that I’m excited about.

In the meantime, I’ll migrate all my past Substack newsletter articles to this site, and then start moving things from elsewhere and publishing new articles.

The Future

There’s still a lot of content to add, not just articles, but also information about my classes, technical coaching, etc. There’s also “design” work to do: larger excerpts for articles on the front page, a “better” front page, different fonts (now there’s a rat hole!), tweaks to the footnoting, etc. And internally, more 11ty shortcuts and plugins to help with things like images, etc. However, I now have a good foundation to build upon.

Community

Do you know I run a Discord community? It’s a place where folks discuss Java (and PHP and C#), object-oriented programming and design, unit testing, test-driven development (TDD), Hexagonal Architecture, and more. I’d always wanted a place where I could talk to folks about code and design at a deeper level than you’d find on places like Reddit. It also supports the “live coding” that I do on Twitch. If that sounds interesting, join us using this Discord invitation link: https://discord.gg/9XDfBSZ.

Not that it was easy to get to this point. In fact, aspects were much harder than expected. Ask me if you want to know more details, maybe I’ll write an article or two about the experience. ↩︎

Implementing the Feature

2022-05-09T10:00:00Z

Implementing the Feature

Continuing from last time, we’re now ready to write code!

The “Write Code” Card from JitterTed's TDD Game

Predictive TDD

As a reminder, the high-level steps of PTDD are:

Precisely define the desired change in behavior
Write a test that fails in the precisely predicted way
Implement (with minimal effort) the behavior to make the test pass
Increase the Changeability of the code by Refactoring

In Part 1, we defined the behavior change we wanted to see. Remember that new functionality (or the rare removal of functionality) is a change in behavior. In Part 2, we wrote a test and made it fail in the way we wanted and expected. In this part, we can finally write code to implement that new behavior and Get To Green!

Least Amount of Code Flowchart

Write Less Code

One of the difficult aspects of learning TDD (and we’re always learning when doing TDD) is writing the absolute minimum amount of code to get the (currently failing) test to pass^[1]. Most of us were taught, or learned along the way, to write generalized code that captures multiple, different scenarios. This habit leads us to write code that handles situations that the test isn’t testing. It’s hard to break this habit, but taking tiny steps is the key to success with TDD.

The “Less Code” Card from JitterTed's TDD Game

Writing less code means the code will more likely be correct. If it’s not, and the test continues to fail (or other tests fail!), there will be less code to troubleshoot. It’s much easier to find a bug in 3 lines of code than 10, let alone 50.

By focusing on just getting the test to pass, and not concerning ourselves with how “elegant” or “beautiful” the code is, we can use all our precious cognitive energy to solve the problem. Later on, we can transform the code into something better through the refactoring process, but let’s make it work first.

Blackjack Game: Player Draws a Card

In Part 2, we wrote a failing test for the behavior where a Player “draws” (takes) a single card from the deck of cards in a game of Blackjack. Here’s that test:

@Test
public void playerWithTwoCardsDrawsCardResultsInThreeCards() {
    Game game = new Game();
    game.initialDeal();
    
    game.playerDrawCardFromDeck();
    
    assertThat(game.playerCards())
               .hasSize(3);
}

After a bit of work, we were able to get the test to run and fail as expected. The player gets 2 cards from the initialDeal(), and since the playerDrawCardFromDeck() doesn’t (yet) do anything, we ended up with 2 cards instead of the 3 that we want.

Implement the Behavior

To get the test to compile (so we could watch it fail for the right reason), we created the playerDrawCardFromDeck() method, but purposely left the implementation empty. Now we (finally!) fill in the desired behavior.

Our instincts might lead us to writing an implementation that looks like this:

public void playerDrawCardFromDeck() {
   playerHand.add(deck.draw());
}

This may not look like much, but just in this one line we have:

playerHand, and knowing what it is (it’s a List<Card>)
The List’s add() method (which takes a Card)
deck (an instance of the Deck class)
The deck’s draw() method (which returns a Card, matching the add() parameter)

That’s 4 different things to think about, which can be a lot if you’re not familiar with the code. However, since we are (at least I am) familiar with it, it’s fine. In fact, this code was copy-pasted from elsewhere in the Game class. We copied it from the initialDeal() method, where cards are dealt to the player and dealer, so this counts as “less effort code”.

Predict Success

Now that we have a test that failed for the right reason and implemented the least effort code that we think will make the test pass, it’s time to run the test. This time, instead of predicting failure, we’re predicting the failing test will now pass, so we run it.

Success!

And it does indeed pass—ship it!

Assertion Precision

Should we celebrate yet? Our assertion that the player ends up with 3 cards is necessary, but is it sufficient? And while we got the tests to pass—we’re in “The Green”—we’re not yet done with our TDD cycle, as we haven’t looked for Refactoring opportunities.

Next time, we’ll “ratchet up” (make more precise) what asserting, and then we can move on to the last step: Refactoring. Subscribe below to make sure you don’t miss it!

The TDD Intro Series

Red-Green or Refactoring First?
Clarifying the Goal of Behavior Change
Predicting the Failing Test
Implementing the Feature (this article)
Tightening Our Assertions

I often refer to this as “least effort code,” because sometimes copying and pasting 5 lines of code is the least effort, but possibly not the least amount of code. ↩︎

Remote Learning Ensembles

2022-01-15T10:00:00Z

2023-10-09: Added “Spectator” role information, added Retrospective details

2023-03-27: Added some Driver etiquette around not blocking information, closing unneeded windows, etc.

2022-06-09: This article was originally published on Dev.to, but it’s time to bring it here, and add some updates.

2022-03-22: Updates since I first wrote this can be found as bracketed & italic remarks inline.

How I Run Remote Learning Ensembles

The Ensemble^[1] sessions that I’ve been running for the past few ~~months~~ years are centered around improving developer skills in test-driven development (TDD), domain-driven design (DDD), and Hexagonal Architecture, with a focus on taking small, safe steps, and frequent refactoring. Since the codebase is Java, it’s turned out that all attendees are using IntelliJ IDEA, so an additional focus has been learning its shortcuts and the less common automated refactorings (such as Move Method).

Facilitate From the Outside

Since the focus is on learning skills and not necessarily getting “work” done, I stay out of the rotation, observing and providing guidance and advice along the way. I also serve as the “customer” providing direction on the features being developed. [However, if there’s only 2 attendees, I’ll participate in the rotation.]

Below you’ll find information on how I currently run the Learning Ensembles. Much of this was gathered from various sources, some adapted, and some learned by trial and error.

Handing Off

I’ve found that using GitHub-based hand-offs, using the awesome command-line tool mob.sh, to work better than other mechanisms that I’ve tried. It allows people to use their own computer and IDE, which means they’re not only comfortable using tools that they’re used to, but they’re building skills (such as shortcut keys) in their “natural” environment. The downside is that there’s a bit of disruption during the hand-off, mainly around the new Driver taking over. They may need to rearrange editor windows and open up files, though this tends to be less of a problem after a complete cycle of turns.

Roles

We call the person at the keyboard (and the one sharing their screen) the Driver and the person directing them the Navigator^[2]. I’ve gone back and forth about the role names (e.g., Typist, Director), but have found that metaphor of getting to a destination using the roles of Driver and Navigator to be well-suited.

Driver

When starting your turn, clearly state that you’re ready for the Navigator’s instructions by saying “I’m Ready” out loud.

This is needed because the Driver needs time to run the mob start command (to get the latest code on their machine) and arrange the IDE windows as needed.

[We’ve standardized on having the IDE split the screen into left & right panes, with the test code on the left, and the feature code on the right. This way the test “drives” the code from left to right.]
The Driver’s job is to carry out the Navigator’s intent. Note: there is only one Navigator navigating at a time, otherwise the Driver can get confused by too many requests.
If the Driver is unsure what to do next, or how to do it, they ask the Navigator for clarification.
- It’s often helpful for the Driver to offer choices “do you want me to extract the whole block, or just line 24?”
Avoid having a Runaway Driver where the Driver does more than (or different things from) what was asked.
Don’t scroll around, unless the Driver requests it, as it can be disorienting to the Navigator (and the rest of the ensemble).
Avoid leaving popups visible as they can block important information.
Close window panes that aren’t needed, especially the Terminal and Project windows. Give as much room to the tests and code as possible.

Navigator

Declares intent at the highest level first, only providing more detail if the Driver asks, e.g.:
- Start with intent: “extract the loop to a new method named Process Transactions”
- Provide more detail: “select lines 24 through 28, use Refactor, then Extract Method.”
- Even more detail: “click on the word ‘for’ on line 24, press the expand-selection key a few times, now click on…”
Avoid micro-managing (“backseat driving”) the fixing of syntax errors or typos.
On the other hand, it’s very important that the Navigator pay close attention to what the Driver actually did as a result of their instructions. Did they type the correct thing? Did they extract the correct lines into a new method? This is not easy, as Navigators tend to think about the next step, and assume their previous intent was carried out correctly. It’s common for the Driver to do something different from what was asked, but about 20% of the time, the Navigator didn’t notice, causing problems or confusion. As facilitator, I’ll often step in at this point, if nobody else pointed out the discrepancy.
- Communication is hard, and the only way a Navigator knows that they were understood is if the Driver did what was desired.
When the turn is over, inform the next Navigator of what you had in mind. However, it’s up to the new Navigator to either continue down that road, or try something else.

Onboarding New Participants

Get their GitHub username
- Add the username as collaborator to the repository that will be used for the Ensemble
- They’ll need to accept the invite, so do this enough in advance
Participants will need to install and verify that these work:
- The mob.sh tool (which requires git)
- Zoom, especially share screen privileges
  - Do audio check, video check is optional
- Whatever IDE they’re comfortable with
  - Increase font size of IDE to at least 16px for screen sharing readability (sometimes 18px is needed!)
- Correct version of Java (11 or later)
- Clone the repository via SSH if possible (this makes it easier to push)
- Build and run all of the tests
- Do a test mob start and mob next to ensure privileges are set up correctly

Facilitator Preparation

Fill out names in the Mob timer
- We use https://mobti.me
- Make sure to rotate so folks aren’t always in the same order or are navigating the same driver
Verify participants have accepted GitHub repo invitations
Verify repository has the latest code (all changes since last session pushed)
Review retrospective and Mission notes from prior sessions
- I keep these notes in the same repository as the project code
Ensure goals (I called this the “Mission”) for the upcoming session are clear
Send a link to the Zoom that we’ll be using (even if it’s the same one, people like/need the reminder)
- I use my Ensembler tool to handle this for me, among other things

The Session

This is based on my experience with 90-105 minute-long sessions [I’ve found 105-115 minutes—just under 2 hours—better for groups that only get together once a week, or less, in order to remember and/or understand the context]. We cap the size to 5 active participants, with turn times of 5 minutes each.

We have two main roles: Driver and Navigator (as described above). When the turn is over (after the 5-minute timer has expired), the Navigator becomes the new Driver and the Driver goes back into the general crowd. [We now go the other way: Driver becomes Navigator, and Navigator returns to the crowd, as the Driver has the code already in their head/fingers.]

The Huddle

[Added details on The Huddle]

The starting Huddle is a way for the group to sync up and understand where things are and what the next task is. This is important as people haven’t seen the code for a week or more (or never!). Once the first Navigator agrees that they have a sense of what to do, the Huddle ends.

During the Ensemble, people can get lost, can disagree on which way to go, etc., and so anyone can call for a Huddle. The timer is stopped and discussion starts. It’s important to get back to the code, so if the discussion becomes too detailed (or too abstract!), it’s time to see if there’s enough understanding to take the next step, without worrying about the steps after that. As the saying goes, “discuss in code”! In other words, trying out an idea by writing actual code, is better at demonstrating what approach is better/worse than just talking about it.

Agenda

Introduce anyone who’s new
Provide the mob timer link (if a separate one like mobti.me is used)
Remind folks of any Code of Conduct
- At a minimum, remind them that this is a learning experience and to be compassionate and curious
Create (or update) a participants.txt file with the date, and start a list with the facilitator’s name as the 0th entry. For example:
```
Session #10 - Friday, May 28, 2021
----------------------------------
0. Ted
```
[I stopped putting my name as facilitator, and now it starts with the first participant.]
Do one rotation by having each participant do the steps below when it’s their turn. The purpose of this exercise it to ensure everyone can share their screen, update their local copy of the repo, and push changes to the repo, as well as a check of their audio and font size. Doing it at the beginning means that it won’t interrupt the Ensemble’s flow during the actual work:
1. Share their screen (I make sure that Zoom allows participants to “steal” or “grab” the screen sharing from the current sharer)
2. Execute a mob start, once it completes…
3. Type their name in the participants.txt file (if it doesn’t show up, or is missing other participants, you know something’s not quite right), e.g.:
```
Participants from Ensemble #50 on March 4, 2022
-----------------------------------------------
1. Hoffman
2. Moxie
```
4. Execute a mob next and once it completes…
5. Announce “Ready for next DRIVER”
6. Next driver takes over and repeats from step 1 until everyone has had a turn
Explain/review the mission for the session
- I keep this in a text file in the same repository as the project code
The Team does a “huddle”, where they discuss the mission, make sure they understand it, and define the next task or two.
The first Driver shares their screen, does a “mob start” and when complete declares “I’m ready”

[Usually they’ll start by running all the tests]
The Navigator provides instructions to the Driver
When the turn is over (the timer has gone off), the Navigator relays their intent (what they were trying to achieve) to the next Navigator

[If the Navigator/Driver pair are almost done with a task, I’ll usually let them finish it before moving to the next person.]
Things that need to be done (delete that test, rename that class, fix that flaky test) are dropped into chat
Side-comments about the work, such as naming suggestions or questions, are also dropped into chat
After each full cycle (everyone has taken their turn once), the facilitator runs a “mini-retrospective”, if the ensemble feels that things are in a good flow, the mini-retro can be skipped.
- Often the 2nd time around, folks feel the need to hold a mini-retro to regroup and gain perspective.
[With a more experienced group, I’ve found explicitly taking time for a mini-retro unnecessary, as folks learn to call for a Huddle as needed]
The final turn ends when there’s 15-20 minutes left in the scheduled ensemble time.
Conclude with a retrospective, where each person in the rotation provides thoughts, observations, things they learn, etc., until everyone has run out of things to say. Then, things to do more or less of, what went well/not so well, etc., are noted in an outline or mind map.
Facilitator shares observations (the more specific and concrete, the better), such as “I noticed it took 3 turns to finally get from red to green” or questions, such as “how did it feel to leave have that test continue to be flaky”, or “was anyone uncomfortable with the poor code formatting in that method?”
Session ends with cleaning up of the pending tasks, collecting undone ones from chat, checking off those that are done, etc.
Everyone waves goodbye!

Ch-ch-ch-ch-changes

Note that we have changed how we run the Ensembles over time, because of things brought up in our Retrospectives and the freedom to experiment. I’ll follow up with additional articles as I learn. One non-trivial change was the order of Driver-Navigator. When we swapped that order, we found less of a need to “hand-off” intentions.

Let me know about your experiences with Ensembles by joining my Discord or tweeting at me on Twitter.

Like others, I prefer to use the term Ensemble instead of Mob Programming, as it’s a “friendlier” term. ↩︎
These roles come from Pair Programming terminology, and we specifically follow the “strong-style” pairing method from Llewellyn Falco. ↩︎

Fooled By the Failure to Fail

2021-11-23T10:00:00Z

In Part 2 of my “Predictive Test-Driven Development” series, I talked about how predicting the failure of a test is not always enough. Predicting precisely^[1] how the test will fail helps me stay alert for tests that fail for a different reason, or perhaps don’t fail at all (i.e., they pass). I want to share another example of what can happen when you ignore the Predicted Failure. This happened during one of my “Refactoring to Testable Code” training classes^[2], which again shows that experts make mistakes!

Test-Driving an HTTP Endpoint

In the third session of the class, I demonstrate how to test-drive a new web-based user interface using Spring MVC and the Thymeleaf templating engine. The code I’m working with is a single-player Blackjack game. In preparing for this particular class, I had updated the Spring Boot dependency to the most recent version—something I usually avoid because it’s risky. I felt OK doing it this time, because I used the same version in other projects with no problems^[3].

I start with a few cycles of TDD, where I create Spring MVC tests to drive the creation of code to handle incoming requests. I get to a point where a template is returned to show the state of the game when it starts, triggered by a button (using POST^[4]). I continue to follow the process, first creating a failing test like this:

@Test
public void postToStartGameEndpointIsStatus200Ok() {
    mockMvc.perform(post("/start-game"))
           .andExpect(status().isOk());
}

Here, the test wants to verify a successful response when requesting (via POST) the page at the endpoint /start-game. Before I run the test, I state my Precise Prediction:

This test will fail with a 404 (Not Found) status instead of the desired 200 (OK) status.

This is because there’s no code responding to the endpoint, and Spring MVC will default to returning a 404 in that case. I run the test, and it fails in the predicted way:

java.lang.AssertionError: Status expected:<200> but was:<404>
Expected :200
Actual   :404

My next step is actually not to make the test pass, but to write just enough code to make it fail for a different reason. This is because writing enough code to make it pass does too much in one step. The two steps I want are:

No more 404: Spring MVC calls the method I want for the /start-game endpoint, and
Return a valid template name that Thymeleaf can find and process.

I want to write just enough code so #1 works, but still fails for #2, because the template file matching the name I return (blackjack) doesn’t yet exist. Once the test fails for reason #2, I can drop in the template file into the templates directory, and finally watch the test pass^[5]. The code I write next (in the @Controller class) is:

@PostMapping("/start-game")
public String startGame() {
    return "blackjack";
}

Now my prediction is:

This test will fail with a Thymeleaf exception, complaining that it can’t find the template named blackjack.

I run the test, and it passes. I am appropriately surprised by this, given my prediction! Note that I have done this exact scenario every time I’ve taught this class, well over 30 times by this point, and it always failed for the expected reason.

Watch Out for the Availability Heuristic

You may have heard of the Availability Heuristic, a cognitive bias that leads us to believe “the correctness of a hypothesis based on how easily that hypothesis…comes to mind”. Well, the most “available” hypothesis that came to mind for me was: “oh no, I shouldn’t have upgraded the Spring Boot dependency, something must have changed, and now it just works”. I ignored the fact that the test didn’t fail, and continued with the next step in the TDD cycle: I copied the Thymeleaf blackjack template into the correct directory, and told the class “now we can run the application to see the generated page”.

You might guess what happened: I got an error page that said:


There was an unexpected error (type=Not Found, status=404).

Now I’m confused. The test passed (when I didn’t expect it to), but at runtime it’s failing in a way I can’t explain. 🤔

At this point, I go into troubleshooting mode: I turn on debug-level logging, rerun the application, and notice a lack of Thymeleaf code anywhere in the output. 💡 I now have a new hypothesis, one grounded in observation (rather than guessing or availability): do I have the Thymeleaf dependency in my project’s Maven file?

Of course, I don’t. 😯 Somehow it got dropped when I initially added Spring Boot dependencies to the project during my demonstration. I added the missing dependency and “rewound” things. I restated the prediction:

The test will fail with a Thymeleaf exception, as it can’t find the blackjack template.

Then ran the test. It now failed for the right reason:

Caused by: org.thymeleaf.exceptions.TemplateInputException: 
  Error resolving template [blackjack], template might not exist
  or might not be accessible by any of the configured Template Resolvers
at org.thymeleaf.engine.TemplateManager.resolveTemplate(TemplateManager.java:869)

With a sigh of relief at the correct failure, I continued on.

Lessons For Everyone

What did I learn?

Don’t ignore tests that fail for the wrong reason, or pass unexpectedly. You could be making a wrong assumption. It’s worth the extra time to track down and understand why it didn’t fail as expected.
Go back to a known state. I could have changed the version of Spring back to the one I had been using for months to eliminate that as a cause.
Don’t update dependencies right before teaching a class. If I hadn’t, I would have searched for other reasons for the problem much earlier, as the upgrade of the dependency would not have been my most “available” hypothesis.
Making mistakes is OK (even in front of an audience). Often those mistakes make great content for articles and future classes. I now make this mistake on purpose to show how valuable it is to pay attention to unexpectedly passing tests.

I’m thinking of renaming my process to Precisely Predictive TDD (PPTDD)! ↩︎
Find out about the next public offering of this class by signing up to my mailing list. ↩︎
This fact becomes important later… ↩︎
I know we shouldn’t return content via POST here for a Web App, this is something we fix later in the class. ↩︎
Note that I don’t directly test the content of the page generated by Thymeleaf, which would have been helpful. ↩︎

Predicting the Failing Test

2021-11-05T10:00:00Z

Way back in March 2021, I started explaining my Predictive Test-Driven Development process. The whole process looks like this:

My Entire PTDD Process. Now available as a game!

In part 1, we looked at the beginning of the process, answering the questions:

What should it do? and
How will you know it did it?

These questions help clarify our goal for the next bit of behavior change, i.e., what we want our system to do that it currently doesn’t. We need this clarity to take the next step: writing a failing test.

The Failing Test

Our next major goal is to create a test and watch it fail. These next three steps in the process get us closer:

Getting Test to Compile

Write Test for Code Yet-to-Be: this reminds us that we’re writing test code for behavior that doesn’t yet exist. Or, it’s different from what exists now, such as a bug.
Fails to Compile: when testing new behavior, we may need to create a new method, or even a new class.
Write Least Amount of Code to Compile: for any non-existent methods or classes, our job here is to only create them, not implement them. Treat this like a game: how little code can you write to get the code to compile?

Let’s look at the example from the domain of a single-player version of the Blackjack card game from Part 1:

Given a PLAYER with a HAND containing 2 CARDs,

When the PLAYER DRAWs a CARD from the DECK,

Then the HAND should have 3 CARDs.

The new behavior here is having the player draw (take) a card from the deck^[1]. Here’s a JUnit test that implements our example:

@Test
public void playerWith2CardsDrawsCardThenHas3Cards() {
    Game game = new Game();

    game.playerDrawCardFromDeck();

    assertThat(game.playerCards())
        .hasSize(3);
}

At this point, the method playerDrawCardFromDeck()^[2] does not yet exist, so it doesn’t compile (and shows as red in my development environment). Now we do the minimum work possible to get the code to compile. We do that by creating the missing method in the Game class:

public void playerDrawCardFromDeck() {
    
}

Notice it’s empty. We don’t implement anything yet, we write just enough code to compile so we can watch the test (hopefully!) fail. Next, let’s run the test.

Predict How the Test Fails

Stop! Don’t run that test yet!

Predict Before Running

It’s tempting to go from getting the test to compile to running it and watching it fail, but you’d be missing an important part: prediction.

For many years, I happily did TDD without predicting how the test would fail, and was successful at it. At some point, I noticed a common mistake: assuming the failing test failed for the expected reason: the yet-to-be-written production code. What if it failed for a different reason? What if it failed because you misunderstood the existing code? Or the test setup (the “when”) was incorrect? If you assumed the test failed because of missing behavior, you’d be confused when the test continued to fail even after implementing that behavior.

In our example, we expect the test to fail because playerDrawCardFromDeck() does nothing. That should mean the number of cards the player has is two and not three. Let’s run the test with that prediction, i.e., the assertion will fail because our expected result of 3 is not the actual result of 2.

Test Failed for the Wrong Reason

Uh oh. That’s not what we predicted (expected). The test is failing (yay!), but for the wrong reason (boo!). Why does the player have 0 cards? Let’s look at our test again:

@Test
public void playerWith2CardsDrawsCardThenHas3Cards() {
    Game game = new Game();

    game.playerDrawCardFromDeck();

    assertThat(game.playerCards())
        .hasSize(3);
}

Oops. We forgot to tell the Game to do the initial deal, which deals two cards each to the player and dealer. Let’s fix that:

    @Test
    public void playerWith2CardsDrawsCardThenHas3Cards() {
        Game game = new Game();
+       game.initialDeal();
        
        game.playerDrawCardFromDeck();
        
        assertThat(game.playerCards())
            .hasSize(3);
    }

Let’s run the test again – but wait! Let’s repeat our prediction: we will expect 3, but the actual result will be 2.

java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at java.base/java.util.ArrayList.remove(ArrayList.java:536)
at com.jitterted.ebp.blackjack.domain.Deck.draw(Deck.java:24)
at com.jitterted.ebp.blackjack.domain.Hand.drawFrom(Hand.java:45)
at com.jitterted.ebp.blackjack.domain.Game.dealRoundOfCards(Game.java:71)
at com.jitterted.ebp.blackjack.domain.Game.initialDeal(Game.java:64)

Oh no, that’s even worse. What’s going on?

A closer look at initialDeal() reveals that we had some code leftover from an experiment and forgot to remove it. And we forgot to run all of the tests before we started this session. Even us “experts” make silly mistakes like this^[3]. However, our prediction prepared us to be on the lookout for anything out of the ordinary.

Let’s clean up initialDeal(), and, before we run the tests, we repeat our prediction so it’s fresh in our mind: we expect a size of 3, but the actual size will be 2.

java.lang.AssertionError: 
Expected size: 3 but was: 2 in:
[Card {suit=CLUBS, rank=A}, Card {suit=CLUBS, rank=5}]

Success! Now it’s failing for the correct reason. It’s still failing, but at this point of the TDD process, we want it to fail^[4]. And, just as important, we want it to fail due to the missing behavior, and not some other reason.

Prediction Prepares Us for Surprises

Over the years, I’ve found this extra prediction step invaluable in fighting the tendency to make assumptions^[5]. By stating our prediction before we run the test, we are better prepared to notice any slight difference. I often state the prediction out loud, because it’s easy to lie to ourselves by thinking “oh yeah, that’s what I thought would happen” when we predict only in our heads.

Assumptions lead us astray so easily, and are frustrating because we’re trying to solve what we think is the problem instead of the actual problem. The prediction step won’t prevent all wrong assumptions, but it eliminates enough of them to make it well worth the effort.

Next Up

In the next part, we can finally write some production code! Stay tuned. If you have questions or want to discuss PTDD, join my free Discord community.

The TDD Intro Series

Red-Green or Refactoring First?
Clarifying the Goal of Behavior Change
Predicting the Failing Test (this article)
Implementing the Feature
Tightening Our Assertions

In the real world, players don’t take cards, they signal the dealer that they want another card. This is called “hit” in the language of Blackjack. Object-oriented programming doesn’t always mean simulating the real world as-is. ↩︎
You might wonder where the Deck is. In this example, the Game already has a reference to a Deck. ↩︎
If you want to see me make more mistakes, just watch me live code on Twitch. ↩︎
And so even though the test is failing, it’s actually a success. This is why the diagram shows this step in green and not red! ↩︎
There’s also research to back this up. See this study: Predicting as a learning strategy. ↩︎

Faster Feedback Using In-Memory Repositories

2021-11-03T10:00:00Z

One of my Twitch viewers was confused about the “Fake” and “In-Memory” Repositories I use, and wanted to know more about them. These are implementations of the Repository persistence pattern (from Domain-Driven Design), where we define an interface with methods to store and retrieve objects^[1], but don’t specify how they’ll be stored. Here’s an example from my Ensemble registration system (aka MobReg):


public interface MemberRepository {

    Member save(Member member);

    Optional<Member> findByGithubUsername(String githubUsername);

    Optional<Member> findById(MemberId memberId);

    List<Member> findAll();
}

In-Memory repositories store objects in memory, instead of writing them to a database. They’re not suitable for production, but they are important for developing and testing your applications. If they’re used exclusively for unit testing, they’re called Fakes.

Faking It for Testing

Fakes are a type of Test Double used exclusively for tests that need to read and write to another object, like our Repository. We can isolate the code under test from the slowness and complexity of a real database repository by having the Fake store objects in memory.

I may write the Fake to only store a single object if that’s all the test needs (see this example from my Kid Money Manager project). Otherwise, I’ll use a Map implementation to store multiple objects, as in this example. Since a Fake mimics the real thing, there’s no need to alter any tests (or code) when we switch to the real thing for production. However, there may be subtle differences between our Fake and a database implementation (often around transactions), so I’ll write (only a few) tests to ensure the code works with both.

I’ll go deeper into developing database Repositories using Fakes in a future article.^[2]

Fast Feedback

The In-Memory Repository is intended to substitute for the database Repository at runtime, so the application can be used in a realistic way. I use an In-Memory Repository under two conditions:

When the application domain is changing a lot, and,
I’m not ready to commit to the database schema I need for production.

I can get quick feedback on changes to the Domain objects without spending the time to constantly update the database Repository code.

At a minimum, the in-memory implementation needs a way to find objects by their ID. Using a ConcurrentHashMap makes this easy and protects against potential race conditions. If the Repository interface has other “finder” methods, e.g., findByFirstName(), I will manually write those (as in this example). If I’m concerned the “finder” methods are complicated^[3] and might not work correctly, I’ll write them via test-driven development (TDD).

Once I’m happy with the way the application works, I can switch to writing the database version. I’ll create migration scripts for the database and test them, usually using Test Containers. Finally, I’ll change the configuration to use these “real” Repository implementations, and manually check the application for any issues. I rarely find any at this point, so I then push to production. I’ve had zero bugs in production following this process, as part of my overall test-driven development process.

Should They Stay, or Go?

While developing MobReg, I found I switched to in-memory repositories so often that I created a specific configuration option to make it easier. Eventually, I’ll remove the in-memory versions once the object structure becomes stable (though that may not happen for a while!). For now, the quick feedback cycles are worth the minimal overhead of maintaining them.

If you want to watch me work on MobReg, or ask questions, join my Discord community.

Technically Repositories store and retrieve Aggregates, but that’s a whole separate article. Or three. ↩︎
Want to see this article sooner? Let me know on Twitter or Discord. ↩︎
Be careful, if you find yourself implementing complicated Fake Repositories, you might be doing too much, or you may need to limit testing that aspect of the Repository to a real database. ↩︎

Refactoring Tests

2021-10-31T10:00:00Z

As you may know, I code live on Twitch whenever I can. I generally work on real-world projects, such as my Ensemble Programming Registration System (aka MobReg). I do this for many reasons, one of which is to show folks what it looks like to do test-driven development on a small, but real-world codebase (mistakes and all). I also enjoy chatting with my viewers, and getting feedback and suggestions while I’m coding.

I recently took the time to refactor some test code, as the setup sections of tests were starting to get verbose and awkward. This video is an excerpt from my stream, where I create a test data builder for the Member object^[1]. While the video is unedited, I hope you find it useful. If you’d like to see more of these excerpts, let me know on Twitter or Discord.

youtu.be/qTJzOlVebdw

I plan to write about Test Data Builders in more detail. If you want to see it sooner, let me know on Twitter or Discord. ↩︎

Naming Conventions for DTOs

2021-10-30T10:00:00Z

This article comes from a question asked in my Discord. If you want to discuss topics like this, come and join us, it’s free!

Naming Conventions

Today, someone asked me about naming conventions for Data Transfer Objects (DTOs). I primarily use DTOs to carry information from my “domain” to and from the outside world. DTOs are a core part of the Hexagonal Architecture that I use for organizing code. (You can watch my video on the topic on YouTube^[1].)

https://youtu.be/ujb_O6myknY

Somewhere there needs to be code that transforms (or translates, or “maps”) the internal domain objects into strings and numbers that can be sent to (or received from) the outside world. Some folks put that code in separate mapper classes, but I prefer to put it directly in the DTO.

I usually use a static from() method that converts a Domain object to the DTO, like this:

public static UserProfileDto from(UserProfile userProfile) {
    return new UserProfileDto(userProfile.getId(),
                              userProfile.name(),
                              userProfile.phoneNumber().asRaw(),
                              userProfile.email(),
                              userProfile.role().name());
}

The downside to using from() is that it can look odd when using it in a stream-map context, like this:

List<UserProfileDto> dtos = userProfiles.stream()
                                        .map(UserProfileDto::from)
                                        .collect(Collectors.toList());

but I’ve gotten used to it. The alternative is to use toDto(), but I don’t think that’s clearer. I no longer name my DTO classes with a Dto suffix, unless I can’t think of anything more descriptive. These days I create objects with names like MemberView for something displayed in a browser (see below), or CreateMemberRequest for an incoming request^[2] to create a member.

public static MemberView from(Member member) {
    return new MemberView(member.getId().id(),
                          member.firstName(),
                          member.githubUsername(),
                          String.join(",", member.roles()));
}

Persistence with DBOs

When I need to transform a DTO back into a domain object, I’ll create an asDomainObject() instance method, like this:

UserProfile asUserProfile() {
    return new UserProfile(id,
                           name,
                           new PhoneNumber(phone),
                           email,
                           Role.valueOf(role));
}

Often the DTO comes from a database or other persistence mechanism. I mostly use ORMs like Spring Data JPA or JDBC, where my naming convention for objects stored in the database is now Dbo (DataBase Object) as the suffix (e.g., UserProfileDbo or MemberDbo). This makes it clear that the DBOs match the structure of the database and are not Domain Objects. It also helps me differentiate them from other DTOs.

Setters & Getters

The rest of the DTO consists of getters and setters to allow libraries (such as Spring and Jackson) to access the DTO’s properties programmatically^[3]. This is, in fact, a standard that goes way back to the JavaBean specification defined in 1997. Having getters and setters in domain code, however, is a no-no, which I’ll talk about in future articles.

This video is a bit dated, but my course on Refactoring to Hexagonal Architecture goes into detail about this. ↩︎
This kind of DTO is often translated from a web form or JSON automatically by a framework, such as Spring. ↩︎
Records can be used instead, with some exceptions, as of Java 14. See MemberView for an example. ↩︎

Favorite IntelliJ IDEA Plugins

2021-04-21T10:00:00Z

2023-02-21: Added the Custom Postfix Templates plugin.

2023-02-02: This article was originally published on Dev.to, but it’s time to bring it here, as well as bring it up to date.

As a software developer, Java instructor, and experienced IntelliJ IDEA user (some might say fanatic) for over 20 years, I’m often asked about the plugins that I use. To be honest, I don’t use a lot of plugins, I find myself mostly focused on improving the quality and testability of code by using IntelliJ IDEA’s powerful automated refactorings, along with its Live Template and Postfix features. However, there are some very useful plugins that are “standard equipment” for me when I install it on a new machine. Note that I use many of the built-in plugins from JetBrains, which I’m not including in this list.

Tab Shifter

Rating: ⭐️⭐️⭐️⭐️⭐️ (5/5 Stars) Great if you like splitting your screen in various ways.

Plugin Page: https://plugins.jetbrains.com/plugin/7475-tab-shifter

Side-by-side Editor Panes

I do a lot of teaching and live coding, where we’re doing Test-Driven Development (TDD). This means we’re constantly moving back and forth between the tests and the code. Splitting the editor to show both test and production code makes it easier for those viewing my screen to retain the full context of what we’re doing. If I’m coding by myself, I can switch tabs quickly (using CMD+E/CTRL+E or CTRL+TAB) when I need to. But when coding with others (pairing, ensembling, etc.), it’s great to see both all the time.

IntelliJ IDEA has splitting built-in, but it doesn’t have keyboard shortcuts assigned to the actions. Tab Switcher adds sensible shortcuts that are easy to memorize: e.g., CTRL+OPT+] to move the current file to the right side and CTRL+OPT+[ to move it to the left side.

Presentation Assistant

Rating: ⭐️⭐️⭐️⭐️⭐️ (5/5 Stars) Required if you share your screen with others during pair programming, ensembling, teaching, etc.

Plugin Page: https://plugins.jetbrains.com/plugin/7345-presentation-assistant

Presentation Assistant plugin in action

Pretty much what it says in its description: “shows name and Win/Mac shortcuts of any action you invoke”. As an instructor and live coder, I always have this installed and activated. I like how it shows both Mac and Windows & Linux shortcuts so those who are watching can learn the shortcuts for their platform. It’s also helpful when I’m writing how to use the shortcuts since I don’t have to search for the shortcuts for the other platforms (I use a Mac), I just hit the keys and Presentation Assistant shows me the keys for Windows/Linux.

Custom Postfix Templates

Rating: ⭐️⭐️⭐️⭐️⭐️ (5/5 Stars) JetBrains make this plugin a part of IntelliJ IDEA itself. If you like Postfix, you want this plugin.

Plugin Page: https://plugins.jetbrains.com/plugin/9862-custom-postfix-templates

Custom Postfix Templates Preferences

I had come across this plugin a long time ago and was recently reminded of it when I was trying to create a Postfix template that combined .new and .var, i.e., one template that would take a class like Game and turn it into Game game = new Game();. I do this so often in tests that a shortcut would be very useful, but the built-in Postfix functionality doesn’t allow for this. I briefly looked at writing my own Postfix plugin, and instead rediscovered this plugin—problem solved!

The plugin not only makes creating custom Postfix templates easy, but also comes with hundreds of templates for all sorts of situations, including popular libraries. It also makes it easy to share templates with others.

PlantUML

Rating: ⭐️⭐️⭐️⭐️⭐️ (5/5 Stars) If you know PlantUML syntax, this is a must-have.

Plugin Page: https://plugins.jetbrains.com/plugin/7017-plantuml-integration

I love drawing diagrams, but I hate using visual drawing tools, because I spend so much time fiddling with the little things. I’ve been using PlantUML for years to draw sequence, class, and state machine diagrams by describing it in a text file. Having it as a plugin in IntelliJ IDEA makes it that much more valuable, especially with the quick view updates as I make changes.

Note: Be sure to install the correct plugin, there are similarly named ones that aren’t as good.

Git ToolBox

Rating: ⭐️⭐️⭐️⭐️⭐️ (5/5 Stars) If you use Git in a team environment, install this plugin.

Plugin Page: https://plugins.jetbrains.com/plugin/7499-gittoolbox

For better or worse (I think worse, but that’s a separate rant), Git is the de facto standard for version control. IntelliJ IDEA’s support for Git is great, but the plugin GitToolBox makes it even better. I rarely find myself using Git from the command line anymore, which I’m very happy about.

SonarLint

Rating: ⭐️⭐️⭐️ (3/5 Stars) Worth trying out, and can be especially useful in a team environment if customized.

Plugin Page: https://plugins.jetbrains.com/plugin/7973-sonarlint

I try to like SonarLint. It’s not that it’s not a powerful tool (it is), it’s just that I find myself constantly telling it to stop bugging me about things that I turn it off when teaching, and then forget to turn it back on when I’m just coding. Perhaps some more fine-tuning would get it to the right level of nudging, but I’m not there yet. However, it has saved me from some silly mistakes, so it’s worth installing and trying out.

Floobits

2022-02-01 I previously recommended this tool, but it hasn’t been updated in years, so would recommend trying CodeTogether instead.

Rating: ⭐️⭐️⭐️ (2/5 Stars) If you need to share the ability to share the editor, it’s worth trying, but can’t really recommend as it unreliable and hasn’t been updated in years.

Plugin Page: https://plugins.jetbrains.com/plugin/7389-floobits

The holy grail of synchronous editing of a project by multiple people has not quite been solved, but of the tools I’ve tried out (Floobits, CodeTogether, Code With Me, and GitDuck), Floobits has come closest to what I want: the ability to use the full power of IntelliJ IDEA, and let the other people use whatever tool they want. It’s not perfect and sometimes things get out of sync or just don’t sync in the first place, but when it works, it’s great. In the Mob Programming groups that I lead, though, I have shifted to using mob.sh as it’s much more reliable.

What About You?

What plugins do you find indispensable? Let me know on my Discord, on Twitter (as @JitterTed), or on Mastodon (as @jitterted@sfba.social).

Clarifying the Goal of Behavior Change

2021-03-05T10:00:00Z

Change Behavior with Predictive TDD

In my last post, I talked about the two main activities of Test-Driven Development^[1]:

Change Behavior: adding capabilities and features to a system, or, perhaps, fixing bugs. The goal is improving the lives of the folks that the system serves.
Increase Changeability: refactoring, or re-organizing the code to make it easier for us, the developers, to understand the code and make it easier to Change Behavior (now or later).

We’ll first look at the Change Behavior part of the cycle, often represented by the “Red-Green” parts of the TDD diagram:

TDD Cycle: Focus on Behavior Change

When I do (and teach^[2]) the Red-Green part of the TDD cycle, the steps I actually perform are more than two:

More Than Just Red-Green

Clarifying Your Goal

Let’s start with the first two steps, which seem simple enough…

Requires Thinking First

Before I did TDD on a regular basis, it always amazed me how much code I could write without being clear about the behavior I was adding. This became really obvious after I resumed my training work years ago. It was common for students to get stuck, so I’d ask them “what are you trying to do here?” Often, they couldn’t explain it, or did so in a way that was vague. After some back and forth, once they were able to verbalize the goal clearly, all of a sudden they knew what was wrong and how to proceed^[3].

Thinking First Helps

Therefore, being clear and precise—in a way that a unit test requires—helps you make sure you know exactly what you need to do. However, that’s not enough for a unit test. You have to be able to observe that the system does what you want it to do, i.e., you have to answer the second question: How Will You Know It Did It?

For example, if you’re thinking about the micro-feature (or “story” if you prefer):

The player gets a new card when they draw one from the deck

How will you know this worked? What, exactly, is the expected (and observable) outcome? Can you access that observation by directly asking an object for information, or do you have to dig into 3 separate objects for details? We’ll need to clarify the assumptions in order to really know.

Let’s start by rephrasing this story in Given-When-Then format^[4]:

Given a PLAYER with a HAND containing 2 CARDs,

When the PLAYER DRAWs a CARD from the DECK,

Then the HAND should have 3 CARDs.

Note the use of our DOMAIN terminology: player, hand, card, draw, and deck. Talking, thinking, writing, and discussing the functionality in those terms will not only help us figure out the desired behavior, but make sure we’re using the language correctly with our domain experts.

Now we have precisely defined the behavior we want to add—player draws a card—as well as how we can observe that it happened, by checking that the size of the hand is 3 cards, when it started with 2. (How do we know we started with 2? Sounds like a separate test!)

That’s a lot of work and thinking, but it’s exactly (and only) what we need to get to the next step, which is writing the actual unit test. We’ll look at that in the next part of this series.

The TDD Intro Series

Red-Green or Refactoring First?
Clarifying the Goal of Behavior Change (this article)
Predicting the Failing Test
Implementing the Feature
Tightening Our Assertions

I’ve had people say that the two main activities of TDD are writing a failing test and then making it pass, but that’s only a part of TDD and misses the other equally important activity: refactoring. ↩︎
I use JitterTed’s TDD Game to help teach this process. ↩︎
We often refer to solving problems by talking about them out loud, perhaps to a rubber duck sitting on our monitor, as Rubber Duck Debugging, or sometimes just Rubber Ducking. No human necessary. ↩︎
This way of thinking about the desired behavior comes from Behavior-Driven Development, which, as we’ll see in future posts, is very much TDD, working at different boundaries. ↩︎

Red-Green or Refactoring First?

2021-02-27T10:00:00Z

When it comes to Test-Driven Development, we often see it as a cycle consisting of three parts: RED, GREEN, and REFACTOR.

Typical Red-Green-Refactor TDD Cycle

I think about the process as two high-level activities:

Changing the behavior of the system via coded expectations: this is the RED-GREEN part of the cycle. We do this for “them”, i.e., the folks who asked us to solve their problem (or perhaps implement their solution) and make their lives better (we hope).
Preserving the behavior and making the code easier to understand. Can also be adapting it to the next thing we’re about to implement, i.e., the REFACTOR part. We do this for us, the humans working with the code, to make our lives better; to increase the changeability of the system^[1].

However, we don’t always need to start with a change in behavior (i.e., step 1), sometimes we start with making the code easier to work with via REFACTOR, which looks like this:

Starting the TDD Cycle with Refactoring

TDD is a cycle, after all, with a choice of where to begin. Though I treat each time we land in GREEN and REFACTOR as safe stopping points (where I’ll try to commit to version control). This is related to “Small Steps” and “Ready Points” (GeePaw Hill), which I’ll talk more about in a future essay.

Over the next several articles I’ll dive deeper into these two parts: Change Behavior (the RED-GREEN part) and Increase Changeability (the REFACTOR part).

The TDD Intro Series

Red-Green or Refactoring First? (this article)
Clarifying the Goal of Behavior Change
Predicting the Failing Test
Implementing the Feature
Tightening Our Assertions

How do you think about the TDD Cycle? Let me know on Twitter or join my Discord to discuss this and other topics!

Note that this is not the same as premature flexibility or speculative generality. ↩︎

Domain vs. Technical

2021-02-25T10:00:00Z

I was recently reminded (thanks to Jon Reid @qcoding) of a tweet I wrote back in July 2020:

When doing #TDD and writing unit tests, I try to write my expectations in the language of the domain (Ubiquitous Language from DDD) instead of primitives and collections. E.g., “dice roll contains four of the same kind” and not “list has four integers of the same value”.
— Ted M. Young #BlackLivesMatter #HexArch (@jitterted) July 9, 2020

At the time, I had just started teaching my new online class^[1], where this came up in a somewhat unexpected way. In the class, we’re working on fixing some Code Smells in the code of a console-based Blackjack card game. As part of the refactoring process, we extract code that compares the value of two Hands—the player’s and the dealer’s—to see if one of them Beats the other. We do the same for another method that compares the hands to see if they have the same value^[2], called a Push.

When extracting these methods, the temptation is to name these methods with TECHNICAL terminology, i.e., using compareTo() for the comparison method, and equals() for the one checking for hands having the same value. However, there are two problems with these names:

compareTo() has a specific usage in Java: for sorting, or with data structures that need ordering (such as TreeMap). Since Hand instances have no need to be ordered, using compareTo() would be misleading to readers of the code. Similarly, equals() has a specific technical meaning, but it would also be incorrect to say that two different Hand instances are equal if they happen to have the same total value of their cards.
If we’re defining public methods on a Hand class (a class concerned with an aspect of the Blackjack domain) that forms its API (what I call its “surface area”), those methods need to “speak” in the language of Blackjack. compareTo() and equals() are TECHNICAL names, so instead we prefer to use DOMAIN terms in the names: beats() and pushes().

Benefits

The benefit of using DOMAIN terms is that it reinforces that the class implements domain behavior. It also makes the code easier to understand, even for non-coders. For me, the biggest benefit is that it helps keep the public API of the class at the appropriate level of abstraction. So, my tests are testing DOMAIN behavior, not TECHNICAL behavior. This allows the code to be more easily refactored, as domain terms are often at a higher level of abstraction than technical terms, and less prone to arbitrary change.

Example

Technical vs. Domain Methods

Here, the first example uses a TECHNICAL method, contains(), which works, but asking (querying) the Hand whether it hasAce() is much clearer. If you do have a DOMAIN need to find out if a Hand has an arbitrary Card, you might want to look deeper at the domain meaning of such a query.

Domain Knowledge

All this assumes that, as a developer, you are familiar with the domain you’re working in. If it’s a Blackjack game, you should know the terms “busted”, “pushes”, “hit”, “surrender”, etc. If it’s an accounting system, you’ll need to know the meaning of “credit”, “debit”, “journal”, “ledger”, etc. While you can write code without much knowledge of the domain, the more you deeply understand it, and the better you can work with those who define what the system needs to do.

What Do You Think?

What domains do you work in? Does your code reflect the domain, or are methods more technical? How does that affect the testability of the code or the “brittleness” of the tests? Let me know on Twitter or join my Discord to discuss this and other topics.

Now called Refactoring to Testable Code. Subscribe to my newsletter, so you don’t miss future classes. ↩︎
In Blackjack, each hand has a numeric value based on the cards it has. For details, see the rules from my Blackjack game code that I use in my course. ↩︎

Human Learning (Video)

2018-10-30T10:00:00Z

Back in October 2018, I gave my 3rd iteration of my talk: “Human Learning: How We Learn & Why It Matters” at the Silicon Valley Code Camp. The video recording of the talk is on YouTube here:

https://youtu.be/SdvmMPcXK0Q

Slides are available here.