GREEN - A cell at 0,0 with two neighbors survives

This is what's known as "fakin' it til we make it." Since a goal of
TDD is to stay red for as short a time as possible, it's totally OK
to "cheat" to get from red to green.

This allows our implementation/design to emerge as we add use cases, as
well as gives us more frequent opportunities to refactor.
REFACTOR - assert_equal takes expected as first argument

I always mess this up.
REFACTOR - Extract helper to set up and run the game of life

Since we had a bit of duplication in both tests, I figured I'd extract a
helper to make the ARRANGE/ACT steps a bit easier to write.
RED - A con at 0,0 with no neighbors dies

Expected Result of running `ruby test/all.rb`
=============================================
>  1) Failure:
>  TestGameOfLife#test_a_con_at_0_0_with_no_neighbors_dies_after_a_single_iteration
>  [test/all.rb:46]:
>  The Con at 0,0 survived!
>
>  3 runs, 3 assertions, 1 failures, 0 errors, 0 skips

We're settling into a pattern of defining a situation of what will
happen to this poor little con at 0, 0. I chose to write this test for a
few reasons:

1. I thought it would fail (And it does!)
2. Using the same con with different neighbor counts lets us avoid
   worrying about writing code to handle different locations in the
   world (for now)

Syntax Breakdown
================

`refute` - The opposite of assert. Causes tests to fail if the first
argument is true.
GREEN - Con at 0,0 with no neighbors dies.

Expected Result of running `ruby test/all.rb`
=============================================
>
>  # Running:
>
>  ...
>
>  Finished in 0.001306s, 2297.0904 runs/s, 2297.0904 assertions/s.
>
>  3 runs, 3 assertions, 0 failures, 0 errors, 0 skips

Again, our goal is to quickly move from red to green. Here we're
checking against the number of cons in the world, and *if* there are
exactly three we return the original world. If there aren't, we return a
cold and lifeless world; devoid of cons.

Syntax Breakdown
================

`<condition> ? <true value> : <false value>` - This is known as a
"ternary operation", and is short-hand for an if/else block. One should
only use ternaries to return a specific value not for larger control
flow operations. Ternaries quickly become difficult to follow when they
get more complex.
REFACTOR - Move the world-changing into `run!`

This more clearly reveals our intent, which is to do the work for birth
and death into the `run!` method.
REFACTOR - Extract constant for number of neighbors

Extracting a constant is a very common way to provide meaning to a
number or string. While we may (for now) know what `3` means because we've
explored the problem domain, we may forget or have to bring on someone
less familiar. Giving a name to `3` let's us  not worry about
forgetting.

I call this "Tom Bombadilling." Giving something a name so we have power
over it.
REFACTOR - Extract `survives?` method.

Here we're extracting a method to reveal the intent of a small bit of
boolean logic. I also wrapped the ternary in `()`'s to make it more
clear how the line evaluates.
RED - Con at 0,0 with three neighbors survives

Expected Result of running `ruby test/all.rb`
=============================================
>  1) Failure:
>  TestGameOfLife#test_a_con_at_0_0_with_three_neighbors_survives_a_single_iteration
>  [test/all.rb:62]:
>  The Con at 0,0 didn't survive!
>
>  4 runs, 4 assertions, 1 failures, 0 errors, 0 skips

Pretty normal test. Nothing to fancy here.
GREEN - Con at 0,0 with three neighbors survives

Expected Result of Running `ruby test/all.rb`
=============================================
>   4 runs, 4 assertions, 0 failures, 0 errors, 0 skips
REFACTOR - Extract neighbor_count method

I extracted a new constant and renamed the old one because we really
only care about survival right now, not ressurection.
RED - Con at 0,0 with 0 neighbors and 2 non-neighbors dies after 1 iteration

Expected Result of running `ruby test/all.rb`
=============================================
>  1) Failure:
>  TestGameOfLife#test_a_con_at_0_0_with_no_neighbors_but_two_non_neighbors_dies_after_a_single_iteration
>  [test/all.rb:77]:
>  The Con at 0,0 did survived!
>
>  5 runs, 5 assertions, 1 failures, 0 errors, 0 skips

Now we begin to worry about actual neighbors vs. non-neighbors. Woo!
GREEN - Con at 0,0 with 0 neighbors and 2 non-neighbors dies after 1 iteration

Here we're using `select` to build a new collection of cons out of the
existing collection of cons. Select loops over every single item, passes
them to the block, and if the block returns true adds them to a new
collection. If you were to use a `for` loop it would look like this:

```ruby
collection = [1,2,3]
new_collection = []

for number in collection
  if number % 2 == 0 # % is the "modulus" or "divisible by" operator.
    new_collection.push(number)
  end
end

puts new_collection # => [1,3]
```

Ruby prefers to use [enumerable
methods](http://ruby-doc.org/core-2.1.5/Enumerable.html) when working
with collections instead of for loops. Enumerable methods are generally
called on a collection and given a block. The enumerable method
passes each of the items in the collection into the block, and depending
on the enumerable method, does something with it.

Here's how we could write our own `select` method:

```
def custom_select(collection, &predicate)
  selections = []
  for item in collection
    if yield(item)
      selections.push(item)
    end
  end
  selections
end

odds = custom_select([1,2,3]) do |number|
  number % 2 == 0
end

puts odds # => [1,3]
```

Syntax Breakdown
================

`select` - An array method that lets us create a new array from an
original arrays members that match a block.

`do ... end` - denotes a "block" of instructions. Frequently used to
pass code to existing methods.
REFACTOR - Rename `number_of_neighbors` to `neighbors`

Neighbors now returns a collection of the cells around a given cell.
Hooray!

This means we don't need that - 1 in our code anymore!
REFACTOR - Introduce Con class

One of the ideas we haven't represented yet is a Con. We've been
representing them as a coordinate Hash, which has been OK, but now that
we're seeing more and more logic around a Cons life cycle, it seems
reasonable to introduce a class.
REFACTOR - Introduce con comparison method

Now we get to something juicy! We can define a custom `==` method on our
new Con class so we can compare cons to each other! Noice!
REFACTOR - Initialize all the cons when the world is created

Initializing objects can be a "heavy" operation, so we're doing it at the
beginning.

In our GameOfLife initialize we're using ruby's `map` method to convert an array of Hashes to an
Array of Cons. Fancy, eh?

In our `world` method, we're using `map` to convert an array of Cons to
an array of Hashes. This prevents us from needing to change any of our
tests.

We want to keep our tests focused *solely on the behavior*, not on the
structure of the underlying code. You know this is true when you can
introduce classes or rename methods without your tests breaking.

Syntax Breakdown
================

`&:location` - Tells an enumerable method to call a method named
:location on item(s) instead of a passed in `do ... end` block.
RED - Con at 3,4 with two neighbors survives

Now we have to start really making the location code work! Let's check
if cons at other places live or die!
GREEN - Cell at 3,4 with two neighbors survives

This implementation highlights a responsibility violation.

Both `survives?` and `neighbor` are exhibity signs of "feature envy"
(taking an argument and calling more methods on a collaborator than on
self) This makes me think they belong on `Con` instead of `GameOfLife`
REFACTOR - Move `survives?` onto Con.

Individual cons can now determine whether or not they survive. Part of
me is unhappy that `Con`s are responsible for deciding whether they live
or die, as it seems like something that should be outside of their
responsibility. Another part of me is happy that it's no longer the
`GameOfLife` class making these decisions.

We'll see where it goes from here.