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.
Monday, 6 April 2009
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!
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
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:
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:
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:
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.
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:
That's all the code that is required. To run a.php, all I have to do is:
This is just about the most simple use of phar, obviously it can do a lot more than this. The documentation is here.
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.
Thursday, 18 December 2008
Enterprise PHP
I arrived home last night after a slightly mind numbing day of reviewing and fixing tests (30 done, another 80 to go) for PHP's ext/imap extension to find that my copy of php|architect had arrived! A cup of tea, a warm fire and something good to read - heaven!
I work for a company that has a bit of a history in enterprise computing, so I read Ivo Jansch's article with interest, I'm certainly looking forward to more in his series. Ivo mentions WebSphere sMash (aka Project Zero), inside sMash we run PHP on a JVM - this really is PHP, many of the extensions we use are PHP extensions we just use a different engine from that in the reference implementation because of the cool things we can do by making it easy for PHP and Java to communicate.
This leads on to something else that happened last week. You probably don't realise it but it's very likely that sometime during the last week you will have have used IBM's CICS technology. Really? Yes - if you have bought something at a supermarket, taken money out at an ATM, had a parcel delivered to your house you have probably been a user of CICS because it forms so much of the underlying structure of commercial systems.
Last week PHP made it into CICS, PHP is now being used to build agile front ends and RESTful interfaces for the technology that underpins most of the world's large scale commercial systems. You don't get much more into The Enterprise than that!
I'm going to stop there because I can feel a bad Captain Kirk joke coming on....beam me up ScottMac!
I work for a company that has a bit of a history in enterprise computing, so I read Ivo Jansch's article with interest, I'm certainly looking forward to more in his series. Ivo mentions WebSphere sMash (aka Project Zero), inside sMash we run PHP on a JVM - this really is PHP, many of the extensions we use are PHP extensions we just use a different engine from that in the reference implementation because of the cool things we can do by making it easy for PHP and Java to communicate.
This leads on to something else that happened last week. You probably don't realise it but it's very likely that sometime during the last week you will have have used IBM's CICS technology. Really? Yes - if you have bought something at a supermarket, taken money out at an ATM, had a parcel delivered to your house you have probably been a user of CICS because it forms so much of the underlying structure of commercial systems.
Last week PHP made it into CICS, PHP is now being used to build agile front ends and RESTful interfaces for the technology that underpins most of the world's large scale commercial systems. You don't get much more into The Enterprise than that!
I'm going to stop there because I can feel a bad Captain Kirk joke coming on....beam me up ScottMac!
Friday, 14 November 2008
Lateral thinking
As test writers, when we see code with poor test coverage the most natural approach is to think that we ought to write more test cases, indeed we have been doing exactly that for PHP. The number of test cases for the PHP implementation has increased from roughly 3000 to 5000 over the past two years.
But - there is another way, and as usual the PHP core developers are showing us the way. The fastest way to improve percentage of code covered is to REMOVE UNTESTED CODE! Accordingly we saw the test coverage of PHP 5.3 increase from about 55% to a little over 70% over the summer of 2008. At the same time the lines of code in PHP dropped by about 50KLOC. How can this be?
To be serious, what's been done is perfectly legitimate. Several libraries that are used in, but not tested by, the PHP project have been removed from the statistics, they should probably never have been included in the PHP5.2 figures. The only misleading thing is that if you don't look closely you might think that PHP5.3 was a lot better tested that PHP5.2, in fact it's a bit better tested and we still need more tests.
Coverage of 70% looks good, but the goal 2009 PHP TestFest should be 80% coverage to be achieved by writing more tests!
But - there is another way, and as usual the PHP core developers are showing us the way. The fastest way to improve percentage of code covered is to REMOVE UNTESTED CODE! Accordingly we saw the test coverage of PHP 5.3 increase from about 55% to a little over 70% over the summer of 2008. At the same time the lines of code in PHP dropped by about 50KLOC. How can this be?
To be serious, what's been done is perfectly legitimate. Several libraries that are used in, but not tested by, the PHP project have been removed from the statistics, they should probably never have been included in the PHP5.2 figures. The only misleading thing is that if you don't look closely you might think that PHP5.3 was a lot better tested that PHP5.2, in fact it's a bit better tested and we still need more tests.
Coverage of 70% looks good, but the goal 2009 PHP TestFest should be 80% coverage to be achieved by writing more tests!
Thursday, 9 October 2008
Tea break's over....
So I'm back at IBM after a year of being a student. I spent the first couple of weeks easing myself in gently by doing a little more PHP opcode documentation, see here. I'm hoping we can move this into the manual.
Things have moved on a little whilst I was out getting educated. In October 07 the PHP runtime used in Project Zero (aka WebSphere sMash) was just running PHPBB. Now it's really looking much more capable, in addition to PHPBB it runs SugarCRM and more recently also WordPress and MediaWiki. I'll be interested to see how the team exploit the possibilities for close integration of Java and PHP code.
Things have moved on a little whilst I was out getting educated. In October 07 the PHP runtime used in Project Zero (aka WebSphere sMash) was just running PHPBB. Now it's really looking much more capable, in addition to PHPBB it runs SugarCRM and more recently also WordPress and MediaWiki. I'll be interested to see how the team exploit the possibilities for close integration of Java and PHP code.
Subscribe to:
Posts (Atom)