![]() |
|
PHP News: stay one step ahead with the very best and latest in PHP
|
Design your website quickly and intuitively
|
Jump to latest PHP news by BlogZero, PHP Net and ILoveJackDaniels:

blogZero
Web Development Community News, Culture and Commentary
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. enabledThe 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!
People love to argue. A recent thread on the DC Perl Mongers mailing list opened yet another discussion of which CPAN module is the best for sending email.
Most Unix systems, at least the open-source flavors I use most frequently (FreeBSD and Linux), have sendmail installed. So when I need to send an email from a Perl script I just roll my own code to do it. You could argue that it's too simplistic because it's procedural or it isn't portable, but it works, it's fast and I have control over the code.
The problem with using someone else's module is you're tied into the way they think, and it can be difficult or time consuming to modify the code to add a feature or fix a bug.
Who made this rule that you have to use a module for everything or that object-oriented methods are somehow intrinsically superior to procedural programming? Don't get the wrong idea, I have nothing against modules or OOP. It would have taken me a hell of a lot longer to write many of the Perl scripts I've written without wonderful tools like CGI.pm and DBI. Not to mention about a 100 others.
#!/usr/bin/perl $to = 'you@somehost.com'; $from = 'me@somehost.com'; $subject = 'test sendmail'; $body = <<EOB; Hello from Perl/sendmail EOB if ($error = sendmail($to, $from, $subject, $body)) { die "Can't sendmail: $error\n"; } print 'mail sent'; sub sendmail($$$$) { my @args = ( 'to', 'from', 'subject', 'body' ); my $arg; foreach $arg (@args) { unless ($$arg = shift) { return (caller(0))[3] . ': missing $' . $arg . ' parameter'; } } my $sendmail = '/usr/sbin/sendmail'; my $switch = '-t'; open MAIL, "|$sendmail $switch" or return $!; print MAIL <<EOM; To: $to From: $from Subject: $subject $body EOM close MAIL; return; } # sendmail()If you are a PHP developer in the New York metropolitan area or are planning a trip there in mid-June, then consider attending the NYPHP Conference and Expo (NYPHPCon). Running from June 14-16 at the New Yorker Hotel (map) in midtown Manhattan, the conference features three days of sessions, tutorials, exhibits, and networking events. Organized by the NYPHP Community and sponsored by many leading companies, the conference focuses on technical solutions and business strategy. You will have the opportunity to meet reps from Oracle, IBM and other top companies, network with fellow developers and business leaders, and have a look around Manhattan while you're at it.
During the two-days prior to the conference you also have the opportunity to receive in-depth training at the Programmer and Designer Track Workshops. Sorry, early bird specials are closed, but you can still register online at a substantial savings over doing so onsite.
Most crontab entries are very simple. For instance, "run this script once every day exactly at midnight." To do this you would add the following line to your crontab file:
0 0 * * * /path/to/script
Depending on your version of cron, you could also use the shorthand string @midnight or @daily. But what if you need to run a script between the hours of 8am and 6pm every two hours, but only on Mondays through Saturdays? That's exactly the problem I had to solve earlier today. Although I use cron quite a bit, I needed a quick syntax refresher course covering some of the more advanced features.
So naturally (like we all do) I reached for my browser and fired up Google. After 20 wasted minutes trying various keyword search combinations, wading several result pages deep and following links, it hit me. Do'h! All the information I needed was right on my FreeBSD server. Man pages contain a wealth of information about your system and have been around for many years. Decades actually. Many people forget that Unix was originally designed as a text processing and technical manual printing system. The entire system is documented using these manual pages and they are designed for viewing, searching and printing. I once kept large chunks of the standard C library in a 3-ring binder.
Since crontab is a file format, I went back to my shell and entered:
$ man 5 crontab
And within a matter of minutes I had the solution. The point of all of this is sometimes we are over reliant on the Web and search. Often the information we are seeking has been there all along. Call me old school, I still like books too.
By the way, the crontab entry looks like this:
0 8-18/2 * * 1-6 /path/to/script
If you really have to use a browser, try this "advanced crontab tutorial."
How ironic, I posted this exactly at midnight.
Yahoo! has just upgraded their Maps Beta product. For end-users, you now have Satellite and Hybrid views. A major complaint from many users to date has been the lack of maps outside the US. They are now rolling out coverage across the globe, although from my tests the results are still pretty limited. For a couple of examples, check out:
Hong Kong StuttgartFor developers, several of the Map APIs have also been upgraded to Version 3. These include:
Ajax Getting Started Guide ActionScript/Flash API GuideWhy it's taking so long for a killer mashup that integrates geotagged Flickr photos with Yahoo! Maps Beta is a mystery to me, although I can guess who is working on it. To stay up to date on the latest development news, join the Yahoo! Maps Developer Community.
There is never any need to get lost.
The W3C Web API Working Group has released the first draft of The XMLHttpRequest Object, a specification designed to formalize the programming interface between a browser's scripting language, typically JavaScript, and asynchronous HTTP requests made to a Web server.
The XMLHttpRequest object is implemented today, in some form, by many popular Web browsers. Unfortunately the implementations are not completely interoperable. The goal of this specification is to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code. In order to do this, only features that are already implemented are considered. In the case where there is a feature with no interoperable implementations, the authors have specified what they believe to be the most correct behavior.Although the Working Group authors are many and represent a number of influential organizations, the principle editor of the document appears to be Anne van Kesteren of Opera Software. Most Web developers are familiar with Anne's work through his Weblog about Markup & Style and long involvement with Web standards
The second version of the PHP Cheat Sheet, a quick reference guide for PHP, with functions references, a regular expression syntax guide and a reference for PHP's date formating functions.
Adding and removing variables to and from URLs using PHP is a relatively simple process admittedly, but I have a couple of functions I use often to make the process even less time-consuming.
The third part of the Writing Secure PHP series, covering weak passwords, clients and more advanced topics.
The "Data Handling" section of the php.ini file.
The "Error Handling and Logging" section of the php.ini file.
|
||||||