Add RSpec testing framework (via rspec-rails)

We're about to add a controller for the first time, and we might want
to unit test it, so now is a good time to bring in RSpec.
Implement new_order_log_url to make step pass

We're being very granular in our progress here; this commit simply
renders a blank template at the target URL, but that's all we need
so far to make the current blocking step pass.
Add (failing) step def for attaching file to form

This next step will necessitate a form.  I made an assumption as to
the generated form element name, based on the fact that I intend this
to be a form for a new "OrderLog" instance.  Note that we've also now
added the fixture file for the first time.
Add order_logs and new form with file field

We finally create our first model - the order log.  For now, it just
has a column for the source data (we'll copy the entire file into the
database) and the gross revenue; this is the only data that we'll need
in order to satisfy the current scenario that's in @wip.

The file upload doesn't do anything yet - this just satisfies the
failing step in the scenario of attaching a file to the form and
submitting it.  The create action currently just redirects to the new
action, to avoid missing template exceptions (since we'll never
actually have a 'order_logs/create' template).
OrderLog creation, flesh out UI with Bootstrap

Order logs are now actually created from the incoming file, and we've
added a series of tests for validation.  We're doing some rough
validation on the file itself - it basically has to include at least
one tab, and be parseable by CSV.parse.

I've pulled in Twitter Bootstrap, including the files directly. No
need for a gem, or LESS support since we're keeping a very basic UI.
For form rendering, I'm adding simple_form, generated with Bootstrap
support, to easily get clean forms with hints, error reporting, etc.
Add order log index, and filename display

Though the impetus was for testability, recording the filename of the
uploaded file when creating an order log can be useful to the user,
since the name of the file can be displayed on the index page for
quick reference on what has already been uploaded.
Document a few classes & methods

Normally I use YARD, but for the sake of simplicity, I'm leaving out
any YARD directives so `rake doc:app` can be run to produce RDoc
pages.
Calculate & display gross revenue from order logs

This satisfies the last step of our first scenario.  We're calculating
the gross revenue by parsing the file and directly aggregating the
order costs for each line; no normalization of data has occurred yet.

There are no user-facing specs that require (or benefit from)
normalization, so in order to fulfill that requirement, we'll need
backend acceptance tests, or we'll need to build a user interface
for interacting with that data, and use more full-stack integration
tests (which are typically my preference).
Implement invalid file upload spec

This required no code changes, since we'd already taken care of file
validation and tested it through RSpec feature specs.  Only step
definition modifications/additions were needed.
Delete unneeded controller spec

This test case is a good example of a development-focused unit
test that doesn't serve much of a purpose in regression testing, and
in fact may become an obstacle in future refactoring.  It's redundant
now with the full stack tests.
Add users, authentication, and authorization

This is a big commit.  All scenarios in "user/uploads_file.feature"
are now passing.  We now have a concept of users who can provide 
authentication credentials to gain access to the system, but who
also need to be explicitly authorized to do anything but arrive at
our Limbo page.
User account creation; pending auth notification

Users can create accounts, but any new account is unauthorized by
default.  If an admin user exists, a notification of the new pending
authorization will be sent to the admin.
Final Gherkins (admin auth approval) passing

All written specifications are now passing; the next step is to write
some tests around the normalization of the incoming data.
Add Cuke for viewing orders from an uploaded log

While this wasn't explicitly part of the initial spec, it gives us a
way to validate the data extraction feature request by exposing the
result to the end user.  Plus, it seems like a no-brainer, if we're
actually going to extract the orders from the log anyway.
First step definitions for order viewing feature

This is enough to get the second scenario running (the negative case),
and get us started on the first.  We're blocked now by not actually
having the concept of an "order" yet, so we'll start building that
structure up.
Introduce order tables, write many tests

We're just going ahead and creating the four models we're likely to
need - Deal, Merchant, Customer, Order.  We've also written a variety
of tests, which document our planned API around these models.
Replace custom composer with money_column gem

No reason to re-invent the wheel on this one; there were several
additional features we wanted that money_column gives us without
continuing to hack our own solution.  Our wheel had served its
purpose, but as soon as someone asked for it to be round and
dynamic, we figured someone had already invented that.
Get all specs running for order log extraction

All of the customer/merchant/deal/order unit tests are passing; now
it's just the integration test (the Gherkin feature) that remains.
Display all orders from an order log

This satisfies the last Cucumber scenario, and all the requirements
have now been met.  There are some non-functional requirements to
take care of, still - such as populating the i18n files and adding
in-line documentation.
Basic email validation for users

Not going to try anything too fancy here, just rough validation.
Obviously we could use a solution that takes advantage of the Mail
gem's parser, but that's a bit overpowered for this app.