The DueDates Project

Imagine this scenario: you borrow a bunch of books and CDs from various libraries, rent some movies from a video store, and then you lose track of when things are due. You go online to check your account, but you have to log in to several different websites, and you have to dig out your membership cards and remember your passwords, and the whole process is just a big hassle. How often has this happened to you? Well if you're like me, then the answer is never--I rarely use libraries (despite working in one), and who goes to the video store anymore? But apparently, it must happen all the time to some very influential people, because I and the rest of my ICS 413 class are working on a project to tackle precisely this problem. The eventual goal is to create a software system that:

• provides multiple user interfaces (e.g., command line, web)
• connects to a variety of sources (e.g., libraries, video rental stores)
• retrieves item, due date and related information
• alerts users when things are going to be due
• sends messages in various formats (e.g., email, text messages)
• is extensible so others can develop additional interfaces, sources, alert criteria, message formats, and more

Our more immediate goal this week is to create a program that connects to the University of Hawaii Library System, retrieves checked-out item and due date information, and prints this information to the command line. You may find the implementation of the DueDates project that Erin Kim and I worked on at our project homepage.

What We Did

Professor Johnson provided DueDateBootstrap to us as a starting point for the project. DueDateBootstrap demonstrates screen scraping using HttpUnit, and it is already able to log in to the University of Hawaii Library System and the Hawaii State Public Library System. We modified the system so that it parses the relevant parts of the library websites, retrieves information regarding checked-out items, and prints the formatted results to the command line. We also implemented a text-menu-driven interface to improve user-friendliness.

On our project homepage, we have a project description and a User Guide wiki to help people learn about and use our program. We also provide JavaDoc comments and a Developer Guide wiki to help developers extend our system. In particular, we provide a Library interface so that developers can more easily add new library sites to the system.

What We Didn't Do

Overall, we finished most of what we intended to accomplish for this stage of the project. There were several things that we didn't get to or couldn't quite figure out, however. For example, we would have liked to validate command line arguments to check that they are in the correct format (e.g., UH ID's are a sequence of 8 digits). Also, by default, errors result in a stack dump error message. We would have liked to have changed the error messages to be easier to understand, but also provide an option for advanced users to see the entire stack dump.

Problems with Testing

One particularly challenging problem was running automated unit tests from the command line. First, I had to figure out how to pass command line arguments to the JUnit Ant-target, and how to access these arguments from test classes. I figured this out pretty easily by consulting the Ant manual (which is pretty awful, by the way). I then encountered errors when running the JUnit target because JUnit could not find some of the supporting .jar files for HttpUnit. At first, I tried adding classpath variables to build.xml, but this resulted in some confusing behavior--the JUnit target would work only if the classes were compiled /before/ the classpath variables were added. Eventually, I solved this issue by adding the classpath variables to junit.build.xml, not build.xml. After all this, I realized I didn't know how to test the classes.

Suppose I have a test class that takes a UH ID and last name from the command line, constructs a UhLibrary object with these credentials, and calls the login() method. Whether I use real credentials or fake credentials, the test should pass, because the test is testing the correctness of the code, not the validity of the credentials. The test works by checking the response from the website against some expected response. But the response from the website is different depending on the credentials. So, because the test doesn't know what credentials the user is going to input, it doesn't know what response to expect, so it can't compare the website's response to anything. One way around this would be to pass the expected response as a command line argument, but I didn't implement this because it seemed like there should be a better way.

Working as a Group

I worked with Erin Kim on this project. We collaborated on everything from the coding to the documentation. We would discuss issues, ask each other questions, and consult each other before making decisions. We got together four times over the course of the week, but we communicated with each other via IM every day. We also used screen sharing and voice chat software to approximate working together in person as much as possible. While this was very helpful for when we couldn't get together, meeting up in person was still more efficient.

Lessons Learned

I wish we had planned better and outlined our tasks more clearly during our initial meetings. At first, the project seemed small and straightforward, and we figured that we would play it by ear. However, it seemed that the more we worked on the project, the more we discovered that there was to do.

I found that writing user and developer documentation (as part of satisfying the second and third prime directives) for this program wasn't easy. I had been working on this project throughout the whole week, and by the time I went to write the documentation, I had become so familiar with the program that it was hard to write for an outside audience unfamiliar with this project. I think it would be useful to write documentation earlier next time, although writing it too early would also be difficult, as you might not have a solidified idea of how the program should behave yet.

Grievances

And now, I would like to take this opportunity to list things that annoyed me this past week.

• Google Code Project Hosting wiki: you can't change the name of the wiki.
• Google Code Project Hosting wiki: every time you save changes, it also writes to the commit log.
• Google Code Project Hosting issue tracker: you can't delete or edit an issue (you can only add comments to it). What if you make a mistake?!
• Wiki markup: Can't add a line feed.
• Wiki markup: Can't indent tables.