Semret & Lindsay - Rideshare Rails - Edges

[snicodimos]

Rideshare-Rails

Congratulations! You're submitting your assignment! These comprehension questions should be answered by both partners together, not by a single teammate.

Comprehension Questions

Question	Answer
Describe the types of entity relationships you set up in your project and why you set up the relationships that way	A passenger has many trips and a driver can driver many trips. Thus there is one-to many relationships between passenger/trips and driver/trip. The trips table in the db has foreign_keys for both passenger and driver.
Describe the role of model validations in your application	There are two places in the site that we get information from the client using a form_with. That is where passengers and drivers are able to create new accounts. We added a validation to make sure that name, phone for passenger and name, vin for drivers were present. If drivers inputed a value that is shorter than 17 characters the error will show up.
How did your team break up the work to be done?	The initial set up that includes routes, the ERD, and general planning was done together. We also utilized the Trello board extensively to drive the work. We color coordinated who does what. We also branched off in our local machines to do the work and merged and pushed accordingly with constant communications about our progress.
What features did you choose to prioritize in your project, and what features, if any, did you have to set aside to meet the deadline?	We met most of the requirements. There were minor features like making the rating option disappear when a driver account is deleted before the passenger rates the trip. If the passenger didn’t rate the trip then they cant request a new trip. We would have liked to work on it if we had time. Another feature is the custom validation is not quite operating the way we wanted to implement but we ran out of time. Additionally, we would have liked to style the index page differently than the rest of the application.
What was one thing that your team collectively gained more clarity on after completing this assignment?	We got more clarity on how models, controllers and views communicate. It was nice to know that class methods of drivers can be accessed in the trip controller. We got more clarity on creating and migrating dbs. We utilized git branching and the process of merging, pushing and pulling was clearer than when we started.
What is your Trello board URL?	https://trello.com/b/QhwF6SgT/semret-lindsay-rideshare-2
What is the Heroku URL of your deployed application?	https://semlind-app.herokuapp.com/
What are two discussion points that you and your pair discussed when giving/receiving feedback from each other that you would be willing to share?	Our communication throughout was really open. Even when we were working on the same problem, we would work on separate branches, communicate about what we did, teach the other person new tricks and collectively decide on a solution and push to the master.

[droberts-sea]

Rideshare Rails

What We're Looking For

Feature	Feedback
Baseline
Appropriate git usage with no extraneous files checked in and both partners contributing	yes
Answered comprehension questions	yes
Uses named routes (like _path)	yes
RESTful routes utilized	yes
Project Requirements
Table relationships	yes
Validation rules for Models	yes
Business logic is in the models	yes
Database is seeded from the CSV files	yes
Trello board is created and utilized in project management	yes
Heroku instance is online	yes
The app is styled to create an attractive user interface	yes
Overall	Excellent work overall! This site's code is well-written and clear. You make good use of model methods, relations and validations, your nested routes are mostly clean, and it is clear to me that this week's learning goals were met. As with any project of this size I've left a number of nitpicks, but in general I am happy with what I see here. Keep up the hard work!

[droberts-sea]

Good use of a guard clause

[droberts-sea]

All of the work done in this method could be moved to a model method. An instance method on Passenger would probably work well, something like Passenger#request_trip.

Note that you can call methods of one model from another model, so Passenger#request_trip could call Driver.available_driver.

[droberts-sea]

I love that you made this a separate model method - good instincts!

Regarding naming, we don't typically include the name of the class in the name of a method for that class. Something like Driver.first_available or .select_available might work well.

[droberts-sea]

You ignore trips with a nil rating when computing the sum, but still include them when dividing for the average here. That means that an un-rated trip will drop the driver's average rating the same as a rating of 0 would!

[droberts-sea]

I don't think you need the :show route for trips nested under passengers. That would create a route like passengers/:passenger_id/trips/:id.