Alex Little

I’ve just been hacking around with PHPDocumentor getting it to automatically create the documentation for the Cohere API and seems to be working well.

I have apilib.php which contains the PHP calls to the functions, then service.php is a wrapper around the apilib.php and provides the actual REST based services. Service.php is basically just a big switch statement, so, since PHPDocumentor needs the function declarations I can’t actually base the service documentation on service.php, so I’m using apilib.php as the basis for the service documentation.

I created my own PHPDocumentor template, which has been straightforward enough, though I did come across a couple of little issues – nothing too big and nothing that can’t be worked around .

These were the 2 little hacks I needed to put into my template:

1. in apilib, I’ve named the functions using camel case, whereas the actual method calls in service.php need to be lower case – so I amended the stylesheet to use: {text-transform:lowercase;} where the function name was displayed
2. I also needed to remove the dollar signs from the front of all the PHP parameters, so to do this I just used the Smarty templating command ‘replace’: {$functions[func].params[params].var|replace:’$':”}

I still have some of the documentation to actually write into apilib.php – most notably example service calls for each method and double checking the return descriptions are consistent (and correct). All is working out well and you can see the generated docs on the Cohere site.

I noticed the announcement the other week about Google Docs adding the capability to work in offline mode (using Google Gears) which is great – especially for me when I’m going away and may only have intermittent/unreliable internet access. Unfortunately the capability hasn’t filtered through to my Google Docs account , but hopefully it will soon (I noticed their release mentions it’ll take a few weeks to be available to all)

Just come back from workshop given by Nick Freear in IET on the WAI Accessible Rich Internet Applications specification. It was something I knew very little about – I’d previously got only a very vague idea what it was all about – so I certainly learned a lot.

My first impression is that there seems is quite a lot to it and it wouldn’t be insignificant effort on the part of web developers to make their web apps compatible (and accessible) with the spec. But to me that always seems the way with making accessible websites… a lot of guidelines to remember at first, but once you get used to it you find yourself instinctively knowing what is accessible and what’s not (though to be fair I don’t think I’ve quite reached this level!!).

I was interested to hear that although WAI-ARIA isn’t a final spec it is implemented (to varying degrees) to most browsers. It was also interesting to hear how this overlaps (conflicts?) with the HTML 5 spec, and the opinion that WAI-ARIA was basically a stop gap measure until HTML 5 is widely adopted and supported.

Have just updated this site to the most recent version of WordPress, which was as easy as ever I do like the new admin interface too!

However on upgrading I noticed quite a large PHP error_log file which seems to consist mainly of messages like this:

[03-Apr-2008 08:46:31] -------------------wpopenid-------------------

[03-Apr-2008 08:46:31] WPOpenID Status: file:error_log [info]: Logging errors via PHP's
error_log faculty to: error_log

[03-Apr-2008 08:46:31] WPOpenID Status: userinterface hooks: Enabled (finished including
and instantiating, passing control back to wordpress)

Turns out that debugging for WPOpenID is on by default, and you can only change the setting by changing the code – rather than through the admin pages

Anyway, all I needed to do to stop the constant entries into the log was change the \wpopenid\openid-registration.php file so that WORDPRESSOPENIDREGISTRATION_DEBUG was set to false (line 20).

As a follow up to my last post, it costs VSO (Charity Registration No 313757) a substantial amount to recruit, train and support volunteers in preparation for and whilst on their placements, so I’ll be doing some fundraising activities over the next few months before I go and any support you’ll be able to give me will be much appreciated. If you just can’t wait to donate, then please visit my fundraising page and make a donation – it’s really simple, fast and secure to donate through this site, plus UK taxpayers can GiftAid their donations giving VSO an extra 28%! All donations, large or small are greatly appreciated by me and VSO

You’ll be able to track how I’m doing with my fundraising target to £1000 by taking a little look at the fundraising widget over on the left <<<<

Many of you probably now know that I’ve been accepted a placement with VSO (Voluntary Service Overseas) to go and work at Mekelle University (http://www.mu.edu.et/ – though the website availability seems a little erratic!) in Northern Ethiopia, starting Aug/Sept ’08, initially for a year. I’ll be working as an IT advisor, trainer and web developer, helping to train teachers in IT, support their IT infrastructure and developing their elearning programme.

This weekend I’ve just been on my first VSO training course ‘Preparing to Volunteer’, which was excellent fun, though extremely mentally exhausting – very long days, with loads of information about the reasons for development work, why it matters and how it can best be achieved, plus how to prepare ourselves for the culture shock that all VSO volunteers will inevitably suffer!! Loads of group work exploring our reasons for volunteering and coping strategies. Played some fun games, including the ‘trading game’, where the 20 of us were split into 5 different countries (UK, US, Thailand, Bangladesh and Tanzania – I was in Tanzania), each given different resources and tools (paper, scissors, compass, rulers etc) to make paper shapes to sell to the bank. We’d set up a deal with the US so we could use their tools (compass & scissors) to make the shapes with our resources (paper), though we had to give a ridiculous percentage of our output as payment for use of their tools. In the end we thought we’d done pretty well, especially with how skewed the rules and bank were in favour of UK & US, though admittedly we did use some underhand tactics – stealing another pair of scissors and not declaring much of our actual output – the US team wasn’t watching us closely enough!