DueDates v1.0: The Personal Library Checkout Management Tool
| Posted on Monday, October 20, 2008 |
0
commentsAdd comments |
In Code Complete 2 author Steve McConnell continually advocates a ‘measure twice, cut once’ philosophy to software engineering. He believes in this philosophy so much that he devotes an entire 37-page chapter explaining the concept and its practice. At its crux ‘measure twice, cut once’ stresses planning and preparing your implementation prior to the actual implementation of it. I really tried embracing this practice in this project.
DueDates 1.0 is a console application allowing a user to access both the University of Hawaii Library (UH) and Hawaii State Library (HSL) systems. By accepting the necessary user credentials from the command line (user id and password), DueDates accesses the user’s account retrieving the checked out items and presents them in the console window.
I was once again joined in this project by my previous partner for the CodeRuler project, Robin Raqueno. (Check out his DueDates blog entry.)
Knowing that this is not the final iteration of DueDates, I wanted the implementation decided upon to be thought out with the future of DueDates in mind. In fact, this was a formal requirement of our implementation. In ‘measuring’ our implementation, while it had to satisfy our current objective—retrieving checked out items data from UH, it need to be robust enough to support migration to a GUI web-based application with a strong potential for added features.
Peer Programming Feedback Loop
Peer programming is supposed to make development on a project faster, higher quality, and more fun. But, peer programming suffers from a feedback loop causing projects to become more robust, thus requiring additional development time and more stressful if you care to be responsible to your peer programmer.
Being paired with Robin, who I had worked with previously, really alleviated the stress and time involved in getting to know a new partner and how to work with that partner on a project. It would be nice to think that a pair of programmers could just get together and hack out a program without needing to become acquainted with a peer’s personality, work habits, realm of experience, etc. Robin and I had already gone through this process during the CodeRuler project, so we were able to jump right into our DueDates project.
Another great benefit to being paired with Robin is that we both work extensively with databases, so this allowed us to take a very data-centric approach to our design process. In some ways, I think this added to the robustness and complexity of the implementation of DueDates we decided upon, but we strongly believe this effort of ‘measuring twice’ will pay off in future versions of DueDates. We identified five classes that DueDates would need to support our implementation:
We split our tasks evenly and equally, both working on all classes and committing updates regularly. I think Robin and I work well together, and I appreciate where he complements my programming weaknesses. Often when I would get stuck or had other responsibilities to deal with (i.e., work), I would let Robin know where I was at, then the next time we’d speak he would have resolved any issue allowing the work flow to continue uninterrupted.
Logistic and Implementation Issues
We suffered several logistical issues during the first several days of working together. These were issues related to working with TortoiseSVN, being in the proper Eclipse workspace, having the proper Eclipse setting in place, and being able to update and commit files. Many of the issues were minor, but just time consuming and frustrating to deal with multiple times over those first days. Once we sorted through these issues, which thankfully Robin was able to resolve, we had no logistical issues during the remainder of the development process.
The same cannot be said for implementation issues, which we encountered a few. Many issues were trivial, such as those flagged by CheckStyle. Others were more difficult to resolve, such as needing to make DueDates into a singleton class and several suggestions by PMD that, in my opinion, degraded the code quality.
Probably, the biggest area that could be improved would be testing of our implementation. We were unable to achieve 100% coverage using Emma due to
DueDates v2.0
So with all this up-front planning we did, will there be a DueDates v2.0? If so, what will it look like?
Robin and I really envision DueDates as a web application providing a robust GUI interface that allows a user to enter library and user information from an interface, add new libraries to retrieve data from, and provide downloadable library repositories allowing users to connect to libraries from additional locations. DueDates v2.0 may include options for notification via email, Twitter, and cellular at a frequency determined by the user. The implementation we decided upon really supports a migration to this format.
Now that you’ve heard about DueDates v1.0, check it out at DueDates-Silver. You will find a User’s Guide, a Developer’s Guide, and JavaDocs for it there. Users may download the executable file from the site, while developers will find the source code available. If you extend DueDates, please let us know; we’d like to know how the process went.
DueDates 1.0 is a console application allowing a user to access both the University of Hawaii Library (UH) and Hawaii State Library (HSL) systems. By accepting the necessary user credentials from the command line (user id and password), DueDates accesses the user’s account retrieving the checked out items and presents them in the console window.
I was once again joined in this project by my previous partner for the CodeRuler project, Robin Raqueno. (Check out his DueDates blog entry.)
Knowing that this is not the final iteration of DueDates, I wanted the implementation decided upon to be thought out with the future of DueDates in mind. In fact, this was a formal requirement of our implementation. In ‘measuring’ our implementation, while it had to satisfy our current objective—retrieving checked out items data from UH, it need to be robust enough to support migration to a GUI web-based application with a strong potential for added features.
Peer Programming Feedback Loop
Peer programming is supposed to make development on a project faster, higher quality, and more fun. But, peer programming suffers from a feedback loop causing projects to become more robust, thus requiring additional development time and more stressful if you care to be responsible to your peer programmer.
Being paired with Robin, who I had worked with previously, really alleviated the stress and time involved in getting to know a new partner and how to work with that partner on a project. It would be nice to think that a pair of programmers could just get together and hack out a program without needing to become acquainted with a peer’s personality, work habits, realm of experience, etc. Robin and I had already gone through this process during the CodeRuler project, so we were able to jump right into our DueDates project.
Another great benefit to being paired with Robin is that we both work extensively with databases, so this allowed us to take a very data-centric approach to our design process. In some ways, I think this added to the robustness and complexity of the implementation of DueDates we decided upon, but we strongly believe this effort of ‘measuring twice’ will pay off in future versions of DueDates. We identified five classes that DueDates would need to support our implementation:
DueDates- The main application responsible for process flow and execution of the program.Library- Represents a library with associated attributes to acquire checked out information from its public web site.User- Represents a user with associated attributes to log in to a library’s web site.UserLibraryInfo- Aquires the checked out data for a specific user from the associated library.Book- Represents a book with associated attributes.
We split our tasks evenly and equally, both working on all classes and committing updates regularly. I think Robin and I work well together, and I appreciate where he complements my programming weaknesses. Often when I would get stuck or had other responsibilities to deal with (i.e., work), I would let Robin know where I was at, then the next time we’d speak he would have resolved any issue allowing the work flow to continue uninterrupted.
Logistic and Implementation Issues
We suffered several logistical issues during the first several days of working together. These were issues related to working with TortoiseSVN, being in the proper Eclipse workspace, having the proper Eclipse setting in place, and being able to update and commit files. Many of the issues were minor, but just time consuming and frustrating to deal with multiple times over those first days. Once we sorted through these issues, which thankfully Robin was able to resolve, we had no logistical issues during the remainder of the development process.
The same cannot be said for implementation issues, which we encountered a few. Many issues were trivial, such as those flagged by CheckStyle. Others were more difficult to resolve, such as needing to make DueDates into a singleton class and several suggestions by PMD that, in my opinion, degraded the code quality.
Probably, the biggest area that could be improved would be testing of our implementation. We were unable to achieve 100% coverage using Emma due to
private and void methods, which are not accessible and have no testable returns to test against using JUnit.DueDates v2.0
So with all this up-front planning we did, will there be a DueDates v2.0? If so, what will it look like?
Robin and I really envision DueDates as a web application providing a robust GUI interface that allows a user to enter library and user information from an interface, add new libraries to retrieve data from, and provide downloadable library repositories allowing users to connect to libraries from additional locations. DueDates v2.0 may include options for notification via email, Twitter, and cellular at a frequency determined by the user. The implementation we decided upon really supports a migration to this format.
Now that you’ve heard about DueDates v1.0, check it out at DueDates-Silver. You will find a User’s Guide, a Developer’s Guide, and JavaDocs for it there. Users may download the executable file from the site, while developers will find the source code available. If you extend DueDates, please let us know; we’d like to know how the process went.
