Maddie Shields - Edges - MediaRanker

[madaleines]

Media Ranker

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
Describe a custom model method you wrote.	did not get to finishing project
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?	Session is a way to store info about the user logged in. Flash is a way to give notice about something that went wrong such as wrong params entered. The session will store the flash so the user cannot manipulate the flash.
Describe a controller filter you wrote.	Did not finish
What was one thing that you gained more clarity on through this assignment?
What is the Heroku URL of your deployed application?
Do you have any recommendations on how we could improve this project for the next cohort?

[droberts-sea]

I'm not going to give a full review for this incomplete submission, but I do want to give some feedback about what I'm seeing. You have most of the controller work done for waves 1 and 2, including Work CRUD, logging in and voting. This controller code looks pretty solid - I'm not a compiler, but I didn't spot any obvious bugs. However, you don't have any views, which means there's no way to actually run any of the controller actions. This indicates to me that, beyond any holes in your understanding of the curriculum, there's a major issue with your process for writing code.

You should be running you code regularly to see whether it works. Every time you build a piece of your site, you should find a way to try it out. In the context of Rails, that means:

• When you make a change to the model (relation, custom method, validation) you try it out immediately, either on the rails console, or by writing a model test.
• When you build a controller action, you also build at least a simple version of the view, before moving on to the next action. It doesn't have to be complete or perfectly styled, but it does need to show the work.

This does two things:

• It allows you to catch problems and mistakes early before you repeat them
• It gives you a little morale boost, because you get to see something working

Both of these will help you to write cleaner, less buggy code faster.

Getting students to run their code and try it out piece by piece is part of why we structure projects in waves - the hope is that if wave 1 is complete, from the database to the views, that gives a solid foundation to work on wave 2. Your development feedback cycle should be even tighter than that (typically no more than 4 or 5 lines of code before trying it out), but the waves give it a little more structure.

This idea of having a tight feedback loop between writing code and seeing the result is one of the core tenants of agile programming. In agile we usually think about it in the context of release cycles and getting feedback from customers, but it applies equally well to the development cycle where you are acting as the user, giving feedback to yourself.