Experimental/multiblog - Refactor of blogs - Discussion of future of HSBNE website/services.

## Overview

This pr is kind of to spur a bit of discussion, rather than to be just merged in. If you merge my other PR first it should make this pr a bit clearer, as its only 1 commit in this branch (b8e1dc0)

## This PR

This is a sort of play around with splitting out this multiblog concept that seems to have taken root on this website.

I'm not really expecting this to get merged, it has some issues:

 - Post URL's are not heirarchical, ie project posts get /blog/ urls, not /project/ urls.

The advantages over the current implementation:

 - Less fuzzing of the posts folder, clearer delineation of sections

In the end, while this is better, I would not advocate it as a solution.

I think, a few things need to be decided.

1. Projects should not be on the website. I think it would be great for people to blog about their projects, but that can be in the main blog feed. If people wish to maintain info dumps on their projects, a wiki is more appropriate (more on that in a bit).
2. Events and Classes, I'm not sure why they are separate? I mean, they're prettymuch the same thing.
3. Events and Classes should not really be in 'blog post' format, since we may have recurring things that should not be attached to specific dates, ala tuesday nights. We can manage auto updating the front page list via a similar method used for the meeting notes, and each event/class can just be its own page (preferably markdown)
4. The blog should just be the blog. Encourage members to use it and talk about the cool things they are up to. I've pushed in master a footer link to edit pages. I can also provide on index pages potentially a 'create new page here' button. Although I think if you're going to get into mucking around with site structure like that perhaps you should make a clone. Is fine for 'new blog post' though. I think I'll make a PR for that at least anyway.

## Wiki, Backends and External Services.

The reason that we run this setup, ie jekyll on github, is that its by and large accessible, data wise (ie its flat html and markdown files in a file structure, rather than data and meta-data in a database of some kind), and that while its not WSYWIG editable, its acceptable.

It behooves HSBNE to make sure that as much as possible, when we are hosting any kind of service, that we are responsible for the upkeep of as little as possible for that service. It's pretty apparent that we are unable to even keep content updated on the website, I would hate to think of how we would go with security patches if we were hosting ourselves.

This essentially leads to the conclusion that hosted services, like webpages and api's etc, should only have us worry about the application, rather than any supporting architecture. As such, github pages is ideal for our website, since it should be more or less a Pamphlet or PR device with some living elements.

When we are talking about a wiki, my recommendation, and current prototype build ( which theban, or Brendan C is currently looking to finish up ) is a [gollum](https://github.com/gollum/gollum) instance on [OpenShift](https://www.openshift.com/). You can play with it at [http://gollum-hsbne.rhcloud.com/](http://gollum-hsbne.rhcloud.com/)

OpenShift is a managed VM server platform that allows application management through a git interface. This basically means that you say you want to run an app based on this environment, they give you a vm thats got the software needed on it, and they maintain that image for you, while you worry about your app.

Gollum is a lightweight wiki in Ruby. It stores its data again, in flat files in a repository, like the website, so the data is **Extremely portable**. With plugins like [OmniGollum](https://github.com/arr2036/omnigollum), we can implement logins and 'member only' areas. It fits the bill for our needs ideally.

If members wish to build backend services and api's to do cool things, it is my future recommendation that they utilise OpenShift to do so, and they expose a [MsgPack](http://msgpack.org/) and [JSONP](http://en.wikipedia.org/wiki/JSONP) api that can be consumed by anything from microcontrollers to the javascript on the website. This way we get a loosely coupled architecture of services, none of which have to be expressly managed outside of the applications themselves.

This of course, is a little off the beaten path. But I think the whole sort of ties in together. I'm interested in the discussion this spurs.

## Finally

I think these are the important points to consider:

 - HSBNE does not and should not 'manage' servers or server environments
 - Data and/or content should be stored in as accessible and portable a format as possible. Flat files == good, Database + metadata == bad.
 - In cases where users interact to edit, editing should be as easy as possible. EG: The website and gollum both allow in browser editing. If editing is not ideally easy, look at methods to make it easier.

Lastly

 - Iterative improvement on existing work is far more productive than 'throw it away and replace with something new'. Everything will have some kind of issue with it. Addressing these is better than continuing to reinvent the solution, ground up.