XDebug talk at PHP London

Last night I gave a talk at the monthly PHP London meeting all about XDebug and kCacheGrind – I only just noticed I made an earlier post on here which lamented the lack of awareness about these excellent tools.
The talk went OK after a late start, and took rather longer than I though it would. I didn’t have a very well defined end point so it kind of petered out, but it seemed to go down OK, and there were some good questions. The MacBook worked great after I remembered to pick up the right kind of video adapter…

You can download a PDF of the presentation here.

Marcus Baker’s talk on “Is agile development right for you?” was entertaining and thought provoking.

I had some great conversations beforehand, and I completely failed to talk to Demian after he kindly bought me a beer!

Having two Marcus B’s around can get confusing too…

Somehow I didn’t get home until about 2am.

Skype sourceforge project released

Skype finally updated their Mac client to support web presence status, so I could finally do some tests, fix some minor niggles, and do a proper release of my Skype PHP classes.
They also updated their developer docs, saying they had fixed all the errors, but its just not true! Nearly all the errors I reported are still there, so they took the doc down again ;^) Apparently they are considering my proposal for some fixed status IDs in order to facilitate automated testing of presence API clients.

Skype SourceForge project up

I’ve finally got my Skype SourceForge project up and running. I sorted out SF’s subversion setup too, and I’ve stuck some PHP classes in the respository – needs rounding out before a file release though.

Installing MediaWiki on SourceForge’s project web area was a little uncomfortable, so I submitted a patch to them to make that kind of thing easier.

Walking the walk

Clay Loveless has an excellent article on professional PHP development attitudes.

I couldn’t agree more about the rules, especially that last one. My own PHP coding (in pretty much the exact circumstances described!) has come on by leaps and bounces in the last year by learning svn and simpletest amongst other things. I regard the use of E_STRICT much in the same way as W3C validation of XHTML and CSS – it’s vital. I encounter many designers that don’t comprehend validation – the excuse that things don’t work the same in IE seems to give them carte blanche to make a complete pig’s ear of everything. Having said that, E_STRICT is hard to maintain with many external packages, particularly bits of PEAR. The forthcoming undeprecation of ‘var’ should clear things up quite a bit, though I don’t know if we’ll have to wait for PHP 6 or if it will sneak into 5.x.

Lately I’ve been looking into PHP IDEs (again). I’m playing with PHPEclipse. It has some great features, but I really don’t get how anyone can be all that productive in a single window IDE! I’ve been having a hard time making it do what I want, and there are just endless amounts of configuration to be done. Even when it’s all working, it just seems much slower and more cumbersome than a few terminals and a copy of BBEdit. Ideally I’d like an interactive PHP debugger in the IDE, but DBG doesn’t seem to want to play nice on OS X, and it doesn’t support PHP 5.1 anyway. I might have to see what xdebug can do in that direction.

Just to add to the error_reporting confusion, PHP6 is scheduled to change it again. From Derick’s PHP 6 meeting notes (which seem to have mysteriously disappeared from php.net):

As we want to expose the language level warnings a bit more, and because of having all error levels in E_ALL, except E_STRICT is confusing we will be adding E_STRICT to E_ALL. As the current default is E_ALL & ~E_NOTICE we will effectively turn on E_STRICT by default.

In a reply to the blog entry, Xing Li said

To control peformance is to shed fat, use lean code, and control i/o follow from point to point and through every single line of code.

While I agree that it’s the way to go for small-scale efficiency, it’s often difficult to do in the large, and is prone to the ‘early optimisation’ trap. To deal with the larger scale issue, I’m surprised that more people don’t seem to use profilers. xdebug‘s profiler pumped into kcachegrind is just a wonderful thing for PHP development, and runs great on OS X.