Blog Posts

Every little girl has to give up the bink...

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…

Continue reading...

Notes on PEAR_Exception

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.

Continue reading...

ZCE - Results are in!

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

Zend Certified Engineer

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!

Continue reading...

PHP Application Documentation

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.

Continue reading...

Search APIs

Twice in the past week I found myself needing to create or alter database search functionality in some APIs for work. In doing this work, I discovered some techniques that make this process much easier. In line with The Pragmatic Programmer, I found myself exploring the DRY principle (Don't Repeat Yourself), and looking into code generation (this time, SQL) — basically to exploit my inherent laziness and to make my job easier.

I thought I'd share some of the principles I've discovered for myself as I haven't read much information on the subject. Some of this may be rudimentary for some readers or those who work with more advanced abstraction layers (I suspect DB_DataObject may do much of this), but hopefully the information can be a useful reference for others (myself included).

Continue reading...

Moving into City Living

We did it… we moved, again.

However, unlike our previous two moves, which were interstate, this time we stayed in the same state. The same county, even. What made (makes; we're still finishing up as I write this) this one so jarring is the fact that we're going from the rural mountainside to the fourth floor of a new apartment/condo building adjoining an interstate spur.

Why would we do this?

Continue reading...

Planet PHP

I recently had an email exchange with chregu of Planet PHP regarding Planet PHP's blog selection. I've been subscribing to its RSS feed for over a year now, but was uncertain how blogs were selected — was it based on popularity of the developer, projects the developer works on (for instance, PEAR), etc. I felt that it was time for this information to be made public; it helps inform the readership why they're reading what they're reading.

And my exchange with him resulted in his Planet PHP FAQ blog entry, which hopefully someday will become a static page on the site. Additionally, I found out how new blogs get added, and am proud to announce I'm now in the lineup!

(Of course, the timing could not really be worse, come to think of it. I'm moving my family in to town this weekend (from our house in the Green Mountains of Vermont), and I need to make arrangements for hosting weierophinney.net in the interim while we wait for phone and DSL service — which won't be up for at least another week :-( I'm sure I'll figure out something… stay tuned!)

Update: corrected link to Planet PHP FAQ.

Continue reading...

PEAR and DocBook documentation

Sean Coates has posted a rant and a blog entry regarding DocBook and the various proposals on PEAR related to using a wiki for package documentation.

A little background is probably in order. Many PEAR developers feel that DocBook is needlessly difficult and provides a barrier to writing good documentation for PEAR projects; this is actually the most often-cited reason for lack of documentation for a PEAR package. Many actually create wikis that they then link to in a minimal DocBook tutorial as "full documentation".

One proposed remedy is to create a PEAR wiki for each PEAR package. A scheduled process would then transform the wiki markup to DocBook, HTML, PDF, whatever.

What Sean rants about is simply this: wiki markup is meant to be simple, and much code documentation would require specialized wiki markup. Additionally, DocBook is already meant to do the transformations required; it is a structured language that is meant to be processed into a variety of output formats.

While I agree with Sean's ideas in essence, I still feel that DocBook is a real pain to work with. PhpDocumentor offers some real convenience when documenting code: doc blocks can contain HTML, some simple inline elements like {@link} — and they make documenting a snap. But I just fail to understand why, when providing tutorials, a switch to DocBook is necessary. Whenever I use it, I find that I have to retool a set of tutorials I have, or somebody else has, already written in order to get formatting correct, and that I have to switch my thinking altogether to accomodate a new set of rules and logic.

Yes, DocBook is simply XML with a documented schema. However, I've never enjoyed XML. I find it too pedantic, I don't like having to escape out CDATA sequences in order to render HTML (and code, and XML, etc.), I don't like having to learn new DTDs for every project, and more. I feel for configuration, unless you have nested elements, there's no reason to use XML whatsoever. And when it comes to documentation, why use anything other than HTML? Since HTML is a subset of SGML (as is XML), there's no reason it can't be transformed to other formats itself — and for the majority of PHP developers, HTML is a known, while XML/DocBook may or may not be.

Whether or not DocBook is hard can be debated from here to eternity. The fact of the matter is that it is perceived as being hard to learn, and thus many PEAR developers are simply choosing not to bother. Why not give them a tool they can use easily? Maybe then the amount and quality of documentation on PEAR will improve.

Continue reading...

Cgiapp 1.7.0 released

I'm getting ready to move in another week, and thought it was time to push a new release out the door… before life descends into utter chaos.

Cgiapp 1.7.0 adds a plugin architecture (which has been present in the perl version since last autumn). Plugins register with the class, and, once registered, their methods may be called from your Cgiapp-based class as if they were part of it through the magic of overloading. This allows for a standard library of utilities to be written — such as form validation (a sample class for this has been provided utilizing HTML_QuickForm), authentication, error logging, etc.

Additionally, I created a Cgiapp5 class that inherits from and extends Cgiapp. Along with it is a CgiappErrorException class that can handle PHP errors and rethrow them as exceptions. Combined, the two create some very elegant run mode error handling that simply isn't possible in PHP4.

Visit the Cgiapp website for more information on Cgiapp; if you want to try it, download it.

Continue reading...

php|Tropics recap

php|Tropics last week was excellent, and I'm not even sure where to begin for a recap. I started journaling while there, but found I simply did not have enough time (or bandwidth — my one complaint about the conference) to keep up.

The trip down was hellish. I'd lost my birth certificate, and was turned away at the ticket counter due to improper documentation. I was able to reschedule for several hours later, and had just enough time to go home, look futilely for my birth certificate, and then run down to the town clerk office in Bolton to get a certified and notarized letter proving my voter registration. Which got me on the plane, but I still ended up having to sign a notarized affidavit of citizenship before my final flight from Houston could take off.

The resort where the conference was held is called Moon Palace Resort, and is one of a string of five or more 'Palace' resorts on the Mexican Riviera below Cancun. The place is huge — there are two lobby areas, and each serves what looks like a couple thousand rooms. You can't help but get exercise while there, because there's simply so much ground to cover.

Marco Tabini gave the keynote, and kept it short and sweet. To my mind, he covered one primary point: the PHP job market sucks for pay. As he put it, why does an assembly line worker at Ford get paid $35/hour, while the average PHP developer is paid $15/hour? This is not to belittle the assembly line worker, but more to ask the question of whether or not a PHP developer is inherently less skilled. Marco feels that the way to boost PHP wages is to produce a standard educational corpus and licensing program — and educate employers as to why someone who has taken them deserves to be paid more. (I'm still not sure how I feel about his conclusions, but they're certainly food for thought — as I'm not being paid much more than the PHP average.)

Rob and I skipped out on the first two sessions. To our mind, we weren't as interested in them as other sessions, and we weren't going to have much free time while there. We put on the swim trunks and took a stroll through the pool. Yes, a stroll. I wish I could find a map that shows just how long and serpentine the pool there is; you can easily get a good workout just going for a stroll in the pool.

And strolling is thirsty business, so we strolled over to a swim-up bar. Now, one excellent thing about the location is that the resort is an "all-inclusive" resort — meaning that all food and drink is included in the price. So, we ordered margaritas, since it was noon where we live. They were okay, a little weak… and Rob noted that the bartender wasn't using anything off the top shelf. "What do you think we need to do to get him to use the Sauza?" asked Rob, to which I replied, "I think you just ask for it." So, next round, "Margaritas con Sauza, por favor."

And so it goes.

Strolling also included the beach, a wonderful expanse of white sand overlooking the azure water of the Caribbean. I spent a lot of time just sitting under coconut trees staring out over the sea; I can see how tempting it would be to retire on the Caribbean.

We started attending sessions that afternoon, and only missed one more over the course of the conference. I did get some excellent information from a number of sessions — but one thing in particular I got out of the conference as a whole is how far advanced is the setup Rob and I have put together at NGA. Our web cluster is almost as good as it gets without pouring money into commercial databases and support (though Ilia Alshanetsky's web acceleration session gave me a ton of information on tuning the relations between php, apache, and the OS); we've standardized on PEAR and are using it well; we're filtering data reasonably well (though we can always do better); etc. I often feel like I'm behind the curve when it comes to our technology, so the conference was a welcome boost to the ego.

On day 2, I ran into Paul Jones, with whom I've emailed once or twice, and on whose blog I've commented several times. We immediately started hanging out, and talking shop. Which began the other important aspect of the conference: the social networking.

In day-to-day practice, I really only get to talk code and program with one other person, Rob. This is fine, but it leads to a narrow exposure. Going to the conference gave me a chance to go over code and coding philosophy with a larger variety of people — my peer group, if you will. I got to see that, if you're not working for a large corporation, you do the same shit I do every day — programming, installing and tuning servers, help desk issues, everything; coding in PHP is only one aspect of your busy life. It was actually refreshing to see that I'm not alone.

A group of six of us got together that second evening, and ate out at one of the 'restaurants' (there are several eateries at the resort; not really restaurants, 'cause you don't have to pay, and they're all buffets) overlooking the Caribbean. As we were talking, we commented on how the networking amongst each other was probably the best part of the conference — and how it would be nice if the speakers would deign to join us.

Ask and ye shall receive. Later that evening, as we stood around the 'swing bar' (a little tiki bar with swings instead of bar stools, out on an island of the large, serpentine pool), we were gradually joined by speakers, including Marcus Boerger, Wez Furlong, Derick Rethans, and Lukas Smith. We had some great discussions that started devolving in indirect proportion to the amount we drank (well, not really devolving, but certainly migrating to other non-coding topics…)

Unfortunately, Rob and I had to cut out around 11:30, as we were taking the Zend Certification Exam at 8 the following morning. I quit drinking between 9:30 and 10… Rob had not, so he got to do the exam with a hangover. All in all, I found the exam less difficult than the study guide, but certainly full of tricks meant to foil you.

The final evening had a similar conclusion to the night before, only with even more participants, including Jason Sweat and Ilia. This time there were no exams to follow, and we stayed up until 1:30 (and later for some people).

Looking back, I see I wrote very little about the actual conference — which seems odd, as it was the central event. There were certainly some excellent presentations, and a lot of great material — much of it I have not been able to find elsewhere. Hopefully I'll find some time to blog about it in the coming weeks.

I didn't take many pictures, and I need to get a gallery going anyways. Rob, however, took a ton of pictures and put them up on his site each day. You can view them at his gallery; I'll put direct links to the individual galleries later.

So, if you get a chance, attend the next PHP conference you can possibly afford, and spend as much time as possible getting to know your fellow PHP code monkeys; the benefits are, to use an oft-used marketing phrase, priceless.

Continue reading...