Jussi Pekonen

The technical implementation of this site, Part 2

Posted on Thursday February 18, 2016

As promised in the Part 1 of this blog post miniseries, this second part will discuss the files this site consists of and how I manage them. As also mentioned in that post, all the pages on this site are static. This post will explain why I have chosen to use static files.

Because it is the year 2016, the technologies used on this site consist of HTML, CSS, and JavaScript. The content that is “dynamic” (like the latest updates section on the main page) is, in fact, parsed using JavaScript from other static files (that are JSON, XML, or HTML). That is the reason why this site appears to be fairly fast to load. For example, this page weighs only 450 KiB (with all associated fonts, and JavaScript and CSS files), meaning that it should not take long to load over a practical Internet connection.

Static site generator?

Now, the obvious question is which static site generator I use. The answer is simply none. The simple pages (like the main page) are handcoded HTML and I write all CSS and JavaScript by hand. Why I am such a pervert who does not use a fancy-pants WYSIWYG editor and the latest and awesomemest JavaScript wrapper framework? Well, first of all I want to learn HTML, CSS, and JavaScript, not just the ins and outs of those tools.

The only exception to the write-by-hand rule is the blog. The pages for the blog are generated by few Bash scripts[1]. The actual blog post pages, like this one, I compile from (simplified) MultiMarkdown files. Once I am satisfied with the post content, I run one Bash script that adds some MultiMarkdown headers (that is, the common CSS and JavaScript files) to the original file, converts it to HTML using the multimarkdown command, and cleans up the HTML output a bit. That script also generates the needed data for blog subpages (for example the 2016 page) and blog tag pages using a pair of Bash scripts. The post generator script also adds the permalink of the post to the master permalinks JSON file (from which the permalink in the footer, see below, is parsed from) and to the redirect rules used on this site.

On creating the content of this site

As mentioned above, I do not use any fancy editors when I write the content and code for this site. I use just a plain text editor, mainly in Terminal[2] because I have a “coding” setup always open. I could try out some editors that have been designed to this kind of workflow, but I kind of like the simplicity of my current setup.

I try to write HTML5 compliant pages, but I have not fully validated the HTML code on all pages. Similarly, I try to write valid CSS3 cide, but I cannot guarantee 100% validity. I write pure JavaScript (not jQuery or anything like that), and it has been written so that it targets the use cases found on this site. I have written the functionality found in the code in the “minimum viable product” way by doing only the steps that are needed for this site to work as it is today.

As I mentioned in the Part 1 of this blog post miniseries, the RSS feeds are autogenerated using a Bash script. The JSON files that I use to store some data are mostly written by hand. The only exception to that rule is the addition of the permalink of a new blog post that gets added by the publishing script. Why I write my JSON files by hand? The data I store in JSON files is small enough to handle manually. Maybe one day when my site becomes big enough I need to reconsider my workflow and start managing the JSON data using a specialized editor. Yeah, right, like that day would ever come…

Ads, analytics, user tracking

If you have (ever) visited the site, you may have noticed that it is devoid of ads. While the terms and conditions of Kapsi (the Finnish non-profit for Finnish Internet users, that hosts this site) do not allow commercial activities[3], they would allow me to have ads on the site. However, I have decided not to have them. Why? Well, I personally dislike what online ads (and ad networks) have become. Furthermore, ads would never fit to the overall look and feel of the site.

Similarly, I do not have any analytics packages running on this site. I do not like what they do, and furthermore they would bloat the pages, which is something I do not want to do. I value speed and lean site size more than the information of what you do on my site. Besides, what would I do with that information? You came here to find something that you wanted, and you probably found it. If you did not, you most likely can send me an email where you ask about it.

The same reasons apply to social media sharing buttons. They bloat the site and do nasty things in the background. Besides, most likely your browser has existing share functionality built in. Learn to use it, it is really handy. Also, it is more flexible than a button I would need to add on my site.

That is it. This post concludes the miniseries on the technical implementation of this site. It also gives a glimpse of the workflow I use when writing for the site. Hopefully you have enjoyed reading about these technical tidbits.

Tags: Website, Blogging