Hacker Interview: Aaron Patterson

Aaron, thanks for agreeing to this interview. Would you please introduce yourself?

Aaron: Sure! First off, thanks for interviewing me. I first started programming to meet women, and that didn't work out. Fortunately I found that programming was something I loved to do. I started doing mod_perl in 1999 for Vehix.com (it was AutomallUSA when I started), then moved up to Seattle in 2001 to work for Classmates.com. When I'm not programming, I like to play piano, attend hip-hop dance class, cook, and participate in activities required of me as a member of the Puget Sound Mycological Society.

How did you find your way to Ruby?

Aaron: When I started at Classmates, we were an all mod_perl shop, and we switched to Java. I liked programming in Perl much better because I prefer dynamic languages. Basically, I became a Java programmer that was hoping and praying for Perl 6 to come out. A little over a year ago, I was talking to one of my friends about Perl 6, and he suggested I check out Ruby. I read a bit online, picked up a copy of the pickaxe, and I was hooked.

How much do you use Ruby on a day to day basis?

Aaron: Unfortunately not as much as I would like! Currently at work I use ruby for testing web applications I'm using. When I am developing an application, and I need to do something repetitive, I'll put together a Mechanize program that will do that stuff for me. At home I'll use it for just weird one-off projects, for instance analyzing KEXP's play list for a given month. I also put together a Rails site with google maps integrated so that I could keep track of where I've found edible mushrooms, that way I can return next season.

I've just accepted a new job doing Rails programming, so I should be programming Ruby all day soon!

What other languages are you using?

Aaron: At work, I use Perl (we still have some mod_perl stuff), Ruby, C, and Java. Too much Java. At home I do almost exclusively Ruby programming with some C once in a while. I've switched all of my little scripts at home to use Ruby instead of Perl, just so I could code more Ruby.

Have you looked at JRuby at all? If so, what makes it work (or makes it not work) for you?

Aaron: I have looked at JRuby. JRuby is very cool, but we don't use it at work for a number of reasons. First our application is highly tuned, and JRuby doesn't have the performance we need. I don't really see that as too much of an issue though because we can get around things like that with clever optimizations and more hardware. The main problem is that very few of the developers I work with know ruby. This can lead to *lots* of confusion when working with our code base.

What projects are you working on these days?

Aaron: Currently I've been working on Mechanize, which is a library for navigating web sites. It will manage cookies for you, you can use it to follow links, or fill out and submit forms. You can even have it upload files to websites for you. I'm also working on an iTunes client written in Ruby called Net::DAAP::Client. It will let you interface with iTunes shares, and anything that implements DAAP. Unfortunately the release of iTunes 7 has totally broken my client! I've also been working on a BetaBrite LED sign library, which lets you manipulate BetaBrite LED signs. I think it will work on any sign that Adaptive Micro Systems makes, but I don't have the money to buy all the signs so that I can test! Oh, if only Adaptive Micro Systems would set up a web cam for me!

As far as mechanize goes, could you give us a short example of how you use it?

Aaron: Sure. Recently I needed to populate a test school with lots of users so that I could do some testing, and here is the script I used:

require 'rubygems'
require 'mechanize'
require 'logger'

agent = WWW::Mechanize.new
agent.max_history = 10

1000.times do
  page = agent.get(' http://localhost:8080/registration/registration.jsp?cType=school&communityId=15613381&location=Classmates%20Test%20High%20School')

  page.form('school_info') { |f|
    f.year                = '1999'
    f.birthYear           = '1980'
    f.currentFirstName    = "#{rand_string}"
    f.currentLastName     = 'asdfasdf'
    f.affiliationLastName = 'asdfasdfasdf'
    f.emailAddress        = "#{ rand_string}@classmates.com"
    f.emailAddressConfirm = f.emailAddress
    f.postalCode          = rand_zip
  }.submit

  agent.cookie_jar.clear!
end

You did a great job at RubyConf in your lightning talk on BetaBrite. Other than getting some more hardware (Is anyone at Adaptive Micro Systems reading this? Throw this man a bone!), what's on the BetaBrite horizon?

Aaron: Well, I've tried contacting Adaptive Micro Systems, but was unable to get through the customer service barrier to someone that might be able to help me. However, I have found a place to buy the new BetaBrite hardware which supports more colors and transitions. The new hardware is serial over USB, and hopefully that means faster communication with the sign. Its a good thing I have a day job to buy new hardware so I can test my code!

Coming out of RubyConf, I always find myself with a big pile of new ideas. Which talks inspired you? And, what new ideas do you think you'll be chasing because of them?

Aaron: The presentations at the RubyConf this year gave me more ideas about re-factoring my code than brand new projects. I am just starting a new project that will be a native extension, and the presentation on mkrf made me particularly happy. I have written a couple small native extensions before, and I honestly thought I was the only one who found mkmf hard to use!

Another example of refactoring ideas came from Ryan Davis' presentation on hoe. I am currently going through my projects and converting them to hoe. I have definitely been seeing my Rakefiles get out of sync, and I'm glad to see that someone has taken the time to solve that problem.

Gregory Brown's presentation on Ruport definitely inspired me to try reporting on some of our data at work using Ruport. I'm not part of the reporting group here at Classmates, but I wanted to see how easy it would be to reproduce one of our reports using Ruport. I ran in to a couple snags, but I was able to sort them out and impress a couple guys on the reporting team.

The Seattle.rb seems to have an abundance of really strong Ruby hackers, and really amazing Ruby projects. How do you think being part of that community affects you and your projects?

Aaron: I feel very privileged to be part of a group that has so many strong Rubyists. Having people so talented around me inspires me to constantly improve my skills in Ruby, which I hope gets reflected in the projects I work on. Also, having people like that around is an invaluable resource. I try to attend each weekly meeting so that I can ask questions, get new ideas, and hopefully give other people new ideas. Seattle.rb is definitely one of the best user groups I have ever been a part of!

Outside of your own, what are your five favorite Ruby libraries?

Aaron: My top five has definitely changed since RubyConf! In no particular order:

• RubyOSA. I have been playing with this library every day since RubyConf. I love it!
• mkrf. I was dreading coming up with an mkmf script for the project I just started and mkrf made my life much easier.
• hoe. I am in the process of converting my projects to hoe. Hoe is another library that is making my life easier.
• heckle. Ryan Davis gave a presentation on this at RejectConf. It is like Jester, but for Ruby. This is very cool stuff.
• rcov. This library encourages me to test all of my code. I really like utilities that encourage me to test. Especially if they involve progress bars and percentages. I like making the progress bars go up, and that improves my testing, so we all win!

Speaking of rcov, what do you think about the claim some people are making that code coverage gives developers/projects an unrealistic sense of security in their tests?

Aaron: I think that relying purely on code coverage to determine whether your software is tested or not is a problem. Code coverage is not an indicator of good testing. Just because the code was run doesn't mean it was tested, or even tested correctly! That is not to say that code coverage isn't important. I find it is a useful tool in my testing toolbox, but it is not my only tool. As long as developers know not to rely just on code coverage, then there isn't a problem. Fortunately, I haven't met any developers like that, so this seems like a non-issue to me.

Code coverage can't guarantee you are fully tested. But neither can fuzz testing, or heckling, or any other method. I don't think you can ever be sure that your code is completely tested, but using all of these techniques together can help increase your confidence.

From your perspective, what should the Ruby-core team be focusing on in the upcoming year?

Aaron: Unicode. Tim Bray gave an excellent speech at RubyConf which convinced me that Unicode is one of the most important things the Ruby-core team should be working on. I don't agree with removing methods like upcase or downcase, but I definitely think we need better Unicode support.

What's next for you?

Aaron: I am currently working on adding Javascript support to mechanize. This is something that I know a lot of people want (including myself), and I want to get something out there. I know this is a very ambitious project, but I've been toying around with a few ideas about how to get it accomplished. I will support Javascript at some point, hopefully sooner than later!

Technorati tags: Ruby interviews