DueDates-Silver v1.2: The Evolution of a Simple Application
| Posted on Monday, November 17, 2008 |
0
commentsAdd comments |
This week my team was tasked with adding two new features to our DueDates project. First, the project was to now support the capability of sending its results to an email account the user specified. The second enhancement was to allow scheduling of requesting and outputting the results. Actually, the first criteria specified that support was to be for either output to the console or the email—throwing an error if neither was explicitly supplied. However, we decided against requiring explicit invocation to output to the console. We reasoned that if the user is calling the application from the command line that the default output should be to the console and that explicit specification of email output by the user was sufficient to override the default (console) specification.
Gremlins, Baci, and Instant Karma
Personally, I seem to be suffering through a patch of difficult times with regards to my computer. In the past month, I have had to re-install my operating system, which required reconfiguring it once more to support the setup required for my ICS 413 course work. Then, just last week my laptop’s adapter cord frayed! That left me with no way to keep its battery charged until I forked over $100 to get a new adapter. That cost me one day of development during the enhancement to v1.2. Atop this, my commits were not being sent to the SICU correctly, which by all accounts I can only attribute to gremlins. Luckily, here my professor was able to resolve getting the commits into the SICU, but the problem of why this is occurring continues to plague me.
Finally, my latest bout of rotten luck came in the form of another wasted (or lost) day of development. While working on setting up the email feature, I kept encountering numerous security issues and NoClassDefFound exceptions for either the JavaMail Message and MessagingException classes. After working on trying to resolve this for about half a day, I committed my files and my project partner updated his build. To our astonishment, the files not only built, but ran correctly!!! There was an actual email sent to his account. We decided to break for the day, as he had been working on the scheduling issue and had been having hours of his own issues with that. Considering my recent bout of poor-quality karma, it was likely it was affecting him, as well. The next morning, I called him up, and we resolved the issue over the phone. So, a day lost, but issue fixed. Later that night, several classmates were having similar issues, which I was able to share how Robin and I had resolved it for me. This solution seemed to work for at least three other classmates. The solution was that the JavaMail mail.jar file need to be copied to both the Java JDK lib/ext and the Java JRE lib/ext directories.
One Minor Version Older And Deeper In Debt
This iteration had me feeling like Hank Thompson’s poor man in 16 Tons. It seemed the more we did, the more that needed to get done. There were just so many details and minor issues that seemed to plague me that it really impacted our success this time. While we did finish and were able to get everything implemented, the process seemed belabored and fraught with frustration at things that we felt more-or-less to be non-issues. (Non-issue: something that should be trivial, but consumes more time and resources than would seem required to accomplish.) But, all-in-all our project remained stable. While some stats climbed and dipped here and there, we were able to manage them and keep them near or at healthy levels.
Also, we took the opportunity to do many things, including cleaning up code (causing a major code churn event one day that was mostly due to sorting methods and arranging class behaviors more appropriately), and implementing three new classes (Email, Messenger, DueDatesTimerTask) with associated interfaces.
What’s on the Horizon?
It appears DueDates v2.0 will be in development soon and a projected migration to a web based application. From the first day we met, Robin and I intended this to be the targeted platform for our DueDates project. All the “measure twice, cut once” practices we have been using coupled with using TortoiseSVN, Hudson, the HackyStat SICU, JUnit testing, and the many other tools have put our project into a state that should facilitate this migration with moderate ease and resource management.
Gremlins, Baci, and Instant Karma
Personally, I seem to be suffering through a patch of difficult times with regards to my computer. In the past month, I have had to re-install my operating system, which required reconfiguring it once more to support the setup required for my ICS 413 course work. Then, just last week my laptop’s adapter cord frayed! That left me with no way to keep its battery charged until I forked over $100 to get a new adapter. That cost me one day of development during the enhancement to v1.2. Atop this, my commits were not being sent to the SICU correctly, which by all accounts I can only attribute to gremlins. Luckily, here my professor was able to resolve getting the commits into the SICU, but the problem of why this is occurring continues to plague me.
Finally, my latest bout of rotten luck came in the form of another wasted (or lost) day of development. While working on setting up the email feature, I kept encountering numerous security issues and NoClassDefFound exceptions for either the JavaMail Message and MessagingException classes. After working on trying to resolve this for about half a day, I committed my files and my project partner updated his build. To our astonishment, the files not only built, but ran correctly!!! There was an actual email sent to his account. We decided to break for the day, as he had been working on the scheduling issue and had been having hours of his own issues with that. Considering my recent bout of poor-quality karma, it was likely it was affecting him, as well. The next morning, I called him up, and we resolved the issue over the phone. So, a day lost, but issue fixed. Later that night, several classmates were having similar issues, which I was able to share how Robin and I had resolved it for me. This solution seemed to work for at least three other classmates. The solution was that the JavaMail mail.jar file need to be copied to both the Java JDK lib/ext and the Java JRE lib/ext directories.
One Minor Version Older And Deeper In Debt
This iteration had me feeling like Hank Thompson’s poor man in 16 Tons. It seemed the more we did, the more that needed to get done. There were just so many details and minor issues that seemed to plague me that it really impacted our success this time. While we did finish and were able to get everything implemented, the process seemed belabored and fraught with frustration at things that we felt more-or-less to be non-issues. (Non-issue: something that should be trivial, but consumes more time and resources than would seem required to accomplish.) But, all-in-all our project remained stable. While some stats climbed and dipped here and there, we were able to manage them and keep them near or at healthy levels.
Also, we took the opportunity to do many things, including cleaning up code (causing a major code churn event one day that was mostly due to sorting methods and arranging class behaviors more appropriately), and implementing three new classes (Email, Messenger, DueDatesTimerTask) with associated interfaces.
What’s on the Horizon?
It appears DueDates v2.0 will be in development soon and a projected migration to a web based application. From the first day we met, Robin and I intended this to be the targeted platform for our DueDates project. All the “measure twice, cut once” practices we have been using coupled with using TortoiseSVN, Hudson, the HackyStat SICU, JUnit testing, and the many other tools have put our project into a state that should facilitate this migration with moderate ease and resource management.
