dotProject

I guess it is a bit presumptive to call two developers a hackfest, however mosen and I have spent the last week hacking away at dp3 (dotProject version 3 for the uninitiated) and achieving some considerable milestones.

I have been a bit disillusioned with dp2 and dp3 was a pretty bold move to address some of the shortcomings we saw in the version 2 code. Ditching the old hand-crafted framework and suite of third-party libraries was the easy part, thanks to Zend Framework. Almost everything we looked at in terms of simplifying our infrastructure had a supporting package in Zend. Most of these packages are extremely well thought out and with a bit of effort can make any application shine. Why write your own database abstraction when Zend_Db has a rich collection of classes to support just about anything you want to achieve? Why write your own authentication classes when Zend_Auth does it far better and is far more complete? In addition we have used Zend_Translate, Zend_Form, Zend_Session, Zend_Date, Zend_Validate, Zend_Log, Zend_Mail and the entire Zend MVC architecture to improve the structure and stability of the product.

The benefits that we believed would be derived from moving to a stable framework are starting to be realised. One of the major hassles I saw with dp2 was the ability for third-party module developers to be able to integrate well with the base product. A lot of the work we've done is to ensure that the new structure has a stable and well-defined architecture and API (Application Programming Interface) to allow third-party developers to get real integration without having to change core code. Being able to put extra fields on standard pages, to be able to modify data on save of a standard object, and a heap of other benefits is going to be possible. Much of the support code for this is already in place.

Permissions has always been an issue and I've not really seen a sensible approach to permissions that makes sense in a project management environment. dp3 now has a completely new policy-based permissions system that is far simpler to understand and implement. Along with this is a far more extended ability to group people. We realised that Companies and Departments don't really make sense in a large number of cases, and people may have Branch, Region, Workgroup, Task Group, Team or any other hierarchy that they may want to use to identify groups of people. This is now possible. We've even extended the concept to have members of Projects, Tasks and other system objects that can either be active or passive resources (think of a programmer and their manager, the programmer may be an active resource on a task - doing the work, but the manager may want to be kept up to date with progress reports, hence a member of the task, but not an active one). Permissions is now handled further down the stack as well, so it is far harder to get around and is orders of magnitude faster than any other approach we've seen.

But what about the current functionality, I hear you ask. In all cases where the functionality makes sense it has been kept, while where we could do it better we are taking the opportunity to do so.

Thanks to deBortoli Wines we have been able to fly mosen down from Sydney and have the time to spend together talking about, planning, and coding the new infrastructure. And may I put in a plug for mosen (or Eamon as his parents know him). Here is a coder who has a commitment to quality and a dedication to see a project through. I've been really impressed with his ideas, his code and his thinking outside the box. If anyone out there needs a great programmer then you would be hard pressed to look past Eamon.

So it is on with the show - we have a great start and no roadblocks in sight!