To be honest I’ve written this post mostly for myself. I’ve edited all my posts (see below) and it was fun to read about the (major) changes I made to this site over the years and rediscover what I did and why I did it.

So here’s another chapter…

Bye bye Acrylamid, hello Hugo!

I last changed the technology stack that generates this website in 2012 when I migrated to Acrylamid. I’ve been happy with that choice for years but Acrylamid has been unmaintained since 2016 and I wanted to use something else.

I shopped around for static site generators that allow me to write my posts in Markdown. After looking at a couple of options I decided to pick Hugo. I like it because:

• It’s open source (GitHub repo)
• Hugo is actively developed on
• It seems to be quite popular (currently number 2 of the generators listed Jamstack.org, based on the number of stars on GitHub)
• There is extensive documentation
• It offers the flexibility I wanted
• There are quite some themes available (at the moment there are 285 listed with the tag “blog” for example)

Process

At first I started out with one of the themes (Noteworthy) to get up-and-running quickly. Later on in the process I started building my own theme, using bits and pieces from Noteworthy. Funny thing is that I ended up with something looking very similar to what I had for my Acrylamid site.

I chose to not render any raw HTML code in my Markdown. To compensate I have created a couple of custom Hugo shortcodes to be able to e.g. use the <blockquote> element with a citation attribute or create tables. On the one hand it removes some flexibility you have when you can write raw HTML, on the other hand it forces me to do things more consistently by using the shortcodes.

Having to replace the raw HTML plus fix lots of broken links, led to the decision to review each and every blog post I have written here. There are only about 150 of them, so that didn’t seem like a massive job… In the end it took me way more time than I expected to go through them all.

It was also fun to read the old posts, like the ones I wrote during my first Plone conference in 2008. And when I read the open tabs post I made in 2018 I rediscovered a book I wanted to read. And although I still haven’t actually read Dark Matter yet, I have purchased it and uploaded it to my e-reader.

While working on this version of my website I took the advice given by Rain Leander in her 2021 devopsdays Amsterdam talk: Playing is instrumental to life. No one can tell you how to play. Do what is fun for you. And when it stops being fun, just stop doing it. As a result I alternated between editing old posts, working on the theme, picking fonts, etc. Or not work on it at all if I didn’t feel like it. This meant I could have finished this sooner, but that’s okay—it’s only a hobby project.

Theme

As I’ve said: I started out with an existing theme, but ended up with creating my own theme. Unfortunately I do not have a clean separation between content and theme at the moment. I might want to improve this in the future, but it is the reason why I haven’t made a separate Git repository for the theme now: the project and theme are too tightly coupled.

The way this new site looks is only slightly different from what it looked like before. Under the hood I’m using newer CSS layout options: grids and flexbox. I cannot call myself an expert on these topics, but it sure was fun to play around with them.

I also wanted to jump on the variable font train. I liked the idea of only having to include a single font which can then be used in all kind of different weights. However I was not able to get it down to an acceptable size. The closest I got was still about 5 times the size of a regular font, which means a much bigger chunk of data to download for the visitors of this site.

As a result I’m sticking to standard fonts for now. I picked the fonts I liked on Google Fonts and used google-webfonts-helper to download the files needed to self-host them. My choice at this moment:

• Merriweather for the main content
• Fira Sans Extra Condensed for the headings and other texts that need to stand out (menu, post meta data, footer, etc)
• Fira Code for code samples

Build times

Although I never had complaints about the speed of Acrylamid in the past, Hugo is quite a bit faster. This became obvious when I was writing my notes for All Day DevsOps. I had been five months since I had written something here, but in the meanwhile I had been working with Hugo to edit my old posts and create the theme. And I had gotten used to LiveReload which in practice meant that a page had already reloaded in my web browser in the time it took to switch from my editor to my browser.

The live reload alone makes the process feel much snappier, but I was curious about the actual difference in build times between Acrylamid and Hugo. So I decided to test the two use cases that are most important for me since this is what I do most of the time:

• A complete rebuild, e.g. to deploy to the live environment (without artifacts from experiments/drafts, etc)
• When I create/edit a post I have Acrylamid/Hugo watch the files and rebuild the site on change.

I ran these scenarios three times and took the shortest run for both tools.

This confirms what I had already suspected: Hugo takes only a fraction of the time Acrylamid needs when rebuilding the site after I change a post (the 2nd use case). Combined with the live reload this makes for a big difference in my workflow.

New domain

For this version of this site I also switched to a new domain. I got the vlent.nl domain in 2003 and used it for my website ever since. Now, 18 years later, I’ve decided to start using a different domain for this site: markvanlent.dev.

Although this frees up the vlent.nl domain for other stuff in the future, I have setup a redirect for (I think) all the URLs I was using. At first I wasn’t sure if it would be worth the effort, but after going through 13 years of blog posts I can tell you that it is really nice if old URLs still exist or at least redirect to a new location for the content.

New hosting

I’ve been managing my own virtual private servers for this site since 2013 and it was fun. It offered me a lot of control: deployment, web server, TLS configuration, et cetera—I was all up to me. And that’s also the downside: there was only 1 person maintaining it: me. It doesn’t cost me that much time, but it’s something I have to take care of nonetheless. And if e.g. a new version of Docker no longer proxies IPv6 requests by default, it’s also up to me to (a) detect the update broke something and (b) solve it.

Because maintaining a VPS no longer brings me joy, and I’ve heard good things about Netlify, I thought this was a good moment to try them out. Especially now that I’m using Hugo, one of the common build configurations, switching to Netlify quite simple.

Future

I might want to tweak the theme in the future or see if I can have a more clear separation between the theme and the content. But for the moment I’m happy and enjoying the fact that this project is finished.

The topics I’ll discuss:

• Hosting: I moved from a RamNode virtual private server (VPS) to one from DigitalOcean.
• Serving: I am now using Docker containers to serve this website.
• Deployment: The code behind this website has moved from GitHub to GitLab and I am using their CI/CD to build the Docker image for this site.
• Performance: The difference in performance between my old RamNode setup and the new DigitalOcean machine is minimal.
• Future: Looking forward to new challenges.

Hosting

RamNode

I have used RamNode since late 2012. They have been a reliable partner throughout the years. Their support staff always responded quickly to my questions, is very friendly and willing to go the extra mile. I have been a very happy customer.

I have run this blog on a RamNode VPS since April 2013. However, my setup got outdated. I was still running Debian Jessie which also meant that most visitors could not use HTTP/2 with my website. The reason is that the OpenSSL version in Jessie did not support Application‑Layer Protocol Negotiation (ALPN). (For more information about the exact issue, see Supporting HTTP/2 for Website Visitors.)

Time to upgrade to Debian Stretch. And since the machine was provisioned using Puppet, that should have been a breeze, right? Well, sure. If not for two things:

• I had not used Puppet to install Certbot, which is responsible for the TLS certificates, so I needed to figure out again how to install that software.
• I had fallen out of love with Puppet and wanted to convert my code to Ansible.

Basically this XKCD comic all over again:

Where I previously used Vagant to test my (Puppet) code, I wanted to use Terraform now. The big advantage is that you don’t have to work on a machine similar to what you will have in real production, but you can actually use the exact same machine.

Unfortunately this also meant I could not use RamNode. They don’t offer a “pay-as-you-go” model like cloud providers do. And since I was going to work intermittently on this project, I was looking for a provider where I could create a machine, use it for however long I needed (ranging from a few minutes to a couple of hours) and then destroy it, while only paying for the time I actually used the resources.

Scaleway

This is where Scaleway comes into the picture. Not only do they provide on-demand compute instances, there is also a Scaleway provider for Terraform.

Their pricing is also fantastic. You can get a “development server” (DEV1-S) with 2 cores and 2GB memory for €2.99 a month.

In their Amsterdam data center, you can even get a “Start server” (START1-XS) with 1 core and 1GB memory for as little as €1.99 a month.

(Note that the Scaleway pricing page does not list the Amsterdam offerings so they might align these options in the future.)

For small applications (like this blog) or for experiments these are great machines. Provisioning is quick and besides compute resources, Scaleway offers a bunch of other services (like object storage and virtual firewalls).

Unfortunately I only discovered after migrating this site from RamNode to Scaleway that the Scaleway IPv6 offering is not mature enough for my taste. So I migrated back to RamNode (that is: I changed the DNS records back) and worked on plan B.

DigitalOcean

That new plan was to move to DigitalOcean (referral link). I have used DigitalOcean in the past for a few experiments and liked the experience. They provide a wide range of services, which include managed Kubernetes clusters, object storage and cloud firewalls. There is a DigitalOcean provider for Terraform and the IPv6 support seems to be what I need.

With this snippet of Terraform code:

resource "digitalocean_firewall" "webserver" {
  ...

  inbound_rule = [
    {
      protocol         = "tcp"
      port_range       = "80"
      source_addresses = ["0.0.0.0/0", "::/0"]
    },
    {
      protocol         = "tcp"
      port_range       = "443"
      source_addresses = ["0.0.0.0/0", "::/0"]
    },
  ]

I can configure my firewall to allow incoming traffic to port 80 and 443 from all IPv4 and IPv6 sources:

Do note that DigitalOcean Droplets are less cheap than the Scaleway servers. But I still think they provide good value for money.

With the hosting sorted out, the next piece of the puzzle is the way this website is served.

Serving the content

I used to have Nginx running directly on the machine and it served the static files that make up this website. And that is a perfectly fine setup, it does not have too many moving parts and deployment of a new version can be as simple as copying a bunch of files over to the machine. But…

It wasn’t very exciting to me. And to be honest, that is also part of why I run my own blog instead of using services like WordPress or Medium—I want to tinker with this stuff. (That and the fact that I want to own my own content.)

So the new setup is using Traefik as a reverse proxy. The big selling points for me are the fact that it handles the TLS certificates for me (via Let’s Encrypt, which I was already using) and that I can easily add backend services by spinning up Docker containers with the right labels.

Which is exactly what I did for this blog. It is now a Docker container with Nginx as webserver. This webserver still serves the static content that makes up this website.

In the future I might spin up additional services (I am thinking about replacing Disqus with something self hosted), and this setup should make that easier.

Note that running the services in Docker containers also means I no longer receive automatic updates via Apt of the services that are exposed to the internet (the reverse proxy and webserver). I will have to keep the Docker images I am using up-to-date myself by either building them myself or regularly pulling recent versions. On the upside: I am no longer bound to the version available in a Debian repository; I can run any version of Traefik or Nginx I like, as long as it is packaged in a Docker image.

A noticeable downside of this setup is that deploying a new version is a bit more complex. I can no longer “scp” files to the right directory. Instead I have to supply a Docker image.

Code repository

Enter GitLab. Their service not only includes a Git repository, but also CI/CD and a container registry. In other words: when I push a change, GitLab can automatically build a new image for me.

And that is exactly what I have set up at the moment. When I’m finished with this article, I will:

• git push it to GitLab,
• wait a moment for the image to build (about 2 minutes currently),
• ssh in to my VPS,
• pull the fresh image, and
• start a container with the new image.

Like I said, this is a bit more complex than before where I could copy over my static files.

Then again, that is not a completely fair comparison. Compiling the static files, generating the CSS from SASS and optimizing the images were things I had to do manually before I could copy over the files. But because those actions were triggered by a single command (“make publish”) it feels like it was less complex.

On the bright side: now GitLab is building the content it means I have clean, reproducible builds. There is no longer a risk of unfinished articles popping up in production. (Assuming I don’t accidentally commit and push them…)

Performance

Just like the last time when I switched hosting providers, I was curious about the impact of the change on the performance of this site. Especially because in the new situation Chrome can use HTTP/2 instead of falling back to HTTP/1.1.

For reference: at RamNode I had a standard KVM with 512 MB RAM, 1 CPU core and 10 GB storage on an SSD. At DigitalOcean I am using a droplet with 1 GB memory, 1 CPU and 25 GB storage on an SSD. Both machines are running in a data center in the Netherlands.

Uptime Robot

I am monitoring my website via Uptime Robot. They can show me the response time of the monitors.

These are averages over the last 24 hours. Overall the results are comparable. The only big difference is the IPv6 times, but it looks like it was a bad day for IPv6 at RamNode as you can see in the image below. (If you exclude the spikes you are also in the 500-ish ms range.)

WebPageTest

I also ran a few tests at WebPageTest. I picked a (more or less) random page, my previous post, assuming it is representative of most of the content here: a page with a few images.

I ran two sets of tests. The first one was a run of 9 tests from Dulles, VA using Chrome on a cable connection. The second set was a run of 5 tests from Dulles, VA using Chrome on a Nexus 5 on a 3G connection. The results in the table below are the values reported as the median run.

In these the numbers there are no shocking differences between the old and the new setup. The new site seems to be 100–200 ms faster then the old one though, except for the load time and first interactive time on the Nexus 5 on the 3G connection.

The biggest differences are in the waterfall graphs.

You can nicely see the difference between HTTP/1.1 and HTTP/2 here. In the old setup, you can see six separate connections to my site, where the new setup only uses one.

The future

Migrating this site has been blocking me for a while. I felt like I had to do this first before I could start working on other things. Now this is finished, I can pick up those things.

Things like (in random order):

• I would like to replace Disqus with a self hosted solution (Isso?).
• Webmentions look interesting. Perhaps I can use them as well?
• I might even migrate away from Acrylamid. I still like the idea of having a static website though, and I’m looking at Hugo at the moment.

But I might also want to improve the current setup a bit more:

• The current Docker image building process works, but there are a few things I could improve or at least clean up. (Then again: if I move to e.g. Hugo this might not be as relevant anymore.)
• Pulling a new Docker image and restarting the service with the new image is something that I should be able to further (or even fully) automate. Ideally there will no longer be a need for me to log into the server. Pushing the new post to GitLab should be enough.

So plenty of fun stuff to tinker with!

Puppet

Ever since the deployment knowledge sharing session I attended in 2011, I have fallen in love with Puppet. About three months later I started to use it in my day job. Unfortunately the investment to completely provision our server with Puppet would be too high compared to what we would gain.

But nothing stopped me from doing just that with my own VPS… So the box this site now runs on, is completely configured using Puppet. The only thing that I have not handled (yet?) is the actual content of this site. That is a separate process handled by an Acrylamid task which I have to run after provisioning the server.

To accomplish this, I have a directory which contains the following:

.
├── install.sh
├── manifests
│   └── atlanta.pp
└── modules
    ├── firewall
    ├── ...
    └── webserver

The install.sh script contains these lines:

apt-get update && apt-get -y upgrade
apt-get -y install puppet
puppet apply --modulepath=./modules manifests/atlanta.pp

So all I need to do is scp this directory to the VPS and run the install.sh script and the server is ready. A quick “acrylamid dp atlanta” command later and I am done. The whole process takes only a few minutes.

The process

Most of the Puppet configuration was created and tested locally. To do this I have a Vagrant box (which uses VirtualBox) with almost the same setup as the VPS. I am using Ubuntu 12.04 64-bit on both the VPS and the Vagrant box, but after a reinstall (before I run Puppet) the VPS is still configured a bit different than the Vagrant box. So I had to make some tweaks to the Puppet configuration after trying it out on the VPS.

Once I was satisfied with the result, I started with a fresh install of the VPS, ran Puppet and copied the content of this site over. A small DNS change later and I was up and running. (Since I have a static site and use Disqus for commenting I did not even have to worry about the DNS change propagation time.)

What does Google think?

My main reason to move from shared hosting to a VPS was to get more control over the environment and get more freedom. Still, better performance also would not hurt.

Time to download

This is what I saw in the Google Webmaster Tools:

As you can see, the time to download a page has about halved since April. My initial thought was that this is probably related to the location of the server: the shared hosting environment ran on a server in The Netherlands while the VPS is running in a data centre in Atlanta in the USA. That might make a huge difference if the pages are crawled from the USA.

I did some quick measurements to get some data. To make a long story short: the VPS is indeed a bit faster. There are too many differences between the previous situation on the shared hosting environment and the VPS to be able to tell what caused this difference. But I am happy to see the previous graph none the less.

Other statistics

Besides a change in time to download a page, I also saw that Google crawls more pages a day:

But since there is also an increase in March that I cannot explain, it might be a coincidence that more pages were crawled per day since early April.

What is remarkable is that there is less data downloaded per day while more pages were crawled:

This can—most likely—be explained by changes I made. In the old shared environment I had no specific configuration to cache content. On the VPS I have configured Nginx to send an expiry time (by adding “expires 7d;” to the configuration which sets the appropriate Expires and Cache-Control headers for the response).

Result

I got what I wanted: my site is running on an environment I can completely control (from the operating system level up that is). This allows for experimentation and perhaps even small side projects.

I also really liked tinkering with Puppet to get everything setup the way I wanted it to. Both the sysadmin side of deciding how I wanted things configured and the ‘developer’ side of achieving that configuration via Puppet were fun.

Why

Let me first explain why I started using CloudFlare. Earlier this year I migrated this blog from Django to a static site. At the same time I also switched from hosting at Zest Software back to my old hosting provider, bHosted. Still, I expected to see a drop in the time required to download a page and thus in the related graph in the Google Webmaster Tools. This is what I saw:

As of October 1st—when I made the switch—the time needed to download a page didn’t necessarily drop; instead it became more erratic and often higher than it was before.

I guessed that the expected speed improvement of having a static site was negated by hosting the site on another server. At Zest my site was dynamic but ran on a server that had a very light load and was only hosting a couple of sites. And at bHosted the site is running on a shared server with a load of 2–4 (based on a few samples) and several hundred other sites.

I then by chance stumbled upon the content delivery network provided by CloudFlare. And they even have a free plan.

Setup and first experience

First of all, the video on the CloudFlare homepage is absolutely right about how easy it is to setup. Sure, I know a bit about DNS but basically they do not require you to do very hard stuff. In fact, the most complicated I had to do was to change the name servers so they pointed to CloudFlare. (Actually: I found out that I could not change them myself so I had to ask my domain registrar to do this for me.)

Unfortunately I lost the screenshots I made of my CloudFlare statistics. But according to those statistics, CloudFlare handled about half of the requests and traffic. And, on the side, also blocked quite a few, supposedly, malicious requests.

I made the switch around the 1st of November. I expected that the time to download a page would be more stable but also that is would be lower. (That’s one of the benefits of a content distribution network, right?) Well, I was partially right…

As you can see, the time to download a page indeed did not fluctuate as much anymore. But the download time increased dramatically! And that is the reason why I switched back to serve the content directly from the bHosted server at the end of November, as you can see in the graph.

Google also assigned “special crawl rate settings” in the period I was using CloudFlare. I am not sure what this means and if it’s positive or not. Either way, within a week after taking CloudFlare out of the loop, it was back to normal.

Measurements

Before I decided to switch back to just bHosted, I tried to do some experiments to see if I could reproduce the differences measured by Google. I gathered circa 30 URLs (the home page, the ten most recent articles, a number of popular articles and a (more or less) random selection) and told Siege to have a crack at it. More specifically I used the options “benchmark” (to run the requests without a delay), “internet” (which randomly hits the URLs I selected) and “concurrent” to experiment with different number of concurrent users. These tests ran for 60 seconds each.

Since the bHosted servers are located in The Netherlands, I decided to make the measurements a bit more fair. So I did not run the test from my home (also in The Netherlands), but a RamNode VPS hosted in Atlanta, Georgia.

Results

The shortest transaction for both servers was stable: for bHosted it was 0.21 seconds and for CloudFlare it was 0.14 seconds. The average response time is also comparable (the right graph lines in the image below). The longest transactions however, differed a bit more.

The transaction rate of bHosted and CloudFlare seem to be comparable. (Except for a spike in the bHosted setup at 50 concurrent simulated users. But this could just be a happy accident…)

Summary

As you may have guessed, I am absolutely not an expert on the matter. But what I conclude from this data is that there is not that much difference between serving pages directly from a bHosted server or putting CloudFlare in between.

Sure, the longest transaction time in the CloudFlare setup is larger in some situations. But for my blog 100+ concurrent users are unlikely. (As a matter of fact in December an average of about 150 pages are requested per day. And Google only indexes an average of 80 pages per day at the moment of writing.) More importantly: the average transaction time for bHosted and CloudFlare is practically the same.

Conclusion?

I am sure you should not draw the conclusion that using CloudFlare is a bad thing. Nor do I want to complain about their service—after all I did not pay them a dime. Having said that, my personal conclusion was that since Google is using site speed in web search ranking this site is better off by not using CloudFlare. Your mileage may vary.

On the one hand, a month may not seem like a long time. So why evaluate Acrylamid now? Well, for one thing, I started working with it a bit earlier than October 1st since I had to migrate existing content and develop this site. Another reason is that during the Plone Conference 2012 I published more articles about those three days than I normally do in a whole year.

Writing articles

During the conference I was not able to publish all articles immediately after the talk was over. So I got into the habit of writing my notes in a drafts folder. When I started making the notes ready for publication, I would move the file to the normal directory. (Alternatively I could have added a draft field, but by having them in a separate directory it was easier to see which articles were not published yet.)

Although the Wi-Fi at the conference was almost perfect and the hotel also offered free Wi-Fi, there were a couple of times where I did not have a connection to the Internet while I did want to edit my articles. But since I could do the writing on my own laptop, that hardly mattered. The biggest issues were that I could not look up things easily (I had to use my phone) and that the pages were not rendered with the right fonts since these are hosted externally.

Another thing I liked was my tool set. I am still really happy with Emacs as an editor. I love that I am able to hit C-x C-s as often as I need—no matter the network state. That beats having to edit articles online using e.g. TinyMCE. Not that the latter is a bad thing by the way, I just prefer my good old Emacs.

As for marking up the articles: Markdown also proved to be a good syntax to do so. Only once was I not able to get the result that I was after. I wanted to have a code block inside an unordered list. I am pretty sure it is possible, I just did not know how exactly and rewrote the article a little bit to work around it. Lets chalk this up to me being too lazy and inexperienced with Markdown.

Output

One of the things I am currently still struggling with is my URL structure. Years ago I used URLs like /weblog/title-of-the-article/. I switched to URLs with dates (/weblog/2012/02/04/title-of-the-article) when I switched to Django. In Django it was very easy to write a view that redirected the old URLs to the new ones. But since cool URIs don’t change I have to list all the old URLs in that .htaccess file or else I have to find a more generic solution—for instance by writing a custom view for Acrylamid that uses a <meta> element or JavaScript to redirect visitors to the new URL. In the meanwhile: to mitigate the problem for visitors, I am using Google to make my 404 pages more useful. Most of the times, the search does return the page the visitor was after.

Another thing that bothers me is that I do not (yet) have views that show the articles for a year/month/day. For instance /weblog/2012/10/10/ to see all articles for the first day of the Plone conference.

Conclusion

I am quite happy with the current setup. I am not completely done yet, but for me it is a huge improvement over the Django (and Plone) setups I had earlier. I think it is a really nice lightweight blogging system.

How it started

The redesign I was working on was about two things: creating a responsive (grid based) design and going back to the essentials. I think I was about 90% done when my attention was drawn to static weblogs. I immediately saw the performance benefit: generate a page once and just serve that static file. No database or processing is involved—it’s just a web server returning files.

I already knew reStructuredText and because Tarek Ziadé moved to Pelican and Daniel Greenfeld also created a new blog using Pelican, that is what I started experimenting with: Pelican. However, I did not like the HTML it generated. This is a web development blog and I use a lot of code samples. Plus I like to have (somewhat) semantic HTML. But inline code was turned into <tt class="docutils literal">example</tt>. And I wanted <code>example</code>. And code blocks were only wrapped in a <pre>, but I also want to wrap it in a <code> element.

In hindsight this was probably more a problem with docutils and/or the code highlighting than Pelican itself, but it made me investigate other static blog engines. I found Acrylamid and StrangeCase.

The latter seems to provide a lot of flexibility. But by reading the documentation I got the impression that that same flexibility would make writing a simple article too complex for me as it requires you to write Jinja2 in your article content. Jinja2 as such is not a problem for me, I just don’t want to be bothered with it when writing an article.

Acrylamid and Markdown

Acrylamid on the other hand made it very easy to start. But because it showed the same problems with reStructuredText I decided to switch to Markdown—something I should have done earlier.

The syntax of Markdown is a bit more limited than reStructuredText. For instance: it does not have a way to write definition lists (<dt>) or tables, as far as I know. But Markdown allows you to simply write HTML for the things not covered by its syntax. And since 95% (if not more) of my articles only need the stuff Markdown provides a syntax for, that’s fine by me.

But back to Acrylamid… A few things I like about it: like I said it was very easy to get started and the author is very responsive if you’ve got questions, bugs or improvements (pull requests). What’s even more important: it has all the features I need for this blog: articles (entries), pages, (paginated) lists of articles, tags and feeds.

Migration

Acrylamid provides an easy way to import content from e.g. an Atom feed. This was great since I already provided feeds on the previous version of my site (using django-atompub). So all I needed to do on the Django side was to add was a feed that listed all articles. (Note that I already migrated from django.contrib.comments to Disqus).

Although the migration of the HTML to Markdown wasn’t flawless. There were three things I had to correct manually:

• The categories were not included in the migration. Even though they were provided in the Atom feed (using the <category> element).
• HTML-ish looking content that could not be converted to Markdown was just left out. For instance, I use angled brackets in command line examples (e.g. “git rebase -i <sha1>”). After the migration the whole “<sha1>” part was gone.
• The code blocks were indented three spaces instead of four and thus were not converted into <pre> blocks.

These three combined made me go over all my articles to make sure they had the right tags and the content was still okay. But to be honest, I did not mind that since it also provided an excuse to review the tags I used. Plus, I don’t have that many articles.

Decisions I made along the way

One reason I started the redesign in the first place was that I wanted a responsive (grid based) design. Although this blog should now be more pleasant to read on so called ‘mobile’ devices, I dropped the grid based design since it was overkill and I also doubt whether it can be called a responsive web design. I do intend to make better use of wider screens somewhere in the future, e.g. by placing the meta data of articles to the left of the main content column. But I don’t think it will be completely responsive.

I also decided to drop the images included in (almost) every article since 2009. They usually did not add anything to the content of the article. And it frequently took me just as long to write the article as I spent trying to find a good image.

To clean up the pages I removed the list of tags and the latest entries. Judging by the number of page views per visitor, they weren’t used that much anyway. Speaking of which: the Dutch Telecommunications Act now requires unambiguous consent to place tracking cookies from e.g. Google Analytics. I did not want to place a mechanism on this site to get that consent, so I decided to remove Google Analytics altogether.

Tools I use

Although I haven’t been working with Acrylamid (or any static blog) for long, I do want to share my current approach.

I guess I am getting old because I still prefer using Emacs over e.g. TextMate, Sublime Text or other fancy editors and IDEs. Perhaps it is because you can find a nice mode for just about any file type you can find. I’m currently using:

• jinja2-mode to edit my templates
• markdown-mode for the content
• sass-mode to work on the Sass files. And speaking of which, my Sass files are written in the older, indented, syntax (because if feels kind of ‘Pythonic’)
• typopunct mode for the occasional inclusion of typographical punctuation marks in my content. But usually I have this mode turned off and let the Acrylamid typography filter handle this kind of stuff.
• Magit to manage the git repository (combined with using the command line)

The environment I use to combine all the components into what you are reading now, is described in the README of the GitLab repo for this site. One thing I want to highlight is virtualenvwrapper.gem. This plugin for virtualenvwrapper allows me to install the gems for Sass and Compass inside my virtualenv. Yay!

The checkout of the repository lives in a Dropbox folder. This way I can use e.g. the Nocs app to prepare articles via an iOS device.

Pros and cons

Again: I haven’t been using this approach for that long, but here are the pros and cons I discovered so far.

The disadvantages

Let’s first list the downsides of Acrylamic (or any static blog) compared to a CMS or my previous Django based solution:

• I cannot publish new articles if I’ve only got access to a browser, e.g. when using a smartphone. After creating/editing a file it needs to be compiled. (Then again: I usually have my laptop at hand when publishing an article anyway. I have very rarely published an article while not working on my laptop.)
• I have less control over the HTML that is generated from the text file. This is something that held me back initially from switching to a static blog engine. However, since I can also write HTML in my Markdown files, I can regain full control if I really want to.

The advantages

Now for the benefits:

• I can host my blog anywhere! No complex setup needed. Just some HTML, CSS and Javascript files combined with some images and a limited .htaccess file (mostly for redirects of old URLs) and that’s it.
• For most of my articles I can just write a bit of Markdown and that’s it. No need to worry about or tweak HTML in TinyMCE.
• The code and content live in a single place: my Git repository—no separate database (ZODB, SQL or otherwise) required. The only dependencies are the Python eggs and Ruby gems I use. But everything specific for my blog is in one place. And with my setup that combines Git and Dropbox I think I also don’t need to worry about an elaborate (off site) backup mechanism. (Famous last words? Time will tell…)
• I can prepare the content completely offline: creating new files, editing existing ones, previewing the result and even storing them in Git can be done in isolation. I only need to be online when I want to push my changes to GitHub¹ or when I want to actually publish the content. This will make it easier to blog during conferences where the WiFi setup isn’t always capable of providing a stable connection to a whole bunch of nerds. ;-)

End result

When I started with the redesign about a year ago I wanted to have a responsive (grid based) design and I wanted to go back to the essentials. I think I can say I succeeded in the latter. It doesn’t get more basic than simple HTML and CSS. As for the responsive design: I think the site got more readable and that is what counts, not what label can be attached to it.

I am happy with the current status even though I’m not completely done yet. I just wanted to get this live before the Plone Conference and improve iteratively. I’ll be attending that conference and will try to write an article about each talk I attend. That will be a good test to see how my current setup works…

Thanks

Moving from Django to Acrylamid means I can host my site anywhere. So it now lives on a server of bHosted.nl. But until today it was still running on a server of Zest Software, the company I left almost two years ago. They were kind enough to tolerate me and spare me the trouble of finding a new location for the old Django site without even charging me. Thanks guys, I really appreciate that!