Expanding code functionality - introducing Due Dates v1.1!

Having some success with the previous incarnation of the DueDates-orange project, and some tragic failures in our testing, wiki guides, and issue tracking, my project group was tasked with adding some additional functionality to Due Dates. This included a new library to query, as well as the new options -sort and -within that would allow for more customized reporting of results. We also started using a continuous integration tool called Hudson.

Welcome to Hudson, the weather is currently sunny!

Right away Team Orange got together and set about adding our project to Hudson, however, we made just a little checkbox error and ended up spamming about 70 commit logs over the next few hours. Other than that little hiccup, I found Hudson pretty useful for getting a second opinion on my project with each commit. I also enjoyed looking at the other projects and seeing how they were doing, and where other people were running into problems.

I have issues

My first task was to create a list of issues for this iteration of the project. Having learned a bit more about issue management, I went about making a large slew of issues regarding designs we had discussed and each of the new feature tasks, as well as issues for problems that had not been properly raise and resolved in DueDates 1.0. A large number of issues were added, some would end up being invalid, but nearly all were completed. I tried to break them down into small components, however some were more general to account for common wide-ranging commits such as Javadoc updates.

Why is this class doing this?

We did have some trouble pinning down a real solid design for the application. New features and realizations caused several major changes during the course of working on 1.1. Though we've had a pretty good idea on how to implement the project since the beginning, and have worked very hard to make it expandable, there were a lot of cases where we decided certain functionality needed to be moved around. Some times these moves could cause infamous huge commits that would lead to collision problems later.

See you... online

As a team, we weren't able to meet too often unfortunately. Busy schedules and somewhat opposite productive hours (Daniel is bit of a night owl, me not so much) did cause some problems, but we were generally able to iron things out. Always exciting to log in and see what happened while you were out! Despite being fairly productive on the project, I definitely see how much time could be saved working as a pair. There were a number of times when code was committed that would have been caught by the other person immediately if we were pair programming. I personally had several other big projects to work on for school and wasn't able to make commits every day, but rest assured, I certainly thought about Due Dates every day, often making charts and coding on paper in other classes! *hides*

Passing the test

Currently the two biggest issues the project has is proper testing and proper exception handling. Daniel implemented the vast majority of this code and we are both still pondering if they are properly done. The tests take quite a bit of time due to the many log ins to lender systems, but they are fairly thorough. I'm sure we'll come back to these in the future.

Conclusion

Overall, I'm fairly pleased with the DueDates-orange project. It's grown quite large and I know there are improvements to be made, but I think the functionality is pretty good and the design will allow for quick implementation of new features. We've also greatly improved the wiki guides so that the project can be used by other people as well, not just our two-person world. Stay tuned for the latest news and avoid late fees!