Notebook: The Public Lab Notebook
When I decided to document my journey in public, I knew I couldn't use a bloated, database-heavy CMS. The tool itself had to embody the philosophy I wanted to promote: simplicity, speed, and transparency. That's why I built notebook.oceanheart.ai from the ground up as a lightweight publishing engine in Go.
The Readme for this project calls it the "quiet one," but says its "raison d'être is pure intent." That perfectly captures the feeling. It's designed to be an engine for the "public lab notebook"—a space where the process of discovery is just as important as the final result.
The Beauty of Simplicity
The entire site is a single Go binary. All my posts are just simple Markdown files in a folder. There's no complex database to manage; it uses an embedded SQLite database for lightning-fast caching. This "content as files" approach is liberating.
- No Fuss: I can write a post in any text editor, drop it in the folder, and it's ready. To fix a typo, I don't need to redeploy the whole application; I just hit a secure
/admin/reloadendpoint, and the new content is instantly cached and served. - Future-Proof: Markdown is universal. My content isn't locked in a proprietary database format. It's portable and will be readable for decades.
- Blazing Fast: Go's efficiency, combined with serving content from either a local file or a simple cache, makes the site incredibly responsive.
Despite its simplicity, it has everything a modern blog needs: an automatically generated Atom feed for RSS readers, a sitemap for search engines, and beautiful code highlighting using Goldmark and Chroma, because I believe your code blocks should look like they moisturize.
Why a "Lab Notebook"?
This architectural choice is a direct reflection of the blog's purpose. Traditional publishing polishes away the struggle. You only see the finished paper, the perfect final code. But that hides the most valuable part: the messy, iterative journey of learning.
The "public lab notebook" is a rejection of that. It's a commitment to showing the work: the experiments, the dead ends, the small incremental discoveries. It's about sharing the journey, warts and all, not just the destination.
This approach, I hope, fosters a community where knowledge is built collaboratively. By making my process transparent, I invite others to learn from my mistakes, build on my nascent ideas, and offer feedback along the way. It challenges the traditional model of hoarding knowledge until it's "perfect." Here, the process is the product.