/dev/weblog

Remember the days where a video would be embedded in a web page? You could stream different kinds of actual video right to your favorite video plugin! I remember a choice between RealPlayer, Windows Media, and QuickTime.

Nowadays, it seems like you only have one choice: Flash. If, however, you're on a 64-bit operating system, you don't have a choice at all. Hey, Flash developers: read that line again. People who run 64-bit Linux, for example, do not have a Flash plugin. Don't blame Linux; it's Adobe's fault.

(Yes, I know there are hacks to emulate a 32-bit browser in a 64-bit operating system, but they're hacks and not solutions or acceptable in any way. Silence.)

Thank you, Google Video, for allowing me to download the videos as actual video, yes, an MPEG-4 file so I can watch it as video should be watched. Thank you, Stage6, for using actual video implicitly.  Meanwhile, I hope and pray that YouTube and its kin will stop wrapping perfectly good video with a Flash plugin that not all of its clients have or want.

Still don't understand?  Turn off your Flash plugin and try watching some Internet videos.  You'll end up spending a lot of time at Apple Movie Trailers.

The Commodore 64 turned 25 this week!

I was 10 when my brother Ryan gave me his (this would be winter '91-'92). His C64 had a Warp Speed cartridge and a 1200 baud modem! It was hooked up to my black-and-white GoldStar 13" TV (the same one I used to play his Atari 2600).

At 10, I was using the C64 to (among other things)

• visit my first BBS
• program stupid choose-your-own-adventure games in BASIC
• play great games like California Games and Operation: Wolf
• do reports for school using Paperclip III.

You should have seen my face the first time I wrote a BASIC script that wrote to the dot-matrix printer.

I found out that a Sega Genesis controller worked great as a joystick for the C64.

The next computer I got was an IBM-compatible 486 DX2/66 that ran Windows 3.1. Quite an upgrade, but I still look back with a smile on my Commodore 64 days.

LOAD "nostalgia",8,1
RUN

Inversion of Control is one of those design patterns that once you "get it", you'll start seeing that it can be applied basically all over the place. It's the lesson of "tell; don't ask".

I've spent a good deal of time this weekend with the Xyster incubator; creating a Dependency Injection package called Xyster_Container based almost entirely on PicoContainer. The good: PHP method signatures are much more simple than Java's; only one constructor per class. The bad: PHP scalar method parameters are not typed, so you cannot use ReflectionParameter::getClass() on them. This first release won't support the LifeCycle capabilities or annotations, but at least annotations support is planned (remember, it's still in the incubator).

This Dependency Injection package will be used to replace/redo the Xyster_Application package. You'll read in Fowler's article (linked above) about the Service Locater concept, which was what Xyster_Application was intended to be. While the Locater might still be done, I think it's more important that application services can be injected into the classes that use them.

For now, read up on Dependency Injection. You'll wonder where it's been all your life.

The third build of the Xyster Framework is available for immediate (ab)use.

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

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.

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.