I know I've said it before, but this time I'm serious... the End is Near:

web2project is nearing v1.0

We - mostly Pedro - have been pounding on bugs, features, and all kinds of shiny and nifty new bits for the last 9 months.  The most important parts are the UI, performance, and security/permissions.

First, I'm not going to go into the security fixes again, but the permissions improvements are huge.  Not only can you quickly review an individual's permissions by going to the User Permissions Information screen but the system now caches the permissions calculations.  This reduces the overall number of queries on any page by approximately 90%.  Yes, you read that correctly... 90%.

Or "Wait a second.. what is that burning smell!?"

Now that things have calmed down a bit with WhyGoSolo, I'd like to give a bit of my perspective...

Whenever you launch a site, there are going to be problems.  Some are going to be tiny and only detectable by the handful of people actively working on it.  Others are going to be so large that you briefly consider giving up technology and living in a tree.  Regardless, they all need to be dealt with... so the questions become:  How and when?

In my book, there are three types of issues and each requires a different response:

First, there are tweaks.  These can be spelling errors, broken images, bad punctuation, or a variety of other things.  These are not functional things at all.  These probably aren't preventing people from using the site.  They're probably not breaking things.  More than anything, they just annoy your users (or your boss) and hurt the credibility of your site.

A couple weeks ago, I started on a bit of tirade discussion about version control that turned into a short series - Version Control and You Part 1, Part 2, and Part 3 - and while that series may expand later, I'm moving onto the next step of the process....

Deployment!

For some people, the idea of deploying code keeps them up at night. Every time they consider what it takes to deploy their latest and greatest changes, they break into a cold sweat. They think they know the changes they've made. They think they know the code/db changes required. Generally this type of team has a deployment process of "well, we ftp it to the server and click around to see if it works".

Um... yeah.

For the record, that's not a deployment strategy. It's the fastest way to break everything and piss off frustrate your users.

In a recent Slashdot article, we get an article from Sal Cangeloso discussing some of the potential up and downsides of Dell's recent decision to put Ubuntu on some of their laptops. He covers some of the obvious aspects such as the potential for Dell to offer lower-cost models based on the lower licensing fees required and the new strains that will come on the infrastructure for updating/downloading software, but I think he misses one major aspect.... technical support.

The days leading up to a product/system release is always an exciting time. For organized teams, it's a tightly controlled process where useful bug reports roll in from the QA team and beta testers while a small strike force of the best team members from each functional area track down the root of the problem and deftly wipe them out with a few swift keyboard clicks and a new deployment. As this cycle repeats a few times, the problems become less frequent and involve more contortion to create and the strike force begins to break a sweat... This is not the team I'm writing about.

If you're a PHP developer and you don't know who Damien Seguy is, stop what you're doing and check out his work. Every month his scripts gather information from the PHP headers of tens of thousands of websites and server and then aggregates this information into something useful for the rest of us.

From these headers, he's able to determine and track the various versions of PHP over time and give the rest of the world insight into what's really going on. I'm not going to go into all the data in great detail - he already does that excellently - but I will cite this one:
This is one of the most interesting and to every mISV or Open Source Project, the most important. According to this, PHP5 penetration is only 17% or approximately 1 in 6 sites. As we're developing exciting new applications and tools, we need to keep this in mind. We need to be aware that some of our potential users and customers are still running on significantly different versions of code that have much smaller/different feature sets. These aren't necessarily old versions - PHP4 is still under active development - but they don't have some of the "modern" functionality that we've learned to love in PHP5.

Chris Shiflett recently wrote on the inherent problems that go along with disclosing bugs in web applications (specifically security holes). I believe he took the responsible route of reporting the issue privately, waiting an appropriate time, and then releasing the details publicly. In his case, the "appropriate time" was a year, Amazon appears to have effectively reduced the potential damage of the issue, and everyone is sleeping soundly at night... but what if it didn't go so smoothly?