MWRC 2009 Mini-Interview: Philippe Hanrigou

This will be the last mini-interview before MWRC 2009. Philippe Hanrigou (@ph7) has been kind enough to answer a few questions on the topic of his presentation — "What The Ruby Craftsman Can Learn From The Smalltalk Master". Read on to get a taste of what Philippe will be covering in just ten more days. Oh, and if you haven't registered yet, there are just 4 more days and about 40 more seats. Don't wait any longer, go register now!

---

Your talk at last year's MWRC was pretty incredible. How are you going to top it this year?

Philippe Well, first thank you. Every presentation is a new experience, and I believe people will end up quite excited about this one since

• The subject should appeal to a wider audience — it touches the core of our craft: software design.
• I am standing on the shoulders on giants. In my mind Kent Beck is one of the software grand masters with the most comprehensive, genuine, and inspiring understanding of the software craft. So simply relaying some of his wisdom as it applies to Ruby should be quite incredible in its own way already.

Rubyists seem to spend a lot of time looking up to the Smalltalk masters, why?

Philippe Smalltalkers were writing Object-Oriented software in a dynamic, interpreted duck typed language 20 years ago. It would be amazing if there wasn't something to learn.

It is also quite notable that the Smalltalk community has been incredibly talented, innovative and creative in pushing the software craft to the next level. Most of the best techniques we use today to develop software are rooted in the Smalltalk community: test-driven development, refactoring, design patterns, core object-oriented principles, pair-programming, emphasis on short an efficient feedback cycles, ... just to name a few! So any sensible software developer would look up to the Smalltalk community, whatever programming language or platform he/she is using.

I actually believe that we do not learn enough from the experience, errors and innovations of the programmer generations and communities that preceded ours — even the Ruby community, which is better than most in this regard. Unfortunately the "Not Invented Here" syndrome, does not just apply to our code, it also applies to ours practices. We have a tendency to "rediscover" the same errors and bad practices over an over again. Rails' original take at testing and test data management is a good example in this regard. So looking up to the best software masters is a great and healthy thing!

What other language's practitioners should we be learning from?

Philippe We can learn from countless people, fields and languages. For instance, there is a lot to learn from the LISP community, especially in terms of elegance, meta-programming and its unsurpassed emphasis on "programmable programming language".

Nevertheless, programming is before all, an exercise in communication, creativity and human interaction. So some of the most interesting things to discover are probably to be learned from communities that do not write any software at all: either from communities facing similar challenges (artists, designers) or from communities that have been studying these topics from a different angle (ethnologists, sociologists, historians). Brian Marick gave a wonderful piece of advice on how we could approach this learning experience in one of his recent blog entries:

"It seems to me that I’m not so much someone who’s come up with any great new ideas as someone who’s good at looking at the familiar from an odd perspective. I get that odd perspective from reading odd things, such as sociology of science or literary theory, and asking “Suppose this point of view were true: what would it mean for building software?"

Sometimes, it seems like our interest isn't reciprocated. What can rubyists teach smalltalkers?

Philippe The sad part about Smalltalk is that its most prominent leaders have been programming in Java for the last ten years. The main thing we can teach smalltalkers is a message of hope. Dynamic languages are coming back in the front scene and this will benefit all of us! Thanks to Ruby marketing and promotion, dynamic languages are now perceived as as a competitive advantage not only by programmers, but also by CEOs! Ruby has an impactful story that extends beyond its technical merits and also appeals to decision makers — In great part due to David Heinemeier Hansson's marketing genius and his emphasis on the productivity message, which makes sense to business people too.

I believe smalltalkers could also benefit by keeping an open mind and using Ruby as a way to challenge some aspects of Smalltalk design that they love so much, like radical language symmetry.

New programming languages or platforms have almost no features that, in isolation, are really new. It is a lot more about picking the right set of features and mixing the right blend. This is an art in which Matz is especially talented, and which gives Ruby a feel that appeals to a much broader audience:

Some may say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But it is nicer to ordinary people.

Consequently Ruby and Smalltalk have very different tradeoffs in terms of naturalness versus symmetry, or in terms of beauty versus expressiveness.

To be honest, I do not expect smalltakers to let go of their radical commitment to minimalism and symmetry: it is too much core to their culture and one man's expressive code is another man's nightmare. Nevertheless, there is something to be learned from a different set of tradeoffs and Matz's pragmatic approach to language design. I personally find Ruby even more expressive than Smalltalk, a characteristic I directly attribute to Ruby's decreased emphasis on keeping everything "pure" and symmetrical, as well as reaching a better tension point between functional and object-oriented programming.

What do you think makes MWRC a good place for Rubyists to gather?

Philippe Last year was my first time attending MountainWest RubyConf and I was blown away by the high quality of talks and corridor chats, the organizers' kindness, the flawless program execution, and even more importantly, the conference's strong and engaging human dimension.

So if you are into expanding your mind and knowledge, meeting great people, or passionate debates on Ruby and software, MountainWest RubyConf will blow you mind. Huge kudos to all the MountainWest organizers for making it happen!

---

Related Posts

• Philippe Hanrigou Interview (and more troubleshooting hints)
• Troubleshooting Ruby Processes

Click here to Tweet this article

Philippe Hanrigou Interview (and more troubleshooting hints)

I reviewed ‘Troubleshooting Ruby Processes’ last week. Since I really liked it, I decided to take a little bit of time to talk to Philippe about it. Fortunately, he was gracious enough to answer my questions. If you’d like to grab a copy of his shortcut for yourself, you can buy one here. Philippe passed along a bunch of great hints and links that aren’t in his book, but you can read them all below.

---

You focus on three great tools, what three tools would you have included if you had more time/space/expertise?

Philippe DTrace would be at the top of my list. It is the only tool that can give you a dynamic and integrated view of the entire software stack: from external devices activity, to operating system dynamics, to the behavior of your Ruby code. This alone is a killer feature that gives you tremendous insight into the holistic behavior of your software stack. In addition, DTrace is a blessing to use in a production environment: it can always stay on, has zero overhead when not in use, and can enable or disable debugging probes in real time on a running kernel. In short, DTrace should be your troubleshooting tool of choice if you deploy Ruby applications on Mac OS X, Solaris or BSD. Unfortunately, due to publishing timing constraints, I was unable to include a chapter on DTrace in my short cut. I plan to publish a detailed article on DTrace early next year though, so stay tuned. In the meantime, Joyent’s examples provide a good starting point for Ruby and Ruby on Rails developers. Big kudos to the Joyent guys for all their work on Ruby DTrace instrumentation.

Another technique that I would love to document is how you can instrument the Ruby interpreter yourself with some minimal ad-hoc tracing code to target a specific problem. Inject your code at a well-chosen spot, recompile Ruby, rerun your program with your freshly instrumented interpreter… and get your questions answered! Obviously, this approach does require some understanding of Ruby internals but this is not as scary as it might seem. Eigenclass’s Self-study guide to the sources, Patrick Farley’s blog and the Ruby Hacking Guide are good resources to demystify the (presumed) complexity of Ruby internals.

There are tons of other powerful tools that can also be used to troubleshoot Ruby applications’ traditional ecosystem, most notably the network and the database. These tools are already fairly well-documented though, so if I had time to document yet one more thing, I would concentrate on visual tools built on top of DTrace such as Chime and Instruments.

If you were going to write a JRuby version of this book, what tools would it include?

Philippe I must admit that while I have an extensive Java experience I have limited exposure to JRuby at this point. Ola Bini graciously lent me some of his expertise on this topic, which I combined with some helpful tidbits below:

In most cases, the tools that are useful for JRuby are the same ones that are useful for troubleshooting any Java application.

In particular, the JVM’s thread dump feature is a powerful introspection mechanism for investigating dead-locks and understanding your application dynamics. Since Ruby threads are also Java threads in JRuby, you can tell a lot from a JVM thread dump. When you start the JVM with one of the -XX flags you even get a Java histogram as part of the thread dump.

On the other end of the spectrum, the easiest way to investigate a problem with JRuby is often to directly change the JRuby code, either by adding logging or a Java exception at the right spot and then rerunning the faulty code. This is surprisingly easy and terribly efficient!

JRuby also includes some support for helping with dumping runtime information. Say that you want to keep track of how often a specific piece of code is reached during runtime, you can do something like this:

    Map rt = getRuntime().getRuntimeInformation(); 
    Integer count = (Integer)rt.get("SomeInvocationCount");
    if (null == count) {
        rt.put("SomeInvocationCount", new Integer(1));
    } else {
       rt.put("SomeInvocationCount", new Integer(count.intValue()+1));
    }

Everything in RuntimeInformation will be automatically dumped on exit. By combining this technique with instrumenting JRuby to provide additional logging or to raise exceptions, most of the time you get a fairly good grasp on what’s going on.

JConsole) is another standard Java tool that proves to be very useful in the context of JRuby development. You can use it to attach to a running process and then inspect memory usage, GC statistics, existing threads and so on. Besides, JConsole can also be used to trigger a lot of interesting JMX events.

Finally, when it comes to memory leaks, the usual Java tools also come to the rescue. A useful technique is to get a heap dump with jmap and then inspect it with jhat or any standard Java heap dump analyzer. Give the SAP Memory Analyzer a try—Ola had a great experience with it.

What kinds of troubleshooting/development tools do the Ruby community need to develop to ‘take the next step’?

Philippe I believe that the Ruby community would benefit a lot from having a robust thread dump tool for MRI. The thread-dump project got started on this, but the current implementation does not seem to work on any of the platforms that I have tried it on. At this point, I am determined to implement a robust thread dump tool myself, and I would gladly welcome help from the community. Contact me if you are interested in participating.

There is also a whole ecosystem of powerful tools that could be built on top of DTrace. Using DTrace probes as a foundation, you could build powerful visual tools each specializing in a particular task, e.g. profiling, performance analysis, memory leak detection, etc. These tools could potentially give you a holistic view of your system including your Ruby code but also your operating system, the network and the database. This is an area where the Ruby community can really shine as it can be done in pure Ruby, and no specific system or interpreter level knowledge is required.

For the most hardcore members of the community it might be worth investing some time and energy to help push SystemTap forward. Unfortunately, while many Ruby applications are deployed on Linux, DTrace is not available on this platform. Due to licensing and unresolved issues there is actually very little chance that DTrace will ever be ported to Linux in the foreseeable future. The closest alternative to DTrace on Linux is SystemTap, which shares the same objectives but is not quite as mature yet. In particular, SystemTap still does not seem to provide support for traces in user space programs. So SystemTap could use some love before bridging the gap between Ruby programs and the operating system.

Finally building troubleshooting tools for Ruby would be a lot easier if any Ruby developer could easily access the Ruby interpreter to instrument and extend it. This is why I consider the success of a project such as Rubinius to be the best way for take the platform to a whole new level in the long term. Any time and effort that the community invest in Rubinius will be well spent.

If you want to read more about Rubinius, you might take a look at my collection of Rubinius posts.

---

Related Posts

• Troubleshooting Ruby Processes
• MWRC 2009 Mini-Interview: Philippe Hanrigou