Blog Wars 4: A new hope beginning.

So this is my new blog. It uses a blog engine called hibachi that I have specifically written for this blog (although it is open-source and can be used by anyone).

About the engine

As far as blog engines go hibachi is pretty much standard issue. It takes Markdown --- well CommonMark to be precise --- formatted files, converts them to HTML and then uses some templates to get the final result. Similar to several other engines it uses git to store the source files of posts. However, different from most engines it uses that git repository in bare mode instead of checked out to a folder. Doing it this way gives hibachi the ability to do some neat tricks that would otherwise be much more annoying:

• I can access files that aren't in the checked out index. For example the mostly static files like robots.txt or about.md are kept in a separate branch --- aptly named static. This way the main branch that keeps the posts keeps only the posts and I don't have a nested folder hierarchy where I have to cd several levels down to get to my posts.
• I have easy direct access to commits, commit history, author, time, etc. That way I have to keep less metadata in the posts themselves that I need to update and keep track of.
• I can use the bare repository that I use as a remote to generate the posts. Git doesn't like to push to a repository that has a worktree associated with it --- for good reason I might add --- so most engines that use git resort to git hooks to update the worktree everytime one pushes to the bare repository. Using the bare repository directly just keeps the amount of moving parts lower. And yes, in theory it keeps the storage requirements lower since I don't have two copies of the files on the same machine. But in reality hibachi is a 30MB Haskell binary that offsets any space savings manyfold.
• I have a very efficient way to check what files were changed in the last update by looking at the OIDs.
• Since I operate on a list of commits since the last run and not on the index itself I can access and generate posts for files that were added and removed to/from the index in separate commits but one push. That's arguably a corner case but it allows to easily create "hidden" posts, i.e. posts that exist in /p/ but aren't listed in index.html.
• I can manage large files such as images using git-annex or git LFS

Also, I don't use a single line of JavaScript, but that's very much the norm for me. Incidentially, because I don't use any JavaScript and only small, handwritten files that can be cached very aggressively the blog is extremely fast. The slowest part by far is the loading of the four fonts (Vollkorn, FontAwesome, Dearest, Hack), none of which are present on an usual distribution. But the font files can again be cached very well because I do not intend on switching them out any time soon.

About the looks

I spent a lot of time making the blog look exactly like I want it to. Most of that time was spent on the typography. My main font is Vollkorn; a beautiful font that has extremely good support for Latin and Cyrillic Script. It also provides oldstyle numerals (0123456789) and very good mathematical symbol coverage (e.g. ∫ ∮ ∬ ∯ ∭ ∰ ≔ = ≠ ≙ ≜ ≡ ≢).

Since I want to use this blog for English, German, Spanish, Russian, Finnish (any language that I feel like really) text and will talk about Maths, Category Theory (⊂ of Maths to be fair) and Haskell / Code in general I do enjoy the good support for all of those. (Also I just love oldstyle numerals). FontAwesome is a free as in both speech and beer Icon Font that just looks nice. Dearest (by West Wind Fonts) is the font that provides the drop cap letters. Yes, I have a font that shows exactly one glyph per post. Deal with it. Hack is … well, Hack. It's the font I use for everything monospace and I do want that to be reflected on my blog as well.

In short, I spent way too much time on little things like the perfect line leading for the line width and things like vertical rythm that nobody will actively notice but me.

Other bits and bobs.

Estimated Reading Time

I'm using Medium's read time formula. But because a lot of people dislike assumptions about how long they will take to read a given article I also always provide the number of Words and Images (if any) on one article so people can judge for themselves how long it will take them to read something.