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.

PHP London Conference

An excellent bash with a very nice venue. I’ve been to several PHPLondon gatherings and it was great to see it all come together. The ‘meet the speakers’ do the previous evening went very well – I had a good chat with Harry Fuecks.
The speakers were pretty good. Pawel’s Dependency Injection was probably the most underpresented, but had the best content, and had similarities to a talk given by Marcus Baker last year.
Matt Zandstra presented his template path pattern well, but I was left with the feeling that it was way too specific to be of much general use.
PHPLondon are a very comfortable bunch to be with!

Error-free PHP

Not nearly as good as it sounds. I’ve become plagued by a very irritating problem over the last couple of weeks – I’m getting no error output from PHP whatsoever, neither to the browser nor to logs, even though all such options are enabled. My config files are as stock as they can be and still work. It’s just making debugging nearly impossible. I’m getting the same symptoms on OS X and RedHat EL4, so it’s not a platform-dependent thing. They are also on different versions of Apache (2.0.54-12 from Fink and 2.0.52 from RHN). Grrr.

Update
I found it!! Really silly issue and it explains everything. There was a .htaccess file containing an old line:

php_value display_errors true

It appears that (unlike in the rest of PHP) ‘true’ is interpreted as boolean false in this context. Commenting it out or setting it to 1 makes it work.

PHP register_long_arrays session breakage

Strange behaviour that’s taken me ages to track down. I had the situation where I could create a session, but any changes to it were not saved. session_write_close() didn’t help. Eventually I tracked it down: if you have register_long_arrays disabled (as is the default in PHP5), this can happen. Enabling it fixed the problem. A very simple test case didn’t show this problem, so I guess something in my sessions has a dependency on HTTP_GET_VARS or similar, though these vars do not appear anywhere in my code…

Update
Someone pointed me at this bug report which seems very similar to what I’m seeing. Still no solution though.