Amy Cash - Pipes - MediaRanker

[cashmonger]

Media Ranker

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
Describe a custom model method you wrote.	I wrote a method to count a the votes for each work, which goes through the vote data and pulls out how many entries relate to a work.
Describe how you approached testing that model method. What edge cases did you come up with?	I didn't get time to finish the testing. I would have written cases for when a work has zero votes, or where an invalid work id is entered.
Describe an edge case test you wrote for a controller	Testing what happens if you enter invalid data -- try to create a work without a title, or with the same title as one already in the database.
What are session and flash? What is the difference between them?	They are both hashes that Rails will create for you, but they do different things. Flash will send one-time messages to the View. Session will keep track of data related to a specific browser session, and can be used to create logins.
Describe a controller filter you wrote.	I wrote a before filter for the works controller, to take the place of all the places where a method needed to find a record, but I ended up not using it, because I later made this all part of a method.
What was one thing that you gained more clarity on through this assignment?	Using Forms outside of their own separate page. Using variables across pages -- between view, controller, model.
What is the Heroku URL of your deployed application	https://tranquil-river-21206.herokuapp.com/
Do you have any recommendations on how we could improve this project for the next cohort?	I know this is a problem that's just inherent in trying to teach/learn so much in a short time, but more time. Specifically more class time. I was sick later in the week, which compounded this problem for me, and, as you'll see, I didn't completely catch up. But, I wish there had been more project time earlier in the week, because I spent a lot of time on things later that I could have clarified then. If there's not more time, then I'd say, split up learning testing over two assignments. Trying to learn and implement all the tests was a challenge.

[droberts-sea]

Media Ranker

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene	yes
Comprehension questions	yes
General
Rails fundamentals (RESTful routing, use of named paths)	mostly - see inline comment
Semantic HTML	You make good use of this in application.html.erb, but I would like to see it used throughout the site.
Errors are reported to the user	some - see inline comments
Business logic lives in the models	yes, but see inline
Models are thoroughly tested, including relations, validations and any custom logic	some - Missing tests for relations and for custom model logic. This will become more and more important as our models grow more complex and gain more business logic.
Controllers are thoroughly tested	yes - good work
Wave 1 - Media
Splash page shows the three media categories	no
Basic CRUD operations on media are present and functional	yes
Wave 2 - Users and Votes
Users can log in and log out	yes
The ID of the current user is stored in the session	yes
Individual user pages and the user list are present	yes, though they're not linked together as on the demo site
A user cannot vote for the same media more than once	yes
All media lists are ordered by vote count	no
Splash page contains a media spotlight	no
Media pages contain lists of voting users	yes
Wave 3 - Styling
Foundation is used appropriately	some
Look and feel is similar to the original	no - make sure you get time to work on styling in bEtsy
Overall

This is a good start, but it feels like there's some room for improvement here. It seems like you had a hard time working with more complex model relations, and building them into a sophisticated application. It would definitely be worth spending some time studying relations and practicing working with models, with the goal of being able to quickly write ruby code to pull whatever information you're interested in from the database.

I also want you to be conscious about increasing the speed at which you can develop. Part of this is just experience, but there are lots of little things you can do to make life easier for your future self. An example of this is always using flash to report the success or failure (and reason for failure) of a database operation to the user. An extra couple minutes writing code now might save you half an hour of debugging later.

This was a large project with many moving parts, and we're not expecting perfection. Make sure you're getting time in bEtsy to practice the concepts you missed here, and keep up the hard work!

[droberts-sea]

I'm not sure if this is what you intended, but this syntax will not nest your vote routes under works. To do so, you need to add a do/end:

resources :works do
  resources :votes, only: [:new, :create]
end

[droberts-sea]

You probably don't need both this partial and the section in application.html.erb to display flash errors. Pick one error reporting technique and stick with it.

[droberts-sea]

I'm not sure this view is ever used.

[droberts-sea]

If updating the work fails, this will not report the reasons why back to the user. Displaying this information is important to help your users understand what went wrong, but it is also an important tool for you the developer so that you can diagnose when things go wrong.

[droberts-sea]

I really like that you've implemented this functionality in the model.

However, I'm a little worried about this implementation - you should be using active record relations to do some of this work for you. For example, instead of calling Vote.all, you can get a list of a user's votes by saying user.votes, and instead of saying @works.find(vote.work_id), you can say vote.work.

Also, since this is already an instance method on User, you shouldn't need to pass in a user, you can just use self.

Here is a simplified version:

def list_votes
  user_works = []
  self.votes.each do |vote|
    user_works << vote.work.title
  end
  return user_works
end

[droberts-sea]

I like this validation. However, you only need one or the other, not both.

[droberts-sea]

As above, you should be using AR relations here.

[droberts-sea]

You should be checking the result of save here, and reporting it (success or failure) to the user so they know what happened.

[droberts-sea]

What if the work has votes? Can you destroy it? What happens to those votes?