Blogging with Metalsmith

30 Jun 2015

I'm switching blogging platforms once more. Moving from Wordpress to Jekyll enabled me to no longer deal with the multitude of updates and protected me hacks I could be susceptible to, but Jekyll being written in Ruby (a language I'm not overly familiar with) has been a problem. I've been able to cobble together scripts to deal with the custom parts of my blog build, but it's never felt like home.

I've decided to start using Metalsmith - a static site generator written in Javascript. It's existed before my switch to Jekyll and now seems to have enough of a plugin ecosystem in order to provide a collection of plugins to provide behaviour I need to make use of.


Metalsmith operates much like a task runner like gulp, where a set of functions manipulate a number of files, one after another in order to eventually build a static site to your liking. A simple build script could be as follows:

var Metalsmith = require('metalsmith'),
    markdown   = require('metalsmith-markdown'),
    templates  = require('metalsmith-templates');


This is just standard node script with dependencies installed via npm. Metalsmith assumes defaults of src and build for the source of markdown and destination of html. An example of markdown containing some useful front-matter might be as follows:

title: Blogging with Metalsmith
author: Ian
date: 2015-06-30
year: 2015
month: 2015/06
  - Javascript
  - metalsmith
  - javascript
I'm switching blogging platforms once more...

It also assumes a default template directory under templates, containing a default post template 'post.html' - which in the example is written in a swig template as below.

    <div class="post">
    <h1><a href="/{{ path }}">{{ title }}</a></h1>
    <div class="post_date">{{ date | date('d M Y') }}</div>
    {{ contents | safe }}

I've managed to reduce my build time (though I'm not currently compiling sass and have added a new sitemap), but am much more familiar with the toolchain in question. Hopefully that'll lead to further, more frequent updates not just in content, but also the design of my company site and this blog.

I'll be adding future blogs about my metalsmith toolchain and hurdles with that I've overcome.

Tagged metalsmith, blogging, javascript, | Leave a comment

The Move Towards Static Websites

22 Jan 2013

There’s some discussion on new podcast “The Back to Front Show” on why of late we’re seeing so many static websites cropping up. It seem like now more than ever, we’re seeing both developers and designers jump ship to this way of working, having long been using database backed solutions (such as WordPress/Drupal) to manage their publishing.

When I talk about a static site, I think of it of raw HTML sat on a server and nothing else. However, it seems as if the industry has adopted the term to refer to sites created from tools which are capable of creating/emulating this HTML, whether it be a local, dropbox or a hosted/self-hosted solution. Typically both types of tool are powered through conversion of flat files into the markup which is served publicly. Through using them you can achieve something akin to a typical blog, without the need for a database (or possibly even a server-side language to power it).


Simplicity – Most of the draw toward toward such setups seems to be on the simplicity over flexibility. I can power a site with a minimal setup, but still regularly and simply update and maintain it, using a partial based environment. With a dropbox based solution, I just need to drop my flat files into a folder and everything is updated transparently. Mark Boulton has previously written about his requirements for writing on the web and why he went with Statamic:

“I wanted a way of simply publishing words, rather than getting all wrapped up in php, theming files and database problems.”

Simplicity it seems, rules.

I previously wrote an article on how you could publish using Octopress and Amazon’s S3 service. For anyone who has a relatively low traffic site, such a setup could also work out cheaper than a monthly hosting package.

Development Time – If you’re one for creating custom themes, a static site is also a much simpler solution than wrestling with styling the innerds of a full fledged cms. Typically posts are stored in markdown and can be styled along with assets using a partial templating system (eg. based on YAML or Liquid). Having recently developed a wordpress theme I can testify to the complexity of having to dig through documentation on function usage and to determine which template file should be modified to achieve what I want within a page.

Source Control – As Rick quite rightly points out below in the comments, having all your posts available in flat files makes them perfect for managing/backing up through your revision control tools of choice.


Customisation – For me, the big loss is the lack of flexibility. I hear everyone cry, “Well, duh – it’s static”. Without a server side language handling requests, I’m unable to schedule posts, handle comments, create forms or trigger email. If I intend on continuing to offer them, I have to find third party services to deal with each of these aspects. I’m well aware there’s services like disqus and wufoo that may solve some of these problems, but it seems like a major hassle to integrate each time something like this is required. It may be that this is just me, you may be perfectly happy using these solutions, or may not require them.

Remote publishing – When using a local based solution (e.g. Jekyll), you don’t have the option of blogging remotely, due to the lack of tools to create and push out your content. Gone are the days of being able to log into a site from your phone and add a small update. For me, this is less of an issue as I can’t recall if I’ve ever written a post in this way and try to be more methodical, less spontaneous about what I’m writing from the comfort of my desktop.

Example Systems

If you’re interested in running a static site, then I’ve listed a few that seem pretty popular at the time of writing, along with a brief list of their features.

Jekyll – Locally run, File based, Open source, Powers Github pages.
Octopress – Locally run, Jekyll/File based, but with preconfigured HTML templates, CSS, Javascript, Open Source
Statamic – Self Hosted, File Based, License Required
Kirby – Self Hosted, File based, jQuery inspired API, License Required
Stacey – Self hosted, File based, Open source
Scriptogram – Dropbox/File based

Tagged blogging, blogs, | Leave a comment

New Year, New Theme

21 Jan 2013

I’ve long made use of the default theme on WordPress, which I’ve always felt wasn’t entirely “me”. The theme now live is one I’ve been tinkering with for a while now based on the lovely preview design used in the document editing tool for github. I really like the focus on simplicity and think it suits me well.

I’ve added some different styling for the navigation elements, given they didn’t already exist on I’ve also added some subtle colour changes when navigating between pages, many of which are based on Laura Kalbag‘s palettes over on colour lovers.

One of the things I hadn’t counted on was consolidating 10 years worth of blog posts into sensible categories as it was becoming a bit of a mess. When I first started blogging, wordpress didn’t exist, let alone tagging and I think I started out using categories in a manner to replicate them.

There’s still a few things I’m not entirely happy with, such as how navigation is represented for single posts. I intend to tidy the theme up and release it back to the WordPress community, but for now I’m enjoying having finally got it out in the open. Feel free to let me know what you think.

Tagged blogging, | Leave a comment

Hosting an Octopress Blog on Amazon S3

09 Sep 2011

Octopress is a framework for blogging based on the static site generator jekyll. In short jekyll takes markdown and turns it into blog style html ready to be served straight away with Apache whilst Octopress dresses it up nicely with HTML5, responsive layout goodness and gives you a bunch of options for code formatting and the like. A perfect little blogging setup for hackers for those of us who typically won’t need all the bells and whistles on our blog I’m sure you’ll agree.

Using Octopress, you’d typically write your posts in markdown and process them locally. You’d then have a number of HTML pages to upload to your web server, which would appear no different than any other blog in terms of functionality.

The most interesting thing that coincincides with the creation of jekyll is that it is now possible to serve static websites straight from Amazon S3, meaning that it isn’t neccessary to have a web server to serve a Octopress blog. I’ve been playing a little and have been able to serve my own octopress blog which you can see over at Here’s how to do it:

Configure an S3 Bucket to Act as a Website

NB: If you want to use your own domain, then you’re going to need to create an S3 bucket from the AWS Console named the same as your domain (so for me I created a bucket called “”.

To configure your bucket as a website, from the AWS Console, select the new bucket and click “Properties”. Choose the “Website” tab from the box that appears and check “enabled” and set the Index document as “index.html”. Click “Save”. Now move to the “permissions” tab and click “Add bucket policy”. Enter a policy as below, with “” replaced with the name of the bucket you’re using.

<br /> {<br /> "Version": "2008-10-17",<br /> "Id": "",<br /> "Statement": [<br /> {<br /> "Sid": "PublicReadForGetBucketObjects",<br /> "Effect": "Allow",<br /> "Principal": {<br /> "AWS": "*"<br /> },<br /> "Action": "s3:GetObject",<br /> "Resource": "*"<br /> }<br /> ]<br /> }<br />

If you’ve opted not to use your own domain, then that’s it for S3. Your new bucket website will be available at a combination of the bucket name and the S3 storage location. In my case, this is There’s a list of endpoints on the “website endpoints” page in Amazons S3 website docs.

Configure DNS

If you’re wanting to use your own domain, then you’ll need to visit your domain registraar and edit some DNS entries. In my case, I added a CNAME entry “www” pointing to You’ll need to use a tool like wwwizer in order to forward from the root of your domain to the www subdomain. e.g. “” to “”. To get that working, you’ll also need to modify the @ A record and point it to Read this serverfault post if you’re interested to know why.

For more info on CNAME configuration and S3 see Amazons S3 website docs (Specifically the notes on virtual hosting).

Download Octopress and write some Markdown

Having successfully configured Amazon S3 to host your blog, you need to tackle the age old problem of writing some content for it. This was particularly hard for me, given my lack of knowledge about markdown! You may like to take a look at John Grubers explanation of markdown if you’re suffering like me. The Octopress blogging basics gives a good overview of how your new local blogging workflow will work. Essentially new posts are written in the ./_source/posts folder and when rake generate is executed, your entire websites content is output to the ./public folder. You can also run rake preview in order to preview on a local server.

TO publish your blog, it’s merely a matter of transferring your /public content to the S3 bucket you’ve generated.

Having done all that you’ve now no need to run your own server. You’re still dependent on those that operate at S3, wwwizer and your domain registraar, but you’ve removed your own from the equation. You may be interested in checking out Jerome Bernard’s tip on easily deploying Octopress blogs with s3cmd.

Tagged amazon, blog, blogging, godaddy, jekyll, octopress, s3, | Leave a comment

Are Music Blogs getting a Raw Deal?

31 Jan 2009

I can’t help but feel a little sorry for music blogs as of late. I’m sure you may be familiar with The Hype Machine and may use it on a daily basis. For the uninitiated, it is essentially a music blog aggregator, which takes details of tracks and ranks them based on how often they appear and how popular they are. I’ve found it really interesting to browse around and discover new artists.

However, lately I’ve been wondering if these blogs are getting a raw deal. From my own personal experience, I can say that recommending music takes a lot of time and effort, especially if you decide to go into detail about your choices. Often, the recommendations which the Hype Machine scans are sourced from long detailed blog posts, which I’d say were put together to provide some context for why the author made those choices on any particular day. These aren’t put up quickly without little thought. However, I generally never look at these posts when listening to music from the hype machine, as I’m after that next great track fix. I can’t imagine that these blogs get much traffic that translates into loyal visitors from the machine. I’ve previously also heard that many of these blogs get a huge amount of their bandwidth eaten up from the number of downloads/streaming they get as a result. I don’t know who is to blame here, or if indeed this problem exists, whether the blogs are providing unneccessary background information or getting good results from the machine, but I still feel a little sorry for them all the same.

[Update 2/2/08: One thing I forgot to mention here is that there are alternative services offering a different way of providing music recommendations. I recently discovered the Peoples Music Store which allows users to make music recommendations within their own unique stores. The users get 10% of the sale if people decide to purchase from their stores. I really like the idea, but I'd imagine people might take these recommendations and purchase somewhere cheaper, like amazon.]

Tagged blogging, blogs, hype machine, Music, | Leave a comment