Autofeeds Without Clutter

/images/_fe28d193-da93-470b-8d6d-372a231ca6bb.jpeg

I need to be able to create some projects, such as my daily Maranga challenge, that will get a new post every day, but I don’t want those auto-pages filling up my Obsidian notebook system. Here’s how I’m planning to manage that.

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇

Currently, Hugo runs on my home server, watching my Hugo content folders for new or modified files. When it finds one, it rebuilds the site so I can see the changes locally, before anything gets pushed to my public HTML service.

There’s also a second monitor running on that server watching my Obsidian content folders. When anything changes there, this shadowmaker service scans the files for any of my special control tags and puts modified copies of those files into the appropriate Hugo content folder, thus triggering a Hugo rebuild. It’s simple and it works.

I can’t just insert the new posts directly into the Hugo hierarchy, because that system gets rebuilt from scratch whenever I update the site.

I think the trick is to recognize that the Hugo folders don’t know where their content files are coming from, so I could easily add an autoposts folder, outside the Obsidian hierarchy, that the shadowmaker will monitor as well. That way, my autopost generators can put files in that folder hierarchy, without risk of them getting into my Obsidian hierarchy, but they’ll still be seen by the shadowmaker and funneled into the web site system whenever the site gets built.

Half of me thinks this is too many watchers and that sooner or later this is going to bite me in the ass, but the other half thinks it’s simple and clean, so why not try it?

Stay tuned to this station for late-breaking updates, as they happen.


Read More


/images/_e1b23d38-68ca-45eb-bf1b-56bd12ad0ce3.jpeg

Obsidian-fu

Refactoring the shadowmaker has become a bigger headache than I had originally anticipated, but it’s for the long-term health of the system, so I’m sticking to my guns. This weekend added further drama when I finally stopped running away from frontmatter and embraced it for all my metadata. Sure, scattering #ch-command directives throughout the body of the notes was insane, but fixing it is going to mean more than just adding a few metadata fields. I may have to completely change the way I use Obsidian.

/images/_e42c8a8a-b127-431f-b414-425c5d17a2dd.jpeg

Ontology-2.0

While trying to integrate the many episodes of CaveTV into the site, I realized that the ontology was getting cramped. It needs to be revised to better distinguish between internal projects, external brand identities, multiple deliverables within a brand, and distinct showrooms.

What follows is the scheme we devised for what the abstractions are, how they should be tagged in Obsidian, and how the files will be managed within Hugo.

/images/_2ef531ec-bc45-46fe-841b-6864301fa06c.jpeg

Cutting The Monster Into Pieces

Now that I’ve identified a useable hosting candidate, my final test of their service will be to roll out a full implementation of the websmith deployment scheme. But in contemplating how I’m going to do that, I’ve realized that I may not have broken the project into distinct repos properly. So I’m going to figure it out by explaining it to the rubber duck. (Meaning you. :-)