Jussi Pekonen

The technical implementation of this site, Part 1

Posted on Tuesday December 22, 2015

After I announced my new microblog Blips, I was asked how I implement the feature. Because it is closely tied to the technical implementation of this site, I thought I should write about the complete implementation instead of that one particular subsection of the site.

Here is a blog post that describes the technical solutions used on this site. However, this post does not cover what files the site consists of are or how I manage them. That will be the topic of Part 2 of this blog post miniseries. For this post, it suffices to know that all pages of this site are static and that all the dynamic content is parsed from other static files using JavaScript.

I use the web hosting service provided by Kapsi, a Finnish non-profit organization for Finnish Internet users, included in the membership of the organization. Other services they provide include email hosting, disk space (for remote backups, for example), and IRC access. For technical solution of the web server, feel free to consult the Kapsi pages, where the relevant information is explained (only in Finnish, unfortunately).

Content management and automatic deployment

All the files for the site are managed in a Git repository[1]. That allows me to fix possible screw-ups by reverting individual commits and it lets me to work on the site from any device that has Git installed. Why Git and not something else? When I started this site I was learning Git and wanted to try it out also for this “project” of mine.

At the moment the repository contains both text and binary files. As you probably know, tracking binary files in a Git repository is not the best possible solution. Therefore, I have been planning to move the binary files to a Subversion repository. The migration of the binary files is currently ongoing, but it is not done when this post goes live.

How do I deploy my changes to the server then? The automatic deployment strategy I use was inspired by this blog post. I use a Git post-receive hook written in Bash[2] that pulls all changes pushed to the master branch[3] to the folder that acts as the root of this site[4]. The post-receive hook allows me to track the files that have changed, which is handy for the automatic generation of the RSS feeds of the site.

Automatic generation of the RSS feeds

Based on the files that have changed, the different RSS feeds are automatically generated. For the automatic RSS feed generation I use a set of Bash functions defined in a few files that are also tracked by the repository. The generated feed files are not tracked by the Git (or the upcoming SVN repository).

When there is a new blog post, the post-receive hook calls a Bash function that parses the necessary information from the HTML file and adds it as a new RSS item to the blog and main feeds of the site. However, if a published blog post got updated (or deleted, which is yet to happen), the feeds do not get updated.

Whereas any new blog post triggers the autogeneration of the blog and main feeds, I use a single text file for tracking the Blips. If it was modified[5], a new Blips RSS feed item is created with the contents of the tracked file. This approach publishes only the latest update, meaning that if I have created several commits that updated the file, only the latest version of the file gets published.

Similarly to Blips, the generic site updates are tracked with another text file. While the Blips file will use plain links because they are crossposted to other media, the site updates file will be parsed for Markdown-formatted links before its content is added to the main RSS feed. Also, only the latest update to that file gets published, similarly to Blips.

Crossposting site updates and Blips

As mentioned in the announcement blog post, I crosspost all new items in the Blips RSS feed to my Twitter and App.net accounts. I use IFTTT recipes Zapier “zaps” that take the Blips RSS feed and create the needed updates on the aforementioned services.

The main RSS feed also goes to my Twitter account via an IFTTT recipe a Zapier zap, similarly to the Blips. Unlike with Blips, I manually create an App.net Broadcast of the updates to my site using another account. I will then repost, manually again, the autogenerated post using my personal account. I could create an IFTTT recipe a Zapier zap for that too, but I do not mind doing the thing manually, especially because the original post was also created manually.

This ends this first post in this miniseries. Part 2 will focus on the how I update this site, the Blips, and so forth. It will be published when it is ready.

  1. You can verify this by trying to open this link to the .git directory. However, I have blocked the access to that directory, so you should get the 403 Forbidden error page instead.  ↩

  2. Why Bash and not something like Python or Ruby? Well, Bash is most likely available on any server I may want to move the site contents to. Python, Ruby, or any other sexy scripting language would have their own problems, starting from being available on the server and having the correct version (case in point, Legacy Python 2 vs. Python 3).  ↩

  3. I also have a test site to which a checkout is performed when I push to the test branch. However, that site is not public and it is also password-protected. I try out different things there first before I push the changes to master.  ↩

  4. For the binary files in an SVN repository, I will be using the SVN post-commit hook that checkouts the master repository to the root of both this site and the test site. That way I can ensure that the data is correct on both sites.  ↩

  5. Or added, in case I accidentally the file.  ↩

Tags: Website, Blogging, Social media networks