My Rails Project

For my Rails Project with Flatiron School I decided to expand upon the Sinatra project I had built previously and add more features to bring it closer toward being practical for production. The app which I have simply titled “KJ’s List” is intended for people in the gig economy to pair with people in need of private contractors to perform odd jobs.

The workflow which I developed for my Sinatra project covers the basics of the application but was rather simplistic and a production application would need more functionality. In the original Sinatra project, user’s (once logged in) could create listings and other user’s could then make bids on those listings based on how much they would charge to perform the listed job. While this covers the basics of the application’s purpose, it leaves out ways for user’s to determine how good the bidders are at being able to perform the tasks of the job. It also leaves out a way for the lister to communicate with the bidders to ask further questions or or ultimately hire them for the job.

In my rails application I solved both problems. The first was solved by adding a review model for the owner of the listing to review the user who ultimately presented the winning bid and performed the job, so that other users would have feedback to look over in determining the qualification of the bidder. One attribute of the review was to tag the user with a skill so that other user’s can easily determine if the bidder’s skill align with the listed job, and also to provide a query parameter for other users to search for contractors by.

The second problem was a little more difficult to solve. In order for users to communicate with one another I wanted to build some kind of messaging feature within the application. creating the associations and join tables presented a difficult problem for me to solve. Initially I had figured it would be some kind of model relationship like this.

Trying do associate my models this way was difficult and after research I figured out a better way to do it. In addition to my User and Message models, I would also include a Participant and a Conversation model. Each model would look like so:

In this set up all of the messages belong to the conversation like a message thread. The missing piece to this puzzle that was difficult to solve at first was how to join the users with the the conversation. The solution was the participant model which essentially acts a proxy for the user that only exists in the conversation. By joining the tables in this manner, I did not need to do a bunch of weird aliasing on the user model to join them based on their specific messages together.