O'Reilly has just released the Rails Cookbook
The Rails book market is getting full fast. Other than the O'Reilly name, what sets this one apart? Why should people buy it?
Rob: Well, from a developer's point of view, more books to choose from is not really a problem at all, right? Also, no market is ever really full — it just becomes unprofitable to participate in. Since profits from direct sales were not my motivation, it's up to each publisher to decide whether they want to push another Rails book into the market or not.
When I was asked to write a book on Rails, it was initially going to be
Rails Hacks or Head First Rails. After some discussion, we decided to write
the first cookbook on Rails. I did a little investigation and saw that
Rails Recipes had been in the works but then was stalled for some reason.
It wasn't until about two months into it, at O'Reilly's sales conference,
that Andy (of the Prags) announced that Chad would be picking up Rails Recipes
At that point I was a little concerned about duplication between the two cookbooks. It turns out though that our books are really very different. Chad's book is 70 recipes that range from intermediate to advanced, while my book has 190 recipes that really cover a much broader spectrum — covering many of the basics through some pretty advanced rails concepts.
Of course, my book took a lot longer to write, so we really ended up covering the framework at different times. The bottom line is that there is very little duplication between the two cookbooks and the consumer has the luxury of choosing between the two — or they can buy both.
I think that i did a pretty good job of covering all the material that a Rails developer need to know in order to become productive, fast. So far I've been getting good reviews but I encourage people to check out the table of contents to make sure it's the right book for them.
What is the appeal of the recipe approach in books?
Rob: The way that different people tend to learn is a very complex subject. Everyone might take a unique path towards mastery of a specific technology. I find that when I'm learning something new, I make a series of "passes" over the subject. The initial fly-over is analogous to skimming the table of contents of a book. Each subsequent pass reveals more details and hopefully leads to a more in-depth understanding of the subject. In terms of Perl books, for example, Learning Perl may be an initial fly-over where Mastering Perl for Bioinformatics would be much later pass. This is one dimension; that of varying degrees of complexity.
In addition to complexity, there's granularity. Think of granularity as the size of the chunks of information that are being presented within a book. A very small chuck might be a line from a Pocket Reference that says to use "params" instead of "@params" while a large chunk might walk you through the creation of an entire web application. The level of granularity I prefer in a book at any given time depends on how in-depth an understanding I need combined with how much time I have available at that moment.
I see a cookbook as a highly indexed body of medium sized chunks of information that vary in complexity. A cookbook is something you reach for as you're developing. You have a problem that you're trying to solve and you want the answer as fast as possible. The idea behind the cookbook is that you look in the list of recipes (and then their problem statements) and find something that resembles your problem, and then you have your answer. That's the goal anyway.
I don't expect that the cookbook format is right for everyone but I think having it in the selection of books a Rails developer has to choose from is critical.
You mentioned a Head First book. Do you think we'll see a Ruby book from the Head First team?
Rob: I expect so but I really can't say for sure. Head First books differ drastically from traditional books in that they only work with the perfect author. I'm sure O'Reilly is looking for that author but I'm not sure what the status of that is. I'll keep you posted.
What kind of Rails development were you doing before you started on this book? How did that experience affect the book?
Rob: About the time I started working at O'Reilly my wife and I decided that we needed to try to raise our kids on a single income. This meant that I had to fire up my contracting business up in order to supplement my O'Reilly salary. This was right around when Curt Hibbs posted his first Rails articles to O'Reilly's OnLamp.com. My Rails adoption route was probably similar to most; starting with amazed curiosity, followed by a healthy amount of skepticism ("Does it scale?", etc...), and finally by the confidence that Rails is, in fact, a better way to develop web applications efficiently.
I can't boast about any high profile Web 2.0 Rails projects but I had no trouble finding a steady stream of Rails work. I really got wrapped up in the excitement of Rails and wanted to share it with my friends and others. At that point I did couple of talks on the subject. In fact, it was at one of these talks (at a North Bay Linux User's group meeting) that I was approached by Mike Hendrickson from O'Reilly about doing a Rails book. Incidentally, Mike (an executive editor) and a few other O'Reilly brass were playing poker around the corner form our meeting.
Basically, I didn't enter the Book writing process as a total noob to Rails, but neither was I a Rails expert. Much of what I've learned about Rails, beyond my contracting experience, has been from researching and writing the book. Ironically, I think this is part of what makes this book work. I know the learning curve that new Rails developers are up against and I believe I've offered a clear and no-nonsense path past it, towards the end of being self-sufficient with the framework. But also remember that much of the book was contributed by other members of the Rails community — many of them having a enormous amount of Rails experience and expertise in areas that I was lacking.
With Rails 1.2 out now, how much of your book is already obsolete? How do you write a book against a target that moves this quickly?
Rob: You'll notice that the book states on the cover that it's been updated for Rails 1.2. This is because I made the decision in December to pull the book out of O'Reilly's production process in order to update it for Rails 1.2. At that point we already had a chapter on RESTful Rails development so there wasn't as much to update as you may think. Still, there was plenty of work to be done. Luckily, I had the help of a couple of my good friends; Christian Romney and Ryan Waldron.
I wasn't really sure when Rails 1.2 would emerge from it's release candidacy but the timing really couldn't have worked out better. My book went on sale a single day before Rails 1.2 released.
As for writing about a moving target, such as Rails; It was a challenge. There were many parts that I had written months before that had to be revised as new features appeared and as old techniques became deprecated. The good news is that you can see most new developments coming from pretty far off by staying in touch with the community and by following changes to the framework via the Rails Trac project and/or blogs of the people driving Rails development.
Part of what makes Rails exciting is it's flexibility to change with the evolving needs of the Rails community. While trying to document things as they change is sometimes difficult, I really wouldn't want it any other way.
What is your favorite recipe from the book and why?
Rob: One cool recipe that I've been thinking about recently is titled "Creating a Custom Report with Drag and Drop" in the JavaScript/Ajax chapter. The idea behind this recipe came from a Rails application that we use at work called Dove, written by John Butler. The idea behind Dove is that it allows users who don't know SQL or much about the complexities of our database to easily create custom reports from our database. Roger Magoulas, of O'Reilly's research department, designed Dove to be a web-based version of query tools like Brio.
Because of the back story of this recipe, it was interesting to see it mentioned on the Ruport mailing list recently. Someone suggested that a Ruport plugin for Rails should be created based on the techniques demonstrated in this recipe. Come to think of it, maybe I should work on that.
Have you spent any time looking at other web development frameworks? What can Ruby on Rails learn from them?
Rob: Over the years, I've had to deal with many web applications that probably should have used a framework, and occasionally some that were designed well enough that they could have had a framework extracted from them, but didn't. To confuse the issue, I've used many components of frameworks. For example, I've used several different ORM (object relational mapping) layers, and as many different stand-alone template languages. Rails is really the first full-stack framework that I've used for more then a single project.
Before discovering Rails, I was shopping around for a framework and was hoping to find a suitable one in the Python world. When I was webmaster at Industrial Light and Magic I was introduced to Zope by a friend (Jed Parsons). He was using it successfully for a large documentation management system for ILM's training department. My impression of Zope was that if you could climb its very steep learning curve then you could eventually be very productive. This seemed like a bit more then I needed at the time so I started checking out CherryPy — a lighter weight Python framework. (This must have been before Django and TurboGears were out in public.) Unfortunately, I never got a chance replace the Servlet/JSP based intranet I was in charge of before leaving ILM.
Shortly after starting at O'Reily, I jumped into my first Rails project with a friend of mine, Ben Bangert. We learned Rails together as we rebuilt a client's site that had been running PHP-Nuke. After that project, I worked on a few more Rails gig before eventually starting on the book. Ben, on the other hand, began writing Pylons. It's funny; the whole time I was writing the book, I had Ben IM'ing me about how he didn't like one thing or another about Rails, and that he had "fixed" it in the framework he was working on (Pylons). Pylons is built to work with the WSGI standard (Web Server Gateway Interface) and supports the idea of pluggable middleware layers. You can stack these layers together as needed. I think this could be an area for Rails to learn from, in terms of clean and standardized way to extend the framework. Rails plugins are great but there is no way to know if one plugin is going to work with another without testing them together. I think Pylons and the WSGI standard have a good solution for this.
What do you think are the most glaring weaknesses of Rails?
Rob: This might sound like an odd point, but I think it's the explosive growth of the framework. It may be that this growth is exposing weaknesses that might not otherwise have been problematic. The rate at which people are jumping into the community is really presenting some difficult challenges. The Rails mailing list is extremely high-volume and is almost a full-time job to monitor. Because of this, many people (some who may have a lot to offer new users) opt out and retreat to more private discussion venues. The same goes with the IRC channels. I assume this will all work itself out as more people get Rails experience under the belt, but this almost frenzy-like growth has definitely been an issue. I don't mean to say that growth is a bad thing for the framework — we just need to work on the logistics of being able to handle that growth.
Documentation is another weakness and one of the areas that suffers most in Rails. The early adopters tend to want to document the most advanced areas of the framework and report on new features the moment they see the light of day. This really leaves the bulk of the community without consistent documentation for some of the mostly commonly used areas of Rails. This is why I think my book is such a good fit right now. I tried to compensate for what I see as a void in general Rails documentation.
A final weakness that I'd like to point out is about process. I would like to see the Rails core be more traditional (professional, whatever) about their software release process. The way we bounced from Rails 1.1.4 to 1.1.6 (I call this Revision Reverb), and how the security flaw that caused all of that was handled, needs work. Open source works best with predictable release practices and security notification systems. Of course, all of this has been hammered out now, but I'd like to see Rails adhere to more established best-practices in its management. I'm sure we'll see improvement going forward, but I has been a weakness.
If you weren't programming in Ruby and Ruby on Rails, what languages and frameworks would you be using?
Rob: In response to a literal interpretation of that question: I don't feel that because I build a lot of Rails apps or even because I wrote a book on the subject, that I can't use other languages or frameworks. In fact I do. I love that I have the freedom to choose the best tool for the job. I like to think that I'm a pragmatist about the tools and languages that I use for any given project. I do feel strongly about Open Source tools and I always lean towards them when possible.
If I wasn't programming in Ruby and Rails, that would have to mean that they didn't exist. If that was the case, my top choice for a language would definitely be Python. As for a framework (again, assuming Rails was off the table), that would necessarily have to be Pylons because otherwise I'd never hear the end of it from Ben (who I sit next to all day).
What non-Ruby/RoR books should Ruby and RoR hackers be reading?
Rob: This one I can answer with out blowing anyone's cover, but
what complicates the question is that so many people are coming to Rails
from different backgrounds. So, I could repeat a fairly standard suggestion
that software developers read the 'gang of four' Design Patterns book but
getting a designer to work through that book might be a bit much to ask.
For most people I think Chad Martin Fowler's Refactoring
is a much more digestible approach to design
patterns, as well is O'Reilly's Head
First Design Patterns. Any kind of object-oriented design pattern
homework a developer can do will payoff, especially with larger Ruby and
Rails projects.
Database design is another topic I think that many Ruby/Rails developers
could read up on. One of my first books on the subject was Database
Design for Mere Mortals. I don't think you need to go too deep with
database theory but you need get to a point where a metal alarm goes off
when you see a bad database design. After all, this is the foundation of
your application and problems born here will reverberate up the stack and
potentially cause a lot of problems.
Another category of books that developers should read are on sound
development methodologies. Right now, the Pragmatic Programmers have a
number of good ones in this area. Practices
of an Agile Developer is a good one to start with that will resonate
well with common practices found in both the Ruby and Rails
communities.
What I do is read up on whatever interests me at any given moment. When I hear about a new gem or a topic from someone, I add it to a text file that I store in subversion. This serves as a "todo" list of things to investigate, as time allows. One way to chisel away at this list is to divide the investigation up among a group. This is a great thing to do in Ruby or Rails user's groups or even your software team at work. Having other people do the leg work of looking into a new topic can help you stay on top of more subjects then you might be able to follow up on alone.
No comments:
Post a Comment