I recently had the opportunity to interview Joe Fair, the author of Payment Processing with Paypal and Ruby. Joe, would you please introduce yourself?
Joe:Sure. I'm a software engineer for L-3 Communications working at the FAA helping make maps for pilots. My bachelors degree is in Computer Engineering from the University of Arkansas, and I have a Master's in Software Engineering from Southern Methodist in Dallas. I've been writing software for almost ten years.
Early in my career I started working on passing information between applications. Reports, billing records, that sort of thing. Later, I found out this is called "Enterprise Application Integration" and there's a whole industry around it. Most of my career has been working with integrations and solving back-end problems. Even now, when I'm on a team doing web applications, most of my time is spent on back-end issues.
How did you discover Ruby?
Joe: Actually, I heard about it at a No Fluff Just Stuff conference in Denver back in 2003. I had asked a panel "What makes you _really_ productive?" and Dave Thomas said, "Ruby". I thought it was interesting, but I never got around to looking at it.
What are some things that you don't think Ruby does well?
Joe: The things I don't like are problems I hear other people have had:
- It's slow.
- It's not well documented.
- It's not easy to deploy.
- It's not easy to find help.
It will be easier to get local help as Ruby spreads, so I'm not worried about that aspect. There are some smart people working on all the other aspects, so I think we'll see Ruby just keep growing. Some day it will be Enterprise Ready, whatever that means.
How much of your daily work is done in Ruby?
Joe: Just my play time right now. I've been concentrating on PayPal integration, so I'm catching up on some new things. Mostly RJS right now, but I'd like to write some tools for more generic back-end integrations, too.
What are you using Ruby for?
Joe: I'm putting together some small commercial sites. My role as a government contractor restricts a lot of what I do during my day job, so I have to feed my Ruby habit after hours.
However, I have heard of one project on our campus that used Ruby for some internal tools. It looks like the camel's nose is under the tent, as they say.
A while ago Hal Fulton caught some flak talking about 'sneaking' Ruby into an organization (in an earlier interview here at On Ruby). Talking about the camel's nose sort of echos what Hal was talking about. How would you respond to the people who call sneaking/slipping Ruby into an organization unprofessional?
Joe: The way I look at it, I'm a professional problem solver. If my problem includes "and use Java" and I don't, I'm providing the wrong solution. That's just as bad as providing the wrong functionality. If the customer doesn't care, then I'm solving the problem with the best tool I know.
I looked up that quote, and it seems to me he deserves some flak for "and your bosses may not even know", but the rest of it sounds like the way a lot of change happens in organizations. I've seen new IDE's, new libraries and new techniques bubble up this way. Occationally feathers get ruffled, but more good is done than harm.
What made you want to write a book about Ruby and Paypal?
Joe: In February I went to a Rails Studio class with Dave Thomas and Mike Clark. I was asking Dave about some ideas for an open-source project I had had, and we got onto the subject of some of his recent books. We talked about some other unexplored areas for Ruby, and payment processing was one of them.
I thought about it for about a week and did some research, and put together a proposal. I sent it to Dave fully expecting he would reject it, or reveal that someone else had started it, or ask for a lot of writing samples. I was trying to not get my hopes up. Instead, he said, "Sounds good. I'll send you a contract. Don't let that hold you up." and I was in.
I don't think they'll mind if I mention it here: The Pragmatic Programmers are looking for good book ideas. If you have a good idea send it to them.
What books about Ruby would you like to see someone write/publish?
Joe: That's a great question. We're seeing more books about converting to Ruby and selling Ruby to your organization. The big push back now is that Ruby can't replace Java in the Enterprise. I think Java and Ruby are different solutions that have some overlap, but Ruby won't supplant Java completly. Just like Java didn't supplant C++, nor C++ supplant C, etc. Each language solves a problem, and some languages fit some problems very well.
Having more tools is better than having fewer tools. I'd like to see books about solving new problems that Ruby is a good fit for.
What drew you to the 'Fridays' format?
Joe: I really like the idea of a focused set of instructions to solve a specific problem. Most developers will probably be able to read this Friday, pick a good solution, and get a simple working example working very quickly.
If you had an entire book there would be more information, but it would need to be more of a reference manual rather than a tutorial. Each has its place, but sometimes you just need the tutorial.
What was the most important thing you learned while you were writing your Friday?
Joe: I think that the most important thing about PayPal is just how much flexibility PayPal gives you. You can do a web site with just static web pages all the way up to SOAP messages back and forth. You can have all the complexity you want (and more.)
The most important thing I learned about Ruby is that you have to be careful about your libraries. The ruby2wsdl tools are terrific, but you have to have the latest version, not the one that comes with Ruby.
The most important thing I learned overall is that it is a lot of fun to write a book, and you'll learn a lot along the way.
Which books about other languages (or language agnostic) should more Rubyists be reading?
Joe: I devoured My Job Went to India: 52 Ways to Save Your Job. It's not really about outsourcing at all. It's about creating a quality product (you) and providing value to your customer (the employeer).
Since reading that book, I've spoken at two user groups, started a Testing group and a Java Certification group where I work, paid for my own Rails training, provided feedback to a local community collage, and written this e-Book. I'm increasing the variety of experiences that I've had so I will be seen as more valuable to my employeer.
It's not just for geeks, either. Almost a year ago I loaned it to a millitary officer, and he liked it so much he marked it up and won't give it back.
What are your favorite five Ruby libraries or tools?
- Rails - Wow.
- Active Record - Even Better.
- irb - Where has this been all my life?
- soap4r - Makes things SO simple.
- Vi Improved on Windows - It just works.
What's next for you?
Joe: I have a couple of ideas. I'd like to build up my Ruby portfolio, and I've had an idea for an integration book for a long time.
I'd like to go back and read the top couple of dozen of the best software engineering books and papers like Mythical Man Month, Peopleware, and No Silver Bullet. I wonder how many mistakes I've made that some guy warned us about 20 years ago. I always wanted to work through William C Wake's Refactoring Workbook.
What do you think is next for Ruby?
Joe: I'm glad to see the JRuby guys got picked up by Sun. It will be easier to win converts if you don't have to convince your admins to install another language (just keep your boss informed :-)
What do you think is next for Rails?
Joe: More hype, more resistance, more press, and more converts.
I'll bet this happens in the next year:
- Somebody's going to try Ruby on a problem it's not suited for and utterly fail.
- They'll write an article or book bashing Ruby and hyping Java.
- It will get widely read and blogged about, and it will be interpreted to mean Ruby is bad for all problems.
- Through arrogance or ignorace, people will use Ruby anyway and we'll see more success stories.
Eventually, I think the developer community will be able to judge what problems Ruby is better at than the alternatives. Right now I don't think we've seen enough people push the envelope and fail to know where to draw the line.