Ismael Celis

@ismaelcelis.com

From the Thinking in Systems book: “boundaries are problem-dependent, evanescent, and messy”. In the context of programming, unpacking that one sentence risks unraveling the entire concept of Object Orientation.

More progress in my Ruby library for data structures, typing and coercions. This time making it easier to compose your own code into these pipelines.

Bild

There’s better and worse CRUD frameworks, but CRUD itself is a very limited view of the world and chock full of foot guns, so not even the most finely crafted CRUD framework will keep your feet safe.

Elixir would have made the event sourcing part easier. Ismael Celis picked Ruby anyway, specifically so it would be harder. The constraint was the point.

Event sourcing gets a reputation for being heavy. Ismael Celis says the core of it fits in a Ruby file and an array. Everything else (the eventual consistency, the runtime, the workflows) is an optional rabbit hole.

Preparing a talk at the London Ruby User Group tomorrow. This is a reactive, server-rendered dataflow workflow in Ruby. The DAG component shows how steps run as soon as their dependencies are satisfied by other steps, so concurrent execution is self-organising.

I'm improving the integration hooks in my Ruby toolkit for reactive apps, and it's looking good! I've also made my Sourced library work as a regular job queue as well as an event sourced backend. So now you can have mix both styles with a single backend.

Bild

Often in programming, simplicity is found in identifying the superset of the problem. Ex: 1. web interactions are workflows. A single-page form is just a one-step workflow. Optimise for workflows. 2. HTTP responses are streams. A one-off response is just a very short stream. Optimise for streams.