My wife Keri is a talented photographer. She also has lots of fun photography toys. She recently upgraded to the Canon 40D, a really nice digital SLR that does just about everything. It has a LCD panel on the back that’s larger than the television in our bedroom. It’s got a button labeled “align satellite” and other one labeled “cure cancer”. It also takes really nice pictures.

This left Keri’s old camera, a Canon 10D, up for grabs. I suggested she sell it to offset the cost of her new camera, but it would seem that digital SLRs (older than say, ten minutes) hold resale value about as well as homes that have been featured in Monster House. She was considering having it modded to do infrared, but in the end decided to give it to me, probably so I wouldn’t break her camera. While she has outgrown the 10D, it’s an amazing camera for someone who doesn’t know their proverbial ass from a hole in the ground when it comes to photography. I used it to snap a picture of a container of milk for an earlier blog post and noticed that I accidentally took a really nice photograph.

Keri’s new camera uses all the same lenses as her old one, so we can share lenses, which is pretty cool. My hobbyist foray into photography doesn’t really warrant even a camera as nice as the 10D, much less the vast arsenal of shiny and expensive cylinder thingies she lets me use.

While I’ve always had some form of digital camera and have some primal sense of aesthetics, I’m far from a photographer. I’ve always found photography interesting, but not enough to really learn the nuts and bolts of it. Lately, though, I’ve been really intrigued by HDR (High Dynamic Range) photography, wherein one takes several shots of the same subject (typically employing a tripod) and tone maps them using software. Because you’re working with several exposures, there’s a lot more light information to work with than just one image. Everything in the image can be correctly exposed, no matter what the lighting conditions. The results can be stunning, and I was really interested in trying it out.

Keri set me up with the proper tools and software, in addition to some basic instruction. Despite the bitter cold we’ve been having these past few days here in Portland, I’ve been taking the camera with me on my walk in the morning, which just so happens to be during the “golden hour“. Yesterday I went out again at around 4pm and took the photographs that were used to make the image above. It’s far from perfect (the focus is kind of soft on the buildings and it’s a bit noisy) but I’m pretty happy to be getting results after only a few days of working in this medium.

The image in this post was taken at the Peninsula Park rose garden in North Portland, a few blocks from my house. I used the 10D and Keri’s EF 17-40mm f/4.0 L USM Lens with a circular polarizer to bring the clouds out. I set the ISO to 100 and took bracketed exposures +/- two stops from f/4.0. I brought the three images into Photomatix to do the HDR business, then did some final tweaking in Photoshop using the PhotoTools plug-in. I think it came out pretty okay for an early effort.

At some point in the late sixties, the venerable Edsger Dijkstra put in place the basic tenets of what is now termed “software architecture”. The origins of the actual term are murky. The basic idea, however, is that when you’re creating software, design, or “architecture” is a discreet process that is done before implementation. Much like building a house, you would gather input from whoever you’re building the house for and then create a plan. Builders can then take the plan and implement it. Thus, the “plan” for a piece of software is called an “information architecture document” (or I.A. as the kids call it) and the person who writes it “a software architect”. Other than infuriating actual architects, I can think of few positive things this approach has yielded.

It seems like a valid approach on the surface, and it’s easy to get one’s head around. Houses are a complex system, a piece of software is a complex system. If you make a change during the planning phase, it’s cheap. If you make a change after the thing is built, it’s expensive. The simplicity of the concept probably explains why it’s used so extensively in teaching systems analysis to college students, and why it’s so pervasive in the business world. Architecture works for houses, why shouldn’t it work for software?

What am I getting at here? Software as architecture doesn’t work. It’s never worked, honestly and I see no reason that it will suddenly start working. Let’s not kid ourselves. Software gets built in spite of this way of thinking, not as a result of it. Think about it. If you’re a developer, how many software projects have you worked on that had extensive IA wherein the final product looked exactly like the IA documents? I can’t think of one. In most cases, the two weren’t even close. If you attempt to draw the housing analogy in this light, it would be like drawing up plans for a raised ranch and building a nuclear submarine.

(Note: Before you start preaching to me about Agile, save it. A system wherein “engineers do whatever they feel like doing today” and “the client can go suck it” is not something I can get behind. Commence angry comments about how I don’t understand Agile. *sigh*)

The problem with software architecture is that the core assumptions are fundamentally flawed. The first assumption is that software systems are like houses. They aren’t. Even the most complex building is made from commodity components. There’s framing lumber, steel, concrete, etc. These are materials waiting to be assembled into a product. Design and engineering of buildings is a well-defined process. Things like how much load a particular wall can support can be mathematically determined. Software, in contrast, is a series of problems waiting to be solved to create a coherent solution. Even if the problems are meticulously well defined, solving them is rarely an exercise in assembling off-the-shelf components. This is what makes estimating the cost of software projects like trying to nail jello to a wall. How can someone say how long it’s going to take them to figure something out? They haven’t figured it out yet!

Another flawed assumption of software architecture is that software is so hard to write that making changes once the development process is in motion (or after it’s complete) will be exponentially expensive compared to getting it right in the planning stages. There was probably a point in history where this was true, but let’s face it: most programming tasks aren’t as hard as to do as they used to be. I could (and plan to) devote an entire article to this fact alone, but for now I’ll just say that I’m getting very tired of software developers talking about how impossible things are. High school students are developing software systems that are often more effective than development teams at large corporations. Are they doing everything perfectly? Certainly not. Are they following industry best practices? Unlikely. Are they building systems in weeks that take large companies years? You’d better believe it.

The final and most obvious flawed assumption of software architecture is that a correctly and meticulously designed software system won’t need to be changed. I highly doubt this has ever happened. Changes can happen any time in the development process for a variety of reasons. You might show a client an early revision of something at which time they pick it apart and request a bunch of changes. The parameters of the problem might have changed while you were developing. There might be something in the IA docs that just doesn’t work in the real world. Whatever it is, a completed software project is a moving target. Stop whining about how “That wasn’t in the requirements document!” Things can and will change before the thing is done. Count on it.

Now that we’ve established the flaws of making analogies between software and architecture/construction, let’s consider another industry that can execute very large and complex projects on very short time lines and adapt continually right up until the very end: film and television.

A movie or a television show (let’s call it a “production”) starts with an idea, which then becomes a treatment. A treatment is a short document that explains the story that’s going to be told at a high level. Based on the treatment, a script is written. A script dictates what actors will say, what locations should look like, what props will be needed, etc. The production is then made, based on the script. While scripts are often very specific, they’re specific about the parts that matter, leaving much of the detail open to the director. Scripts are usually written by writers who don’t have any real idea how cameras work or how to set up lighting. That’s because a script is a goal. The production is the means to achieve that goal. Scripts are far from immutable, even once production starts. Writers are present through the whole process. If something isn’t working in production, the writer changes it and it’s re-shot. Once a production is shot, it goes into post-production, wherein it is edited and refined until it’s complete. Change is an intrinsic part of the film and television work-flow.

Why couldn’t a similar process be applied to software development? Couldn’t we start with a specific and concise but mutable plan for what to build and then adapt as needed until we get what we want? Instead of fearing change, which is inevitable anyway, why not integrate it into the very fabric of the process? It works for film and television, and I’m pretty sure they have much tighter deadlines and much bigger budgets than your garden variety software project.

So let’s consider the steps of creating software products as productions as opposed to houses.

The Five Steps of Software Production

#1 - The Idea
Define, in one sentence, what the final product will do. This should be extremely broad. This probably won’t change over the life-cycle of the project. This will serve as the litmus test for every decision made by every person involved. If something you’re working on isn’t to achieve the end set out at this stage, it shouldn’t get done. Set a deadline here.

#2 - Treatment
In five hundred to one thousand words, describe what the system will do in plain English. Avoid any engineering-speak or technical jargon. Show this to your client or stakeholder. Make sure they understand it and can explain it to you in their own words. Ask them to change it as needed. Agree on this document, as it will likely be the most important one you write.

#3 - The “Script”
This is the closest we’ll get to traditional information architecture. It should be the fewest number of words and diagrams to express the basic workings of the system in question. For web projects, I often use the design comps. This document is the basis, not the bible. Don’t spend inordinate amounts of time detailing it, it’s going to change wildly before you’re done.

#4 - Principal Production
This is where you write the code. The goal is to get the basic core functionality working in a way that you can demo it as fast as you possibly can. As soon as you’ve got something, show everyone involved. Keep everyone engaged as much as possible. Respond to change as deftly as you can. Everything you do should be considered in light of the deadline set in step one. If something can be done before the deadline, do it. If not, it waits until post production.

#5 - Post-Production
There are issues inherent in any software system that just won’t be exposed until you’ve got it in front of real people. Once your product is in its “beta” phase, have a way for users to provide feedback. Measure feedback carefully against the original idea. If you can make changes based on feedback that serve the original idea, make them. If they don’t, forget it. This will probably go on continually so long as the system is serving a purpose (note that I didn’t say “intended purpose” as actual and intended purposes for software are often different.) When the core idea changes, it’s time for a refit or an entirely new system, which should be considered a separate production.

So there’s my far-from-finished thoughts. I hope this inspires you to shift your thinking when it comes to planning and implementing software systems. I’m interested in getting feedback on these concepts, as it’s something I’d like to develop into a larger work, either a paper or a book. I look forward to your comments.

Despite my best attempts to take part in the current generation of video game consoles, I have been utterly unable to procure my platform of choice, that being the Nintendo Wii. I have been trying to get one for months to no avail. I know they exist. In fact, I know they exist within a five mile radius. It would seem, however, that most stores keep their Wiis in some kind of quantum state, managing inventory via the Heisenberg Uncertainty principle. That is to say that merely observing the Wii inventory can cause it to change. Take this conversation I had with the fine young man in the video games department at Best Buy recently:

Me: Do you have any Wiis?
Dude: Ha! No.
Me: So do you know when you’ll be getting some in?
Dude: Sometimes, we get a few on Tuesdays.
Me: What is this, Rain Man?
Dude: What?
Me: Nevermind. So you get them on certain Tuesdays. Could I say…call on Tuesday and see if you have any?
Dude: Ha! No.
Me: So basically the only way I could even find out if you have the thing is to drive here every Tuesday morning and wait for the store to open.
Dude: Yeah. You know, there’s actually a group of guys who meet at the Starbucks next door every Tuesday and wait for the store to open.
Me: Wow, that’s profoundly sad. Has any of them been able to purchase a Wii?
Dude: Ha! No.
Me: Do you have any Xbox 360s?

And lo, I did purchase an Xbox 360. Granted, the 360 was not a complete impulse buy, considering my aging PC video card turned BioShock into an experience I like to call Slides From My Trip To Rapture. Having recently purchased one of those fancy flat-screen HDTVs, I also grabbed a ragga-fragga-fifty-dollar HDMI cable. There was also the obligatory Halo 3, an “extra” controller (It comes with one. It’s like they know you’re lonely.) and something I think they called “Xbox Live Triple Platinum Carmel Macchiato”. I winced as I signed the credit card slip, but damn it, I was finally relevant again.

I brought it home and set it up. Before long, my brother and I were playing something called “Slayer” in Halo 3. (Where I come from, they call that “deathmatch”. You know, because people die. In the game. Nevermind.) It was around this time, sadly, that I learned the mouse and keyboard skills I had been honing since Quake 2 did not translate to a pair of thumb sticks. “Slayer” turned out to be a pretty apt name for the game mode, but I think “Firing Squad” might have been more accurate. Jeff is a seasoned veteran of Halo 2 on the original Xbox, and that does translate, right down to the finer points. After an hour or so of having my ass handed to me with everything from rocket launchers to something resembling a salad shooter, Jeff said something to the effect of “Look, keep practicing. It’s not like I can get any better.”

I did improve after a while. You see, Halo 3 has this other mode called “campaign”, the sole purpose of which seems to be training you for multi-player mode. At least I’m guessing that’s why they put that in, because you play it by yourself and I couldn’t detect any hint of a storyline behind it.

For a time, all this was good. The Xbox had done something very positive: It got me out from in front of my computer… and on to the couch. Something was missing from my overall video gaming experience, though: other people. Aside from the occasional aforementioned rounds of “Jeff Using Various Implements to Harm Jaybill”, there really wasn’t a lot in the way of games everyone in the house could pick up and play. Something had to be done.

I went to my local game store and purchased a used Gamecube, four wireless controllers and Mario Kart. I brought it home, hooked it up and before long, we were all screaming obscenities at the television just like we used to. Just like the old days, before I sold the Gamecube and all the games to purchase a Nintendo DS during leaner financial times.

So while I have yet to achieve the coveted Wii60, at least everyone in the house can enjoy video games until winter is over and we can go outside again.

Oh, if you’re interested, my “gamertag” (whatever the crap that means) on Xbox Live is Amma Hurchu. I welcome anyone who wants to see the kind of damage I can inflict with that salad shooter thingy.

When it comes to web applications, I spend a lot of time evangelizing the use of application frameworks. This stems from a desire to save people from writing mountains of new code that they’ll have to maintain. The less code you have to write to accomplish your goal, the better, as far as I’m concerned.

Frameworks promise you less work for greater return. This is good. What’s bad is that focusing on a framework can cause you to overlook an even easier solution: using something that already exists. I don’t care how easy it is to write blog software in Merb. If you’re writing blog software from scratch, please stop, for you are dumb. This problem domain has been conquered over and over. Don’t solve it again. The only time you should be looking to build an app from scratch is when you’re approaching a problem that’s never been solved before. The practical developer has no room for ego as far as inventing goes.

I can hear you saying, “But I don’t like the way other blog software is written! I want to write my own!” Well, go ahead. If you’re doing that for clients, prepare to a) maintain your non-standard app until you get fired, because you’ll be the only one on earth that can do it b) prepare to get your lunch eaten by a competitor who can install and customize Wordpress.

The other reason I thought it would be a good idea to compile this list is that there are a surprising number of people who don’t actually know about some of these apps. Everyone knows some of them, but very few people have a toolbox that includes all of these.

There’s a few things I look for in an off-the-shelf web application that I used as parameters when creating this list:

Good Documentation - If I can’t figure out how to use it, it’s of no use to me.
Solves a Specific Problem - The app must do one core thing and do it well.
Must Work Out of the Box - If there isn’t an outright installer, there should at least be some simple steps for getting the basic application working. If I have to customize or extend it before it’s useful, it’s not an app, it’s a framework.
Easily Extensible - There has to be a way for me to customize and extend the app without modifying the core code.
Plays Well With Others - There should be options for integrating with other apps via standard communication methods, like RSS, XML-RPC, JSON via HTTP or whatever.
Established Developer Community - I need to know there are other people using the thing that can help me if I get stuck or that could take over for me if I need to offload some work.
Minimally Picky - The app must run on standard web servers using standard tools and technologies without extensive tweaking and configuration.
Free and Open Source - Not negotiable. I must be able to use, customize and redistribute the thing without any legal or monetary restrictions.
MVC - There should be a clean divide between the presentation, controller logic and model layers.
Client Usage - This list is only stuff that a freelance developer might implement for a client.

Note that I did not say “has to be written in PHP”. For me personally, that certainly helps, but it’s not a strict requirement. I use plenty of things that aren’t PHP based. I probably won’t go to great lengths to customize things in languages outside of my core competency, but that doesn’t make them less useful. You’ll find this list heavily biased towards PHP, but that’s because it’s my list, not the list.

Okay, enough said. Here’s my list:

#1 - Wordpress - Blog/CMS
Pretty much the last word in blog software. You can be up and running in minutes. Lots and lots of pre-built themes and very easy to customize. With the advent of “pages” in Wordpress, expensive proprietary CMS systems seem kind of…quaint. The plug-in system is really neato and there are hundreds of available plug-ins.

#2 - Trac - Issue Tracking and Documentation
Trac uses Python, but I’m not holding that against it. Probably the best all-around issue-tracking and software documentation setup there is. Hooks directly into Subversion and has lots of other highly useful features.

#3 - phpBB - Discussion Forums
phpBB has been around for a long time and has grown up considerably over the years. The latest version has a really nice templating system. Plug-ins and themes abound and the installation is a snap.

#4 - Gallery - Image Archive
Feature-packed, easy to use and highly extensible, Gallery is as good as it gets for displaying large numbers of images in a useful way. I used to do a lot of sites for photographers, and Gallery was often a very good solution.

#5 - MediaWiki - Wiki
This is the package that powers Wikipedia, so I guess you could say it has a fairly good sized user base. Pretty much the gold standard for Wiki systems, it’s well known and well documented. It’s very well put together and can handle very high traffic quite efficiently.

#6 - eGroupWare - Groupware/Intranet
Why anyone would build their own intranet app when there’s eGroupWare is beyond me. There’s a ton of useful stuff right out of the box: webmail, timesheets, resource management (i.e. “Who has the freaking projector?”), threaded discussions, issue tracking, file sharing and a whole lot more. Writing your own extensions is a snap, too.

#7 - Sugar CRM - Customer Relationship Management
I’ll just go ahead and say it: CRM is very boring to me. For that reason, I’m very glad I’ll never have to write another CRM app again, because SugarCRM did right the first time. Companies that want CRM solutions also generally want enterprise support (whatever that means in the real world) which SugarCRM, Inc. is happy to provide.

#8 - Magento - eCommerce
eCommerce has long been a weak point for open source web applications. Before you say “osCommerce”, just…just shut up. If you haven’t implemented it, don’t talk to me about it. I have. It causes a burning sensation and leaves permanent scars. Magneto, though not even out of beta, is poised to shake things up quite a bit. It uses my very favorite framework and has a very nice set of features, even at this early stage.

WAIT, THERE’S MORE!

#9 - OpenAds - Ad Server
After I made my carefully crafted list of 8 apps, I realized there’s another important one I left out. OpenAds is a really nice ad serving app, capable of running some pretty complex campaigns with multiple clients. The admin tools are really awesome and there’s a very large community of people that use it if you get stuck.

“But wait! There are other great web apps that aren’t on your list!” Yes. I know. There’s even a few prominent ones that didn’t make the list. Here’s a few with explanations:

Drupal and Joomla - Both are indeed solid, well-written applications. They fail the “do one thing well” test, however. They both try to be all things to all people, though, and as a result they don’t do any one thing in particular very well. Both have an extremely high entry barrier for new developers. I also think they both have stupid names that don’t mean anything.

PHPNuke - Really? Are people still using that pig? Granted, I haven’t used it in a while myself, but from the looks of it, not a lot has changed. While it does have a lot of customization options, it’s a usability train wreck when it comes out of the box. By the time you’ve customized it back into something usable, you might as well have started from scratch. The back end code is (or at least was) a mess.

And there you have it. Commence the strongly worded comments about why the list should have X and shouldn’t have Y.

When Microsoft unveiled their um…iPod killer a while back, I really thought that was the ultimate shark-jump. Apparently, though, they really enjoy enormous wasted duplications of effort. That’s why they came up with Silverlight. For those of you who don’t know, Silverlight is Microsoft’s new “Flash Killer”. You can go ahead and laugh now. No, really. Go ahead. I’ll wait.

No, seriously. Microsoft, seeing that there was something they didn’t completely dominate, thought it would be a good idea to reinvent Flash. You see, in Microsoft Fantasy Land^TM Silverlight is replaces the Flash player and everyone develops content on a combination of Visual Studio and something called Expression. The player is “cross platform”, meaning that it runs on PCs and Macs. They don’t have a version for Linux (like Flash does), but hey. Who needs those guys? Of course, you can’t develop content for it on a Mac. The development tools are Windows only. That will surely have the Flash developers jumping ship in no time!

(Editor’s Note: Several people have brought Moonlight to my attention. I don’t really think it counts, at least not yet. Even they admit it’s a work in progress. It’s also developed and maintained by people outside of Microsoft, virtually guaranteeing compatibility problems.)

Considering their track record of Not Invented Here Syndrome, it’s hardly surprising they’d try something like this. What baffles me is that it doesn’t make any business sense. I mean, they’re giving away the player, so there’s no money there. They’re charging for the development tools, which are utterly non-compelling. Throw in the fact that for a content developer, there’s utterly no guarantee that web clients are going to have Silverlight installed, and I can’t really see the business proposition.

You know what would have been great? If Microsoft made something that say, easily integrates .NET and Flash. I mean, the SWF file format is well-known. The license terms permit other tools to create SWF files. Instead of wasting time and money creating a competing standard, why not embrace the standard that 98% of web clients already use to enhance the utility of your own products? Everyone would win, including you, Microsoft!

The funniest part of this whole sordid affair is that Microsoft doesn’t even use this pig. While it’s rumored that they’ll be moving the entirety of Microsoft.com to a Silverlight-based interface, none of their other important sites use it. I see you, back there, waving your hand in the air and mouthing the word “PopFly“. Shut up. That doesn’t count and you know it.

I am a PHP developer. Maybe even a halfway decent one. As such, I often find myself engaged in conversations on the subject of web application development in general and PHP in particular. I am continually flustered by the myths, half-truths and outright falsehoods that technical and non-technical people alike hold about this humble programming language.

I’m far from a zealot about anything software related. I think if you’re excited about software, you’re missing the point. It’s like a carpenter being really excited about hammers instead of building houses. Having said that, I feel I really need to dispel a few of these things before they fester any longer. That and I’m getting tired of being talked down to by Java developers who feel their chosen language is The One True Way^TM. So here’s my list.

Myth #1: PHP is not a truly Object-Oriented Language

I hear this one a lot from Java programmers. It’s completely false. PHP has excellent OO language facilities. There’s inheritance, abstract objects, interfaces, properties and methods. Okay, there’s no method overrides, but there are ways around this. Late binding is still a bit immature. I will say that there have been vast improvements in PHP’s OO mechanics with PHP 5, but I’ve written lots of PHP 4 apps that were totally OO. The mere fact that you can write purely procedural PHP code doesn’t mean that PHP isn’t OO capable. Furthermore, the fact that PHP allows you to mix OO and procedural code makes things like bootstrap scripts really simple.

Myth #2: PHP Encourages Sloppy Code

Also false. Is there a lot of sloppy PHP code around? Absolutely. PHP’s low entry barrier means that a lot of people who aren’t formally trained developers get in over their heads. The sloppy code that results is a result of poor training and bad management, not the language itself. Saying PHP encourages sloppy code is like saying hammers encourage bloody thumbs. Sure, you can bang your thumb with hammer, but is that the hammer’s fault or yours for not knowing how to use it correctly?

Myth #3: PHP doesn’t follow MVC

I know this sounds ridiculous, but I can’t tell you how many Rail-tards I’ve had this discussion with. No, PHP does not, in and of itself, provide an MVC framework. Neither does Ruby, or any language for that matter. That’s because Ruby and PHP are languages, not a application frameworks. MVC is a design pattern, not a language facility. There are many great MVC frameworks written for PHP. I like the Zend Framework. Can you make database calls from a script that also renders HTML? Sure you can. Does that mean you should? No.

Myth #4: PHP is slow because it’s interpreted

This one is insidious because it sounds so plausible. In fact, it should be true. In practice, it’s not. The Zend Engine that powers most PHP implementations is ridiculously fast right out of the box. Combine it with an accelerator, (like the free eAccelerator) which pre-complies and caches the code (and re-complies it if it changes on the disk), and it’s one of the best performing application platforms around, even compared to things that are traditionally compiled, like Java and .NET. Short of writing your app in C or C++, compiling it native and hooking directly into the web server or something, you’re not really going to get much faster.

Myth #5: PHP doesn’t have a good IDE or Debugger

This is true. I doesn’t have one. It has several. There are at least two debuggers and many good IDEs. You can get all the goodies you’d expect, like breakpoints, variable watching, mouse-over evaluation, etc. Can you use a text editor and an FTP client? Sure you can. You certainly don’t have to, though.

Myth #6: PHP apps all look the same

I have to say, it took me a long time to figure out what people who made this assertion were getting at. At first I shrugged it off as if the person saying it was crazy. After all, PHP is just a language, you can make the output look like…whatever you want! Surprisingly, I’ve heard this a lot. Eventually I determined that the confusion stems from non-technical people confusing PHP with PHP-Nuke, which is just an application written in PHP. It’s fairly customizable, but deals in columns and boxes that all look kind of the same.

Myth #7: PHP isn’t really for “serious” developers.

This is another one I hear from Java developers (and perhaps more amusingly, .NET developers). Similar to #2, I think this stems from PHP’s low entry barrier. Pretty much anyone can learn the rudiments of hacking a PHP script together in an afternoon. Does this mean it has no place in “serious” development by “serious” developers? Well, PHP, like any development platform, is a tool. How well a tool is used varies greatly based on the skill and training of the person using it. I have written many large scale, robust, high performance applications in PHP and so have lots of other people.

Myth #8: PHP is only good for web applications

That was true once, but these days it’s pretty much general purpose. It has a command line interpreter that can be run completely independent of the web server (for scripts) but can still use your existing PHP code libraries. You can even knock together GUI applications using PHP-GTK. Admittedly, PHP’s lineage and primary purpose is web applications, but that’s far from all you can do with it.

Myth #9: PHP code is a mess of “include” and “require” statements that break easily.

Being a scripting language, PHP is interpreted at run-time. That means any code that gets executed has to get pulled off the disk and the script in question needs to know where that is. The easiest (but by far the worst) way to do this is to place an “include” or “require” statement that loads your external script. If you do this and you move or rename a file, your script breaks unless you change the offending statement. A mess of includes and requires can make your code into spaghetti.

Fortunately, by following sound OO processes, good naming conventions and using __autoload, in-line includes and requires are generally completely unnecessary. __autoload is a callback function that accepts a class name as an argument. If you instantiate a class that the engine doesn’t know about, it calls your __autoload with the name of the class as a string. Assuming you have a reasonable naming convention, (one class per file, class name and filename match) it’s pretty trivial to load the required class when you need it. This has the side benefit of only loading classes that are actually needed for a particular script, as opposed to loading all of them before your script even runs.

Myth #10: PHP Code is rife with in-line SQL statements

Take a look at a lot of PHP applications and you’ll see it. SQL being scraped together with concatenated strings and passed to database (often mysql) specific statements. This makes your code brittle, annoying to debug and maintain and subject to SQL-injection attacks. It’s also completely unnecessary and easily avoided. Simply use a database abstraction layer like Zend_DB or ADOdb instead of directly talking to the database.

So there you have it. Ten common PHP myths utterly…well…busted. This isn’t to say that PHP isn’t without its faults, but I think few other tools get the unwarranted bad rap that PHP gets. Here’s hoping I cleared things up a little!

I’ve been sitting on this one for a long time, but I was recently emboldened to write about it by reading Derek Sivers blog post about his struggle with a failed transition from PHP to RoR. Then I let it sit for another month. Today, as I watch the Rails community fight like middle school students, I decided I should finally finish this and post it.

While I have spent most of my career as a PHP developer, I have once and again found myself using other platforms because my job at the time required as much. I’ve built apps in Java, .NET and once, a long time ago, Perl. A year or so ago, I was working for a .NET web shop. We had a (somewhat) internal app that we chose as our first foray into Ruby on Rails. Rails is a sexy beast, make no mistake. I, like most developers that have spent untold hours writing the same database access routines over and over and over, was enamored with ActiveRecord and the beauty of the Ruby language syntax. We had a working prototype in mere hours. The ease with which we developed the first 80% of the application felt too good to be true.

That’s when the nightmare began. Implementing the last 20% of the project would end up taking more effort than if we had built the thing from scratch on some other platform. That’s because if you try to solve a problem outside of Rails core problem domain, you’re into plug-in territory, a scary place where people solve their own specific problems and crap out solutions that are kissing close to what you need, but don’t quite work right. Sure, you can write a bunch your own plugins, but then what’s the benefit of the shiny framework? (I’m looking right at you, user authentication and access control.)

So we finished the app, somewhat painfully and behind schedule, but we finished it. It worked great. We were happy, our users loved the demo and we figured our problems were over. Oh, how wrong we were. It was then we discovered that Rails application deployment can break a man.

I am not a fan of Windows anything for web hosting, but I found myself in a Windows hosting shop. (Dammit, Jim, I’m a developer, not a sysadmin.) Options for Rails deployment there are not pretty. You can use WEBrick, but that might be the worst idea ever. You can run Apache/FastCGI etc., but I’ve always felt that the Apache folks treat the Windows version kind of like an afterthought. IIS isn’t bad (considering the alternatives) but it was out at the time due to no FastCGI being available for it. After more than a week of research and false starts, I had the thing running on a FreeBSD box with Apache 2.2, mod_proxy_load_balancer and a series of mongrel servers. (I repeat, Jim, I’m a developer, not a sysadmin.) Not pretty, not easy and I hope no one ever has to move that app to another machine, let alone another platform. Performance, in case you’re wondering, was abysmal. When it was working, that is. It fell down for no reason several times a day.

Sure, you can call me an idiot because I tried to run the thing under windows or because I struggled to deploy under Apache. But um…isn’t the idea behind Rails that it is supposed to be less complex to use?

So what can we learn from all this? Lots! In short, I look at it like this: RoR is the H. Ross Perot of web application development. Perot forced everyone to acknowledge issues they were trying to ignore, but in no way does that mean he should have been elected president. Rails took very solid practices and many new and innovative ideas for how to structure a web application and implemented them in the worst way possible. It did, however, force the entire industry to evaluate its methods. Things changed. There’s now lots of great frameworks in lots of languages that incorporate many of the Rails ideals but are far better performing and easier to implement. Web development can be fun again, no matter what language you use.

So, Rails, take another pointer from Perot: Your point is made. Please fade into obscurity. Don’t worry, we’ll think of you fondly every so often.

I propose a massive write-in vote for Keith Olbermann.

[kml_flashembed movie="http://www.youtube.com/v/fiedCgh_CH8" height="373" width="475" /]