InfoQ's Rob Bazinet and Matthew Bass had the opportunity to talk with Jeremy McAnally, about the book he co-authored with Assaf Arkin, "Ruby in Practice". The book is not for the beginner looking to simply learn Ruby but for the Rubyist seeking more detailed guidance on specific topics. The publisher describes the book:
"Like Ruby itself, "Ruby in Practice" will make you more productive. The book shows you practical techniques and strategies for small projects and large-scale environments. A cookbook-style reference, it gives you concrete examples of systems integration, messaging, web development, and databases, all in a clear problem/ solution format."
The interview is accompanied by Chapter 5 : Web Services from the book. The chapter covers Service Oriented Architecture (SOA) using Ruby, creating SOAP and RESTful web services along with working with legacy applications. The information covered in this chapter is often some of the most common use cases for Ruby today.
InfoQ: Who are you and what is your background?
Jeremy McAnally (JM): My name is Jeremy McAnally. I currently work at entp (entp.com) doing Rails and some iPhone development, but my background is a diverse mix of stuff including VB, .NET, PHP, and Python. These days I hack mostly on Ruby and Objective-C, but I'm venturing into some other fun languages like Scala, too.
InfoQ: What inspired/prompted you to write "Ruby in Practice?" What need were you trying to fill?
JM: As I went to conferences and talked to others who were learning Ruby, I found a lot of people asking one of two questions: "Why learn Ruby at all?" or "I know Ruby...now what?" It's a fairly big knowledge gap in most programming communities, and I think we answer both questions pretty successfully. If you think we don't, then please contact one of us; we'd be glad to discuss it further!
The latter question is especially paralyzing. It's really difficult to know where to start, and so the biggest goal of the book was to give you a kickstart with real examples. We didn't want to be just a plain ol' how-to/cookbook Ruby book; we wanted to show you how to actually use these techniques in their environments and contexts through clear explanations and substantial code.
InfoQ: How have you distinguished the book from other Ruby how-to guides?
JM: The biggest factor is that we don't just give contrived examples like some cookbooks (not all of them, mind you!). All the major examples in the book have tests with them in our code repository, and each technique has a starter example (to give an idea of how to use the library) and a follow-up, real-world example that shows why or when you would use it. Most of these real world examples are actually either extracted from real projects or at the very least based heavily on code that we've written in real projects before.
Another benefit is that we've pulled in contributors to lend a hand in their areas of familiarity. While Assaf and myself have a lot of experience, we felt that pulling in people with either a specialty (like Greg Brown who actually wrote the reporting library we discuss in the book) or those who have a lot of substantial experience (like David A. Black) would give a new flavor and depth to the book that you can't really get any other way. Their contributions are enormous, and I really think it made the book that much better to have their voices in the mix.
InfoQ: The book talks about Ruby being a good "glue" or integration language. What is it about Ruby that makes it so ideal for this use?
JM: Ruby is a great glue language for a wide range of reasons. First of these is the immense flexibility of the language itself. Between its ability to create beautiful DSLs that can be used to wrap up ugly APIs to its beautifully easy integration with C (and Java and C# and all those other awesome languages on VMs that support Ruby), it's the perfect choice for tying other components together in a language that doesn't hurt.
Second, it has a great toolkit around it. Tools like Rake, curb, Rails, and so on make it very simple to use Ruby to integrate a lot of disparate systems in nice little scripts and even into bigger systems. Combine that with the ability to directly integrate with other languages, and you have an incredibly powerful tool to rapidly develop that 10% of typically annoying code to tie things together.
InfoQ: Is this book best for independent consultants/freelancers or programmers looking to use Ruby in a large enterprise/corporate environment?
JM: I think both groups can really learn something here. It's a fairly general Ruby manual, but we do cover topics that would be especially useful to "enterprise" developers.
InfoQ: You mention Ruby as being useful for "Enterprise" developers. How do you see enterprise developers using Ruby?
JM: Of course, Ruby excels at scripting and gluing pieces together, but I don't think it's stuck in that box. I honestly think that you can build almost anything in Ruby. My philosophy is to build it in what's expedient and then re-implement in what's "optimal" (for some definition of the word) from a performance perspective only when you need it. This is why even when I've built really large systems, I've typically started in Ruby (or a mashup thereof).
Now, if your requirements are serious performance, then what's expedient in that situation might be a high performance language (i.e., not Ruby). But in general, Ruby can accomplish any task.
InfoQ: Enterprises are often hard to change. How do you think developers in an enterprise could bring in Ruby to an environment otherwise ruled by Java or .NET?
JM: A lot could be said about this (there are literally books on this exact topic), but I'll suffice to say this: show them with code. Just start using it where possible. So maybe you waste 15-20 minutes writing that script in Ruby because management reject it, but the fact you wrote it in 15-20 minutes will stick with them next time they need a script really, really quickly.
InfoQ: Is Ruby capable of integrating very well with existing Java (J2EE) or .NET applications and what facilities are available in either Ruby or third-party libraries to help with this task?
JM: Yes. We talk a little about this in the book, but you can use IronRuby and JRuby to integrate pretty tightly with most Java or .NET systems, respectively. I haven't done a lot with IronRuby honestly, but I've heard good things. I have, on the other hand, used JRuby quite a bit, and I have to say it's a solid product. I highly recommend it if you're doing anything with Java (and even outside of integration with standard Java, deploying apps with it is super easy thanks to the mature Java toolsets).
InfoQ: Ruby on Rails is the web framework that really made Ruby popular, brought Ruby to the masses. Do think there is room for another great web framework > to be created to be then next Ruby on Rails? If so, what do you think that framework would look like knowing what you know about Rails today?
JM: I think we have a pretty diverse set of web frameworks out there for Ruby, but there's always room for more. I'd especially like to see some departure from the standard MVC paradigm, since Rails does an excellent job of covering that (on a large scale at least). Sinatra does a great job with small scale stuff. But we need a solid continuation based framework or something like that. I'm not sure I really know what something "next generation" would look like, but I'm excited to see what the super smart hackers out there come up with.
InfoQ: What value do you see in all of the different Ruby implementations we hear about; Rubinius, MacRuby, JRuby, Ruby 1.9.1 and IronRuby? Are these good or bad for Ruby as a language?
JM: I think each implementation brings something to the table (JRuby has Java integration, 1.9 has speed and extra features, MacRuby has excellent speed and Mac integration, etc.). Though, I'm wary of "forks" (e.g., MacRuby adding Obj-C dispatch type stuff) only because I like the fact that I can run Ruby code anywhere (not just on one VM). But I think these language additions make total sense on the whole.
InfoQ: Where do you see Ruby going in 5 years?
JM: I'm not sure. Looking back at previous interviews and writings, I think my predictions have been fairly accurate about Ruby's projection thus far. The interesting thing is that we're sort of at a crossroads for the language. We've conquered the web. But now we're breaking out of the web and, thanks to tools like Adhearsion, nanite/vertebra, Archaeopteryx, we're looking at other venues to display how much Ruby rocks.
Biggest idea of the next five years? I think we'll see Ruby on iPhone through MacRuby (once they get garbage collection on there). That would be a huge win for Ruby and for iPhone. Writing applications is already stupid easy thanks to XCode and Interface Builder. Throw in a language like Ruby and we could see a huge boon in application development.
InfoQ: Thank you Jeremy for taking the time to talk with us today about your book.
More information about Ruby in Practice can be found on the Manning web site where additional chapters are available for review. Manning Press has been kind enough to offer InfoQ readers a 40% discount on Jeremy's book, "Ruby in Practice" using code "ruby40" (expires 6/19/2009).