This past year, Maeve had a month-long unit on Safaris and jungle animals at daycare. One day, she came home singing:

On Safari, on Safari, In a jeep, in a jeep, I can see a lion, I will take a picture, Click, click, click. Click, click, click. On Safari, on Safari, In a jeep, in a jeep, I can see a tiger, I will take a picture, Click, click, click. Click, click, click.

And so on.

There's a place just over the Quebec border called Parc Safari that we've been hearing about, and today we went up there on a family outing — one of the last that we'll have with just the three of us (before little Liam is born).

Not long ago, as Maeve and I were en route to Jen's work one evening, Maeve was being very insistent that certain things were a certain way, and was very adamant even as I used a placating tone with her. I asked her, jokingly, "Why are you so contrary today?" Her reply?

"Because I'm so smart, and because I'm so right."

I almost wrecked the car as I guffawed. Kids. They're so dang cute. And so right!

File_Fortune has been released via PEAR.

Changes since the proposal include the addition of a static method for retrieving a random fortune from a list of files, the addition of a DocBook tutorial listing several usage examples, renaming the exception classes to conform to PEAR CS, some minor bugfixes, and some streamlining of the package definition.

Included in the release is an example script, phpFortune, that can be used on the command line to get random fortunes from one or more fortune files. Usage is:

$ phpFortune fortunes
$ phpFortune fortunes simpsons hitchhiker
$ phpFortune

Enjoy!

What a way to start the day — I had an email from PEPR letting me know that my File_Fortune proposal had been accepted!

File_Fortune is a PHP OOP interface to reading and writing fortune files. It is loosely based on the perl module Fortune.pm, but modified significantly to better work with PHP file access methods, as well as to add writing capability.

I will be uploading my initial release shortly, probably as a beta or RC.

So, go fetch those Simpsons, Hitchhiker's Guide, and Star Wars fortune cookie databases and prepare to add random quotes to your site!

I've been doing a lot of thinking on form validation recently. Among other things, I want to be using a standard set of tools for validating form input at work; I'm also rewriting the family website in PHP, and want to have consistency there as well. Finally, I truly buy into Chris Shiflett's top two security practices: filter input, escape output. Validation should always be done, and should be done rigorously; don't allow anything more than is necessary to get the work done.

I flirted briefly in the past month with HTML_QuickForm. Being an observer on the CGI::Application mailing lists, HQF looks like PHP's answer to perl's Data::FormValidator. HQF has a high frequency of posts on the php-pear-general lists. A lot of people seem happy with it. I decided to try it out as an example plugin for Cgiapp for the latest release.

My problem is that I want to be able to define form validation in a file outside my script. The reason for this is that as I extend and reuse classes, I often find that I can use the same general run-modes for a method… just so long as the form validation logic is separate. This allows me, for instance, to decide that in one application instance I will require fields A-M, but in another, I only need A-E (or vice versa). But it requires no changes to the actual application logic, as the validations are kept separately, and I have the application instance indicate which validation file to utilize.

So, last night, Maeve fell asleep in the early evening, on the couch, clutching her sippy cup and sucking on her bink while watching Scooby Doo. She woke up an hour later, and after she'd been up for a while and was less groggy, she announced to Jen and me that, "I'm not going to use my bink ANY MORE. Every little girl has to give up the bink some time, when they're four, so I'm not going to use the bink EVER AGAIN." (Imagine dramatic pauses between the all-caps words there…)

This coming from the girl who has a fit every time her bink isn't within eyesight and reach. Needless to say, we didn't quite believe her, but we were willing to support her. We told her that if she wants to stop using the bink, that's okay; it's also okay if she decides to use it again. (Fully expecting she'd want it within minutes of going to bed.)

Well… Maeve slept all night without it, and didn't want it this morning, nor in the car. She's adamant, our little warrior queen! (Which is what the Gaelic Maeve translates to in English, in case you were wondering.)

I might be jumping the gun here, but I get the feeling our little girl has taken another step in growing up… and I'm bewildered and a little sad. Much as I've hated the bink the past year, I also associate it with my little girl… and she's getting so she's not so little any more!

UPDATE: I jumped the gun. She did go a full 24 hours, but the following night decided she wanted the bink again. But there is hope for a bink-less future…

I've been doing some thinking on exceptions, and PEAR_Exception in particular. You may want to skip ahead to read about how to use PEAR_Exception, as well as some of my thoughts on the class on first use. If you want the background, read on.

I've created a package proposal on PEAR for a package called File_Fortune, an OOP interface to reading and writing fortune files. I've been using a perl module for this on the family website for years, and now that I'm starting work on the PHP conversion, I thought I'd start with the building blocks.

In creating the proposal, I started with a PHP5-only version, though I found that I wasn't using much in PHP5 beyond the public/private/protected/static keywords. For error handling, I decided to try out PEAR_ErrorStack, as I'd been hearing buzz about it being the new "preferred" method for error handling in PEAR. (Honestly, after using it, I'm not too happy with it; throwing PEAR_Errors was much easier, and easier to manipulate as well — but that's a subject for another post — and exceptions were easier still, though more typing.)

The first comment I got on the proposal was the question: "Why PHP5?" (Paul wasn't too surprised by that reaction.) I thought about it, and decided it wasn't really all that necessary, beyond the fact that I'd need to take some extra steps to be able to actually test a PHP4 version. So, I did a PHP4 version.

Well, then some chatter happened, and a number of developers said, "Why not PHP5?" So, I went back to PHP5. And then somebody else said, "Use PEAR_Exception." So, I started playing with that, and we finally get to the subject of this post.

Got the official notification: I passed the Zend PHP Certification Exam, and can now report I'm a Zend Certified Engineer (ZCE)!

Thanks go to my bosses at NGA for giving me the opportunity to attend php|Tropics, to Marco Tabini for offering the ZCE exam as part of the php|Tropics conference fee, and to my wife, Jen, and daughter, Maeve, for putting up with me while I studied… and being good sports about having to stay home while I went to Cancun. Hopefully next time I can take you along!

Paul Jones has written an interesting piece about documentation in the PEAR project, in which he argues very convincingly for using wikis for end user documentation.

I actually think that last point bears repeating: using wikis for end user documentation. I talked to Paul about this issue at php|Tropics, and both of us use phpDocumentor quite religiously. However, API documentation is very different from end user documentation. And the issue with documentation at the PEAR project has to do with the fact that there are many projects with little or no end user documentation — which often makes it difficult for a developer to determine how a module might be used.

The often-cited barrier for this is that end user documentation on the PEAR website must be done in DocBook format.