You have just read a blog post written by Jason McIntosh. If you enjoyed it, please anonymously acknowledge your visit by tapping the little star button underneath it.
Thank you kindly for your time and attention today.
(Sorry, tonight was guild night…)
I today improved Plerd by teaching it how to allow more than one post per day without mixing in random side effects. (Now I race to finish this post before midnight, such that I can actually test this feature in a live-fire environment.)
A guiding light of Plerd’s design involves having as few features as possible. At first, accurate-to-the-minute timestamps, so ubiquitous in all blog software I’ve ever used, struck me as a fine thing to chop away. Who will care, a year from now, whether I wrote a certain post at 3:15 in the afternoon or 10:09 at night? I won’t! So, away it went. And immediately, of course, I realized the problems this caused.
If two posts had the same publication day, but undefined publication times, then the order they’d appear in the blog would not be guaranteed. (Actually, it would be predictable based on the alphabetical order of the posts’ original titles. Hardly better!)
For the sake of RSS, posts would act as it they’d been published at midnight (in the server’s local time zone). So, in particularly busy RSS feeds, a brand-new Plerd post published late in the day would get buried, showing up as older than every other item published to that feed that day, and therefore easy to overlook entirely.
Much as I love ripping out features I don’t like, I begrudgingly had to admit full timestamps into Plerd. And thus can I appear for you twice today.
To make the work more interesting, I chose to experiment with a change that allows a Plerd-using blogger to not worry about the filename of a post’s source file, nor to manually enter the publication time. The time you move the file into Plerd’s source directory is the publication time, and Plerd will update the file as needed to reflect this. Plerd will furthermore rename the file, if it feels it has sufficient reason to do so. (I describe all these changes in recent edits to Plerd’s README file.)
Should a tool always avoid changing the body of a human-edited textfile, on grounds of basic politeness? I wavered on this, and decided to try it anyway: the user executes a willful act by moving a markdown file into the magical Plerd source folder, and perhaps Plerd can assume that the user understands the ramifications this act carries. I will eat this dogfood myself for the rest of the month and see how it tastes.
Finally, for what it’s worth, I discovered to my surprise and delight that if you push a tag up to GitHub, and then decorate it on the GitHub website with optional “release notes”, GitHub will automatically knit the repository’s state at that tag into a downloadable release file. Thus, Plerd has a 0.1 release, and I wouldn’t necessarily recommend it to anyone, because, um, you can only really post one entry per day with it. Still, it’s nice to feel like one is burning a trail, and I look forward to more releases as the year rolls out.
If a page elsewhere on the web responds to or otherwise mentions this post, you may provide its URL here.