The trial batch of our new course “Ruby Metaprogramming” started recently. On this occasion, RubyLearning caught up with author Paolo Perrotta (who is writing the book “Metaprogramming Ruby“) and chatted with him.
Satish>> Paolo, could you tell us something about yourself – your background, where you are based?
Paolo>> I’m an Italian developer entering his 40s. I always worked as a freelancer, so I have a pretty colorful curriculum by now. Amongst other things I worked on computer games for Valve, I was on the Hibernate Object-Relation Mapper team, and I came very early to the agile methodologies party. At the moment, I’m coaching agile teams at Yoox, a wonderful Internet fashion boutique. I’m based in Bologna, Italy – roughly halfway between Florence and Venice.
Satish>> How did you learn and get into Ruby Metaprogramming?
Paolo>> At first, I got into metaprogramming for the tricks. After years of Java, Ruby kept surprising and delighting me. “I can catch all the calls to this object, add this parameter and route them to this other object… all in a single line of code! Cool!” So that’s what got me into metaprogramming at first: the power to refactor complex, duplicated pieces of logic into a few lines of elegant code.
When I grew more experienced, I started to see patterns emerge out of Ruby. I realized that metaprogramming sits at the very heart of the language, and when you understand metaprogramming, that’s the moment when you start “thinking in Ruby”. So I’d say that I got into metaprogramming for the cool tricks, and I stayed there because I realized that you need to know and use metaprogramming if you want to be a native Ruby speaker.
Satish>> Why did you choose the topic of “Ruby Metaprogramming” for your first book?
Paolo>> When I got past the initial “falling in love” stage, I found that Ruby could trip me up sometimes. On the surface, it looks like a dynamic version of Java or other object-oriented languages. But dig a tad deeper, and you find so many differences, so many questions. How does the “private” keyword work? What happens when you include multiple modules? Why can’t I ever get scopes right? And so on.
After fighting with these questions for a while, I found that I could answer all of them by understanding the principles behind the language. If you “get” the Ruby object model, then there is no question about “private” or modules anymore – everything suddenly looks obvious and elegant. But there was no single source I could tap into to learn this kind of information. To piece the Ruby puzzle together, I had to hunt around for blog posts, articles and pieces of source code.
So, this is the book I wish I could read when I was learning Ruby. It gathers that knowledge together in a single place, and gives names to techniques that don’t have any common name yet.
Satish>> Why did you write this book – what was your motivation?
Paolo>> All programmers know how satisfying it is to deploy something big and complicated. After focusing on the minute details for so long, you step back, and you see the system as a whole, finally complete and useful. That’s also the reason why I wrote a book. Now that it’s in review, it’s nice to step back and see people reading it, and telling you it’s useful to them.
And then, of course, there’s the obscene amount of money! (Just kidding).
Satish>> Who’s the audience for your book – Metaprogramming Ruby?
Paolo>> It’s billed as an advanced book for Ruby experts, but the reviewers are telling me that anyone with working knowledge of Ruby can read it and learn the techniques. I had Ruby beginners read it and enjoy it a lot.
Satish>> I know that it is too early to say, but looking back are there some topics that you now wish should have been covered or dropped from the book?
Paolo>> As you write, you learn that the more you cut away, the better is the final result. It’s the same with code: the shorter the better, as long as it’s still as clear as it can be. I dropped a lot of unnecessary details, but I wouldn’t look back. If I had more time, I’d make it even shorter.
Satish>> Anything else you would like to add?
Paolo>> Just one thing: Remember that as cool as metaprogramming is, it’s just a tool, with its own set of trade-offs. Sometimes it makes your code clearer and more concise, sometimes it makes it more rigid and obscure. You should really know about metaprogramming, but that doesn’t mean you have to use it all the time. Resist the temptation to overuse it, and always weigh it against more traditional techniques.
Oh, and have a nice Ruby Metaprogramming course!
Thank you Paolo. In case you have any queries and/or questions, kindly post your questions here (as comments to this blog post) and Paolo would be glad to answer.