Archive for the 'PHP' Category

 

Remix07

Jun 24, 2007 in .NET, PHP, Silverlight

Over the next couple of days I’ll be attending Microsoft’s Remix07 conference - the Australian format of a similar confernce called ‘Mix07′ held in Vegas last year. Its a quasi official-product-launch of the brand spanking Silverlight rich client platform, and it should prove pretty interesting.

For anyone not familiar with Silverlight, it’s a new .NET and xaml based platform/framework for delivering rich client content to the web. The basic gist is that it allows developers to create client applications, running in browser space, with all most of the features of the .NET platform - and if you buy the hype, means the end of ajax as we know it. I’m not as knowledgeable on the subject as I’d like to be, but it’s essentially Micosoft’s answer to recent developments in rich client platforms like Flex and Open Laszlo, with a few cool distinguishing traits like the bringing of all the .NET goodness and the ability to use isolated storage on client machines - typical security concerns aside, sounds positively kick-ass!

Possibly a unusual choice of conference for an OS developer and Linux fan (qualified by the fact that I’m currently sitting MCSD certification) but I’m very interested to find out whether it lives up to all the hype. There are a couple of PHP-related presentations that look promisin - ie, ‘PHP & Microsoft’ being presented by Steve Marx, which beyond technical details, will be interesting to hear Microsoft’s official line on PHP.

More to come.

As a side note for anyone interested: Dave Glover from Microsoft will be coming along to the next PHPMelb meeting ( 13-07-2007 ) to talk about Silverlight and some of the other ways PHP fits in with Microsoft technologies.

SegFault Rant

Apr 30, 2007 in PHP

(one of the lost rants I’ve meaning post for a while)
More fun lately with PHP segmentation faults. Segmentation faults in any language can be a major pain to isolate & debug, but in an interpreted language like PHP, for some reason that pain is 10000 times worse. Unless working with an IDE, these type of issues are particularly hard to debug & your code ends up peppered with echo statements trying to find the statement causing memory access issues. When developing locally you probably use an IDE and everything works out fine, but if you develop on a server, good luck. Further the nature of seg faults can be very platform-esoteric - that which will cause fatal errors on one particular distro/hardware/configuration, may run perfectly on others.

After about 6 hours worth of digging through code, I’ve reached the following conclusions:

  • It’s obvious, but never trust 3rd-party software packaging - no matter who is responsible for them. I use dotdeb.org packages because I run Ubuntu, I want PHP 5.2, and I can’t be arsed maintaining my own binaries. They’re far from perfect. Not much I can do about that aside from either giving up development using PHP 5.2, give up using Ubuntu, or start rolling my own PHP binaries (I’m too lazy for that crap!).
  • PHP documentation blows- yes, that might be stating the obvious. The particular function that was causing my problems was pg_escape_string(), which incidentally, can accept an undocumented, optional database connection as it’s first argument.
  • IMO, the optional first argument of pg_escape_string() is the pinacle of brilliance in mediocre api design. Aside from being buggy as all hell (passing a type other than a resource as the first argument, doesn’t generate warnings or failures, it just tries to use whatever it’s given and seg faults), common sense dictates that optional arguments should alway be the last item to appear in a method/function signature. There *might* be a good reason for doing this, but stuffed if I can see it.
  • PHP needs a better way of catching, reporting and failing when a seg fault occurs. I realise that can be difficult given the nature of the error, but it’s handled much better in other interpreted languages. Also, what’s the freakin point of Exceptions in PHP5 if they can’t respond or handle common errors like maloc bugs in the underlying C code? (just adds more weight to my opinion that, in their current form, PHP exceptions are a freakin waste of time)