Some amazing work.

Killer drumming.

Greg Young:

We will talk about what seems to be the most complex areas of event sourcing for most developers especially those first getting into it. Versioning.

Remapping the event stream is an approach we’ve used. I like the idea of emitting stop and stopped events to the store to support zero downtime migrations while remapping the stream.

Eric Evans on avoiding the pursuit of perfection when using DDD.

Chris, Andy, and Greg 😍

Dan North:

Over the last year or two I have been exploring OKRs—Objectives and Key Results—with several organisations, from a few hundred people in size to a couple of thousand. Some are well over a year in, some are just starting out. There doesn’t seem to be much out there in terms of experience reports or hands-on advice so I have tried to capture the advice I wish I’d had when I started out.

A different future.

Nick:

That’s my advice if anything terrible ever happens to you: Form a band and go on tour.

Formidable:

Clean and robust state management for React and React-like libs.

The library grew from the idea that state should be just as flexible as your React code; the state containers you build with freactal are just components, and you can compose them however you’d like. In this way, it attempts to address the often exponential relationship between application size and complexity in growing projects.

Like Flux and React in general, freactal builds on the principle of unidirectional flow of data. However, it does so in a way that feels idiomatic to ES2015+ and doesn’t get in your way.

The single state object, reducers, and selectors associated with Redux feels overwrought and often gets in the way. Freactal looks like an interesting alternative.

A scannable, erasable physical notebook.

Get your feet wet with some high performance computing.

Jan Stenberg:

The single biggest bad thing that Young has seen during the last ten years is the common anti-pattern of building a whole system based on Event sourcing. That is a really big failure, effectively creating an event sourced monolith. CQRS and Event sourcing are not top-level architectures and normally they should be applied selectively just in few places.

Young also believes there will be more use of Process managers, especially with more and more use of Actors since they for him make perfect Process managers. He describes an Actor framework as a Process manager framework.

Chris McCord:

Phoenix 1.3 moves away from models to (bounded) contexts and schemas.

It’s interesting to see a framework explicitly support this.

Feels like a good fit. Especially for a framework based on a functional language.

Heads in unexpected directions.

Hard and fast rules for building Redux applications.