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/