safreiberg / saf_proj2

Project 2: Shopping Cart

Full problem description is located at: https://stellar.mit.edu/S/course/6/fa12/6.170/courseMaterial/topics/topic2/project/text3/text

###Heroku URL

Please put it here: powerful-scrubland-1233.herokuapp.com

Note: There is an admin account created already: username: admin password: admin

###Notes

Any instructions or notes for your grader should be placed here.

There are some items for sale already in the store. Feel free to poke around :).

###Code Deliverables

Your code should be a rails project located at the root of this repository. To create a new rails project, run

>> rails new .

in this directory.

###PDF Deliverables

Additional deliverables, such as the problem-analysis and the design-analysis, should be saved as PDF files in the directory called "deliverables"

saf_proj2's Issues

2.2 Comments

Good job!

Even the little bit of UI work you put in makes things look a lot nicer than other implementations I've seen. Most of the features work. Especially liked the fact that each item had a page, from which I can specify how many of that item I want.

Some problems you might want to rectify for 2.3: (1) I can check out n items even though you don't have n items in your inventory. Moreover, when I do check out n items, you don't change the admin page to reflect the inventory changes. (2) Whenever I try to check stuff out as admin, the checkout button fails. (3) Zooming into an item page from the shopping cart fails. :(

Fine code, design/problem analysis.

2.1 Comments

CONTEXT DIAGRAM - Like Prof. Jackson mentioned in class, your context diagram is solid; I like how you include third parties you rely on like PayPal/Stripe.

OBJECT MODEL - One of the cleanest I've read. One thought: I think you misuse the OM syntax when you say Product Order * <---- + Quantity. What does it mean for a product order to have multiple quantities associated with it? I think you're trying to say a quantity value can be >= 1? In which case there's still only 1 quantity associated with a product order.

EVENT MODEL - My only qualm is that you don't use a regular grammar here. The advantage of a regular grammar is that you can specify constraints on the number of times a particular event can occur and the ordering of said events. Change this to a regular grammar for 2.2.

Great job!

object model

Generally good! Use simple relation names rather than writing sentences on OM arcs, and if the relation isn't clear, define it separately in a textual addendum. All looks good, except for two tricky issues: (1) "Each User has one Cart. A Cart has a User or is anonymous with a session": is this anonymous cart created afresh for each session? Should you represent this explicitly? Will you transfer items to the user's cart when they log in? (2) " A Product has ! an Inventory and Price at each Store": the mention of the store suggests that something else is going on here that should be represented (or you shouldn't have mentioned the notion of a store).

2.3 Comments

FEEDBACK:

Design Analysis -

Need to do a better job here. You list a set of design challenges but then the 'details' section doesn't thoroughly or clearly address each one. For example, the first paragraph in the 'details' section does not clearly relate to the design challenges you present. Ensure that for each design challenge you mention, you establish what the possible solutions to that challenge are and what the advantages/disads of those solutions are and then how you picked a solution.

Problem Analysis -

Good. Clarity here is great.

Functionality -

Super solid. Two confusing things: (1) Lists that 'Guest' make private are viewable to all other 'Guests'. This is weird? (2) Why can't I add multiple things to the wishlist? :(

Very thorough unit tests.

modifying orders

Re: "For the administrator, there is a summary page that allows products to be added, removed, and changed with prices and inventory. The administrator will also be able to view the orders table."

In practice, the admin would need to modify the orders of course. But fine to skip for this project.

context diagram

Good context analysis. The arc marked "Small business implements AwesomeCart on their website" is suspect though. What exactly is the flow here?

Design Critique

User Perspective

The table listing the items is kind of awkward (but that’s definitely not part of the project). I like that clicking into an item, I can add it to a wishlist or my cart. That’s a nice feature.

I really like the way that quantities are handled. If I try to update the cart to a quantity that is too large, it will be set to the max available.

I like how the items I add to my cart persist over login.

Developers Perspective

The schema seems to be thought through pretty well. The use of tables with id of two items to relate say a product and wishlist is nice and keeps things clean and modular.

Most and least successful decisions

The decision to have quantity in the product is debatable. Some say that a product should contain information about the actual product, which persists or stays the same over time, while items are derived from products because they are the actual items a person would receive. This helps separate a product from the items being sold/shipped.

Analysis of design faults in terms of design principles

I feel like the routes.rb file does not follow rails convention. It seems to be pretty messy and use of resources might help clean it up.

Priorities for improvement

The functionality is pretty solid so I think focusing on the UI/UX would be the first area for improvement.