Tag Archives: review

Review: Modsecurity Handbook, by Ivan Ristic

mod_security Handbook

I’ve finally finished reading Ivan Ristic’s new book, mod_security handbook, published by Feisty Duck. Ivan is the brain behind mod_security. By the way, if you’re not using mod_security on your Apache server, you should be. And this is the book to tell you how to use it.

Ivan sent me a few early releases of the book, and about a month ago I received the first print edition.

This book is what you’ve been waiting for if you use mod_security. (And, as I mentioned, if you’re not using it, you should be.) The documentation for mod_security has long been frustrating. Even where it was complete and informative, you just didn’t know where to start.

This book is where to start.

The first 2/3 of the book is written in tutorial fashion, walking you through tasks from installation to complex scripting. Chapter 6 gives a great description of writing rules, and Chapter 9 gives numerous practical examples which flesh out what goes before. I always learn best by example, so these examples and the accompanying explanations make the earlier academic learning more meaningful to me.

Chapter 8 is about persistent storage of data. I’ve long been interested in this area of mod_security, and have had many times when I needed it and didn’t understand the docs on it. Ivan makes it much clearer than I’ve seen it presented before. I’ll be looking back at this the next time the need arises to do this kind of thing.

The last third of the book is the reference manual. I’m a big fan of having the reference manual in printed format, although it does run the risk of being out of date quickly.

This book is constantly updated, so you can always obtain the latest version. However, it’s unlikely that I’ll be buying a new paper book each time there’s a new release of mod_security. This book is also available in electronic format, and if you buy the ebook, you get updates to it as part of your purchase price. That’s pretty cool.

On the whole, this book is a long-awaited resource, and is very well written, by the person who knows the topic best. Highly recommended. You should go get a copy right away.

When you reach me, by Rebecca Stead

I just finished reading When You Reach Me, by Rebecca Stead. It won the Newbery award this year, so I figured it would be worth reading.

I found the book rather disappointing. In the last few pages, all of the bizarre and confusing things that happened through the book are all explained, and everything falls in place but the fact is that until that moment, the book is hard work to get through. I think it’s unlikely that my kids, anyway, would persist through to that Ahah! moment, and so would dismiss the book with their usual designation of “boring.”

Added to that, the book relies heavily on the reader being familiar with “A Wrinkle in Time”, a book which (yes, I know, it’s heresy) I can’t stand. So, if you’re familiar with Wrinkle, and if you liked it, perhaps this will resonate with you. But it really didn’t work much for me.

Here’s a review that completely disagrees with me.

Son of A Witch

We recently got done reading Son of a Witch, by Gregory Maguire. It’s the second volume in the series The Wicked Years, which starts with Wicked, presenting some of the backstory behind the rather shallow Oz stories, full of their cardboard-cutout evil characters. They are wonderful stories, although Maguire inserts rather raunchy scenes in them at various places, often for no readily discernible reason, as they often contribute nothing to the the plot.

Maguire is obviously a fan of Baum’s work, as he is very true to the details provided in the original Oz books, while providing a great deal of depth where Baum leaves out details. Often, however, Baum’s easy answers are explained as political lies and propaganda, which is just as delightful.

I highly recommend these books, although you don’t want to read them with your kids.

Magento: Beginner’s Guide (Packt books)

Long, long ago, Packt sent me a copy of the book “Magento: Beginner’s Guide” by William Rice, and asked me to review it. I finally got around to it, and over the last few evenings have been reading this fine book. I just got done with it, and feel like I want to go set up my own store.

The strongest points of this book are:

1) Table of contents organization – the chapters are obviously very well planned out. Rice carefully considered what a beginner would need to know, and in what order they would need to know it, then broke it into clear, digestible pieces.

2) Presentation of ideas within the chapter – Ideas are clearly presented, clearly explained, and then there’s a wonderful “What just happened?” summary that reminds you of the important parts of the instruction, and why they matter, so that you don’t end up lost as to what you did.

3) Voice – The voice in the prose is kind, patient, and not condescending like so many tech books. I felt like I was being helped by an expert, but one who knew how frustrating it can be to be talked down to.

I have only two complaints about the book, and one of them is really a nit-pick.

In the intro, Rice refers to Apache 1.3 as “the proven, reliable version 1.3”, and puts it on an even footing with 2.2. Folks, 1.3 went into maintenance mode six or seven years ago. Folks need to move on. (Yes, ok, this is a nitpick. He’s just saying it’ll work both places.)

Now for the real one. The installation chapter is very strongly geared towards web hosting providers who offer a web-based pointy clicky configuration tool, and folks who either don’t have a web-based “control panel”, or have one that’s not described, may still feel a little at sea when it comes to doing things like creating a Mysql database.

But, having gotten those two complaints out of the way, I have to say that this is probably the best-written technical book I’ve read this year. I highly recommend it, and, having read it, also highly recommend Magento as a web commerce solution.

Review: PHP Programming with PEAR (Packt)

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.