When is the DueDate???

Intro

This is an open source group project which will develop a program named DueDates. Its purpose is to log onto a library website without the use of a web browser. You will then need to provide a login and password for the library website. Once logged into the site, the program will display a list of books that you have checked out and their due dates.

Download DueDates.jar

Process

The process of creating this program was not too tricky. With our professor giving us a description of what I possibly should do, we knew what we wanted it to achieve. We wanted the basics of the program to be able to connect to a library website, log on to your account, and display a list of books you barrowed from the site. With that in mind, we also thought of making the program able to other libraries around the world, so that anyone in the world can use it.
We split the program up into different class files, that way we can be more organized, and just combining them into one package. Another reason for making different classes was if someone else where to make improvements to the program, they would know which file to enhance. The different classes that make up our program are: User, Library, UserLibraryInfo, and DueDates, which is the front end of the program. There are other minor classes which these four classes are derived from and they are: IUser, ILibrary, and IUserLibraryInfo. with everything separated and organized, future enhancements will not be a hard possibility.


Problems that Occurred and Solutions

We ran into some problems during the initial building of the program, the first of our problems was with importing external tools into our project. The problem with importing external tools was solved by communicating with other people in our class. A previous lab partner of mine, John, suggested to me that our project was not bringing in the Httpunit tool and instructed on how to import it into the project. Once that problem was fixed we proceed to develop our copy of DueDates. Just when we thought we were home free, suddenly our testing of the program was not working. After hours of gruesome tracing and looking at lines of code. I abruptly tried to import our files into a previous DueDates project our professor gave us, and it worked. The test completed and we were able to continue with the development.

Just when we thought it was smooth sailing from there on, our EMMA tool was not completing its coverage of our program. We decided that this problem can wait and proceed to fixing other minor problems. Later it was time to try to fix the EMMA problem; after a few hours of thinking of what it could be, Ron notified me that we need to make a test class in order for EMMA to complete its coverage and display its results. Creating that test class and running at least one test fixed the EMMA problem. Our other problems occurred during the running of the quality assurance tools, such as Check Style and PMD, but those errors were quickly resolved. The problems we faced, at the time seemed so big, but the answer to them was so small.

Working on this project we took a bigger step in to the world of Google Project Hosting. Learning how to use the different syntax of the wiki page was very troublesome. The user guide did not help so much and possible correction to the syntax I made, I had to commit the file to the project page to see the results; which cause a large number of commits. Another problem I had with the project page was when I accidentally made a commit and did not put anything on the log. There should be an option to go to the page and edit the log entry, depending if you were the one that made the commit.

The Future

A possible improvement for future development would be to create a user-interface. During our outsource testing; some of the users did not know how to get to a command prompt screen, which prevented them from using actually using the program. Also with a developed user-interface, we plan to also hold more than just the two libraries that are stored in the program, keeping mind that this program would be used for people from around the world. With the way we designed our program, I think future developments won’t be too complicated.


Thoughts

Creating an open source program is a tough and time consuming process, even though our professor provided us with the direction and foundation of the project. Despite the rough road to completion, I learned a lot from this experience. First of all, this being a group project, having a very dedicated and intelligent partner was really helpful. We met almost every day since the project was first assigned all the way to its completion. It was a good experience programming with someone on this open source project. When one of use was stuck in a problem, the other would find a way to solve the problem. Solving big or small problems with someone watching my back, has increased my liking for peer programming.


Also another thing that I valuably learned was how to handle problems, not taking so much time to look for a way to fix it. Take other routes to completion, moving around that problem and get back to it later, presuming that the problem won’t affect the rest of the development. Also not to burn yourself out on looking for a solution, take it as a sign to step away from the computer and relax your mind. Remember a big problem can always be solved by doing something so small.