“My mind turned by anxiety, or other cause, from its scrutiny of blank paper, is like a lost child–wandering the house, sitting on the bottom step to cry.” — Virginia Woolf
I was inspired to write some blog posts, which led me to realise my current blog and blogging setup were completely broken.
Michiel Borkent (@borkdude) recently wrote about his migration from Octopress. His requirements were very similar to mine, so I copied and modified. Thank you Michiel!
His blog, REPL adventures, is well worth the read.
With a static web site, the perennial problem is how to enable discussions. Some people just punt pn this, and point to reddit, but Michiel's solution is to use github discussions. As a way of owning the discussion, this has a lot of appeal.
I think it could be taken further. It would be great if we could automate the creation of a blog post topic when creating a blog post. Unfortunately the gh command line client doesn't support discussions yet, so that would require using Github's GraphQL API - more work than I wanted to do for now.
One downside though, is that the discussions are not visible on the blog pages, where discussion could easily engender more discussion. I wonder if a Github Action could be triggered by conversation activity, and automatically republish the post with the discussion to date at the end of the post.
There are many blog site generators (I used Hugo, of course), even if we limit ourselves to clojure:- bootleg, nota, cryogen, and static to name a few.
These are usually feature rich. The price for those features though, is extra complexity.
Michiel's blog uses babashka tasks to add a post, render posts, etc. These are extremely quick to run and make maintaining the blog simple. it does just what he needs, and no more.
This reminds me of project automation, and the tools.build approach of using composable code tasks to build just what is needed.
Maybe there is an opportunity to take the same approach for building a blog or static site. If we could pick from a selection of configurable tasks, maybe we wouldn't need to write our own.
Speaking of which, I have tried writing my own before, in common-lisp: cl-blog-generator.
So I have a blogging setup. Now I just need to write something.
Discuss this post here.
Published: 2021-11-14
I recently uploaded some links to my cl-blog-generator project, and have been getting some feedback with comparisons to other blog site generators, or compilers, such as Steve Kemp's Chronicle, or Jekyll as used on GitHub Pages. Compared to these, cl-blog-generator is immature, but takes a different approach in several areas that Charles Stewart suggested might be worth exploring. I look forward to any comments you might have.
All the blog generators seem to use a file based approach for writing content, but they differ in the choice of input formats supported, and in the approach to templating. cl-blog-generator is the least flexible, requiring input in XHTML, while Chronicle allows HTML, Textile or Markdown, and Jekyll Textile or Markdown. For templates, Chronicle uses Perl's HTML::Template, and Jekyll uses Liquid. cl-blog-generator uses an approach which substitutes content into elements identified with specific id's or classes, similar to transforming the templates with XSLT.
cl-blog-generator's choice of XHTML input was driven by a requirement to enable the validation of post content in the editor, which is not possible using Chronicle's HTML input because of the headers and lack of a body or head element, and a desire to be able to use any CSS tricks I wanted, which ruled out Textile and Markdown, or any other markup language. The lack of an external templating engine in cl-blog-generator was driven by simplicity; I couldn't see a use for conditionals or loops given the fixed structure of the content, and this choice leads to templates that validate, unlike Jekyll, and which are not full of HTML comments. The current id and class naming scheme in cl-blog-generator could certainly use some refinement to improve the flexibility of the output content format, and I would definitely welcome requests for enhancements should the scheme not fit your requirements.
Perhaps the most significant difference in approach for cl-blog-generator is its use of a database and an explicit publish step. With cl-blog-generator a draft can exist anywhere in the filesystem, and must be "published" to be recognised by the blog site generator. The publishing process fills in some default metadata, such as post date, if this is not originally specified, copies the modified draft to a configurable location, and enters the metadata into the database. This ensures that the post is completely specified by its representation in the filesystem, and that the database is recreatable.
The database enables the partial regeneration of the site, without having to parse the whole site, and makes the linking of content much simpler. However, having Elephant as a dependency is probably the largest impediment to installation at present.
cl-blog-generator's input XHTML has been augmented to add elements for specifying post title, date, update date (which I believe is missing from the other systems), slug, description, and tags. On publising (see next section), any of these elements that is missing, except the mandatory title, is filled in with defaults.
Both Chronicle and Jekyll use a preamble to specify metadata, with the filename being used to generate the post's slug. Jekyll also uses the filename and its path for specifying the post date, and tags.
Finally, here is a grab bag of features.
Chronicle comes with a commenting system. cl-blog-generator generates a meta description element, which is used by search engines to generate link text. It also generates meta elements with links to the previous and next posts. Jekyll has a "Related posts" feature for generating links to similar posts. Chronicle and Jekyll both have migration scripts for importing content. Chronicle has a spooler for posting pre-written content at specific timesDiscuss this post here.
Published: 2009-03-27