Matthew

Hosting on Amazon S3

Amazon has an excellent guide for hosting a static website on S3. It covers the whole process from setting up the buckets and uploading files, setting up DNS rules to redirect visitors to the buckets and setting up a CDN using Cloudfront. I didn't go as far as setting up a CDN, but it's reassuring to know the option is there, and isn't much added effort beyond what I've already done.

For registering my domain, I recieved recommendations for Gandi and Namecheap, and ended up going with Gandi, if only for their motto ("No Bullshit"), and the option of a cheap SSL certificate if I decide I want to use it.

In my mind, one key benefit with using S3 for hosting this static website, is that there was no server configuration at all. I only had to flick a switch to turn the S3 bucket into "webserver mode", and point it to my index.html. Amazon recommend their Route 53 DNS, which has no immediate benefit to me right now, but if I put any future projects on AWS, it has features for health-checking and failover.

Like most of Amazon Web Services, you are charged on the basis of what you use, I've had no upfront cost associated with my project, except registering my domain. Amazon clearly go to a great effort to make the barrier of entry as low as possible.

I didn't actually upload my files to S3 through the web interface. s3cmd is a command line tool that allows you to upload files very easily. The advantage of this is I that I can make simple fabric or Make scripts to automate the the process of generating the blog with production settings and uploading to S3. Pelican and s3cmd only require a few commands, but it's nice to be able to reduce that further, and if I needed to add more steps before I could publish, then a script handles this better than an increasing list of commands to run in order.

Making this blog

There are loads of really good tools for generating static sites, but I went with Pelican. It's written in Python, uses Jinja for templating, and allows composing articles in both reStructuredText and Markdown.

The quickstart guide is great, and had me with a working site in short order. I didn't much like the default theme that Pelican ships with, but that wasn't a problem, as there is lots of inspiration available. I wanted something simple and readable, that I could easily add my own customisations on top of, so I forked Jody Frankowski's blue-penguin. It also comes with the popular Solarized colour scheme for Pygments, which lends some nicely styled code highlighting that matches the colour scheme of the site.

I wanted to change the fonts in the theme, so looked on Google Fonts for some fonts with free and open licences. I found Crimson and Raleway. For the font nerds, Crimson is very similar to Minion, and Raleway is the base font in Skeleton. I wanted to make the blog look better on smaller devices, and so decided to pull a CSS Grid into the framework. Skeleton is ~400 lines long, which means it's dead easy to see what it's doing, and makes a great base to work off for a small site with very few elements like this, where any of the more popular grids would have been overengineering for the problem.

I think grids can be a double-edged sword. Inless you are very diligent in how you structure your markup, it's easy to add unneccesary <divs> and classes. They add a lot of utility but can work against you if you are trying to make the markup semantic. Ideally, I should me able to swap out the CSS, and the markup would not need touching.

Pelican requires some config to generate pretty URLs. To avoid all my URLs ending with .html, I needed to change some _URL and _SAVE_AS settings in my pelicanconf.py like so:

# Pretty URLs
ARTICLE_URL = 'article/{slug}'
ARTICLE_SAVE_AS = 'article/{slug}.html'
PAGE_URL = 'page/{slug}'
PAGE_SAVE_AS = 'page/{slug}.html'
CATEGORY_URL = 'category/{slug}'
CATEGORY_SAVE_AS = 'category/{slug}.html'
TAG_URL = 'tag/{slug}'
TAG_SAVE_AS = 'tag/{slug}.html'
ARCHIVES_SAVE_AS = 'archives/index.html'

You can look at the source for both the blog and the theme on my Github.

Hello World!

So I've decided to start writing a blog. As with all beginnings, sometimes simply getting started is hard. This post, unimaginatively titled “Hello World!”, is that tricky start, so please excuse the lack of any originality.

First, I must make a confession, this wasn't even my idea! In the autumn of last year, my company started a mentoring scheme. I'm a very new developer, having only been doing web development since June 2014, so the opportunity to learn from an experienced dev was not to be missed. Already a big thank you has to go to Chris, for volunteering his time and wisdom.

After some discussion with Chris about my motivations, we used a simple “five whys” exercise. From Chris' perspective, it helped him really understand the reasoning behind my goals, and from my perspective, it helped me justify my intuition of what I wanted. It's surprising how challenging the exercise can be by the fourth or fifth “why?”

Based on our talk, he suggested that I start a blog.

Day to day, I work with mainly with Python and Django, and while a great deal of what I'm interested in and want to learn fits into my regular work, not all of it can.

This blog is not for just the things that don't fit in my job, but as a way of me recording everything that I'm messing around with. A great deal of learning is achieved by hacking away yourself, but one aspect of learning can be trying to teach others, even through the very indirect means of writing a blog.

On the way, I hope that this might be at least a little informative for the reader, as I publish my ramblings about the things I'm tinkering with!