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.

Devcathlon: Mockup 2.0 badges and levels

Introduction Ongoing development of Devcathlon, we started mockup 2.0 which includes the addition of badges, levels, and more events. The mockup6(old) group includes John Ancheta, Phillip Lau, and myself, at the 11th hour John came up with the neat idea of incorporating Devcathlon with the Hackystat Project Browser. Mockup 2.0 John's idea was to build Devcathlon into the Hackystat ProjectBrowser adding on the Game Master page, badges, and levels page. My Game Master page is an ongoing design which handles some of the scoring in Devcathlon. The game master should be able to promote or demote a developer's level and award badges outside of the automated scoring system. The goal is to be able click on a level or badge, along with choosing a player's name and the developer will have a new level or badge appear on their profile. With mockup 1.0 the Game Master was more of a system administrator adding projects and teams to Devcathlon. It was decided, because Devcathlon is tightly bound to Hackystat player registration was not necessary. To participate in Devcathlon a developer must be register with Hackystat. Sorry to those who wanted to enjoy the excitement of playing Devcathlon. Events Thinking up a new event is difficult and requires heavy thought it is not a simple as it sounds. I thought it important to keep track of the ratio of development time and the number of commits. For every hour of development time there must be at least one commit to the repository. If a developer does not make an upload after coding for a hour they lose so many points and the point loss will be incremental as programming time increases. During a development an issue could pop up that requires the learning of a new language or technology. A player could earn points, a level bump, or badge for successfully implementing something new into the system. As students we hope the development of a system like Devcathlon will assist us in getting employed. I know of at least two local employers who are aware of the content in Professor Johnson's ICS 413/414 Software Engineering classes. Big bonus points for the team that gets noticed by the folks in the professional computing community. Checkout the Events page for more information. Badges and Levels Philip is handling the badge and level design. A player will earn a badge after scoring so many points. You can see the detail of the badge system by clicking on the images on the right. For the level hierarchy Phillip chose a military theme. A level will be awarded to a player after earning so many badges. For instance after earning 10 badges a player will earn the rank of PFC. Team Scores Because of Devcathlon is still in mockup stage there are no builds to break or no worries over coverage at this point. The SVN sensor is not set up for mockup 2.0 so none of the commits are tracked. Team mockup6 had 3 team meetings, made commits, and spent time developing the mock pages. The point system is not set yet but I would say mockup6 has over 80 points. The chart above represents the total amount time spent developing mockup6 on Eclipse from January 27 to February 3 which was a total of 5 hours spent writing html script. What the chart does not show is the time spent meeting and mulling over badges, levels, and events. Phillip and John probably used other tools that are not tracked by Hackystat to develop their pages. In order to score John's and Phillip's development they need to self report the time spent coding or designing. All of the Hackystat sensors are not in place so not all of the data is being collected for scoring. Conclusion Mockup 2.0 is moving the team towards doing some heavy duty coding. Devcathlon is starting to take shape, I am excited to get started and get this project working.