=============================================================================== blog.notryan.com/001.txt Tue, 21 Jan 2020 Ryan Jacobs 06:15:00 -0800 Plaintext Blogs . . . . . . . . =============================================================================== I've tried to start a blog several times, but I always get fed up with the formatting and/or the build process. See, I'm always thinking about longevity. I'm thinking about: how should I build something to last? Well, text lasts forever. So I should stick to Markdown right? Tentatively, that answer is yes. But then, I get stuck in the build process again. Which Markdown compiler should I use? How do I plan on styling the resultant HTML. When I embed images, will they fit cleanly on the screen? I want to store the original 3.5 MB JPEG, but that doesn't seem okay for web... so I need/should incorporate plugins to compress them. For a while, I settled on Eleventy for all of this. And it looked great! But... it wasn't perfect... And I'm not exactly sure why yet. I can't quite put my finger on it yet, but I will follow up when I can. I think it's something to do with longevity. I'm not 100% confident that the framework and its dependencies will be around in 10 years. It's so many layers of complexity to deliver text in a pretty manner. But for right now, I am settling on this medium: words on a screen. I am settling on files with .txt extensions. Specifically, UTF-8 files with mainly ASCII characters (and Unix line-endings). My ideal blog has a couple of facets. Ideally, I will have a series of "threads". For example, I want to try a week without artificial electrical lighting in my bedroom. And I also want to post intermittently on my DIY laundry machine detector. But I'm afraid that it will be hard to follow these intertwined (in respect to time) posts. (Blogs are typically sorted by datestamps.) So I'm proposing two types of blog entries: epoch-oriented and thread-oriented. Anyways, I'm glad I wrote this down. I'm glad that I'm writing again. --- As much as I enjoy the avoidance of build systems, I created a dead simple one for this blog. In this case, the benefits of having an index of entries outweighs the cost of inaccessibility. Here are the specifications for my blog, as it exists in the version-controlled source repository: I have a folder with .txt files. The blog entries are named 1.txt, 2.txt, 3.txt, etc. A script named `build.sh` produces an HTML file `index.html` that contains hyperlinks to the blog entries. The links' text content use the scraped titles in the .txt file headers. The header ends when we encounter three or more dashes. The title is the line before the dashes. Look at the top of this entry for reference as to what a header looks like. Right now there are only four lines, so my script just grabs the fourth line for the header. In the future, some dynamicism might need to be added if I decide to add optional header fields. (Check out the script by visiting https://blog.notryan.com/build.sh) I have decided to not name files by their blog title for a couple of reasons. First of all, sorting gets tricky when the filenames can be anything. I want everything to be in chronological order when I type `ls` into my shell. Sure, I could prefix the filename with a datestamp such as "21_Jan_2019" but this wouldn't work because `ls` has no concept of months or date formats. "2019-01-21" would probably work. However, my second gripe is that blog titles/dates can change. It's rare, but sometimes I want to change a title. There are two titles to change: the internal one within the file contents and the filename itself. Since the URL is based on the filename and not the internal blog title, the supposed permalink doesn't change (nor should it). Permalinks aren't supposed to change. If I email a particular post to a friend, they should still be able to click on that link a year from now. The easiest away to get around this is to have a unique non-changing name/id for each post. That link should be valid forever. https://example.com/blog/421 should always point to that entry, even if I change the posting date or the title. `https://example.com/blog/how-to-write-fizz-buzz` is bad. If I decide after posting that "FizzBuzz" should be one word, then I need to change the title (or else I won't sleep at night). I will need to first change the title internally, which is fine. But then when it comes to updating the filename, the URL will change too. Sure, there are all types of patching I could do. I could create a symlink to redirect `how-to-write-fizz-buzz.txt` to `how-to-write-fizzbuzz.txt`. I could also just leave the filename alone and ignore the slightly different URL. Anyways, these all seem like kludges to me. It might be slightly worse for SEO, but it'll be a hell of a lot easier for maintenance to save my blog entries as numeric ids. Plus, if some *nix freak wants to download my blog programmatically, they can run `wget https://blog.notryan.com/{1..99}.txt`. On my to-do list: embedding images in a backwards compatible way. I want to keep my 80 columns of text width format, so I'll probably render images at 80em or 80ch. I will most likely produce a corresponding HTML file that is a one-to-one copy of each .txt document. Detected URLs will become hyperlinked tags and images will be rendered as tags. This is starting to sound an awful lot like Markdown... but I swear it's not. I want something that uses text for everything except for features that are impossible to implement in text, such as images. Bullet points and headers are definitely possible in ASCII. Hell, flowcharts are possible in ASCII.