DueDates

Recently I started a Java project named DueDates. What this program does is retrieve information from libraries and allows a user to find out what books they have borrowed along with their due dates. In this project I worked with Jon Ly we put together a program that allowed a user to access the UH Library system and find out the books he has borrowed. The project can be found here and project files can be downloaded here.

Design

One of our first problems was to figure out how to divide up the classes. We wanted to make sure the program was extensible so that in the future we could easily add more libraries and features. We created a Lender superclass which in the future we hope will have generic methods that can access libraries that can't be found in the program. There is also a toFormattedString method in it that we use standardize the output of all libraries. In the future we could also add other standardized features to the Lender class like a GUI.

From that superclass we created library subclasses that had login and getInfo methods specific to each library. Later we can add other methods that might be unique for each library.

Problems and Resolution

Using HTTPUnit we had the program look for the first table with the string "Renew?" on the UH page which should be the table containing the information on books borrowed. It's doubtful that any other table will start with that string and testing for that possibility would be slightly difficult since the only other possible table before that one is the Patron Block table which I believe is related to late fees.

Since we moved all our methods to other classes there was only a static main method in the main class so a Singleton error cropped up while running PMD. This was an error I've never seen before and through some research I found it can be fixed by adding a private constructor.

One of our biggest problems was making the test cases. It took me a while to figure out how to pass arguments to test cases. I couldn't tell if it worked because we couldn't figure out how to get the login method test to work. The method was suppose to return a object, in this case a WebConversation object, but we couldn't figure how to check if the correct object was returned. So we had to add a @Ignore to get the program to pass verify.build.xml.

Another problem I noticed was that when running Emma it would produce a Rhino classes error. I wasn't exactly sure whether the cause was our test cases or Rhino which we were told we could ignore.

Future Features

In the future we hope to add other libraries including the Hawaii State Library. The Hawaii State Library system wasn't the focus of this phase of the project but we had a cursory class for it. There are a few problems with it, including a slow info retrieval and getting accurate information, that we hope to fix with the next phase of the program. We also plan to add the ability to retrieve more information besides just borrowed books including fees, requests and holds. We also want to allow the user to renew books through the program. It'll be nice if the program had an alert system that a user can schedule to warn him when something is almost due. Also the ability to send a feed to different programs would be cool. Lastly, even though it's unlikely, I'll like the program to attempt to access other libraries that haven't been covered by the program.

Group Project

Our group met at the Hamilton library about 3 times, spending an average of an hour each time working on the project. We had discussions on the design of the program and what part of the project we will be working on. We made sure to commit frequently throughout the week. I think that the way we organized ourselves was effective and allowed us to get the program done in a timely manner.

As for Google Project Hosting I found the Issues tab to be an effective way for members of a project to point out problems that arise during the course of the project. Probably the only annoyance I had with Google Project is the amount of emails I got. In the past week I received 40 emails from the project. I understand getting an email for rather important items like commit changes but wiki changes and some issue reports are things that I really don't need to know about. There should be some sort of priority on whether something is email worthy.