Dave Copeland:

When a dangerous or difficult-to-undo operation must be performed, but it cannot be made idempotent without more context, use an Idempotency Key.

Eric Normand:

But there’s a deeper problem. I actually think ten lines of code is too big for an abstraction (Metz agrees). Ten lines of code that happen to be repeated are so unlikely to have any interesting properties, including being bug-free, reusable, and composable, that you should be very skeptical of being able to factor the whole thing out as common.

However, don’t despair! You can more often than not find lots of one-, two-, or three-line bits of code that are 1.) easy to name and 2.) reusable. If you break enough of those out, you may start to see some underlying structure to those repeated ten lines as they become replaced by your new, small abstractions.

In graphs.

UpGuard has discovered an open database containing information on what appear to be approximately 198 million American voters left misconfigured by a GOP analytics firm.

ASCII art editor for macOS. Great for adding diagrams alongside code.

A slick set of React UI components.

Lessons for leakers and journalists.

Printers drawing secret fingerprints.

Everything’s a fold.

Shows a distinct lack of crocodiles.

A map of pain.

Off the hook.

Ripper.

CellF is a neural synthesiser. Its “brain” is made of biological neural networks that grow in a Petri dish and controls in real time it’s “body” that is made of an array of analogue modular synthesizers that work in synergy with it and play with human musicians.

Watch stone carver Anna Rubincam as she goes from measuring a live person to a clay model to a finished stone portrait in three weeks.

Seeya Chris 😢

Some nuggets of gold in this.

Rails to React.

Brandur Leach:

It’s not that new technology should never be introduced, but it should be done with rational defensiveness, and with a critical eye in how it’ll fit into an evolving (and hopefully ever-improving) architecture.

It suggests improving increasing productive output by continually improving the efficiency of a system even while keeping input the same. I project this onto technology to mean building a stack that scales to more users and more activity while the people and infrastructure supporting it stay fixed.

Programming calendar time is hard.

I always enjoy the behind the scenes stories of comedians.

A look into some of the inspiration and decisions in the design of Elixir.

Jujitsu and meditations on narrative and consciousness.

A visual demo.

Ben Smith:

Building applications following domain-driven design and using CQRS feels really natural with the Elixir – and Erlang – actor model. Aggregate roots fit well within Elixir processes, which are driven by immutable messages through their own message mailboxes, allowing them to run concurrently and in isolation.

I too think that Elixir is a good fit for CQRS/ES applications.

The post provides a thorough walkthrough that builds an event sourced/CQRS Elixir application using Phoenix, Commanded, and Eventstore. The Commanded and Eventstore libraries look to have implemented most of the features I’m looking for.

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.

Tasty.

Heads in unexpected directions.

Hard and fast rules for building Redux applications.

Cap’n Proto RPC:

Cap’n Proto RPC employs TIME TRAVEL! The results of an RPC call are returned to the client instantly, before the server even receives the initial request!

There is, of course, a catch: The results can only be used as part of a new request sent to the same server. If you want to use the results for anything else, you must wait.

However, Cap’n Proto promises support an additional feature: pipelining. The promise actually has methods corresponding to whatever methods the final result would have, except that these methods may only be used for the purpose of calling back to the server. Moreover, a pipelined promise can be used in the parameters to another call without waiting.

An interesting feature which limits the number of network hops in the query is a pipeline of dependent requests.

Phil Calçado:

In my experience, a good-enough specification for a pURI should specify:

• How many segments are there and if teams and service owners can add new segments
• What is the encoding and escaping expected for the text
• What in the identifier should be treated as opaque data as opposed to parts where consumers can make assumptions about data formats

We’ve been playing with almost the exact same scheme recently for some of our services.

Vladik Khononov:

From my point of view, the CQRS-induced complexity is largely accidental, and thus can be avoided. To illustrate my point, I want to discuss the goal of CQRS, and then analyze 3 common sources of accidental complexity in CQRS-based systems.

I find myself nodding to the sentiments of this post. It feels like doggedly pursing a theoretical ideal can lead to unnecessary difficulty in CQRS implementations.

Magnets blasting your head.

That’s gonna take a while.

Just in case.

Fascinating.

I feel like we’ll be needing more and more of these.

How to follow good practices with Bash.

Presented with typical beauty from The Food Lab.

Designed by Jørn Utzon.

From MIT 15.S50 Poker Theory and Analysis.

An introduction to unix sockets in Ruby.

Forty years of work.

Want multiple Gmail web UIs next to each other? This is your bunny.

A catalog of logos, symbols, and trademarks.

Jesper L. Andersen:

In the recent years, I have adopted a method for system design, which I think yields good results. For a lack of better word, I overloaded “stack” yet again, and use it as a metaphor for this design.

The baseline is level 0 in the stack, and now we try to move the system upwards in the stack by adding another level. It is important to stress that transitioning is a best effort method. We make an attempt at increasing the operational level of the system, but if we can’t we stay put at the current level.

Jan Stenberg quoting Eric Evans:

Evans points out that a microservice, which should be autonomous, can be a good bounded context, but emphasizes that this does not mean that a service always is a bounded context, something that developers sometimes interpret it as.

Some interesting points in here about using multiple bounded contexts within a system to make it easier to work on.

Sometimes a model is a little incomplete, lacking the ability to handle all the cases it’s meant to handle. Instead of creating a model that is able to handle more cases but feels awkward, an alternative may be to create a function that deals with cases not handled by the model. Such a function works with lots of if-then-else statements, staying away from any high-level concepts to avoid creating yet another model. An abstraction that is leaking or confusing should not be used at all. Evans notes that it’s better to use if-then-else instead of creating an illusion of an elegant model. Such a model may even prevent finding a working model. He believes that this is a great example of a trade-off, aiming for a good but not perfect design.

I think this is a pragmatic approach. Finding an all-encompassing model can be paralysing.

The Mikado Method is a structured way to make major changes to complex code. It helps you visualize, plan, and perform business value-focused improvements over several iterations and increments of work, without ever having a broken codebase during the process.

Jesper Andersen:

In any kind of process planning in a factory, people know the price of running the plant at 100% utilisation: it gets sensitive to small errors. So nobody does that.

A look at error handling in event sourced systems.

👌

HST reads his essay documenting his dabbling with electricity.

A solid React/Redux boilerplate.

Simplicity of programme, Kettlebell, and not training till failure.

KD plus f-bombs.

Deep.

Plug in and get some work done.

Bang on.

Flying car concept.

Protecting artists from the banned countries.

An example application built with React + Redux that includes auth and remote data fetching.

Julia Evans:

in this post we will dissect an SSL certificate and try to understand it!

Are we all a projection from some two dimensional image?

I don’t even.

Goosebumps.

Nice QA checklist for launching a website.

Robert Reppel:

… smaller subsystems communicate via agreed-upon contracts (commands and events). Each has their own data store. Eventsourcing and the CQRS pattern are used to reduce coupling (and therefore the potential for side effects) to a minimum.

What makes the combination of event sourcing, Domain Driven Design and CQRS so attractive is that it can greatly simplify building software which keeps subsystems cleanly separated and independently maintainable as more features are added over time, akin to what we have learned to do for cars, spacecraft and toasters.