Building This

Posted on August 4, 2016 by John Duhamel

Ok, now that my site is up and running, I’d like to make a post about putting it together…


In college, I set up a mediawiki server that I hosted from a dusty computer in my closet. It turned out to be incredibally useful. Over time, it became my playbook of tricks that I used to get through engineering school.

Over time, my Mediawiki server was somehow forgotten. The LAMP stack became outdated as people moved to new architecures designed for the cloud. I was busy at my job, and I just didn’t find the time to keep my server online. The power went out at my apartment one night, and the server was never turned back on.

I had strong opinions about how to build my site. It would need to be unambiguously better than what I had before. My new site would showcase the types of systems I have learned to build.

For months, building this site felt like it would be too much effort. I wanted to spend the my small amount of time outside of work on other projects. To name a few, I tried building a system for tracking NCAA statistics and an e-commerce platform for selling drones. However, none of my projects gained much traction. I realized the tool I was missing was my old wiki. After some thought, I decided I decided to start the project.

So here I am…


My first task was to define exactly what my new site should do. The only general requirement I had going in was that it should be unambiguously better than my old site. What did that even mean? After some thought, I decided my site should do the following things.

Cloud Hosted

Over the past year, I’ve come to understand the huge benefit of hosting things on the cloud. Services like AWS provide complete suites for all web-hosting related tasks. Hosting things on the cloud saves that operator invaluable time to focus on other things.


More and more, I find myself revisiting code that I worked on months ago, and don’t have a completely clear memory of how it works. I frequently wish I had written down some notes that I could go back and reference. I plan to use this blog for exactly this purpose. As I work on projects, I’ll use this to keep a record of the challenges, decisions, and lessons I encounter.


Blogs are a nice way to create a narative around your thoughts. However, it’s cumborsome to write a blog post for every little thing to want to record for future reference. Wikis are much better tools for for tracking these little details. Thus, I wanted my site to have a wiki.


The intended audience for this site is myself. Regardless, people with whom I engage with professionally will inevitably discover this site. Thus, I want to convey information about myself that I’d like other people to know.

Static Site

I made a conscious decision that my site would be static. At work, I use Javascript for almost everything. This allows you create all sorts of neat interactive content. However, doing so takes a lot of time and effort. I don’t want to need to spend time maintaining my site. Thus, I decided that a static site was the correct approach for this project.



Hakyll is a static site builder written in Haskell. It’s inspired by the popular site-builder Jeckyl, which is written in Ruby. Hakyll uses Pandoc to convert several data formats (including Markdown and Tex) to HTML, so it’s likely to support all my needs in the future. Furthermore, it supports publishing an RSS feed, which I think would be a neat feature that I’d like to take advantage of in the future.


Gitit is a Haskell-based wiki engine that resembles mediawiki but also uses Pandoc to compile several formats to HTML. I was never a huge fan of the mediawiki markup language. It works well, but I’d prefer to write my pages in Markdown. Gitit makes that possible.


Deploying Hakyll and Gitit on Docker and Elastic Beanstalk provided a few unexpected challenges. Both Hakyll and Gitit are heavily file-based, and by default Docker does a poor job of persisting data between deployments. I’d need to build some extra machinery to ensure my data

After a few evenings of work, I’m pretty happy with the result. Here’s a diagram:

My entire site is backed up in a private S3 bucket. This provides reasonable guarantees that my data is safe and will stay online indefinately.


My site has been running reliably for a few weeks now. I’m pretty happy with the results. I think that I chose tools that are well suited for my needs, and I learned a ton!