PROJECT: Due Dates
PROJECT PAGE: http://code.google.com/p/duedates-gold/
TEAM: Tyler Wolff and Scheller Sanchez (team gold)
OVERALL CONCEPT: Due Dates is a program that will go and retrieve information about various items that you (the user) have borrowed, including their due dates. The application can be used for library books, videos, or anything else with a due date, and it can be extended to any source that has an online login. As the tag line states – “Never pay a late fee again!”
project homepage view
THE SYSTEM
For the first version of Due Dates, my partner, Scheller and I decided to implement a system for use with only one library – the University of Hawaii at Manoa Library. This would enable any UH student to use our application to view what books they have borrowed and which ones are due, thus making it a useful system (Prime directive #1). We decided to do this with the addition of some extendible features to expand the functionality in the future. For this stage of our program, it would include these classes.
- LibraryVault – an object to hold information about a given online library system. Object holds the site URL, the login form’s name, and the two parameter names within form.
- DueDatesGold – this is the main class that uses LibraryVault objects in conjunction with user defined id/passwords (or any type of login information) to gather information about borrowed books and their due dates.
This initial structure, however simple, would give great functionality into accessing UH Manoa’s library system, as well as allow for some future program expansion. The way we see it, since there is a LibraryVault object, many libraries can be set up initially from outside sources, like a file or even a database. Because of this, methods like the login method can then be used for multiple library systems, thus abstracting the code a little more.
However, because our first version of Due Dates only deals with the UH Manoa Library system, the overall code is not simplified that much. In addition the program works through the use of command-line arguments (the UH student’s ID and last name). This means, it runs from a terminal with no interface capabilities. The output is just as informative though, and it can be run very simple through the use of a jar file. Anyone can download and use it (Prime Directive #2):
Sample Program Output
GROUP PROCESS
Sheller and I decided early on that we would communicate everyday about the project, whether it be in person or through the use of an instant messaging program. What ended up happening was that during the last week, we met up almost every other day in person for a couple hours, to talk about the program and work things out. This was definitely to our advantage and it worked well for both of us.
At our initial meetings we planned out the system while issuing specific tasks to each other on the project page. We even met once in Hamilton Library so we could borrow some books (for program testing!). In some of our later meetings we programmed together or edited existing files. What I found interesting was how much can get done while working together. We set up the project page instantly and put up issues just as fast. Its much easier to program as well because you can physically show the other person your code without having to send them the file. A big initial problem we had was getting Eclipse to recognize the HttpUnit classes. We worked together trying to fix it and finally found a temporary solution to the problem. This was later resolved in class.
Something that we did not do a lot at our meetings was commit files to the project repository. I don’t know if this was because we never got to a final stage with our code or because we just never thought about it, but it probably would have been more efficient to commit/update code right then and there. Overall though, it was really nice working with Scheller on this project. We both did what we planned to do and everything ran smoothly.
SETTING UP THE PROJECT
Hosting the Due Dates project on Google Code was really great. It allowed for really easy collaboration between Scheller and I. Creating a public project page for Due Dates was something I really enjoyed. It is sort of like marketing it as a product and making it accessible to everyone (Prime Directives #2,#3). I gained some experience making a wiki page for Developers to build and modify the project. Since the project does have external dependencies like HttpUnit, I had to create informative instructions for installing and using those tools. I used lots of screen captures and descriptions to explain it all.
The issues log was a great function of google projects that I did not previously know about. After adding issues to the list, Scheller and I were able to go through each of our specific tasks, noting when they were completed. It is like a complex to-do list that really makes it easier to reach project goals as a group.
TESTING THE SYSTEM
Testing for the Due Dates system was a little different than past tests I have done. I personally was responsible for testing the login method and the method that gathered data from the UH Manoa library. I tested for correct login information, as well as incorrect login information. For the due date information, I made test cases with users who had no books borrowed and with users who did have borrowed books. I made sure content was correct and exceptions were caught.
It was interesting building a test suite from the ground up as I have never done that before. I’ve only ever added to other test classes. The things we were not able to test for were external dependencies like internet connection, internet errors, etc. This could be done in the future though.
FUTURE IMPLICATIONS
One of the coolest things about the Due Dates program is its extendable capabilities. Scheller and I talked about this a lot since there is so much that could be done to enhance the system. For one the system could employ a better command-line system as well as support multiple libraries. It would be really cool too if a user was able to add their own libraries without extra coding on the programmers side. In addition, some sort of graphical interface would be great. It would make the program look even better.
CONCLUSION
Overall, the building of this project as a group was a eye opening experience. I have never really done this sort of thing programming before and it really showed me the possibilities of open source software development. If many people were all working on this project at the same time, who knows how great the program could become. And it is all done so easily with Google Project Hosting and subversion technology. Hopefully in the future this project can really expand and develop.