projects

tinyblok is the obvious next experiment after monoblok: can the patchbay run on a microcontroller and ship sensor data straight into a remote NATS cluster? In the original post, the Peter’s Porsche Rentals worked example put a Raspberry Pi behind the glovebox; an ESP32 is an order of magnitude cheaper and smaller. Coupled with a 4G mi-fi or the car’s onboard Wi-Fi, it’s a self-contained edge node that can sit on a OBD2 dongle’s worth of power and select what crosses the mobile data connection....

Note from the future: the mixer was built when patchbay evaluation was the per-process bottleneck. Turns out patchbays are seriously fast, and the mixer’s own parse loop (every byte gets parsed twice, once at the mixer and once at the worker) tends to cap before the workers do. Sustained-load measurements have the mixer pinned at one core while workers sit at ~50% each. Deviating from the clean single-loop model was a mis-step....

Market data moves fast. Imagine your data provider gives you a stream of JSON frames that carry several fields per message, and every downstream subscriber re-implements the same demux, round, dedupe, alert logic. At scale, doing this n times causes read/write amplification and much wasted work, not to mention subtle bugs. Doing it once at the broker means that subscribers can use subject filtering to pick the slice they actually need and ignore the rest....

There’s now a public monoblok demo server you can use with any NATS client to try it out. It is at nats://monoblok.rtd.pub:4222, docs at demo.md. Grab the nats CLI, save the demo server as a context once, and select it so you don’t have to type the URL every time: nats context save monoblok-demo --server nats://monoblok.rtd.pub:4222 nats context select monoblok-demo Now nats pub and nats sub go straight to the public demo server....

Want to jump straight to the code? A car publishes its engine RPM ten times a second. A market data feed ticks on every quote. A cheap temperature sensor posts a fresh reading every two seconds, mostly identical to the last one. Data moves quickly, but most of it is noise: a publisher that doesn’t know what its subscribers care about, and a fleet of subscribers each writing the same defensive code to round, debounce, and ignore the boring readings....

Watching a feed, deriving a few values, and firing an alert when something looks off shouldn’t require a Kafka cluster, a JVM, and three days of ceremony. For a lot of problems, it doesn’t. NATS is a natural hub for streaming values: lightweight, subject-routed, no schema enforcement. The missing piece is somewhere to do the computation. It turns out Excel is a left-field but fairly compelling answer. It puts stream processing in the hands of analysts who already know how to use it, without asking them to learn a new framework or become developers overnight....

The Excel C SDK dates from the early 1990s. Memory management is manual, the type system is painful, and there’s almost no tooling. Despite all of this, it remains the only way to build add-ins that run truly in-process with Excel, supporting multi-threaded recalculation and the full breadth of what the host application can do. If you want the best possible performance, you need an XLL. But it’s a foot gun....