PHP is not so black as he is painted

I had interesting chat with some other programmer the other day. We exchanged some experiences but when I told him about PHP5 gig I did several months ago he started squinting at me strangely. ‘That must have been madness’ his grin seemed to say.

Well… how then PHP appeal to people who never tried it? I guess the perception of this popular and powerful language is still as it was few years ago… A library to quickly hack html and make it ‘dynamic’. Sql statements flying around html markup, etc. Perhaps quite a number of production web pages are still like that but… truth is PHP5 gives enough OO and flexibility to be a decent tool in good hands: we did rapid TDD on every layer of application, from HTML to database. It was moments to set up continuous integration server – cron-driven PHP script. Application had massive performance requirements and we met them. My observation was that PHP5 had much better productivity than any .NET or java project I was in…

To end this PHP commercial I have to admit that I’m a ruby boy. But even if RoR family leads the trends nowdays PHP is also productive and fun.

web apps & directory layout

When servlet spec first appeared there was a trend to maintain web app sources in the same manner as any other non-web java app (bin-src layout pattern, etc. ). Then build process, usually ant, assembled war file by placing classes, libs, web.xml in appropriate places and zipping all together. Even ant war task seems to encourage this ANTI-PATTERN. I never use that task because…

Web app sources should be maintained in a layout as close to real deployment structure as possible. So, web.xml is kept in WEB-INF, compiled java code in WEB-INF/classes and so on. Why?

• Main motivation is that it’s so easy to setup the proper web development environment with goodies like: java hot-swap, instantly visible changes to view layer (html, jsp, vm or whatever), etc. Just tell server to look for web app at the source files’ location. It’s usually simple addition to server configuration file or something more fancy like tomcat’s context files.
• Ant scripts that build wars are smaller and easier to understand. They jar folder as-is. No hidden magic added.
• It’s just simpler – source layout reflects contents of war. When I look at unpackaged war file on server I know exactly where to look for those files in code-base (and vice versa).

All above advocate productive (java) web development. Productive means that when I change java/html/jsp/vm I don’t have to run any ant scripts and/or restart web server to see my change working. Keeping web app source structure conforming to servlet spec is a first step towards productivity.