A weekly series from the Ruby Masters

Welcome to the next installment of the weekly interview series on the RL blog – “Path to Ruby Mastery” – by top trainers and developers in the Ruby community, from across the globe. The interview series will provide insight and commentary from these notable Ruby trainers and developers, with the goal of facilitating and providing answers to the questions Ruby beginners face. We welcome your suggestions for interviewees and questions. Look for a new post every Tuesday!

This week, we’re happy to have Ian Dees from USA.

Satish Talim>> Welcome, Ian and thanks for taking out time to share your thoughts. For the benefit of the readers, could you tell us something about your self?

Ian>> Hi. I’m a software developer working for a test equipment company near Portland, Oregon, USA. I started programming for fun in 1986, and for pay in 1996. Projects have ranged from assembly code running on bare metal, through embedded systems and desktop software, all the way up to high-level test code and Web applications. Outside the office, my obsessions include my beautifully chaotic family, bicycles, guitars, books, coffee, and cooking. I’ve written a book, “Scripted GUI Testing with Ruby,” published by the Pragmatic Programmers.

Willian Molinari, Brazil>> How should one go about learning the Ruby language? What material (books, eBooks, online tutorials etc.) would you recommend?

Ian>> The best way to learn Ruby is to write it. My first Ruby program was an entry in a programming contest. That code turned out clumsy, verbose, and non-idiomatic, but writing it taught me a lot of the quirks of the language.

So I’d say work your way through a tutorial or two, then look for a programming challenge to have fun with. Here are a few code challenge sites (some are focused on other languages, but there’s no reason you couldn’t solve them in Ruby as an exercise):

• http://perl.plover.com/qotw/
• http://codekata.pragprog.com/
• http://www.devx.com/DevX/Door/17707

As for reading material, _why’s Poignant Guide to Ruby is a great way to soak up the Ruby atmosphere. That plus the official Ruby reference docs should get you off to a good start.

Jerry Anning, USA>> Can you recommend things to study after learning Core Ruby, including different frameworks, gems and external libraries?

Ian>> Tempted as I am to give a “Great Moments in Ruby History” spiel, I’d recommend seeing what libraries you end up depending on most in your own apps, and peeking behind the curtain to see how they tick.

For example, we use the Camping library at work to drive a couple of status pages on our build server. I ended up cracking open the unabridged version of the source to diagnose a problem, and was rewarded with a crisp, thoroughly documented treat of metaprogramming.

Satish Talim>> Most beginners in Ruby, would like to contribute their time, skills and expertise to a project but invariably are unaware of where and how to do so. Could you suggest some?

Ian>> Ruby has a way of leading people on a natural path to becoming contributors. First, you happen to use a library for a while, and maybe ask a question on the mailing list. Then, you notice a bug and submit a ticket. In the meantime, you find a way to fix the problem on your own machine. You submit a patch. Next thing you know, you have commit access, are listed as a core contributor, and are answering mailing list traffic daily on three different projects.

The best part is that this all seems to happen on its own, just as a byproduct of using and loving Ruby. That said, if you’re looking for something specific, the Rubinius project is actively seeking contributors of varying skill levels.

Keith Brady, Australia>> What are the pros and cons of Ruby that are being discussed in the development community and what is your opinion on that?

Ian>> Matz has said that his goal in creating Ruby was to optimize for programmer happiness. The language’s advantages and disadvantages stem from that decision. Ruby has an Algol-like syntax for familiarity, dynamic typing for “sketchability,” a little bit of Lisp’s and Smalltalk’s power so that enterprising coders can extend the language, and a few of Perl’s shortcuts.

On the downside, optimizing for the programmer has meant that interpreter implementors have traditionally had to make performance sacrifices (though see the obsessive effort that has gone into making Ruby 1.9 and JRuby faster). And Ruby doesn’t support quite the level of on-the-fly modification of programs that, say, Smalltalk and Lisp do.

Willian Molinari, Brazil>> What has been your biggest challenge while working with Ruby?

Ian>> Limits, both mine and Ruby’s. For me, meta-programming — programs writing programs — introduces tons of new things to keep track of. When you’re handing off code that’s not going to run until much later on, in a completely different part of your program (or someone else’s program!), will it have everything it needs to execute? I’m less than a week away from going back to grad school to learn theory of computation, so I can keep some of this stuff straight.

As for Ruby’s limits… it seems like it’s human nature to run straight to the end of what any particular language feature (e.g., blocks) can do, and almost immediately bump our heads against the edge cases. There are a lot of coding shortcuts we could take more safely if we had something like Lisp’s macros. Keep an eye on the work Reg Braithwaite has been doing on this subject.

Satish Talim>> What can / should job candidates (for Ruby) do to distinguish themselves from their competition?
Note: The candidate has done his/her homework on the company that they are interviewing with. The candidate understands what they’re looking for, and the candidate is prepared to show them that he/she fits the bill, based on the candidate’s skills and experience. What else can the candidate do, to set themselves apart from other equally well-qualified and well-prepared candidates?

Ian>> My current job wasn’t specifically a Ruby job when I interviewed for it, but here’s a principle that transcends languages:

Have a portfolio. Work on some open-source projects, and show your prospective employers the contributions you’ve made. (Hopefully, you’ve found a project that’s meaningful to you, speaks to your passions, and isn’t just resume filler.) If that isn’t an option, sketch out screen mockups of the closed-source apps you’ve built. For each one, talk about how it challenged you and what it taught you.

Satish Talim>> Do you have any other suggestions for these participants (would-be Ruby developers)?

Ian>> Aim for MINASWAN (Matz Is Nice And So We Are Nice).

Satish Talim>> Thanks Ian for sharing your views with the RubyLearning participants.

On 25th Nov. we talk to Bruce Tate from USA.

Disclaimer:
The opinions expressed are those of Ian Dees and do not necessarily reflect those of www.RubyLearning.com.

The Path to Ruby Mastery Series (So Far):

• #1: Jamie van Dyke
• #2: James Edward Gray II
• #3: Dr Nic Williams
• #4: Stuart Halloway
• #5: Jay Fields
• #6: Chris O’Sullivan
• #7: Guy Naor
• #8: Jonathan Conway