Fire - Madeline

[made-line]

Media Ranker

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
Describe a custom model method you wrote.	Will come back to this.
Describe how you approached testing that model method. What edge cases did you come up with?	Will come back to this.
What are session and flash? What is the difference between them?	Session and flash are hash-like objects in Rails. Session data is stored until the contents are cleared by removing browser cookies or setting the ID to nil in Rails. Flash data is only stored until the next request-response cycle.
What was one thing that you gained more clarity on through this assignment?	How important relationships are as you're scaling up more features and actions.
What is the Heroku URL of your deployed application?	TBD; I plan on completing the project more before deploying to Heroku.

Assignment Submission: Media Ranker

Congratulations! You're submitting your assignment. Please reflect on the assignment with these questions.

Reflection

Prompt	Response
What was a custom model method you wrote? What was it responsible for doing?
Describe how you approached testing that model method. What edge cases did you come up with?
What are session and flash? What is the difference between them?
What was one thing that you gained more clarity on through this assignment?
What is the Heroku URL of your deployed application?

[beccaelenzil]

Media Ranker

Updated feedback from 12/2 in ()

Functional Requirements: Manual Testing

Criteria	yes/no
Before logging in	--
1. On index page, there are at most 10 pieces of media on three lists, and a Media Spotlight	(✔️) missing media spotlight
2. Can go into a work's show page	✔️
3. Verify unable to vote on a work, and get a flash message	(✔️) This has not been implemented
4. Can edit this work successfully, and get a flash message	✔️
5. Can go to "View all media" page and see three lists of works, sorted by vote	✔️
6. Verify unable to create a new work when the form is empty, and details about the validation errors are visible to the user through a flash message	✔️
7. Can create a new work successfully. Note the URL for this work's show page	✔️
8. Can delete this work successfully	✔️
9. Going back to the URL of this deleted work's show page produces a 404 or some redirect behavior (and does not try to produce a broken view)	✔️
10. Verify that the "View all users" page lists no users	✔️ Not required (wave 3)
Log in	--
11. Logging in with a valid name changes the UI to "Logged in as" and "Logout" buttons	✔️
12. Your username is listed in "View all users" page	✔️ Not required (wave 3)
13. Verify that number of votes determines the Media Spotlight	(✔️) Votes not implemented
14. Voting on several different pieces of media affects the "Votes" tables shown in the work's show page and the user's show page	✔️ Not required (wave 3)
15. Voting on the same work twice produces an error and flash message, and there is no extra vote	Votes not implemented
Log out	--
16. Logging out showed a flash message and changed the UI	✔️
17. Logging in as a new user creates a new user	✔️
18. Logging in as an already existing user has a specific flash message	✔️

Major Learning Goals/Code Review

Criteria	yes/no
1. Sees the full development cycle including deployment, and the app is deployed to Heroku	No deployed
2. Practices full-stack development and fulfilling story requirements: the styling, look, and feel of the app is similar to the original Media Ranker	There are a few styles applied
3. Practices git with at least 25 small commits and meaningful commit messages	✔️

Previous Rails learning, Building Complex Model Logic, DRYing up Rails Code

Criteria	yes/no
4. Routes file uses resources for works	✔️
5. Routes file shows intention in limiting routes for voting, log-in functionality, and users	✔️
6. The homepage view, all media view, and new works view use semantic HTML	✔️
7. The homepage view, all media view, and new works view use partials when appropriate	See in-line comments
8. The model for media (likely named work.rb) has_many votes	(✔️)Votes not implemented
9. The model for media has methods to describe business logic, specifically for top ten and top media, possibly also for getting works by some category	(✔️ see in-line comment for how this could be DRYed up) see in-line comment and recall our dicussion about how the logic in the view could be moved to the model
10. Some controller, likely the ApplicationController, has a controller filter for finding a logged in user	✔️
11. Some controller, likely the WorksController, has a controller filter for finding a work	(✔️) see in-line comment
12. The WorksController uses strong params	(✔️) see in-line comment
13. The WorksController's code style is clean, and focused on working with requests, responses, params, session, flash	✔️

Testing Rails Apps

Criteria	yes/no
14. There are valid fixtures files used for users, votes, and works	(✔️)No fixtures
15. User model has tests with sections on validations (valid and invalid) and relationships (has votes)	No user test
16. Vote model has tests with sections on validations (valid and invalid) and relationships (belongs to a user, belongs to a vote)	(not vote tests) Votes not implemented
17. Work model has tests with sections on validations (valid and invalid) and relationships (has votes)	(✔️ - see inline comments for the votes relationship tests) Validation tests look good
18. Work model has tests with a section on all business logic methods in the model, including their edge cases	(no tests of custom model methods) No custom model methods

Overall Feedback

(Good work completing this project. You did a great job implementing the Votes model. It is also clear that you met the learning goals around creating custom model methods, writing controller filters, and using strong params.

I still see room for growth in using partial views to DRY up your code. I encourage you to try to refactor your index views with partials views and let me know if you have questions. As you mentioned, you did not have time to complete the model tests. I also encourage you to work through these. I've provided feedback on the work/vote relationship test that should get that test passing. As always, please let me know if you have any questions).

You are off to a good start on this project. Your controller CRUD actions for logical and clean. You've met the learning goal of working with session for login and log out functionality. You've done a good job using semantic html in your views. As we discussed, by using loops, model methods, and/or partial views, you can DRY up this code.

As we discussed, the voting feature was not implemented and thus you didn't have an opportunity to design and learn from writing the custom methods involved in this feature. In addition, you did not have the opportunity to work with test fixtures.

For the bEtsy project, I encourage you to work closely with your team on designing and implementing the custom actions (particularly adding to cart and checking out) so that you are able to do some of the learning involved in writing these custom routes, model methods, and controller methods. I also encourage you to work with test fixtures and styles.

Let's continue to work together to figure out how you can work more effectively to be able to complete more of the projects so that you are able to meet the learning goals.

Overall Feedback	Criteria	yes/no
Green (Meets/Exceeds Standards)	14+ in Functional Requirements: Manual Testing && 14+ in Code Review
Yellow (Approaches Standards)	12+ in Functional Requirements: Manual Testing && 11+ in Code Review, or the instructor judges that this project needs special attention
Red (Not at Standard)	0-10 in Code Review or 0-11 in Functional Reqs, or assignment is breaking/doesn’t run with less than 5 minutes of debugging, or the instructor judges that this project needs special attention	✔️

Code Style Bonus Awards

Was the code particularly impressive in code style for any of these reasons (or more...?)

Quality	Yes?
Perfect Indentation	✅
Descriptive/Readable	✅
Logical/Organized	✅

[beccaelenzil]

Consider making model method:

#Work.rb
def self.select_by_category(category)
    return self.all.select{ |work| work[:category] == "book" }
end

#works_controller
def homepage
   @books = Work.select_by_category("book")
   @movies = Work.select_by_category("movie")
end

[beccaelenzil]

Alternatively, instead of using select_by_category in the controller, in your view

["book", "movie"].each do |category|
     works = Work.select_by_category(category)
     <% top_works= works.sample(10) %>
<% top_works.each do |work| %>
  <li>
  <%= link_to work.title, work_path(work) %> <%= work[:creator] %> <%=work[:publication_year] %>
  </li>
<% end %>
``` <-- not correct snytax

[beccaelenzil]

A partial view could also be used to DRY up this code

[beccaelenzil]

Consider moving this logic to a controller filter find_work

[beccaelenzil]

Good work displaying the validation errors.

[beccaelenzil]

Good work displaying the flash messages

[beccaelenzil]

See updated feedback in the rubric in ()

[beccaelenzil]

Note that these 3 blocks of code for each category are nearly the same. Consider how you could DRY this up with a partial view or loop.

[beccaelenzil]

Note that these 3 blocks of code for each category are nearly the same. Consider how you could DRY this up with a partial view or loop.

[beccaelenzil]

consider making one method that takes category as an argument to DRY this up.

def self.sort_works(category)
        works = Work.where(category: categorys)
        sorted_works = works.sort_by {|work| work.votes.count }
        return sorted_works.reverse
end

[beccaelenzil]

Instead of using ids, you should just pass the user and works directly. Fixtures don't like ids.

Suggested change

	vote1:
	user_id: batman.id
	work_id: parable.id
	vote1:
	user: batman
	work: parable

[beccaelenzil]

You should remove these lines because these relationships are already created in your fixtures.