I tweeted the link to @ricardovice who was nice enough to add my page to his canonical list of wasted domains. There wasn’t really a point to the page but I was kind of interested to see how much traffic I could get from riding the coat tails of funnier people than myself. The traffic I did receive wasn’t extraordinary but in twelve hours I got 3,800 hits. 95% of that was purely from Ricardo’s list. The remaining was from Hacker News (I shared the link in a comment thread) and my meager 100 Twitter followers. Only 24 people followed the link through to my website.

I’m not going to pretend that there are any great lessons to be learned from this. It was fun to be able to launch a concept including purchasing the domain and some dodgy Photoshop hackery in twenty minutes. Getting traffic is always nice too. As a side note I actually own a Windows Phone 7 device and think the Nokia chose was a decent one, especially considering how much Microsoft is throwing money at them.

var Car = new Class({
	Extends: Vehicle,
	Implements: [Options],
 
	options: {
		wheels: 2,
	},
 
	setOptions: function(options) {
		if (options.wheels < 3) {
			throw new Error("That's not a car.");
		} else {
			this.parent(options);
		}
	}
});

Apparently mixin methods like setOptions don’t act like inherited functions in Mootools’ class implementation. The obvious fix is to make the class inherit from the mixin directly.

var Car = new Class({
	Extends: Options,
 
	// Code omitted
}

This works, but we’ve lost the ability to create a sane object hierarchy. Thankfully the Options variable I added to the Implements array is just a reference to the class used to implement the mixin. So it is possible to call the parent method manually, just like I would without Mootool’s magic this.parent method.

var Car = new Class({
 
	// Code omitted
 
	setOptions: function(options) {
		if (options.wheels == 2) {
			throw new Error("That's not a car.");
		} else {
			Options.prototype.setOptions.call(this, options);
		}
	}
}

This works exactly like I hoped. The same approach would obviously work for other mixins like Events and Chain.

As a side note, it’s worth mentioning that Options.prototype.setOptions is actually pointing to a wrapper method which does a bit of Mootools-specific magic and validation; like ensuring the function is not protected. Fortunately the wrapper is written in a sane enough way that calling it from another object like this works OK.

The web ceased long ago of being a mere tool for sharing text documents. Images, sound and interactivity via JavaScript have all shifted the web towards the multimedia future we have long been promised. At the same time the iPhone and its App Store have raised consumers expectations of what their web enabled devices are capable of. Web developers are striving to meet these new expectations and are taking their lead from the desktop to create more interactive web applications.

Read the article on Brightlabs.

The encoded file has format major ID 1, whereas the Loader expects 4

Hoping I just missed a configuration variable I decided to check out what Zend had to say about the error.

Files to runon PHP 5.3 must be re-encoded from the original source for 5.3. 5.2 encoded files will not run.

Er… what? It turns out that Zend have decided to couple their PHP encoder and optimizer together and directly encode PHP interpreter instructions rather than develop a pesky intermediate format. It’s common knowldge that the PHP interpreter has undergone massive, sweeping changes in every major revision. I can’t imagine what thought process went on at Zend that made them think it was OK to encourage users to distribute byte code for such an interpreter?.

Zend’s lack of forsight means that millions of lines of distributed code are now locked to a version of PHP that has now reached its end of life. I can’t tell if their supposed solution of “re-encoding” the code is stupid or just lazy. What exactly do they think an encoder is for if not to stop people accessing the source code? Thousands of developers are simply expected to track down a new copy of the encrypted code through potentially shelved products, defunct companies or AWOL freelancers.

Not surprisingly, the product page for Zend Guard doesn’t mention the limitations. It actually tries to claim the complete opposite.

The only product that provides with [sic] protection for object oriented programs created with PHP 4 or PHP 5

The frustrating thing is that this is not meant to be some fly-by-night company. Zend have styled theirselves as the “official” PHP company. Ironically Zend competitor IonCube has no issue running their PHP 5.2 encoded files on PHP 5.3 installs.

A peek at my error logs did reveal one potential problem though. I’ve had well over a thousand hits to invalid URLs like http://joshduck.com/perio. These are obviously URLs which have run up against Twitter’s infamous 140 character limit and have been truncated. This results in wasted traffic for me and a waste of time for my visitors so I decided to push a quick fix.

I was already redirecting 404′s to a custom PHP page, so I added a check which redirects anyone who gets a 404 after accessing a truncated URL to the correct page. To stop similar problems from happening in the future I’ve added a short script that looks at static pages and blog posts on my site and tries to match them against any the requested URL when serving a 404 page. These URLs are then used to display a list of suggested links to the user. The script also does a little regex magic (read: hackery) to find the titles of the suggested links. Now URLs like http://joshduck.com/photo or http://joshduck.com/blog/201 will give visitors a push in the right direction.

The actual script I use is specific to the code I use for my own site, but I’ve supplied a generic version of the script below.

<?php
$request_path = $_SERVER['REQUEST_URI'];
 
// Special case: redirect anyone trying to get to periodic-table.html straight there.
if (strlen($request_path) > 2 && strpos('/periodic-table.html', $request_path) === 0) {
	header('Location: /periodic-table.html');
	die();
}
 
// Check static files.
$suggestions = array();
foreach (glob('/*.html') as $file) {
	$url = '/' . $file;
	if (strpos($url, $request_path) === 0) {
		$content = file_get_contents($file);
		if (preg_match('/<title>([^<]+)/i', $content, $matches)) {
			$title = $matches[1];
		} else {
			$title = $url;
		}
		$suggestions[$url] = $title;	
	}
}

The function takes a string with string fragments marked up inline as its main argument. It then formats the output based on the count passed into the function.

function pluralize($text, $count = 0) {
	$regex = '/\[(.*?)\]/';
	$divider = '|';
 
	// If there are no end braces [] use whole input as option list.
	if (preg_match($regex, $text, $matches)) {
		$search = $matches[0];
		$fragments = explode($divider, $matches[1]);
	} else {
		$search = $text;
		$fragments = explode($divider, $text);
	}
 
	// We accept one (which is pointless...), two or three inline text fragments.
	// If we've been given just two then case for zero should be same as two or more.
	if (count($fragments) == 1) {
		$fragments = array($fragments[0], $fragments[0], $fragments[0]);
	} else if (count($fragments) == 2) {
		$fragments = array($fragments[1], $fragments[0], $fragments[1]);
	}
 
	// Normalize count.
	// If value is array then use the number of elements as count.
	if (intval($count) <= 0) {
		$count = 0;
	} else if (is_array($count)) {
		$count = count($count);
	} 
 
	// Choose the appropriate text fragment.
	if ($count <= 1) {
		$replace = $fragments[$count];
	} else {
		$replace = $fragments[2];
	}
 
	// Replace markup with chosen option.
	$text = str_replace($search, $replace, $text);
 
	// Place our count into output (allows user to put %d inline to get count).
	$text = str_replace('%d', number_format($count), $text);
 
	return $text;
}

The tests show example usage.

$input = "There [are no pages|is 1 page|are %d pages]";
assert(pluralize($input, 0) == 'There are no pages');
assert(pluralize($input, -1) == 'There are no pages');
assert(pluralize($input, 1) == 'There is 1 page');
assert(pluralize($input, 2) == 'There are 2 pages');
assert(pluralize($input, 1000) == 'There are 1,000 pages');
assert(pluralize($input, null) == 'There are no pages');
assert(pluralize($input, array(1, 2, 3)) == 'There are 3 pages');
 
$input = "1 page|%d pages";
assert(pluralize($input, 0) == '0 pages');
assert(pluralize($input, 1) == '1 page');

I am releasing this into the public domain so feel free to copy and redistribute the code.

PHP actually has two distinct uses for the static keyword. The first and most common usage is related class method and property scoping, the second to variable scoping within in a single function.

Static Methods and Properties

The static keyword allows you to define methods and properties scoped to the class in which they’re declared, rather than one particular object instance.

Let’s start by taking a look at some code examples.

<?php
class Planet {
	static $count = 0;
	public $name;
 
	function __construct($name) {
		$this->name;
		self::$count++;
	}
 
	public function getDescription() {
		return $this->name . ' is a ' . self::getShape();
	}
 
	public static function getShape() {
		return 'sphere';
	}
}
?>

What happens to the static property $count as we start creating instances?

<?php
//Outputs 0.
echo Planet::$count;
 
$earth = new Planet('Earth');
$pluto = new Planet('Pluto');
 
//Outputs 2.
echo Planet::$count;
?>

The static property $count is attached to the Planet class and not to either of the instances. It can be referenced at any time, even before $earth or $pluto are instantiated.

We used the self keyword in the constructor method to increment the counter with the expression self::$count++. Any instance method can access a static property through the self keyword – which works much like the $this variable does for referencing instance members. Using Planet::$count to access the static property would have also worked, but it’s best to avoid referencing our class by name when possible.

Let’s try calling the static method.

<?php
//Outputs 'sphere'.
echo Planet::getShape();
 
//Outputs 'Earth is a sphere'.
echo $earth->getDescription();
?>

Just like the static property, the static method can be referenced without the need to call against a specific object instance and is called via the self keyword in the statement self::getShape().

When to use static methods and properties

The static keyword is ideal for creating class-level utility methods and for share data between objects of the same type.

It also tend to get used in older code as a way of segregating code into modules, such as Log::message() or FileHelper::getFilePermissions($filename). PHP 5.3 introduced namespaces which are more appropriate for this use case and should be where if possible.

Unfortunately there are a few issues with how static methods and properties work with class inheritance. I’ve covered some of the nuances of static scoping inheritance in one of my previous posts, which looks at how PHP 5.3′s late static binding resolves the issues.

Static Variables

Despite sharing the static keyword, static variables are unrelated to PHP’s static methods and classes. In fact they have nothing to do with OOP at all. They allow you to define a variable that persists across function calls – effectively allowing you to attach state to any function.

<?php
function hello() {
	static $staticVar = 1;
	$normalVar = 1;
	return "Hello " . $staticVar++ . " " . $normalVar++ . "\r\n";
}
 
echo hello(); //Prints "Hello 1 1"
echo hello(); //Prints "Hello 2 1"
echo hello(); //Prints "Hello 3 1"
?>

Regular variables, like $normalVar, only exist within a single function call. As soon as the function returns, the variable falls out of scope and is discarded. This is why the value of $normalVar is always 1 on each call. Static variables like $staticVar, however, are only instantiated once. The same variable (and value) will be available on subsequent calls to the function.

The statment static $staticVar = 0; is only ever evaluated on the first call to the function. Because of this magic static variables can only be instantiated with scalar values (like 1, “Hello” or true) and not complex expressions (like arrays, object instances or result of a function call). If you do want to initialise a static variable with a non-scalar value then a little boiler-plate code is needed.

<?php
function hello() {
	static $world = null;
	if ($world === null) {
		$world = new Planet('Earth');
	}
	return "Hello " . $world->getName() . "\r\n";
}
?>

I find that static variables are often useful in memoizing expensive function call. The memoize function’s signature doesn’t have to change and I don’t have to resort to creating a class with private properties for a cache values or to using global variables to store the pre-calculated value. Ryan Day has posted an example and benchmark using this method.

<?php  
$product_id = $_GET['product_id'];
$category_id = $_GET['category_id'];
 
include 'includes/product.php';
if ($_SERVER['HTTP_REQUEST_METHOD'] == 'POST') {
   	include('includes/product_update.php';   
}  
 
$template->set('categories', $categories);
$template->set('errors', $errors);
$template->set('product', $product);
?>

The authors might try and justify this by saying that the includes allow for code reuse but can you really tell what’s happening here? Where are $categories, $errors and $product being defined? We can guess that $product is defined in product.php but is it being used or even modified within product_update.php? Could we safely refactor any of these files without fearing that we’ll created unintended consequences in a rarely-used code path?

Debugging the eCommerce package with Xdebug session showed that there were almost 50 different local variables in scope by the end of a typical script. I couldn’t be certain which variables were required and which weren’t, let alone where each was defined.

Why is inline code in includes a bad idea?

There are a few specific reasons we should rule this kind of code right out:

• Our main script can’t be sure of what variables are required by included files. You won’t be able to remove or refactor variables without checking each and every includes first.
• Likewise, our parent script can’t be sure if an include will modify local variables. Each included file could potentially change a global variable in a way that is required by subsequent scripts – either intentionally or unintentionally.
• If you’re using a server with register globals turned on then you’ll need to add if (!defined('APP_START')) die(); style guards to the start of every include, so they cant be requested directly by the end user. For most core this isn’t a problem, but commercial packages must code for the worst. If an include just contained function definitions this wouldn’t be a problem.

So how exactly should I be using includes?

Each include files should contain only:

• Configuration variables or constant definitions.
• A single class. The file should be named after the class. E.g. class Product is defined in Product.php.
• A set of related functions. Don’t create “do-everything” files; break your functions down into logical groups like database functions or HTML helpers

The only time I’d ever include inline code in an include file would be if I were defining config variables in code, including a PHP-based template or if I’m initialising environment configuration (such as defining error handlers, PHP ini settings and script timeouts).

Which include function should I use?

There are quite a few statements we can choose between for including files: include, include_once, require and require_once. Which should we be using?

If you follow the best practices and just have function and class definitions in an include then it becomes obvious that you wouldn’t want to include a file more than once. Doing so would force PHP to error when it attempts to redefine a function or class. Using include_once or require_once is obviously a better choice.

A missing function or class definition is something that you should know about sooner rather than later. For that reason I find require_once a better way to define dependencies.

The other function should be reserved for special cases, for example an autoloader function that would prefer to handle missing files without E_ERROR being raised.

Summing up

Rather than helping code reuse misusing includes turns your code base into a mass of spaghetti code, which would be bad enough on its own but is made worse by the code being spread over dozens of files with no hints as to what is where.

Apache Config

The easiest way to create dynamic subdomains is with the mod_vhost_alias. This module can be enabled in the conf/httpd.conf file by adding or uncommenting the following line.

LoadModule vhost_alias_module modules/mod_vhost_alias.so

Now I can define a single VirtualHost record that will work for all of our development domains. This can be either in the conf/httpd.conf file or in an included config file like conf/extra/vhost.conf.

<VirtualHost *:80>
     UseCanonicalName Off
     VirtualDocumentRoot C:\Users\Josh\Projects\%-3\
     VirtualScriptAlias C:\Users\Josh\Projects\%-3\
</VirtualHost>

The magic in this step is the %-3 wildcard. This will substitute the third last part of the hostname into the document root. So www.project-1.example.com would map to the path C:\Users\Josh\Projects\project-1\ on my development machine.

The wildcard can contain either positive or negative numbers to refer to parts of the hostname counting from either the start or end, respectively. The module document contains some examples. I find that using the third last part of the hostname is a good choice as the domain will work with or without a “www” prefix.

Creating a loopback host

This Apache vhost magic isn’t too useful without some way of pointing each dynamically created hostname to 127.0.0.1. Unfortunately the Window’s host file can only be used to add absolute aliases; wildcards just won’t work.

I could create a wildcard DNS entry against a domain I control, but it would be easier to just piggyback on the hard work of others. A quick Google turned up the following hosts which map back to 127.0.0.1.

• hexxie.com
• smackaho.st
• 42foo.com

So once the vhost magic is set up project-1.hexxie.com or even lots.oflots.of.subdomains.project-1.42foo.com will load the project stored in C:\Users\Josh\Projects\project-1\.

This useful behaviour can become frustrating when a carefully laid-out table encounters abnormal input and suddenly decides to stop paying attention to the cell widths we’ve specified. Luckily there is a simple solution to this. All the major browsers implement an alternative fixed table layout which is specified through the appropriately named table-layout CSS property.

The demo table below should be 200 pixels wide, with each column taking up 50% of the total width. With the default layout enabled the last word clearly pushes the table beyond these dimensions. You can toggle the table-layout between fixed and auto (the default) to see the differences.

Top 5 Words

Set table-layout to fixed

On a related node, you’ll notice that overflow: hidden has no effect on table cells. You’ll have to wrap the cell contents in a container element if you want to crop it.

This simple CSS property tends to go a unnoticed, but when you need it you’ll definitely be thankful it’s there.