Devcathlon: Starter Events Part 2

We got our Devcathlon starter events (http://code.google.com/p/hackystat-ui-devcathlon/wiki/StarterEvents) extended because not everyone was done or something was missing or extra lines code that does not have to be in there. Getting it extended was a good and bad thing – good thing was that the code was reviewed by the professor, P. Johnson, so we know what to change and what to get rid of; bad thing is that this means most of us were not starting ahead of time, delaying the next part of the Devcathlon system.

My starter event is “Pass the Build,” an explanation on my previous blog post. Making things short, it checks data for successful and failed builds. Gives one point for each successful build, deduct one point for each failed build. There are bonus ten points for successful builds and no failure in a seven day period.

Some mistakes I made in my coding, my method names were not meaningful to what they actually do – corrected that, hopefully it is not confusing now. My methods for finding build data was not working because I was not using the correct result types: ‘Failure’ and ‘Success;’ I was using “failed” and “success’ – that is corrected and the methods are working correctly. Lastly, I made test cases for testing out my methods working properly in finding and scoring points for my start event.

A problem came up in Hudson after I committed my files to Devcathlon’s main repository. Hudson failed build after I committed, the error message I notice was this:

[junit] java.sql.SQLException: Failed to start database 'sensorbase',
see the next exception for details.

I did not know how to fix it and it was causing on random test files. So I asked a fellow student, J. Ly, if he have any idea on fixing it. Scratching my head, I came up with this theory that something went down for couple of minutes on Hackystat side (my professor’s Hackystat server).
That theory was proven wrong when I ran automated testing and it was able to contact the “sensorbase database" on my local machine. So I changed some Javadocs in order to have Hudson build again, first two times Hudson failed, but the third time was a charm when everything passed in Hudson. Soooo… I do not know what really happen that cause that error.

Devcathlon: Starter Events

This week we are starting to code for the Devcathlon system. What is the Devcathlon system? My pervious blogs will tell you what it is. Soooo… this week, each of us in my software engineering class get to work on a starter event (http://code.google.com/p/hackystat-ui-devcathlon/wiki/StarterEvents).

Starter events are simple events to code to get started on Event portion of Devcathlon. My starter event was:

Pass The Build
Summary: Give points for passing builds.
PAR: Wakeup once per day. Determine how many builds occurred during that interval and how many passed and how many failed. Award 1 point for each passing build during the past day and deduct -1 point for each failing build during the past day.
Decay/Incentives: Award 10 bonus points for 7 straight days with at least one build per day and no failures.

So this event only checks one team at a time and rewards +1 for each successful build deducts 1 for each failed build. It also gives a bonus for 7 straight days of successful builds and no failure. The problem I ran into was going though the correct Hackystat Javadocs for the right line code to work with, I asked some of the classmates for help, which was great. Another problem was the TestConfigurationManager file, it tests the total number of events, and the problem was incorrect number of events to test.

assertEquals("Test events", 7, config.getEventConfigurations().getEventConfiguration().size());

Merge conflicts happened this morning when I was uploading my java files onto main repository. Hudson failed to compile and build because of incorrect number of events and other things. Like around 12:30 AM 2/25/09, Hudson failed for couple of hours, the person that failed it did not fix it. One of the classmates that were waiting for the Hudson to compile and build successful gave up the wait and went in and fix it. One other problem is that coverage tool Emma (http://emma.sourceforge.net/) is showing 0% line coverage for all test files, I do not know what is going on, for example my test cases is working in Eclipse, but showing failed in Emma.


On the side note, I think the screencasts (http://code.google.com/p/hackystat/wiki/Screencasts) are great, if it is possible to get the file too that was with each screencast will be awesome as well.

My First Hackystat Data Retrieval Program

We are about to start coding for the Devcathlon system. If you do not know, the devcathlon system is a “game” my software development class is going to make. The game consists of matches against software programmers. Before we can start coding for the devcathlon, we have to learn how to retrieve information from the Hackystat server (http://dasha.ics.hawaii.edu:9879/projectbrowser/). Our professor, Dr. P. Johnson, gave step-by-step tutorials on how to retrieve information from the server (http://code.google.com/p/hackystat/wiki/Screencasts).

With all that resources available, I code my first basic hackystat program. This program will retrieve the total number of data instances for each day of November, 2008 that was submitted to hackystat server. A data instance can be coding time, number of commits to main repository, and etc. My program will retrieve data instances from November 1, 2008 to November 30, 2008. Then it prints out the total number of data instances for each day, and the total for November 2008.

import javax.xml.datatype.XMLGregorianCalendar;
import org.hackystat.sensorbase.client.SensorBaseClient;
import org.hackystat.sensorbase.resource.sensordata.jaxb.SensorDataIndex;
import org.hackystat.sensorshell.SensorShellException;
import org.hackystat.sensorshell.SensorShellProperties;
import org.hackystat.utilities.tstamp.Tstamp;

/**
 * My first Hackystat program to get information from U. of Hawaii Hackystat server.
 *
 * @author Ka Hung Phillip
 *
 */
public class HackystatTask1 {

  /**
   * Get the total number of data instances for each day of November 2008.
   *
   * @param args
   * @throws SensorShellException
   */
  public static void main(String[] args) throws Exception {
    String host = "http://dasha.ics.hawaii.edu:9876/sensorbase";
   
    SensorShellProperties properties = new SensorShellProperties();
   
    String user = properties.getSensorBaseUser();
    String password = properties.getSensorBasePassword();
    System.out.println(user + "\n");
   
    SensorBaseClient client = new SensorBaseClient(host, user, password);
    client.authenticate();
   
    String project = "Default";
    XMLGregorianCalendar startTime = Tstamp.makeTimestamp("2008-10-31");
    int total = 0;
 
    for (int i = 0; i < 30; i++){
      XMLGregorianCalendar endTime = Tstamp.incrementDays(startTime, 1);
      SensorDataIndex index = client.getProjectSensorData(user, project, startTime, endTime);
   
      System.out.println("Total # of instances for " + endTime + " is: " + index.getSensorDataRef().size());
      total = index.getSensorDataRef().size() + total;
      startTime = endTime;
    }
   
    System.out.println("---------------------------");
    System.out.println("Total instances for November is: " + total);
  }

}

I am still working on my second basic program that will retrieve data instances on any given month. My for loop that program is giving me funky results, fixing it and will have that code up probably later in the day.

This is cool that I can get instances from the Hackystat server; maybe in the future I can create plug-ins for other IDEs (jokes). My first problem I ran into was getting to the right command to retrieve data. I used the APIs on hackystat wikis to solve it. The second problem was getting the XML Gregorian Calendar date for correct retrieval. I forgot to put in the new date after each retrieval, fixed that and I got it to work. Right now, I am fine with Hackystat APIs, there is no problem for me as of now.

Devcathlon: UI Recommendation

My software development class is about to start coding the “Devcathlon” system. If you read my last couple of entries, it will tell you what the “Devcathlon” system is. Before we can start coding the system, we have to decide on one user interface.

My previous three blog entries review mockup 4, 5, and 6 for the Devcathlon system.
I choose mockup 4 layout for the basis of the Devcathlon system, but I also liked the mockup 6’s idea of integrating the system with Hackystat. The main page after a user logs in should be change. Add some images, or some create things to make it “hip”. I mean this is the first page that users going to see after logging in.

I kind of liked the military insignia as the ranking for the system and the dev-card with the level ranking. I liked mockup 4 and 5’s idea of not having to display all match details in My Matches page but have it in another page.

The collapsible tabs are excellent in saving space. I think there should be more of a social networking feel to it. Probably integrate a music player, and/or adding some apps into it. The comments on the user profile in Mockup 4 is awesome, lets people add their comments and the user profile.

I also like mockup 6’s idea of an Administrator page for the manager/boss. This page lets them promote and demote ranking of players and team. Also this page lets you award and take away badges. With this in place, players cannot cheat the system and put in bogus points and badges. With an administrator page, he gets to see over all matches and moderate things within the system.

The drop down menu bar might have to be change so it can also be collapsible within each link. Similar to menu bars in online stores, where a user click on a title and that title expands to different sections – this is done within the menu bar. As the Devcathlon is developing and new pages and ideas is added to the system. I think that the menu bar right now will not be able to show up all links.

We should not have an extra “messaging” system with Devcathlon. I think it will be one extra thing to worry about. Also, the system automatically sends emails to users, so keeping the system to sending emails to users is alright. I do not thing we need the extra messaging system. Too much hassle to worry one more “inbox.”

Add an RSS option to the matches, so users can get a RSS feed to anything that accepts RSS feeds. Keeps the user up to date with their current matches and projects. It is awesome with a RSS feed, I use it for my news updates and deals updates. Might be a good idea to have a RSS feed.


Spice up the color scheme by trying out different color combinations. There might be one nice color combination beside the light-blue we have right now for the Devcathlon.

These are the things I have in mind for the user interface recommendation. Hopefully some of them get implemented into the Devcathlon system.

Devcathlon: Mockup 6's Review

My software development class is about to start coding the “Devcathlon” system. If you read my last couple of entries, it will tell you what the “Devcathlon” system is. Before we can start coding the system, we have to decide on one user interface. Soooo… this week, I am going to review my team’s mockup pages and the other two teams – let’s get started.

This entry, I will be reviewing Mockup 6’s team – oh yeah, that is my team. This team consisted of D. Arakaki, J. Ancheta, and me. This team is the “dream” team, the awesome team out of the class.


The first user interface is similar to mockup 4 and 5’s pages, we also have an administrator page called Gamemaster that lets the “manager”/”boss” to promote and demote rankings, also they can add and take away certain achievements. Our ranking system uses military insignias and you can be automatically promoted if you obtain a certain amount of achievements. I kind of like the idea, as you obtain more and more badges you get to go up rank.


I want to review the second user interface that mockup 6 have. The idea was that in order to create a team, first project have to be defined in Hackystat. Once there is a project, it has members in it, and that is how teams are created. Taking that approach of “binding” between Hackystat and Devcathlon. The idea was to have Devcathlon be integrated into the Hackystat project browser.

With this intregration, it is only few clicks away from defining a project and members for that project (that in turn creates a team). The tabs on the left are layout for the user to have easy access to Devcathlon.

The layout is similar to Hackystat browser, most of the Devcathlon pages are one page-r. Following Hackystat’s layout, the Devcathlon have a similar design to its own layout. Since the pages are integrated with Hackystat, the color scheme is all the same. The downturn is that we cannot define a new color scheme for Devcathlon or else it will look entirely different. There is one or two widgets – gamemaster have the widget with military insignias and badges to promote and demote players, widget to add files to Devcathlon.


Mockup 6’s Pros:

• nice idea of integrating into Hackystat Project browser.
• Gamemaster lets player be promote and demote in rankings and badges
• keeping Devcathlon simply by adding extra menu tabs on the left.

Mockup 6’s Cons:

• Color scheme cannot be different from Hackystat project browser.
• might be too confusing to first time users.
• Gamemaster can be bias.

Overall, I liked the idea of integrating with Hackystat, but it does not let us change the color scheme. Also it might be too confusing for first time user. It might be best to have Devcathlon user interface separate from Hackystat.

Devcathlon: Mockup 5's Review

My software development class is about to start coding the “Devcathlon” system. If you read my last couple of entries, it will tell you what the “Devcathlon” system is. Before we can start coding the system, we have to decide on one user interface. Soooo… this week, I am going to review my team’s mockup pages and the other two teams – let’s get started.

This entry, I will be reviewing Mockup 5’s team. Their team consisted of A. West, J. Zhou, and S. Sanchez. This team also has an advantage in creating some awesome pages and coming up with some cool ideas for the “Devcathlon” system.

Mockup 5’s main page after logging in is similar to Mockup 4’s main page. The main page shows most links that a user can click on to get started. The drop down menu bar right after banner also has most of the links for the user to examine. A user can get a team and a match started fast – just takes three to four clicks to get both a team and match.


The main page, user profile, and drop-down menu bar shows everything a user needs. The user profile is different from Mockup 4’s user profile. This user profile shows information about that user, I wonder if this applies to all users, and do they have any option of not showing certain information, like their address. The user profile, everything is on the left side, too much white space on the right side of the page. The team should have thought of lay out in a way to get rid of white space. I liked their idea on the “My Matches” page, only if they have thought of getting open and close tabs that would have been excellent. They will save time from linking all the html pages together.


The pages organization looks somewhat consistent. The user’s profile has to be fix to get rid of the white spaces on the right side. The icons on the achievement page should be all one size and not different sizes – it looks messy and the color scheme on that page does not match the color scheme for the entire site. Overall, the layouts looks similar, they are not confusing and “messy.” They have one or two widgets in place, like importing a file – a window pops up for you to find the files on your local machine.


Mockup 5’s Pros:

• My Matches page – good idea in making the each match clickable and shown on that page.
• two to three clicks away gets a team and match started.
• The pages are consistent and layout does not show the pages “confusing.”

Mockup 5’s Cons:

• icons on the achievement page are different sizes, should make them all one size
• user profile is bunched up to the left, too much white space on the right.
• saving the hassle from making new pages, use the idea from Mockup 4’s open-close tabs

Overall, the team has a similar idea in creating an easy to use interface for the “Devcathlon” system. They have the similar laying out the pages so the pages are not confusing to a user.

Devcathlon: Mockup 4's Review

My software development class is about to start coding the “Devcathlon” system. If you read my last couple of entries, it will tell you what the “Devcathlon” system is. Before we can start coding the system, we have to decide on one user interface. Soooo… this week, I am going to review my team’s mockup pages and the other two teams – let’s get started.

This entry, I will be reviewing Mockup 4’s team. Their team consisted of J. Ly, R. Ranqueno, and A. Du. Personal, I think this team is stacked with developers who can think over the top and beyond.

Mockup 4’s main page after login shows most links that a user can click on to get started. The drop down menu bar right after banner also has most of the links for the user to examine. A user can get a team and a match started fast – just takes three to four clicks to get both a team and match.


The main page, user profile, and drop-down menu bar shows everything a user needs. All the pages looks like they are one page-r which is good because some people (I am one of them) do not like to scroll down a web page that is three or more pages long. I like their idea of using closeable drop-down pages within their pages; it saves page space and keeping the pages to one-two pages long. I do not like the user’s profile page where I have to scroll to the right in order to see the inbox. It is a hassle to scroll to the right of the screen in order to see the user’s inbox and scroll back to the left.


The pages organization looks somewhat consistent. The user’s profile has to be fix to get rid of scrolling right and left. Overall, the layouts looks similar, they are not confusing and “messy.” They have one or two widgets in place, like importing a file – a window pops up for you to find the files on your local machine.


Mockup 4’s Pros:

• the closeable pages within a webpage is awesome, saves space.
• two to three clicks away gets a team and match started.
• it has the facebook/myspace feel to it, overall the pages are consistent.

Mockup 4’s Cons:

• User’s profile have to scroll right to see the message inbox.
• not all the links are in the menu bar
• the closeable pages show have a drop-down indicator so user will know they are open-able.

Overall, the pages are consistent. I liked the idea of the close-open pages within each web page. It has a social networking feel to it, which is good because most people have a social networking site.

Devcathlon: Mockup 2

My software development class is still in the mockup phase for the devcathlon system. If you read my last two blog entries, it will talk more about the devcathlon system. This week, we switch around the teams, and I am currently working with J. Ancheta and D. Arakaki. With the new teams means new ideas and that means a new set of new pages for the mockup devcathlon system (http://code.google.com/p/hackystat-ui-devcathlon/source/browse/#svn/ui/mockup6).

My job was to redo the badges page (devathlon system is using a badge rewarding system, an individual achieve an event i.e. commit early to their main repository, will be rewarded a badge) the badges page had different image sizes, so I resized all images to 50 by 50 pixels. I added four new badges that an individual can get:

My next step was to create a level system (also can be call a ranking system, right now we are using D. Arakaki’s idea of using military insignias as our ranking system. For example, an individual will get a rank of a private when he gets two badges, and so on. The following image will show an example of the ranking system.

My last task was to create an event idea that might get into the devcathlon system. My event idea is:

Coaching
Summary: Reward to the individual that solves a problem and shares it with the other programmer, who cannot effectively solve problem alone. This other programmer has to understand the solution and how it was implemented so he can become a better developer.
PAR: After reaching a solution and shares with the other programmer, the developer that come up with the solution logs in to a special section to indicate their participation. They must indicate (a) what was the problem; (b) what was their solution; and (c) the other developer they were working with. This event instance then gets put on a queue of items to be validated by a member of the opposing team. If validated, the individual came up with the solution gets +15 points. While the other programmer gets +10 points.
Decay/Incentives: No more than 1 solution can be awarded in a single day to a single programmer.

We did at least two in-person meetings and one online meeting. I do not have any Hackystat (http://code.google.com/p/hackystat-utilities/) data for this week. Just like last week, I did my mockup pages using Adobe Dreamweaver CS3. Maybe in the next couple of weeks where we start coding the devcathlon system that I will get development time data from Eclipse IDE.