Why I Hate System Administration
I got assigned to a new project at work recently. At first, I was delighted, because I knew that the project requirements would allow me to use PHP. My job generally involves Oracle Forms and Reports or PL/SQL data cartridges, so going back to my language of choice seemed like it would be a refreshing change. The client, however, has rather interesting requirements regarding the server environment.
First, they're running on Sun hardware and as such require that they maintain a Sun operating system, namely Solaris 10, only that hardware. Second, their applications are currently running off of an Informix 7 database server.
There is currently only one PHP extension for interfacing with Informix that is actively maintained: PDO_INFORMIX, which is in PECL and is maintained by IBM (who bought out Informix shortly after the client got this database server). The latest release of this extension was made in February 2007 and it relies on PDO 1.0, which is about 3 versions back from the current version of PDO. That's not to mention that you need the Informix Client SDK installed on the system to install PDO_INFORMIX.
The only Solaris builds of PHP are on the Freeware for Solaris web site and the only build that will run on Apache 2.0.59 (what's currently running on the client's production server) is PHP 5.2.1, which has the latest version of PDO built in by default. There's no way to override this with an installation of the separate PECL extension, at least that I know of. The only way to get around it is to recompile PHP from source and disable the default inclusion of PDO.
I spent today trying to figure out how to get PHP to compile from the source tarball offered on that web site so that I could disclude PDO from being built into the interpreter and then install it as a separate PECL extension to allow me to install PDO 1.0 to allow PDO_INFORMIX to be installed and work correctly. No matter what I tried, I got this error message:
ld.so.1: httpd: fatal: relocation error: file /usr/apache/libexec/libphp5.so: symbol sapi_module: referenced symbol not found
I've been told (and I believe it) that libphp5.so is expecting there to be some Apache files somewhere and obviously just isn't finding them, even though I've used the --with-apache2 and --with-apxs2 options when configuring PHP for installation from source and tried installing Apache from source as well.
The last thing I did before leaving was start a fresh installation of Solaris 10 to a VMware disk, which I intend to make a snapshot and backup copy of before I try again. I'm hoping that my initial attempts to install PHP and Apache from their Solaris packages is causing some sort of conflict, though I have to say I have my doubts. I'll continue searching for answers tomorrow. In the meantime, any sagely advice in the comments would be welcome.
PHP Articles and News
Etienne Kneuss has an excellent article explaining late static bindings, a prospective feature for PHP 6 (and possibly 5). If you have any interest in scope or context as it relates to inheritance, I highly recommend you check it out.
Also, while this one is a few months old, I still think it's link-worthy: Ligaya Turmelle wrote an article illustrating the various types of SQL JOIN clauses in a very simple, easy-to-understand manner.
Elizabeth Marie Smith has been working on a new project recently to create a PHP 5-geared PECL extension to wrap the Win32 API as a nicer alternative to Winbinder.
Update: While Stijn Leenknegt isn't the first person to suggest the "function-return-array" idea, I think it's certainly been a popular suggestion and may even make it into PHP 6. It's definitely a useful feature in JavaScript.
Log Analysis and PHP
As the Extension Categorization section of the PHP manual and the Wikipedia entry for PHP will attest, one of PHP's greatest strengths is its level of integration with third-party libraries. If the functionality you need isn't included in the officially supported extensions, chances are good you can find it in a package on PEAR or PECL. However, there are no guarantees, as I was reminded this past week when my curiosity was piqued enough to motivate me to check for a particular extension.
Log analysis is a fairly common task in the field of web development, most often analysis of web server traffic logs or what Wikipedia refers to as web analytics. PHP has no officially supported extensions designed specifically for log analysis. There are no related extensions in PECL. The only remotely related extension in PEAR is PEAR_Log, which for generating logs rather than parsing or analyzing them. In short, there is no common solution here.
At this point, most people generally choose to do one of two things. The first is to roll their own solution in PHP. While this has the advantage that it can be catered to the specific data the programmer is trying to extract, it requires time to develop and has the overhead of being written in an interpreted language.
The other common approach is to use a third-party software package to do the log parsing and analysis and to have PHP capture its output and extract whatever is needed from there. Common examples of such software that are open source include analog, awstats, webalizer, and visitors. This generally has somewhat better performance than the first approach (as most such software is C-based) but is limited to the data and output formats that the software provides, which can make it inflexible and difficult or tedious to integrate with.
I believe a PECL extension for log analysis would be very advantageous. Written at the C level, its performance could be on par with existing solutions and it could provide a flexible API for extracting the desired data. The underlying code could potentially be written as a separate library first and then a PECL extension written that merely wraps it. When rolling their own solution, many developers generally dump their raw data into a database first in order to tap its analytic capabilities rather than trying to replicate them in their own code. As such, I wonder if it wouldn't be advantageous to have the API use a variant of SQL to allow the user to specify what data should be extracted.
So what do you think? If you were a potential user, what do you think optimal test cases for such an API would look like? The strength of open source software lies in the ability of its developers to offer and consider multiple perspectives. As such, if I'm going to take on this project, I'd like to hear what others have to say.
Update: I've just been told that development on phpOpenTracker has recently resumed after about a three year hiatus. If you're interested in a PHP-based web analytics solution, it might be worth a look.
Update 2: If you tried to get to the visitors link above and found it broken, it's been fixed. Sorry about that.
Pondering PHP 6
Let me start off by openly admitting that in no uncertain terms am I speaking on this topic with any substantial amount of authority. I don't subscribe to the PHP internals list and the gist of what I've heard about it indicates that the most likely result would be subsequent nightmares for life. (OK, maybe that was melodramatic, but you get my point.) The last time I dealt with C or C++ was a semester or two before finishing out my bachelor's degree. That was during a time when the compilers course being taught at the university I attended became optional within our curriculum, and to ease the workload of my schedule, I skipped it. I rather regret doing so now, and while I've always meant to set aside time to inspect the innards of PHP and make a contribution myself, it's always sat on the ever-growing laundry list.
Be that as it may, as a user with about five years under his belt as of now who has seen all qualities of PHP code ranging from pristine to pedantic, a thought or two has crossed my mind on the subject of the latest upcoming incarnation of the language. I know, I know, everyone and his brother has already spoken on one aspect or another of the subject. This is just my two cents; take it for whatever it might happen to be worth to you.
Namespaces - While this was an on-the-fence topic and debated for some time, I'm personally glad to see the addition. The common practice in lieu of this feature has been to fully qualify class names with what would normally be the namespace, which leaves them rather long and painful to look at. David Coalier has started a series on namespaces to further explain them.
mysqlnd driver - It saves memory, passes more unit tests, provides tighter integration with PHP, and otherwise lands a pretty good sucker punch against the existing libmysql-based driver. Despite the licensing snafu that generated a decent deal of hype many moons ago and was eventually handled with the FLOSS License Exception, I think it's fairly safe to say that MySQL is the database most commonly used in conjunction with PHP and this is going to be an awesome improvement.
Unicode support - OK, I know a lot of effort has gone into implementing this, a lot of people are drooling over it, and I can certainly appreciate that. As for me personally, aside from the capability of a few neat tricks that have more of a coolness factor than a usefulness factor, this doesn't really have me jumping up and down. I've never had to work on sites where localization or internalization was needed to the extent that non-Latin character sets had to be used.
Deprecations - Go register_globals! And take register_long_arrays, magic_quotes_gpc, and safe_mode with you! These settings have contributed to the ability of implementing messy code for far too long. My only gripe is, why is open_basedir not also on the way out? It may not cause any issues in PHP itself, but doesn't its mere presence imply that it should be secure when the PHP 6 meeting notes admit otherwise?
Named parameters - The meeting notes have an example of what these are and detail the reasoning behind why they're not going in, which I can't say I agree with. I've never heard of PHP purporting to follow the KISS principle in any respect. What exactly is the "it?" I wouldn't say there's anything easy or clean about the current common practice, which is to use associative arrays. Personally, I think it's ugly. This may be syntactic sugar, but it would make code look a lot more readable.
There are many other significant changes in PHP 6, but those are the points that drew the most attention from yours truly. Regardless, PHP 6 seems to be major improvement over past iterations and I hope it overcomes the adoption difficulties that PHP 5 has experienced.