I’ve kept talking about command-driven and event-sourced apps in Ruby, to anyone who’ll listen.
I was on the Dead Code podcast talking about my WIP Ruby stack.
Listen to the podcast here (or on your preferred app).
I also spoke (again) at the July 2026 edition of the London Ruby User Group. This one was about Sidereal, my Ruby framework for building command-driven, reactive…
For a number of years now, I’ve been hacking on several side-projects in parallel, whenever I can. 
 They try to scratch different itches and explore different ideas, but they all build on a common, evolving intuition about how I’d like to think about building software. Recently, these projects have started converging into a somewhat unified Ruby stack. 
 I’ll describe…

 
 
 
 Watch the talk on YouTube 
 
 I gave a talk at Wroclove.rb , in Poland, this April. It was originally going to be about the Actor Model in Event Sourcing, but I changed it to Building reactive systems with Ruby and Event Sourcing .
This is a presentation about durable messaging, Event Sourcing and Ruby that I gave at the London Ruby User Group this past November. 
 
 

The conventional distinction between “foreground” request handling and “background” operations in web development is broken, misleading, and incomplete. 
 There, I said it. 
 
 
 Conventional browser, controller, background job flow 

Video of a presentation on Ruby and Event Sourcing I gave at Baltic Ruby 2025 back in June. 
 
 
 
 
 Watch the talk on YouTube 

Our experience of reality is based on the passage of time. Things begin and end, events happen one after the other. The world changes .
And yet we model software as static object graphs frozen in time.
I was recently invited to chat at the Dead Code podcast (thank you for the invite!), about Event Sourcing and Ruby. Here are some notes (and corrections!) from the conversation.
I’ve been playing with and exploring Event Sourcing for a while now, but only recently realised that part of my thinking might have been muddled by unexamined assumptions about what commands are and what they do in the context of Event Sourcing.
The Decide, Evolve, React pattern provides a unified mechanism for expressing, handling and reacting to state changes in a system.
It optionally provides a lossless audit trail of changes, and the seeds of a pub/sub sub-system, by tying together events to the state changes they cause.
It’s a generalisation of the Event Sourcing pattern, but it doesn’t require a log of events or…
In this series:
Part 1: Practical Railway-Oriented Pipelines in Ruby Part 2: User input, errors and metadata Part 3: Extending pipelines Part 4: Middleware Part 5: Testing pipelines Testing pipelines. Testing any complex workflow can be challenging. Composable pipelines can make it easier to use a “divide and conquer” approach to testing.
1. Unit test each step in isolation.…
In this series:
Part 1: Practical Railway-Oriented Pipelines in Ruby Part 2: User input, errors and metadata Part 3: Extending pipelines Part 4: Middleware Part 5: Testing pipelines In the previous article in this series I showed how to extend the basic pipeline with domain-specific steps and helpers.
Here I’ll show how to add middleware to the pipeline, to add tracing, logging,…
In this series:
Part 1: Practical Railway-Oriented Pipelines in Ruby Part 2: User input, errors and metadata Part 3: Extending pipelines Part 4: Middleware Part 5: Testing pipelines In the previous article in this series I showed how to pass extra metadata from one step to the next, including user input, errors and context data.
This article expands on the previous ones by showing how to…
In this series:
Part 1: Practical Railway-Oriented Pipelines in Ruby Part 2: User input, errors and metadata Part 3: Extending pipelines Part 4: Middleware Part 5: Testing pipelines In the previous article I described a bare-bones implementation of Railway-oriented pipelines in Ruby. I showed how to build pipelines of steps that can be executed sequentially, with each step receiving the result…
In this series:
Part 1: Practical Railway-Oriented Pipelines in Ruby Part 2: User input, errors and metadata Part 3: Extending pipelines Part 4: Middleware Part 5: Testing pipelines Some years ago I explored patterns for building composable processing pipelines in Ruby, using a Railway-oriented paradigm.
In this series, I’ll describe a simplified implementation for practical…
This is part of a series on Event Sourcing concepts, with Ruby examples. Read the previous part: Event Sourcing with Ruby examples. The Event Store interface.
The Command Layer is conceptually the place where business logic happens, user input is handled and decisions are made.
It’s not by any means unique to event-sourced apps, but present in all kinds of software in one way or the…
This is part of a series on Event Sourcing concepts, with Ruby examples. Read the first part: Event Sourcing from the ground up, with Ruby examples, part 1.
The Event Store interface is the canonical data store in event sourcing, and it’s in charge of persisting and retrieving events produced by your system.
#append_to_stream(stream_id String, events List<Event>) boolean…
In this series I’ll go over the basic concepts in Event Sourcing. The code examples are in Ruby, but the general principles should apply in any language.
What’s Event Sourcing The essential idea is that the state of objects in an app is tracked by a sequence of events describing discrete changes to those objects. For every state change, an event is produced and appended to a log in…
An exploration of patterns for building composable data pipelines in Ruby, from the basics to the possibly YAGNI.
Function composition Ruby’s function composition allows you to neatly chain Procs together using the #>> operator.
DISCOUNT = 200 substract_discount = ->(amount) { amount - DISCOUNT } TAX_RATE = 0.19 add_tax = ->(amount) { amount * (1 + TAX_RATE) } calculate_total =…