PHPSEC, the PHP Security Consortium, has been launched. Ever since Marco Tabini’s call to arms for the PHP community to rally around PHP for business, I have been thinking about how I can support the effort to bridge the gap between enterprise and the brilliant PHP coders I have met along the way. Having given it some thought, I have a lot to say about how to bring PHP to the conference table. Hopefully I can sketch out a little of my thinking in this post.
The strengths of PHP are numerous–and, indeed, one of PHP’s greatest strength is in numbers. I still remember the ISP I used to work for in college that switiched from FreeBSD to Linux. The move was inevitable, since Linux counts a small army in its development ranks, while FreeBSD ambles along. Likewise with PHP, it is popular because it is popular. And popularity means a wealth of features, resources, community support–the chance to tap in to a massive amount of collective cerebral voltage. High voltage. I went so far in one article as to liken PHP to the punk rock movement of the late 1970s. So you get the idea.
However, a low barrier to entry means a lot of entries. Many programmers these days learn PHP as their first language, missing out on the intricacies of functional programming and lambda calculus or, worse, on memory allocation and casting in strongly typed languages. All of this, however, can be shored up over the course of a few good classes in computer science. What is harder to teach–so much harder–is good coding practice.
I see security as a natural extension of this category. I stand up out of my chair and applaud any effort to improve the coding standards of PHP programmers, and particularly in the areas where businesses can be hit and hit hard–the areas where those mythical creatures lurk that strike fear and trembling into the heart of every CEO know to man: hackers.
There is another, more insidious, and potentially much more costly area to address, however. I have eaten my share of spaghetti code, tallied up the hours companies have lost due to lack of documentation, and know from the marrow out that good coding practice only begins with security. Maintainability and robustness are words equally high on my check list of “must haves” before I consider any application, and especially one written in PHP, to be enterprise-ready.
The language has never been to blame. Perl, in fact, gives you more rope than PHP. Yet the sheer popularity of PHP has brought in such massive participation that it has come to this: we need standards now not only for evaluating coders but code. Some apps are so shoddy when I peer under the hood that I would be better off writing it myself. Coding standards like Pear’s are only enforceable with packages uploaded to their website. The business world still desparately needs guidance on how to treat PHP and its coders when designing truly business-critical apps.
Enough of this for now. I will let the gears continue to turn in the background. This could be the subject of my next article for the good folks at IPM.