Keeping CRUDités from getting cruddy. (Secret?: lots of REST)
The struggle is real. As a teacher, I was pretty lucky to do my job remotely for the last 8 months, giving me some extra hours each day to focus on my Flatiron studies. But right around when Phase 2 started, I started going back to the school to teach hybrid classes. Which put a dent in the hours I could devote to Sinatra, CSS, HTML, ORMs, and SQL. (Even with all the time I save not changing out of stretchy pants!) Not to mention the stress that came with sending little ol’ un-vaccinated-me back into the world.
I started strong though! SQL seemed fairly manageable after a day or two, and when I was understanding join tables before some of the classmates that I look to for help, I felt this would be smooth sailing. And then for whatever reason, by the time we got to Sinatra, I felt like midlife dementia had set in. I got very lost. Very quickly. I felt like I was playing catch up. (I still feel like that a bit, on the precipice of a week off!) But I had an idea, and no one was going to stop me from seeing it through…after modifying that idea, abandoning one or two key components, and really getting comfortable with my Phase 1 coding. It wasn’t until about 4 days before this project was due that I felt — comfortable.
I have a love of puzzles. Creating, solving, collaborating, competing. You name it. I want in. So I had a (lofty) idea for this project that would assemble puzzle creators and solvers alike, and allow them to share out puzzles, and even create a Team based format that would allow for a competitive angle that would allow for scoring, a leader board, and cloud storage that would allow access to all puzzles that were uploaded.
That’s not what happened, unfortunately.
I knew the focus was on CRUD and RESTful routes, and I found that while I had the makings of a great site (and should revisit this for Phase 3, perhaps), I wanted to make sure I had the basics down first. You have to learn how to glue those wings on before you fly towards the sun, right? I trimmed a few things from the above, and I have a very clean site that -at the moment- allows ideas to be shared, of which the best puzzles are born from.
I had to retrain my thinking for any HTML. I used to “design” my theater company’s website way back in the day, 17 years ago to be exact, and I was making that up as I went. So, to get into an actual format for basic website creation, and understanding the flow of the GET and POST routes took some rewiring.
Here’s some great things I learned during my struggles:
COMMIT! I’m only seeing the benefits of committing as you code, even though I need to do a lot more exploring of Github. A great trick I found is to use the sidebar in VSC to simplify your commits and pushes.
I’m still learning everything I can do on VSC, but that 3rd menu item from the top, with 3 dots all connected by lines- clicking that shows all your changes to you code.
To commit and push, do the following: type in your commit message, hit the checkmark, and then open the 3-dot menu, and scroll down to Push, and voila! You’ve committed and pushed your code to your Github. This has saved me a lot of time, frustration, and a look of disdain for not having enough “commits” in my project.
Default values and altering my database proved necessary after I realized my models were not talking to each other in the way I needed them to. I had a Games model that served as a join table for my Player and Puzzle models, but along the line I needed Players to edit their puzzles (and ONLY their puzzles — am I right? Can I get an “Authentication!”), and the current way to validate involved code that looked like :
if Game.find_by_player_id(session[:player_id]) == ...
NO. It wasn’t clean, and I was confusing myself. So, I added a created_by attribute to my Puzzle model to facilitate authentication issues for Edits and Deletes, and also created a default method of false for a new solved? attribute for my Games table. I didn’t know you could do defaults in tables! Chalk one up on the “Learning” board!
One of the best things I discovered was the players/account to help keep other users from altering data they shouldn’t be changing.
Instead of having individual :id routes for each user, when one player logged in, they were routed through the players/account method to their #Show page. But this method confirms that the current_player(who is logged in) is identified as @player (whose :id is tied to their puzzles). It was a work around so that players weren’t being mistaken for others when entering their Gameroom (show page) through the navigation bar. It also reduced any errors that were arising from string interpolation in my nav-bar routes. *And* I made my Logout button disappear if no one is logged in, using some simple conditional .erb templating (white box above).
In hindsight, now that it’s done, I feel that my project idea far outpaced by skill set. Which is not to say that I shouldn’t push myself, but I’m happy to know that there are things I want to learn that we haven’t gotten to yet, and that makes me very excited for Phase 3.
final musings:
~helper methods are HUGE. use them often, especially if you are using any code more than twice. they are the children of DRY.
~when you are stuck with an HTML problem, it is an enormous help to have multiple friends who are designers to ask for help. Obviously, they did no designing on my site, but they got the scroll bar to come back!
