All of this would not be too big of an issue if the downloadable source code was complete (The chapter5 code doesn’t have the database) and identical to the book code, or if that wasn’t possible (IE: correcting syntax, typos, etc..) contained comments in cases where it wasn’t so a reader would know why.

In the end, I like the book, but mostly because it’s my only choice for a topic I’m interested in learning. For the most part, I believe most of these issues are actually the result of poor publishing. The author in this case is very knowledgeable and well known on this subject, but the book falls apart due to poor technical review making reading it (and thereby learning catalyst) quite a chore that you really have to want to accomplish.

Jens: Resolving dependencies is a “fact of life” for the Perl programmer. It’s the price you pay for having other people write your app for you The RoR and PHP mentality seems to be to cut-n-paste code from blogs, while the perl mentality is to reuse code in the form of modules. As modules’ dependencies change, they stop working, and the author needs to fix the module (and the cycle repeats). It can be tedious to be caught in the middle of this, but in the end it’s a big time saver. (Plus, CPAN modules ship with automatic QA tests, so if the tests pass you know the module will work on your machine. It’s better to get a “no, this won’t work” than to get something that’s only half-working.)

Finally, the book is aimed at people with good Perl proficiency (that already know the CPAN and OO), so it helps if you follow that suggestion. For getting up to speed on Perl, the O’Reilly series is excellent (Learning Perl, Intermediate Perl, and Programming Perl).

Anyway, sorry for such a long-winded comment