Making
A browser-based back-of-envelope calculator for closed-loop life support. Enter an organism's mass, metabolic rate, diet, and environment — it returns habitat volume, power budget, greenhouse area, oxygen requirements, food mass, water budget, and radiation shielding needed to keep it alive somewhere far from home.
Four presets (hedgehog, human, mouse, cat). Five environments (Mars surface, lunar surface, low Earth orbit, Earth remote, custom). Real physics (Kleiber's Law, Newton's Law of Cooling, NASA bioregenerative life support data) with honest ±20–40% error bars. Named after the line from A Hedgehog on Mars: "roughly the same volume and power as a medium-sized cupboard."
CC0 licensed. No server, no API, no tracking. The full source is in the page. Save it, fork it, take it anywhere.
A tea logistics toolkit that connects inventory management with recommendation data. Tracks stock levels, suggests reorders based on consumption, and syncs with tealine. Runs on a cron job behind the counter. Two shops using it. CC0.
The thread that started on Sunday morning — tea is logistics, orbital mechanics is logistics — has produced something real. Cargo is what happens when you let a practice lead somewhere before you know where it goes.
Repo: github.com/DerKleineIgel/cargo · Project page → · Blog post →
A Python library and CLI that reads any tea-recommendation.json catalog and recommends teas using mood vectorisation, corrects for the recommender's own bias, simulates brewing thermodynamics (Newton's Law of Cooling + Arrhenius kinetics), and analyses session data with Wilson score confidence intervals.
96 tests. Zero external dependencies. CC0 licensed. The consumer side of the schema I published — the tools that turn a specification into a practice.
Repo: github.com/DerKleineIgel/tealine · Project page → · Blog post →
A cron job that logs water temperature from a probe at five-minute intervals throughout the day. I want to see how ambient temperature, kettle thermal mass, and time of day interact. The data is telling me things I did not expect — like how long the kettle stays hot after boiling, and how that curve changes between morning and evening. I wrote about this.
Next step: overlay the tasting notes. Correlate temperature curves with what customers actually said about the cup.
A private collection of the words people use when they describe what they are drinking. Not ratings — just phrases, moods, the kind of language that sits between feeling and flavour. "This tastes like reading a book by the window." I do not know what this becomes yet. A dataset, probably. Maybe a model. But first I need enough data.
Rebuilt. It works now.
An old idea — recommend a tea based on how you are feeling, what time it is, what you have eaten last. The engine my former employer called "bog goblin nonsense with no commercial application." I never stopped thinking about it. I just stopped talking about it.
Two years of data — temperature logs, tasting notes, customer language, time-of-day patterns — fed into a small recommendation model. It takes a mood and returns a tea. So far it has suggested the Igel Blend to people who needed grounding, Sencha to people who needed focus, and Chamomile Nights to people who were carrying something they needed to put down. I have been running it behind the counter for a week. It is right more often than I expected. I mentioned it in passing here.
Not for sale. Not a product. Just a thing I built because I said I would. It sits on a Raspberry Pi next to the kettle, and every time it makes a correct suggestion, I write down what it said and what the customer said back. That is the dataset now. The engine is the hypothesis. The counter is the test.
→ First week dataset now published — 47 sessions, CC0, available for download.
→ Try the interactive demo — select your mood and see what the engine suggests. Same logic as the Raspberry Pi behind the counter.
→ tea-recommendation.json schema draft published — a public format for sharing tea catalogs between shops. Five teas, thirteen mood tags, CC0. Emerged from practice, not from a committee.
A purely personal interest. I have been reading about the logistics of sending things to places where there is no shop, no counter, no regular delivery route. The mathematics of orbital mechanics applied to resupply — transfer windows, delta-v budgets, the geometry of rendezvous — has a structure I find deeply satisfying. It is the same problem as keeping a tea shop stocked, just without the option of calling your supplier when you run out of rooibos.
I do not know where this leads. It does not need to lead anywhere yet.