Create a seeds file, and fix missing link.

After setting up my models, I like to make the seeds file generate a very
simple setup of all of them. This often finds problems with the model that I
didn't realize.

In this case, I _completely_ forgot to add a link between an Artist and a Shop
in the schema. So I added a new migration to take care of that.

I also had to add some extra `has_many`/`belongs_to` methods to various models.
I don't like to automatically just include every single one, but I do often
find that my models all 'flow' from some main one. You can tell this by looking
at the drawing, `Shop` is the big, important model where everything starts
from. Even though I didn't call it `User`, I need to make sure it doesn't turn
into a God Object.

Also of note: it's nice if seeds.rb is idempotent. It ensures that something
exists in your database, rather than adds more stuff to it. This way, you don't
need to do the whole dance:

    $ bin/rake db:drop db:migrate db:seeds

I do this kind of development in an very iterative way. Here, check it out (cleaned up for ease of reading):

    $ history
    <snip>
    61  vim db/seeds.rb
    62  bin/rake db:seed
    64  bin/rails c
    65  vim db/seeds.rb
    66  bin/rake db:drop db:migrate db:seed
    71  bin/rails c
    72  vim app/models/shop.rb
    73  bin/rails c
    74  vim db/schema.rb
    78  bin/rails g migration AddShopIdToArtists shop:references
    80  bin/rake db:migrate
    81  vim db/seeds.rb
    <snip>
    92  bin/rake db:drop db:migrate db:seed
    93  bin/rails c
    94  vim app/models/artist.rb
    95  vim app/models/customer.rb
    96  vim app/models/appointment.rb
    97  bin/rails c
    98  git status

I explore the model in IRB to make sure that things are working like
I expect them to. I'll also check that the seeds.rb is consistent as
I expect:

    irb(main):005:0> c.appointments.first.artist.shop == c.shop
    true

Doing stuff like this is what led me to realize that I missed the column on
Artist.
Add minitest-rails-capybara

I'm gonna be loading this on every test, but for now, we only
have feature tests, so that's okay. Once I end up with some unit
tests, I'll end up moving some setup around.
Fix travis config to run all tests.

Turns out `bin/rake test` doesn't run feature tests. So we'll make
sure that Travis runs all the tests instead.
Add a sign in link on the home page.

We have our first test! We want people to be able to log in
from the home page, so we add a link there.
Make an explict task for features.

Apparently this doesn't come with minitest-rails-capybara by default, even
though `bin/rake test:all` will run the features. *shrug*.
Shops can now sign in.

Lots going on here:

First of all, Shops now `have_secure_password`s. I highly prefer this to
Devise. I had a hard time articulating why, until I heard someone say "You
shouldn't outsource core compentencies. User management is a core competency."
I think this person was Ryan Bates, but I'm not 100% sure.

Anyway, we still use `has_secure_password` over rolling our own password
encryption stuff, because it's better to use crypto that's vetted by others.
Plus, I have patches into `has_secure_password`, so in some ways, I wrote it
anyway :wink:.

It requires bcrypt, so we have to add that to our Gemfile. For more on this
topic, see this blog post by @codahale:
http://codahale.com/how-to-safely-store-a-password/

We also hook up a session controller, but we give it better URLs. REST doesn't
mean 'expose your database over the web,' I don't care what Rails tells you.
:wink: It has a destroy method because I know I'm gonna use it later, so I
generated it. Sue me.

I had to introduce flash messages, and so I added in the bootstrap classes,
becuase I will be using bootstrap. Get mad. When you show bootstrap sites to
people who don't have Hacker News accounts, they don't say "omg just like every
other Bootstrap site," they say, "Hot damn, this looks amazing! You're the
best!"

I am not totally happy with the first line of my test saying `shop`, but it's
such a minor detail that I'm not gonna stress it. Suggestions welcome.

Finally, you may wonder why I don't unit test the new features on the User
model. Frankly, trying to test Rails built-in stuff is a waste of time, because
it's already tested by Rails. If I remove the `has_secure_password` line, tests
will break. That's good enough for me. I'm not likely to touch any of this
code ever again, at least, not for a while, and not very often. I'm happy with
the tradeoff here. YMMV.

If this were a feature that relied less on Rails built-in stuff, I would have
this broken into a bunch of commits, where the test is pending, I'd build it up
step by step, yadda, yadda, yadda. But frankly, if I were @dhh, this (or
something like it) would be in Rails itself, and I've written this code so many
times that I'm surprised I haven't bothered to write a generator for it yet.
Well, without the bootstrap stuff. He doesn't like the idea of it being in
core, though, so what are you gonna do. Mostly, write a commit like this in
every application. *shrug*.
New development log: authentication part one
Test incorrect password when signing in.
Incorrect email leads to sign in failure.

While this just adds a test, I _did_ comment out the implementation for
the previous test, just to watch it fail. It just so happens that either
causes the same failure. It's nice to have a test for both, though.

These tests are probably overkill for something that's not as important
as signing in. I want to make 100% sure this works all the time, though,
so I'll expend the effort to make it overly tested.
Signing in should take you to your dashboard.

I like giving signed in users their own URL, rather than displaying
some kind of dashboard on the root page. It's way easier to do things like
caching when you give distinct pages their own distinct URLs.
Add a sign out link to the home page.
Add a sign out link to the dashboard.

We'll need one here, too.
Signing out actually signs you out.
New feature complete: authentication.

You can sign in and sign out. Awesome.

See #8 for more details.
Typo
Add bootstrap.

I'm using the bootstrap-sass gem since it's now officially part of Bootstrap.
This is generally how you're supposed to use libraries with the asset pipeline:
add a gem which takes care of updating things for you and doing the
integration. I'm not 100% sold on it, exactly, because it relies on people
doing the wrapping rather than importing them directly, but I don't plan on
doing a whole lot of fancy in this app anyway, so it shouldn't be an issue.

The gem instructions don't tell you about adding the file; it took me a bit of
searching to realize that the gem only made the sass files available, rather
than adding bootstrap itself to your project. This makes sense, I guess, if
you want to pick and choose which parts of Bootstrap get used, or to only
use them on part of your sites.
New home page.

Here's a trick that I like in Rails apps: you basically just render the
homepage with `layout: false`, and then shove everything into the single view.

This is an example of where DRY can lead you astray. Yes, I copy and pasted a
bunch of stuff into the view from a layout. Yes, I could, in theory, extract a
common layout and use it for both. No, that would not be worth it. Here's why:

The home page is often just marketing material, and ends up being significantly
different than the rest of the site. Depending on how big your organization is,
it can also end up changing a lot for various reasons, too.

Using the common layout doesn't actually buy you anything, because _the home
page and the rest of your site don't actually have a lot in common_. The
purpose of DRY is to make future change easier. Trying to have this page share
a layout with the rest of the site actually makes future change harder, in my
experience.

Eventually, when I'm ready to launch, this won't be a Bootstrap template, and
will be something real instead.
Bootstrap-ify the layout.

Easy enough. Just the basics.

One thing that's still missing: flash message styling.
Merge pull request #9 from thegcat/patch-1

Typo
Style sign in box