Author Interview: Jeremy McAnallay - Ruby In Practice

With the recent release of Ruby in Practice, I've contacted both Assaf Arkin (@assaf) and Jeremy McAnally (@jm) to do some interviews about their book. These will be posted on my best posts about the best books page.

I posted Assaf's Interview last week. Here's what Jeremy had to say.

---

This book has been a long time coming, how does it feel to see it finally hitting the book shelves?

Jeremy I don't think I can explain the feeling. I imagine it's similar to having a child, except mine is made of paper. So...awkward.

If you had a chance to start it today, what are the big things you'd want to address?

Jeremy I'd definitely want to look a little more at JRuby. It's risen up to be a serious force in enterprise development. But then again, it's a bit of a different beast, so perhaps it's left better to its own books.

What would you drop?

Jeremy I don't know that I'd drop anything. I feel like we've covered a lot of good ground, but if I could drop anything, it would probably be the Rails chapter. It's a good chapter with some good techniques, but there's no saying it won't be out of date by the time it hits the shelves.

What's the most exciting thing happening in Ruby and it's community today?

Jeremy Man, I'll say it again: Adhearsion. I don't think a lot of people have given it a serious look yet, but once you do, you'll see how awesome it is. I'd also say Rhodes could be a really cool thing (but I haven't had a chance to use it yet so I won't declare it awesome just yet :)).

What's next for you?

Jeremy I'm going to keep writing. My next project will be updating the Humble Little Ruby Book for 1.9 to be published on No Starch. I'm also writing some commercial software, more open source, and who knows what else?

Other than the fact that you're both great guys, why should Rubyists run out and shell out their hard earned money for this book?

Jeremy There has been a big knowledge gap for people who aren't in "Ruby jobs." They learn the language, they get excited, they dig what they're seeing, but they reach a point where they feel helpless. They don't really know what they can do with Ruby, how to do it, or if they figure it out, if they're doing it right. I think Ruby in Practice is a really solid collection of information that solves that problem, and I'm really happy to fill that gap.

Click here to Tweet this article

Author Interview: Assaf Arkin - Ruby In Practice

With the recent release of Ruby in Practice, I've contacted both Assaf Arkin (@assaf) and Jeremy Macanally (@jm) to do some interviews about their book. These will be posted on my best posts about the best books page.

Assaf got his answers back to me first, and I liked them so much I decided to post them as a stand alone interview. Look for Jeremy's responses soon. Until then, enjoy Assaf's!

---

This book has been a long time coming, how does it feel to see it finally hitting the book shelves?

Assaf Like sitting down for a cup of water after a long run.

If you had a chance to start it today, what are the big things you'd want to address?

Assaf Talk more about BDD. I liked RSpec since I first started using it, but the latest releases are such a leap in making specs easier to write and maintain. That and Cucumber which I'm now getting into. It works at a higher level, describing scenarios or features, and it means that you can drive tests directly from the design, and have that design be part of the source code, not in a separate unmaintained file.

Background processing is something I missed when I first got into Ruby. With Java I had more options for queuing, scheduling and batching. That changed and now when I'm evaluating for a new project I'm working on and there are a lot of good options to choose from. That would make great material for a chapter in the book.

Ruby recently got a serious kick in the XML pants. First libxml came back from the dead with renewed force, then nokogiri showing up from nowhere, hpricot made huge strides. I know people who look at Ruby before, looked at REXML, and decided to go elsewhere. It's time to reconsider Ruby.

I really like where ActiveRecord is going, and I'm always very cautious around ORM because of their tendency to turn relational databases into dumb object stores. I'm using relational databases because they're relational, and I'd rather see the language take on some of these relational aspects. I think Ruby can do interesting things because it's not so OO dogmatic and much more malleable. I use ActiveRecord outside Rails a lot, and that shows in the book, where we just use ActiveRecord when we need to use a database in a context other than the database chapter. I think a chapter about advance ActiveRecord techniques would be great.

Not entirely related to Ruby, but I think this will interest a lot of people: the development workflow. We talk about specs and testing and how to use these as starting point to build and refactor code. Git hit the soft spot with Ruby developer, and there are some practices worth talking about. Also the different tools you would use to take code from development through testing, staging and finally production deployment.

Phusion Passenger. We had to wrap up the book before we could cover it.

What would you drop?

Assaf Tough. We tried to cover things that other books don't talk about, so I'll have to take a look at books that just come out before I can answer that, but if there's a good book on the subject, I would drop that subject.

Except for testing/BDD. The RSpec book is coming out soon and I would recommend it, but I would still have a chapter devoted to testing. I think testing should be talked about more often, and take every opportunity to introduce people to BDD as a better way to design and build your application.

What's the most exciting thing happening in Ruby and it's community today?

Assaf For me, Rails 2.3, which is coming out soon. For the apps I'm working on, 2.3 is a major step forward in smoothing out the rough bumps of previous releases. I'm continually amazed by the things that are happening around Rails. By intentionally not solving all the world's problems, it's leading to an amazing eco-systems of adds and plugins. My latest favorite is Scrooge which inspects your queries and what you do with the results, builds a profile out of that and uses it to optimize your code.

Testing. Manual testing sucks the life out of me, so do bad test frameworks. I love what you can do with Ruby, and even the prospect of using Ruby code to test Java applications. I mentioned RSpec and Cucumber, there's also Should and Webrat, and just a lot of continuous improvement that keep making my life easier.

Ruby 1.9. Faster, better, but not entirely backwards compatible, so that's still work in progress waiting for all the libraries to catch up.

Github. It's a fabulous service that puts all others to shame. It's a social network built around sharing code, and a great tool when working in teams, open source or not. It's also an amazing resource. Sourceforge and even more modern services like Google Code force you to make multiple mouse clicks before you can see the first line of code. Github puts it right there in front of you on the welcome page. It's telling you "come, look at the code, learn from the knowledge of others".

What's next for you?

Assaf Two projects I'm currently involved with which are taking Ruby in interesting directions.

The first is Singleshot, it's a task manager, of if you prefer the workflow term, a worklist manager. It gives you a task list that you can manage, allows you to delegate, and also allows various applications to delegate tasks to you. It's classical enterprise technology and we're trying to make something that has usability at its forefront. That and being a test case for a Web API that takes hypermedia seriously.

The other one is Buildr, a build system that we're using for large applications that have a build cycle. So yes, we're using Ruby code to build applications written mostly in languages like Java, Scala and Flex. Ruby is ideal here because you can use it declaratively, at the level of defining what a project is, but also do grunt work like moving files around or calling command line tools. It's the first project that's strictly Ruby going on at Apache.

Other than the fact that you're both great guys, why should Rubyists run out and shell out their hard earned money for this book?

Assaf Because they're lazy. I know a lot of people who come to Ruby with a strong background in Java and the mentality that you need big APIs, big frameworks, dependency injection, XML configuration, scalable failover containers, and a thousand lines of code later you managed to read a list of names from a file and sort them alphabetically.

Complexity kills, so one thing I tried to show in the book is how you can size the complexity of the solution to the complexity of the problem. Maybe, instead of setting up an ESB with connectors on each side an pipeline in the middle, you can write a few lines of Ruby script, get the same job done in 1/10th the time. Even when, and this is one of my favorite examples, the job requires moving XML messages from WebSphere MQ to Salesforce. Ruby will get you there faster and cheaper than big architecture tooling.

Click here to Tweet this article

Ruby In Practice Blogging Contest

Manning has been kind enough to offer up a free MEAP (Manning Early Access Program) copy of Ruby in Practice as a prize for this month’s blogging contest.

Since Jeremy and Assaf are writing about practical Ruby use, I’d like to hear what you guys are doing with Ruby. Write up your Ruby In Practice adventures, post them on your blog, then drop a link in the comments here, and you could win. You can enter as often as you’d like.

I’ll accept entries until midnight (Mountain time) on January 31st. Then Jeremy, Assaf, and I will take some time to review the entries and announce the winner. Good luck!

You can also read my interview with Jeremy and Assaf.

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.