[7.1.1] Added debug information to site layout

The profiles in this section will be the first truly dynamic pages in
our application. Although the view will exist as a single page of code,
each profile will be customized using information retrieved from the
site's database. As preparation for adding dynamic pages to our sample
application, now is a good time to add some debug information to our
site layout

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:rails_environments
[7.1.2] Set up REST-style routing for users

We can get the REST-style URI to work by adding a single line to our
routes file.  You might have noticed that Listing 7.3 removes the line

    get "users/new"

last seen in Listing 5.32. This is because resources :users doesn't just
add a working /users/1 URI; it endows our sample application with all
the actions needed for a RESTful Users resource, along with a large
number of named routes for generating user URIs.  Over the course of the
next three chapters, we'll cover all of the other entries as we fill in
all the actions necessary to make Users a fully RESTful resource.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:a_users_resource
[7.1.2] Add minimalist profile page

We'll use the standard Rails location for showing a user, which is
app/views/users/show.html.erb. This view uses Embedded Ruby to display
the user's name and email address, assuming the existence of an instance
variable called @user.

In order to get the user show view to work, we need to define an @user
variable in the corresponding show action in the Users controller. As
you might expect, we use the find method on the User model to retrieve
the user from the database

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:a_users_resource
[7.1.3] Add factorygirl gem

In order to make the necessary User model object, we could use Active
Record to create a user with User.create, but experience shows that user
factories are a more convenient way to define user objects and insert
them in the database. We'll be using the factories generated by Factory
Girl, a Ruby gem produced by the good people at thoughtbot. As with
RSpec, Factory Girl defines a domain-specific language in Ruby, in this
case specialized for defining Active Record objects. The syntax is
simple, relying on Ruby blocks and custom methods to define the
attributes of the desired object. For cases such as the one in this
chapter, the advantage over Active Record may not be obvious, but we'll
use more advanced features of factories in future chapters. For example,
in Section 9.3.3 it will be important to create a sequence of users with
unique email addresses, and factories make it easy to do this.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:tests_with_factories
[7.1.3] Add tests for user show page and make them pass

We'll put all our Factory Girl factories in the file spec/factories.rb,
which automatically gets loaded by RSpec. By passing the symbol :user to
the factory command, we tell Factory Girl that the subsequent definition
is for a User model object.

With this definition, we can create a User factory in the tests using
the let command and the FactoryGirl method supplied by Factory Girl.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:tests_with_factories
[7.1.3] Set bcrypt cost factor low during tests

One thing you will quickly notice when running tests with Factory Girl
is that they are slow. The reason is not Factory Girl's fault, and in
fact it is a feature, not a bug. The issue is that the BCrypt algorithm
used in Section 6.3.1 to create a secure password hash is slow by
design: BCrypt's slow speed is part of what makes it so hard to attack.
Unfortunately, this means that creating users can bog down the test
suite; happily, there is an easy fix. BCrypt uses a cost factor to
control how computationally costly it is to create the secure hash. The
default value is designed for security, not for speed, which is perfect
for production applications, but in tests our needs are reversed: we
want fast tests, and don’t care at all about the security of the test
users' password hashes. The solution is to add a few lines to the test
configuration file, config/environments/test.rb, redefining the cost
factor from its secure default value to its fast minimum value. Even for
a small test suite, the gains in speed from this step can be
considerable.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:tests_with_factories
[7.1.4] Add support for gravatar profile images

We'll start by adding a "globally recognized avatar", or Gravatar, to
the user profile. Originally created by Tom Preston-Werner (cofounder of
GitHub) and later acquired by Automattic (the makers of WordPress),
Gravatar is a free service that allows users to upload images and
associate them with email addresses they control. Gravatars are a
convenient way to include user profile images without going through the
trouble of managing image upload, cropping, and storage; all we need to
do is construct the proper Gravatar image URI using the user's email
address and the corresponding Gravatar image will automatically appear.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:a_gravatar_image
[7.1.4] Add sidebar to User show page

The last element needed to complete the mockup is the initial version of
the user sidebar. We'll implement it using the aside tag, which is used
for content (such as sidebars) that complements the rest of the page but
can also stand alone. We include row and span4 classes, which are both
part of Bootstrap.

With the HTML elements and CSS classes in place, we can style the
profile page (including the sidebar and the Gravatar). Note the nesting
of the table CSS rules, which works only because of the Sass engine used
by the asset pipeline.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:a_gravatar_image
[7.2.1] Spec out signup form

Our first task is to test for a failing signup form, and we can simulate
the submission of invalid data by visiting the page and clicking the
button using click_button. This is equivalent to visiting the signup
page and submitting blank signup information (which is invalid).
Similarly, to simulate the submission of valid data, we fill in valid
information using fill_in.

The purpose of our tests is to verify that clicking the signup button
results in the correct behavior, creating a new user when the
information is valid and not creating a user when it's invalid. The way
to do this is to check the count of users, and under the hood our tests
will use the count method available on every Active Record class,
including User.

When submitting invalid data, we expect the user count not to change;
when submitting valid data, we expect it to change by 1. We can express
this in RSpec by combining the expect method with either the to method
or the not_to method.

Combining the two cases with the appropriate describe blocks and pulling
the common code into before blocks yields good basic tests for signing
up users.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_form
[7.2.2] Add User signup form

Now that we have good failing tests for user signup, we'll start getting
them to pass by making a form for signing up users. We can accomplish
this in Rails with the form_for helper method, which takes in an Active
Record object and constructs a form using the object's attributes.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:using_form_for
[7.3.1] Add create action to the Users Controller

We can get the test for invalid information to pass with this code. This
listing includes a second use of the render method, which we first saw
in the context of partials (Section 5.1.3); as you can see, render works
in controller actions as well.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:a_working_form
[7.3.2] Add error messages to signup form

Though not strictly necessary, it's helpful to output error messages on
failed signup to indicate the problems that prevented successful user
registration. Rails provides just such messages based on the User model
validations.

Notice here that we render a partial called 'shared/error_messages';
this reflects the common Rails convention of using a dedicated shared/
directory for partials expected to be used in views across multiple
controllers.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_error_messages
[7.4.1] Redirect to user profile on success

The default behavior for a Rails action is to render the corresponding
view, but there is not (nor should there be) a view template
corresponding to the create action. Instead, we need to redirect to a
different page, and it makes sense for that page to be the newly created
user's profile

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:the_finished_signup_form
[7.4.2] Add a flash message on signup

Before submitting a valid registration in a browser, we're going to add
a bit of polish common in web applications: a message that appears on
the subsequent page (in this case, welcoming our new user to the
application) and then disappears upon visiting a second page or on page
reload. The Rails way to accomplish this is to use a special variable
called the flash, which operates like flash memory in that it stores its
data temporarily.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:the_flash
[7.4.4] Set production to use SSL

Having developed the User model and the signup functionality, now is a
good time to deploy the sample application to production. As part of
this, we will add Secure Sockets Layer (SSL) to the production
application, thereby making signup secure.  Since we'll implement SSL
site-wide, the sample application will also be secure during user signin
and will also be immune to the session hijacking vulnerability.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:deploying_to_production_with_ssl
[7.6.1] Add size option to gravatar_for helper

Verify that the code in Listing 7.29 allows the gravatar_for helper
defined in Section 7.1.4 to take an optional size parameter, allowing
code like gravatar_for user, size: 40 in the view.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_exercises
[7.6.2] Add tests for signup error messages

Write tests for the error messages implemented in Listing 7.22.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_exercises
[7.6.3] Fix "password digest" error

Replace the error message for a missing password, currently "Password
digest can't be blank", with the more understandable "Password can't be
blank". (This uses Rails' internationalization support to produce a
functional but rather hacky solution. Take special care to use spaces
and not tab characters; the YAML format forbids tabs.) Note that, to
avoid duplication of error messages, you should also remove the
password's presence: true validation in the User model.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_exercises
[7.6.4] Test User create page redirects properly

By writing the test first or by intentionally breaking and then fixing
the application code, verify that the tests in Listing 7.32 correctly
specify the desired behavior after saving the user in the create action.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_exercises
[7.6.5] Tidy up flash rendering code

As noted before, the flash HTML in Listing 7.26 is ugly. Verify by
running the test suite that the cleaner code in Listing 7.33, which uses
the Rails content_tag helper, also works.

[Source] http://ruby.railstutorial.org/chapters/sign-up#sec:signup_exercises