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:
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.
Well, it's official: My IT Manager convinced those in the upper echelons (well, considering it's a non-profit with only around 20 employees, that meant the president and the CFO) that (1) he and I need to attend a PHP conference, (2) due to the amount of work we've been putting in to bring money into the organization, cost shouldn't be too much of a deciding factor, and (3) php|Tropics isn't too expensive, especially considering the sessions involved cover some of the very issues we've been struggling with the past few months (PHP/MySQL/Apache and clusters, PHP5 OOP, PHP Security, test-driven development, Smarty, and more).
So, we're going to Cancun in May!
This is incredibly exciting! I've never been to Mexico, nor even a resort, so I'll finally get to find out what my wife and friends have been talking about all these years. Plus, the conference is top-notch -- many of the presenters are well-known in the PHP community, and have blogs I've been following for the past year. (I only wish that Chris Shiflett's PHP Security series wasn't running head-to-head with the PHP5 OOP Extensions and PHP 5 Patterns sessions; I suspect Rob and I will have to do a divide-and-conquer that day.)
Drop me a line if you'll be attending -- I'm looking forward to meeting other PHP junkies!
I've been extremely busy at work, and will continue to be through the end of March. I realized this past week that I'd set a goal of having a SourceForge website up and running for Cgiapp by the end of January -- and it's now mid-February. Originally, I was going to backport some of my libraries from PHP5 to PHP4 so I could do so... and I think that was beginning to daunt me a little.
Fortunately, I ran across a quick-and-dirty content management solution yesterday called Gunther. It does templating in Smarty, and uses a wiki-esque syntax for markup -- though page editing is limited to admin users only (something I was looking for). I decided to try it out, and within an hour or so had a working site ready to upload.
Cgiapp's new site can be found at cgiapp.sourceforge.net.
Shortly after I wrote this original post, I figured out what the strength of Gunther was -- and why I no longer needed it. Gunther was basically taking content entered from a form and then inserting that content (after some processing for wiki-like syntax) into a Smarty template. Which meant that I could do the same thing with Cgiapp and Text_Wiki. Within an hour, I wrote an application module in Cgiapp that did just that, and am proud to say that the Cgiapp website is 100% Cgiapp.
1.5.3 fixes an issue introduced by 1.5.2 that creates a performance hit whenever the run mode is being determined by function name or CGI parameter. More details on the Cgiapp download page.
At work, we've been developing a new platform for our website, based entirely on Cgiapp. This week we released the first stage of it: garden.org and assoc.garden.org. These should stand as good testament to Cgiapp's robustness!
With all that development, and also with some communication from other Cgiapp users, I've made some changes to Cgiapp, and release version 1.5.2 this evening.
1.5.2 is mainly security and bugfixes. Error handling was somewhat broken in 1.5.1 -- it wouldn't restore the original error handler gracefully. This is now corrected. Additionally, I've made run() use the array returned by query() -- consisting of the $_GET and $_POST arrays -- in determining the run mode. Finally, I've modified the behaviour of how run() determines the current run mode: if the mode parameter is a method or function name, it cannot be a Cgiapp method or a PHP internal function. This allows more flexibility on the part of the programmer in determining the mode param -- words like 'run' and 'do' can now be used without causing massive problems (using 'run' would cause a race condition in the past).
As usual, Cgiapp is avaiable in the downloads area. Grab your tarball today!
I don't know why I never bothered to look this up, but I didn't. One thing I typically do in my parent Cgiapp classes is to pass $_SERVER['SCRIPT_NAME'] to the template. I just found out -- through the pear-general newsgroup -- that this is unnecessary: use $smarty.server.KEY_NAME to access any $_SERVER vars your template might need.