/dev/weblog

PHP 4 is end-of-life very soon. In addition to offering projects the chance to refactor and improve their application design, PHP 5 offers many things PHP 4 just doesn't. This series of posts will deal with things projects can get their fingers into that will benefit everyone.

The second: stop using global variables; I mean it.

If there's one thing that really gets under my skin, it's the use of the global variable scope to store all kinds of things that just shouldn't be there. I've seen everything from lengthy configuration settings to global arrays for event hooks (I'm looking at you, MediaWiki). There are several reasons using globals is a bad idea, but I'll point out two important ones.

First, it's a vulnerability. The problem is that variables in the global scope are just that: globally available to be read from and written to by every line of code. A great security risk comes into play when sensitive information like usernames and passwords are available to your entire application or can be easily overwritten. What happens when an important global variable containing an array is overwritten to be a string? Whoops! The whole application just broke.

Second, it's sloppy. Putting values in the global scope so they can be accessed by your functions is hackish and ugly. It leads to problems with maintenance and debugging. If you have 500 functions that access a single global variable, you have to edit every last reference to it if you ever refactor your code. Consider what happens when you want to embed one application within another and they both happen to reference a global variable with the same name: mass hysteria.

What should you do, you ask? Matthew Weier O'Phinney made some good suggestions in an entry about Embedding Applications. He says use static properties or singletons to store your globally available settings; both good ideas. Let's go over two examples I brought up earlier and how to fix them.

Configuration settings should be loaded from and accessed through a configuration class; Zend_Config, PEAR Config, Solar_Config, you name it. You can throw exceptions for attempting to access a setting that isn't there, or just return null if you wish, but no more PHP notices about unset variables or array keys. Prevent changes to these settings except by actually modifying the configuration file. Store your passwords in an encrypted form. Place the actual configuration file outside of the web root. Make an instance of your configuration class available statically in a registry or by calling a static method.

Event hooks should be managed by a class with methods to add or remove hooks. Throw exceptions for an invalid event name or an unusable callback reference. Better yet: design a plugin API that implements the Listener or Observer pattern. You don't want someone inserting an invalid hook that breaks an entire system.

So long story short: use PHP 5's static properties or static methods to make available system settings and stop using kludgy globals.

Taking note of blog entries from Derek Rethans and Sebastian Bergmann about speed improvements to PHPUnit's use of Xdebug for code coverage analysis, I obtained the latest copies of each.

Running the full code coverage report for all Xyster tests used to take about 15 minutes on my modest hardware.  The new versions of these libraries reduced that time to under 2 minutes.  I was floored.

Well done, boys!  Anyone running or using either library should definitely upgrade.

There have been three issues which have prevented me from buying an iPhone:

1. AT&T
2. Price
3. 3rd party software

Due to the fact that I'm unwilling to use hacks to unlock a phone's SIM, the first issue is going to continue at least until the exclusive use agreement with AT&T ends in a few years. The second was resolved to my satisfaction with the $200 price drop. The third, however, seemed like it may never truly be solved.

Today, however, Steve Jobs announced that they'll have an iPhone / iPod Touch SDK available (hopefully) in February. This all but confirms my suspicion that Apple wasn't allowing 3rd party apps on the iPhone simply because they didn't have an SDK ready at launch time.

He strongly suggested that a digital signature will be required for applications to run. This puts Apple in the position to determine who is allowed to develop applications and who is left out in the cold. I'm hopeful that the process of getting a certificate will be free and will only require proving your identity.

Overall, things are looking pretty good and I can't wait to get my hands on it.

Yesterday morning, Sam Spilsbury posted a mildly amusing image about the "Truth About the Internet" in a blog featured on the Planet Compiz Fusion news feed.

The joke image that was posted then promptly removed from a Compiz Fusion blog.

He has since removed the blog entry and issued an apology, no doubt at the request of Novell or some other authority figure over the Compiz Fusion project.

Anyway, since the post has been removed, I wanted to make sure it was still available

I applaud the efforts of the GoPHP5 campaign. They're getting commitments from lots of projects to adhere to minimum requirements of PHP 5.2; PHP 4 is end-of-life very soon. In addition to offering projects the chance to refactor and improve their application design, PHP 5 offers many things PHP 4 just doesn't. This series of posts will deal with things projects can get their fingers into that will benefit everyone.

The first: you have no excuse to support only one database.

PHP and MySQL for many years have gone together like bread-and-butter. Some applications still only solidly support MySQL. Nothing is inherently wrong with MySQL (shush, trolls), but not everyone can or will run it. I can't imagine many of these PHP applications are using super-proprietary MySQL features that can't be done with other systems.

Use an abstraction layer for your data access. PDO is a fantastic addition to PHP; it's been stable and in the core distribution for a good two years. If you have the extensions for each system, PDO can out-of-the-box support MySQL, Sqlite, PostgreSQL, MS SQL Server, Oracle, and recently DB2. In the Zend Framework, Zend_Db is a great tool as well. It's fast, well-thought-out, has many convenient features, and provides some more abstraction than PDO does. For instance, listing all the tables in a database, describing a table, and performing limit/offset queries.

All that's left to you the application developer is writing the SQL for creating your tables in each database system. As far as I'm concerned (Yes, and my opinion matters), you should support the "Big 4" (MySQL, PostgreSQL, MS SQL, Oracle) out of the gate; these have the widest install base.

Lastly, since you're going to the trouble of using such a data access layer, make sure you take advantage of value binding. Binding your values to placeholders in the SQL statement greatly reduces the risk of SQL injections. It also lets the DB worry about how to escape the value.

So stop being database system elitists. You'll have a wider and happier user install base if your system supports a few databases.

The second build of the Xyster Framework is available for mass consumption.

Please head over to the Xyster site to grab yourself a copy.

The API docs should be current, but the user manual won't be up until tomorrow or Friday.