DueDates Project (Part 1)

Premise:
I have been tasked this past week to assist in the creation of a project called DueDates. DueDates is currently a program that enables a user the ability to check the status of items they may have borrowed from one or more library systems. It is meant to generalize the interface between the user and their list of items, whether they be books, bills, tasks and etc. For this project, I will be accompanied by the following tools and source code: Google's Project Hosting, SVN, Eclipse, HTTPUnit, and sample code, DueDatesBootstrap.zip

Process:
The hardest part in any project is the process. I found it difficult at first to plan out a reasonable and consistent plan. Many times a plan might backfire or doesn't go as you'd expect, but after a few moments of reading up on the project's needs and wants, I finally came to conclude some possible project enhancements:
User Interface:
End-users are left with a couple of command line options that makes too many assumptions as to what is required by them. Another problem was that the resulting error dumps (Java Exceptions) were being outputted in a very cryptic manner. To solve this, we could suppress the messages and also provide an extra parameter to display other misc stack dumps for developers.
Functionality:
The sample code, DueDatesBootstrap only provides sufficient code to initialize, connect and grab responses over the network to a fixed number of supported library systems. We could provide general library system templates, and pass required parameters to them. This might not solve all internal problems, such as HTTP parsing, but it will provide a step in the right direction.

Execution:
Setup:
Even some practices needed to be re-iterated. I found myself needing to take the time just to refresh on the syntax of SVN. I keep getting this notion that I need to do a "svn import", but that's only when I'm locally hosting my SVN repositories. Google's Project Hosting site skips one step in the common "svn import" and "svn checkout" process that I'm used to. Another minor problem was knowing which folder(s) needed to be included on revision. In most common development environments, only the source, custom libraries and configuration files are worthy of inclusion to the repository.
Plan:
The first thing I noticed about the initial DueDateBoostrap program was its lack of "friendly" error handling. It occurred to me that possibly building an ErrorLogger for this system would be most beneficial not only for this project but also for others. My goal from here on was simple, build an error logger that simply takes in at least one (supported) option and deal with auditing the errors. Although my approach is simple, it does the job with a few left out features. This error logging system lacks the ability to audit with level of warning types. In future enhancements I would like to incorporate a more sophisticated level system that weighs the severity of an error/exception.

Conclusion:
I enjoyed taking the time to get my hands on a new project again. Here I can step back and think about new ideas that I have yet to explore and hopefully, along the way make changes to better the application as a whole. Its always important to know that there are some ideas that work for certain situations and some ideas that work for others. I have learned from the past that large projects like these amounts to the overall effort and not only the ability of one individual. I believe that in this high collaborative society, esp. for software engineers, that we are only as strong as our weakest link. Learning to accept the fact that you are not the lone programmer these days will better you for the actual development setting. The setting is ever changing, people come and go, while many of us still have to learn to adapt rapidly. This project proved to be quite a learning experience for both me and my team member.