Slashdot review of Drupal 7 Module Development
Michael J. Ross contributed a review of our Drupal 7 Module Development book. Slashdot typically writes very fair reviews, and Michael's is no exception. He does a good job of digging into each chapter and examining both the strengths and weaknesses of the book.
Up front I would like to make a request. We would like to encourage readers to use the GitHub book code instead of the downloadable code bundle from Packt. The bundle packaged by Packt was outside of our direct control, and seems to contain earlier versions of some of the code. In addition, the GitHub project contains code updated to the latest errata that we know about. And we respond to bugs filed through GitHub. In other words, the code there is a living document.
I found it interesting that Michael could tell that different authors had written different chapters. This is very much the case. Each of us took a turn or three as a "primary author" for a chapter, while others just provided input about what should be covered or how well a topic was covered. This gave each of us a chance to play to our own strengths. It also (I hope) held at bay the old "too many cooks in the kitchen" problem. We assumed that readers would be able to move effortlessly from chapter to chapter without being tripped up by the unavoidably different voices of the authors. We could have added a byline to each chapter, giving a clear indication about who wrote what, but we just didn't feel like that added anything.
Perhaps the biggest difficulty writing the book was in continually trying to hit a moving target. When I began chapter 2 well over a year ago, Drupal was still under very heavy development. APIs were changing. Strategies were still in flux. Documentation (and in some cases, design) was not complete. This led to an interesting writing process: Write the chapter, go back three months later and try to find out if anything changed, go back three more months later and try to find out if anything had changed, etc. Thankfully, the tech reviewers caught many of these issues along the way. Needless to say, it is far easier to write a book against a finished code base, but it was more important to us that we get the book in developers' hands right around the time D7 was released. It was sort of our D7CX commitment. <!--break--> On a final general note on book reviews, one of my pet peeves is when reviewers complain that "the author didn't cover feature X which is very important to me. Author--." In my D6 book, for example, I got complaints that I didn't cover programming Views 2 or CCK. There are reasons why we don't cover every feature. Book length and readability is, perhaps, the main concern. Relative unimportance of "feature X" is another. But that's not all. I couldn't cover Views 2 and CCK for the D6 book because neither was released. (And, in fact, Views 2 went through a major refactoring between when the book was published and when Views 2 was released). We didn't cover installing, contributing to the community, or even downloading additional modules in our book. Why? Because the book was on writing code. We already forced it above the deadly 400 page mark. We couldn't cram anything else in there. Sometimes there are legitimate complaints about uncovered topics, but generally you can identify these using a simple rule: If you cannot code for the platform without that knowledge, it ought to be in the book. We hope there are none of these aporia in our book.
