My Presentations

Here you’ll find upcoming talks, presentations, meetups, etc., and slides, source code, recordings, etc. from talks I’ve given in the past.

Upcoming Talks

Clear up Messy Code with Refactoring Maneuvers in IntelliJ IDEA - March 4-6, 2026 (DevNexus, Atlanta, GA, USA)

• Conference site: https://devnexus.com/events/clear-up-messy-code-with-refactoring-maneuvers-in-intellij-idea

• Abstract:

  IntelliJ IDEA is an amazingly powerful development tool, providing automatic refactorings such as Extract Method, Introduce Parameter, and many more. But are you taking advantage of its full power? Do you stick with the Extract and Rename refactorings because you’re not sure how to use the more complicated ones?

  In this session, you’ll see how and when to use the many refactorings available to you. You’ll learn about higher-level Refactoring Maneuvers, such as Cohere Method and Expose Details, and how they combine and sequence IntelliJ IDEA’s automated refactorings to make your code more understandable and testable.

  This session will cover:

  • Extract Method
  • Introduce Parameter
  • Move (Instance/Static) Method
  • Make Static
  • Inline Method
  • Introduce Constant
  • Extract Delegate (and Enum)
  • Introduce Field

  Along the way you’ll learn about a wealth of keyboard shortcuts to save your brain from having to think hard.

Refactoring Tests - March 26, 2026 (online)

• Register at Seattle Software Crafters Meetup

• Abstract:

  Tests are code, too, but don’t get as much attention as production code, often leaving messy, hard to understand tests. Poorly factored tests can also make refactoring production code that much harder.

  In this session, we’ll start with what we need from a good test, using AssertJ and JUnit features to make it readable and maintainable. We’ll walk up the ladder from Helper methods, shared Factory Methods, all the way to Test Data Builders, using automated refactoring tools to easily make the transition. We’ll look at test “smells” and how to repair them, using Parameterized Tests, finishing with how to “retarget” your tests when extracting a new production class from existing code.

Testable Architecture - April 22, 2026 (JCON Europe)

• Conference site: https://schedule.jcon.one/2026/session/1052968. This is the shorter 20-25 minute version!

• Abstract:

  One of the most important, yet misunderstood, aspects of Hexagonal, Clean, and Onion architectures is not their folder structure, but how they keep I/O and domain logic separate. Why? The clear separation makes it easier to write tests: by moving away from the confusing terms of “unit” and “integration” tests to “I/O-based” and “I/O-free”, there’s no longer any confusion about how the test should be structured.

  In this Java code-filled session, we’ll look at how to combine Hexagonal Architecture with Domain-Driven Design’s context boundaries and tactical patterns to make it clear what code goes where and how to test it. We’ll also see how to refactor “mixed up” code to separate I/O from domain and application logic. The result is extremely fast tests for the most important part of your application, the domain, while also reducing the number of tests needed for coordination.

Past Talks

Want me to give one of the talks below? Contact me! ted@ this domain.

Testable Architecture: Ya Gotta Keep 'em Separated (Dec. 10, 2025)

• Recording on YouTube

• Presentation slides

• Source code for Ensembler

  • This is the code for the Ensembler project that I used for some of the examples.

• Source code for other examples used in the presentation.

• Abstract:

  One of the most important, yet misunderstood, aspects of Hexagonal, Clean, and Onion architectures is not their folder structure, but how they keep I/O and domain logic separate. Why? The clear separation makes it easier to write tests: by moving away from the confusing terms of “unit” and “integration” tests to “I/O-based” and “I/O-free”, there’s no longer any confusion about how the test should be structured.

  In this Java code-filled session, we’ll look at how to combine Hexagonal Architecture with Domain-Driven Design’s context boundaries and tactical patterns to make it clear what code goes where, and how to test it. We’ll also see how to refactor “mixed up” code to separate I/O from domain and application logic. The result is extremely fast tests for the most important part of your application, the domain, while also reducing the number of tests needed for coordination.

Event-Sourcing From Scratch (Nov. 25, 2025)

• Recording on YouTube - please like & subscribe 😁

• Presentation Slides

• Source code for JitterTicket

  • Note there are two branches (or perhaps one by the time you read this):

    • main was the main line of development, adding a “global event sequence” in a certain way, but Daniel Ranner (aka @Suigi) suggested an easier alternative, which is being worked on in the suigi-separate-global-sequence-as-param branch. Eventually this will become main and the original idea will become a dead-end branch.

  • As mentioned, I continue to work on this code base on my live coding stream. Recordings will eventually make their way to my YouTube channel.

• Books, People, etc. References

  • Greg Young (no relation) came up with CQRS and is the creator of the EventStore database. He has a few books on the topic:

    📘 Event-Sourcing is a book aimed at beginners.

    📘 Patterns of Event-Sourced Systems is a “design patterns” book on event sourcing.

  • Martin Dilger wrote a book on Understanding Event Sourcing and Event Modeling and also writes a lot on LinkedIn about those topics.

  • Yves Goeleven talks a lot about patterns, event-sourcing, and other interesting architecture/design topics.

  • Real-World Event Sourcing is a short book that uses Elixir for its examples. (You can use the discount code SAVE50 for 50% off until December 1st.)

Event-Sourcing From Scratch at dev2next, October 2025

• Presentation slides

• Source code for JitterTicket

• Abstract

  • Event-sourcing allows the business to ask questions about your application’s data that weren’t thought of when the system was created, such as “how often are customers changing their shipping address?”. Event-sourcing is like version control for your data, with meaningful commit messages, allowing you to understand not just what the current state is, but how it got there.

    In this session, you’ll learn how event-sourcing works at the code level without event-sourcing libraries getting in the way of deeper understanding. We’ll walk through a codebase for a Concert Ticketing system and see how straightforward the implementation can be.

    We’ll start with modeling the events, the commands (user actions) that generate them, the aggregates that make business decisions, and the projections used to generate the user interface. We’ll look at the (Java) code that implements these concepts and see how event-sourcing makes testing easier to write and understand.

    We’ll end by touching on the challenges to using event-sourcing, such as performance and schema evolution (versioning).

JUnit Tests Need Refactoring, Too at dev2next, October 2025

• Presentation slides

• Source code for Ensembler

• Source code for Blackjack

• Abstract

  • Tests are code, too, but don’t get as much attention as production code, often leaving messy, hard to understand tests. Poorly factored tests can also make refactoring production code that much harder.

    In this session, we’ll start with what we need from a good test, using AssertJ and JUnit features to make it readable and maintainable. We’ll walk up the ladder from Helper methods, shared Factory Methods, all the way to Test Data Builders, using automated refactoring tools to easily make the transition. We’ll look at test “smells” and how to repair them, using Parameterized Tests, finishing with how to “retarget” your tests when extracting a new production class from existing code.

Testable Architecture: Keep 'em Separated at Commit Your Code, September 2025

• Video recording of talk is here

• Slides are available here

• Source code repository is here

• Abstract

  • One of the most important, yet misunderstood, aspects of Hexagonal, Clean, and Onion architectures are not their folder structure, but how they keep I/O and domain logic separate. Why? The clear separation makes it easier to write tests: by moving away from the confusing terms of “unit” and “integration” tests to “I/O-based” and “I/O-free”, there’s no longer any confusion about how the test should be structured.

    In this Java code-filled session, we’ll look at how to combine Hexagonal Architecture with Domain-Driven Design’s context boundaries and tactical patterns to make it clear what code goes where and how to test it. We’ll also see how to refactor “mixed up” code to separate I/O from domain and application logic. The result is extremely fast tests for the most important part of your application, the domain, while also reducing the number of tests needed for coordination.