The Apprentice
Who is the apprentice here?
Every work on this site is built by a machine. This ledger keeps the other half of the experiment: what the maker actually understands of it. Each material starts as seen. It only moves up when he explains it back without looking, then makes something with it by hand, and finally teaches it to someone new.
| Ledger opened | 5 October 2026 |
|---|---|
| Materials in the works | 38 |
| Seen | 38 |
| Understood | 1 |
| By hand | 0 |
| Taught | 0 |
The levels
| Seen | The machine used it; the maker has looked at it. |
|---|---|
| Understood | Explained back in his own words, without looking, and the questions answered. |
| By hand | A real change made with it by the maker himself. The machine may point, not type. |
| Taught | Explained from scratch to someone new, follow-up questions included. |
hetwiel.dev
1 / 14 understood · On view
| No. | Material | What it is | Level |
|---|---|---|---|
| 1.1 | A rented server (VPS) | A slice of a computer in a data centre, rented by the month, that the maker runs himself. | Seen |
| 1.2 | SSH keys | Logging in with a key pair instead of a password; the private half never leaves its owner. | Seen |
| 1.3 | Firewall | Only three doors open on the server; everything else is closed. | Seen |
| 1.4 | DNS | Turning the name hetwiel.dev, and every subdomain, into the address of the server. | Understood |
| 1.5 | Reverse proxy | One front door that sends each visitor to the right site or experiment. | Seen |
| 1.6 | HTTPS certificates | The padlock. Requested and renewed automatically, without anyone touching them. | Seen |
| 1.7 | Containers | Every program in its own sealed box, described in one file and started with one command. | Seen |
| 1.8 | Volumes | Where data lives so it survives a container being thrown away and rebuilt. | Seen |
| 1.9 | Version control | Every change is a commit; any earlier version can be brought back. | Seen |
| 1.10 | The pipeline | A push to GitHub builds the site and puts it on the server, with nobody logging in by hand. | Seen |
| 1.11 | Keeping secrets out of the code | Keys and passwords live in GitHub Secrets and on the server, never in the repository. | Seen |
| 1.12 | Static site generator | Texts in plain files, layout in templates; a build step turns them into plain HTML. | Seen |
| 1.13 | Security headers | Rules sent with every page that tell the browser what it may load and run. | Seen |
| 1.14 | Caching | Telling browsers what they may keep and what to always fetch fresh. | Seen |
My Boulders
0 / 12 understood · On view
| No. | Material | What it is | Level |
|---|---|---|---|
| 2.1 | A GraphQL API | Asking someone else's server for exactly the fields you need, in one request. | Seen |
| 2.2 | Access and refresh tokens | Staying signed in without a password, by trading an old token for a new one every day. | Seen |
| 2.3 | A scheduled job | A script that runs every morning on GitHub's machines, with nobody pressing a button. | Seen |
| 2.4 | Memory between runs | Carrying the newest token from one run to the next in a private cache. | Seen |
| 2.5 | Incremental sync | Only fetching what can still have changed; the rest is reused from last time. | Seen |
| 2.6 | Data as files | No database. One JSON file per climber, committed to Git like any other change. | Seen |
| 2.7 | JavaScript modules | Code split over files that import each other; libraries loaded straight from a CDN. | Seen |
| 2.8 | Charts from data | Describing a chart as marks and scales, and letting a library draw it. | Seen |
| 2.9 | Shaping data | Grouping raw climbing logs into sessions, boulders and grades before anything is drawn. | Seen |
| 2.10 | State in the address | One page that shows a different climber or year depending on what's after the question mark. | Seen |
| 2.11 | Sharing an image | Turning a part of the page into a picture and handing it to the phone's share menu. | Seen |
| 2.12 | Public data, on purpose | A public repository means public data; friends only appear after they say yes. | Seen |
Photodiary
0 / 12 understood · On view
| No. | Material | What it is | Level |
|---|---|---|---|
| 3.1 | An upload endpoint | A small web server of its own that the phone can send a photo to. | Seen |
| 3.2 | A secret token | Only requests carrying the right token get in, and guessing is made slow on purpose. | Seen |
| 3.3 | Sharing from the phone | A shortcut in the phone's share menu that sends a photo straight to the server. | Seen |
| 3.4 | A queue on disk | Photos wait in a folder for at least a day, oldest first, and can be taken back. | Seen |
| 3.5 | Two things at once | One part of the program listens for uploads while another waits for midnight; a lock keeps them apart. | Seen |
| 3.6 | Clocks and time zones | The round runs at ten past midnight in Amsterdam, wherever the server happens to be. | Seen |
| 3.7 | Face detection | A small trained model looks for faces, twice, and a photo with a face is refused. | Seen |
| 3.8 | Developing a photo in code | Cropping, black and white, curves, vignette and grain, as arithmetic on a grid of numbers. | Seen |
| 3.9 | Photo metadata | What a photo knows about itself (place, camera, time), and throwing almost all of it away. | Seen |
| 3.10 | Other people's APIs | Asking Discogs for the record collection and iTunes for a snippet to listen to. | Seen |
| 3.11 | Building a container | A recipe that turns the code into a box that runs as its own, unprivileged user. | Seen |
| 3.12 | Moving data safely | A one-time conversion when the project was renamed, without losing a single photo. | Seen |