When I was at the Library of Congress, I worked with a team lead - Duane Gran, one of my three readers - who hammered us when he joined the team. Our build process was lacking, our version control was non-existant, and our overall architecture... needed some work. But in no time he turned things around and it was smooth sailing through the end of the project. I thought this was the norm and have generally worked for companies and teams with the right pieces in place.

Later I worked in an environment where although there was version control (SourceSafe), almost no one used it. There were three of us out of the team of 10 that used it with any frequency... and one person who would do two checkins. Once at the beginning of her project, once at the end. I thought this was the exception.

As I work with different people, projects, teams, etc, it turns out, I was wrong in both cases:

I believe that few developers know how to use version control at all, let alone effectively.

In the past month or so (including ZendCon and DCPHP), I've talked with numerous developers who don't use any form of version control. Some believe that since they're the lone developer, they don't need it. Some believe that their team is smart enough not to need it. Some believe that version control is too complicated or limiting. Finally others believe it's only for "those enterprise projects".

For any PHP'ers who might have been asleep for the past week, it is official... The PHP4 End of Life has been announced:

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5

Honestly, it's not a surprise at all. As noted, PHP5 has been out for 3 years now, all of the authors have moved on, the bulk of the innovation is happening in PHP5/6, and most of the books and presentations have moved onto PHP5 long ago. But here's the thing that concerns me... when you combine this decision with the research by Damien Seguy, the numbers are disconcerting at best.

I received word late on Friday afternoon, one of my presentation proposals for ZendCon 2007 was accepted:

The Bionic App

We can rebuild it, we have the technology. Usually when we think of rebuilding an application, the first step is to start from a clean slate... losing the lessons we've learned before. Fortunately, we have an alternative. By using tools like the ZendFramework, Smarty, and your favorite Ajax library, you can bring even the most boring application up to date and implement completely new functionality quickly with minimal disruption.

Of the proposals I submitted, I'm the most excited about this one as I get to talk a bit of strategy, a bit of code, and I get to talk about major development efforts that I've undertaken in the last year. My goal with any of my presentations is to cause the audience to walk out saying "wow, I want to try that" or "I think I can use that here". So now I get to walk the tightrope of trimming enough to fit into a single hour but still giving the audience something actionable.

Last fall I found Ohloh and I have to say... I'm still amazed by it. From one place, you can get summary information on the project's status, see similar projects, see a list of recent commits, who did them and overall information on the code itself. If you have any involvement in the Open Source Community either as a user or as a contributor - and if you're on this site, most likely you do - you should check out Ohloh and look up your favorite projects. You can easily comment upon or flag the projects you use or appreciate. I just updated mine. Anyway, the single most useful aspect I've seen shows the overall lines of code over time. For example, dotProject currently has 134kloc and is shrinking... wait, shrinking!?

Over the weekend, Robert Scoble pointed out all the technology that Steve Jobs has killed off over the years and asked a simple question:

which feature are you getting rid of to make your product/service/store/business simpler?

As I've pondered this over the last few days, I've been looking at the various products, systems, and code I've been working on and considering what could be cut away. What things can go into the next version? And even more importantly, what aspects don't need to be in any version?

Last night, I committed a small portion of code to the dotProject permissions system which is important enough that it deserves some discussion here. It all stems from a relatively simple question:

What is the difference between 'edit' and 'view' permissions?

Sounds easy, right?

'Edit' permissions allow a user to edit the selected record. If I grant edit permissions to the CaseySoftware company to a user, it means that they can view the related information and edit any of it. They can't necessarily delete it, but they could create Projects, etc.

About six months ago, I started work on a small PHP project. It involved a relatively simple concept with an identical method of loading and displaying content but each set would have a custom look and feel*. It seemed liked a relatively straight-forward small-scale Content Management System with a transform layer in front.

At the beginning, I evaluated using Drupal to see how it would work for our needs. Although it did aspects of what we were looking for, it didn't seem to support the dynamic theming required. Regardless, there were a few aspects which Drupal did beautifully, so I pulled a few of those functions - properly attributed of course - and adjusted them for our purposes. A small but useful success.