A very nice matrix exploring programmer aptitude.

I wish I hadn’t waited so long to install the ClickToFlash plugin, it totally improves the web experience. The idea is simple, all flash animations are paralyzed by default To view flash, including videos like youtube, etc, you have to click to play. A lot healthier for the laptop, no more CPU running at 100% nor mindless distractions when you’re trying to absorb valuable content.

I can’t believe Zend is publishing articles on OXID eShop, this is definitely some of the worst code I have seen in ages.

As “the PHP company” I think Zend ought to at least select projects that have some merit in terms of software design, as surely beginner PHP devs look to Zend for good examples and copy/emulate whatever they showcase.

PHPterror took a closer look at some of the OXID code, really jaw-dropping stuff.

A new look at how to create unit tests – using Photoshop!  Sense of humour required …

Thanks to Andrew Betts, a PHPlondon regular, for coming up with BadAPI, a service that allows you to simulate misbehaving APIs.

These days there’s almost no such thing as a web app that’s not integrating data from various external APIs, and with that integration comes a new set of problems the developer must handle.

From the BadApi website:

BadAPI allows you to simulate misbehaving APIs. This is useful if your site relies on the availability of service X, and you want to ensure that any downtime experienced by that service has minimal impact on your own application.

You might be surprised to hear that some developers have no idea what unit testing is – I know I was, but I have recently spoken to a suprising number of people who had never run across the ‘concept’.

I do have the advantage that one of the key proponents of unit testing and PHP, Marcus Baker, is a founding member of PHPlondon whose meetings I attend regularly, so I’ve had a pretty good exposure to testing and agile methodologies in general.  At work we have also been quite ‘test infected’ for some time now, this became more obvious recently when we had to complete an assignment where no testing framework was accessible, and quickly realised how dependent we had become.

For a good overview of the SimpleTest framework check out this excellent introductory article (cancel the print dialogue, this view is easier to read than the paged one), before heading over to Marcus’ extensive docs on the SimpleTest website.  SimpleTest is also available as a PEAR package which can be downloaded from the SF site.

Give it a try, see if you get addicted, can test-driven development work for your organisation? Also be sure check out Mock objects for help with isolating layers and resources in your application.

This question came up in a conversation with Marcus Baker, maintainer of the SimpleTest project, and he was kind enough to give the following detailed response:

Ok, there are three main strategies here. You can go all for one
strategy or mix and match. Here they are…

1) The most extreme – mock the database connection always. It means that
the mocks have to check SQL queries. Although this is a very quick way
to initially write the code, the sensitivity of these tests to changes
quickly buries you. Even changing a table name will ripple through the
test suite. What you can then do is refactor to make these tests easier,
for example using a SQL object rather than a string. I have personally
managed to make this scheme work, but it puts a lot of flexibility into
the code that you probably don’t need. And as always with mocks you
still need an integration test or two to confirm that it is all working.
Runs fast though.

2) The dumbass approach – send the objects to the database and confirm
the existence with low level calls. So you might have $object->save() in
the code and then you write assertRow(…) to confirm a table row was
written out. This has all of the test sensitivity problems of number 1
plus anyone reading the tests has to understand the mapping between the
two layers. This is pretty effective at getting you started though, so
it’s often the first test you write. Sometimes you just keep a few for
sanity checks, but otherwise refactor your way out of this pickle as
fast as you can.

3) Mathematical purity – the complete set of operations. This is my
currently prefered method. You only write your test code in the object
language you are trying to create. So if you are testing the search,
then you first save the objects using you new code. Something like…

class MyTest extends UnitTestCase {

    …

    function testSearch() {

        $apple = &new Fruit(’Apple’);

        $apple->save();

        $finder = &new FruitFinder();

        $result = $finder->findAll(’Apple’);

        $fruit = &$result->next();

        $this->assertEqual($fruit->getType(), ‘Apple’);

    }

}

The catch is that you need to be able to clean up before and after the
tests, so you will have to add methods like Fruit::deleteAll(), etc.
This is what I mean by a complete set of operations, coding one means
that you have to code the lot. The problem is bootstrapping this process
so that you can still develop incrementally.

My prefered approach is to start with 1 and once up switch to 3. I still
keep some ones around to simulate failure conditions.

I really enjoyed Jeff Moore’s (creator of WACT) post today, I thought I’d post it in its entirety.  It’s a compelling question, what is it that makes some programmers more adept than others?  While this article is a good stab in the right direction, it still doesn’t shed sufficient light on the phenomenon where you have the programmer who is highly intelligent, considerably experienced, with a broad exposure to CS concepts but not a particularly good software maker.

Now is a good a time as any to attack your webapp with Badboy:

This release contains many many
new features both large and small. Thanks to your feedback
we have been able gather the requirements from hundreds of users to
determine what to add to Badboy to make it better than ever. The
following major features are brand new in Badboy 1.5:

• Draggable and
  Dockable tool windows
  - arrange the Badboy windows the way you want!
• Unlimited Browser
  Popups
  - Badboy now records and plays back to an unlimited number of popup
  windows!
• HTML Reports
  - Badboy can now save beautiful reports in HTML format
• Timeouts
  - Ensure that your scripts finish on time every time – even when errors
  occur
• Data sources
  - unlimited, customizable data sources!
• Script
  Documentation
  - Add notes in rich text to document how your script is working inside
  Badboy!
• Logging
  Control
  - Better logging controls and log your own custom messages using JScript!
• Server Log File
  Integration 
  - Let Badboy capture and track your log file as your script plays!
• Easy Assertions
  – Just select the text on the page and click a button to create Assertions!
• Spidering – Let Badboy find the bugs for you!
• Popup Message Box Handling – Badboy can now record and playback responses to Popup Message Boxes
• Script Scheduling and Aggregation Run scripts on a schedule you specify, and call other Badboy scripts from each other!

Hello,

I’m posting this to clear up how to find the PEAR path on most servers, and then at the end are instructions how to use PEAR in your PHP programs.

Editors note: this article is for beginner to intermediate level users, and I think will be useful to many as reported problems installing PEAR are still widespread in the forums, etc. – Demian