Write test for image upload

Here we've extracted a test helper to hold the login_as function so we
can use it across multiple feature tests.
User may upload file

This implementation relies on local file systems, which won't work when
we push to Heroku.

A future commit will make this work when uploading to AWS.

Of important note is the use of "strong parameters" here. This is the
`safe_picture_params` method in the PicturesController. This ensures
that only fields we want users to change may be changed.
Pictures are owned by a user

As you can see, my tests didn't include anything about the user! In
fact, it looks like my login wasn't even working!

Once I added in the requirement that a picture has an owner, everything
fell apart! Oops! I'd forgotten I wanted `login_as` to take a user hash,
not a user object. This is the problem with copy-pasta! There's a pretty
fancy way to get around this in rspec; but it's more about being clever
than anything else so I won't do it. (Hint: It involves defining your
own describe-type!)

The *actually* cool bits here are:

1. Using the association to create the picture
   (`current_user.pictures.create`). This is easy to overlook; and is
   one of the things I really appreciate about ActiveRecord.
2. Getting all the semantic goodness of a Picture belonging to an Owner.
   (Even though the class is `User`). Another thing I appreciate about
   ActiveRecord. Being able to preserve the semantic meaning without
   creating weird intermediary classes. You should see this in both the
   User and Picture model
Add flash notification that their picture uploaded

Providing feedback is always a good thing
Guest users cannot upload images

Here we're leveraging devise's built in "authenticate_user!" helper to
force someone to log in before they can even send GET or POST reuests to
the new picture route.
Require a picture and caption on upload

Now we get to handling invalid uplods!

Again, you'll notice that I managed to mess up something that writing a
test caught. I had params.require(:picture).permit(:name, ...) instead
of params.require(:picture).permit(:caption, ...)

Writing these negative tests really helps.

In the controller, we now have a check that ensures the picture is
persisted before it redirects. otherwise we re-render the new picture
form.

We've also started adding some error handlers under neath of the form
field. I'll extract those soon.

e Please enter the commit message for your changes. Lines starting
Extract shared error renderer

Some people would put this in a helper. I, personally, prefer to keep as
much of my HTML as possible in partials as that means they're super easy
for a designer to work with. Yes it's a *touch* more verbose; but
keeping the html in the HTML is "worth it" in my opinion
Enable S3 Uploads

Uploading our images to S3 is the only way we can make things work on
Heroku.

This means you'll now need to have an AWS account and an S3 bucket to
upload images in development. We're using `dotenv-rails` to make loading
the ENV variables super easy.

Everything else is setting up your initializer to have the correct buckt
name and access credentials to upload your files. In the test
environment we want to just upload files locally; as uploading to S3 is
quite slow.
Merge pull request #2 from codeunion/user-may-upload-image

User may upload image
Add link to second pull request
User may see their pictures

This commit introduces the concept of nested resources. Nested resources
are a nice way to denote ownership. By default, nested resources just
use the top level controller. Because I expect the pictures index to
wind up showing all the public pictures, I decided to make a
controller explicitely for the users pictures.

You *could* put the new/create methods in the users pictures controller
as well, and it wouldn't hurt anything. Since pictures aren't likely to
be created for anyone *except* the currently logged in user, I see it as
reasonable to leave it within the pictures controller.

We also get to see the new html5 `figure` and `figcaption` tags!
Redirect to users pictures when picture is created

Instead of redirecting to the home page, let's redirect to the users pictures
page! Such UX, Very Workflow. Much design
Extract have_picture matcher

To much duplicate code!  Custom matchers are useful when you want to
make an assertion about your applications logic.
Merge pull request #3 from codeunion/user-may-see-all-their-pictures

User may see all their pictures
Add link to the list of pictures PR
Picture uses a uuid for its id

UUIDs are nearly globally unique strings. By using them for the id for
our pictures, it makes it almost impossible for a malicious user to
guess the URL used to view a picture.

This lays the groundwork for allowing a guest to view a picture shared
with them by the pictures owner
Guest may view a picture

By making the picture show a nested resource, we ensure a user must have
access to both the users id and the pictures id before they can access
a picture.

Sure, this makes the URL pretty long, but it also protects our users a
bit from accidenal image discovery.
Make it more obvious how to share a picture

Doin' some Interaction Design here. Makin' things findable.

Yep.
Merge pull request #4 from codeunion/guest-may-view-users-image

Guest may view users image
Add link for the last two features of release 1.0.0