Two weeks ago the internal developer tool was given a face; last week that face was wired to the instrument behind it, able to describe a schedule, show the days it falls on, and tell one schedule from another. This week it was neither extended nor redrawn. It was proved, and it was dressed for the open — the two unglamorous kinds of work that stand between a tool that happens to work and a tool you can set in front of a stranger. Thirty of the week's thirty-six closed items belonged to that single effort, and not one of them added a feature. They made what was already there trustworthy, and they made it fit to be published.
The first half was proof. A working tool is, until it is tested, only a claim that it works — and the tool now makes that claim answerable. A suite of tests was built around it in layers: unit tests over the domain, where the arithmetic of schedules actually lives, held to the strictest coverage; unit tests over the services that sit above it — the parsers, the calculator, the plain-language describer, the exporters, the comparer — so that each is checked in isolation; and, over the interface itself, component tests that drive the controls the way a person would. To those were added two kinds of test that catch what hand-written cases miss. Property-based tests do not check chosen examples but generate hundreds of their own and assert the rules that must hold across all of them. Snapshot tests pin the exact text of every description, every calendar export and every error message, so that no wording changes unnoticed. A benchmark project was stood up to keep an eye on speed, and coverage reporting wired in to make the untested parts visible rather than assumed.
Proof of that kind earns its keep the moment it finds something, and this suite did so twice. It turned up a genuine divergence in the tool's own reading of ordinary cron: where a schedule restricts both the day of the month and the day of the week, real Unix cron treats the two as alternatives — it fires when either matches — while the library beneath the tool had quietly been combining them the other way, as a conjunction, so that a rule meaning “the 1st, or any Monday” was being read as “the 1st, but only when it is a Monday.” It is exactly the sort of fault no amount of re-reading finds and a generated test catches on its first pass; it was corrected to match the convention the rest of the world keeps. The second was nearer to home: the release pipeline had been cancelling its own merge builds — a regression in which two unrelated events had come to share a single concurrency group. Both were fixed. Neither would have been a comfortable thing to discover after release rather than before it.
— On readiness —Working is where a tool becomes useful to the person who made it. Tested, documented and declared is where it becomes fit to be handed to a stranger.
The second half was publication: everything a tool must carry before it can be left out for people who did not build it and cannot be talked through it. The documentation was written — an introductory page saying plainly what the thing is; a reference for each of the dialects it speaks, since a line of cron means subtly different things under Unix, under Quartz and under Amazon's EventBridge, and a tool that accepts all three owes the reader an honest account of each; a page that sets those dialects side by side for the differences that most often catch people out; and a cookbook of worked examples to copy from rather than derive. Beneath the writing went the apparatus of standing in public: a privacy notice, a vulnerability-disclosure policy, and a machine-readable security file to the recognised standard, so that anyone who finds a flaw knows exactly where to send it; a credits page and a third-party-notices file that acknowledge in full the open work the tool is built upon; and confirmation that the practice's data-protection registration properly covers it. Last, the quiet mechanics of being on the web at all: guidance for the crawlers and a sitemap, a set of security headers and a content policy, a build-mode page, and a real 404 for the reader who arrives somewhere that isn't there.
A handful of smaller things were closed in the same pass: the way the tool holds its whole state in a shareable link, tidied and signed off; the input rows given another turn of polish; a cheatsheet of the grammars a reader can keep open beside the field as they work; and a considered message for the reader who arrives on a link mangled in transit, explaining the quiet fall back to a clean state rather than failing without a word. Small work — but it is the difference between a tool that behaves well only when everything goes right and one that behaves well when it doesn't.
Beyond the tool, the practice's own longer-running side project went on as it has. The family-history web application — a quieter build, carried in the background — kept its cloud foundations moving: the hosting and the database settled on a familiar platform in the London region, and the pipeline that will build, test and deploy it still being wired together. Nothing there reached Done this week; it is the kind of groundwork that is meant to take its time.
The smaller stewardship was kept, as it always is. For a local dog-training club the week's work was a handover rather than a build: its treasurer stepping down, and so the outgoing accounts and responsibilities written up into a proper report, distributed to the committee, walked through in a handover meeting, and the remaining tasks reviewed so that nothing falls between the two holders of the post — and, while the books were open, the club's venue booked for the rest of the year. And for the retained veterinary practice, the recurring hygiene a modest site needs and rarely shows: another clear-down of accumulated contact-form entries, and a routine health check of the machine behind it.
Looking ahead: the internal tool, now proven and documented, has little left between it and release — the last checks before a thing of one's own is set out where anyone can reach it; the family-history application goes on laying its foundations; and the retained clients go on being kept, as they always are.
Thirty-six items to Done across three projects — thirty of them a tool of our own, this week neither extended nor redrawn but proved correct and made fit to publish: wrapped in tests that promptly caught two real faults, and dressed in the documentation, policies and plumbing a thing needs before strangers can use it. The smaller work was quietly kept, and the practice's own longer build went on beneath. The same deliberate, unhurried practice — with the inward thing now all but ready to be passed on at last.