Mike Pearce – blog

… to describe your sprint backlog process, it’s probably too complicated!

My thoughts are with the people of Japan who, right now, are under an onslaught of enormous proportions from mother nature. First an earthquake to fuck shit up, then, if that’s not enough, a tsunami to mop up anyone lucky enough to have survived the initial catastrophe.

Nice one mother nature, sometimes you can be a bitch.

I saw a tweet today that said:

Niecee
Hellicopter flying over me on Ocean Blvd urging people to move away from the water but herds of people still coming hoping to see a #tsunami
11/03/2011 16:52

And it reminded me of the sci-fi book, The Moon is a Harsh Mistress. Where a penal colony on the moon starts a revolution and demands independence from earth. The only weapon they have is a giant catapult used for firing barges of grain at the earth. They repurpose it to throw rocks. These impacts are worked out by a computer, so they know where they’re going to hit. They inform the people of earth when and where these rocks will hit (mostly government buildings and military installations) instead of people moving AWAY from the impact zones, they move toward them instead, to get a better view of the show … and end up dead.

Don’t be stupid people, stay away from the danger.

I used to have an account with Servelocity. They were fairly cheap, but their implementation of Plesk was shockingly buggy and their customer service was non-existent, even if you used the premium support line. I did kind of feel sorry for the staff working there as they even seemed to give up using the forum after a while as they would just get trolled.

Today, I received this email and it’s testament to everything that is wrong with a webhost that has this on their support page: As the majority of our customer base are highly technically able and in order to provide the most competitive product possible our private servers do not come with support as standard.

Dear Subscriber,

We advise that Servelocity Ltd.  will not be able to offer services to you after the end of March 2011.

We thank you for your support in the past.

Yours Faithfully,
Servelocity Ltd.

So long Servelocity.

//////////////////////////////////////////////// http://www.thimbl.net/award.html

Why Thimbl should win the Transmediale/Mozilla Foundation Open Web Award

Thimble by zimpenfish @ flickr

The Telekommunisten Collective thinks that people should finger each other as often as possible. Maybe even several times a day, hell, why not once an hour? As often as you like!

People thrive on interaction with other people. Mutual stimulation is a deeply felt human need, a key characteristic of what makes us human. Imagine that instead of reading your status updates on Twitter or Facebook, your friends would just finger you instead.

The Finger protocol was originally developed in the 1970s as a way to publish user and status information, such as who you are, what you’re working on, and what you’re doing now. This is how the relatively few folks with access to networks posted pithy personal bios. From when colourful polyester pants were still groovy until the 90s people used to Finger each other all the time! Finger evolved into a completely decentralized system, where any user could finger any other user as long as they were both on the Internet. There were no big companies in the middle to control these users, or monitor them, or try to turn their personal data into money. Fingering was a personal matter between users, direct and unmediated, and nobody really knew exactly who was fingering who. Promiscuous, right?

Sadly, these heady days of open relationships slowly came to an end. Finger software was developed before the Internet had many users, and before development was driven by commercial interests. The idea was bold, but the software was primitive. Capitalists and their desire for profit have no interest in such freedom and promiscuity and chose to instead fund centrally controlled systems, in which they are intermediaries. Investors wanted control, so that they can commodify and monetize these relationships. Instead of users fingering each other with reckless abandon, people are now stuck with centralized, privately owned services like Facebook; chaperoning their relationships, imposing user policies on them, and monitoring and monetizing their conversation.

Back in June 2010, Telekommunisten had had enough! “People must be freed from these puritanical, controlling, consumerist, profit-seeking cults”, they thought. If witchcraft, wet shaving, rocker hair and skinny jeans could make comebacks, why not Finger? The Thimbl project was born, and immediately started working on giving the project an online identity and releasing tools to create a microblogging platform built on Finger, that groovy 70s protocol.

In October, Telekommunisten received the news that Thimbl was one of three projects nominated for Transmediale/Mozilla Foundation Open Web Award and almost immediately, Thimbl broke on Hacker News and the project started to attract significant interest. Thimbl started popping up all over the place: P2Pfoundation, ecopolis, alt1040, O’Reilly Radar, OneThingWell, Ecrans, reboot.fm… Evan Prodromou from competing service identi.ca even took a playful swipe at us!

Finger was becoming cool again. The masses were longing to finger each other!

In a few short months, without much in the way of a marketing strategy and with a budget that could be stored in a matchbox, Thimbl has managed to gather over 250 followers on Twitter – the very service it someday hopes to compete with – and has been the subject of hundreds and hundreds of tweets. Thimbl even has a small following on identi.ca, which is closer to the heart of Thimbl than the service with birds and whales. The thimbl.net website has over 300 ‘Likes’ with its Facebook button and the Telekommunisten Facebook fan page is abuzz with talk of Thimbl. The project has even gathered over 100 votes on the Drumbeat platform. Not bad for a project that was completely unknown to all but a handful of people when the award nominations where announced!

Still, the problem remains: Capital will not fund free platforms like Thimbl. Even with the buzz Thimbl has, building a community big enough to actually create a viable platform without financing is a major challenge.

Wouldn’t it be great if Thimbl could actually win the Open Web award? The endorsement of Transmediale and the Mozilla Foundation would be a tremendous boost for the project, perhaps enough to give the community the needed escape velocity to break free from centralized social media like Twitter and Facebook and make Finger the once and future king of personal status updates! Transmediale and The Mozilla Foundation had a great idea: instead of having a jury decide the winner of the award, present three projects to a community engaged with the open web and its technical, political and artistic dimensions. Mozilla had recently launched the Drumbeat project, just for this purpose, as a hub for projects that embrace the open web to get support and find contributors. So it made perfect sense for Drumbeat to host the voting for the award.

Drumbeat is a fantastic initiative from Mozilla and has a really promising future. However, Drumbeat is a relatively new platform. As a result none of the projects received much attention from existing Drumbeat users or from the Transmediale community jumping on to Drumbeat to participate. The idea that an impartial community would consider the three projects and select a winner didn’t quite work out. Instead, it has become a competition to rally the existing supporters of the three projects to sign up to Drumbeat and vote for them specifically, without genuinely considering voting for the others. This means that, honestly, the vote count is about as impartially meaningful as a Florida election run by Diebold.

Thimbl is up against two cool projects as candidates for the Open Web Award; Booki, the book publishing platform behind FLOSSManuals and many great book writing sprints, and Graffiti Markup Language, a project to enable analysis and archiving of graffiti writing which has the support of many awesome, large and active communities like F.A.T. Lab and eyebeam. If the open web award is really meant to give well-earned support to existing, successful projects like Booki and GML, then we will celebrate their success with them at the award ceremony in a few days. We readily concede that Thimbl has not yet achieved anywhere near what these projects have and that our community is much, much smaller and far less known.

Unless we succeed in our desperate bid to convince Lady Gaga to dump Polaroid and instead dedicate her star power to the cause of ushering in a new golden age of rampant fingering, we are very unlikely to win based on Drumbeat vote count. But if Open Web Award aspires to “clearly demonstrate the unbound potential of the open web in ways that can spark new thinking and practices,” as stated, then, damn it, Thimbl is the most about the open web!

We live and breathe the open web, directly addressing the technical and social issues facing the open web in every aspect of the project, in the code, and in our manifestos. We talk to anyone who will listen about how the open web is not just critical to the future of the Internet, but to society itself. And people are beginning to take notice.

Selecting Thimbl for the Open Web Award at Transmediale would be one heck of a powerful spark. Igniting the new thinking and practice that led to the idea of Thimbl with a clear and bold statement of support for an open web that is truly open! The multitudes are trapped and frustrated, clinging to their social interactions within sterile, commercial platforms, longing for wanton, unbridled realms of contact.

Join us in inscribing upon on our banners the revolutionary slogan, “Don’t be a Twit, it feels good to be fingered!”

Give Thimbl the Open Web Award!

With Kind Regards, Your Telekommunisten.

http://www.thimbl.net /////////////////////////////////////////////////////////////////

(psst… pass it on)

Hopefully my illustrious readership have gleaned at least one or two useful things from my blog here. I’ve enjoyed writing the posts and I just hope you’ve enjoyed reading them.

I’ve also enjoyed giving the two talks at PHP London How Not To Write A RESTful API and Writing Effective User Stories). It’s because of this that I’ve decided to submit a paper to talk at the PHP London Conference 2011. I’ve got a few ideas of things I’d like to talk about; including past talks (for a wider audience, natch. Doesn’t harm that I don’t have to write a new presentation either!) but I thought I’d ask my tiny readership if there was anything you’d like to see.

Well, is there? Leave a comment below, or email/twitter me. mike@mikepearce.net and @MikePearce

Injection Dependency STRAIGHT INTO YOUR OCCIPITAL LOBE!

I’ve struggled with the concept of unit testing and how to deal with dependencies a lot in the past. The solution seemed to be just out of reach. I knew there WAS a solution and not a hacky one either, one that was elegant and worked well. I never really found it. PHPUnit seemed to be well written but not particularly well documented and a lad like myself, one who is a few sandwiches short of a picnic at times, almost gave up.

Almost.

I know and understand the benefits of unit testing and I understand the disadvantages. Unit testing is a weapon that can mite out retribution and vengence if not used properly. There are plenty of posts on the web about the wrong way to unit test and the hazards of them, so I’ll leave you to find them.

Aaaaaanyway, writing your application so that it uses the dependency injection pattern is the best method for making sure it’s uncoupled and modular enough to write some efficient, unit tests (ie: tests that test just a unit of code). Especially when they depend on objects which link to databases, or web services or other crazy stuff that you don’t really want or need to instantiate in your test suite. The problem that I encountered time and time again was when you mocked an object to pass into one test, then you wanted to actually test the REAL version of the object you’d previously mocked or stubbed, you couldn’t. PHP would throw an error:

Code.php:

<?php
    class badger {
    }
    class badger {
    }

%> php code.php
Fatal error: Cannot redeclare class badger

See? It’s a predicament, especially when you want to do some unit testing.

<?php
class weather {
    /**
     * @param string $postcode
     * @return object
     */
    public function getWeatherFromPostcode($postcode) {
        //.. connect to a web service
        $weather = new ThirdPartyWeatherService();
        return $weather->getWeatherAt($postcode);
    }

}

class stuff {

    public function isItRaining($postcode)
    {
        return (
                    $this->weather->getWeatherFromPostcode($postcode)
                          ->precipitation = 'RAIN'
                        ? TRUE
                        : FALSE
               );
    }

    public function injectWeatherObject(weather $o) {
        $this->weather = $o;
    }
}

class doTest extends PHPUnit_Test_Case {

    public function testIsItRaining() {
        $stuff = new stuff();
        $stuff->injectWeatherObject(new weather());
        $this->assertTrue($stuff->isItRaining('RH2 9SS'));
    }
}

The problem with the above code is that, the test may pass or false randomly depending on the weather. Clearly, this is a nightmare! No one thinks that there code is going to behave differently depending on the weather, that’s CRAZY TALK MAN! Well, this code would, especially if the weather is as strange as it is in Reigate.

So, how to get round this: dependency injection and mock objects. See, we had the foresight to inject the weather object into the stuff object. That means we’re halfway there (if you’d just instantiated the weather object in the stuff object, this would be much harder). To workout the solution to this, we need to ask a question: What are we testing?

The answer is, we’re testing the stuff class and, more specifically, the isItRaining() method. So, what do we need to do to test that? Well, for a start, we don’t actually need the full weather object (which might connect to a 3rd party service, which in turn, might be down, or slow or whatever – meaning the test might fail NOT because the unit is broken, but because a dependency is…), we only need to AN object with a ‘precipitation’ property. So, this means we can mock it up. Woo!

Code.php:

class weather {
    /**
     * @param string $postcode
     * @return object
     */
    public function getWeatherFromPostcode($postcode) {
        $w = new stdClass;
        $w->precipitation = 'RAIN'
        return $w;
    }

}

class stuff {

    public function isItRaining($postcode)
    {
        return (
                    $this->weather->getWeatherFromPostcode($postcode)
                          ->precipitation = 'RAIN'
                        ? TRUE
                        : FALSE
               );
    }

    public function injectWeatherObject(weather $o) {
        $this->weather = $o;
    }
}

class doTest extends PHPUnit_Test_Case {

    public function testIsItRaining() {
        $stuff = new stuff();
        $stuff->injectWeatherObject(new weather());
        $this->assertTrue($stuff->isItRaining('RH2 9SS'));
    }
}

Now, we know that it’ll ALWAYS be raining in Reigate (which sucks, but well, what can you do? All in the name of great testing, right?). This test will now pass, unless someone changes isItRaining() and it breaks. But that’s what unit testing is for.

Huzzah, let’s party. Except, we’ve introduced a problem here; what happens if we now weant to test a method in the REAL weather object:

Code.php

class weather {

    public function getTypesOfCloud($type)
    {

        $clouds = array
        (
            'high' =>
                array('Cirrus', 'Cirrocumulus', 'Cirrostratus')
            'medium' =>
                array('Altostratus', 'Altocumulus',)
            'low' =>
                array('Stratocumulus', 'Stratus',)
        );
        if (isset($clouds[$type])) {
            return $clouds[$type];
        }
        else {
            return FALSE;
        }

    }
    /**
     * @param string $postcode
     * @return object
     */
    public function getWeatherFromPostcode($postcode) {
        ..
    }
}
class weather {
    /**
     * @param string $postcode
     * @return object
     */
    public function getWeatherFromPostcode($postcode) {
        $w = new stdClass;
        $w->precipitation = 'RAIN'
        return $w;
    }

}

class stuff {

    public function isItRaining($postcode){ ... }

    public function injectWeatherObject(weather $o) { ... }
}

class doTest extends PHPUnit_Test_Case {

    public function testIsItRaining() { ... }

    public function testGetClouds()
    {
        $weather = new weather();
        $this->assertEquals(
            array('Cirrus', 'Cirrocumulus', 'Cirrostratus'),
            $weather->getTypesOfClouds('high')
        )
}

%> php code.php
Fatal error: Cannot redeclare class weather

OMFG! Now we’ve got two classes called the same thing, this makes it impossible to TEST THEM OMG NOO!

I should mention here that you’ll probably not have all your tests in one file, they’ll probably be split across multiple files and directories. They’re all in one file here to make things easier. However, this doesn’t mean you won’t get the same problem.

The easier thing to do would be to rename the mock weather object to something like ‘weatherMock’, but we can’t because our stuff class expects the object that is injected to be an instance of the ‘weather’ class.

“Well, remove the typehinting dumbass!” I hear you cry, throwing your hands in the air.

I could, but I shan’t. Because I WANT the typehinting there, it’s a conract and I am BOUND by it. I must have a weather object passed in, I can’t have ANY OLD object being passed in now can I? What would happen if someone passed in a ‘cheese’ object? DOES CHEESE HAVE PRECIPITATION?

Anyway, this is how I chose to solve this problem:

Code.php

<?
namespace Weather {
    require_once 'PHPUnit/Framework.php';
    abstract class abstractWeather {
        public function getTypesOfCloud() {}
        public function getWeatherFromPostcode() {}
    }

    class weather extends abstractWeather {

        public function getTypesOfCloud($type)
        {

            $clouds = array
            (
                'high' =>
                    array('Cirrus', 'Cirrocumulus', 'Cirrostratus'),
                'medium' =>
                    array('Altostratus', 'Altocumulus'),
                'low' =>
                    array('Stratocumulus', 'Stratus'),
            );
            if (isset($clouds[$type])) {
                return $clouds[$type];
            }
            else {
                return FALSE;
            }

        }
        /**
         * @param string $postcode
         * @return object
         */
        public function getWeatherFromPostcode($postcode) {
            // Commented as this doesn't actually exist.
            //$weather = new ThirdPartyWeatherService();
            //return $weather->getWeatherAt($postcode);
        }
    }
}
namespace WeatherMock {

    class weather extends \Weather\abstractWeather {

        /**
         * @param string $postcode
         * @return object
         */
        public function getWeatherFromPostcode($postcode) {
            $w = new \stdClass;
            $w->precipitation = 'RAIN';
            return $w;
        }

    }

}

namespace Main {
    class stuff {

        public function IsItRaining($postcode) {
            return (
                        $this->weather->getWeatherFromPostcode($postcode)
                                      ->precipitation = 'RAIN'
                            ? TRUE
                            : FALSE
            );
        }

        public function injectWeatherObject(\Weather\abstractWeather $o) {
            $this->weather = $o;
        }
    }

    class doTest extends \PHPUnit_Framework_TestCase {

        public function testIsItRaining() {
            $stuff = new stuff();
            $stuff->injectWeatherObject(new \WeatherMock\weather());
            $this->assertTrue($stuff->isItRaining('RH2 9SS'));
        }

        public function testGetClouds()
        {
            $weather = new \Weather\weather();
            $this->assertEquals(
                array('Cirrus', 'Cirrocumulus', 'Cirrostratus'),
                $weather->getTypesOfCloud('high')
            );
        }
    }
}

So, the solution is two fold.

1. I made both the weather classes (real and mock) an extension of the abstractWeather class. This is good, because it means my contract is still in place (if a little more flexible) and I can force people to use the methods prescribed.
2. I wrapped the abstract class and the real object in a namespace and the mock weather object in another namespace. This means I can have two instances of a class named ‘weather’ as they reside in different namespaces. I could have named the mock weather object as ‘weatherMock’ and not had the namespaces, but adding them makes it much cleaner. If I know I’m using namespaces and not going to get into trouble with conflicting error names, I can be confident that, with a HUGE library of tests, when they’re all run together, I’m not going to get the error (I don’t know if a colleague created a weatherMock() class two days ago for a different part of the application, but for use in the same suite of tests – using namespaces means it doesn’t matter).

Now, you could use interfaces instead of abstract classes, but I prefer the abtract classes as they give you something concrete to work from and, really, if you’re wanting to ride modular, encapsulated code, then you SHOULD be using abstract classes.

The only other thing to remember (which caught me out) is that stdClass lives in the global space, so, whenever instantiating a new stdClass, it must be pre-pended with a forward slase: \stdClass (the same goes for anything that ISN’T in a namespace when you’re working in one: \PHPUnit_Framework_TestCase

Feel free to copy this code and run it in your own environment, it *should* run!

This is not the only, or definitive method of achieving this. But I think it fits my ideal of having an elegant solution and it means the actual code (and not the tests) isn’t mauled about JUST to make the tests fit. Which is where a lot of unit testing falls down.

If you have another method or other ideas for how to get round dependcy and classname conflicts, then I’d love to hear them. Please post in the comments below!