Sinatra Project for Flatiron School
To conclude the second phase of the software engineer course at Flatiron School, students in my cohort were required to create an app using Sinatra. Sinatra is lightweight Ruby framework for quickly creating web-applications in Ruby. Within this project we were also required to use Active Record for storing information in a database. In phase 2 we got our first introduction to querying a database, in which we had to first write SQL statements. Active Record makes querying a database much easier to work with my generating the SQL statements for you.
Our Sinatra application was required to be a CRUD application with multiple models using ‘belongs to’ and ‘has many’ relationships. The application I decided to build is similar in purpose to Craigslist or Angie’s List in that it is designed to pair private contractors or gig workers with people who need odd jobs done. It is not specific to pairing a contractor with someone needing some home repairs done though, as it is completely open ended for what can be listed. A musician for example could be looking for other musicians for a project or maybe a tech to do sound or lighting for a gig. Someone could theoretically be looking for a chauffeur for an evening or a caterer, and they could post that as a listing.
On the other end, other users can view these listings and if it is a job they could perform, they simply send a bid to the lister for what they would charge to perform that gig. This cuts out some of the back and forth that occurs with a service like Craigslist where you then communicate via phone or email outside of the application and gets directly to the point. Whereas where Craigslist users must always be cautious of a scam, if this app were put into production, there would be a record of the agreed upon price and a payment gateway could even be implemented similar to Paypal with Ebay.
Obviously this isn’t a fully robust application like one of the examples mentioned, but it was fun to plan something like that and the foundation is certainly there should I want to add such functionality later in hope of bringing it to full production. This most enjoyable part of this experience for me was planning the modeling to make the business logic work and then figuring out how to relate the models together in the database. As someone who enjoys problem solving, this right here is why I want to pursue a career as a software engineer.
In the next phase of the course we get to learn Rails and I am excited to jump into an even more robust framework. My ideal career in software engineering would be to work with a backend language like Ruby or Python getting to write software to interact with a database. Being presented with business logic problems to solve by figuring out how to make software model real life situations and interactions is certainly something I can get very used to doing.