Refactor: move app-related code into public/
Refactor: Rename javascript files for clarity
Refactor: Introduce MVC pattern

At this point, we have separated out the behaviour into the three
MVC responsibilities. We've introduced the concept of functions,
and the battleship.js file can be loaded from any page.
Add model spec (shootAt())

We've renamed the file acceptance-tests.js to tests.js to reflect
the fact that it contains both high level tests for the overall behaviour
of the app, and lower level unit tests.
Enhancement: Hitting and missing ships

Here we add the acceptance test for the new behaviour.

Notice we're changing the wording in the test to use more domain
specific language, talking about shooting, hitting and missing
instead of clicking. This reflects our growing understanding of the domain.
Enhancement: Hitting and missing ships

Adding a unit test for missing a ship. This spec could be refactored,
but we'll tolerate the duplication for now.
Enhancement: Hitting and missing ships

Adding the implementation to make the tests pass.
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