When given our Rails project my natural inclination was to fully build out the remainder of my Sinatra project because I had much larger goals for what I eventually wanted it to become; but then I stopped to think about all of the other interests I have that would make for a great website with a many to many data relationship. I have a wide range of interests, many of which I have touched on through my work in this course, however, I do have a deep interest in music and am an avid festival “go’er” as some may say. I am even drawn to the idea of entering the music industry through my software development knowledge as it would certainly motivate me to create new tools and functionalities that have not yet been thought of. This realization brought me to the idea of creating a performance management application for management companies who will be overseeing the operations and scheduling of a festivals stages, artists, and their associated performances. Behold, EZ Manager, an application where you can do exactly that!
After being recently introduced to the Rails generators, I was excited to begin my project with a few commands that would generate a plethora of code for me that I manually had to write during our Sinatra project. I did stay away from using the scaffold generator as instructed, and mainly utilized the resource generator as it provided just enough code to set me up without adding a bunch of useless files and folders that I am unfamiliar with. This was by far the most exciting part of the project for me as it made the painstakingly written code from our last project seem so simple and easy to now implement into a brand new project, not to mention a huge time saver!
The most challenging part of this project was deciding how my Models would work in relation to one another to create the many-to-many data relationship that is required for the project. At first I thought of having my Artists model also be my User, however I quickly began to realize the limitations this would impose on the flow of my program. Technically speaking, if I were to go this route, a user would then be required to be an artist in order to use the application for its intended purpose. Due to this I refactored my Model relationships so that a User will indeed be separate from an Artist and a User will no longer be required to be an Artist to properly use the app. An ideal use case for this application would be an Event Management company who needs to manage the performances of many different artists, on many different stages, for many different events. Also, a User can still be an Artist and may create themselves as an Artist in their database if they so choose, so this flow encapsulates the most use cases and enables me to focus on the big picture of the application so I am able to offer it to large of an audience as possible.
The Rails material is definitely more difficult to learn than any of our previous sections, however, I look back and remember myself thinking the same thing when in the middle of the last sections, and now I look back on the material and notice myself feeling like I have know my whole life what we learned 5 weeks ago. I am very excited and motivated to finish the rest of the cohort so I am able to reenter the work force and start implementing the new skills I have developed. As always, I would not have gotten this far without the help and support of my instructors and classmates and would like to say ‘Thank You’ to them as well.