/dev/weblog

Just to bump the visibility, I added two GitHub gists that you might find useful.

• One is a JSON file containing all ISO 3166-1 alpha-2 country codes as of 2013, sorted by code.
• The other is a PHP file containing an array of all ISO 3166-1 alpha-2 country codes as of 2013, sorted by name.

Cheers!

As it turns out, the Number of the Beast isn't 666.

… it's 2.2250738585072011^e-308

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 third: play nice with authentication.

Your application isn't the only kid on the block, especially if it's a single-purpose application like a forum or an issue tracker. Nothing is more frustrating than having to hack your application so my users don't have to login to different parts of my Web site.

Clay Loveless made a post in June of '06 stressing the stupidity of "loner applications".

You can remedy your application's isolation using one of two things: OpenID authentication or some kind of authentication plugin API or adapter.

Implementing OpenID is perhaps the lesser solution. Users would still have to put their OpenID address into each application on a site to login; it's not nearly as bad as having separate passwords, but still less convenient than a unified sign-on.

The preferred solution to this mess is to provide an API for others to write pluggable authentication modules and then pick which one is being used in a configuration somewhere. I applaud DokuWiki for their very simple and effective implementation of such an adapter. I also have experience with MediaWiki's plugin system, but don't get me started on the MediaWiki source code. Mantis has a decent start on an authentication plugin, but it still leaves much to be desired.

If you're going to start an authentication adapter system from scratch, may I suggest Zend_Auth? Adapters are a breeze to implement and Zend_Auth takes care of persisting a user's session. If you're using the Zend_Controller MVC, may I also suggest Xyster_Controller_Plugin_Auth? It gives you the ability to specify the MVC dispatch locations for login prompting, success, and failure.

Actually, adapters and plugins are a good idea for any software. If I have to edit a single source file for your application, you're doing a poor job at keeping extensibility in mind.

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.

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.