Week 2 Diagnostic

week-2-diagnostic.markdown

• Describe the request-response cycle. Start with the client making a request.

  The user looks at a page of info and then requests a new page from the browser. The browser assesmbles an HTTP request which is sent to the server. The server receives the request, prepares and sends a response. Then the process starts over.

• Explain when each of these HTTP verbs would be used: GET, POST, PUT, DELETE.

  GET: rendering info on the page POST: sending info to the server PUT: editing info DELETE: deleting info

• What are all of the necessary routes for full CRUD functionality in Sinatra app? Why do we need seven routes when there are only four CRUD actions?

  _____ = main subject of page - tasks, skills, users, etc. GET + "/" = info about all (users, taks, etc) (read) GET + "//:id" = info about one in particular (read) GET + "//new" = form to create a new item/thing (create part 1) POST + "/" = create the new thing (create part 2) GET + "//:id/edit" = form to edit a particular thing (update part 1) PUT + "//:id" = update the thing (update part 2) DELETE + "/_____/:id" = delete the thing (delete)

  We need 7 routes because creating and editing happen in two stages - getting the information and then actually making the change/new thing. (what is a better way to refer to "the thing/task/user", etc.?)

• Describe the function of models in the MVC structure.

  The models represent knowledge in our app. The model folder holds all of our classes and Ruby logic which is used to manipulate state (typically in the database).

• Describe the function of views in the MVC structure.

  The views are what render the models to the viewer/user. The views don't hold logic of their own, they instead ask questions of the models (each view is attached to a corresponding model I think).

• Describe the function of controllers in the MVC structure.

  This is the brains of our app and provides a link between a user and the system. The controllers are like the bosses, delegating everything in the app. The controllers will provide a means for the user to give input/data (via menus, forms, etc.). Then it/they (we can have more than one controller, yes?) takes the input and passes it to one or more of the views (which then grab the logic from the models and render the output).

• What is the difference between model tests, feature tests, and controller tests? Give an example of functionality tested using a model test, functionality tested in a feature test, and functionality tested in a controller test.

  Model tests are like what we did all through module 1 - they test our methods and logic behind the scenes in small pieces. Feature tests are where we use Capybara and are testing the environment that the user interacts with. We should not be testing logic at all, instead testing if the correct things are rendered on the correct pages, etc. Controller tests I'm a bit unclear about - I think they are testing the connection between the above - if certain routes are doing exactly what they should be...

• What does ActiveRecord do? Why do we use ORMs like ActiveRecord?

  ActiveRecord is an ORM - object relation mapper. It allows us to interface with our database (which we typically can't see). The ActiveRecord methods grab us data that we can then perform Ruby functions upon. I'd like to be able to expand on this, but I need to study it and use it more...