A Code Challenge: Storedom

Code Challenge: Storedom

# Module 4 First Code Challenge

This challenge is intended to help you assess your readiness for the end-of-module assessment and for upcoming technical interview assignments. You'll be given 3 hours, from 9:00 AM to 12:00 PM to complete the 2 challenges described below. At the end of the allotted time, you should push your code to a repo so that you can review it with an instructor later. Along the way, you should be making regular commits that demonstrate your work process.

For both of these challenges, we'll be using the existing Storedom application. Clone and set it up according to the instructions [here](https://github.com/turingschool-examples/storedom).

### Challenge 1: Storedom Order Flow and Order Notification Service

For this challenge we'll be adding a simple order flow to the Storedom App and then constructing a small notification feature which alerts our administrators whenever new orders are placed.

* Placing Orders: Add a "one-click" order flow to Storedom. This should simply be a button on the Item#show page which creates a new order containing the appropriate item.
* Storedom does not have a login system, so for simplicty just attach the orders to the first user in the database.
* After placing an order, the user should land on an Order#show page displaying information about the order that was just created.
* Order Notifications: Our admin likes to keep tabs on how storedom is doing, so let's notify them whenever an order is created. Add an Order Mailer which gets sent to [email protected] whenever a new order is created. Include basic information about the order in this email.
* Set up your application to send these emails via Mailcatcher in development.

__Extension:__ Add a background processing library such as Sidekiq or Resque and send your emails asynchronously from a background job.

### Challenge 2: Storedom Wishlist

Let's add an interface that allows our users to "favorite" items within the storedom UI

* Add a link under each item tile on the items index to "Add to Favorites"
* Clicking that link should submit a request via Ajax which records the item as a favorite.
* You may either: __a)__ Store the wishlist as a list of ids in the user's Session. __b)__ Add a new
  table to the application to record favorited items. In this case treat the wishlist as "global" without
  attaching specific user ids.
* Once a user has favorited an item, the link within that item's tile should convert to "Remove from Favorites"
  and this should remain on subsequent reloads. Clicking this should remove the item from the user's favorites,
  and the link should revert to its original ("Add to Favorites") status.
* Add a link in the navbar which allows the user to view their favorites. This can be rendered as a simple list
  of items as you see fit.

__Extension:__ Add the number of "favorites" an item has received to its display on the Item index. This could either be implemented by counting records in an associated table or by adding a column on each item to store the count.


## Rubric

Subjective evaluation will be made on your work/process according to the following criteria:

#### 1. Satisfactory Progress

* 4: Developer completes all elements of both challenges as well as one or more extensions.
* 3: Developer completes all elements of both challenges.
* 2: Developer completes most elements of both challenges, with one or two minor features missing.
* 1: Developer struggles to make progress.

#### 2. Ruby Syntax & Style

* 4: Developer is able to write Ruby demonstrating a broad/deep understanding of available language features. Code that is exceptionally clear and well-factored.
* 3: Developer is able to write Ruby structures with a minimum of API reference, debugging, or support while balancing conciseness & clarity
* 2: Developer is able to write Ruby structures, but needs some support with method names/concepts or debugging syntax
* 1: Developer is generally able to write Ruby, but spends significant time debugging syntax or looking up elementary methods/concepts
* 0: Developer struggles with basic Ruby syntax
 
#### 3. Javascript Syntax & Style

* 4: Developer is able to write Javascript demonstrating a broad/deep understanding of available language features. Code demonstrates clarity around client/server relationship.
* 3: Developer is able to write competent Javascript, with some hiccups or confusion around client/server
* 2: Developer is able to assemble working Javascript, but code is not idiomatic or struggles with client/server boundary.
* 1: Developer struggles with basic Javascript methods or syntax.

#### 5. Rails Style & API

* 4: Developer is able to craft Rails features that make smart use of Ruby, follow the principles of MVC, and push business logic down where it belongs
* 3: Developer generally writes clean Rails features that make smart use of Ruby, with some struggles in pushing logic down the stack
* 2: Developer struggles with some concepts of MVC
* 1: Developer struggles with MVC and pushing logic down the stack
* 0: Developer shows little or no understanding of how to craft Rails applications

### 6. Testing

* 4: Developer excels at taking small steps and using the tests for *both* design and verification
* 3: Developer writes tests that are effective validation of functionality, but don't drive the design
* 2: Developer uses tests to guide development, but implements more functionality than the tests cover
* 1: Developer is able to write tests, but they're written after or in the middle of implementation
* 0: Developer does not use tests to guide development