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.

ICS 499: Healthcare Software and Devcathlon development

Introduction
Last week the 414 team was given real Devcathlon Events to implement. I am starting send out my resume to employers and noticed that hospitals have a need for software developers. I have no idea what health care applications look like and since I am applying to a hospital I figure I should find out what is being developed.

Health Care Applications
I know the health care system requires the storage and retrieval of patient information. So a background in databases is important and I feel confident I can apply what I learned in ICS 321(databases).
The program on the right appears to be a diagnosis application developed using the .NET framework. After doing a Google search on health care software I found a lot of companies like using .NET for application building. I suppose I should be learning the .NET framework in the near future. Without having seen source code for a health care computer application I am not sure what to expect but I am sure the programs use the same structure and syntax as any other piece of software.

Event Development
I was assigned the Commit Often Event this week. Developing the application was a little easier compared to coding the Starter Event. I could have finished the assignment a lot sooner had I applied the unit test properly. I had set the time for the makeDevTimeData method to run forward. The DevTimeData needs to be created with time set backwards. Because Commit Often has a requirement to look back one hour and look for DevTime/Commit data. I got to implement a HashSet and HashTable where the HashSet collects file names and the HashTable track the number of occurrences of a DevEvent/filename. John Ancheta implemented an overridden makeDevTimeData method allowing it to take in a file name as an argument. I was able to assure CommitOften.java was able to read more than one file.

Development Rundown

• Monday-Saturday, 3/2 - 3/7
  • Implemented CommitOften and TestCommitOften. I think I lost over 50 points for not making commits within the given number of DevEvents. However, I made up some ground by performing unit tests and verifying before making every commit. I estimate my score to be 15 points.
    
    
• Sunday 3/8: Blog work.

Engineering the Event pt II

Introduction
The class got a reprieve and got an extension on Event development. After a disastrous start, the team struggled with the Hackystat framework, which led to more review and an extra nudge to get everyone to work extra hard.

Working with the Framework
Professor Johnson mentioned in class the difficulty with working with a new framework and how he spends numerous hours reviewing documentation and tinkering with code. I was quite relieved to hear a seasoned computing expert to talk about their learning curve when learning something new. The team was given a week to go through the DailyProjectDataClient documentation and write code using the API. The challenging aspect of the assignment was not the task but trying to figure out how everything fits together. At this point in our college careers we should be able to work with a new framework in a fair amount of time. In my case I was not aggressive with writing the code and assumed that I could bang out the event in a day or two. However, it took me 4 days of actual coding to complete the assignment.
Over the course of the 4 days I hacked away trying to figure out.

• How to extract members and dev time using DevTimeDailyProjectData.
• How the bonus points get calculated.
• How a HashMap works, I used only once in an assignment for 311.
• Why didn't start on this assignment sooner.

I did complain to Professor Johnson about the Hackystat documentation being difficult to research. Because the Sensorbase, Utilities, and DailyProjectClient Javadocs are not in one document or linked together. It can be a bit of a pain if you are in the section Tstamp and you need information on DailyProjectClient API.

Digging for Data
For the event No MIAs I had to dig for data: development time and user information. I spent about a day and half using print statements to find the right code combination to extract what was needed to get the application moving.

for (int i = 0, j = timePeriod; i < timePeriod ; i++, j--) {
      try {
        DevTimeDailyProjectData devTimeDpd = 
          dpdClient.getDevTime(owner, projectName, Tstamp.incrementDays(currentTime, -j));
        
        for (MemberData dataRef : devTimeDpd.getMemberData()) {
          String user = dataRef.getMemberUri().substring(38);
          this.devTimeMap.put(user, dataRef.getDevTime().intValue());
          devTimeSum = this.devTimeMap.get(user);
          devTimeSum += devTimeSum;
        }
      }

Some notes about the code.

• Need to iterate over a given number of days. The parameters for the assignment is 3 days.
• A DevTimeDailyProjectData instance is needed to extract member data. The DevTimeDailyProjectData object is initialized by getDevTime from DailyProjectDataClient class.
• Loop through the member data, retrieve the user name, and dev time.
• Store the information into a HashMap for easy access.
• Sum up the scores.

Probably the most important snippet from NoMias.java because it retrieves the data necessary to assess if developers are spending time coding.

Conclusion
Wish I took a more aggressive approach to developing the event. I probably could have finished the assignment on time. I felt working with a new framework was challenging but not impossible. I am hopeful that I can learn other frameworks in the near future and perhaps make software engineering a career.

ICS 499: Hackystat framework and Scoreboard design

Introduction
This week was a bit of a whirlwind for me as I was learning and working with a new framework to develop events in Devcathlon. Because of time constraint I had little time to work on the Scoreboard for Devcathlon.

Hackystat Framework
The class got a reprieve with the assignment event developing seems the learning curve with the framework was steeper than originally thought. I was able to climb that hill and complete the No MIAs event.

The SensorBaseClient and DailyProjectDataClient classes are vital to access data processed by Hackystat. The DailyProjectDataClient allows a programmer to peek into Hackystat data so one can develop events. Some of the data that can be located within Hackystat.

• Development time
• Build data
• User data
  • User name
  • User email
• Commit data
• Coverage data

The fun part about working with new frameworks like the DailyProjectDataClient is trying to figure out how the information is formatted. For the No MIAs event I spent several hours examining the dev time and user name data. Because I needed to know how to set the subString method for the user name which is extracted from the Member URI. The user name is needed to keep track of the user's development time. I implemented a HashMap to store the user's name and their dev time. Through the HashMap I can track if the user put in code time or not. Using the data in the HashMap the event can be scored accordingly based on the development time.

The Scoreboard
I wanted to spent sometime working on the scoreboard for Devcathlon. Unfortunately, because my time was used to develop NoMias and TestNoMias. I did not have a chance to work on the scoreboard. Hopefully, I will have more time in the upcoming week to build a rough draft.

Development Activity

• Monday 2/23
  • Worked NoMias and TestNoMias, misinterpreted the specifications of the Event, need to fix the code and test.
  • Research using
• Tuesday 2/24
  • Worked on NoMias and TestNoMias, used the wrong class SensorbaseClient. Should use DailyProjectDataClient class to get dev time data.
• Wednesday 2/25
  • Worked on NoMias and TestNoMias, used a lot of print statements to check how the dev time and member data is accessed.
• Thursday 2/26
  • Worked on NoMias and TestNoMias, spent time working on the scoring the event.
• Friday 2/27
  • Completed NoMias, TestNoMias, and ICS 414 blog.
• Saturday 2/28
  • Fixed NoMias, cleaned up code, and added three methods to reduce clutter.
  • Worked on Devcathlon scoreboard and blog.
• Sunday 3/1
  • Complete ICS 499 blog
  • Worked on Devcathlon scoreboard.

Devcathlon: Event Implementation

Introduction
In order for scores to occur in Devcathlon an Event must be invoked by the activity of a development team. To get a feel for implementing an actual Event the team is enacting Starter Events.

Engineering the Event
My Starter Event for the week is called No MIAs which tracks the development activity of members within a team. The system is checked every 24 hours for programming activity.

• If a member of a team has not made alterations to the code within 72 hours his or her team loses 10 points.
• If all members of a team has not developed within 72 hours his or her team loses 20 points.

The point of the event is to assure everyone on the team is carrying their fair share of the project load.

Implementing this part of the system is difficult because there is a steep learning curve with coding a new framework. The complexity of the development is in finding the right combination of code to get the No MIA event to work properly. Invoking No MIAs will do the following.

• Iterate through a list of team members.
  • Using the foreach is like learning to play golf, you're not always going to hit it straight but when you do its quite satisfying.
• Check for every team member's development time against a 72 hour time period.
  • To do the time check do a calculation using the current time and the member's dev time.
• Set up a XMLGregorianCalendar instance for comparisons using the Tstamp class.

Another piece which is causing me much grief is the configuration.example.xml file. If I cannot get the script to work I will not be able execute the unit test. <DevcathlonConfiguration> Hackystat webserver stuff... <EventConfigurations> other code... </EventConfiguration> <EventConfiguration event="No MIAs"> <WakeupInterval minutes="1440"/> <BaseScoreWeight weight="1"/> <Properties> <Property key="OneMember" value="-10"/> <Property key="AllMembers" value="-20"/> <Property key="ThreeDays" value="4320"/> </Properties> </EventConfiguration> </EventConfigurations> </DevcathlonConfiguration> According to the stack dump the OneMember property cannot be found, I do not understand because the getProperty method takes in the oneMemberKey String, which holds the "OneMember" property.

public NoMias() throws EventException {
    super(eventName);
    try {
      this.oneMember = Integer.parseInt(configManager.getProperty(eventName, oneMemberKey));
      this.allMembers = Integer.parseInt(configManager.getProperty(eventName, allMembersKey));
      this.threeDays = Integer.parseInt(configManager.getProperty(eventName, threeDayKey));
    }

Not sure how to resolve issue at this point because I can't locate the cause of the failure.

Edited on February 25, 2009
Found what was causing the error with the unit test. I improperly set up the properties for the configuration.example.xml file. Now I can move on with the unit test.

    configManager.addProperty(eventName, "OneMember", String.valueOf(oneMember));
    configManager.addProperty(eventName, "AllMembers", String.valueOf(allMembers));
    configManager.addProperty(eventName, "ThreeDays", String.valueOf(threeDays));

Screencasts
The screencasts are great! When I was going over the Hackystat API for this assignment I was using the screencast to review content that needed clarification. If students are sadly mistaken if they think they can miss class because the lecture will be available online. Professor Johnson enjoys giving quickie quizzes instead of taking attendance.

Conclusion
Good and challenging assignment, I need another day to finish this assignment, also I need to solve the issue with the property key from the configuration.example.xml file. Once I fix the problem I can perform the unit test and clear the Event from the issue board.

ICS 499: Devcathlon Event implementation and Scoreboard design

Introduction
For the week of February 16 to 22, ICS 414 continues with the development of Devcathlon, get exposure to Yahoo YUI and JavaScript for working with dynamic pages.

Event Building
The team is getting an introduction to Event building this week and developing Starter Events which will eventually turn into actual Devcathlon Events. To help the team with the development of the Events. Professor Johnson created helper classes to get the team acquainted with developing Event code. I think the code for the Events is straightforward, nothing overly complicated, just a matter of sitting down and working with the API.

For NoMias, the class needs to retrieve the following data.

• Track down the project, team, and team owner.
• Within the team data, iterate through each team member, and extract the development time.
• Retrieve the current time and compare it against each member's dev time.
• If a member has not coded within 24 hours deduct 10 points from his or her team. If a member has not coded within 72 hours deduct 20 points from team his or her team.

Seems fairly easy the only hard part that I see is to extract each team member's development time data.

Scoreboard Design
I think Devcathlon should have a cool scoreboard something that looks like Yahoo's GameChannel which tracks live sporting events. To design something like the image on the right requires the learning of Yahoo YUI and AJAX. In order to accomplish the cool scoreboard I am going to take on Yahoo YUI and AJAX so Devcathlon players will have something groovy to track their scores.

The scoreboard should have been part of the mockup phase however, I unsure if it was something that could be coded. After researching Yahoo YUI I feel confident that it is something that could be implemented into Devcathlon and look forward to challenge.

My interest of Yahoo YUI was sparked by Robin Raqueno who was working on the progress bar for Devcathlon. I wanted to know how to get dynamic elements functioning in Devcathlon. I have yet to implement code using Yahoo YUI because I am going through the Starter Event development. I hope to get something up and running next week. During my research I found several advantages of Yahoo YUI.

• Open source.
• Portability across most web browsers.
• Well documented.

Development
For the past two blogs I used a table to show the time I spent working on elements for ICS 414 and 499. In this week's blog I will do a daily summary of topics I researched and coded. That way Professor Johnson can get a better feel for what I am doing with my time rather than just posting my development hours.

• Monday 2/16
  • Edited ICS 499 blog to make it presentable. Worked on Hackystat implementation assignment, should have made a stronger effort having difficulty sorting through the API.
• Tuesday 2/17
  • Worked on ICS 414 blog and Hackystat implementation assignment. Got Task1 to work however, running out of time to get Task2 to operate.
• Wednesday 2/18
  • Start work on Event implementation assignment: logged myself into Hackystat for the Devcathlon project and took ownership of the "No MIA" event.
  • Start ICS 499 blog, within the process of writing the blog I am also learning more html by working with dates and lists.
  • Started research on Yahoo YUI.
• Thursday 2/19
  • Continue work on the Event Implementation assignment: Researching KeepTheCoverageHigh and TestKeepTheCoverageHigh, starting to code NoMias and TestNoMias.
  • Continue research on Yahoo YUI.
• Friday 2/20
  • Continue work on the Event Implementation assignment: Researching KeepTheCoverageHigh and TestKeepTheCoverageHigh, continue coding NoMias, added more properties to the configurationexample.xml.
• Saturday 2/21
  • Continue work on NoMias and TestNoMias, its slow going, trying to fully understand what each method is doing.
  • Continue work on ICS 414 and 499 blogs.
• Sunday 2/22
  • Continue work on NoMias and TestNoMias.
  • Continue work on ICS 499 blog.

Devcathlon: Interfacing the System to Hackystat

Introduction
Devcathlon is still in its shell state the development cannot move forward without a mechanism to track scoring. Devcathlon must be integrated with the Hackystat system in order for points to be distributed.

The Code
Task1

Working with Hackystat
In Devcathlon, the point system is dictated by events performed by software developers. Scores are earned or taken away when a programmer performs an action within the events list. To track a developer's efforts Devcathlon must have an interface that connects with Hackystat. The Hackystat system is well documented and contains several APIs to help retrieve data.

Implementing the APIs is the easy part trying to figure out where to find the class or method was the difficult part. Hackystat has numerous classes that I am unfamiliar with and required many hours of research to understand how each component works.

    String host = "http://dasha.ics.hawaii.edu:9876/sensorbase";
    
    SensorBaseClient.isHost(host);
    
    //to login
    SensorShellProperties sensorProperties= new SensorShellProperties();
    String userId = sensorProperties.getSensorBaseUser();
    String userPassword = sensorProperties.getSensorBasePassword();
    
    //need a client
    SensorBaseClient sensorClient = new SensorBaseClient(host, userId, userPassword);
    
    sensorClient.authenticate();

The above code sets up application for logging into the system. Notice the sensorProperties object which accesses a .properties file which holds user information. Eliminating the need to hard code data into the program.

    MultiDayProjectSummary summaryIndex = 
      sensorClient.getMonthProjectSummary(userId, myProject, 2008, 11);

The code sets up a MultiDayProjectSummary object and takes in a summary of data from November 2008.

  logged in...

  01-Nov-2008 0
  02-Nov-2008 0
  03-Nov-2008 0
  04-Nov-2008 110
  05-Nov-2008 87
  06-Nov-2008 0

A snapshot of the output from HackystatOne.java.

Screencasts
Professor Johnson added a new feature to class lectures utilizing a program that records his desktop and webcam at the same time. The a few nice things about using screencasts for lecture purposes.

• Nothing in the lecture will be missed.
• The lecture can be reviewed at a later date.
• No need to bother the professor about items in the lecture.

There maybe a downside to using the screencast for lecturing but I think the benefits outweigh the negatives.

Conclusions
The APIs for the Hackystat system will be useful when the team starts to develop the Devcathlon Events. All of the necessary classes and packages will be at our finger tips to collect Hackystat sensor data. The sensor data is the lifeblood of Devcathlon the information from Hackystat will be used for the all important scoring mechanism. Without the point system, Devcathlon will be one boring game.