I’ve officially passed the half way point in my Flatiron School’s Online Software Engineering Bootcamp with the completion of my third out of five portfolio projects. Going into the start of this project, I was a lot more confident than I have been for the previous two. I had a solid idea about the web application that I wanted to make, and I felt pretty good about my RoR skills as they had progressed throught the labs - which put me WAY ahead of where I’d been with my CLI gem and Sinatra projects, where I’d spent honestly more than half the project week just trying to wrap my head around where to start!
My idea seemed simple enough - I wanted to make an app that functioned like an online workout tracker. In theory, I would be able to create and save Users, that would have secure log ins. These Users would be refered to within the app as Athletes, with this being a gym and all. The next model would be Skills, which would store the name of different exerises that you can do as part of a workout, with a name and a description. And the glue that makes this an actual app worth making, would be the third model, Workouts. Workouts would be made of a number of different skills, and Athletes would be about to track which workouts they had completed, and through the stored workouts, which skills they had worked on.
With this idea in mind, and confidence in heart, I jumped in. Only things didn’t go as smoothly as I had imagined, and I ran into some (no, a LOT) obstacles along the way. Here are a fewr take home points that I learned along the way:
Things get tricky with Devise when you’re trying to call your User model something other than User.
Although I had never used it before (all our other projects and labs have been done with the Rails standard SQLite3), I started my project with PostgreSQL and good intentions, as I had heard that it is simpler to publish through Heroku this way. It was simple enough to get an initial framwork set up, with my models named how I initially imagined they would be….until I tried to run the Devise gem to set up all my user authentication aspects. Without a model called User, but with the same function of User, I thought I would be able to tell the gem in my set up steps to just override its default and set up all the log in, etc. functionallity on my Athlete model. Turns out I was wrong. I’m sure that it IS possible, but what I found was that it was more way confusing than I was prepared for. I ended up deleting my first app attempt all together and starting over from scratch, just to find that PostgreSQL still persisted my faulty tables, so I ended up changing my app name slightly in order to really start over from scratch. My takeaway here, was to simply stick with the User model until I understand Devise a bit better.
Forms Forms Forms (and routing)
A significant bulk of the curriculum that we’ve been working on throughout the Rails section of our bootcamp has been focused on forms and routing. Somehow, when it came to creating an app from the ground up, I realized that I was SERIOUSLY lacking in my understanding of how these things work and how/where to apply them. With the first form_for that I put into my app, it became apparent that I had very very little idea what I was doing. I didn’t know the syntax by heart, and needed to google every. single. step. of the process. And even then, I was getting stuck and needed to ask for guidance from classmates who could actually verbally walk me through things. Slowly - and I mean SLOWLY - I started to get the hang of it. At some point it started to click what text_field’s and collection_select’s and check_box’s were capable of doing. I started to understand how to set the URLs, and where data entered was being stored. Maybe most importantly, I started to be able to know where to look for the information that was passed from my forms, and how to pass that along to wherever else I needed to collect and use that data. By the end of the project, I finally felt like I could write a form that was actually useable for my app to have the functionality that I had envissioned!
AND MOST IMPORTANTLY…
Ask for, recieve and GIVE help!!
By far and away the biggest takaway that I got from completly building this (very simple and likely quite brutish) app, was that the most valuable asset available to me, is the other programmers around me. Between my cohort instructor, classmates, and stackoverflow.com, I was able to stop beating my head against the wall trying to re-invent the wheel. Every single problem I ran into in my own product developement process, someone else has already been there. Its easy to have a stubborness that makes you want to figure things out on your own. Its even easy to talk yourself into believing that if you can just power through and solve all your problems on your own, then you’ll have a better grasp of the material in the long run. I found that this (for me at least) is simply not true. The more I brainstormed with other programmers, the more often that someone was willing to share with me their take on how THEY would approach a problem, the more diverse ways that were presented to reach a solution to the same problem, and the more roadblocks I looked at that other people had encountered when they had worked on similar problems - the more my mind was able to actual start wrapping around the complex and dynamic ways that Ruby on Rails can be used to create. Once that began to sink in, I was able to begin offering my own suggested solutions to other peoples project problems. And as they say, teaching is the greatest way to achieve mastery of a subject.
At some point during my project week, I lost confidence and started questioning if I really had what it takes to make it as a programmer. With the help and support of the other programmers around me, I reached a breakthrough point. I can do this.
Check out my finished project here: https://github.com/kirstenwerner/skillz_app/