Cgiapp 1.6.0, "Wart Removal", has been released!

This release does not add any new methods, but adds quite a lot in terms of functionality:

• phpt tests. I finished writing a suite of unit tests using the phpt framework popularized by the PHP-QA project and PEAR. This process helped me find some obscure bugs in the class, as well as some… well, downright ugly code, and to fix these areas. (To be honest, most of the 'ugly' code was a result of being too literal when porting from perl and not using more standard PHP functionality.) Among the bugs fixed:
  • s_delete() now works properly. param() and s_param() now behave gracefully when given bad data (as do a number of other methods)
  • _send_headers() and the header_*() suite now function as documented.
  • All methods now react gracefully to bad input.
• Error handling. carp() and croak() no longer echo directly to the output stream (and, in the case of croak(), die); they use trigger_error(). This will allow developers to use carp() and croak() as part of their regular arsenal of PHP errors — including allowing PHP error handling. Additionally, most croak() calls in the class were changed to carp() as they were not truly fatal errors.
• PEAR packaging. Cgiapp can now be installed using PEAR's installer. Simply download the package and type pear install Cgiapp-1.6.0.tgz to get Cgiapp installed sitewide on your system!

As usual, Cgiapp is available at the Cgiapp website.

As promised in my earlier entry from today, here's my quick-and-dirty tutorial on unit testing in PHP using phpt.

First off, phpt test files, from what I can see, were created as part of the PHP-QA effort. While I cannot find a link within the PHP-QA site, they have a page detailing phpt test files, and this page shows all the sections of a phpt test file, though they do not necessarily show examples of each.

Also, you might find this International PHP Magazine article informative; in it Aaron Wormus gives a brief tutorial on them, as well as some ways to use phpt tests with PHPUnit.

Finally, before I jump in, I want to note: I am not an expert on unit testing. However, the idea behind unit tests is straightforward: keep your code simple and modular, and test each little bit (or module) for all types of input and output. If the code you're testing is a function or class method, test all permutations of arguments that could be passed to it, and all possible return values.

Okay, let's jump in!

I've been tinkering with Unit Testing for around a year now, and have tried using PHP Unit as well as Simple Test. It was while following the Simple Test tutorial that I finally grokked the idea of unit testing, and so that has been my favored class for testing.

However, I find writing the tests tedious. In Simple Test, as in PHP Unit, you need to create a class that sets up the testing harness, and then you create a method for each test you wish to run, and so on… I found it incredibly time consuming. Additionally, I found the test harness often felt like a foreign way of testing my code; I was setting up a structure I would never use my code in, typically. All in all, I only test when I have extra time (which is rare) or when I'm really having trouble nailing down bugs (and the unit tests often don't help me find them).

Recently, I've been hearing some buzz over on the PEAR lists and the blogs of some of its developers about 'phpt' tests. From what I hear, phpt tests sound very similar to how one tests in perl (though I've never written perl tests, I've at least glanced through them). However, until recently, I haven't seen any documentation on them, and installing PEAR packages via pear doesn't install tests.

We got a copy of PHP5 Power Programming a few weeks ago, and in the section on preparing a PEAR package was a brief section on phpt tests. The section was small, and when I looked at it, my immediate thought was, "it can't be that simple, can it?"

So, I decided to try it out with Cgiapp. A few minutes later, I had some working tests for my static methods. "Hmmm," I thought, "That was easy. Let's try some more."

Turns out they're kind of addictive to geeks like me. In a matter of a few hours, I'd knocked out tests for over half the functionality, and disccovered, to my chagrine and joy, a number of bugs and bad coding practices… which I promptly corrected so I could get that magical 'PASS' from the test harness.

In the process of writing the tests, my understanding of the tool evolved quite a bit, and by the end, I had the knack for it down. I'll blog later about some of the ways I made them easier to use for myself — and how I made them more useful for debugging purposes.

I just had to add a note over on PHP.net regarding abstract classes and methods: Object Abstraction.

I'm working on Cgiapp2, which is a PHP5-only implementation of Cgiapp that is built to utilize PHP5's new object model as well as exceptions. One thing I decided to do, initially, was to make it an abstract class, and to mark the overridable methods as abstract as well.

In testing, I started getting some strange errors. Basically, it was saying in my class extension that an abstract method existed, and thus the class should be marked as abstract, and, finally, that this means it wouldn't run.

What was so odd is that the method didn't exist in the extension at all.

So, I overrode the method in the extension… and voila! Everything worked fine.

The lesson to take away from this is quite simple: if the method does not need to be present in the overriding class, don't mark it as abstract. Only mark a method as abstract if:

1. The method is required in the class implementation, and
2. The extending class should be responsible for implementing said method

Now I need to update my source tree…. :-(

Greg Beaver writes in his blog about PEAR, the new PEAR channels, and some issues he sees with PEAR and its developers. Greg is responsible for the latest version of PEAR and the PEAR installer — and for the development of PEAR channels. The particular link referenced above makes reference to a thread on the PEAR-dev mailing list… that I originated, when asking whether or not Cgiapp might be a good fit for PEAR.

At work this week, Rob was doing some monitoring of our bandwidth usage. We have SNMP on each of our servers now, and he uses MRTG to create bandwidth usage graphs that are updated every five minutes or so. He's been monitoring since late last year.

Before January, we had two systems going. The first, legacy, system hosted the majority of the content from garden.org, and was done using Tango 2000, a web application server that ran on top of IIS and Windows NT 4. I say 'ran', because Tango 2000 was the last version to ship; the company that made it stopped supporting it a year later. This meant we could not upgrade our server's OS to Windows 2000 or 2003, nor could we switch to a more secure web server, etc. It was a time bomb waiting to happen.

The second system is a basic LAMP system — Linux + Apache + MySQL + PHP. Rob began migrating applications to it shortly after he started at NGA 3 years ago, one application at a time. Mostly, new applications were placed on it, though in May 2003, he and the other programmer who was there at the time started migrating old applications to the techology. Part of the reason I was hired was to continue this migration.

The migration was time consuming, and plenty of other projects often got in the way. However, starting last July, we made a big push to get it all ported over — before the old WinNT server fails on us. In January, we were able to rollout the new garden.org, which runs on this new technology.

A big reason we were able to finish is because of Cgiapp. I originally ported it to PHP last year around this time, and knew that while I wanted to develop new applications using it, I wasn't so sure I could sell Rob on it.

Amazingly, it didn't take much to convince him. We had already started using Smarty for templates just before this, and were also using OOP in new development. Cgiapp just helped unify these technologies and to provide a nice, standard framework with which to program.

This last can not be emphasized enough. We started developing all applications in three places: an API for data access, a Cgiapp-based application, and our templates. Either one of us could pick up development of an application from the other without having to spend a day or two familiarizing ourselves with the idiosyncracies of what the other had decided was the programming paradigm of the day. Sure, we still have our own programming styles, but the framework makes it easy to debug or extend each others programs painlessly.

Now, back to the bandwidth reports: Rob has noticed that our bandwidth usage has been growing steadily on the new server since we switched garden.org over — a 45 degree line. At one point this week, our outgoing bandwidth was almost 3 T1s — and we were having no performance issues whatsoever. This simply would not have been possible on the old system — nor without Cgiapp. We've managed to produce both a hardware architecture and a programming framework that has proved immensely scalable — which will in turn save the organization money.

I love open source! How else can you create such high-performing software without paying through the nose for it?

So, I did a little experimentation, and I was able to seamlessly integrate Serendipity into my existing website via Smarty, some CSS, and changing just a couple of links!

The result is the website you're currently reading!

This means I can now offer trackbacks, comments, RSS feeds, and all the other stuff a modern blog should offer… and with minimum fuss and with a lot of standards and security. I wish everything I did was this easy.

I've been wanting to improve — no, rewrite — my blogging software for a month or more now. The more work I've done at work, the more efficiently I've felt I could handle it. I've learned a lot of ins and outs with Cgiapp and Cgiapp superclasses, and figured out how to tie things together much better. However, I've also noticed, in reading and analyzing blogs, that there are a lot of standards that I just don't know enough about or simply don't have the time to implement ("the more work I've done…" has been something like 70 hour weeks recently). Things like trackbacks, and RSS/Atom feeds, and comment moderation/blacklisting, etc. I certainly have the skills, but do I have the time? Not really. I still have a goal of writing some lightweight blogging software using Cgiapp. However, for now, that's on hold so I can focus on family, myself, and the next round of Cgiapp improvements. In the meantime, i've been seeing a lot of stuff about Serendipity, and I thought I'd give it a try. Here are the results! It was super fast to setup, and I hope to import all my old entries from my own system to it, once I can see how entries are stored in the DB. So, you can now keep track of me via RSS… Read away! Update: I'm liking S9y even more: it uses Smarty for templating, which means I'm able to modify it to look like it was always seamlessly in my site!

I couldn't resist… the car model demands it…

For those not familiar with where I live, my family and I live in West Bolton, VT — about 20 miles from Burlington, and at the base of Bolton Mountain. Our daily commute is 4 miles on a dirt road, another 3 to 4 miles on some twisty two-laners at 35mph to the interstate, and around 10 miles on the interstate into Burlington. Then there's all the miles in town getting Maeve to day-care, Jen or myself dropped off, and whomever has the car to work. And we only have one car.

So, you can imagine the crisis when, almost a month ago, our Toyota RAV4 died on the way in to work.

We started it up that day, and it had this funny knocking sound. I remembered a similar sound in my old pickup back in Montana… the one that died. I determined to get it into a shop that day to get it diagnosed. The noise came and went while we were on the backroads, and because it wasn't constant, I figured it couldn't be too serious.

And then we tried to get to highway speeds…. a few miles on the interstate, and it was evident we were in trouble. The Rav was having trouble maintaining 60mph on the way up French Hill — when it normally was able to accelerate past 70mph. And the knocking sound was getting worse and louder.

We resolved to pull off at the first exit, at Tafts Corners in Williston. I pulled into the first gas station there, and as we tried to find a place to park the vehicle, a mechanic was flagging at us to stop the car. He came over to where we parked and said, "Sounds like you've blown your engine."

These, of course, were the absolute last words I wanted to hear.

To make a long story short, apparently a bearing was thrown when we started the engine that day, and because we decided to drive it, we basically destroyed the engine. The cost to replace it: around $6,000.

Now, we're not exactly what you'd call "financially secure". We've had a lot of transitions in the past five years, and except for the past year and a few months, haven't typically both been working at the same time. We've been in a perpetual cycle of having enough to pay the bills… but having to pay consistently late. And we haven't been able to do much, if anything, about our educational debt. In short, our credit sucks. Which means that $6,000 is a big deal.

Did I mention that, at the time of the incident, we still had 17 months left on our car payments?

And, on top of it, I've been in the middle of a huge project for work that's required a fair bit of overtime — and very little wiggle room for personal time?

The timing could not have been worse, either professionally or financially.

We've been very fortunate, however. Jen's parents very graciously offerred to pay off our existing car loan — which helped tremendously. It bought us both the time to figure things out, as well as eliminated one factor that may have barred our ability to borrow towards repairs or a new car. Additionally, a friend of Jen's turns out to be absolutely ruthless when it comes to dealing with car salespeople, and went to bat for us in working out a deal. If it hadn't been for her efforts — and those of the salesperson, who also went to bat for us — we would not have gotten more than a thousand or so for the vehicle; we ended up getting over $3,000 for it, as is. Finally, the finance guy at the dealership advocated for us tremendously so we could get a loan on a new vehicle, with the Rav as our trade in.

So, to conclude: We're now proud owners of a 2005 Toyota Matrix! (And now the mystery of the title is revealed… to all you Matrix fans out there…)

I'll try to get a photo of the car up soon… about the time we update the year-old photos on our site… :-)