blogZero

The DC PHP Developers Group didn't meet last month since our old venue at the National Press Building is no longer available. After a long thread on the group's mailing list, the new location we settled on is the MLK Library at 9th and G Streets, NW. As you can see from the photo, the library is right across the street from the Gallery Place/Chinatown Metro Station (use the 9th exit) which services the Red, Blue and Orange lines. It's also a short walk from Metro Center (use the 11th Street exit), so all lines are covered. Not only does this make the location convenient, there are also a ton of bars and restaurants in the area for those who might want a pint or a bite (or both) after the meeting. The library closes at 8:30, so the meeting time has been rolled back to 6:30 PM. For folks who normally drive, the library has an underground garage. To find the entrance, drive to the interesection of H and 10th Streets, then turn south onto 10th. Turn left onto G Place, the ramp down to the garage will be on your right.

I am told the new room is quite a bit larger than we've been used to at the Press Building. This is good news as we were packed in there like sardines at the January meeting. No more standing for two hours if you arrive late! This month's meeting (tomorrow, Wednesday, March 14th) features not one, but two presentations. Ray Paseur will present Learning Algorithm for Popular Search Terms, and Ben Colombini will present A Basic Drupal Module. Details are available at the group's Web site.

I'm still waiting on Robyn to find out what the actual meeting room number is, I'll post an update when I find out.

Update: The meeting will be held in room A5, one level below the main entrance.

I normally only get a few comments, I also get some spam. The usual crap: drugs, porn, gambling... Not so many that I can't moderate them without much hassle. But not today. The same asshole was slamming me with blocks of 50 to each of several posts before I shut him down. Comments for all old posts are closed.

I had the same problem with trackbacks a few months ago and disabled them. Hey spammers! Get a fucking life, would you? I know of at least one Web developer who closed his blog for good, in part because of dealing with you pricks—and a real shame if you ask me because he had a lot of interesting things to say. Actually, you can find some newer articles from Tommy over at SitePoint.

Guess what spammers? Not one of your stupid comments has ever gotten through. You're wasting your time and, worse, mine. So why don't you just give up?

Prototype version 1.5 has just been released and includes many enhancements and bug fixes. Best of all, excellent online API documentation. For more information on the latest version, visit the Prototype blog.

Joe Hewitt has announced the final release of FireBug 1.0. Rather than go into all the details about new features and enhancements here, I'm going to refer you to the Yahoo! User Interface Blog where you can view a lengthy video featuring Joe as he demos the new version. Joe has put an enormous amount of work into this extension, if you use it regularly and it saves you time and frustration, then consider helping out with a donation.

JavaScript development just keeps getting more efficient and powerful!

In my second visit to the DC PHP Developers group meeting I joined yet another over-crowded room of local programmers for this month's presentation. I really appreciate Robyn Wyrick's efforts to put these meetings together, but it's becoming clear that the venues provided by the National Press Building are faltering—a testament to the growing popularity of the group.

Jonathan Modell was tonight's presenter. A DC local, recently returning from a 10 year stint in Colorado (my home state, or more accurately I was born in Durango and then lived in Boulder for a year), Jon has extensive experience in many aspects of Web development.

His presentation focused on how he learned to integrate Ajax technology within a core PHP system. Obviously this is a hot topic, if somewhat too hot in my opinion. In a nutshell, Ajax allows you to create an HTTP request back to a server-side script, and then dynamically insert the results into your page via the DOM—all without having to POST or GET a new page (something most PHP programmers are well versed in).

Web-based applications that quietly introduced this technique are most famously associated with Google. First was "suggest" a sort of search as you type, and then Gmail and many others that began to reinvent how Web pages could improve interactivity. In truth, it was Microsoft (circa 2000) who first implemented the XMLHttpRequest (XHR) object in their version of JavaScript (jscript). Later browsers (Firefox, Safari, et al.) followed suit.

As the function implies, the traditional payload of a server-side script called by an XHR request is XML. I know of very few people that continue to do this. By far the simplest method of dynamically insterting results into your page is to use a element with a unique id, initially hidden via CSS, then grab the data returned as normal markup (for instance a set of unordered list elements), then use innerHTML to update the DOM, and finally "unhide" the element (typically a <div>). This technique is sometimes referred to as AHAH.

JSON is another lightweight technique for returning data to the requestor. It's basically serialized JavaScript in the form of name/value pairs that you eval() on the client-side for parsing and insertion into your page. In addition to JSON, the Yahoo! Developer Network set of Web services are able to return serialized PHP. Although not as applicable to an Ajax implementation, it is none-the-less an interesting method worth investigating. If there is such a beast as a JavaScript unserialize PHP function or class out there, by all means drop me a comment. For PHP developers interested in available packages for encoding and decoding JSON data, visit this comparison of PHP libraries. As of PHP version 5.2.0, JSON support is native.

In the early stages of his presentation, Jon confessed to having tested many of the Ajax JavaScript libraries that are floating around out there, and then spoke highly of his choice to use Sam Stephenson's Prototype. He is not alone, not by a long shot. There are a number of frameworks that are built on top of Prototype: RoR, Rico, and "effects" libraries that include script.aculo.us and moo.fx. PHP frameworks with built-in Ajax support include CakePHP and ModX.

If you are doing this sort of development work, I cannot emphasize enough how much Joe Hewitt's fantastic FireBug Firefox extension will save you hours of headaches.

To conclude his presentation, Jon demoed a social networking application that displays a calendar of events and the members who are attending, locations, dates, and so on. I came away with the feeling that traditionalists in the audience were impressed how the page would update without the need to refresh it. But keep in mind that is the nature of asynchronous requests. There is nothing particularly new going on here, these are normal HTTP requests, they just happen to occur in the background via JavaScript and a little DOM magic to alter the page on the fly.

I was way overdue and finally made it down to the National Press Building (map) for my first DC PHP Developers group meeting, and I was pleasantly surprised by the turnout. The conference room (#495) was close to standing room only and additional chairs had to be brought down so everyone had a seat. I'm not sure if this was atypical, maybe it had something to do with the presentation. This, in contrast to the Washington Web Standards group meetings, which are very informal and only a handful of people (at best) regularly show up.

I suspect the reason for the strong showing was Keith Casey's presentation on the Smarty templating engine. He was obviously enthusiastic about his recent experiences working with it, and went beyond simple include/if/foreach constructs in your markup, or the "view" side of separating your application into data/code and presentation. Smarty also allows you to create custom filters, or plugins, which boil down to PHP functions that can be used in your templates to deal with special situations.

As ever, I will not mince words. I still cannot see how a "designer" would be any less intimidated by editing templates over markup embedded in a PHP module using here document syntax. I had the same impression I've been seeing for years, being this separation of the "progammer" camp and the frontend designer. To me, Web development is the whole ball of wax. You should understand everything from Internet protocols, server configuration, valid and semantic markup, CSS/presentation, database design, efficiency, security, and so on, or you pigeonhole yourself into one role.

And I didn't even mention client-side stuff like JavaScript/DOM scripting, or XHR.

Another thing that puzzles me are constant references to the MVC paradigm. "This is not a new idea," one that predates the Mac and DOS/Windows, not to mention Linux, by a long shot. MVC is rooted in the research done on GUI design at Xerox/PARC. For a generic overview, MVC is composed of:

• Model — Data and the logic to access it (the backend).
• View — Presentation or user interface (the frontend).
• Controller — Event handlers (most of which is already done by the browser unless you are using scripting).

I admit the latter isn't quite that simple. Server-side code (other than preemptive client-side validation) would include such things as processing form inputs and the security baggage that goes along with it.

My design and development philosophy has always been deeply rooted in the original principles of Unix and KISS. How many layers of abstraction are necessary? Or worse, layer after layer after layer...when does the developer lose all sense of the underlying system? I'm not advocating coding server-side HTTP responses in assembler or C/C++ (which I have done), but when I see programmers writing classes using methods that are nothing but wrappers around PHP functions, which are themselves wrappers around library calls that then make system calls...I hope you see the point of this rant.

However, it was a good presentation and Keith's strongest assertion, one I happen to agree with, is this: If you are going to use a templating engine Smarty is worth considering. It is mature, has a strong and loyal userbase, and is well maintained and documented.

Related reading: PHP Templating Engines.

Rather than manually installing either the IE7 or Firefox 2 upgrades, I thought I'd wait and see which one initiated the installation first, through an auto-update. Microsoft won this battle (I'm still waiting on Mozilla but not the least bit concerned about it). However, and this is typical for Microsoft, the installation was anything but convenient. Since the browser is so closely tied to the core OS, it took something on the order of 20 minutes and several reboots to finish.

I suspect the Firefox upgrade will be relatively painless, based on past experience. The only thing you have to do typically is restart is the browser itself, which makes perfect sense. If anything, I may have some issues with extensions that are no longer "compatible" and will be disabled after installation. Several of my favorite extensions will no longer be necessary anyway, as Firefox 2 now has the same functionality built-in.

While I'm on the topic of Microsoft, am I the only developer who's jaw dropped in amazement when they heard that Zend is now working with them to improve the stability and performance of PHP running under IIS? As far as I can tell, this boils down to a port of FastCGI as an add-on to the server. I've never used Windows on the server-side, and you couldn't pay me six figures to use IIS. Perhaps Microsoft is following IBM's lead in recognizing and supporting the role of open-source.

The Yahoo! Developer Network has just announced that starting today, the APIs for all their properties are moving to a new domain. For instance, making a REST call to api.search.yahoo.com/Path... now becomes search.yahooapis.com/Path... Developers are encouraged to update their applications with the new URI as soon as possible. Flash developers are warned that if they do not do so by December 11th, the old location will cease to function. I'm not exactly sure why Flash developers in particular are warned rather than everyone. Another caveat from Yahoo! is only the new domain will feature updates and bug fixes.

I'm sure many programmers will find this a pain, but a simple search and replace in your source code should take care of it quickly. Hell, you could even write a sed or Perl script to do it from the command line on multiple files.

And with that, I wish you all an enjoyable Samhain if you're Irish, or Halloween for the rest of us.

Over the years I've tested many so-called Web server (log file) stats packages, including Webalizer, AWStats, and lately, a slick remote JavaScript solution from Google—better known as Analytics.

The results? My visitors are me. Whoa, what the hell does that mean (and why should it come as no surprise)?

The typical profile of a visitor to this site is:

• Running XP
• Has a screen resolution of at least 1024x768
• At 32-bit color depth
• Their browser is Firefox
• Speaks English
• Is on a broadband connection
• They have JavaScript, Flash, etc. enabled

The rest fall off quickly into the long tail. And even though I've taken pains to accommodate them, I no longer worry too much about the scant 2 hits from a person on a Sun workstation with a browser that is as old as the hills.

I would probably be more concerned if I got millions of pageviews a day, but at some point you have to say to yourself, is it really worth the effort? Why should I bust my balls for the few people that are too lazy to educate themselves and install a decent browser?

After all, this site is geared for Web developers and if they are still running IE6 on Windows 98 with a dial-up connection (or whatever), then they need to wake up and smell the coffee.

Although I won't be attending the 2006 DC PHP Conference, since I am a local and a PHP developer, decorum states I should post an announcement about the gathering. The 2-day conference begins next Thursday, October 19th at the L'Enfant Plaza Hotel. The reason I'm not going? Partially because of the focus on the Federal sector, which doesn't interest me, and partially because of the expense. Now if I had an employer willing to foot the bill, I definitely would attend.

Assuming I was going to be there, I wouldn't want to miss Rasmus Lerdorf's keynote Getting Rich With PHP 5, and presentations by Laura Thomson and Chris Shiflett (both of OmniTI). It would also be interesting to meet Ben Ramsey and some local PHPers that I have only talked with via email.

For more information on who will be appearing, have a look at the conference schedule.

Following a tip from Russ I was pleased to find an interesting post on the Official Google Webmaster Central Blog titled How to verify Googlebot. In a nutshell, it explains how to use the Unix shell program host to authenticate that an IP address copied from your Web server log file really is a Googlebot and not some email harvester (or whatever).

I decided to take this a step further and demonstrate how you can automate this procedure using a scripting language. For these examples I chose PHP and Perl, although you could certainly use Python or Ruby or whatever your preferred language is, as long as it has an interface to the gethostbyname and gethostbyaddr system calls.

Using these calls under PHP is the simpler of the two approaches, as the interface to these routines are written at a more abstract level than using the Perl Socket module. Below is an example googlebot() function in PHP that returns true if the IP address parameter authenticates, although there is no 100% guarantee of preventing a spoof getting through (but it will catch the vast majority of them). A bit of test code is included.

<?php

function googlebot($ip)  {

    // check to see if this IP really is a Googlebot

    $bot = 'googlebot.com';
    $name = gethostbyaddr($ip);
    if ($name == $ip) return false;

    return (strpos($name, $bot) !== false and gethostbyname($name) == $ip) ? true : false;
}

// test it

$ip = '66.249.66.1';

echo $ip . ' is ';
if (!googlebot($ip)) echo 'not ';
echo 'a Google bot' . "\n";
?>

The Perl version is at a much lower level, very similar to the corresponding C system calls. In fact, the module is derived directly from the sys/sockets.h header file and the functions are just wrappers around these Standard C library calls. See Berkeley Sockets for more information. If you have a copy of Programming Perl, the chapter 16 Interprocess Communications section on socket programming will help, and if you are lucky enough to have a copy of the Perl Cookbook, chapter 18 Internet Services has some great recipes for DNS lookups. For really gory details, refer to chapter 14 DNS: The Domain Name System of TCP/IP Illustrated, Volume I—The Protocols.

#!/usr/bin/perl

use Socket;

sub googlebot($)  {

    # check to see if this IP really is a Googlebot

    my $ip = shift;
    my $bot = 'googlebot\.com';
    my $name = gethostbyaddr(inet_aton($ip), AF_INET) or return 0;
    my @addr = gethostbyname($name);
    my $addr = inet_ntoa($addr[4]);

    return ($name =~ m/$bot/ and $ip eq $addr) ? 1 : 0;
}

# test it

$ip = '66.249.66.1';

print $ip . ' is ';
unless (googlebot($ip)) { print 'not '; }
print 'a Google bot' . "\n";

Finally, in case anyone is interested why it's been so long since I posted anything, much of the summer I was sick as a dog and since recovering, busy as a bee. It's nice to be feeling better and back to work!