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.

ICS499: Collecting Raw Hackystat Data

Introduction
In order for Devcathlon to be an entertaining game actions of a player and/or team needs to have a score kept. In order to have an accumulation or loss of points Devcathlon needs to receive data from Hackystat. The Hackystat system has a series of Java APIs that helps with the retrieval of raw Hackystat data.

Devcathlon and Hackystat Data
A key component to Devcathlon and probably the whole point to the game is the collection of Hackystat sensor data. Hackystat data is the key mechanism for the automated events in Devcathlon. Through the Hackystat system, software engineering elements such as development time, committing clean build, and keeping coverage high will be tracked for scoring purposes. The Devcathlon development team will build an interface to retrieve sensor data and use the info to tracks scores of Devcathlon Events.

To assist the team Hackystat has a series of APIs to help build the interface. The Hackystat-sensorbase contains numerous classes that when implemented will collect sensor data. As an assignment I need to collect data from a specific date and display the number of times sensor data was sent for each day. I found everything I needed for the assignment in the Sensorbase and Sensor Utilities APIs. I found the APIs flexible where I could get a on handle dates, type of sensor data, and just about anything else within the Hackystat System.

As of this writing I am still working on the code and have only snippets to show. Also, the code is not very exciting its just a main method with a bunch of invocations to collect data.

  SensorBaseClient sensorClient = new SensorBaseClient(host, userId, userPassword);
  sensorClient.authenticate();
  
  String myProject = "Default";
  
  String firstDate = "30-Nov-2008";
  
  XMLGregorianCalendar endTime = Tstamp.makeTimestamp(Day.getInstance(firstDate));
  XMLGregorianCalendar startTime = Tstamp.incrementDays(endTime, -2);

  SensorDataIndex sensorIndex = 
      sensorClient.getProjectSensorData(userId, myProject, startTime, endTime);

The above code logs into the Hackystat system and calls on a date and project.

My only gripe with the Hackystat APIs is sorting through all of the classes. I was a little impatient with having to track down what I needed to know. For example, while researching the Tstamp class I wanted to know if I could pass in a Date instance as an argument. Instead I found another a class called Day which required more research. Of course I found what I needed and was able to retrive the date from Hackystat. I guess its part of the learning process of working with a new API and/or system.

Development Time

	Feb 10	Feb 11	Feb 12	Feb 13	Feb 14	Feb 15	Feb 16
Research Time	0.5	1.0	1.5	1.5	1.0	1.0	0.0
Code Time	n/a	0.5	1.0	0.0	1.0	3.0	2.0
Blog Time	0.5	0.5	1.0	0.5	0.5	2.5	1.0

Conclusion
Learning a new API takes time to do the research and experiment with the code. I remember an instructor telling me that the actual writing of code is only 10% of the development process. The latest assignment is a good example of research time outweighing coding time.

Devcathlon: System Recommendation My 2 Cents

Introduction
The mockup portion of Devcathlon is completed the system thus far has gone through peer reviews. UI recommendations will be made by everyone in the class and we will then proceed to the implementation of the code.

The System so far
Devcathlon is a mere shell right now made up of CSS and HTML script. So from a functionality the system does not do anything significant except link to other pages. The class was divided into three groups with each team responsible for creating their own mockup. All three teams have chosen a social networking type of apperance that should be familiar to anyone who has a Myspace or Facebook page.
Each team came up with good ideas and cool features for the game.

• Mockup4: Anthony Du, John Ly, Robin Raqueno laid out a decent badge system and a neat solution to showing a player's score and team information which I will talk about in my recommendations.

• Mockup5: Aric West, John Zhou, Scheller Sanchez nice scoreboard.

• Mockup6: John Ancheta, Daniel Arakaki, Phillip Lau came up a cool level scheme employing a military type system where players earn their "stripes" from earning so many badges. I will recommend a different type promotion system where moving up in level will require point production. Mockup6 team also designed a game adminstration element for Devcathlon called Game Master where an administrator can control the scoring mechanism, badge and level promotion or demotion.
  

My Recommendations
Devcathlon should move ahead and implement the system with the social network appearance. The design will appeal to a large audience and the class seems to have embraced the layout. The implementation from mockup6 which integrates Hackystat ProjectBrowser with Devcathlon is a clever approach in keeping the two systems tightly bound. However, building Devcathlon into Hackystat will be a process which requires a lot of time and thought. The team is restricted by the time aspect with twelve weeks left in the semester. The team should implement the following items from the mockups.

• The badge hierarchy and drop down design from mockup4 with some modifications to the drop down design to make it more intuitive for the player.

• The military style level system and game master from mockup6. Using a points methodology for players to get promoted in level should be considered.

• The gallery and scoreboard from mockup5 with modifications done to the gallery and scoreboard for organizational purposes.
  

Whats Next
Implementation of Java code and communications: email and Twitter. The class used Wicket to tie Java and HTML together I expect to use Wicket again for Devcathlon.

Expected issues
I am concerned with how we are going to get the data from Hackystat to communicate with Devcathlon. Another thorn in my side is JavaMail because we do not have a dedicated SMTP server we are going to have issues with sending messages out. Aside from my concerns I think we have good group this semester and Devcathlon will be a entertaining and interesting system.

Devcathlon: Review of Mockup6

Introduction
the mockup6 team is : John Ancheta, Daniel Arakaki, and Phillip Lau we did two designs one that follows mockup2 and a new design that integrates the Hackystat ProjectBrowser see on the left and Devcathlon. However, I will only talk about the mockup system Professor Johnson was hesitant with moving forward with the integrated system because of issues with interfacing with the Hackystat server.

The Mockup
The click ratio to perform a task seems to be in the 2 t0 3 click range. The pages could use more information because not everything in Devcathlon is intuitive. Although a well thought out design should make all pages and functions intuitive. If a page requires scrolling all it takes the user is one click to reach the bottom half of the page. The only problem would be the player profile but that page may not make it into the build. There was an effort to keep the design as consistent as possible. However, because there were 3 different developers there is slight deviation with each page but the overall look is uniform. The input mechanisms do not work, I guess the consensus was since this was a mockup the data forms did not need to function.

Strengths and Weaknesses
Badge and level hierarchy makes sense, should give the players a reason to have fun with the system. I can see players getting into the level system where they will work hard to get their next rank. There could be some bragging going on where developers will start showing their "stripes". I think with a little bit of work with the format the player profile page could be cool and fun for the players. The displaying of the badge and levels will be like a Myspace page.

Even the project manager or professor can get in on the fun with the Game Master function. The person in charge of development will be able get into the action by promoting or demoting developers and taking or giving away badges. I think the awarding of badge and levels still needs to worked out and there be a consensus as to how players get their rewards. In my opinion level promotion is based on points and at the discretion of the Game Master. The badges should be awarded based on achievement and again at the discretion of the Game Master.


The Gallery (seen on the left) was a left over mockup2 but it looks cluttered and unorganized not sure if we should implement it or make a modification. Because I think a scoreboard can do same function but with the scoreboard we should keep things tidy until the user decides to open up graphs and logs. For the scoreboard we should use mockup4's design because our design (seen below) seems rather plain in comparison.

Conclusion
I thought our group did some good work I was paticualrly impressed with John's idea of integrating Hackystat with Devcathlon. However, complications with integration nixed that idea but I think Professor Johnson should investigate integration of Devcathlon and Hackystat for a future project. So kudos to John with all his hard work with his integration idea and to Phillip for the design of the badges/levels.

Devcatlon: Review of mockup5

Introduction
This a review of mockup5: Aric West, John Zhou, and Scheller Sanchez who did the same thing as mockup4 and mockup6, took mockup2's system and modified the interface adding their levels and badges.

The Mockup
The tabs for mockup5 link to almost all of the necessary pages. Could not find a link to their levels page and it had to be opened outside of the interface.


Navigating through mockup5 was easy and did not require too many clicks to move from one page to the next. With exception to the player registration and Gallery all other pages make good use of the screen with a couple of pages requiring one click to page down. Most of the pages are fit well in the aesthetic sense. The organization of the mockup5's layout does not deviate each page fits and makes sense. The structure is similar to the systems in mockup4 and mockup6 so the user interface does make sense and has an order which is not confusing. Like the input mechanisms in mockup4 and mockup6 none of the forms in mockup5 take in data. Because there is no database I am guessing all of the groups chose to not have functional forms.

Strengths and Weaknesses
I do not see anything that is particular outstanding out in mockup5's system when compared to other user interfaces built by the other teams. However there are several items I think should be included into Devcathlon. There is a run down score of matches similar to a scoreboard from a sports website(seen on the left). With a little more work in making the text more readable by giving it a little more "pop" I think this will be a fine addition to Devcathlon. With regards to the levels it is not as interesting as the level system proposed by mockup4 and mockup6.

While the cat badges are cute(seen below), in my opinion I'm not sure if it will be appealing to the average player. Seeing how the majority of students in the department are guys.


Conclusion
The pages look similar to the mockup2 system and it seems like nothing new was added to the mockup.

Devcathlon: Review of mockup4

Introduction
This is a review of mockup4 the team Anthony Du, John Ly, and Robin Raqueno who did some cool things with their portion of the user interface for Devcathlon.

The Mockup
It looks like all of the teams chose the current look of the webpage. The design is similar to the player profile page for XBox's online system.


The user should have no problem navigating around mockup4's system. There are tabs that link all the pages together so there is no need to hit the back button.
One issue I have is with some of the navigation tabs like the My Profile tab which also contains a drop down menu. I understand the placement of the menu because Edit Profile, My Teams, My Matches fall into the My Profile category. However, the combination of a navigation tab and drop down list may confuse the user. One possible solution would be to create another tab/menu. Team Mockup4 did a really nice job with some of the additional features with their design. However, certain features may not be intuitive and will probably require a user to go searching for a desired task or information.


For example the My Teams page serves as a listing that points out which teams the player is participating in, listing teammates, team name, and scores. Team mockup4 added a nice feature where a user clicks on the gray bar and reveals the team's information.

Overall mockup4 makes decent use of screen space although the player profile page requires 3 clicks to reach the end of the page. After reviewing all the mockups it seems no one made changes to the profile page and maybe eliminated as we enter the build phase. The architecture laid out by mockup4 makes sense and is intuitive however, the system was borrowed from mockup2 so the layout was already in place. None of the input mechanisms work, nothing happens to data after typing it in and submitting. However, none of the other mockups had working input forms.

Strengths and Weaknesses
The badge system was well thought out it uses a point scoring system to award players. I especially the Larry O'Brien trophy from the NBA. I think most players of Devcathlon will identify with the badges. With mockup4 new badges will not be displayed until a player has enough points to earn the achievement. I thought the drop down menus for team pages was cool and a nice way to present the information. I would like to see an icon that points out the menu drops down. Because in its current state the reveal is not intuitive. Mockup4's architecture is well laid out all of the links are organized. I think we should go ahead, use their design, and add the other pieces to their system. Certain pages like the team information page could use more information to guide the user.


The level hierarchy page needs a little information however, I doubt we will implement the level system into Devcathlon. Because there is a sensitivity issue with the design and it maybe insulting to other professions.

The My Profile navigation tab needs to broken up because it seems confusing in my opinion. It could cause a user to miss click and navigate to the wrong page.

Conclusion
Anthony Du, John Ly, and Robin Raqueno did nice work on mockup4. The team should go and implement mockup4's badge system and drop down menu for the team information. In fact we should figure out what other pages could use a reveal.

ICS 499: Devcathlon, Mockingup the Interface

Introduction
For ICS 414 Spring 2009, the class will spend the semester building a software development game titled Devcathlon. The game will be integrated with Hackystat, a system used to track different aspects of application building. Some of the areas Hackystat keeps tabs on using sensors embedded into a developer's system.

• Development Time - Time spent writing code.
• Coverage - Using unit tests to invoke methods for application assurance.
• Commits - The number of times a developer uploads a change to the repository.
• Build Status - What shape the system is in at the time of the commit.

The data from the Hackystat sensors will be applied for scoring purposes. It is the class or team's job to integrate Hackystat with Devcathlon to build a working system.

Devcathlon
Game development is not an easy task it requires time and thought in order to come up something that is interesting and entertaining. The first stage of development for Devcathlon was to design a user interface. As part of team mockup1 we came up with a rough draft of the interface which included.

• Signin/Signup - A developer needs to be registered and sign into the system.
• Scoreboard - Keep the scores of ongoing matches between teams.
• Player profile - A developer's/player's page that holds the badges, levels, current score, etc.
• Game Adminstration - The Game Master can set up matches, teams, award badges and levels.

I chose the Game Adminstration which I called the Game Master. Initially the Game Master had controlled over everything registration and scoring. However, it was discovered Devcathlon must be tightly bounded to Hackystat. Therefore, if a developer is registered with Hackystat then he or she will have access to Devcathlon. For the second mockup it was decided the Game Master take on a new role as the person who hands out badges and levels should the deeds made by the player warrant such an award. The second mockup also required the groups to develop a badge or achievement system and a level hierarchy.



Our mockup included a level hierarchy that employs a military system. When a player earns so many badges he or she will move up in rank and receive their "stripes". Alternatively, I would like to see a point system where so many points gets the developer their promotion. I think this is a good system because it keeps a player striving to earn more points to move up in rank. In order to score points a player needs write code, make commits, not wreck the build, etc. Having good developement habits will lead to high scores and fast level promotion.

Our badge design is made up of a series ofdifferent icons a wrestling belt and ice cream. The badges are earned through scoring points. It will be difficult to differentiate between levels and badges if both rewards are earned on points. I think badges should be earned based on actions done by the player such as making so many consecutive commits without breaking the build which Hackystat will be able to read and the badge awarded to the player automatically.

Development Time(in hours)

	Design Time	Code Time	Blog Time
mockup1.0	3.0	5.0	2.0
mockup2.0	4.0	5.0	5.0

Conclusion
The groups wrapped up their versions of the mockup and the team will move forward with the implementation of Devcathlon. There is a lot work ahead of and I foresee numerous challenges such as interfacing Hackystat sensors so Devcathlon can track scores. I am hopeful that everyone in the class will carry their load and meet their benchmarks. Because we can ill afford to have someone slack off Devcathlon will be a challenging project.