Learning New Tricks: an iOS Developer Learns Ruby on Rails

I’ve been doing this programming thing a long time. Since roughly when Zork I hit the market, in fact. Back when computers couldn’t talk to each other. After that there were modems, and then FidoNet provided a crude networked mail feature. And in the very early ’90s, we discovered the Internet and all the various protocols it comprised. My contribution was that some friends and I wrote the code behind a pretty big web site. In those early days, we first did it with CGI programs written in Pro*C, then a second time with Java Servlets. A year later, we used servlets again to build an e-mail marketing platform. Building web apps with those technologies was hard work.

I am now an iOS developer, spending my time concerned with provisioning profiles, retain cycles and autolayout constraints. My interaction with these web services is mostly limited to using an instance of NSJSONSerialization. But sometimes I find myself wanting to throw together a practice app backed by a web service. During our most recent Clash of the Coders, I found myself wishing I could contribute more on the server side.

Today, server apps are built in better ways. At Big Nerd Ranch, we are big fans of Ruby on Rails. We have a lot of production apps deployed on Rails, including our internal work tracking system. To contribute, I needed to up my game in this area. But with regular work constantly beckoning, I wasn’t likely to self-start all the way up to whipping up web apps. I’d tried a few times but gotten lost without a guide.

And let’s be honest—there’s a great danger in complacency. I know more than one developer who helped build a monolith at some company and is riding that monolith to retirement. I’m not knocking it, but that life ain’t for me. I want to build apps in the latest technologies. I want to keep my skills current. Like exercise, it feels good to stretch your brain. And also like exercise, it keeps you young. It’s even better when you’re pushed out of your comfort zone. Like Zork, there’s always another level to conquer.

I found myself in a deep valley west of a large building with an unlocked front door. Going inside, I was greeted by a cavernous room with a huge fireplace made of river stone. The staff quickly and efficiently checked me in and I was directed to my cabin. Once there, I found a big bed, a gorgeous view of the valley and a serviceable internet connection. Truly, this Nerd’s paradise! I spent the evening installing my software so that I’d be ready in the morning. In the night, I was not eaten by a Grue, though I think I might have heard one lurking.

After breakfast, the students assembled in the classroom. The other students were similarly ready; only a few minutes were spent setting up software, and then we were off. The first day was spent on Ruby core concepts, the Rack web server and Sinatra application stack. We got acquainted with our classmates, from places as disparate as Seattle and Orlando. A post-lunch walk held off the afternoon nap attack.

We learned about Ruby’s runtime, and some of the syntax. We created some database tables and made them web-accessible. Picking up the syntax of the Ruby language made this day perhaps the most brain-bending day of all. In fact, it would be relatively natural to write a Zork interpreter to run in Ruby’s shell (irb). The syntax steal sword, from: troll or wind_up clockwork_bird would be simple to implement. At the end of the evening, a nice communal dinner, and off to our private spaces to practice. No Grues or potential Grues sighted overnight.

On day two, we dug into Rails.

Learning Rails

Rails is a gem for Ruby (a gem is a software package; installing them from public repositories is simple) that installs a complete web application. There are easy-to-use components to handle database persistence, authentication and rapid development of API hooks. When you’re in the swing of things, you can build out all the CRUD operations behind an object in just a few minutes, complete with bare-bones web forms, JSON APIs and documentation.

Another notable thing is that Rails has done an admirable job of enforcing a model-view-controller development environment. Basic components of each type can be generated for you. You are encouraged by convention to keep your controllers light (in contrast to iOS, which suffers from controller bloat!). In fact, coding by convention is sometimes a mantra in this community. By automating the generation of boilerplate code, the Rails developer concentrates on just the aspects that make this API’s function different from a generic one of its type.

At the beginning of each chapter, Zac or Blithe would go through some slides about the topic at hand. We built numerous applications to demonstrate one or more concepts. We caught mail. We wrote flexible handlers for HTML or JSON. We modified our database, and then rolled back the changes! And from time to time, we would hear the whizzing sound of someone shooting past the classroom on a zipline. On one of our hikes, I think we might have found the remnants of Flood Control Dam #3, too.

A vast amount of material was covered in the first four days. At the end, we were offered perhaps a dozen optional topics to focus on. I was tickled to get a glimpse at Ruby’s approach to unit testing. And then around midday on Friday, before I really knew it, the class was over and I headed back with my brain full of knowledge. I chose not to listen to music this time.

Home, home on the… server

Upon my return to work, I found that one of the other developers had been chasing a bug in our tracking system’s Mac client, where he appeared to be getting erroneous data from the server. I copied down the server’s source and dug in. After entering a detailed bug report on the issue, I found myself officially working on the tracking system. This was great for me; it means that my newfound Ruby knowledge would be buttressed by practical application.

I might have felt lost in this giant codebase, as if I were in a maze of twisty little passages, all alike. But thanks to a week of class, I wasn’t completely lost. I had a map of sorts. I knew where the models would be; I knew how the views were rendered. With a hint or two from the product owner (a Ruby dev himself), I found myself making contributions to the app! They’re only small things, but the class concepts are being reinforced. And my original goal has been met: I’m ready to quickly spin up a web service to support my mobile efforts.

Work will soon call me back to Objective-C, and I’m slightly torn about that. Now that I’ve figured out the walkthrough, I’m ready to go exploring a while. Plus, if I work the tracking system’s backlog down far enough, I might get to implement my own stories…