Devcathlon: Great Experience

It has been a while since the last blog entry. The spring semester of 2009 at University of Hawaii is almost over, only couple of days left. What have I been up to for the last couple of weeks – doing some coding on the Devcathlon system of course!

For those of you who are not familiar with what I am talking about, here is a quick summary of what the Devcathlon system is. The Hackystat "Devcathlon" (http://code.google.com/p/hackystat-ui-devcathlon/) is a software engineering game where individuals and groups "compete" based upon their actual software development practices. A software development rule they follow or practice (for example, commit code at least once to a main repository) will be turned into an event, that event have a negative and positive score. A team or programmer follows an event is award points, and not following will a deduction in their score. The Devcathlon system is now running and functional (http://dasha.ics.hawaii.edu:9880/devcathlon/).


The whole Devcathlon development team was given the task to test run the system and jot down findings of what works and what does not work. So I have been test driving the system. What I found

• (1) should have added scroll option to the events’ panel.
• (2) The team main, team browse, and match invitation are working.
• (3) Match invitation’s decline button does not delete the match from Match browse when one of the team owners decline.
• (4) Preview icons after selecting one from list or uploading from local machine.
• (5) Overall, the system is running and functioning.

Next, I invited a friend to test drive the system. I kind of notice at times where a scratch to the head and a face of confusing of what am I suppose to do next look. Anyways, here is the outcome:

• (1) the scoreboard on the login page is great for people who do not have a login credential to get a small “preview.”
• (2) Liked the whole personal profile managing system, it is like editing your own Facebook, MySpace user account.
• (3) Commenting on a match lets users “turn up the heat” on the opposing team.
• (4) The events panel should be scrollable, the list gets too long.
• (5) There should be more images on the site, it looks a little bland.
• (6) Link to a user guide should be included within the menu.
• (7) Add a little more color to the current color scheme, it did not give a “kick.”
• (8) Overall, the system is a new kind of “game” that programmers might use. I do agree with my friend’s observations and opinions, testing driving the system were somewhat straight forward.

Well, it was a great semester in Dr. P. Johnson’s software development 2 class. Here is my Top Five Lessons Learned from ICS 414:”

• (1) Working with a team of eight programmers is a lot harder than with four and two programmers.
• (2) Do not start programming late, input some hours into a program everyday.
• (3) Fixing merge conflicts when uploading to main repository is a pain in the butt.
• (4) In the team, there will be someone who is willing to parallel/pair program with you late in the night.
• (5) All team members have their own style and habits, but we all should communicate with others and follow a standard so there will not be a “silo” effect on the system.

My software development habits have changed a lot – now I know what “siloing” a system means – where people do not communicate with each other, causing people to not be productive and difficult to achieve milestones. Program earlier in the week, so there will not be a late night session at a library. My strength is that once I get the train rolling, then I am on it. My weakness is that the first couple of minutes, I do not know what to do, or I get distracted by other things. I will be working on staying focus and get the trains rolling. Overall, it have been a great experience to work in a team, meeting milestones and deadlines, having the experience on what it is like when a deadline is not met, and programming in a big project like this one.

Devcathlon: User and Team Pages

The Devcathlon system was official turned over to the students in my software engineering class on Wednesday Match 18, 2009. The professor, P. Johnson, is still fully in charge of the system, but the coding and laying out the HTML’s are now in our hands. Hopefully we (students) get a lot of coding and layouts done before mid-May. Alright, here is my run-down of what I did before March 23, 2009 milestone.

We formed two teams to tackle some coding of the devcathlon system – Team User-Team and Team Matches-Scoreboard. I was on Team User-Team (A. Du, J. Ly, S. Sanchez, and me), this team does the coding and HTML layouts for user profile, user’s team profile, listing of teams in the system, listing of user’s teams, manage teams, invitations for joining a team.

So my job was to layout the User’s Teams and Teams in Devcathlon pages. Pages display teams, one is teams affiliate with the user, and the other is all teams in the system. So I created the layouts for both pages, what they should look like. The following images show the layout in the web browser.

I also added pagination to both pages, they are numbers of pages you can look at, a previous arrow to go back one page and a next arrow to go on. The pagination is a great idea if people want to go to Page #3 or Page #8 without looking at the pages in between. The pagination on the Team Browse Page is using the letters of the alphabet because that page display all teams in an A-Z manner.


I made around five to six to the main repository since March 18, 2009. I know it was not that much, I did not commit in the earlier part of the week because I was still implementing the wicket coding (http://wicket.apache.org/) for User’s Team and Team Browse Pages. The majority of my code were committed to two packages: the org.hackystat.ui.devcathlon.teams and org.hackystat.ui.devcathlon.teams.browse.


You can click on the following link to view issues/tasks that are assigned to me: http://code.google.com/p/hackystat-ui-devcathlon/issues/list?can=1&q=PhillipKHLau&colspec=ID+Type+Status+Component+Owner+Summary&x=owner&y=component&mode=grid&cells=tiles. Since March 18, 2009 to the date of this blog entry, I had for issues assigned to me. I complete two of the four issues; the other two issues were not required by this milestone.


My development time tracking sensor for Eclipse is not working properly, I did not notice until fellow team UT member, J. Ly, told me to check out my development time sensor because it is not displaying the amount of time I worked in Eclipse. After posting this blog, I will be reinstalling my Eclipse development time tracking sensor and test it to see if it is the case. I am pretty sure I put in a lot of hours for this week, especially over the weekend.

My team, Team UT, met on Wednesday (when we were in our newly formed groups) and on Friday, March 20, 2009. Those dates we did in-person meeting, met for one hour discussing about the layouts and API’s for getting user and team data. We did two online meeting on March 19 and March 22, 2009. The two online meeting was to for any questions and answers while we are working on our tasks. All the meetings were good because you get to know if everyone was on task and what not.

Wicket All Over Again

HAHAHA! I do not remember how to do Wicket (http://wicket.apache.org/) and Cascading Style Sheets (CSS) for html pages. This week for the software engineering class, we are refreshing our minds with an example on wicket, cascading style sheets, and HTML’s. The example is using a menu bar, submenus, and CSS to create an appropriate look. We took the code from a guy named Adam Kalsey (http://kalsey.com/2003/05/css_tabs_with_submenus/) and we have to modify his example to fit what we want.

My first task was to make a new menu (menu 3) in the menu bar that comes with three submenus. That was easy, just have to add some new codes to the BasePage.java and create new htmls for menu 3 and its submenus.


My second task was to make menu 3 to hold ten submenus tabs. So I went into the menu.css and added #menu #subnav 4 to #menu #subnav 10, so this will let the menu bar hold ten submenu tabs.


My third task is that when the header/title text on the page is change to different sizes, the submenus are not dynamically position; they are set to a constant number of pixels. If we change the text size from one to another, we also have to change the fixed position of the submenus. By doing that, we have to go into the menu.css and change this part of the code to the correct number of pixels.


I had trouble doing the final task for this example, is to make the submenu tabs highlight people are viewing that submenu. I did a little research using Google.com to search up any useful implementation of that kind. They had some, but did not work out in the menu bar. A little Java Scripting would be helpful in the future; if possible we can use it for the Devcathlon system.

Had this handy dandy book on the side:


Here are the files that I modify and used, the ten tabs can only be view on test-menu3.java (because that was the page that I modify and did not add to test-menu1.java and test-menu2.java): http://sites.google.com/site/phillipkhlau/files/wicket-example05-phillipkhlau-1.0.318.zip

Devcathlon: Regular Events

This week we are continuing our work on the Devcathlon system. This week, we are working on regular events(http://code.google.com/p/hackystat-ui-devcathlon/wiki/Events). We are also partner up with a fellow classmate to work on this week’s event.

I am partner up with fellow classmate, R. Raqueno. The event we are working on is ‘Keep The Repository Clean,’ there are two wakeup intervals to that event, the first one is waking up every 60 minutes to check if there are any failed builds during that 60 minutes range. The second one is waking up every 24 hours to check if there are any successfully builds during that 24 hours period.

So I am working on the first part of this two-part event. ‘Keep the Repository Clean Hourly,’ event where it will check the continuous integration service (Hudson) every 60 minutes intervals and see if there was any failed builds. If there is a failed build during that check, then it will deduct five points for that team. My part of the event was simply and easy to implement. I re-used my code from a previous event I did ‘Pass the Build,’ added couple of lines so it checks for continuous integration builds instead of regular builds. I also did some test cases to check if the code and scoring is working properly.

I did not run into problems when coding for this event. I did run into problems when I was running automated error detection tools (Emma, JUnit, FindBugs). I forgot what the error was, because it did not happen after a couple of tries. I do not think it is a heap overload error, because it was corrected by the professor, so I do not know what it was. I try to reproduce the error as I am writing this entry, but I am unsuccessful in producing the error again.

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.

Devcathlon: Mockup 1

In my previous blog entry, I talked about the second semester of software development class. This semester we are going to code a game called Devcathlon (http://code.google.com/p/hackystat-ui-devcathlon/), a collection matches for programmers. Points are based on variety of things: program code compiles, build successful; points can also be deducted on compile failure, and other things. Programmers can team up and go against other team. Devcathlon is based on Hackystat (http://code.google.com/p/hackystat-ui-wicket/) and/or Hudson (https://hudson.dev.java.net/).

I am teamed up with fellow classmates John L. and John Z., to create a mock draft of what it should look like, the first couple of days we were planning on what should go on the site, so each of us made a sample. Friday night we had an online meeting and showed our sample. We agreed on John L’s layout and took my idea of a drop down menu bar.


So everything was agreed on and we started to tackle the mock draft. I created my set of sites and uploaded to our team’s repository folder. By now we have our mock draft of Devcathlon, it looks decent and alright. The bad part about my Hackystat data is that I did most of the pages using another program and not in Eclipse. Since we are creating web pages, I did most of my set of pages using Adobe Dreamweaver CS3. So I might not have any Hackystat data for doing my set of pages.


Some Devcathlon events I think would have been good for this “match” are committing no more than 300-500 lines per one time, spread time out evenly (like working no more than two hours each day), meeting at least once in the week, spread work evenly with team. I do not see getting coverage as one of them, and building/compile correct as another. I think our team would have won; the points probably came from rules being set before a match, and one or two self-reporting points.

"Devcathlon" Game

Had a blast in 2008, welcomed the New Year, out with the old. A new semester at the University of Hawaii, taking the new software engineering course two with Dr. P. Johnson.

Right now, the project for the class is to develop a similar game (http://www.ddj.com/cpp/184401568?pgno=1) that will reward and deduct points from a group of people. The points are based on if a person fails a build (does not have automated tools [PMD, FindBugs, Checkstyle, and etc.], does not pass Junit test case runs, and/or does not compile). There are other ways the points can be given out. The game will be called “Devcathlon”; the ‘dev’ is for code development, the ‘cathlon’ is similar to the Olympic event Decathlon. The game racks up points for each developer and at the end of a time length, the group of developers can see who racked up the most points and have bragging rights for the time being.

Before the class begins working out the code, GUI, and the works of this game, each of us have to find out what makes a game “good?” I took a game designing class a year ago, and this question was brought up to us on the second day of class. The class used Adobe Flash, and we did animated games, you can view the games I done by clicking on the following link: http://sites.google.com/site/phillipkhlau/projects-page. Back to the subject, what makes a good game, so I read an article (http://serc.carleton.edu/introgeo/games/goodgame.html) and I agreed with the points the author made, it got to be fun, it has to be balance between the AI and player, player and player and etc. Other points includes getting the player hooked onto the game, there are certain games that I played and got bored of it (I have one or two games where I still did not get though the story) and there are some games where I finished it in three – four days. This article http://www.gamegrene.com/node/591 I read, talks about why Halo is a good game, maybe because they are “fun.” That is one good point; the game has to be fun to the player. Another site I read was a forum site; it was asking why the game Silent Hill is scary, what makes it scary http://boardsus.playstation.com/playstation/board/message?board.id=horror&thread.id=41323, another point of making a good game is probably the surprises that come along with the game.

Taking what I read about making a good game into making the Devcathlon system. The system can have “surprises” like extra rewards (like reward of 20 consecutive successful builds) and deductions. Can have some animation in it, in this day and age, I do not think a text-only game will be “fun” (I might be wrong). Can the points be useable, or it is just there.