After I had upgraded from Firebug 1.2.0b7 to 1.2.0b15, my web apps were no longer throwing any kind of logs into the Firebug console. I’m using the Zend_Log_Writer_Firebug class for that.

Luckily, just earlier today I noticed a new release of Firebug 1.2.0. And with that, FirePHP 0.1.1.2. But now there was a new problem:

[”There was a problem writing your data from the Wildfire Plugin http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1″, Array(4)]

That, of course, wasn’t helping any. So I checked the release notes and noticed issue #14, which is a copy of ZF-4020. Since I’m stuck with ZF1.6 RC2 and would rather not pull from the trunk, I figured I’d test to see if I could fix it myself. Followed the code through to Zend/Wildfire/Protocol/JsonStream.php line 203 and replaced $part); with '|' . $part . '|'); Works great!

And I just noticed that ZF1.6RC3 was released. And it includes the fix, of course. Quite a chain reaction. A bug in Firebug’s tabWatcher.js gets fixed, causing a refresh issue with FirePHP, which fixes the issue and also adds a workaround for a problem with whitespace disappearing, which requires a new ZF release candidate. All is well at last.

Evidently 2008 is the year of the aggregators. They’re everywhere. Socialthing, ping.fm, and what have you. But here’s one with an immedialy obvious business model. Introducing Spokeo. An aggregator that asks you to provide your AOL, Gmail, Hotmail or Yahoo email credentials (which, in my opinion isn’t the safest way to share contacts and I wouldn’t divulge that kind of information) to load all your contacts from your address book and then tries to connect all the dots.

Spokeo advertises that individuals who give up their email account credentials can find out “secrets” about their friends. The same information that’s available free to individuals (well, subsidized by allowing Spokeo to harvest your contact list) is also sold to anyone who’ll pay for it. Specifically, they’re targeting HR departments.

Their business model is providing in a way, a social media-based public information “background check” to companies. And that’s probably a very appealing thing to Old Economy Mega Bank Corp. which will use this service to see what potential job candidates have been up to on 43 Things, Amazon, Bebo, Blogger, Buzznet, dailymotion, deviantART, Digg, Facebook, Flickr, Flixter, Fotolog, Friendster, Hi5, iLike, imeem, Last.fm, LinkedIn, LiveJournal, Multiply, MySpace, Netlog, Pandora, PhotoBucket, Picasa, PictureTrail, Slide, StumbleUpon, Twitter, Upcoming, Veoh, Vox, Web Results, WebShots, Windows Live Spaces, Wretch, Xanga, Yelp, and YouTube.

So, if work hard and play hard, make sure what happens in Vegas stays in Vegas.

For the longest time I’ve used the Plantronics .Audio 70 “Behind-the-headset”. It’s lightweight, has clear sound, and has an almost 10 foot long cord. And perhaps that’s part of the problem. I keep rolling over it with my chair every so often, and eventually, after 6 months of use or so, the chord will short out. Although the issue is usually right where the cord meets the headset so I doubt I can fault my chair for that. Ultimately I’m not quite sure whether it’s smart or idiotic to keep buying the same headset. I just like it the way it is. Other and usually bulkier “gaming” headsets are just too heavy and clamp onto my ears so tight that they start to hurt after an hour.

The last headset I bought was a Microsoft USB headset, which was pretty decent, but it also had the dreaded broke cable issue after a few months of use. I threw it out a few months ago, and have just been using my very awesome (and cheap) Sony MDR-G42 headphones along with my laptop’s built-in microphone. That works, but I also use my PC every so often, particularly when I need more horsepower.

So I went out and found the Plantronics .Audio 645 USB headset, which seems to be the successor of the .Audio 70 I used to buy. It’s very similar, except that they’ve added padding, and a USB adapter.

I don’t need the USB adapter at home since I have a Sound Blaster X-Fi, but it’s interesting that for all intents and purposes, this USB adapter essentially is a sound card. The headset set me back $42, and I doubt that the USB adapter cost all that much. I’m almost tempted to crack it open and take a peek inside. And I feel a bit sheepish having bought a $150 X-Fi if a $2 thumb drive looking adapter can accomplish, well, something similar, anyway.

Earlier today while reading through the Zend Framework 1.6 RC1 release notes I’ve come across an interesting bug that has been fixed: [ZF-3382] Zend_Cache_Backend_File problems under very high load.

There are a lot of things to say about this issue. The obvious ones first:
1. Under typical operation such as opening, locking, reading/writing, and then closing a file you should never need to unlock a file explicitly since fclose() implicitly unlocks a file. Calling flock(LOCK_UN) explicitly merely introduces a potential race condition between the lock release and file close. And it’ll be (very) hard to debug.
2. PHP’s fopen() has a bug when using “wb” (overwrite in binary mode). Instead, “ab+” (append in binary mode) followed by a fseek(0) and truncate(0) eliminates another potential race problem. Roof Top Solutions has an article on this.

Honestly, these types of bugs are of the worst kind particularly because they’re rather hard to identify. The buggy code runs and seems fine, but will fail when you need it the most; under high loads, such as when you’re on digg, slashdot, or any other large site that sends massive amounts of traffic your way. Suddenly, instead of helping your site scale, it causes your web application to thrash while the cache files are getting clobbered and trampled on.

Now imagine this is an issue with your in-house component that you have to solve by yourself. First it would have to be isolated and identified because the big picture is just that your application crumbles under high load — “even with all the caching that it’s doing. Not sure what’s going on”, might be the first thought. I know that it would take me quite some time to actually narrow it down to the caching layer, create stress tests, experiment with various backends to see if, say, using memcache vs. files would fix the issue. And that’s just identifying the problem. When it comes to fixing it, not explicitly unlocking isn’t too hard to figure out, but the issue with fopen() in “wb” mode? That would have taken a while. Case in point; looking at the issue ticket, it was created June 4 and resolved on June 26, and judging by the notes, largely due to the efforts of Cody Pisto, who spent his afternoon on June 25 identifying the problems and creating a patch for this tricky issue.

Furthermore, this is a great example of the benefits gained from the Zend Framework (and other open source frameworks and components). In buzzwordy marketing lingo: It’s a time and battle tested feature rich platform of loosely coupled components that you can mix and match as you please, and it only gets better as its adoption rate increases.

I use Phing to deploy my projects, and as they become more complex I expand on my use of Phing tasks. For instance, I have a ZIP archive of zip codes that Phing extracts and then imports into a database when deploying the application.

I maintain two development environments. One on a Linux server, and one locally on my Windows laptop using WAMP. So naturally, my PHP projects are cross-platform compatible and run on either Windows or Linux. And for the most part that simply means being careful about buildings paths, filenames, and file permissions.

To my surprise, the Unzip task defined in my build.xml that imports the Zip code data failed in mysterious ways: It reports success, but there’s no extracted files to be found. It works on Linux, but not on Windows.

I dug into it and found two issues. First, the Phing’s Unzip Task doesn’t have the most solid error checking, and errors coming back from the Archive_Zip PEAR component. Second, the Archive_Zip PEAR component doesn’t correctly check for absolute paths on Windows. Both problems have been reported on Phing’s web site as Issue #261 and #262.