PHP in Action

I went to the UK PHP conference, and now finally I get to blog about it. There was actually a "blogathon" following the conference, but I had to leave early to get the blissful experience of returning to snowed-down Norway half asleep in the middle of the night.

Where are all the other blog posts about the conference? I don't know; I guess I'll have to  Google for them in the coming weeks.  The organizers should have put up some space for links on the conference web site. And strongly encourage people to use it. Last year's PHP Vikinger unconference had a blog of its own, but there's practically no post-conference material there.

Anyway, that's all I have to complain about. The conference itself was wonderful. All the speakers had excellent content and presentation. And everything was about subjects I'm currently interested in.

I'll have to come back later to what the speakers talked about. Lots of interesting points to discuss. It could take me months to finish processing all that. 

This is embarrasing: I just deleted all the comments in this blog, and I didn't have a recent enough backup to recover them. I was deleting spam and pressed the delete button too fast.

There we'rent many comments, but I apologize to those who had commented. I promise not to do it again.

Implementing a new piece of software is working with a black box that doesn't even exist yet. You know something about what's supposed to come out of the black box, but typically not much.

So  where and how on earth do you  start?  Let's say we know one thing about the result; call it the known fact. Do we start by  making educated guesses about what should be in the black box? A lot of development is like that.

The smarter way to do it is to start with the smallest possible step from the known fact. What is the smallest inference, the one that wil tax our intelligence the least? Of course, you may want to challenge your intelligence, but I'm talking about a way to make the most difficult problems tractable by chunking them so small you can do them while drunk.

Enough of this philosophical mumbo-jumbo; what does it mean in practice? Well, it's test-driven development, and more specifically, it's what Kent Beck calls the Fake It patttern. You implement a test for the result, then you hard code the result. It's an absolutely weird idea that's magical in its effect because it get you started. And as the German expression goes, aller Anfang ist schwer--all beginnings are difficult.

Let's say we want to create a class to represent URLs. What do we know about it? It's going to be able to do all sorts of parsings, takings-apart and gluings together, but above all, it must be able to spit out a URL string. So we start by implementing a test for this behavior:

class UrlTest extends UnitTestCase {

    function setUp() {
        $this->url = new Url('http://www.example.com');
    }

    function testUrlObjectReturnsUrlString() {
        $this->assertEqual('http://www.example.com',$this->url->toString());
    }
}

Now we do the simplest thing that could possibly work by creating the class like this:

class Url {
    function toString() {
        return 'http://www.example.com';
    }
}

It's shocking, of course. This class doesn't listen, it just talks. And it's completely phony and useless except as a first step that will lead to something else. Slightly better is to actually keep the URL string in an instance variable:

class Url {
    private $urlstring;

    function __construct($urlstring) {
        $this->urlstring = $urlstring;
    }

    function toString() {
        return $this->urlstring;
    }
}

It's still pointless, but now we're ready to choose another small step that will actually do something real: get the host name or something else interesting. And we can do that by writing a test for that single behavior and implementing it with, say, a single regular expression. No grand plans are necessary, at least not until we've learned something about the nature of the task by tinkering with it. Actually, it's probably wise to use the built-in PHP function parse_url(), not least because it's likely to handle weird variations appropriately. But the point is we could do without it if we wanted to without getting confused by the complexity of the problem.

• Main
• Archives

• How code comments deteriorate
• How harmful is "harmful"?
• Comments considered harmful
• The one-line web framework
• How to test everything
• Zend_Test
• More beautiful code
• Beautiful code
• Refactoring is design
• Get links with XPath

• Application design [19]
• PHP [28]
• Refactoring [3]
• Frameworks [4]
• Testing [13]
• Ruby [3]
• Smidig2008 [1]
• Java [1]
• General [0]
• CSS [0]
• JavaScript/Ajax [0]
• Me [4]
• Vim [1]
• Humor [0]

• RSS 0.90
• RSS 1.0
• RSS 2.0
• Atom