Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leaves - Janice, Ga-Young, Mariya, and Julia K #85

Open
wants to merge 301 commits into
base: master
Choose a base branch
from

Conversation

Kalakalot
Copy link

@Kalakalot Kalakalot commented Nov 1, 2019

bEtsy

Congratulations! You're submitting your assignment! These comprehension questions should be answered by all members of your team, not by a single teammate.

Comprehension Questions

Question Answer
Each team member: what is one thing you were primarily responsible for that you're proud of? Janice: I was primarily responsible for the functionality behind orders--cart, checkout, confirmation, etc. Ga-Young: One thing that I learned that I was responsible for was making the table for the merchant's fulfillment section. I have never made a table with bootstrap before and that was interesting to mess with and figure out. Mariya: I am proud of creating the products partial. Julia K: I worked on the reviews model/controller/tests/view/styling and I am happy with the way it turned out.
Each team member: what is one thing you were primarily responsible for that you would like targeted feedback on? Janice: I'd appreciate targeted feedback on my tests and styling. Ga-Young: I would like targeted feedback on my merchant's show view page. The view page shows a different view depending on if a merchant is signed in or not and I'm not sure if this is good practice or if there is a better way to do this.. Mariya: I'd like targeted feedback on my tests (products & categories). Julia K: I'd like feedback on the application.html.erb view (contains navbar, flash messaging, and footer) and the home page (homepages index.html.erb). These are two separate views but I think of them as a single, entry-into-website package.
How did your team break up the work to be done? Mariya took on products and categories, Janice took on the shopping cart and order products, Ga-Young took on merchants, and Julia took on reviews, the application view, and the homepage view.
How did your team utilize git to collaborate? We all did individual work on our own branches then created a pull request when we ready to push out our changes to the rest of the group. We set up PRs so that two approvals were required before a PR could be merged.
What did your group do to try to keep your code DRY while many people collaborated on it? We used partials in views and caught some duplicate code during code reviews (since our PRs required two approvals before they could be merged, we all looked at each other's code frequently).
What was a technical challenge that you faced as a group? The shopping cart! This was most difficult technical part of the project, and Janice did an amazing job of taking on this work and explaining to the rest of us (repeatedly) how the controller actions work and how to make the cart play well with other functionality.
What was a team/personal challenge that you faced as a group? We had a couple of team members out sick during the course of the project, but it never felt like work was falling behind. Once our work started overlapping, we sometimes did duplicate work because we weren't communicating as well as we could have.
What was your application's ERD? (include a link) https://tinyurl.com/y4qw8bzz
What is your Trello URL? https://trello.com/b/luVexQcs/petsy-betsy
What is the Heroku URL of your deployed application? https://petsy-dream-team.herokuapp.com/

janicewhuang and others added 30 commits October 24, 2019 16:20
…updated strong params so that it will work with session[:merchant_id], updated new form to include categories
made changes to make oauth authorize correctly
gyjin and others added 28 commits November 1, 2019 10:49
fix cart styling--ordered list, lining up
@beccaelenzil
Copy link

bEtsy

What We're Looking For

Manual testing

Workflow yes / no
Deployed to Heroku
Before logging in
Browse all products, by category, by merchant yes
Leave a review yes
Verify unable to create a new product yes
After logging in
Create a category yes
Create a product in that category with stock 10 yes
Add the product you created to your cart yes
Add it again (should update quantity) yes
Verify unable to increase quantity beyond stock yes
Add another merchant's product yes
Check out zip failed when it was 00000
Check that stock was reduced yes
Change order-item's status on dashboard yes
Verify unable to leave a review for your own product yes
Verify unable to edit another merchant's product by manually editing URL yes
Verify unable to see another merchant's dashboard by manually editing URL yes

Code Review

Area yes / no
Routes
No un-needed routes generated (check reviews) yes
Routes not overly-nested (check products and merchants) yes
Merchant dashboard and cart page use a non-parameterized routes (should pull merchant or cart ID from session) instead of the merchant dashboard url being /merchants/#id and the cart page being /orders/#id consider custom routes to /dashboard and /cart
Controllers
Controller-filter to require login by default see comment
Helper methods or filters to find logged-in user, cart, product, etc yes
No excessive business logic yes -- note one comment on the create method in the orderproducts_controller
Business logic that ought to live in the model
Add / remove / update product on order it looks like most of this work is done in the orders controller
Checkout -> decrease inventory this should be in the model
Merchant's total revenue this is done in the view
Find all orders for this merchant (instance method on Merchant) yes - fullfillments
Selected Model Tests
Add item to cart:
- Can add a good product
- Can't add a product w/o enough stock
- Can't add a retired product
- Can't add to an order that's not in cart mode
- Logic specific to this implementation
thorough tests of these actions in the controller
Get orders for this merchant:
- Includes all orders from this merchant
- Doesn't include orders from another merchant
- Orders are not included more than once
- Does something reasonable when there are no orders for this merchant
there are limited custom methods, so limited things to test
Selected Controller Tests
Add item to cart:
- Empty cart (should be created)
- Cart already exists (should add to same order)
- Product already in cart (should update quantity)
- Bad product ID, product is retired, quantity too high, or something like that (error)
missing check for retired product
Leave a review:
- Works when not logged in
- Works when logged in as someone other than the product's merchant
- Doesn't work if logged in as this product's merchant
- Doesn't work if validations fail
yes

Overall Feedback

Great work overall! You've built a fully functional web store from top to bottom. This represents a huge amount of work, and you should be proud of yourselves!.

I am particularly impressed by the way you designed your user experience. It is nearly flawless!

I do see some room for improvement around taking "business" logic out of the controller and the views.

Requested focused feedback is below:

Janice: I'd appreciate targeted feedback on my tests and styling.

Consider using fixtures for your order_test.rb. Your validation tests are very thorough. Because you are using rails built in validations, it's necessary to be quite so thorough. You can trust that rails did that work for you!

Ga-Young: I would like targeted feedback on my merchant's show view page. The view page shows a different view depending on if a merchant is signed in or not and I'm not sure if this is good practice or if there is a better way to do this..

Yes -- this is a good amount of logic to put in the controller. The design was robust so that even if a nefarious user tried to access a route that the user interface didn't provide, they weren't able to perform the action

Mariya: I'd like targeted feedback on my tests (products & categories).

For the product model test you did a great job using fixtures where possible.

For your controller test, it is good practice to divide your tests into "logged in" and "logged out" tests. As such, you will only have to perform_login once.

Julia K: I'd like feedback on the application.html.erb view (contains navbar, flash messaging, and footer) and the home page (homepages index.html.erb). These are two separate views but I think of them as a single, entry-into-website package.

The application.html.erb view uses great semantic html and it produces a great user experience. As I said, the user experience is flawless! The amount of conditional logic that's used for changing the view based on what's in session is appropriate.

I noticed that the homepages index.html.erb is sectioned mostly by

s. You make good uses of classes, but I wonder if there's a way to infiltrate some more semantics into that view.

bEtsy is a huge project on a very short timeline, and this feedback should not at all diminish the magnitude of what you've accomplished. Keep up the hard work!

Only the person who submitted the PR will get an email about this feedback. Please let the rest of your team know about it.

end

def destroy
if session[:merchant_id] == nil

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should technically be able to logout even if you're logged in. There could be a UI bug where you double click the log out button. You want this action to be idempotent

end

if session[:merchant_id].nil?
flash[:warning] = "You must be logged in as a merchant to edit a product."

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The work of requiring login is a good candidate for a controller filter.

end
# if there is already an order going and desired product is already in the cart, locates that orderproduct
cur_orderproduct = Orderproduct.find_by(order_id: @order.id, product_id: @product.id)
if cur_orderproduct != nil

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of this work could be done by a custom validation in the model.


def update
if @order.update(order_params)
@order.orderproducts.each do |orderproduct|

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This belongs in the model

<th> Subtotal </th>
</tr>
</thead>
<% total = 0 %>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The work of calculating the total should be a model method that can be tested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants