Bidding Farewell to the Cardboard Crack
Those of you who know me well probably know that I had an unfortunate case of serendipity recently. I spend approximately three to four hours each weekday commuting for my job. The interstate, of course, is not the safest place in the world to drive. A few weeks ago, a tire tread came off of a truck with me behind it. I didn't have enough time to avoid the tread before running over it, causing one end to snap back and do about $1,600 worth of damage to the body.
It's not enough to render the car unfit for the road, but it is enough to prevent it from passing inspection, which became overdue as of the first of this month. As someone who's been ticketed for that offense once in the past, I can say it's not a cheap ticket. The car has also been hurting for an oil change, alignment, and new set of tires, which all got done this past weekend and will make for a very tight budget between now and next payday.
So, it appears that my attempts at saving for ZendCon will be going toward car repairs instead. Additionally, since I haven't really been doing much with them anyway, I'm selling my Magic: The Gathering card collection off on eBay. In order to optimize their chances at selling, I'm auctioning off the rares, uncommons, and commons/lands in separate auctions. If you enjoy the game and would like to give me a hand through this difficult period, please place a bid.
Also, you might have noticed that there's a new wishlist section in my navigation. It's configured to credit my Amazon Associate account for any purchases made by following the link in that section. If you're planning on buying anything you happen to see in that section anyway, please consider doing so from my blog. As they say, every little bit helps...
And now back to your regularly scheduled programming...
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.
Now on Ohloh
I finally got around to getting an Ohloh profile and setting it up to reflect my work on the Zend Framework and Forkr. Hopefully my list of work will grow as time goes on.
I'm so geekish...
@dungeon | http://news.zdnet.co.uk/comm...Elazar | Not so surprising. I'd heard that experiments had been done that managed to get particles accelerated to a speed approaching light speed.
@dungeon | vulcans are due in how many years?
Elazar | 54.
@dungeon | ty
Elazar | Actually, closer to 53.5.
Elazar | April 4th, 2063.
Elazar | Sorry, 5th.
-*- Elazar feels rather geekish for knowing that.
@dungeon | thanks geek
-*- Elazar thinks he just invented a new word: "geekish." :P
@dungeon | you should feel geekish for being in here
@dungeon | Elazar is a geek among geeks
I can't say that I own an "I'm blogging this" t-shirt, but I probably should.