The Release of Due Dates Version 1.2 [team gold]

This week marks the release of Due Dates version 1.2 [Project Homepage]. With this new version comes two new features: an email reporting service, as well as a timer-based reporting function that allows the user to automatically have the program run at some specified interval of time. Both functions have been integrated into the Team Gold release of Due Dates and everything functions well.

This release also builds upon many fundamental changes to the source code. Classes have been stripped down and simplified. More checks have been added to ensure program robustness and a more exhaustive test suite has been created with well over 90% coverage. Due Dates v1.2 is definitely an upgrade from Due Dates v1.1.

GROUP PROCESS

This weeks development process was much the same as it has been the past few weeks. Although I had time to meet up, Scheller was really busy and so we were only able to meet up a couple times. Otherwise, we communicated via email, IM, or phone. Initially, we talked over program design and test design. We set up a bunch of issues that we thought would be the most useful in modifying the system. This was all good.

However, I found that Scheller and I have two different development styles. I like to get started on things early and he does stuff later. This can be attributed to Schellers heavy workload, but it really is hard to collaborate efficiently like this. Most of the time I felt like I was working alone on the project. I would just keep him updated with what was going on. Scheller did create some good code for the project though. He implemented the self-timer for running Due Dates on a schedule. 

Overall, the development of Due Dates v1.2 could have been better if Scheller and I had worked similarly on the project. Although the state of project meets my initially expectations for the program, things could have been done more efficiently. I would still like to meet up more in person, or at least communicate more on all things relating to the program. Hopefully on the next version of Due Dates, this can happen.

DEVELOPMENT

Development for Due Dates v1.2 went really great for me this week. I attribute this solely to starting early. I did not have to rush on anything the entire week, and I was able to really think out my ideas for the system. I felt like I was ahead most of the time which is not a usual thing for me. I hope to keep up this sort of development style with future developments of Due Dates.

DEVELOPMENT PROBLEMS 

The biggest problem we had in the development of this release was trying to get the DueDates.jar file to run correctly. The reason it was so challenging was because the program now uses JavaMail, and referencing these libraries is quite different than most libraries. They must be put directly in the system frameworks rather than referenced in the build classpath. It was especially confusing for me since my computer runs on soylatte 1.6 for its Java JRE, not the usual Java release.

Initially I had a lot of help from other students like Arthur Shum and Ronn Reeves. At one point, Arthur and I did a screen sharing thing through a messenger program called iChat, which allows him to control my computer. That was cool but it did not solve anything. We were copying the mail.jar file to the lib/ext of my Java framework, the right thing to do. However, it was still not working. 

Eventually I realized the only difference between my computer and Arthur's computer was that I was using soylatte. Thus it had to be a problem with that. Then it dawned on me (with the help of Arthur and Ronn). Instead of having the mail.java file in the system framework directory, I needed to put it in the soylatte directory on my system. This simple change fixed it all and the jar file ran fine after that. I was really stumped by this whole problem. I'm really glad it was eventually sorted out.

CONTINUOUS INTEGRATION AND SOFTWARE ICU

The development of Due Dates v1.2 was monitored by HackyStat, a software ICU program reviewed in my last blog post, In the Green With HackyStat. Essentially what this does is monitor all the vital signs of your program as well as monitor the development process. Due Dates had sensors sending data to HackyStat throughout the last week and it was great to visit the project page and see the results of this. It was nice to see current values and trends having to do with things like complexity, coupling, coverage, tests, development time, etc. I usually checked it a few times a day, just to see. I am happy to say Due Dates v1.2 is still all green.

What was cool about all this was that the Hudson continuous integration server ran a daily build that would send sensors back to the HackyStat sensorbase. This meant there was an automated build each day just for the software ICU. It was great to have the Hudson server do this.

FUTURE DUE DATES IDEAS

With Due Dates v1.2 there were a lot of improvements in functionality and there were many improvements in the source code. I am very satisfied with how it turned out. Yet, I know this program can be made even better! Something that will definitely be done in the next version of Due Dates is to create an online application for users to use. This will make it ten-fold easier for the average person to go and use Due Dates. We will be using Wicket to do this. It should turn out really good.

The Release of Due Dates Version 1.1 [team gold]

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.

TIME CONSTRAINTS WITH VERSION 1.1

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...