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
