Author Interview: Assaf Arkin and Jeremy McAnally

With the publication of the first four chapters of their new book, “Ruby In Practice”, through the Manning Early Access Program (MEAP). Assaf Arkin and Jeremy McAnally have been kind enough to answer some questions about the book, Ruby, and themselves. You’re welcome to join our discussion here, or you can buy the book and join the Manning Forum for Ruby in Practice and discuss the book there. As the more of the book is published through MEAP, Assaf, Jeremy, and I will take some more opportunities to talk, so if you have questions you’d like to ask, please let me know.

---

Hey guys, I just got the first MEAP release of your book and I’m loving it so far. Thanks for taking some time to chat with me about it. Let’s dive right in to some questions:

1) It’s obvious that you guys are taking a different approach to writing about Ruby than most people (no Ruby Tutorial, no ‘How do I install a gem’ section, etc.). Why did you choose to go this route?

Assaf There are books that teach you Ruby, I personally recommend the Pickaxe, I don’t think we need another one. For a lot of people, I happen to be one of them, the first obstacle is not learning the language itself, but learning to use the language to solve specific problems. It’s easier to learn Ruby and be productive when you’re seeing examples for real life problems, like generating a report, or parsing an XML document, or using a Web service, so that’s the approach we took with Ruby In Practice.

Jeremy It was really at RailsConf that I think we decided to pull a lot of the introductory stuff we had in there. We had a lot of “learning Rails” type stuff with some introductory Ruby coddling, but I was really struck at RailsConf how many Ruby books I saw at the book store at the conference and later at the mall. I usually keep pretty on top of the book market, and there were 3-4 that I’d never heard of. The market was finally robust, and so I saw no need to duplicate effort.

Even further, the original vision of this book was “I know Ruby, but now what?” We wanted to fill that gap. We also wanted to partially try to answer “Who cares?” also, but to a less extent. In a nutshell, we wanted to write a book that people could use right after they read Ruby For Rails or the Pickaxe or Learning Ruby or my book. I know a good number of programming languages fairly well, but I see no business sense in them. We want to instill that knowledge in our readers: “Yes, Ruby can be used for your problem, and here’s how.”

2) No book can cover everything. What are some Ruby things you wanted to talk about but just couldn’t fit into the book?

Jeremy We originally covered a lot more of the “why” for Ruby, but after reviews and actually reading what we wrote (haha! novel!) we decided that it didn’t fit. This is a manual designed mostly for developers, architects, or hybrids thereof, so we wanted to make sure that’s who we focused on.

I, personally, would also like to spend more time on the Ruby language, but this is a “practical” manual rather than a “language” manual so it didn’t really fit.

Assaf You can write an entire book on XML processing with Ruby, or Web services, or Ruports and PDF::Writer. The hard part is picking a handful of examples to show basic usage and more advance techniques, and fitting that into a single chapter. Besides covering all the different ways you can use a given library, there’s also a few things we won’t be able to fit into the book, but can’t list those until we’re done with the book.

3) In your first chapter you run through some of the Ruby idioms and features that really make the language shine. Where would you recommend readers go who feel that they need more information on these topics?

Assaf Have a look at other people’s code. When I started with Ruby, a lot of the concepts like writing a DSL or using method_missing were abstract. It was interesting to learn, but it only became practical when I looked at other people’s code and learned by example how, when and why to use them. And thankfully, Ruby has a lot of open source code you can look at, and your options range from Rails (a lot of good ideas in the code) to blogs that deal with one specific use case at a time.

Jeremy The Ruby Way and Ruby For Rails. Hal’s book is a given, but David’s chapter on the dynamic features of Ruby is top notch in my opinion. I still feel like there’s a gap in “advanced” Ruby knowledge to fill, and I hope to be involved in a project that fills it in the future (but we’ll see).

4) In Chapter 2, you guys provide the first coverage of RSpec and Heckle that I remember seeing in a Ruby book. Why did you choose to cover them alongside test::unit?

Assaf Testing is about specifying how the code should work, and then making sure it behaves that way. Rinse, repeat. You want to express tests in the most natural way, and RSpec does just that. But RSpec comes from the ability to have open classes and extend objects which works for Ruby; in languages like Java and C++ you don’t have that capability, so the best you can do is write assert statements. Assert statements are not the way to write tests, they’re just a compromise made by the limits of the language. Still a lot of people move between Ruby and other languages and already know the xUnit way of testing, so it makes sense to teach both at the same time.

Jeremy More and more I’m finding that people know Ruby, but don’t test. The paradigm doesn’t make sense to them: why am I asserting things about code that doesn’t exist yet? The BDD paradigm makes more sense: you’re defining behavior, discussing things that “should” happen, and so on. So, I think for those coming to the book with knowledge of Ruby but aren’t testing yet, covering RSpec might be a breath of fresh air.

As for Heckle, I’m finding that even in my own code, my tests are weak. Since I’ve been heckling, I start thinking a lot more carefully when testing. We included the section on heckle primarily because it’s such a darned useful tool for rooting out bad tests!

Assaf Heckle is testing our tests :-)

5) I also enjoyed Chapter 3’s discussion of integration. It seemed to have a lot less code than I would have expected, but I think it covered integration better because of that. What prompted you to write the chapter the way that you did? Will we see more of this kind of writing in future chapters?

Jeremy One reason was that a lot of these systems have a lot of code running in them (most of it code that can’t be released publicly…), but also we wanted to setup the rest of the book. The main thrust of the chapter is that you take ideas from it and then apply it to the technologies we teach you in the book. We give you some strategies you can enact combined with the practical content later on to solve some pretty big problems.

I think when/if we write an appendix on tighter integration with things like JRuby and IronRuby, you’ll see more code. If we don’t get to that, then it’ll be on the blog probably. :)

6) Chapter 4 continues to take a different perspective on things with it’s coverage of Rails. I really would have liked to see some coverage of Merb as an alternative to Rails … Any chance something like that might show up the book’s blog? What kinds of things do you plan on writing on the blog?

Jeremy We have a lot of stuff we cut out of the book that will likely end up on the blog. The “why” material discussed earlier, some unused Rails stuff, and, yes, some alternative web framework coverage (I believe we have a Camping section written and part of a Merb one that is rather out of date). Once the book it totally finished, we’ll start releasing that stuff. :)

Assaf Think 80/20. We can’t possibly cover everything in a single book, so some things are unfortunately left out, but hopefully we’ll give people enough taste of Ruby that they’ll go out and experiment with more Ruby libraries, beyond those we could cover.

7) Anything else that you guys would like to say to prospective readers?

Jeremy Enjoy. Enjoy life, enjoy Ruby, enjoy the book, and please enjoy giving us some feedback on the author forum so this book rocks that much harder when it comes out.

Oh, and write tests, Haskell, YAGNI, Agile, SCRUM, spec, Rails, Web 2.0. I just wanted to make sure that this answer at least had something to do with software development.

Assaf Write a lot of tests, have a look at RSpec and RBehave, they make test writing fun which is the most important feature in a testing framework. Learn not just the language, but the whole philosophy behind Ruby; you’ll get much more from keeping your code simple and DRY, avoiding premature abstractions and YAGNI, than any programming technique or feature. Don’t be afraid to scale out, and don’t be afraid to use the command line and mix languages.