For the last week and a half, my partner Scheller Sanchez and I have been working on Due Dates Version 1.1. This new version has many new features compared to the last one, including support for the Hawaii State Library, a sort option, as well as a within option. All in all what ended up happening to our original code was a lot of redesign, a lot of review, and then even more redesign. Visit the project homepage to check out how it turned out.
VERSION 1.1 DESIGN
A lot has changed in the design department of our Due Dates implementation. Some of the things we initially made for future extension, like the LibraryVault class, we found were obsolete for this version because they were not abstract enough. For this very reason, I redesigned the overall structure a lot, first by putting all the methods for every library in the LibraryVault class, and then by making the LibraryVault class an interface for each separate library to implement from. This, I think turned out to be quite efficient as one can now add libraries easily based on the interface.
Another big change in version 1.1 was the creation of the ItemDue object that holds information about a borrowed item. Using this object, we were able to create an overall List of all the items that were due, allowing the program to sort through them, as well as perform other functions on them.
Also, Due Dates version 1.1 uses the open source ArgParser libraries to parse the command line arguments. These libraries are super useful in specifying command line options and ranges of certain arguments. Using the argparser definitely added to the robustness of the overall system, and it will allow for future additions to the program as well.
Since the release of Due Dates 1.0, I have been loaded with huge amounts of school work. In the last week and a half I not only had two midterms, but two large midterm projects due, not including Due Dates. For me, this was the main thing that slowed progress down on developing the system. I really spent all my extra school time working on Due Dates and it still was not enough.
What I had to do to really get things done was reserve certain days for working on Due Dates, and just work extra hard on it during these times. Although it was not the best system for doing things, it worked out. It was also nice that the system was reviewed twice in this time, helping me to narrow down what the most important things were to do.
COMMUNICATION PROBLEMS AND GROUP PROCESS
Another thing that changed since the last release of Due Dates was communication between our group. It turned out to be much, much harder to meet up in person this week since Scheller and I both had huge amounts of other work to do. By last week wednesday, the original date for the release of the system, he was still unable to help out on Due Dates because he was stuck working on another project. It was hard to collaborate on things because of this.
When we met in person a few times we went over some issues to do as well as some design problems we had to solve. This was good, but it was far from planning everything out. At some point last week I realized I had to just start trying out my new design ideas for Due Dates version 1.1. This was not efficient since I was the only one doing things, and because of this I had to redesign the program a few times over. Things didn't run as smoothly as they did with the release of version 1.0.
Sometimes it took awhile to contact Scheller, but eventually I would get some sort of answer. Luckily we could communicate via instant messages, and luckily we were using configuration management software. It could have been worse. The truth is this version of Due Dates probably could have been better if we had worked more together on it. We did our best for the time period, and I tried my best to release the program up to specifications. I hope for the next release of the program I will be able to meet up with my group a lot more in person. That seems to be the best route for creating collaborative software.
WORKING WITH THE HUDSON SERVER (Continuous Integration)
For the development of version 1.1 we had access to the 'Hudson' server, which is used for the continuous integration of our system. This was, to say the least, really, really, really useful. I could not believe how many times a build would fail on there when I was positive I just checked it on my home machine. On one occasion, I would fix some problems that were found and that would cause even more problems (this had to do with declaring 'private final static' variables and the order of those words). I would commit thinking that everything was a-okay, but the build would fail and hudson let me know each time. Having a back up check using continuous integration is essential.
On the other hand, it was a bit much to always have the system build on Hudson. On many occasions I wanted to commit my code to the server for my partner to look over but the code did not pass verify due to QA errors that popped up. I would always end up spending a long time fixing these errors, when all I wanted to do was commit the code I had so far to show my partner, regardless of the errors. For a while I ended up committing code that would fail the build because of this. That's why we probably still have 'cloudy skies' on hudson.
FINAL THOUGHTS
Overall, working on Due Dates version 1.1 was a lot more of a challenge compared to version 1.0. There were a lot of factors that caused this (time constraints, group process, etc), but I still believe the final outcome turned out great. The program runs nicely now and has all the functionality needed. It is now very extendable too! Developing the next version of the system will be interesting.
Some of the other teams also did great implementations of Due Dates for version 1.1. One worth checking out is Due Dates (Team Silver). I did a review on their system and it is just really awesome. Watch out for the next version of Due Dates coming soon...
Posts
0 comments:
Post a Comment