Tricky Shadow

/images/_33478bc9-410b-4ea0-af16-02d14824d783.jpeg

Creating that Jeff-to-Nikola translator wasn’t too bad, but I did run into a headache trying to figure out how to structure my shadow files to conform to what Nikola is looking for. I read somewhere that Nikola could be told to search through the content directories recursively and that it happily consumed metadata in YAML format, so that’s what I set up.

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

Unfortunately, if those behaviors were once true, they don’t seem to be any longer. Worse, Nikola wasn’t complaining about anything either. It just ran happily, informed me in a chipper voice that it was done, and then served up an empty site.

It took longer than it should have to discover those problems, but in the end, I got those bits sorted out and it now seems to be parsing my shadow files and recognizing all the metadata. It’s still not generating the category pages that I want, but I believe that’s because I need to make some changes to the config file, and maybe the templates. More on that later.

Meanwhile, I did encounter an interesting issue. Linux files don’t usually track a birth timestamp, so I don’t actually know when each article was written. All I know is the last time it was edited. For old files in the wiki, that’s fine. But the website will be sorted by creation/publishing date, so if I ever go back and edit a file, Linux will report the new date and suddenly that old post will start showing up as new. Not ideal behavior.

So I wrote a little routine as part of my shadow generator. Each time we see a new slug, it gets registered along with its creation date in a local data file. Henceforth, that recorded date will always be used as the creation time, and any subsequent changes to the date will be treated as an edit date. That way, if I ever edit an article, everything will still sort properly.

The only thing I’m not happy with at the moment is that I have to manually edit the Nikola config file every time I add a new project to the site. That violates one of my original requirements, so I’ll have to dig into that tomorrow.


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. :-)