Collecting my attempts to improve at tech, art, and life

Rebuilding My Public Brain

Tags: site second-brain

I changed my blogging workflow — again.


I took all my blog posts since 2000 — since before the site was a blog — put them in Obsidian, extracted note cards for recurring content, and smashed the whole thing into a new iteration of Random Geekery.


I tried sharing My Public Brain a couple times. It didn’t work out. Maintaining an extra site added personal friction, and I ended up ignoring all of it. I wanted to keep trying, though. My first site coolnamehere was an organized collection of notes on topics as I learned them. I’ve mostly been blogging the last decade, but missed the ability to link back to topic notes from my posts.

At the very least, having dedicated topic cards means fewer places to update external links. That can save a few minutes of effort over a couple decades, for sure.

Storing the whole thing in a PKM makes it easier to find mentions and follow cross-references, eventually ensuring some kind of consistency in site structure.

Okay, How?

Building the vault

Most of the details and reasoning are over where I describe How These Notes are Organized. Basically I have a private folder for new notes, a private folder for journaling, and a private folder for vault templates. Everything else is public.

The process itself was manual:

This process of evaluation and refactoring was fundamentally manual, so I limited the plugins to what I needed to mark progress and visually distinguish links.

I’ll probably add plugins later, but the extra functionality of Templater or Dataview would have distracted me from the core task. It happened with previous note consolidation efforts.

Building the site

Initially I pulled the vault into an Astro site with ts-node. It sort of worked. Came into some issues with ts-node on very fresh Node.js though, and decided to see if someone had already figured out Obsidian export.

Turns out, yes. obsidian-export handles internal links and provides some starter template logic for working with Hugo. I’m setting Astro aside for the moment. Sticking with Hugo made cleanup easier, since I no longer had to care about shortcodes.

Got a Perl script for backlinks and a Python script for processing Obsidian Markdown rules that obsidian-export didn’t cover. Not happy with either of those scripts yet, so I won’t go into detail about them here. The Perl script finds backlinks and puts them in a data file for quicker backlink handling at site build time, and the Python script currently does some regular expression handling to identify special markup and transform it.

I pulled in my automated tests from the current site iteration. I really should talk more about those tests at some point. They mostly check for structural issues with markdownlint and broken internal links.

What next

Before I have the Python script handle all the processing, I’ll revisit the Astro iteration. remark-obsidian and remark-deflist handled nearly all the special Markdown for me. I mainly need to decide how top-level pages like now and follow get treated within Astro’s dynamic collection approach.

What now

Budget is constrained, so before the annual hosting bill comes due I’ll shift from a paid host to Netlify. My planned usage tier should be free there. I expect to bounce back out again after resolving the current Job Search to my satisfaction, but maybe not. We’ll see.

Hugo works. Netlify works. My notes need work, but hey don’t we all. I’m not going to jiggle anything else just yet.

I think it’s time for just pull backlinks process build test push.


Maybe tighten that invocation up just a little bit.

Got a comment? A question? More of a comment than a question?

Talk to me about this page on: mastodon

Added to vault 2024-01-22. Updated on 2024-02-01