Developing an Event: Commit Often

Introduction
The Devcathlon team gets to play with real Events this week. The implemented Events are the scoring mechanisms in Devcathlon. I was given the CommitOften Event, which was a tricky little nugget to crack.

Commit Often
The Commit Often event tracks the ratio of DevEvents to a commit. Any change made to source code is a DevEvent and is sent as SensorData. Commit Often scores the Event by doing the following.

• Look back at a given time and retrieve DevEvent data.
• Capture and store a file name in an ADT.
• Keep a running count of each occurance of the file name.
• If a Commit was made within 10 DevEvents a score of 0 is returned.
• If a Commit has not occured in more than 10 and less than 20 DevEvents a score of -10 is returned.
• If a Commit has not occured in more than 19 DevEvents a score of -20 is returned.

The idea of Commit Often is to get developers to not spend too much time on writing code and regularly making commits. So everyone involved with the project has an opportunity to work on the code.

Digging for DevEvents
The fun part of Hackystat is digging for data. In order to get extract DevEvents a little trial and error is required. I spent about a day trying to display the data from the DevEvent. However, with the implementation, the trouble I experienced was not with the API rather it was the time at which the unit test was creating DevEvents. I was passing into the makeDevTimeData method the current time thus, the DevEvents had a timestamp that is one hour ahead. Below is the correct the code snippet which creates DevEvents oneHour backwards.

int oneHour = 60;
    XMLGregorianCalendar developTime = Tstamp.incrementMinutes(Tstamp.makeTimestamp(), -oneHour);
    
    this.makeDevTimeData(owner, project, developTime, 100);

The problem with the DevEvents being created one hour ahead is the CommitOften implementation does a check one hour backwards. You can see the problem I was having with not being able to retrieve DevEvent data. The application cannot retrieve information that is not present. So I wasted a day trying to fix what was not broken. I wonder if professional developers encounter this phenomena?

Conclusion
It is nice to get my hands dirty working with a new API, troubleshooting, and resolving code issues. I have to wonder if my implementation is correct even though my unit test passes all of its tests. The team will see when the Events are actually invoked.