Initial state after `rails new -d postgresql -T .`

It's a good habit to commit auto-generated code seperate from human
written code.

In the event generated code causes a failure, being able to
deterministicaly verify it was the generated code is indispensible.

By committing the immediate output you can more easily
triangulate if the upgraded library or generated code is causing the
error, or if *your* code is causing an error.
Remove coffeescript

I'm more a fan of plain old javascript. I find the syntax between
coffeescript and ruby too close. I tend to conflate what I'm working in,
which increases cost of a context switch.
Commit bundle after removing coffee-rails
Pre-emptively remove turbolinks

Turbolinks keeps your applications front end (javascripts and css)
loaded over multiple page loads. Creating a slightly "faster" page
load. This is generally A-OK; but it means your javascript state may
persist longer than you expect.

On a greenfield project it's probably fine to keep it in; but since it's
primarily for "performance" and can introduce unsettling defects I tend
to remove it.
Result of bundle after removing turbolinks
Remove extra README
Remove commented out gemfile lines
I prefer ActiveRecord::Serializer over jbuilder

Admittedly, we won't *need* either of these until we start building an
API...
Bundle, Post remove of jbuilder
Add rspec-rails to gemfile
Results of bundle and `rails generate rspec:install`
Add Capybara to project

Capybara is a tool for testing your application through it's web
user interface. You can use it to `visit` pages, `fill_in` form fields,
and `click` links and buttons.
Results of bundle install with capybara
Add schema from `rake db:create db:migrate`
Add failing check for user account registration

A feature test interacts with the application to provide a "sanity
check" as a feature is built. Writing them helps us "get in our users head"
before we start writing any of the code to make it work. As developers,
we frequently prioritize the the code over the user. Feature tests are a
relatively small way to spend more time thinking about the user.

While the final HTML and messages may not have these values; we have an
idea of what the form will look like.

As we look at this test; we see it's three distinct parts:

1. Set-up
2. Actions
3. Expectations

We "set up" by visiting the home page and clicking the "create user"
link.

We take Action by filling in the fields of the create user form and
clicking the create user button.

We confirm our Expectations by checking:
* The page content for a "you did it!" message
* The database for a Users existance
* The resulting web address to see we've arrived at our expected
  destination.
Create homepage route, controller, and view

This gets us past the first line in our test: `visit root_path`

I let the test failures guide me:

1. Created a route in `config/routes` to point to
   WelcomeController#index
   controller. Running the test told me the controller doesn't exist.
2. Created the controller. Running the tests told me the `index` method
   didn't exist
3. Added the `index` method. The tests told me that there wasn't a view
   `views/welcome/index.html.erb`
4. Added the views/welcome/index.html.erb. The tests told me that
   turbolinks wasn't available.
5. Removed the `require turbolinks` from application.js. Now the tests
   tell me that the `create_account` link doesn't exist!

Perfect! Since we've moved forward a line in the test, it's a perfect
time to commit!
Add devise dependency.

Devise handles user authentication and account creation; so before we
start implementing that functionality we're going to add devise to our
gemfile and run the installer.
Check in generated devise code

This is the result of:

```
bundle install
rails generate devise:install
rails generate devise user
rake db:migrate
```
Add link to new user registration form

You may notice that I had to change the `click_link_or_button` from
"#create_account" to "create_account"

I had assumed that click_link_or_button took a CSS selector as it's
locator. Turns out it takes a plain ID attribute.
Bring account creation test in line with devise defaults

Since I didn't remember what Devise does by default, I had to change my
test to match the form that it presents.

To get these I used my browsers debugger tools to find the `id`
attribute on each of the form fields.

While you *can* use the content of the label (I.e "Email"); this makes
your tests brittle. A designer or wordsmith may want to change the
content; if so, it's better not to have to change your tests. When you
introduce internationalization; you'll wind up needing to change quite a
few tests as well.

You'll notice I had to use the content for the "Sign up" button. This is
because devise doesn't provide an id for the form submit button! Ah
well.