Monday 30 November 2009

Unconferences

A year of hosting weekend events at IBM's Southbank location culminated last Saturday with the London Java Community Unconference. This was the most successful event so far - all the others were good, but this was the highlight of the year. Have a look at twitter for comments.

Having gained some experience over the past year I thought it was worth writing a few words on hosting unconferences from the point of view of a $BIGCORP. In the future I hope we will see many more companies welcoming technology groups into their offices at weekends.

Here are my suggestions for a successful event:




1. Remember your place

We ($BIGCORP) are really only providing a location - the event is all about the group that wants to run it and about what their members want. The LJC - led by Barry Cranford - has a clear mission, they are passionate about all things Java - all we are doing is providing a place to meet. This is not the sort of event that can be used to promote commercial products - leave that to the marketing teams.


2. Work with a good team

In fact, three good teams in my case. The IBM team that turns up on the day (Robin Fernandes, Cath Hope, Mark Hindess, Ant Phillips) - we are all developers from IBM's labs in Hursley and have worked with each other for a few years; I know I can trust them to do whatever they say they will. The second IBM team, led by the Hursley Innovation Centre, are people you don't see at the event - they work hard in the weeks running up to the event to ensure that we have catering, security, networks, projectors etc. Finally, the user group team. In this case Martijn Verburg and Barry Cranford from the LJC who displayed an exceptional level of trust in our ability to pull this off, especially given Barry's inclination to plan everything.


3. Keep it small

One of the great things about last Saturday was watching people talk to each other over lunch and in breaks. This is something that I feel is sadly missed at big conferences, at least half the point of these events is to encourage people to talk to each other.


4. What not to organise

Resist the temptation to organise the speakers in advance. Whatever happens on the day it will work out right. It really is up to the attendees to provide the content and I have yet to go to an event where there were too few talks. Perversely I also find that the quality of talks is much higher at unconferences than at mainstream conferences - I don't really understand why - perhaps because the audience are involved the atmosphere tends to be friendly and supportive towards presenters.


5. What to organise

Registration, sponsors, badges, projectors, wireless network, flip charts, white boards, pens, food (40% vegetarian, 10% vegan), directions, cleaning equipment, twitter tag, 'the grid'. That's it really. Oh, and some signs:



Thanks to Richard Dallaway for the image.

Tuesday 27 October 2009

The other side of IBM

Last week was full of 'firsts' for me. It started with my first ever commit to an Apache project . This was a career milestone for me, I will be writing a lot more about that project in the future, but not in this post.

The other 'firsts' were all associated with BarCamp London which ran from Saturday morning through to Sunday evening at IBM's Southbank location. It was the the first time I had ever been to BarCamp and I was enormously impressed by the level of organisation. I've been to a few big conferences and they could learn a lot from the BarCamp organisers who pulled the whole event together in their spare time.

The other side of IBM
Image courtesy of Adewale Oshineye - check out his other photos of the event
here

It was also the first time that IBM UK has ever hosted a BarCamp and it's hard to describe the level of nervousness that was permeating the corporate psyche prior to the event. As it happens, apart from one small(s) problem, the weekend went entirely smoothly. So many people helped to pull this together that I can't list them all. I will however mention three companies that I bet no-one else will talk about, G4S, Johnson Controls and Compass . Their employees were on site for much of the weekend ensuring that the building was safe to sleep in, kept clean and comfortable and that people were fed. Well done!

I think IBM gained a great deal of respect for trusting BarCamp to use their premiere London location knowing that they would be entertaining clients there on Monday. The developers from IBM who attended also gained from meeting a different and diverse set of people. When you work for a big company it's too easy to develop a language and way of communication that only makes sense inside the company - getting out once in a while at least makes you realise you are becoming institutionalised.

Someone asked me why I got involved with organising BarCamp - it's a simple answer. I've seen so many complex problems solved by bringing highly technical and creative people together and allowing them time to communicate. Sadly there aren't that many places where 200+ people can meet and share ideas. IBM has a great location which is not often used at weekends, how could I not have got involved?

Friday 31 July 2009

Does my PHP app run on Project Zero?

As the PHP implementation in Project Zero gets more complete it's possible to run quite a few significant applications. It would be nice to know in advance how likely it is that a PHP application would run on Project Zero - without investing a whole lot of time in trying to run it. Well, now you can.

There is a new Project Zero application which will scan your application and tell you whether it thinks it will run on Project Zero. The way it does this is to extract information from the Project Zero PHP parser - for instance it finds out the names of functions that are declared in the application and compares them with the names of functions that are invoked. If the application scanner finds that a function is invoked by the application but is not declared by it, it uses function_exists() to figure out if it is implemented in Project Zero's PHP. Similar analysis is carried out for classes and methods in the application.

The instructions for extracting and running the scanner are here. They assume that you already have a working version of Project Zero.

One of the reasons that I wrote this was that I wanted to figure out if PHPUnit would run on Project Zero. This led to a horrible chicken and egg situation in that I can't write PHP without PHPUnit and most of the scanner is written in PHP. In the end I had to inch forward on both tasks simultaneously, with the final benefit that I worked out how to use PHPUnit at the same time as writing the scanner. The instructions for running PHPUnit are here. I'm not claiming full support for PHPUnit in Project Zero - but there is enough to be able to test PHP classes as you write them.

The application scanner can't say definitely whether an application will run or not, this is because it is using static analysis. However it gives enough information to be able to tell whether it's worth trying or whether you should mail the Project Zero team with your scan results and ask them when they think they will have support for your app :-)

Wednesday 8 July 2009

On no! Not more tests!

One of the problems with the incredible level of success of the PHP TestFest is that PHP gets more tests, 887 more to be precise.

Well, isn't that the point? Yes, but it's beginning to take *forever* to run them which is a bad thing and as TestFests get bigger and better this will only get worse.

A year or so ago I started worrying about this, then I met Stefan Priebsch at IPC and made him worry about it too. Together we started a project to re-factor the code that runs tests (run-tests.php) so that it could run tests in parallel.

In May we had a prototype going, it ran most of the tests in sequence. It still doesn't have all of the capability of run-tests.php but it was enough for our PHP GSOC student (Georg Gradwohl) to start writing and integrating code that would run groups of tests in parallel.

Yesterday I ran some tests on my dual core lap top - this isn't a proper benchmark and I had all sorts of other stuff going on too...but here they are:



The chart shows the time taken to run 7700 tests with the current code (old), new code sequentially (seq) and the new code with increasing numbers of parallel tasks (para). As you can see we are able to run this sample in about half the time taken by the code that is used at the moment. There is still a long way to go with this but I'm happy to say that a couple of people have started to check out the code and try and run it. At the moment this only works on *ix, supporting Windows is on the TODO list.

With the help of the 'many hands' of the PHP community I'm quietly confident that by the time PHP gets all the tests it needs we will have something that will run them efficiently :-)

Friday 29 May 2009

PHP TestFest - one more month to go!

Groups from all over the world have contributed 554 new tests for PHP since April 1st 2009. Of these, 327 have already been moved into PHP's CVS (thanks Felipe!). The results of running tests on a Linux 32 bit platform can be seen here (sorry about the colour scheme), the user groups who have contributed are also listed. We also run the tests on a 64 bit Linux platform here, but this only runs PHP5.3 and PHP5.2.

I also ran some coverage tests recently to try and work out how much of a difference we were making overall. This turned out to be far more problematic than I had thought it would be. The main issue was one that Felix had already found, ccache and lcov do not coexist happily. It turns out that there is a check for this in the php configure script - but unfortunately the debian way of installing ccache is simply to link it to gcc, which by-passes the check in configure. Oh well.

The before TestFest coverage data shows an overall line coverage of 70.4%, a run from the 28th May shows a line coverage of 72.3% in total. There are minor differences in the number of lines but I think this is to be expected. It's interesting to look at the areas where I know groups have been concentrating their efforts - for example the line coverage of ext/ldap has increased 8.5% to 89.1%! Check curl, date, dom, ftp, gettext, intl, posix, reflection, sockets, spl, sqlite3, xmlwriter and xsl for other TestFest related increases in coverage.

I'll rerun the coverage tests regularly in future. I should perhaps mention that I know that ext/imap statistics are missing and that's because we don't yet have the ability to run the ext/imap tests on the system that is being used for TestFest. I will fix this in the next week or so - if you see anything else that doesn't look right please email me and I'll fix it, or better still, email php-qa@lists.php.net :-)

Thursday 7 May 2009

PHP TestFest ramps up!

It feels like a long time since we started on this road in February 2009. So much has happened since then ... and now we are two days away from the 9th May when several European groups will run events.

We have 22 groups registered in all, Munich and Quebec have already run successful events.

As tests are written they are being checked into a subversion repository - local organisers have admin rights and can add users from their groups. Once every hour we check tests out SVN and run them using PHP52, 53 and 6. The results are displayed here

It's great to see user groups helping out with PHP development in this way - I'm just amazed and humbled by the enthusiasm and talent of PHP users.

I also want to thank our sponsors, although I'm not even sure that I know who all of them are :-). The ones I do know are Microsoft (who are making office space available and providing access to Windows machines), IBM (also making office space available and of course allowing me some time to work on this), and Ibuildings. Ibuildings are a major sponsor in Europe, they are buying lunch for the PHP NorthWest group, they have funded some cute PHP TestFest mugs for the London group...and much more. At the end of TestFest I'd like to do a round up of every company who helped us - so if you are sponsoring something, don't be shy, let me know!


From now until the end of June the user groups will be writing tests, after that we'll count up and commit tests in PHPs CVS - I have strong feeling that this year's test fest is going to be a massive success!

Monday 6 April 2009

PHP and SAP

Last Saturday Robin, Ant and I went to London to the SAP Inside Track. We had an amazing day on so many levels! Ant had prepared a demo showing how to use the PHP implementation in WebSphere sMash to access data from SAP, but as we went up to London on 06:18 (!) train we really had very little idea what to expect.

The meeting got under way in the usual unconference style with attendees choosing the talks. Two things became clear pretty quickly, this was an incredibly interesting group of people and they had some very cool stuff to talk about. Dennis Howlett made a short video of the attendees which nicely captures spirit of the event.

Ant and Robin did a great demo of sMash, Dennis Howlett made another short video interview with Robin. Ant spent the whole of the lunch time having an intensive SAP lesson from Gregor Wolf - Ant is now officially our SAP expert!

I learnt a huge amount (I know a lot more about SAP than I did) I particularly enjoyed the talk about ESME by Darren Hague. ESME is a twitter-like project but designed with business applications in mind - I can see a lot of potential here.

All in all - it was a great day and I'm looking forward to the next SAP event.

Thursday 2 April 2009

PHP TestFest 2009 Kicks Off

So here we are at the beginning of the 2009 TestFest. There are currently 16 PHP user groups intending to participate, these are pretty widely distributed from Brazil, the USA and Europe.

The test repository is open for submissions to registered groups from today (see here and here for information and instructions. Join the freenode #phptestfest IRC channel and follow phptestfest on twitter.

Let's go!

Sunday 1 February 2009

PHP TestFest 2009

It's time to start getting the 2009 PHP TestFest underway. The TestFest is a worldwide event in which PHP user groups and individuals contribute to PHP by writing tests for PHP. It's a great way to contribute to one of the most successful open source projects there has ever been, it's also pretty cool to see your name in the the source distribution for code that's running on over 20 million web domains.

So how does it work?


User groups can register by sending a mail to php-qa@lists.php.net. In the mail we'd like you to pick an date for your event (somewhere between April 1st and June 30th), it would be great if you could let us have the name and e-mail for the primary contact too. As these arrive on the QA list, someone (probably me) will transfer them to the TestFest wiki. We will help you to work out what sort of event to run and how to organise it. Individuals can register for the TestFest too, just send a mail to the php-qa@lists.php.net.


User groups (or individuals) can pick areas in which they'd like to write tests, this might be something you know quite well already, or maybe something new you'd like to know about. For example, the London PHP group picked the dom extension last year. I didn't know much about that when we started but I did when we finished!


What do we need?

A bit of infrastructure! Scott MacVicar is putting together an SVN repository for tests so that contributors will be able to commit tests directly. He's still working on how access control will work....more on this later.

Sponsors! We have one offer of ElePHPants. We'll do the same as we did last year and hold a draw at the end of the TestFest. Anyone who contributes a test will have a chance to win one. Of course, the more you contribute the higher your chances will be!

Mentors, mentors and more mentors! We need internals developers who know how to write tests, have karma in cvs.php.net and who can review tests and commit them. Again - if you can help with this send a note to the php-qa@lists.php.net or let me know on IRC (efnet #php.pecl or freenode #phptestfest, #phpwomen).

For more information on PHP's TestFest have a look here and here

Monday 12 January 2009

So phar so good.

I've just finished converting a small procedural application, designed to be run from the command line, to PHP5 . I wanted a way to give users a single file to execute and as phar is included in PHP5.3 I decided to try to use it.

The source tree for my application looks something like this:


/mnt/workspace/ws_phpscripts/pharsamples/a.php
/sub
/b.php
/c.php


The main code is in a.php, classes 'b' and 'c' are in sub/b.php and sub/c.php respectively and I include them from statements in a.php.

The first step is to create the phar file. By default the ability to create phar files is switched off, to enable it you will need to add the following line to your php.ini file:




phar.readonly=0


The next step is to build a phar file from the source tree, phar makes this easy for you. Here is a script to create a phar:


<?php
$phar = new Phar('/tmp/a.phar');
$phar->buildFromDirectory('/mnt/workspace/ws_phpscripts/pharsamples/src');
?>


In the first line I instantiate a new Phar object, the argument to the Phar constructor is the path to the phar file I'm going to create.


The second line just builds the phar from all the code under my src directory. So, now I have created a phar, but how can I tell that it's worked? The easiest way is to read it from another PHP script, like this:


<?php
new Phar('/tmp/a.phar' , 0, 'myphar.phar')
echo file_get_contents('phar://myphar.phar/sub/b.php');
?>


In the first line of this script I am opening the phar I have just created. In this case the Phar constructor takes three arguments. The full path to the phar is the first argument, the second argument (flags) is zero, at the moment I can't think of any reason why it would ever be anything other than zero. The flags argument is inherited from the class RecursiveDirectoryIterator, so if you want to understand what it does look at the documentation for that class. The third argument is an alias - or the way I want to refer to the phar in my script.

The second line of the script attempts to get the contents of one of my files out of the phar. If I get the contents of file b.php back from the echo I know I have created the phar correctly.

I really want to be able to execute the phar from the command line, just like PHP code. To ensure that my main program (a.php) is run when the phar is executed I need to add a stub to the phar. The full create script looks like this:


<?php

$phar = new Phar('/tmp/a.phar');
$phar->buildFromDirectory('/mnt/workspace/ws_phpscripts/pharsamples/src');

$stub = <<<ENDSTUB
<?php
Phar::mapPhar('a.phar');
require 'phar://a.phar/a.php';
__HALT_COMPILER();
ENDSTUB;

$phar->setStub($stub);

?>


That's all the code that is required. To run a.php, all I have to do is:


cd /tmp
php a.phar


This is just about the most simple use of phar, obviously it can do a lot more than this. The documentation is here.