August 26, 2005
I've had a rant building inside me for some months but amazingly it hasn't come out here. It's starting to surface elsewhere, though, such as this message that I wrote to the TCPHP list recently:
After working with dynamic languages like PHP, Perl, and Python, Java feels like a slow-moving behemoth.
My primary complaint against Java is not the language itself, but that the culture of the Java world so strongly favors large, heavy, overburdened frameworks. Frameworks largely developed by companies that would be more than happy to sell you hardware to run your resource-intensive applications. And as much as Java developers talk about testing (the xUnit testing frameworks started with JUnit, remember), trying to test applications running in a servlet container or an EJB contaner is still difficult. Possible, but difficult.
There are signs that some Java communities are waking up and trying to inject sanity and simplicity into developers' lives. Spring is gaining popularity, and even EJB 3.0 looks to be taking a cue from lightweight persistence frameworks like Hibernate. If you have to work with Java, I cannot recommend strongly enough that you read Better, Faster, Lighter Java. In fact, I recommend it even if you're not a Java developer, as it explores important ideas of simplicity that are important for any programmer's work.
As PHP 5 takes many of its cues from Java, we are benefitting from things such as a cleaner object model, a decent exception mechanism, and broader enterprise acceptance. Note, however, that "enterprise" acceptance comes in part as a result of support from companies like Oracle, IBM, and Sun, those same companies that are selling heavyweight application servers and frameworks. In such company, I expect that PHP will always play second fiddle to Java — running PHP inside a servlet container is very cool, but Java is clearly king.
And maybe that's okay. There's no reason to stick with one language throughout the entire application stack. PHP is excellent for rapidly developing web applications; I don't really like to use it for anything else, although I know that some on this list like its CLI capabilities (for that, I'm still a Perl devotee, many of my coworkers are sed and awk diehards :). I still hold out hope that at work I'll be allowed to develop a web front end in PHP, talking to a Java backend — be it through web services (hopefully RESTian where appropriate) or through more direct means enabled by an app server. There may well be benefit to choosing Java over PHP for certain areas of legacy app integration, although I'd be inclined to want to look at using dynamic languages with strong Java integration like Groovy or Jython to take advantage of faster development time.
With interest in PHP from IBM et al, we're also getting some very interesting R & D that builds on work done in Java. A PHP implementation of Service Data Objects, for instance, which is certainly intriguing reading but will likely be applicable only to a limited set of scenarios. I've seen strangely complex Iterators used in PHP code when a simple foreach() would have been enough. I fear that developers will use these tools and techniques in an effort to be more "enterprise-friendly" or Java-like, when they don't really make sense in PHP. Much as has happened in the Java world.
That about sums up how I feel. The more I work with Java, the more I appreciate how productive I am in other environments and dynamic languages.
Expect more on this from me soon.
August 24, 2005
A Twin Cities chapter of the Open Web Application Security Project is starting up. Our first meeting is September 13 at the Golden Valley Library.
August 23, 2005
On Saturday I gave a talk about form processing and input validation to the Twin Cities PHP User Group. It went well. I had originally planned to talk for 20 minutes or so, but other speakers backed out so I had lots of extra time. I made a spur of the moment change, pulling in slides from previous presentations, covering SQL injection, cross-site scripting, and cross-site request forgeries. If you're operating in a strictly whitelist mode, it's possible to do input validation without understanding the threats, but it's extremely limiting and generally unwise. You have to know your threats to write secure software. Thereis obviously far more to consider than SQL injection, XSS, and CSRF, but time was limited and that's what I had slides for. :)
After that quick overview, I covered basic strategies and pitfalls awaiting the programmer fortunate enough to be considering input validation. I even gave props to the Apache Commons Validator, a Very Useful Java validation library that we use in Struts (and that in fact started life in Struts). I'm not aware of anything parallel in PHP, although some libraries and frameworks offer similar functionality. I am intrigued by Solar_Valid and Solar_Filter in Solar, a library/framework for PHP 5. Paul M. Jones has been busy. Matthew Weier O'Phinney provides the background on Solar_Filter. (Quick aside: Marcus Whitney recently interviewed Mr. Jones for the Pro-PHP Podcast.)
I'm not sure how, but after the talk they convinced me to make my slides (PDF) available online. I'm normally opposed to this, and indeed the slides aren't that useful in isolation, but detailed meeting notes are forthcoming so I am somewhat mollified.
August 17, 2005
A few people at work are experimenting with using blogs to connect with customers/users or whatever you want to call the people that our IT division serves. It's a worthwhile experiment, but so far it has languished. After some asking around, I figured out who was responsible for the effort and sent a few suggestions, including this:
It would help to have a more clearly human voice. If weblogs are ever effective communication tools, it's because they engage people in conversation, punching through a corporate-speak firewall and connecting individuals. I don't sense this happening in the training feedback blog. The same was true of the ISRS Admissions blog, too: everything is posted by "ITS Support." Who's that? I suggest that you use people's names, to put an actual human being behind the words. People are not inclined to trust or even be interested in something written by an unnamed entity. You can't make an organization more transparent by hiding behind walls. That may not be what you intended, but frankly I think it's the result.
Ironically, not half an hour later someone in HR sent an event invitation to everyone. I don't know who in HR because it was sent by "HR Office."
Sigh.
Update: I like what the folks at Technical Careers @ Microsoft have done, adding personalized icons for each of the blog posters. I even like that they're not real photos. I don't have to read the poster's name to know who wrote what, I just passively identify the words with the picture and over time build a sense for that person's unique voice. Awesome.
August 11, 2005
Kiara and I are taking Owen to Corn Days in Long Lake this weekend. Growing up, there was only one reason to go: corn. Lots and lots of hot, buttered corn on the cob. I don't know what an all-you-can-eat ticket costs, but it's worth it. Now that I have a kid, I have two reasons to go:
A coworker heard me mention Corn Days and got all excited. "Ooh, are there all sorts of different foods made from corn?" No. Just corn. "Is there...?" No, just corn. She looked disappointed.
I wasn't being fair. There might be something else, but I don't care. As far as I know, unless you like corn on the cob or have young kids, there's not much reason to go. I'll report back anyway.
