The Good
The newest version of
Due Dates is now available for public and developer use! Several new changes and additions were made to the system to allow it to output queries to a specified email and also allow the program to sleep in the background and then requery and output results.
Implementing -console was quite trivial. I simply added a boolean flag that would be true if the -console command was encountered and allow printing to go as normal.
Implementing -email was a bit more involved. An email method was created that took an email and smtp server and created a message to send. To create the message, the print method that console was using was rewritten to return a String, rather than printing out. Then that string could be sent in the email message. I had some troubles with setting up the smtp server, not realizing just how that worked. My first test run it went fine, but from then on it wouldn't work, having been flagged as a potential spammer because I was trying to send it through mail.hawaii.edu, rather than my local ISP. After that was figured out, the messages all went through fine. I also had some troubles with the string being created and pmd disagreeing on my style. I ended up including several .append(" \n") with the space included so that pmd would not complain about adding a single character.
The -wakeup option was very satisfying to get working. Initially it had some problems that caused it to create several new DueDate objects each time the timer fired and really showed the weakness of the dependency between the DueDates and Console classes. However some tweaking eliminated the multiple object creating, though it does still perform an extra query in the beginning. Overall I was very excited and happy to see it performing a useful task!
The other thing that I found to be very satisfying is I didn't really have to touch any of the Lender classes. They were self contained enough to not care about the changes and additions going on in DueDates and Console, so that's a good sign!
The Bad
While the basic features were implemented, they are not very well tested. With the current design I found it difficult to test individual methods and classes as much as I would like and this will need some vast improvement. On top of that, my sensor data that I thought was working, apparently is not. It shows very little of my activity in the latest build despite hours of development, and dozens of builds and commits. Unfortunately I didn't realize this until too late to see if I could fix it, since the daily build was done at that point. The daily build was also failing, though the Hudson builds were still usually working. It seems there's a problem with what our test cases expect and what the daily build is doing.
The Ugly
The last week saw a complete breakdown in communication between Daniel Tian and myself. We discussed some design issues a couple times, but we have had disagreement over proper design of the project and tenets of object oriented programming. Busy with other work as well, we did not get much development in for the first several days of the project. I was waiting for him to commit some code changes he had been working on, but they didn't come in for several days, right after I started to begin making changes toward "my direction." Daniel then did some work on the test classes and cleaning up the code structure. Work really didn't begin on the new features until November 16. I began and committed some basic code for the -email method and shortly after Daniel made a slight change to it and that was the last commit I saw. I continued from there to implement the remaining features, working my way around the disagreeable interaction between DueDates and Console class, but not wanting to do a whole new transfer of code to fit my design ideas and cause further confusion of how the code worked. In the end, I got it working and did the wiki updates, but am very unhappy about the design and dependencies between DueDates and Console. It does not feel or look at all elegant and easy to maintain and update, at least to me. We just never were able to solidly hammer out a good design for the project so it's been a continual battle to steer the project in the right direction, and a battle we haven't been facing together. There's still time to get things straight though.
No comments:
Post a Comment