My decision to hand over project maintenance of the Achievo project has turned out to be a good one.

Since Sandy took over, we've had 3 new releases. A first release candidate for Achievo 1.2 was out when he was at the helm hardly one month, and yesterday, he released Achievo 1.2.1, which contains several important bugfixes for the 1.2 branch.

I've had several remarks from users who were 'glad the project was apparently still alive after months without a release'. I think the project would've died prematurely if Sandy hadn't taken over.

As a result of the takeover, I was able to finally take the time to do some other things I've been planning to do for a while now. I've written a Typo3 ATK bridge that makes it possible to develop Typo3 backend modules in ATK. This reduces Typo3 backend modules from hundreds of lines of code to the minimal amount of coding we're used to from using ATK. This extension is currently being tested internally and will be released with a howto soon.

Also, I'm finishing up ATK 5.6. It contains some interesting new features, among which is an atkCalculatorAttribute for arbitrary calculations on fields and an atkMlWrapper which can turn any attribute into an internationalised field (sponsored by our friends at Zicht). ATK 5.6 should be out within 2 weeks.

Finally I've been spending a lot of time on epointment.com. We're finally getting somewhere with the features we need. I will be writing a 'syncing Achievo with epointment.com' howto soon. Although at its current state, we have a lot of competition from the big guys, we're seeing quite an amount of interest from Dutch people (probably because Google Calendar only has an English interface at the moment), so we're coming along nicely. We're also talking to the guys from MarkThisDate for cooperation (open standards rule!).

The largest benefit for ATK will be that we're pushing the development of the Ajax functionality in the framework. In ATK 5.7 (which might become ATK 6) you can expect a lot of (optional, ofcourse) Ajax powered functionality such as autocompletion and Partial Page Rendering.

When in october 2004 Peter and I took on the idea of developing epointment.com, we thought we had all the time in the world, given the fact that at that time most online calendering applications were rather rubish.

Over the past few years, several new sites have been created for this same purpose, and when a few months back the rumours about Google Calendar started, I was initially horrified. I felt what I think employees of Netscape must have felt when Microsoft released Internet Explorer.

Funny thing is, it's hardly ever about money. Netscape was already freely downloadable when Internet Explorer was released. Similarly epointment is as much free as Google Calendar is (our investments are to be won back by providing professional services). This is more about how given enough weight, any market can be taken. Internet Explorer didn't crush Netscape because it was a better browser. Microsoft just was a bigger player with better cards.

Now we don't claim to be better than Google Calendar, that would be quite presumptuous, given that probably they employ some of the smartest minds in the industry and have a lot bigger team than the two of us working on epointment. But my point is that neither price, nor quality, matter, when the elephants walk by. The fact that it is 'Google' Calendar and not 'Just Any Calendar', makes it Good. (I sometimes have the same feeling about art. Some art is art only because of the signature on it). And don't get me wrong, Google Calendar actually *is* good. And competition is a good thing anyway, it gives people choice.

And, instead of sobbing, which never really helps anyway :-), mice like us should do the only sensible thing: distinguish ourselves. We have many ideas that we will roll out in the foreseeable future, but we already do it very subtly. While Ajax is hype and everybody makes sure Ajax is part of their product description, we stay away from the term. We actually use the technology (using prototype and script.aculo.us if you're interested), but you will have a hard time finding it.

Another choice we made is to make the agenda not look like the digital version of the schedule of a trained secretary, but make it something that is more like the type of calendar that hangs on your mother's wall. Keep it simple, so to say. Most people don't really need a digital secretary, they just need a way of keeping track of (and remembering) their appointments.

So no, you cannot sync your appointments in epointment yet, we'll focus on ease of use first (and how much do the non-techies sync their agenda's in real life anyway? ;-))

One thing we did realize in the past months do is that looks do matter. The initial layout (well, let's rather call it a complete lack of layout) was, in hindsight, terrible. So yesterday we finally released a new version of the site that we feel looks a bit better. Now all we have to do is stay away from the elephant's feet and run right under them and finish first.

Oh and, because we are geeks after all, we just had to implement easter eggs. Not that anyone would ever find them, but writing them was fun in itself.

For almost 6 years, I've been the lead developer of the Achievo Project Management application. It has always been an interesting project. While being a relatively small application, among larger suites such as phpGroupware, we've always tried to keep it simple, targeted at a certain set of functionality, with a specific focus. I think we succeeded in doing so, as because of this, it appeals to a specific set of users and mainly to smaller companies with small projects they need to track.

About 5 months after its first release, we rewrote Achievo from scratch, because a community started to form that demanded new features that were time consuming to add, even if it was just the addition of a new field. Achievo was in fact the first thing I ever wrote in PHP, so the code was not something to be proud of. We learned an important lesson from that first release, and we replaced the large set of php scripts with clean, object oriented code, and the basis of this quickly became a framework. About two years ago the framework had evolved enough to stand on it's own, and the ATK framework was released as a separate product.

Since then, ATK has seen a lot of growth. Last year, the ATK community became larger than the original Achievo community, and as such, took up a lot more of my time. Also, I'm working hard to get my own company, epointment up and running.

The result is that the Achievo Project Management application does not get the amount of attention that it deserves anymore. This is painfully evident in the release frequency, the last stable release was (although development never stopped) a year ago. This is not motivating for the developers that are working on new features, and it's not good for the community.

So I've made the decision to hand over the Achievo Project Management app, so I can concentrate on ATK and epointment. The most likely candidate for taking over is Sandy Pleyte, as he has been one of the main developers since the start, and has always fueled Achievo development. I've discussed the future of Achievo with him, and he has a lot of ideas, both for functionality and for restructuring the development process, so I'm confident that Achievo is in good hands with him.

This does not mean I will leave the project entirely. I will remain on the development team, and will continue to work together with the rest of the team. It's just that I think the project maintainer should be able to have more dedication for the project than I am currently able to offer.

So I think this is what's best for the project, and I wish Sandy the best of luck. You will probably start seeing the results of this very soon, as Sandy is eager to put his plans to action.

A few weeks ago, we had a major problem with software we'd written for a client. It was software for sending mailings to the client's customers. Suddenly there were many reports of clients receiving multiple mailings instead of just one.

The problem appeared to be in our test code. The software had a 'test' mode for testing the mailing by sending it only to the author and a small test team. It appeared that for some reason, all test mails were being mailed to the customers as well.

This problem would not have appeared if we had applied what I would like to call 'defensive programming'. Take a look at this example, which is an oversimplified version of how the software worked:

 
  ....
  if ($mode=="test"}
  {
     $recipients = "testers@somedomain.ext";
  }
  else
  {
     $recipients = "customers@somedomain.ext";
  }
 

What happened was that due to some change in the software, this particular piece of code, along with a bunch of other code, was refactored into some other function, where the $mode variable ran out of scope. Result, $mode=="test" is never true, and we send all the test mailings to all our customers.

The defensive programming approach would be like this:

 
  ....
  if ($mode=="production"}
  {
     $recipients = "customers@somedomain.ext";
  }
  else
  {
     $recipients = "testers@somedomain.ext";
  }
 

Would the same problem appear, the bug would have been less awkward, as only the testers would receive the mailing. Ofcourse this doesn't solve the actual bug, but it helps fight bad results.

In essence, you have to expect the worse. Write your code with Murphy in mind. Anything that can go wrong, will go wrong at some point. Especially when relying on (global) variables that are defined at some distance from the code where they are used, so it's easy to not notice the problem until it's too late.

P.S. We've released ATK 5.4 this week and, [shameless plug], my little .com adventure epointment.com has gone live this week in a very basic first version [/shameless plug]. For those interested: the epointment site is entirely written in ATK, while the backend server was written using Ruby on Rails, linked together via SOAP. What better way to compare ATK with Ruby on Rails