Canopy - tags, labels, and reaching outside the image

Canopy - tags, labels, and reaching outside the image Canopy's mechanism, from the first part of this pair, in short: a singleton that is itself a tree, domains hanging off it by name, and at every leaf either a raw CanopyCell or a CanopyAccessor binding that position to a live object through two independently optional selectors - one for reading, one for writing. Config and metrics turn out to be

Canopy - I have global values

Canopy - I have global values Every config value starts the same way: you just need it, right now, and the fastest path is to write it straight into the method that uses it. A credential, a limit, a base URL - hardcoded, because reaching for a whole configuration mechanism for one value feels like overkill, and you don't want to be slowed down by ceremony you don't need yet. That's fine, right up

Soil: checkpoints and recovering from a crash

Soil: checkpoints and recovering from a crash The transactions post left this dangling: "if any of this actually changed the database, Soil checkpoints afterward - flushing everything to disk in a way that can survive a crash. What a checkpoint really guarantees is its own post." The journal post added its own loose end on top: every fragment file has to start with a checkpoint entry, for reasons

Soil: the journal, and what makes it a WAL

Soil: the journal, and what makes it a WAL The transactions post left this one dangling: "Every new or changed object, every index update, and the new database version becomes an entry in a journal - an in-memory list first, not yet on disk [...] The journal is central enough to deserve a full post of its own later." This is that post. From transaction to journal entries The thing a transaction as

What's hitting my static blog, and where it's coming from

What's hitting my static blog, and where it's coming from Anyone running a publicly reachable webserver gets visitors fast. Not necessarily human ones. This blog is produced by a static site generator and served by nginx: a handful of HTML files, some CSS, a few images, nothing else. No WordPress, no PHP, no CMS, no application behind the webserver at all - there's no login form to brute-force, no

Soil: knowing what changed

Soil: knowing what changed The transactions post left this on the table with a one-line mention: "'Dirty' itself comes from one of two tracking strategies - either you mark an object dirty yourself, or, as of the current version, Soil detects changes on its own by hashing an object's content and noticing when that hash no longer matches." That's the whole subject of this post: what those two strat

ESUG 2026 in Plovdiv, Bulgaria

ESUG 2026 in Plovdiv, Bulgaria Plovdiv was a very pleasant visit. Living in Cologne, I'm fairly used to having a lot of history around - a bit over 2,000 years of it. Plovdiv is a whole level more extreme: 8,000 years of continuous settlement, and with a location like that, centuries of shifting rule and changing hands to match. A guided city tour walked us through a good chunk of that: Thracian r

Soil: catching write conflicts, optimistically

Soil: catching write conflicts, optimistically Every transaction in Soil gets to act as if it has the whole database to itself - read whatever it wants, take its time deciding what to change, and work all of that out without ever announcing itself to anyone else running at the same time. That's a comfortable illusion right up until two transactions both decide to change the same thing. Something h

Soil: MVCC and snapshot isolation

Soil: MVCC and snapshot isolation The last post walked through what a commit actually does: serialize outside any lock, then take one global lock just long enough to bump the database version, check for conflicts, write the journal, and apply it. Only one writer gets to be in that critical section at a time - the same trade-off SQLite makes. Readers, though, were said to bypass that lock entirely

OpenAPI, brought up to spec

OpenAPI, brought up to spec The last post told JSONSchema's origin story: it exists because ApptiveGrid needed OpenAPI, and OpenAPI needs a way to describe request and response bodies. OpenAPI is the other half of that story - a Pharo implementation of the OpenAPI 3 specification, three packages deep: OpenAPI-Core models a document as an object tree and can validate a whole document against the sp