Ismael Celis

Sunday hack: now that my Ruby Eventsourcing library has an API for statecharts (nested state machines), I reused it to model the lifecycle of consumer groups running in the background, including failures and retries.

Today in Ismael's Confirmation Bias ™️: video on how "executable specifications" are the way forward for coding. I've been trying to build this for a while now! www.youtube.com/watch?v=EkH_...

Guys if you think type systems are beneficial because they make invalid states impossible (they are), think of declarative state machines as a type system for your app’s behaviour. They make invalid paths through your system impossible.

There's a lot of talk about how abstractions and frameworks don't matter anymore.

IMO append-only logs are obviously a simpler way to reason about software, and they remove a whole class of problems, but CRUD-pilled devs find it really hard to grasp (and for me to explain). There’s something fundamentally different about the structural / causal views of software design.

It also took me a long time to fully internalise, but I never found CRUD simple to reason about, so I had an incentive to keep exploring. I wonder if it’s just a personality thing.

And here it is! Event-sourced, server-rendered, async, nested state machines in Ruby!

This afternoon's hack: the Sidereal CLI now prints the full runtime's boot/configuration topology

It also supports a "--mermaid" option

Good progress of my configuration Ruby library. Libraries can declare typed components, host apps can implement them and declare their dependencies. It does dep. resolution and starts/stops components in the right order. And it can be inspected without running. Here, Mermaid for dep. graph, and tree

ENV values are transparently decoded via Plumb's form codec. You just declare the Ruby type of your component, and the library coerces it for you. Example: dates, Money, your own custom types.

Good progress of my configuration Ruby library. Libraries can declare typed components, host apps can implement them and declare their dependencies. It does dep. resolution and starts/stops components in the right order. And it can be inspected without running. Here, Mermaid for dep. graph, and tree

Something very common with English-speaking academics: impressive knowledge of the subject (here: conquest of the americas) while utter ignorance of the languages (basic Spanish pronunciation). It’s so jarring!

I don’t expect impeccable accent but at least be aware that the Spanish “J” never sounds as in “Jane”! Or how can you be an expert on a guy called Velasquez and not know that the U is silent. It just makes me doubt their expertise.

Use LLMs, but at the end of the day your boss or client will ask you (or their LLM!) how the app works, and expect a clear answer. Comprehensibility-has always been the bottleneck, and MVC/CRUD has never led to comprehensive systems at scale, LLMs or not.

I may or may not be building yet another DI system for Ruby.

Live inspection of the running system

I may or may not be building yet another DI system for Ruby.

You can use it for simple config values, but also components that have a lifecycle, such as workers that run in threads or fibers (you can do this with Dry::Types too, I think)

I may or may not be building yet another DI system for Ruby.

I made good progress with an app generator for Sidereal, my framework for reactive, command-driven apps in Ruby. It generates an app with a default directory layout, a CLI, and an initial app that shows how you can send commands from anywhere. Reactive and multiplayer by default!