Enhancement: Make application Node.js/NPM-aware

We've added a NPM manifest file to declare our application properties.
This - among other things - will allow us to define package
dependencies for both the testing code and the application itself.

Most popular browser-based JavaScript libraries have their counterpart
in NPM (e.g. jasmine, jquery, etc.).
Enhancement: Open test page from the command line

We've introduced a little Node.js script that automates the task of
opening a (default) web browser and loading the test page of our
application.

What we learned:

* How to require and use Node modules
* Spawn child processes with Node
Enhancement: Serve application and tests through HTTP

We added a simple Node.js-based HTTP server to expose the application
and its tests more easily. This is the first step towards having our
tests being run on the CLI.

What we learned:

* How to install Node modules through NPM
* How to write a simple web server in Node
* Events (emitter)
* Callbacks which are everywhere in Node.js
Enhancement: Run unit tests on the CLI

In order to improve the way we get feedback from our TDD setup, we
moved the unit tests to a dedicated spec/ folder to be executed by
Jasmine from within a Node.js process. This allows us to not rely
anymore on a web browser for our unit tests, effectively making our
TDD cycle faster.

We use jasmine-node, a Node.js wrapper for Jasmine that gives us a few
helpful features like autotest (`jasmine-node --autotest .`).

What we learned:

* jasmine-node, a Jasmine package and wrapper for Node.js
* How to export functions and variables in a Node.js module
* How to organise specs for Jasmine
* NPM "dev dependencies"
Refactor: Encapsulate model into a constructor with a prototype

Previously, we had to require different components of our model within
its spec. It felt a bit clumsy and could potentially have grown into a
long list of requires. This was a smell that led us to encapsulate the
model in a nicely self-contained instantiatable constructor.

What we learned:

* Constructors in JavaScript
* Prototypes
* Instantiate objects in JavaScript
* The special `this` variable
Refactor: DRY model spec code

The model spec contained some repetition: some spies were created
repeatedly. We removed that repetition by using the beforeEach
so-called "hook" function provided by Jasmine.

More importantly, we completely decoupled examples from each other by
forcing new blank instances of our model to be created within them.
This suppresses all risks of cascading failing tests.

What we learned:
* Hooks in Jasmine
* "DRY" principle (and how to not abuse it in tests)
* "Independant tests" principle: don't share state between tests
Refactor: Turn view into instantiatable constructor

Similarly to what we did to the model, we turned the view into a self-
contained instantiatable object.
Refactor: Turn controller into instantiatable constructor

The controller is the latest component we had to turn into an object.
The view and model instances are injected into the controller, making
all those objects highly decoupled.

What we learned:
* Injecting dependencies into constructors
* Accessing properties of an object instances from itself
* Injecting doubles to isolate an object during tests
Refactor: Move user action handling to view

The view is now responsible for catching user interactions with the UI
(i.e. clicks on cells). The controller - which is responsible for
orchestrating things between the view and the model - registers a
listener to the view. The listener is executed by the view to notify
the controller the player is shooting at a cell. The controllers then
tells the domain (via our model) to handle that event.

The controller (application layer) is now simply listening to some
events on the user interface (presentation) and delegating it to the
model (domain).

What we learned:
* Presentation, application and domain logic separation
* Registering a simple callback
Refactor: Decouple acceptance tests (work in progress)

Each test *should* be independant. Even acceptance tests. We expect
the system under test to be in a clean blank state when a test is
starting to reduce risks of flickering and to ensure the deterministic
nature of our tests.

In order to reach that situation, we start a new game before every
single end-to-end tests.

What we learned:
* All tests should be independent
* Tests start with a system in a clean (or very well-known) state
Problem: Dual-state cell in the grid during tests

When hitting, the cell is marked as both a hit and a miss. Try to
understand why and fix it if you can!
Solution: Introduce templates

The problem we faced proviously lies within the DOM. Event though new
instances of all our objects (view, model, controller) were properly
created before each example, the DOM table and cells was not changed.

Previously attached event handlers were still being triggered. This
means our previous game, view and controller instances were reacting
to clicks on the cells, as well as the newests. In short, the same
TD elements were being tight to different instances of the game.

To avoid that incorrect behaviour, we've introduced the concept of
templates, which brings other interesting benefits to our application.
They will help organize the HTML into smaller reusable units that are
bound to views.

What we learned:
* How listening to events affect (unreferenced) object instances
* How careful we must be with listeners
* The concept of view templates and how to define/use them
Enhancement: Introduce Linting

We love clean code. To help us write the cleanest and finest
JavaScript, we've introduced Linting with the help of the JSHint
library.

See the [JSHint documentation](http://www.jshint.com/docs/) for
more information.

What we learned:
* Linting
* JSHint, how to configure it
Refactor: Fix code following JSHint's report

JSHint told us to fix a few bits in our code. Check.
Enhancement: Add build configuration

In order to simplify the way the whole application quality can be
measured at any moments and on any systems (e.g. continuous
integration servers), we've created a basic *build configuration* that
can be invoked through NPM with `npm test`.

What we learned:
* Concept of *builds*
* Configure build script in NPM
Update README from commit history

Generated using the following command:

`git log --format="## %s%n%n%b%n[View this commit](https://github.com/mattwynne/js-testing-training/commit/%H)%n" --reverse > README.md`