The coding continues for Team Purple as we add more functionality to DueDates. In addition to the new tasks we get more experience working with software ICU and having HackyStat keep tabs on our development of DueDates 1.2.
DueDates 1.2 and JavaMail
Team Purple needed to fix some issues with version 1.1. DueDates needed to be more abstract and there was a problem with the naming of the project. DueDates 1.2 requires the application to send an email notice and check when a book is due to be returned. I took on the task of implementing JavaMail into our system. Using SMTP, messages will be sent to the user when an item is due with twenty four hours. The difficulty with JavaMail is finding a mail server that does not require a password with every transaction. Unfortunately, Gmail requires authentication with each email sent regardless if it is sent within system. The University of Hawaii mail system allows messages to be sent within the network however, the user is required to have an account with hawaii.edu.
Working with JavaMail was a challenge I had to learn how email is structured and delivered. I spent several days going over SMTP, RFC-2821, SMTP using Gmail, JavaMail API, and example code. DueDates 1.2 is not capable of taking in a password for email so the user must use a SMTP server that does not require authentication for every message sent.
With each build DueDates gains more functionality but as the system grows the coding process is a little more complicated. However, with version 1.2 the process was straightforward compared to DueDates 1.1. I am not sure if it was due to the improvement in abstraction, I definitely had an easier time working with the code in this assignment.
Team Purple
When it comes to group programming the best method to accomplish the assigned task is to meet everyday to discuss and work on the code. John, Marilee, and I met for at least one hour for three days. With each meeting the group would talk about how their assigned task and decide on which direction the team should move. Team Purple has met on regular basis with each version of DueDates and we have reached every bench mark which I believe is related to consistently meeting and working on the project.
CI and ICU
In version 1.1, the team already got a taste of Continuous Integration or CI, which is a handy tool or nusisance. Depending on how you feel about having something constantly looking over your shoulder. Another tool in our arsenal for code design is Professor Johnson's Hackystat system which is used for software ICU. In my previous blog I mentioned the postives and negatives of software ICU, where the tendency would be to focus on getting coverage numbers into the green.
With DueDates 1.2 my theory was confirmed by my team's obsession with the coverage and I am just as guilty of being fixated on getting our numbers into the green. I appreciate how Hackystat monitors the progress of a design. However, I think a project's robustness and functionality should be the focus rather than getting numbers into the green.
Conclusion
I feel I am improving as a programmer with each version. With DueDates 1.2 much of my code and tests are making it into the release. But I know I have a long way to go in becoming a developer that can code a DueDates system on my own. To improve as a designer I need take on more coding responsibility and take on the tougher aspects of the design.
