Packt recently sent me a copy of the book “PHP Programming with PEAR” to review. I rather wish they hadn’t, because it faces me with the dilemma of having to post a really negative review of a book, and potentially hurt the sales. On the other hand, it’s my obligation to tell you, the PHP programmer, that this book should be avoided at all costs.

Unfortunately, it probably also means that Packt will stop sending me free books to review. But I gotta do what I gotta do.

1) The book is about PEAR. However, nowhere does it tell me what PEAR is, other than a short paragraph in the preface, which nobody will read. Much more importantly, there’s nothing whatever in the book that tells me how to locate, download, and INSTALL a Pear module. So when it jumps right into a chapter on one of the more obscure of the Pear modules, almost without telling me what it is, what it’s for, or why I would consider using it in preference to PDO, I’m completely at sea. Where do I obtain this module? How would I install it once I had obtained it?

If you type ‘pear help’ at the command line, you get more information than is contained in this entire book about the pear command line utility. It isn’t once mentioned, as far as I could tell.

Chapter 1 is missing, entirely. Chapter 1 should be “What is PEAR?” Chapter 2 should be “Using the pear command line utility” Those two chapters would be what most buyers of your book would actually be looking for. Without those chapters, the current book is an exercise in frustration. Yes, this stuff looks cool, but where the heck do I find Pear::DateTime? It’s not installed on my server.

I see that Packt has a separate book called The PEAR Installer. Presumably that book answers these questions. The problem is that if I go to the store to buy a book about PEAR, I’m going to buy one or the other, not both. A chapter on the pear command line utility is essential for this book.

2) The code examples are almost always there without showing the output. In the few cases where the output is shown, it’s almost always difficult to ascertain which code example led to it. The worst example of this I found was in the calendar chapter, where an example is shown of a HTML table rendering of a month calendar, complete with a description of what color the various dates were. I was unable to find the code that generated this output. Since this is one of the things that I’d actually like to do today at work, I find that very frustrating. This was the rule, rather than the exception.

I have found, in years of writing and presenting at conferences, that examples carry 100 times more weight than pages of exposition. Showing a line of code, and the output that it produces, communicates more than discussing the function and its uses. This book shows a lot of functions, and very seldom really shows what they do.

3) The book assumes that you already know what OO syntax looks like, and almost never shows it to you. One reason that PEAR developed was that with the transition of PHP from 4 to 5, nobody knew about OO syntax, or how to build objects, and PEAR was a way to provide these object models to people to get them started. Showing them how to use PHP objects is critical to success. CPAN did this really well with Perl, and PEAR has done it less well with PHP. I’m not real sure why so few PHP programmers know about or use the stuff on PEAR, while Perl programmers universally use CPAN. This book, and others like it, are an opportunity to tell people about the great stuff on PEAR. Reusable code is a really big deal, and PEAR is, and should be, the place for that code to live. Unfortunately, this book doesn’t communicate that.

4) The selection of modules to cover was, to be charitable, random. There are (as of today) 534 packages on PEAR. (See http://pear.php.net/packages.php for details.) This book chooses, at random, 5 of them, and covers them in a rather haphazard manner. Now, I don’t claim that I know which modules should have been covered. But I can assure you that if I wrote this book, I would do some research into which ones were most popular, and which ones seemed neglected, but amazingly useful, and which ones nobody uses because they’re not useful.

5) This book completely overlooks what I consider to be almost the most important topic, after “what is PEAR” and “How do I install a module”. Specifically, “How do I write a PEAR module?” And the related question of, once I’ve written a really useful module, and I’d like to share it with the world, how do I go about contributing this to PEAR. CPAN has done a wonderful job of answering that question, and, as a consequence, I have something like a dozen modules on CPAN that are used by thousands of people. I don’t know how to contribute my code to PEAR, and have some that I’d like to contribute. I was hoping that this book would answer this question.

6) I’m a huge calendar geek. I was looking forward to the calendaring chapter, because I figured it would give me the same charge that the calendaring stuff in Perl does. Calendars are a lot of fun, and PHP has put a LOT of effort into datetime code in the last few versions. A lot of brilliant people have devoted hundreds and hundreds of hours to making the datetime implementation respectable.

The calendar chapter was a huge disappointment. It focused largely around a code example to generate a HTML table rendering of a calendar, although early in the chapter it hinted at the fact that you can do this with a single function call in the Tabular class. But it didn’t tell me what that function is, which just pissed me off for the rest of the chapter. And since I was at the pool when I was reading it, I couldn’t look anything up, or try any code examples.

So ….

all of that to say, I think that this book is significantly below the standard that I have come to expect from Packt books. I was very, very disappointed. I think that this book is really important – that is, a book in this space – and it’s frustrating that it wasn’t done well. It felt like someone’s first writing experience. We’ve all been there. My first book was an embarrassment, and I’m glad that it’s out of print. I hope that these gentlemen progress in their career enough to feel the same way about this one. I felt a number of times that I could have written the book better.

50% of writing a book like this is research. Another 25% is experimentation – writing code with the stuff learned from the research, getting a feel of how it actually works, and coming up with interesting examples. A poorly written book on a topic like this is just a rehash of the documentation. However, I don’t think that this even goes that far.