DueDates

"Two Heads Are Better Than One"

That basically sums up the experience for DueDates. Any problem I had, I felt less worried than usual because I had someone else to consult. Someone had my back and I had theirs. My partner this week was John Zhou.

The Task This Past Week

We were all partnered up this week with another classmate to work on DueDates, an Open Source Java command-line program that retrieves checked out library items information.

Basically any UH student with an internet connection and a machine with Java 6 installed can use this program. They simply need to perform the following steps and as Emeril Lagasse would say, "BAM!" Users see their results in the command-prompt. Unfortunately, the results are not as instantaneous as the expression. It's more like "BAAAAAAM!" stretched out over 3-6 seconds.

Sample output can be seen in the screenshot below.

What We Accomplished:

My partner and I were able to meet most of the requirements for version 1. From the user's perspective, the program meets all the requirements of version 1. But from a developer's perspective, we lack testing. We did not get 100% coverage on our test cases. In fact, we sort of ran out of time to do much or any testing. We did attempt it and ran into some problems.

Problems We Encountered and Solutions We've Arrived At:

1. Emma and JUnit

• Because of the lack of javascript support in HttpUnit, JUnit Testing fails and presents an error when run with Ant. This errors seems to be apparent cause to the low coverage reported in Emma. I guess the coverage test stops as soon as the error is reported.

2. Design

• We felt that all libraries will needs it own unique way of logging in and retrieving information. So all libraries should be a subclass to a larger superclass. To keep output consistent, we decided that the superclass should have toFormattedString method. And all subclasses would use that method to keep output uniform.
  
• SOLUTION: Created superclass Lender, with subclasses UhManoa and HawaiiStateLibrary. All within placed inside a subpackage, "library".
  

How We Worked:

I thought we did a pretty good job accomplishing most of the tasks considering how busy the other's schedule. Both of us had midterms at different times throughout the week. Nights when I was free, my partner needed to study. And the opposite applied when my partner was free. But even through all of the schedule conflicts, my partner and I were still able to meet about 3 times for about an hour each meeting at Hamilton library.

There's nothing much more we can do. It's midterm time and it's good that we can even find time to work with one another. I think the number of face-to-face meetings was about right. We didn't exactly meet on weekends but we communicated through IM. I do wish there was somewhere more casual and laid back to meet. However, it's hard to find somewhere with WiFi and food to eat.

What I Learned:

It's different thinking about future releases of this project. It's difficult to know what to expect for future libraries. It's also difficult to run tests since all accounts could generate different results. Except in my friends' cases, they all have no books checked out.

Google Project Hosting keeps everything very public. Every single update is documented. Not only do you want to think for the future, but you want to put out your best impression to the world. You never know who wants to contribute and who is critiquing your work. Since our real names are published, there is pressure to write clear, well-documented code.