On the Benefit of Mapping Things Out
As soon as I’ve learned a new concept in Ruby and am given a prompt with which to use it, the very first thing I want to do is power up Sublime Text and just start hammering away at the keyboard
The following is a guest post by Kyle Shike and originally appeared on his blog. Kyle is currently in the Ruby-003 class at The Flatiron School. You can follow him on Twitter here.
As soon as I’ve learned a new concept in Ruby and am given a prompt with which to use it, the very first thing I want to do is power up Sublime Text and just start hammering away at the keyboard until I type that final end and the project is done. Save it, run it from the command line, and then watch as the code brilliantly executes the concept it was intended.
In actuality, it’s more than likely that I’ll get a NoMethodError on line 4, calling .each on nil:NilClass or something of the like, and I’d be incredibly foolhearty to attempt to build anentire program without once running it. Hell I’m more inclined to run it after ever method definition with binding.pry tacked on or raise some_element.inspect to fully understand where my code is in an iteration, and what my program has at that particular moment.
That’s not what I’m here to write about though. As I’m given projects to work on, I’m finding more and more that there exists an incredibly valuable moment of time that occurs before the even the first line of code is laid down, when you, the programmer, are (hopefully) figuring out how youthink the code should work. Come to understand the key components of the process and design the rest about them. In a way, I think this is one of the potential benefits of test driven development.
As an example, I’ll explain the process of a group project we had to scrape the Flatiron School’s student profile pages for their data with nokogiri, and export that data with the sqlite gem into a database.
So given that all this data was ultimately going to be sent into a database via SQlite, we roughed-out a hash structure that would lend itself well to the tables and columns of our yet-to-be database. We even drew it out on paper beforehand.
Ultimately, the layout looked like this:
Each key points to a hash of individual student data, and each key itself is given a value to correspond to the primary id of that row in our table. In each hash of an individual student’s data, the keys represent the title of each column and its respective value represents data to fill that column in that row.
It was then a matter of digging through the HTML and CSS of the webpages via nokogiri, and assigning the values in the hash to the data we scraped. I found process to be really interesting -even though I’ve never been spelunking, that is exactly what it felt like to me: searching through this unseen territory for some thing string in particular.
So with this hash, full to the brim with our data and specifically layed-out for a database, the matter of writing the SQL statements (using the SQlite gem) was a breeze:
That we had taken the time to sort out the what and the how of our program beforehand made the process of implementing it in code simply a matter of syntax, which alone can be a challenge when dealing in nested iterations and the like.
As I look at it now, it seems to me that there may be a neat way of refactoring the CREATE TABLE statement, iterating through the hash for nested keys, rather than typing out each one individually. Here is the joy of making it work, and only then playing with it to make it more succinct.
Disclaimer: The information in this blog is current as of October 9, 2013. Current policies, offerings, procedures, and programs may differ.
