Three quarters of the way through theFirehoseProject wrapped up, week 9 is over. Painting a car, the 4th of July holiday weekend, and the Women’s World Cup final (which was AMAZING, hell yes USA! Carli Lloyd, what a beast but I digress) kind of threw me off my schedule a bit so I didn’t get as much in as I would’ve liked, such is life. What I did get in, in terms of coding, was very useful and will be extremely beneficial as I move forward with my career. My week has covered foreign_key associations, learning how to test, STI (single table inheritance), moving forward with lightning talks and troubleshooting virtual layers. Looking back even with the holiday I managed to fit a lot in this week! So where we go.
Foreign keys, a way to link one table to another by attaching a foreign key to another table’s primary key. Well that’s the best way I can explain that. The task at hand was to be able to pull a user_id from one table and then place that user_id in either a black_user_id or a white_user_id for when we start a new chess game. Instead of creating a super sophisticated or redundant way of approaching this option Rails has a wonderful way of dealing with relational databases and using foreign_key associations it made that task pretty easy. It’s sort of hard for me to explain without showing with a few examples but alas this is not the time nor place (I have recently been tossing around the idea of having a strictly technical blog but we’ll see). So foreign_key associations a great way of dealing with relational databases in Rails. Worked beautifully for what I needed.
After talking a the foreign keys and since I was working on this project with a group of people I didn’t have a way to see if my code worked. Enter TDD (test driven development), asking one of the founders if he had suggestions on testing what I built he gave me a great starting position for building tests to test my code, I had to really start somewhere. So I begun, I know TDD is super important so I took this as a challenge to learn more, and I definitely struggled. First I went at it in my console since that was explained to me that’s the best way to start thinking about writing tests, write the test like you would write it in your console. I wrote it in my console, then I wrote on a piece of paper (unfortunately it lacks the immediate feedback loop), and then I wrote it in test file. BANG! It worked! Feeling a wonderful sense of accomplishment, no matter how simplistic and mundane my actual test was it was a boost to my confidence.
Riding on the high of accomplishing some TDD I jumped into my next task building out the method that would populate our initial chess board with its pieces. Not a super difficult task but a time consuming one from the approach that I took, I’m still trying to figure out how to refactor it some more. The result again is that I had no way to actually test my code or did I? Yes, yes I did. I would have to write another test and now I was excited, a new challenge and no guidance. Once again I hit up my console to get things rolling and bango, Bob’s your uncle, I nailed it! Using the same tactic as before I wrote my test in the console, then wrote it on paper (feedback loop or not it’s a great way to solidify knowledge and reference later), and then I applied it to my test file. All green and we’re on our way. Two tests in one day! With the guidance of Ken I was able to really start to understand testing.
Building upon the task I had just completed we needed to implement STI (single table inheritance) which is a way to emulate object-oriented inheritance in a relational database. It’s a powerful way of using the built in inheritance to call objects without having to waste valuable table space in our database and without having to build out multiple and unnecessary tables. Now I wasn’t the lead on this task but I was consulted, thoroughly confused (I needed to sleep on it), and then I had my ah-ha moment where STI just clicked. After implementing STI into our chess app I then had to implement those new models into my board population (yay! code got cleaner!). STI can be a really powerful way of making the Rails magic work for you and I will definitely keep this knowledge in my mind for future projects.
With continued interest with last weeks idea of Firehose lightning talks I continued with theorizing the logistics of the talks and prepping for my own talk. I’ve got to say I’m really excited about this, I think this will be an excellent way for us, the Firehosers, to build a really great community, teach each other, and share our interests. Like I said I’m excited for this idea and so I got a start on my prepping. Now I’m doing my talk on Jekyll and since I played with it on a different machine I needed to setup my dev environment so I could use it on my primary computer. Which I’m using VirtualBox and Vagrant to host my dev environment and while I LOVE virtual machines, troubleshooting issues can be an absolute nightmare! That’s what I dealt with a nightmare, nothing was working, and so I had to dive into Vagrant and Jekyll and figure out what was going on. Sometimes being a developer has nothing to do with developing anything and everything to do about getting your environment setup. An hour later of fighting with the damn virtual machine I figured out how to get things working, lesson learned for my lighting talk.
This week was pretty awesome, great socializing experiences and great coding experiences. Each week I learn more and more and the further down the rabbit hole I chase this thing called web development the more I find myself feeling like I am exactly where I should be, I love it! This next week will be even better, with more time available to me and more things I want to accomplish I’ve got my work cut out for me and I’m looking forward to it.