Effective Perl Programming

I now have my copy of the new edition of Effective Perl Programming. I'm halfway through another book, a wedding on the 20th and some other major personal (good) news, so I won't be able to review it right away. However, a few quick notes:


  • Covers 5.12.
  • A full chapter on Unicode
  • Good discussion of testing


  • Recommends SQLite for a test database (I used to like this idea myself).
  • Needs better coverage of Test::Class.

(Can you tell the one chapter I've already read?)

I don't think the testing points are that serious; there needs to be a far more in-depth treatment of testing and for this book, it can't possibly cover this area properly. I also noticed it had nice things to say about Moose, but didn't use it in examples. I think this was the right decision, but I wish it weren't.

And in Web sites it recommends, blogs.perl.org is listed, but use.perl.org is not. Rather interesting.

In any event, those were just a few things I noticed flipping through the book. I'll have a better description later. For now, suffice it to say that it looks very, very good. Just a few of the places I've taken the time to read are well-thought out and show lots of experience.


My English is not stellar, I'm assuming the wedding is yours. If so: congratulations! As people in my country usually say: "Selamat menempuh hidup baru."

What problems do you see using SQLite for a test database?

Only reason I can think of is when using database triggers and procedures.

Got the book myself as well and like it a lot. Well worth the money.

@Ovid: I wasn't under the impression you're not happy with it. I meant to agree with you about the fact it looks very, very good :-).

When you're using custom data types you're already disabling the use of certain SQL databases (like SQLite and MySQL). It would've been best if this was mentioned, although I think most people know this already.

Since I primarily use MySQL, I prefer to test my application using a MySQL database. Test::mysqld has been a lifesaver for me. It can build a temporary database on the test machine and destroy it after the tests are over. That way I get to test schema deployment/upgrading, triggers and stored routines, and mysql built-in datatypes and functions. Testing in SQLite only misses out on that greatness.

We recommend SQLite as a test database because it's a good enough answer for most Perlers. Obviously, if that doesn't work for you, don't use SQLite. That doesn't mean that everyone else shouldn't use it because it doesn't work in your advanced and complex case.

Another con might be that we don't include the cure for cancer. We would have loved to provide more coverage for Testing, just like we would have loved to provide more coverage for many other topics. However, every book is limited in time and space. We are continuing to add Items that did not make it into the book at the book's website, The Effective Perler. Everyone will find something they think is missing, but that shouldn't detract from all the things that are in the book.

The trouble with big topics such as Testing, however, is that they don't fit into the format of the book. We present short Items that usually assume quite a bit background material. A proper testing book shouldn't use the cookbook style of the Effective Foo series. We left Moose out for the same reason.

Thanks a lot for mentioning Test::mysqld! It made me do a simple search on CPAN which yielded Test::postgresql, which seems to be exactly what I need for consistent database unit testing that can be combined with UI testing on known state of database.

I was thinking the answer might be that you needed something custom that couldn't be tested easily with SQLite.

Leave a comment

About Ovid

user-pic Have Perl; Will Travel. Freelance Perl/Testing/Agile consultant. Photo by http://www.circle23.com/. Warning: that site is not safe for work. The photographer is a good friend of mine, though, and it's appropriate to credit his work.