Sunday, December 7, 2008

Red Bull a programmers drink



DueDates 2.0 is the continuation to our open source program; from a small command prompt program to a now fully integrated, user friendly, web graphical interface.

In this version of the DueDates program, our original groups were broken up and placed into new groups, but instead of a two person group we were either placed into a group of 3-4 people. With a much larger group the tasks would be evenly distributed to each member, supplying each member with less of a work load. The group I was included in is Team Ahinahina, which consisted of John Ly, Philip Lau, and Scheller Sanchez. Each of us took up task to meet the requirements for this new version of DueDates.


Processing the Task

We, team ahinahina, met a couple of times during the first week to discuss which group members would do what for the program. At first we took the program lightly, thinking that since the group is much large that tasks would be done sooner and the progress to completion would be reached before schedule. During the first week, we tried to get as much done before the Thanksgiving break. After the break we, on the second week, realized we haven’t got much done and the dead line was drawing closer. So I tried to organize as much time for all of us to meet at Sin Claire Library, even if it meant late at night.

During the second week, everyday that went by a requirement was getting done. Also with all of us there we paired program or, asked and offered a fellow group member for help on a task. This method of pair programming helped a lot, with all of us operating like each wheels on a car; when one wheel was stuck, the whole car was stuck.


So close, but yet so far

We reach completion of the program, or so we thought. After reviewing the requirements we received from our professor, which to me acted as our client, we saw that we missed two of the requirements. One was the requirement for a user to be able to sort the list of books by title, which is very similar to sorting the list by the library location. The second requirement was alerting the user of a due book depending on the amount of days inputted.

During testing another dilemma occurred. This third problem was the “within” option, which gives the ability for a user to filter out books depending on the amount of days it was due. The function was implemented to the program, but being new to Java Wicket, we would need more time to fully integrate it dynamically to the program.


Problems on the test

On the process of building the program, we didn’t think about testing so much. With the deadline hangover our heads, the idea of having testing coverage wasn’t our biggest concern and mostly focusing on getting the program up and running was. When we did get to it, we had some problems; for instance when I uploaded a proper test class to the project page, the Hudson serve would show that it failed. Though, the test class would pass on each member’s computers. This problem occurred due to the fact we were not sure of the test accounts that we used, if they were also on the Hudson server.


Conversion to 2.O Wicket Style

The conversion of switching to wicket was fairly moderate on my part. The 1.2 version of DueDates was supplied by John, a previous member of team yellow. The program was pretty straight forward; I just had to do some work around of the original program to compensate for the integration of Wicket into the program. Using wicket was a really cool experience, on how it bridges java over to web programming. I would love to further learn more of its capabilities, such as the Ajax mixing of it and how it would handle flash web programming.


An Eye Opener

This experience was a real eye opener for me on the last week of the project. After looking at code for almost 20 plus hours on a Saturday, being juiced up on red bull, and having a total amount of 47.9 hours, according to the HackyStat sensor; like what John said in his blog, “I’m over due for some sleep”. Being reassigned to a new group this late in the semester was fairly hard on my part, having to get use to a new people's work habits and time management. Also in how fast i can understand a new program structure; good thing John was available to answer my questions, him being one of the original programmers to the version of DueDates we used. I hope the others gained more knowledge from this than I did though, I know our professor has his reasons for doing this random grouping assignment. One reason that caught my eye was, preparing us for the real software industry. Comparing my experience from working for Star Degree, I would have to at times randomly work with new people or have to work on programming code that was written by someone else. So these two experiences are alike in many ways. Generally this has been a good, full of red bull, experience.


Screen Shots

The display page




The alerts page....the page i spent most of my time on


Red Bull gives you wings....my stats are flyin'

Links

DueDates-Ahinahina Project Page
User Guide
Developer Guide

Downloads
DueDates.jar

DueDates distribution
DueDates 2.0 API Java docs