Written by khh 2016-06-13 15.00 CEST

Nearing deployment


So in the last post I kind of lied. A lie by implication, if not by words. I hadn’t actually gotten very far in the development when I wrote that post, and so I didn’t quite have the full picture of how things would look. I still don’t have the “full” picture, I assume, but at least I’m closer.


Currently the blog functionality works. It indexes posts on disk, maps the files to a URI, and caches this mapping. The latest post is displayed on the blog landing page. It does however not cache any of the pages (so for each request the document must be fetched from disk, converted from Markdown to HTML, processed by the templating system, and spat out. I still plan on adding some strategic caching later to speed things up, but there’s just no need yet.

Which is how it’s with most other features too. I’m implementing features as I go along, and so whatever I currently need is what I create. Plus, whatever seems like it will be fun working on. That’s an important factor to consider as well. And since I’m using Discount as my Markdown library, the page creation is lightning fast.


Things are moving forwards, though, and I am just about ready to do a test deployment. I will need to write some scripts to manage the deployment. In time I might have an automated deployment system which performs various tests, scrapes the pages for information, and then moves files around accordingly. For now, I’ll settle on a script which can automatically copy the requisite files where they’re needed, and I’ll have to write a Systemd unit file to run it behind a webserver.

And then I think I will have to work on a static file system. Including all stylesheets and javascript on all the pages doesn’t seem like a sustainable system.