Diana Kimball

Notes on what it’s like to write code.

CS50 started last week. It’s the introductory computer science class I never took as an undergrad, so I’m beyond excited to be taking it now. We learned all about psuedocode and binary and ASCII and Scratch. I watched both lectures on video (one via simulcast at HBS, one the morning after on my iPad at the gym), which felt like a strange luxury. The problem set was to assemble a small app in Scratch. Looking around my dorm room for ideas, the mobile hanging from the ceiling lamp caught my eye. (Amazon tells me that it’s called “Expecting Fish,” but we always thought of our matching mobiles as whales.) I spent a lot of time tracing photographs of the mobile on my iPad in Adobe Ideas (quite a great app—it smooths out jagged, finger-painted lines) to create some hand-drawn sprites for the app I had in mind. It’s called Hungry Whales in Love. I might try to animate the sprites a bit more before the problem set is due, but I’m pleased by how possible it was to create something cool.

Scratch is a visual programming language created at MIT with kids in mind, but it also serves as an accessible entry point for just about anyone. Professor David Malan wrote up a good guide to what Scratch can teach about computer science more generally.

After I’d taken a stab at the problem set, a conversation with my friend Zach got me excited about a new idea. This idea would require parsing emails and, probably, learning Rails. Ruby is a programming language and Rails is the web framework that made it famous. After a couple of early attempts to understand Rails (dating all the way back to 2010!), I switched allegiances to Sinatra and never looked back. Well…until this spring, that is, when Zach and I built a web app together for a school project, and the codebase started to spiral out of control. Sinatra is great for simple apps and serviceable even for larger ones, but the recent memory of a monolithic codebase made me think that maybe Rails was worth a second shot.

But before I could dive into Rails, I first needed to solve the mystery of the unloadable gems. Gems are Ruby’s way of presenting bite-sized code libraries, but to be used, you first have to load them into Ruby. I’d recently upgraded my computer’s operating system to Mountain Lion, and the next time I went to update my gems I was hit with a wall of fearsome errors in the Terminal window. I Googled around, but to no avail; the standard fixes (which included installing command-line tools through XCode, which I dutifully did) didn’t seem to have any effect. So on Saturday, I hopped on Skype to screenshare with Erik and he walked me through a bunch of cryptic commands that did the trick. I mostly understood what each command did, but was still impressed with the human-computer mind meld required to conjure up the sequence of incantations in the first place. Let it be known: if your system gets out of whack, that’s a great time to reach out to the most UNIXy person in your life for help. You can try to be a hero for a little while, but at some point you’re just holding yourself back from writing the code that’s within reach by trying to solve problems that call for hard-won intuition you’re still in the process of building.

With gems in place, I was able to happily truck along for a few hours before realizing that what I really needed was a tour of Rails. Creating an app in Rails generates A LOT of folders full of files. I could explore the existing files on my own, but it was hard to tell where new files should go. Fortunately, Erik was available for a second Skype session, so we hopped back on and he gave me the full Rails tour, going folder by folder.

Then, since Erik still had a bit more time, we did some setup on the app idea I was working on, which involved integrating with SendGrid’s email parsing API. (You can send an email to your app and get it out as structured data! Subject line, body text, everything.) Sadly, I learned that there was no Ruby wrapper for the parsing API (just the sending API), so I had to learn how to interact with the JSON (a common way of transmitting application programming interface, or API, data) directly. Less sadly, this turned out not to be as difficult as I’d imagined.

Returning to the app idea today, I realized that Rails still felt like a foreign country. Rather than push ahead, I decided it might be a good idea to take some time to revisit Michael Hartl’s Rails tutorial. This was, in fact, the very same tutorial that yielded my first-ever GitHub repository in October 2010. But I was pleased to discover that Michael had substantially revised the tutorial within the past couple of months, so it’s as up-to-date as ever: still chock-full of current development best practices like “version control with Git and GitHub, test-driven development (TDD) with RSpec, and instant deployment with Heroku,” and even tweaked to incorporate Twitter Bootstrap, my favorite front-end framework. (A “front-end framework” helps define the way a website looks and acts in a browser.)

So I started going through Michael’s tutorial, marveling again at how good it is (and at how much I’ve learned in the two years since my first attempt), and then decided to swing back to the app I was working on to see if any of the (chapter and a half) I’d gone through had stuck. Nope: Rails still felt like Container Store quicksand. However, I’m now convinced that going through the tutorial (the real actual whole tutorial, not just one and a half chapters in an afternoon) will help me feel more at home in Rails.

While coding, I listened to the xx’s new album on repeat. For sustenance, I relied on good old Amy’s microwavable mac & cheese, among other things. (I’d stocked the freezer compartment in the common area fridge in advance.)

Other than Scratch and Rails, I’ve also been getting back into R. R is many things—the main thing being “a full-on functional programming language”—but most people know it as a statistical package that can also sometimes stand in for Excel when dealing with datasets. Fred’s a believer and so when I expressed interest via email, he replied with a link to an awesome tutorial that reveals one of R’s secret superpowers: the graphical packages with which it plays nicely. ggplot2 is Fred’s favorite. After going through the tutorial, I’m sold, too. Not sure exactly how this will fit in with everything else, but for now I’ll just let The Art of R Programming quietly in my pile of desktop windows, beckoning me to work through a few pages every once in a while.

Oh, and iOS. One of my long-term goals for the semester is to build an iOS app that integrates audio recording and upload. It seems like it can’t be that hard, yet I kind of know it will be. Greg suggested that MacRuby might be a good bridge to Objective C since I’m already familiar with Ruby, so as I was shuffling tabs today I decided to open one to search for Matt Aimonetti’s MacRuby book. One tab spawned another (as tabs tend to do), and I found myself at Matt’s blog. This was actually a good thing, since he has some fascinating writing up there. One of the nice things about programming (and about the internet in general, I suppose) is that a single unassuming search can land you in the heart  of an expert debate. Along those lines, I especially enjoyed reading Matt’s February 2012 post on learning from Rails’ failures. Reading it helped me remember that Rails is written by people, and people are human, and we’re all trying to find the balance between strengthening our cores and expanding our capabilities.