Andy Hedges' Blog

The Simplest Blog That Might Work

I’m aiming for a simple, fast and minimalist blog. A blog where writing posts is all I have to think about, not themes, fancy backgrounds, AJAX, hosting services, cloud APIs and well one starts to lose the will to live.

Raspberry Pi in a takeway container on top of random network equipment
Figure 1. Raspberry Pi in a takeway container

The design goals are:

  • simple
  • cheap
  • fast

I’m quite pleased with the way it works, it’s probably not for technophobes but then nor is blogging. In order to publish a post you create a new text file with your post in it in a simple directory structure, if you have any images, video etc then you drop them in a “resources” folder. If you’d like some formatting in your post you can use markdown. After that, run a simple script and everything is taken care of: it’s published to the web. So far my limited posts look like this in the directory structure:

$ tree --charset US-ASCII posts/
posts/
|-- 20120216
|   |-- article.yaml
|   `-- resources
|       |-- First-Project-Syndrome-Figure1.png
|       `-- First-Project-Syndrome-Figure2.png
`-- 20131230
    `-- article.yaml

3 directories, 4 files

How it works

The markdown from the YAML file is converted to HTML, which is minified (optimised to remove redundant spaces etc), and then put into a folder which btsync is watching, once a change is noticed it is synced to all computers with btsync installed on, including, most importantly the web server.

A Note On DNS

As I’m hosting this on my home broadband connection, which doesn’t have a static IP address, I needed a way to update my DNS record quickly every time my IP address changed. To do this I used a free service DNSdynamic which gives you a subdomain on one of their domains (e.g. example.dnsdynamic.com), I chose andyhedges.http01.com but anything would work, you then install a client which regularly checks your IP address and updates the DNS if need be. This is great but I wanted to use my vanity domain name hedges.net, I therefore configured a CNAME with my DNS registrar to point blog.hedges.net to andyhedges.http01.com and I was in business, DNS-wise at least.

Costs

The cost of my blogging platform breaks down as below:

  • software - £0 (all open source or freeware)
  • hosting - £0 (using my home fibre connection)
  • hardware
    • Raspberry Pi - £28.99
    • Power Supply - £0 (free with phone)
    • Network Cable - ~£1
    • SD Card - ~£4
  • DNS - £0 (using my DNS registrar and Dynamic DNS provider)

There we have it, a blogging platform for thirty four quid that doesn’t require 3rd party hosting. It remains to be seen if my ISP gets cross.

Benchmarks

On the little R’berry Pi a quick benchmark with no optimisation shows it can handle 250 requests per second with a response time of 3ms (across my home gigabit network).

Todo

There are still a few more to-dos:

  • preview mode
  • comments (I think I’ll use disqus or maybe G+)
  • RSS
  • optimising Nginx (e.g. gzip or sdch, SPDY, threads and so forth)
  • smartypants-like substitution
  • Open Source it (tidy code, add licenses put it on github)
  • Set up a 301 Moved Permanently on a virtual host for the Dynamic DNS name

Full details

For those interested the full details of software, hardware and network.

The tools I’ve chosen for the client side are are:

  • Notepad (although sublime, textpad, gedit or vi would do), this is for editing the posts
  • btsync this enables me to keep the webservers and any computer I use in sync with all of the generate content, the source information and templates, more on that later

The development tools:

The software libraries:

  • SnakeYaml this is a YAML binding for Java, YAML is basically a human friendly information format, similar to XML or JSON but unlike those two easy to read and write for us humans.
  • FreeMarker is a templating language similar to JSP or Razor and provides an easy library to integrate it with your projects
  • Actuarius a markdown to HTML converter
  • htmlcompressor an HTML minification library
  • YUI Compressor a CSS minification library

The server side software:

  • Nginx a nice, light, fast HTTP server
  • btsync see above
  • ddclient The Dynamic DNS client that allows me to have my DNS record updating when my ISP changes my IP address
  • Raspbian A Debian Linux variant for the Raspberry Pi

The hardware:

  • Raspberry Pi a circuit board sized computer
  • Indian takeaway container, no this isn’t the wacky name of some kickstarter project, I used one of the plastic tubs that takeaway curry comes in to provide a case for the Raspberry Pi, it keeps dust and/or water off it
  • Mini USB charger plug and cable from my Nexus 5 (I have so many of these and so I chose a smallish one)
  • Network cable from my man draw

The network:

  • Existing Fibre connection and associated routers and access points
  • Netgear Gigabit Switch
Andy Hedges

First Project Syndrome

I hold the opinion that Services (as in SOA) should, where at all possible, be delivered as separately budgeted and planned work from functional enhancement projects to avoid First Project Syndrome.

To understand what First Project Syndrome is let’s take a look at some graphs (bear with me…).

Capital Cost

Capital cost vs number of projects
Figure 1. Capital cost vs number of projects

As you can see from figure 1. the assertion is that the cost of delivering the first project with a service is higher than for the first project using a point solution (by point solution, I mean grabbing data from source data stores or replicating data into your database or any number of data sync techniques). The reason why this costs more for the first project is:

  • there are overheads with creating a service such as following their prescribed best practise
  • creation of infrastructure to run the service
  • some expert knowledge in SOA practices

However from the first project onward the savings are realised. The reasons why point solutions cost more from the second project onward are because:

  • a point solution often starts from scratch each time, the work has to be redone and redone slightly differently for each specific scenario
  • point solutions layer complexity upon complexity (e.g. tables accessed by many unknown systems, various extract files created for many systems, data shunted to and from multiple undocumented systems)
  • it’s very hard not to make mistakes when syncing data
  • syncing data causes all sorts of edge cases when trying to modify it

Operational Cost

Operational cost vs number of projects
Figure 2. Operational cost vs number of projects

Point solutions are almost always more expensive to manage, with a service built correctly and to specification the operational costs are lower: day one. They are easier to manage, monitor, failover and so on. The significant reason why they have these qualities is because they are conforming to set of good practises that specifically give these qualities. They leverage the wealth of investment made on previous service developments within the organisation. Each service then stands as a container for future enhancement in its particular business domain allowing functionality to be added and still providing the operational characteristics demanded.

More often than not the first project does not consider, in detail, the operational cost of managing the solution on-going or may not have the budget/resource/time to seriously take this in to account. Typically the projects have the more immediate concern of getting the solution shipped to the business.

Other Common Pit Falls

There are a number of other pitfalls of delivering services as part of the first project. In no particular order:

  • the first project’s scope determines the scope of the service making it less suitable for other consumers
  • freezing of the project causes the service to also be frozen where that service would have had wider benefits to the business. The case for the project didn’t stack up and so the assumption would be that the service’s case didn’t either.
  • compromises in the design of the project solution force compromises in the service design

To all these points I would posit that the first business project that requires a service should not be the project that delivers that service. This does, of course, mean that the business case should stack up against more than one business facing project (and if it doesn’t then it probably isn’t worth building).

You wouldn’t try to create a power station as part of the build of a house but every house needs one to function.

Andy Hedges