DueDates v1.1: Further Progession Into Open Source Software Development
| Posted on Monday, November 03, 2008 |
0
commentsAdd comments |
Ladies and Gentlemen, it’s my pleasure to now introduce to you DueDates-Silver v1.1. DueDates v1.1 has come a long way since just two weeks ago when v1.0 was first released. In this release, my project partner, Robin Raqueno, and I strove to make it satisfy even more of the Prime Directives of Open Source Software (OSS) Engineering. (You can read about these directives in my blog JFreeChart: Open Source Charting Solutions.) And, the “measure twice, cut once” methodology first embraced during the development of DueDates v1.0 continued to pay off while enhancing the project to meet the specifications of DueDates v1.1.
OSS Priorities
While we had new specifications to build into the latest release of DueDates, my top priority was having our project add a linchpin in the form of an XML file that held library data. This XML file would bind the project together in a data-centric way that both Robin and I had envisioned in the project since development of version 1.0. It would also provide excellent OSS support of the prime directives by freeing users and contributing developers to easily expand the project to include their own set of libraries without much effort. By simply following the repository template we provide, they could add their own library information and even remove the libraries that we provide. Peers who reviewed our project were amazed at this, believing it to be a great feature and one that all DueDates project should incorporate.
New Specifications
This version of DueDates supports sorting of results by library or by the date items are coming due. A second specification was to support a query of items coming due within a specified number of days. Also, prior to the v1.1 release, we had a peer review of our project from which we were to incorporate any additional suggestions as appropriate and possible.
Measuring Again, Cutting Again
Robin and I really didn’t have many issues completing this week’s tasks and moving DueDates v1.0 to DueDates v1.1. Prior to adding the new specification, we looked into two aspects of changes to our project. First, we wanted to move to an XML based repository for our library data. We searched for a day on the topic and eventually found this article from Sun Developer Network. Following these instructions, we were able to add this feature to our project without much effort.
Our next goal was to find an appropriate command line parsing software to assist us in that task. We found an absolutely wonderful OSS command line parser from John E. Lloyd called ArgParser. This did everything we needed, along with providing bells and whistles.
After resolving those issues, we set about the task of adding our new specifications. We were basically able to do this over the course of the first few days of development, leaving the remaining time to do our peer review projects and provide additional testing of our system. The biggest change in implementing version 1.1 was to alter the UserLibraryInfo (ULI) class from being a single object class to a collection object class. Version 1.0 allowed ULI to take in only one user-library pair and query results for that single value pair. The latest version allows multiple user-library pairs to be added to the ULI object and all queried at once.
Having abstracted the problem out even further this week allowed us to make an additional change to the project that allowed the user to specify the library repository (XML data file) that they want to use from the command line. The remaining time we spent testing and updating our User and Developer Guides per the comments from our peer reviewers.
Conclusion
We used continuous integration during the development of DueDates v1.1. We failed a few times, but these were mostly due to changes in our project structure that did not get updated properly when committing the changes to Google Code’s server. We altered our project structure, moved files around, and deleted files. Occasionally, the old file had not been removed from the local repository or the SVN repository which would cause builds to fail. But in general, I think striving to keep a sun on the Hudson server was a motivator to not break the build.
Robin and I continue to work well together, and even received high praise from our peers this week on the quality and the direction our project has taken. We have several ideas for our project once it moves in to a GUI world and look forward to that opportunity.
OSS Priorities
While we had new specifications to build into the latest release of DueDates, my top priority was having our project add a linchpin in the form of an XML file that held library data. This XML file would bind the project together in a data-centric way that both Robin and I had envisioned in the project since development of version 1.0. It would also provide excellent OSS support of the prime directives by freeing users and contributing developers to easily expand the project to include their own set of libraries without much effort. By simply following the repository template we provide, they could add their own library information and even remove the libraries that we provide. Peers who reviewed our project were amazed at this, believing it to be a great feature and one that all DueDates project should incorporate.
New Specifications
This version of DueDates supports sorting of results by library or by the date items are coming due. A second specification was to support a query of items coming due within a specified number of days. Also, prior to the v1.1 release, we had a peer review of our project from which we were to incorporate any additional suggestions as appropriate and possible.
Measuring Again, Cutting Again
Robin and I really didn’t have many issues completing this week’s tasks and moving DueDates v1.0 to DueDates v1.1. Prior to adding the new specification, we looked into two aspects of changes to our project. First, we wanted to move to an XML based repository for our library data. We searched for a day on the topic and eventually found this article from Sun Developer Network. Following these instructions, we were able to add this feature to our project without much effort.
Our next goal was to find an appropriate command line parsing software to assist us in that task. We found an absolutely wonderful OSS command line parser from John E. Lloyd called ArgParser. This did everything we needed, along with providing bells and whistles.
After resolving those issues, we set about the task of adding our new specifications. We were basically able to do this over the course of the first few days of development, leaving the remaining time to do our peer review projects and provide additional testing of our system. The biggest change in implementing version 1.1 was to alter the UserLibraryInfo (ULI) class from being a single object class to a collection object class. Version 1.0 allowed ULI to take in only one user-library pair and query results for that single value pair. The latest version allows multiple user-library pairs to be added to the ULI object and all queried at once.
Having abstracted the problem out even further this week allowed us to make an additional change to the project that allowed the user to specify the library repository (XML data file) that they want to use from the command line. The remaining time we spent testing and updating our User and Developer Guides per the comments from our peer reviewers.
Conclusion
We used continuous integration during the development of DueDates v1.1. We failed a few times, but these were mostly due to changes in our project structure that did not get updated properly when committing the changes to Google Code’s server. We altered our project structure, moved files around, and deleted files. Occasionally, the old file had not been removed from the local repository or the SVN repository which would cause builds to fail. But in general, I think striving to keep a sun on the Hudson server was a motivator to not break the build.
Robin and I continue to work well together, and even received high praise from our peers this week on the quality and the direction our project has taken. We have several ideas for our project once it moves in to a GUI world and look forward to that opportunity.
