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.

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.

Fascinating.

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