fix(docs): Added mocks for guides, wrote why bother article

docs/guide/deployment.md

@@ -0,0 +1,9 @@
+---
+title: Deployment
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+

docs/guide/documentation.md

@@ -0,0 +1,143 @@
+---
+title: Documentation
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+---
+
+Ubiquits comes with documentation generation tools out of the box, so all you need to do is start writing.
+
+Under the hood of `@ubiquits/toolchain` is the awesome tool  [Metalsmith](metalsmith.io) which allows for the 
+ automatic generation of static sites using simple markdown source files and handlebars templates.
+
+Ubiquits ["eats it's own dogfood"](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) as such so this documentation
+ is generated using the same tooling. 
+
+## Getting started
+To start writing documentation, first start up the documentation watcher:
+
+Example:
+```
+$ u
+[ubiquits] Loaded 12 commands. Type 'help' to see available commands
+ubiquits~$ doc watch
+[doc] Removing directory ./dist-docs
+[doc] Done.
+[metalsmith-watch] ✓ Live reload server started on port: 35729
+[metalsmith-serve] serving /Users/zak/ubiquits/ubiquits/dist-docs at http://localhost:8080
+[doc] Copying doc assets from toolchain
+[metalsmith-watch] ✔︎ Watching **/*
+[doc] [ubiquits] Doc watcher started at https://localhost:8080
+Run 'doc stop' to stop the watch server
+```
+
+Now all you need to do is open your browser to http://localhost:8080
+
+Note that you can still run other commands within the ubiquits console. To stop the watch server, just run `doc stop`
+ or `CTRL+C` (twice) to close the entire console.
+
+## Adding pages
+Pages can be easily added by just creating a new markdown document anywhere under the `./docs` directory and putting some
+yaml [frontmatter](https://jekyllrb.com/docs/frontmatter/) meta information.
+
+For example the frontmatter for this page is:
+```
+---
+title: Documentation
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+---
+```
+
+### Collections
+Collections are groups of pages, and can be used to generate listings or navigation automatically.
+By default, the ubiquits toolchain processes three collections:
+* `main` - the top-level items that should appear in the navigation
+* `guide` - pages to go under the guide page
+* `news` - all pages for the news section
+
+If you set the `collection: <type>` attribute in the frontmatter of your page, it will be automatically added to their
+ respective listings or navigation sections
+
+*Note: you may need to restart the doc watcher when adding new files as it only does a rebuild of changed files, 
+and listings sections or navigation items may depend on other items*
+
+
+### Templates & Partials
+The template defines which handlebars template is used to render the page. The toolchain provides a few defaults:
+
+| Template  | For                   | Features                            | 
+|-----------|-------------------------------------------------------------|
+| basic.hbs | Anything simple       | None                                |
+| guide.hbs | Creating guide pages  | Contents section, pending display   |
+| post.hbs  | News articles         | Date information                    |
+
+All templates can be overidden by just placing your template in the same location as the toolchain.
+See [the template directory in the toolchain](https://github.com/ubiquits/toolchain/tree/master/docs/templates) 
+for the locations of the layouts/partials
+
+### Styles & Assets
+Like templates & partials, you can add your own assets into the `./docs/assets` folder. 
+Any file that matches the same name as the toolchain will override the default.
+
+### Variables
+The `./package.json` file content is available globally to handlebars templates at `{{pkg}}`
+
+Currently there is no other options to pass in extra variables, 
+if you'd like this capability, [get in touch](https://github.com/ubiquits/toolchain/issues).
+
+## TypeDoc
+To document your API in it's full detail, [TypeDoc](http://typedoc.io) is used to automatically generate documentation.
+You can see an example of this documentation at [/api](/api)
+
+To run the generator, execute `typedoc` in the cli. This takes a while so we don't run it on every watch. This is
+ automatically run on deployment of the documentation, so you usually don't need to worry about it when writing docs.
+
+## Deployment
+The toolchain is configured to be able to automatically deploy to github pages on the gh-pages branch.
+If you want to deploy to a different destination see the configuration options below:
+
+### Config
+Configuration of the deployment is handled in the `ubiquits.js` file. 
+By default, the documentation will deploy to the `gh-pages` branch at your repositories `origin`.
+
+If you have different requirements, see the [`UbiquitsProject.configureDeployment()`](/guide/cli/#-configuredeployment-config-) section for configuration options.
+
+### Travis CI
+To automate deployment fully, you can use TravisCI to run the deployment process, however you will need to configure
+ keys so that Travis can push the documentation into the target branch.
+
+* Add the following to your `.travis.yml` file:
+
+```
+ after_success:
+ - npm run coveralls
+ - eval "$(ssh-agent -s)" #start the ssh agent
+ - chmod 600 .travis/deployment_key.pem
+ - ssh-add .travis/deployment_key.pem
+```
+* Add your *encrypted* private key to .travis/deployment_key.pem.enc 
+- see https://docs.travis-ci.com/user/encrypting-files/#Automated-Encryption for more encryption instructions
+
+Note that you **MUST NOT** commit your unencrypted private key directly into .travis/deployment_key.pem.
+
+## Plugins
+The toolchain currently uses the following metalsmith plugins:
+
+* metalsmith-markdown
+* metalsmith-layouts
+* metalsmith-permalinks 
+* metalsmith-serve
+* metalsmith-watch
+* metalsmith-prism
+* metalsmith-collections
+* metalsmith-define
+* metalsmith-date-formatter
+* metalsmith-headings-identifier
+* metalsmith-headings
+
+At this time adding new plugins is not configurable. If you'd like this capability, [get in touch](https://github.com/ubiquits/toolchain/issues).
+

docs/guide/email.md

@@ -0,0 +1,10 @@
+---
+title: Email
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+This has been completed for console logger and abstract, just need to write docs

docs/guide/logging.md

@@ -0,0 +1,10 @@
+---
+title: Logging
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+This has been completed for console logger and abstract, just need to write docs

docs/guide/middleware.md

@@ -0,0 +1,8 @@
+---
+title: Middleware
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---

docs/guide/migrations.md

@@ -0,0 +1,8 @@
+---
+title: Migrations
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: https://github.com/ubiquits/ubiquits/issues/25
+---

docs/guide/models.md

@@ -0,0 +1,9 @@
+---
+title: Models
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+

docs/guide/queues.md

@@ -0,0 +1,10 @@
+---
+title: Queues
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+This has been completed for console logger and abstract, just need to write docs

docs/guide/routing.md

@@ -0,0 +1,11 @@
+---
+title: Routing
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+
+This has been largely completed, the documentation just needs writing

docs/guide/seeding.md

@@ -0,0 +1,9 @@
+---
+title: Seeding
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+

docs/guide/services.md

@@ -0,0 +1,10 @@
+---
+title: Services
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+This has been largely completed, the documentation just needs writing

docs/guide/testing.md

@@ -0,0 +1,10 @@
+---
+title: Testing
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+Testing infrastructure has been implemented, just need to document how to use it

docs/guide/validation.md

@@ -0,0 +1,10 @@
+---
+title: Validation
+date: 2016-06-09
+collection: guide
+collectionSort: 1
+layout: guide.hbs
+pendingTask: true
+---
+
+Testing infrastructure has been implemented, just need to document how to use it

docs/news/why-bother.md

@@ -0,0 +1,67 @@
+---
+title: Why bother?
+date: 2016-06-09
+author: Zak Henry (https://twitter.com/zak)
+collection: news 
+layout: post.hbs
+----------------
+
+I've decided to undertake the task of building yet another JavaScript framework. 
+There are [many out there](http://nodeframework.com/) so to build a new one is quite a risk.
+
+### My primary reason is **timing**. 
+
+The JavaScript world has rapidly matured in the last 6 months with Angular 2 [right on the horizon](https://github.com/angular/angular/blob/b60eecfc4714e57a4566b38332e36d65cb544b39/CHANGELOG.md), 
+ TypeScript [nearing version 2](https://channel9.msdn.com/Events/Build/2016/B881) and ES2015 being supported by both [Node and major browsers](https://kangax.github.io/compat-table/es6/).
+
+Angular 2 is a revolution in design patterns, with it's no nonsense dependency injection the composability and testability 
+ of modules. There is no reason to keep that goodness to the browser, so I've decided to implement it in the backend.
+
+I'm not leaving Angular behind though - by directly using Angular for it's core dependency injection framework, this allows
+ for a pattern of having Angular components and backend services able to share the same injectable dependencies.
+
+I find myself effectively racing to get a first beta version out at around the same time Angular will release v2, so that I
+ can effectively attract developers that are falling in love with the dependency injection pattern, and can transfer that
+ knowledge directly to Ubiquits.
+
+### I want a node framework like I was used to with PHP.
+
+Until recently I've been writing most of my JavaScript for the frontend. I used to work with an Angular/Laravel PHP stack
+ and my background is with PHP frameworks. Coming into the Node.js world, I found that there was no mature frameworks like
+ [Symfony](https://symfony.com/)/[Laravel](https://laravel.com/)/[ZF2](http://framework.zend.com/) as can be found in
+ the PHP world. I'm seeking to fix that.
+
+The biggest framework in the Node world would have to be [Meteor](https://www.meteor.com) and I would consider Meteor to
+ be a major competitor to Ubiquits. Meteor suffers from a few issues that are symptomatic of their long history, and the
+ obvious need to avoid breaking changes. With Ubiquits, I have the advantage of being able to start from scratch with TypeScript
+ and therefore utilise all of the design-time features TypeScript offers like 
+ [decorators](https://www.typescriptlang.org/docs/handbook/decorators.html), 
+ [metadata reflection](http://rbuckton.github.io/ReflectDecorators/typescript.html) etc. 
+
+Additionally, there are some fundamental differences between Ubiquits and Meteor.
+
+Meteor uses Remote Procedure Call ([`methods`](http://guide.meteor.com/methods.html) in their nomenclature). While this may be a suitable choice for the
+ specific implementation of Meteor, it encourages coupling between the frontend and backend. With a Ubiquits application,
+ the API is completely decoupled from the frontend via the REST interface, which means a Ubiquits application can easily
+ support other clients like native mobile, desktop etc.
+
+The choice between [NoSQL](https://en.wikipedia.org/wiki/NoSQL) or [relational databases](https://en.wikipedia.org/wiki/Relational_database)
+ is always a contentious one, but in reality it comes down to the nature of the application. In my experience, I've had 
+ more need for relational databases, so I intend to design relational first, possibly supporting NoSQL variants
+ later if there is demand.
+
+### I think JavaScript transpiled from TypeScript is the way forward
+The benefit of using the same language for both frontend and backend cannot be understated. There is no getting away
+from the need to write JavaScript on the frontend, and with Node.js being a fully capable (and high performance) platform
+it becomes an obvious avenue to at least investigate using a single language.
+
+I have been working with TypeScript for 12 months now, and despite the initial learning curve I am in love with it, and
+ think it is the way forward for the web. Despite coming from a loose typing background (JS & PHP), I find that the more
+I write with the typing system in TypeScript the more bugs that I fix before running any code. 
+[ES2015](https://babeljs.io/docs/learn-es2015/) is great, but in comparison to TypeScript, it just feels halfway there.
+Unfortunately, I foresee that the choice to use TypeScript over JavaScript will raise the barrier of entry significantly,
+ but as I am targeting Angular 2 developer initially, it is an easier transition for those developers to be able to write
+ the same style code for the whole stack.
+<br><br><br>
+So, in summary, I feel that I have found the current offerings lacking, and with Angular 2 coming shortly I intend to
+ leverage that momentum to get an enterprise scale node framework into the world.

docs/templates/home.hbs

@@ -42,7 +42,7 @@
                         <h2 class="center grey-text"><i class="material-icons">assignment</i></h2>
                         <h5 class="center">Self Documenting</h5>
 
-                        <p class="light">By leveraging <a href="http://typedoc.io">Typedoc</a>, <a href="https://github.com/danielgtaylor/aglio">Aglio</a> and <a href="http://metalsmith.io">Metalsmith</a>, generating documentation for consumers of your component is a breeze.</p>
+                        <p class="light">By leveraging <a href="http://typedoc.io">Typedoc</a> and <a href="http://metalsmith.io">Metalsmith</a>, generating documentation for consumers of your component is a breeze.</p>
                     </div>
                 </div>
 

package.json

@@ -49,9 +49,9 @@
     "zone.js": "^0.6.12"
   },
   "devDependencies": {
-    "@ubiquits/toolchain": "^0.1.4"
+    "@ubiquits/toolchain": "^0.1.7"
   },
   "directories": {
     "doc": "docs"
   }
-}
+}