Hackystat Programming 101

Purpose:

In this blog entry I'll describe my experiences working with Hackystat services and building my first Hackystat program.

Installation:

The installation of the Hackystat services and sensor binaries were fairly straightforward, given the aid of the Hackystat wiki pages and Professor Johnson's very helpful screencasts. All links and provided show notes for the screencasts can be found here.

Building my very first Hackystat App:

The following are two code snippets taken from my first Hackystat driven application which returns back the number of instances for each day of the given month and year, and my test-driven application for determining the max number of instances in a given month:

public class HackyProg1 {

/* Constants */
public static final String SENSORBASE_URL = "http://dasha.ics.hawaii.edu:9876/sensorbase";
public static final String PROJECT_NAME = "Default";

/**
* @param args
* @throws Exception
*/
public static void main(String[] args) throws Exception {
boolean isHost = SensorBaseClient.isHost(SENSORBASE_URL);
System.out.println("Try to contact host is: " + isHost);
SensorShellProperties properties = new SensorShellProperties();
String user = properties.getSensorBaseUser();
String password = properties.getSensorBasePassword();
System.out.println("U/P: " + user + "/****");

/* Check to see if the user is registered with provided host */
boolean isValidUser = SensorBaseClient.isRegistered(SENSORBASE_URL, user, password);
System.out.println("Check to see if this user is valid: " + isValidUser);

/* SensorBaseClient simulates a client instance */
SensorBaseClient client = new SensorBaseClient(SENSORBASE_URL, user, password);
/* Authenticate sensor base client instance */
client.authenticate(); // Is valid if returns client instance back.

/* Display the number of instances per day of the given month and year. Finally give the total # of instances for that month. */
int totalInstances = 0;
for (ProjectSummary projectSummary : client.getMonthProjectSummary(user, PROJECT_NAME, 2008, 11).getProjectSummary()) {
  for (SensorDataSummary dataSummary : projectSummary.getSensorDataSummaries().getSensorDataSummary()) {
    System.out.println(String.format("%s - %s : %s instances", projectSummary.getStartTime(), projectSummary.getEndTime(), dataSummary.getNumInstances()));
    totalInstances += dataSummary.getNumInstances().intValue();
  }
}
System.out.println("Total instances for the month: " + totalInstances);
System.out.println("--END--");
}

}

This was my attempt at determining the max day of instances for a given year and month. Unfortunately I ran into an issue specifying the project for a user given raw sets of data. Because of this, the test application is incomplete.

public class MaxMonth {
private String host, user, password, project;

public MaxMonth(String host, String user, String password, String project) {
 this.host = host;
 this.user = user;
 this.password = password;
 this.project = project;
}

public SensorBaseClient loginUser() throws Exception {
 /* Check to see if the user is registered with provided host */
 boolean isValidUser = SensorBaseClient.isRegistered(host, user, password);
 System.out.println("Check to see if this user is valid: " + isValidUser);

 /* SensorBaseClient simulates a client instance */
 SensorBaseClient client = new SensorBaseClient(host, user, password);
 /* Authenticate sensor base client instance */
 return client.authenticate(); // Is valid if returns client instance back.
}

/**
* Returns the day containing the the maximum number of sensor data instance give the month and year.
* @param m - month
* @param y - year
* @return
* @throws Exception
*/
public int getMaxMonth(int month, int year) throws Exception {
 int maxDay = 1; // 1-31
 SensorBaseClient client = loginUser();
 int totalInstances = 0;
 for (ProjectSummary projectSummary : client.getMonthProjectSummary(user, project, year, month).getProjectSummary()) {
   for (SensorDataSummary dataSummary : projectSummary.getSensorDataSummaries().getSensorDataSummary()) {
     System.out.println(String.format("%s - %s : %s instances", projectSummary.getStartTime(), projectSummary.getEndTime(), dataSummary.getNumInstances()));
     totalInstances += dataSummary.getNumInstances().intValue();
   }
 }
 return totalInstances;
}
}

public class TestMaxMonth {
/* SensorBase test instance 'overwrites' SensorBase properties */

/* Test server host name */
private String host = "";
private String user = "anthony@hackystat.org";
private SensorBaseClient client = null;

@Before
public void setUp() throws Exception {
 Server server = Server.newTestInstance();
 host = server.getHostName();
 /* Registration test will do the following:
  * Create the user and not send an email
  * Set the password equal to the user name.
  * */
 SensorBaseClient.registerUser(host, user);
 assertTrue("Testing registration", SensorBaseClient.isRegistered(host, user, user));
 /* Test will fail if JAVA MAIL is NOT installed properly */

 /* Authenticate newly created user client with test sensorbase server */
 client = new SensorBaseClient(host, user, user);
 client.authenticate();
 /* Send data from client to host with new user */
 /* Setting raw sensor data fields */
 SensorData data = new SensorData();
 data.setOwner(user);
 XMLGregorianCalendar tstamp = Tstamp.makeTimestamp();
 tstamp.setDay(3);
 tstamp.setYear(2008);
 tstamp.setMonth(2);
 data.setTimestamp(tstamp);
 data.setResource("/Users/hackystattest/TestHackystat.java");
 data.setSensorDataType("Build");
 data.addProperty("TypeOfBuild", "Development");
 data.setTool("Eclipse");
 client.putSensorData(data);
 tstamp = Tstamp.incrementHours(tstamp, 1);
 data.setTimestamp(tstamp);
 client.putSensorData(data);

 tstamp.setDay(15);
 data.setTimestamp(tstamp);
 client.putSensorData(data);
 tstamp = Tstamp.incrementHours(tstamp, 1);
 data.setTimestamp(tstamp);
 client.putSensorData(data);
 tstamp = Tstamp.incrementHours(tstamp, 1);
 data.setTimestamp(tstamp);
 client.putSensorData(data);

 tstamp.setDay(20);
 data.setTimestamp(tstamp);
 data.setSensorDataType(null);
 client.putSensorData(data);

 /* Return data given user and timestamp */
 SensorData returnedData = client.getSensorData(user, tstamp);
 assertEquals("Testing returned data", tstamp, returnedData.getTimestamp());
}
@After
public void tearDown() throws Exception {
 /* Delete the user */
 client.deleteSensorData(user);
 client.deleteUser(user);
 assertFalse("Testing deletion", SensorBaseClient.isRegistered(host, user, user));
}

@Test
public void testGetMaxMonth() throws Exception {
 int numInstances = client.getSensorDataIndex(user).getSensorDataRef().size();
 assertEquals("Testing number of sensor data instances", 6, numInstances);

 String project = "Default";
 MaxMonth maxMonth = new MaxMonth(host, user, user, project);
//    assertEquals("Testing getMaxMonth", 6, maxMonth.getMaxMonth(3,2008));
}
}

Overall, I still have very much to learn about using the provided Hackystat API's. Hopefully in the course of a few more days, I'll gain a better grasp on resolving my earlier issues.

ICS 499 - BMXNET, the next step

Purpose:

The purpose of this proposal is to gain minimal insight into electronic health record systems (EHR), and to explore the possibilities of developing an open source component to enable greater extensibility and interoperability for development platforms.

Introduction:

The Indian Health Service (IHS) is an organization under the U.S. Department of Health & Human Services (HHS) that provides health care services for American Indians and Alaskan Natives through federal IHS, tribal, urban-operated facilities and programs. The scope of its health care services have expanded into over 500 health care facilities composed of hospitals, health centers, school health centers, health stations, satellite clinics, and Alaskan village clinics. IHS and the U.S. Department of Veteran Affairs (VA) are long time collaborators in the tradition of health information and technology advance sharing. In 1984, IHS picked up on the VA's very own "VistA" medical health information software (not to be confused with Windows Vista) and renamed their version of the system to "Resource and Patient Management System" (RPMS). RPMS is one of the most notable and successful adaptations of VistA health information systems. RPMS is a decentralized, conglomerate application composed of 60 plus applications fitted to work independently or in unison. The software modules can be broken up into three main categories: 1) Practice management applications that consist of patient registration, billing, scheduling, etc., 2) Clinical applications that directly support health care planning, delivery, management, and research, and 3) Infrastructure applications that consists of the management, development and communication tools of RPMS. Our main focus will be on the infrastructure of RPMS by utilizing the tools associated with it, including VA's Kernel package manager system, and the all important VA's FileMan as RPMS's database management system.

Problem: 
Currently hospitals and clinics pay millions (in Hawaii $20-50 million) just to implement a commercial enterprise medical health record software. What can we do to reduce the cost and increase support for our hospital clients? Also, developing GUI tools for medical health record systems require prior knowledge of old languages like MUMPS or clunky looking GUI's for reporting patient data built in Delphi. How can we increase the support and ease the pain for future developers planning to write Electronic Health Record systems (EHR) but have to adapt to decades of tradition?

Solution and Goal:

Amongst the various tools and applications written for RPMS, there is one with the sole purpose to communicate to a level of .Net supportive applications. This component is called BMXNET. BMXNET is a .Net specialty tool that provides disconnected row set technology for linking .Net applications with RPMS. This built in library gives the ability to communicate with RPMS by simple query statements (SQL data definition language) to access patient records and returns them in a familiar .Net data structure. So with that fact in mind, why don't we build a component that utilizes BMXNET to support multiple runtime engines such as Mono and Java. By doing this we will improve the interoperability of development platforms and give developers a greater range of environments to develop GUIs for EHR systems. Simply, no more looking at dirty, old 60's code written MUMPS. Let's eliminate the thousand lines of code that you know can be done better in another language more comfortable to you as a developer and meets todays expectations of Object Oriented Programming. This will also save hospitals millions in costs for purchasing the EHR software (plus tech support) and hopefully create a more aware community of open source developers for bettering the health care industry.

The next step:

In the past week, I've had the chance to dive into two documents regarding the setup and running of BMXNet. These user, technical/developer guides can be found directly from IHS's home site here. The user guide helps first time developers new to BMXNET get started in using the classes of ADO.NET and integrate them with BMXNET (now .NET 2.0 framework supportive) technologies, while the technical guide gives the infrastructure of BMXNET. I will begin within the next few days by rolling out a test/development server for installs of RPMS and GT.M's compiler for the standard M (MUMPS) language. Hopefully by then I'll be able to communicate from a .NET application (written in C#) to RPMS via BMXNET. The next steps will be to figure out a way to translate these exchangeable commands to be consumed by another runtime engine besides C# and the .NET environment platform (the conversion and eventual goal). At this point, Mono seems to be the easiest but we can't rule out that its fully .NET compatible since it merely provides a portal for Windows .NET applications to be ran in Linux.

Devcathlon Code Reviews

Premise:

In this blog entry I'll be reviewing three code bases (including my own) for the mock up implementation of our game project, called Devcathlon. In the following reviews, I will pin-point the good and the bad of each code base and hopefully that will give certain insight into future designs for this project. Although not all issues will be addressed, I will certainly mention ones from my experiences in building these mock ups and my understanding of the game.

The Reviews:

I will try to section off each review with the following outline:

Functionality and Features:

• Can the user login?
• Does the user have the ability to create or edit form elements, such as personal, team or team member information?
• Is there a way to create event matches between two or more teams?
• Is it possible to make record of or reputable proof of pair programming?
• Are the points properly assessed and clear?

Aesthetics:

• Did they embed useful technologies, such as Javascript, CSS or XML? (also including external widgets or libraries)
• Are the points nicely displayed and easy to the human eye?
• Does the user interface (UI) make effective use of screen real estate?
• Does the user interface provide a logical structure? Is the organization consistent from page to page, or do different pages have completely different layout.

Ease and seamless:

• Does the user interface enable the user to accomplish common Devcathlon tasks efficiently? How many "clicks" does it take to accomplish common tasks? Is the information you need to accomplish a task available on the screen?

• Do the data input mechanisms facilitate correct entry? For example, if a date is required, does the UI provide a calendar widget, or does it require the user to type the date in as text?

Overall summation:

• Does all the above information give the website cohesive enjoyment of a game? Also, does the website leave room for possibilities outside of its initial domain?

Mock up 4:

Mock up 4 was certainly a round up of many things experimental. It worked out like a sandbox for possible fun changes and re-works of existing features. I, along with two other members had a personal involvement in this implementation of Devcathlon's mock up 4. We based our implementation off of the unique design employed by one of our members' previous mock ups. This initial mock up had everything needed, including drop-down menus and an overall social network-like feel for design. In many aspects, the implementation in its "mock up" stages felt almost like a real world web 2.0 website.

Functionality and Features:

Mock up 4 has all the features expected for any website. It has a login and sign up page, home page for introductions, and help pages for hints and usages. It also strengthens its features by utilizing its fully expandable drop-down menus, making it easier to navigate through the site and finding its subsequent pages. Along with signing up for an account with the website, this mock up enables reusable forms for creating/editing a user's personal, team, project or match information. Upon logging into the site with proper authentication fields (login and password), the user is presented a welcome screen and their common functions, including links to the user's public/private profile, a team, match creation page, match invites, self-report requests, and site-wide announcements beneath it all. The public/private profile page provides an abundant set of information about a user and their involvements in teams, projects, and matches. This profile page is the center of every Devcathlon user's life. It provides information on the user's standing (system wide rank), recent achievements and matches, currently associated teams and ability to post/reply to comments underneath. To the right of all of that, the user is given email notifications in a personal inbox. This functionality of an inbox is still debatable amongst other designers, but it is a feature that has no bounds for possibilities. The only reason to include a personal inbox for Devcathlon is to provide convenience to the user, but hinders the fact that the information is repetitive and can sometimes be annoying if a person sees it both in their email and upon logging in. Also, beneath that is a list of the possible actions the user can take for interacting with Devcathlon (similar to the welcome page: create team, match, self report, etc.). The forms are in fact very reusable and encompasses the full gist of user interaction within Devcathlon. So it is important to get these forms to seem quick and convenient for the user. All the action links mentioned early will be representing in a form field-set fashion. For the team creation page, a user is able to search for existing teams, other members and projects. The parameters for the team creation page includes all relevant text to get the user started, including the team name, team type (appropriating members relations by organization, friends, etc.), team project definition, and an about section. Although this page needs more work in functionality, the intent is quite clear that we would want a dynamic page rendering both a search for existing teams, members and projects, and the ability to create a fresh new team on-the-fly. The match creation page also provides a comprehensive coverage of all required inputs for creating a match. It intelligently populates a drop-down of options including all your team and project involvements. There is a section to invite teams, but it doesn't follow the organizational structure of rendering a search for existing teams. In actuality it has a text area box for text input separating each team name with a semicolon. I feel that this is a bit ineffective and inconsistent with the team creation page which included the search. Other parameters for the match include the time period of the match (start and end dates), minimal score settings for commits, builds, and test coverage (which can be expanded for more customizable settings). Self-report request is another debatable matter that needs further nurturing for full acceptability in our game. However, in mock up 4, we dealt with this problem by asking the user to provide a brief description and picture for proof of the project being worked on. A neat product of this is that you can challenge other teams for self-reporting, as well as submit your own for pending assessments. This idea still needs valuable time to test in order to resolve issues involving point assignments and ethic values (the integrity of the feature to no be used to ones advantage through malicious means). The last action is for accepting or declining match offerings. This accept/decline match page provides a quick summary of the match for the team member who chooses to "accept" or "decline." Now, moving along the top navigation bar, a user is also able browse Devcathlon user profiles. This is another iteration of the technique in utilizing some kind of search for our persistent display of records. This will provide better "coverage" in linking our site together by means of relations and/or associations. Each page, including the gallery, match, team, or hall of fame features areas for knowledgeable information of awarded/deducted points of a team and its members.

Aesthetics:

Admittedly, this is the most acceptable looking Devcathlon mock up from our first initial mock ups. It is evidently so, since the mock ups here on after utilize this very same CSS and navigation bar. Initially, the first thing they will see is the site's initial home page (public view). This page provides information regarding the motivation of our site and link to forms for account authentication (log in) or sign up. At this stage, the public view is quite elementary and not very elaborate in design. The layout simply has a header, a logo area, navigation bar, main content, and footer for notes. The public view also limits the information and access to certain pages of the site.

When the user signs into the website, the first thing they will notice as they hover their mouse over the navigation bar is the very responsive drop-down menus and sub-menus. The chromed-like tabs have a significant depth as you hover over it, and makes for a fairly readable and fun user interaction. The font settings are also readable and it makes some use of titling, large or small text, and bullet-points. Links are also distinguishable by underlining the link text as you hover your mouse over it. The color scheme somewhat conforms to the Hackystat look with a few tid-bits here and there. Each page uses up the real estate fairly well, by populating information where it is needed or centering the content through divs. When you navigate over to the "My Team" page, you'll notice the compactness of all teams related to the logged in user. As you hover over a team, the element is highlighted, indicating some user interaction and implying a click-able object on the page. When the user clicks on the tab it expands out listing quick information about the team and team members. The magic behind this features lies in the classes written in Javascript by Adobe's Spry Framework. This JS includes the timed effects for the collapse and expansion of each tabbed panel. The motivation behind this is to increase user focus in interaction, save real estate, and to minimize users from scrolling up and down a page too excessively.

As you navigate further, following the clickable links you will notice again the usage of this collapse and expand feature for displaying multi-formed information that's nested per person, team, and match. You might think, what if the tab panels get to be too long and excessive themselves? Yes this could happen, thus we will propose a simple anchor system for referencing page content elements (like chapters in a book). This will enable users to jump back and forth between sections of a page.

On the match page, there is a nice fight-card line-up for players to easily compare teams in a match. The only flaw behind this is the possibility of having lots and lots of teams per match. Because of this, the real estate of our page will grow out of the scope of the content and will most likely make it harder for users to navigate or compare.

Also, the rows of each table have hover interactions indicated by color changes as the user passes over the top of it.

Ease and seamless:

The overall navigation is fairly self-explanatory. Links are easily distinguishable with underlines, borders, and color highlights as the mouse hovers over the text/object. The effectiveness of each page is quite seamless and comforting for any first-time user visiting the page. Information is linked wherever the sub-pages are needed and can be previewed using the collapse/expand feature of the tabbed panels. When the user commits to viewing a certain page (eg: team or match) then there is a separate page for it as well, thus giving the content of each page enough air to breath within its subject matter.

Overall summation:

I think it is safe to say that this, and all the other mock ups have intentional room for expansion. The difficulty in saying that is in the consequence of not knowing exactly which path to take for expansion. There are multiple routes to consider and they might not all lead to extraordinary UI's.

**Please note that a lot of the analysis in the first mock up will carry similar descriptions in both mock ups 5 and 6. Thus they will be shorter, and will only expresses dissimilar features from the first.

Mock up 5:

Functionality and Features:

When browsing over to the "My Matches" page under "My Profile" there is a clear list of all matches associated to the user. The listing also indicated which match is currently marked "active" or "complete." After clicking on a match for extended details, you'll also notice a nifty table showing all recent points. On the same page, if you click on "see details" then it will display a history of all points between each team in the match. It also gives a time stamp of each event and its corresponding points gained or deducted.
Aesthetics:

All lot of the CSS and page layouts were fairly similar to the previous mock up.

Ease and seamless:

The links were very clear and simple to follow.
Overall summation:

The history of points received for each match and team is a great feature and must be incorporated in a similar fashion for our future Devcathlon game.

Mock up 6:
Functionality and Features:

Mock up 6 employs a very strict set of levels for player achievements. The level definitions follow a military standard of badge ranks.

Another unique feature lies in the "My Matches" page. This page includes history listings with weekly reports of team accumulated points. This could prove to be a better way than simply listing a full history and time stamp of each consecutive event in one long table. We could break things up in the weeks and months depending on the elapse of the project and its total project life span.

Overall summation:

Mock up 6 also made an attempt to explore the possibilities of integrating Devcathlon with Hackystat. This idea seems great, yet it takes away the pure independence of this game. By placing Devcathlon as just a tab in Hackystat, then we are confined within the territories of Hackystat. On the flip side, the concept of using the data records of Hackystat should be supported for our application. I think that by reusing the account information supplied in Hackystat, we can possibly pre-populate the team and project definitions automatically for our Devcathlon players.

UI Suggestions:
Provided the three mock ups, I will make some recommendations regarding the design and function of Devcathlon. I will base my design off of my own Mock up 4. All of my previous comments will still apply. The only thing that still bothers me is the fact that pair programming is in all difficult to track due to consequent ethics of the game. To solve this issue of pair programming, I would like to implement a system of discussions per code event or issue. This will be recorded by our google discussion board (created for Devcathlon projects or teams) and assessed either amongst group members or members of another team. So by following good programming practices, every programmer is required to code on part of a particular issue or task. If the user confines to those guidelines as they are assigned to them by the team, then the user is considered "on task," otherwise "not on task" (for point deductions). Other than the issue raised about pair programming, the design patterns in Mock up 4 makes for a good starting point for our future implementations regarding UI's. One thing that lacked from Mock up 4 was a system for levels. We had an idea of using human evolution as a way to advance or mature a player, but it has hidden implications that might offend a few people. Because of this concern, I would consider Mock up 6's standard for leveling a player through military ranks. It sounds more formal, yet it gets to the point and seems to feel more natural. Another neat detail given in Mock up 6 is the way of sectioning timed events by months, weeks, and days. This way, we can store and retrieve our data records more easily in these timed archives. The idea is very similar to how Blogger organizes each blog post by month, year and/or by subject.

Conclusion:

I'm still tempted to say that the overall enjoyment of the game is still up in the air, since there are still little interactions between players and possibly gameplay. Plus, this observation is only from my perspective of creating these mock ups. Perhaps, getting into the game and actually experiencing the behavior of each functional feature will give better rise to the actual game as oppose to just pure speculation.

--

Resources:

Mock up code bases: http://code.google.com/p/hackystat-ui-devcathlon/

Monitor code changes: http://code.google.com/p/hackystat-ui-devcathlon/source/list

Devcathlon Mockup Part 2

Premise:
In continuation of the previous two blog entries regarding Devcathlon, I will again review my experiences and concerns in this second part iteration of Devcathlon's mock up site. I will also briefly mention additions to our events list, the concept of "badges", and levels.

Designer <=> Developer:
This is my second iteration of mocking up the interface design for Devcathlon's site. I noticed that the first mock up proved to be a challenge since it used to be easier to just pass the design stuff over to a professional designer, and not have to worry about it. This kept the designing and coding schema separate and provided production boosts (through specialization) for the overall project. However, in these past two mock ups I was able to wear both hats of being a developer and designer. First and foremost, CSS is a prevalent skill. I say this with confidence, because any markup text in this day and age requires the usage of CSS. Do whatever you can to muster the basics of elements, tags, descendants, etc. CSS will be heavily used in your HTML and it's a proven to simplify a lot of styling out of your markup (keeping HTML basically what its good for, which is rendering text and links). I think the terms of a "developer" or "designer" can be interchanged and used similarly in certain situations. Considering the objective, problem or solution, either a designer or developer will look at it in terms that are not all that distinct. When a programmer programs, he or she technically has to "design" themes from real world entities that can be classified as classes (in OOP languages today). Even though when the programmer thinks that he's "programming," in fact, he's actually designing before even writing a single line of code. On the other side of the coin, designers are faced with the fact of creating something usable, appealing to a user, and seem less. So, designers simply create GUIs in the front-end of the spectrum, yet they transmit some work flow details of a user. The work flow of a user is the interesting part of being a designer. At the stage of getting the "look" down, a designer must also take into consideration for the "feel" of what they are building (eg: buttons, links, forms, etc.). These interactions are crucial and play a large part in the functionality and behavior of a site.

"Eventful" Additions:
My team and I came up with two other simple events regarding the basic units of building and coverage. A team member can build to success or failure depending on circumstances of frequency and trend relations. If a person builds frequently, and does so over a certain period of time without significant changes to the code, then that person gets penalized for "unnecessary building" (vice-versa). The other concept deals with the almighty relation between writing test code and coverage. Instead of just looking for an increase or decrease in the level or percent of coverage, we will also include the relational trend of the graph. Some relational dependencies to this event include: early test cases and incremental coverage gains. The trend (provided by Hackystat) should help in determining early built test cases for basic class or method functionality. From there on, we detect any fragments of change in coverage (gains or loss). If the user continues following the good practice of writing his tests before integrating the app any further (test driven development), then he'll benefit in the long run of the game. As for those who don't change much in coverage and remain stagnant throughout will suffer penalties.
The concept of "badges" is not a new topic, but it has been highly mentioned when dealing with determining valuable players in the game or team. Badges are awards (almost like mini trophies) given out to individual players who achieve certain number of plus points.
Another concept was the idea of "levels" for a player or team to achieve a certain number of points to advance. A player or team can advance to levels through a system of recognized achievements. Just to add some kicks and giggles, we followed the concept of human evolution with imposed implications of software engineering as the end point of the time line.

The code and other resource materials can be found here: http://code.google.com/p/hackystat-ui-devcathlon/

Devcathlon site mockup

Overview:
This past week my group and I were tasked with mocking up the general features of our game, called Devcathlon. To learn more about Devcathlon, please read the blog post prior to this one or head on over to http://code.google.com/p/hackystat-ui-devcathlon/.

Planning:
Generally, I approached the mock up of Devcathlon like any other website. The parts that go into a website are apparent and can be easily modeled by notable ones like Google, Blogger, or Facebook. It seems to be a must, in today's standards of Web 2.0 to have Ajax functionality and dynamic webpage access and retrieval. Unfortunately, our mockup didn't express those characteristics physically, but the idea is still quite enforced. I thought of the application as more of a social website. So the basis of this application is very much that, it had to be socially adept and capable of growing. Users should be able to communicate with others in a personal or public matter depending on what the situation calls for. Designing the structure of the site wasn't very specific, but it had to be standardized. We simply broke the site into two parts, the public and private domains. The public section of our site is a simple "tour" for any outside user who is willing or just curious to explore our site without a direct account. Of course, for any alien who comes near our site, we restrict them access to certain elements or retract any links that only should be seen by registered users.

Site work flow:

* Public user enters site's home page. He or she is prompted for a login/password.
* User enters a valid login/password, then gets redirected to his or her's profile page.
* The logged in user is able to edit their profile as they please, add/remove/update teams and matches.
* Registered user could also search and associate with existing teams or matches.
* Every user is provided a personal and public profile.
* When a match is declared then it is marked as a user event and should message the user under their recent activities.
* When a user gets prompted by an administrator, then that information is displayed under notifications.

Besides dealing with site administrative tasks, such as creating a user account and modifying profile settings, we also focused on important questions dealing with how the game should work. One idea that I posed (as mentioned in my previous entry) is to possess every user/player the ability to create stories/tasks for themselves as the project/game progresses to a goal/objective. Creating these special “stories” is another way of saying a developer creates an issue on an issue tracking system (Google Project Hosting). Upon generating these stories, other players can either interact or discuss (Google’s issue discussion groups) about a particular subject and trade off ideas through post entries. This way players will interact with other players and thus resolve some obtainable “mini” goals. Mini goals can also be known as a milestones or phases in a project development (stages or levels in games) that give players awarded advances and points for their achievement. All of these aspects are simply ideas, but we have yet to encounter the facts of reality in creating such a world for them to exist in. Hopefully in our next increment of this project, we will dive into those concerns in more detail.

Conclusion:

Mocking an entire website from scratch is particularly difficult since website designers need to anticipate every move. Every form built was either doodled out or envisioned multiple times before getting it right. Most likely changes will be made after the mock up, so I wouldn’t be surprise that we would keep or discard certain elements from the current design. Unfortunately, the only regret I had during this process of mocking was the lack of “mock tools.” I wish we had more open source mock-supported development tools for web development. Maybe they won’t reach the same standards such as high competing tools from Adobe’s Creative Suite, but we need to start somewhere to ease the process.

What's in a game?

Overview:
In this brief blog entry, I'll explain the concepts of game designing and utilize these tactics to enable a better understanding of my new venture into a project called Devcathlon.

About Devcathlon
Devcathlon is a computer game designed to help improve software development and developers while rating the health of their project. The players include the developers, tech managers, etc, game pieces include the code, quality assurance (QA) tools, etc. Continuous integration is a software engineering practice to help teams speed up their implementation and expected delivery date by providing automation of redundant tasks (such as building code, QA builds, maintaining a code repository, etc.). The concept of the game is derived from a collection of continuous integration practices that should be second nature to most software engineers/developers. The goal of this game is to provide an educational way of keeping a developer on task with such practices. Once the developer sees that the game is not just a way of racking up points and envelop in certain bragging rights, but it also fuels the notion that you are really just competing with yourselves. The self-improvement of an individual will contribute to the overall success and health of a project.

So far, we understand the motivation of the game we are trying to create, but we have yet to capture the attention of what a game really is and how to go about from creating a successful one.

Designing a game
What's in a game? What is the effective game design? The methodology behind the creation of a game is undoubtedly its high standards in the designing process. Let's first define the meaning of a game and the essence of a computer game. A game is basically a contest of rules designed to have multiple players making strategic decisions to achieve a specific outcome (winning). In computer games, the definition is not all that different, it is a software program in which one or more players make decisions through the control of game objects and resources, in pursuit of a goal. The make-ups of a game is fairly simple, yet the complexities lie in the makings of the game. Every computer game consists of players that interact with or against each other to obtain or reach an objective/goal. The players provide a variety in a game. Each player has a personality and it shows as they make decisions in the game. Another resource that's prevalent in this game is the game objects. Game objects or resources are the tools that equip a player in the game. These objects are either given or obtained as the process of the game continues. Every game needs an obtainable goal and objectives leading up the climatic conclusion of a game. The interesting part about the goal of our project is that it is fairly non-aesthetic, very virtual, because it is meant to educate a developer and his team. That is the higher logic of our goal, yet it sets apart from the "mini" goals needed to achieve a higher standing in the game. In a competitive thinking process, you are trying to out think your opponents, and gain an edge in winning the game. In our situation, getting an edge is a matter of how motivated you are to keep up with tasks relating to your development environment. Some questions would be: Is the user doing daily builds like he should?, or Did he make his 1 of three commits for the week?, etc. Is it possible to have a competitive edge in our game without tiring the player? Can we relieve a team by rewarding them for good behavior? In every good game, there is a matter of aptitude decision making on the part of the player. They make decisions to either square against a demon from hell or choose to run away and find shelter to level up. These questions are posed to the player and in relation to the outcome of the game. How will decision making be incorporated with our game? What will we need to give developers a crux in the game where they would have to choose routes? Another matter is the dealing of balance in a game. For example as players play the game, they are ranked on the games scoring report, and from that we rank #1 as the winner of the game. But in our situation ranks are not set, in that I mean there will be times when other development teams who play Devcathlon will have a succeeding or lost for one day. So to say that balance is in the game, then we have achieve at least that much in the process of effective game designing. The other hot topic goal of gaming is the feeling that the player feels mentally "immersed" in the game. Every successful game gives us that feeling of importance for a character and its relation to its environment. As players become more involved to the grounds of what they are trying to achieve, then the soul purpose of the game becomes more apparent.

Conclusion:
When it comes to creating a game then every detailed manner has to be addressed clearly and reasonably. The design process is a key aspect in developing a coherent game. The pieces and the overall concept or objective is primary to when drawing an audience of players. Once a developer has a product concept in mind, the next part is to involve drilling into the details of each subset piece of the game, then analyzing how each piece will integrate with each other as a whole.

Open issues and ideas for Devcathlon
One of my main concerns is regarding the blind processing of pair programming. How will this issue be dealt with? We can probably create options for pair programming and delegate points depending on the difficulty of tasks (changes via code base) and number of participating members. Another interesting topic not mentioned heavily above is the concept of artificial intelligence. Possibly in a more stylized situation will we need such a component where the computer itself will challenge our players rather than just having our players go against themselves. However, one situation would be to supply a "tutorial" of Devcathlon to simulate a good, bad, and okay development project environment given a default sample program event. The process will detail the scoring and correct moves to be successful in the scoring high in the game. Player interaction with other players are somewhat limited to the design of Devcathlon. Possibly communication is dealt with elsewhere from the system, but there is no good way of knowing that. One way to solve this is to have conversational story boards, where each developer is required to write a "story" before hand, to describe his/her intention in a very technical manner (using bullets etc.). Each story will be in conjunction of a task (provided by issue tracking). For every story there is a twist, given exceptions where the story teller doesn't know the ending. So another team member jumps into provide a more complete "ending" to the story. These interactions will be mapped out via issues and marked as "dependent on" another issue number. We can score a project on their effectiveness of communicating with each other and issue management! Of course, this is only a very rough draft of what's to come. Hopefully when our development team gets into the nuts and bolts of this project, only then will we know exactly what is effective or not.


Resources:
http://code.google.com/p/hackystat-ui-devcathlon/wiki/References

Other resources:
The Art of Computer Game Design by: Chris Crawford
http://tinyurl.com/dmug

This online book explains the artistry of creating a game. Although the time period of which this book was written seems old, I have to still consider this a good starting point for any game developer or gamer to grasp. The thing that drew my attention the most was that it provided history about the evolution of gaming and the growth of the gaming industry and users. He starts out giving a good two chapters worth of information about what a game really is and different gaming genres. The author also speaks about the future of gaming and its implications on our world's society. He also addresses many predictions that are very true in our community today. The book also describes the game design sequence which lays out a general sense of what computer game developers can do. The author merely presents his generalizations and habits as suggestions rather than a strict set of processes which readers will find very coping.

A Primer for the Design Process, Part 1
http://gamasutra.com/features/20000630/huntsman_01.htm

This interesting, yet incomplete article dives into the concerns of gaming and the market as to inter-relating things. It follows a more business approach for real world game developers, and makes you pose questions prior to implementing your game. The article serves as a simple planner for effective game designing in the pre-production stages.

Gamasutra
http://gamasutra.com/

Good place to learn and contribute the gaming community.

Java Game Development
http://www.gamedev.net/reference/programming/features/javagame1/

Describes the technical details of creating a full-fledged game using Java as the platform for development.

GameDev.net
http://www.gamedev.net

Is yet another great place to attribute the philosophy of game designing and further education of games.

DueDates 2.0 Wicket App

Premise:
We've been working on the project DueDates since the early month of October. Since then I've had my eye set to get to this stage of our application. I'm excited to say the least that this application has just achieved status as a genuine web application. In this 2.0 release of DueDates, it has been re-factored many times, re-designed for expandability, and fixed to interact more effectively. I'll explain the process that brought us to this point in our application and what features you'll find different from previous increments of DueDates.

Project's page: DueDates-polu
Group Members:
John Ancheta,
Anthony Du,
Yasu Kaneshige,
Erin Kim

Process:
I sometimes have to remind myself that the process is just as (or even sometimes more) important than the end result. It is especially applicable in group projects such as these. I'm proud to say that this time around I was grouped with some very strong and talented individuals. By being surrounded with this kind of environment, I felt that the knowledge sharing was much more of a solid ritual rather than an obligation. It was easy to get in touch with one another and no one felt left out. Everyone had an equal set of tasks, and we frequently spoke outside of class about the project. I also felt a sense of security, since we started very early on in this project. It felt great since the project had fresh new faces and ideas regarding the application. It was easier to communicate our ideas and worries effectively since we chatted on Google talk and Gmail (thank you Google!). So we often sat around the camp fire and discussed about which tasks needed to be done and accomplished, and for which days they needed to be integrated. We followed the concept of working fast to get things done to achieve functionality, and save room for later enhancements. I have to admit that we didn't follow the agile approach of Test-Driven Development, but eventually our testing and coverage caught up to us. It was inevitable that testing was a key aspect, but we kept it in the shadows for awhile since we were predicting a quick end-time for this application. Practically the first week was pushing to finish all required tasks needed for this web app. We did so, since we all wanted an enjoyable Thanksgiving holiday. As the days progress, there on after we kept on improving the look and feel of the application, little by little we also added new features and stripped out unnecessary pieces to enable a more defined product.

Setting goals:
One of our group members made a very nice calendar describing our jobs during the span of two weeks. This made it easier to see what we had planned ahead of time and what things were tasked to who. The breakdown of the project was very clear. Each set of tasks were derived from these milestones:
R1) Support an XML configuration file.
R2) Basic DueDates functionality
R3) Basic DueDates functionality w/ CSS.
R4) Provide sorting
R5) Filtering
R6) Email Alerts
Since we have an even group of 4, it was easier to just have two pairs working on a couple of milestones. Although the pairs were established, we still looked to each others skills to accomplish certain tasks that were related. I had the pleasure to work on R1, R2, & R4. Possibly the coolest thing out of this whole project is just the idea of building a web application using Wicket. Initially we imported a previous project DueDates-blue-v1.2 as our base code, but many aspects in the design needed to change in order to suit the needs of building a Wicket application. More things needed to be added, but basic functions enabling the features were pretty much solid. It was safe to say that we almost had everything needed to finish this application. We simply needed to provide a GUI for what we had previously built in DueDates-v1.2! The online Wicket example apps and Wicket API was a good place to absorb knowledge and derive simple practices for common tasks. I enjoyed looking at the API as a resource guide to understanding the structure and formation of components/models/markup. Soon after assimilating the facts and concepts, the transition from novice Wicket developer to intermediate Wicket developer was easy.

Layout:

• Index page - contains the user login prompt.
• Home page - contains the listings and the core purpose of the application.
• Alerts Preference page - contains a set of options to enable a user to set alert processes.
  

Features:

• Currently we support user authentication in a localized setting for users. In later enhancements, we will start looking into creating a database back-end using Derby's Embedded/Network Server engines which will require the user to register upon first visiting the page.
• Support libraries, including: University of Hawaii @ Manoa Library & Hawaii State Library.
• Customizable alerts and options to filter results of due dates listing. Background processing is another topic that would enhance our alert system.
  
• Capable of retrieving and updating multiple libraries at once.
• Easy navigation links.
  

ICU of our project:
I can't rule out that our project was properly assessed by Hackystat. We each had problems with it not sensing our data, or not reading our number of commits, builds, etc. Overall, the data does somewhat describeseach individual's participation in a fairly accurate manner. Currently it's the closest thing we have to gain statistical evidence about the health of a project and its affecting members.

Conclusion:
Everyday meant progress, someone was either working on the css, the html simultaneously, or spicing up a functionality for a page. We each had a hand in the making of this application. I'm very proud to say that I could be a part of it. Although we didn't successfully pull off the database back-end or background-processing, I hope that we'll revisit them sometime in the near future. As for now, the application is in good shape for general use.

Resources:
DueDates Project Page: http://code.google.com/p/duedates-polu/
User's guide: http://code.google.com/p/duedates-polu/wiki/UsersGuideWiki
Developer's guide: http://code.google.com/p/duedates-polu/wiki/DeveloperGuide

Other Resources:
Hackystat Project Page: http://code.google.com/p/hackystat/
Apache's Derby Home Page: http://db.apache.org/derby/