sklar.com/blog

I just posted on the Ning code blog about the PHP microbenchmarking framework we released:

Here are some links that are related to the Editor/IDE panel I'm on today at the 2008 DC PHP Conference:

Chris often cites this xkcd cartoon in security talks, since it's a) funny and b) a good example of SQL Injection.

I was curious to see what sorts of shenanigans one can get away with in a legal name. I'm still waiting to hear back from the NYC agency that issues birth certificates but here's what the US Social Security Agency told me:

So with hyphens and apostrophes you might be able to get away with a little syntax error mischief, I suppose.

Turns out the SSA has really detailed public documentation of all their procedures.

I had never heard of Haskell Curry before I read the preface to SICP just now, but it occurs to me that his distinction of having each of his names (first and last) turned into a term used in the discipline he studied (Haskell the programming language and Curry the operation) is sort of like how Glenn Seaborg, working at LBL, could have a letter addressed to him using element names (seaborgium / lawrencium berkelium / californium / americium.)

Who else can you think of that falls into this admittedly fuzzy-edged bucket?

How many different ways (in PHP) are there to concatenate the string values in two variables and put the result in a third variable?

Here are a few to start:

I would say something like "Of course, this entire exercise is just for fun and in practice is totally useless," but whenever I start out thinking that something actually productive eventually emerges. So perhaps this is totally useless, perhaps not!

The slides from my "API Design in PHP" talk at the 2007 DC PHP Conference are up at http://www.sklar.com/files/dcphp-2007-api-design.pdf. Enjoy!

Jon Aquino, my talented cow-orker built a time-lapse view for Subversion. This is fantastic.

We switched from Perforce to Subversion recently (at Ning), and one of the things that I miss about Perforce was its handy time-lapse-view feature. No longer!

The slides from my API design talk yesterday are available.

If you missed Zendcon, come to the DC PHP Conference in a few weeks. I'll be talking about API Design there on November 8.

As Diego and Gina have pointed out, the Ning Platform has just celebrated its second birthday.

The past two years have been a lot of work and a lot of fun. It's been gratifying to see the crazy, heartwarming, innovative uses folks have come up with for the platform and also extremely rewarding to work with such talented people.

I wonder what I'll have to say in a blog post a year from now that links to this one?

Zendcon (aka "The 2007 Zend/PHP Conference and Expo") draws near. I'll be there giving a talk about API Design in PHP and undoubtedly getting sucked into various conversations about how PHP's disorganized ugliness is its greatest asset.

+1 to what ndg said in response to Jacob's post about e-mail address validation.

I think Jacob sort of touches on this in his post but too often it's not explicit what people are looking for under the vague and broad umbrella of "e-mail validation".

If it's "Did the AOL user signing up for my site forget the '.com' part at the end of the address?" then some pretty simplistic text-based matching will do.

If it's "Is the address supplied a valid mailbox that is controlled by the person who is supplying it to me?" then all the string parsing in the world isn't going to save you. You'll need to roundtrip something out to the mailbox with confirmation instructions. And even then you're not out of the woods -- maybe the user's mailbox is full, or a transient DNS error is causing a problem.

I think e-mail address validation tends to be a bit of a tarpit for nerds (myself included) because the delicious complexity of RFCs 822 and 2822 makes writing code to handle the grammars they describe a fun challenge. That makes it easy to forget what the point of the address validation in the real world actually is: handholding well-meaning users that may have made a careless mistake, or robust protection against malicious users, or bot protection (in which case you probably want to ban RFC-valid addresses that have known-suspicious domain names or components), etc.

I'm going to be giving a talk on "API Design in PHP" at ZendCon 2007 in October.

Our PHP API at Ning is a little over two years old at this point. There are some things I love about it that I think we've done really well, some things that we have revised, some things we can do better, and some interesting things planned for the future.

The talk is all about what we've learned developing, building, and supporting the API with both a ferocious devotion to backwards compatibility and a rapid new release cycle.

See you in October!

A PHP issue that comes up over and over again is how the static keyword doesn't know about inheritance. That is, code such as:


class Masons {
    static $where = "World-wide";
    static function show() {
        print self::$where;
    }
}

class Stonecutters extends Masons {
    static $where = "Springfield";
}

Stonecutters::show();


prints World-wide, not Springfield because the self inside Masons::show() is bound at compile time to the Masons class. This is different than how $this works in instances, so it can be unexpected.

There are plenty of good reasons why PHP 5 works this way and it seems that in PHP 6 the static keyword will be able to be used in place of self to get the dynamic behavior a lot of folks are looking for (that is, print static::$where; in Masons::show() would cause Stonecutters::show() to print Springfield.

All well and good once PHP 6 is done.

In the meantime, I was noodling around with runkit and came up with some glue that lets you do something like this:


class Model {
    public static function find($class, $filters) {
        // This method would actually do an SQL query or
        // REST request to retrieve data
        print "I'm looking for a $class with ";
        $tmp = array();
        foreach ($filters as $k => $v) { $tmp[] = "$k=$v"; }
        print implode(', ', $tmp);
        print "\n";
    }

    public static function findById($class, $id) {
        return self::find($class, array('id' => $id));
    }
}

class Monkey extends Model { }

class Elephant extends Model {
    public static function findByTrunkColor($color) {
        return self::find(array('color' => $color));
    }
}


And then after the mysterious (for a few seconds) glue:

MethodHelper::fixStaticMethods('Model');


you can do:

Monkey::find(array('name' => 'George', 'is' => 'curious'));
// prints: I'm looking for a Monkey with name=George, is=curious

Elephant::findById(1274);
// prints: I'm looking for a Elephant with id=1274

Elephant::findByTrunkColor('grey');
// prints: I'm looking for a Elephant with color=grey

Monkey::findById('abe');
// prints: I'm looking for a Monkey with id=abe


(The innards of MethodHelper after the jump...)