While this has probably been the longest time I’ve spent on a segment of the program, this is when things finally started to ‘click’ inside my head about how websites work. I’ve set up local environments to work on HTML and CSS before, but working with a local database was something I never knew how to do before, and was so surprisingly easy when demystified. The concepts were the same as object orientation, essentially, but you were able to save and retain data for ease of use. This allows you to build the application in manageable, testable chunks. But such familiarity with a process could also lead to over-confidence that leads to project bloat and bad code practices.
For my Sinatra project, I decided to expand upon my Phish Ruby CLI app.
Originally, I tried to one-for-one copy my previous objects within the new Sinatra project. This created a significant amount of bloat with a lot of information I did not need. Setlists, lyrics, tours. It all seemed important, so like a hoarder, I included it all.
My first git commit was after about two hours of typing, copying, and pasting because “everything was working fine.” It’s a bad habit that I didn’t recognize immediately. I keep going until something doesn’t make sense, then I would commit and try to work it out. It’s a mistake I would like to never make again, because once I realized it was too far to turn around, the furthest I could roll back was far beyond where the over-complication occurred. The code was full of stuff I didn’t need and processes that didn’t need to happen.
I took a look back at the project requirements in Spec.MD and decided to completely change direction. I had to make something a user could create and edit, not just add things to the user’s profile. So I decided to make this a show review app. These reviews would post to the /shows page after submission, in chronological order. A user’s reviews would also post to their profile where they could edit or delete them. If a user’s own post was on the /show page, you could enter the edit or delete function from there as well.
I branched it and first decided to gut it of columns and things we didn’t need and refactor it to make it neat like I was taught.
I can totally remove <code>Setlists</code> and any join tables of those objects therein. All that info could be stored in a string within the show itself. No need for it to be an object in and of itself.
Then I checked what data I wasn’t scraping about each song. Song itself isn’t even needed but I think it would be good to hold on to these for purposes of individual totals in the future. Songs will belong to shows, not setlists — though I plan on still using the setlist information to add the songs to a show.
Ok, then I decided to make different controllers. This also caused me to shore up my login verifications throughout the user controller, which handles most of the sign in commands. I added flash messages and continued to tightened up security flaws I left in early on.
It then became time to cut my introductory video: