Devcathlon Event Implementation

Premise:
This past week I teamed up with one of my colleagues to implement an event for our semester project, called Devcathlon. We were in charge of developing the CollectiveOwnership event which entails the following:
Reward developers for ensuring that most files are worked on by multiple developers for a certain number of time.

Process:
My colleague and I had very ample time to work on this event. Given the prior experience with working on our mock events, we were semi-comfortable with the Hackystat APIs. Fortunately enough we had a very distinct plan from day one and that was to finish early. A lot of the code was taken from the same context as our starter events. Eventually those same concepts, such as calling to the remote hosting server, retrieving data from the host, specifying sensor data types, and sending data to our test server became second nature to us. I also corrected myself during many instances while building this event. One of my main difficulties was understanding what was was being accepted by Hackystat as valid input and what was being spit back. I was a bit trapped by this and had to resort to some old debugging techniques that may seem out of style in today's standards, but worked out just fine for certain situations. In many of our preliminary test cases, we did various "System.out.println..." to see if the accepted values were generated correctly by our black box (Hackystat). Yes, I basically thought of Hackystat as a big "black box." Although the code is open source and can easily be read from Google's browsing tool, I was compelled to see how much can be inferred from the details of the Javadocs without digging through code manually. However, in one instance my colleague found a code section for determining a user's developing time by a simple class called DevTimeCounter. The name is quite obvious and it simply did what it needed to do flawlessly. This incredible, yet hard to find class simplified the code even further from what we had started out with. We also ran into a little difficulty in building test cases, so my colleague expanded the DevcathlonHelper class method for making dev time, by adding the ability to specify a file name the user or owner has been working on. This helper was a necessary change to the test helper methods and it greatly came in handy for what we needed to test out in our event.

Conclusion:
The experience was very rewarding, since I became more familiar with the Hackystat API and much more comfortable building Devcathlon events. Although we hit some road blocks along the way, they were minor and worth noting for future reference. Considering the rate at which we are going, we should be on our way with getting some kind of GUI for our application soon.