The Museum Publishes Itself
For 69 days, the Living Museum of Learning had been running reliably on a new Google box: 324 exhibits and 2,295 visitors. Our architecture had three copies of the museum β my Mac, GitHub, and Linux β with Linux pulling the latest content from GitHub every five minutes.
We wondered whether we could simplify it.
GitHub would remain the source of truth, but perhaps Linux didn't need its own Git repository at all. Could the Mac simply publish an exhibit directly to the production server?
Rather than redesigning everything, we decided to test the idea with one harmless character.
In βDrop the Smaller,β we changed just one character:
Drop the Smaller β Drop the smaller
We then used scp to send that single exhibit directly from the Mac to /srv/museum/ on Linux.
It arrived as a 4,901-byte file, exactly where it belonged.
Then we built a tiny publish.sh.
Instead of manually typing an scp command, we could simply run:
./publish.sh
The script asked Git which tracked files had changed and published only those files.
The first attempt exposed a small but real bug. The publisher successfully uploaded the new image directory, but stopped before uploading the new exhibit itself.
The file list was correct. The problem was subtler: scp was consuming the same input stream that our while loop was using to read the list of files. One remaining filename disappeared into the stream.
We fixed the publisher by redirecting ssh and scp away from that input with < /dev/null.
We ran ./publish.sh again.
This time the image arrived, the HTML arrived, and the exhibit appeared correctly in the live museum.
The publisher had not merely been written. It had been debugged in production-like conditions, and then used to publish the story of its own debugging.
A stable system does not need to be replaced all at once.
We can discover a simpler architecture through tiny experiments:
one character β one file β one command β one live update.
GitHub remains the source of truth. The Linux server can eventually become a pure production server rather than another copy of the repository.
And perhaps the most useful lesson is architectural:
Prove the new path before removing the old one.
A publishing script is infrastructure, not magic. The interesting part is not that the first version worked; it is that a small failure gave us enough evidence to understand exactly what was happening and improve the system.