Reformulate DueDates 1.2 into a working web application using Wicket.
DueDates and Wicket
The team was able to meet all benchmarks of the system including an extra credit assignment which required DueDates 2.0 access more libraries.
For DueDates 2.0 I was able to contribute: ConfigurationManager.java, TestConfigurationManager.java, HomePage.java, HomePage.html, HomePage.css, AlertsPage.java, AlertsPage.html, AlertsPage.css, DueDatesMail.java, TestDueDatesMail.java, the project's HomePage and UserWiki.
There was disagreement over the DueDatesMail and how it sends an email to the user. The issue with JavaMail is the lack of a dedicated SMTP server. Depending on the internet provider the user may not be able to send an email through its SMTP system. However, the DueDates system can send email via the University of Hawaii mail server. But limiting the application to a single mailer hurts the program's flexibility. We agreed to allow the system to have a versatile mailer taking the chance it may fail for a user. If the email issue becomes a problem we are prepared to switch to a dedicated mailing system. I guess the best resolution is to have your own SMTP server.
Team Akala
Team Akala is made up of Arthur Shum, Jeho Jung, Daniel Tian, and myself. With more developers in a team finding time to have regular face to face meetings is a challenge. However, with Team Akala I am not sure if certain members did not have the time to meet or did not care about the project.
Only Arthur and myself met on six out of the ten working days and in those sessions we talked about where each person was in system, worked on code, and helped each other with coding issues. Jeho met with the group on two occasions and Daniel met with Arthur and I for two hours one day. I found in the previous versions of DueDates, Team Purple's success was due to the regular face to face meetings. However, in version 2.0 there seem to be less of a team effort.
Arthur blazed through the project, at one point I asked him to take the night off so Jeho and I could get some commits into the system. If you look at the charts from the Hackystat system it is clear that a couple group members did more work than others. With regards to communication I would chat with Arthur about the code through g-chat and face to face meetings. There was one day where Arthur, Daniel Tian, and I performed triple programming to get ConfigurationManager.java to work.
Kudos to Arthur for doing a lot of the heavy lifting however, I thought more of the code should have been dispersed evenly. But really hats off to Arthur he got the team into a position so that we did not have to program our tails off at the last minute.
Note: Because Arthur reorganized the package structure of DueDates 2.0, he will have a high number of commits on 12/7/2008.
Akala Development Time
The chart below represents the time spent coding in Eclipse, I am the pink line.
Note: The development time is accurate as of 12/7/2008. DueDates 2.0 was cleared for released on 12/7/2008.
Akala Commits
The chart below represents the number of commits for each team member, I am the green line.
Note: Arthur got a head start on the project and committed his version of DueDates 1.2, plus the support files for Jaxb. Explaining why Arthur had such a high amount of commits early in the development.
Akala Builds
The chart below represents the number of builds each developer invoked I am the green line.
Note: There is an error with Jeho's Hackystat sensor, he did have builds in the development.
Issues
I thought working with this system was much more difficult because of working with Wicket. My experience with Wicket is limited so it was a challenge to get meaningful code committed. I attempted to work on a progress indicator for an extra credit requirement however, it was difficult to find information and what the search engines returned was confusing. The Wicket API documentation is in my opinion lacking in detail. Trying to find out what a class or method does took some time to understand. A combination of using the Wicket in Action book, documentation and examples from the Wicket website made the coding process somewhat bearable.
Development Tools
Having worked with Hackystat and Hudson with DueDates 1.2 I do not think there was anything new to learn or discover. With this group there was less obsessing about coverage and there seem to be a focus on getting the system working first. I thought having colors represent the task portion of the project was a good idea. Group members can see the development, build, and test time was spent for this project, plus the group would know if at least two members were involved with coding. Having used Hudson with three projects, knowing the continuous integration tool is overseeing the build provides some confidence, where there is a watchful eye on the system.
Akala's Health and Status
Note: Green numbers and lines mean healthy, yellow means needs attention, red means sickness. The increase in coupling was due to the addition of several files at the last minute.
Conclusion
For DueDates 2.0, I thought I made a significant contribution to the system I got my hands dirty with a little CSS and Wicket. I should have been more assertive in getting Arthur to slowdown with the coding or do more pair programming. That way the development and build counts would be more even. I would like more of my code to make final version of the build. So for ICS 414 I intend to have my code be in the final build of whatever project we get assigned.
