Taking a break and gsoc 2009

As the name tells, I took a break during spring break. =P

Ideas of Google Summer of Code

In the last meeting with Philip, he provides me an idea of utilizing Issues data into Hackystat, from the bottom of collecting and sending data to the top in Software ICU analysis. In the middle there are an associated DPD analysis and a set of Telemetry analyses. The Issues data is an essential sign of health of project management, but long missed in Hackystat version 8. Additionally, this is a good chance to work all through the system, which I did not experience yet. This proposal contains enough work for 3 months, so I used this idea in my application to GSoC 2009.

Before that, I have another idea: provide a facilitating way to deploy service of Hackystat. The first part is easy way to deploy sensorbase upon various database implementation. Currently, users have to implement the interface in Java code by themselves and complie the system. I want to find a way to separate the database access part into a standalone componenet that user did not have to complie sensorbase everytime there is update of sensorbase. The database access component requires much less update in functionality than sensorbase, thus less, if any expect bug fix, update/recomplie required. I may also do the implementation for some popluar database such as MySQL, IBM DB2, Oracle and MS SQL Server. The second part is an administration tool to lauch Hackystat service such as sensorbase, dpd, telemetry and projectbrowser. It provides GUI to configure settings, and capability to hide the command-line windows, make Hackystat runs in backgroud like most system services do. I did not familiar with either database implementation nor GUI configuration building. Thus estismated work is unknown for me. I expect more time in research that coding to accomplish this.

Revise my thesis

State of manual report tool

The manual report tool is finished for basic but complete functionality. The UI is similar with the figures post before, except that the "Labels" field is removed and labels is expected to input in "Resource" field. This is actually the way to construct the resource field in sensor data. Making it this way makes user less confused when they see their "labels" shown in the resource field in history panel.

As discussed before, history panel manipulate sensor data piece by piece, no grouping function is provided.

Revise my master thesis

I start revising my thesis from the "portfolio" version to a "software ICU" version. The introduction is being totally rewritten to introduce the idea from different angle. I am reviewing recent tech-reports about Hackystat and software ICU, which including 09-02, 09-03 and 09-07 to get ideas of the start point.

Most of other parts, such as the related work section, can remain the same.

Self-report tool is ready

After a little talk to Philip, I realize that showing the raw sensor data may even better than grouping them into events, because in that way we can give user more control over their data. The initial motivation of add that "event management" feature is in case of editing data. However, for the near goal, we will not provide the editing feature in the manage panel. If user think there is error in their input, just delete the data and resend it again. When managing the raw data, there is a possible trick to shorten the time by delete some of the data. The other reason I wanted that grouping feature is trying to make sure users will correctly delete their data, not leave unexpected data in sensorbase. However, in either way, users have to take responsibility to their data. The additional feature will not ensure they will make less mistake than without it. In contract, if the additional is less robust than it appear, users might pay less attention to their data's completeness than they will do with raw data, which may lead to more defect data. Therefore, after this second thought, I decide to leave the responsibility of the data's completeness back to the owners before a powerful and reliable enough manager exists.

Plan for this week is to finish the self-report tool. Everything is ready actually, just need more test of sending out data. After that, thesis!

More analysis on log data

Accomplish of last week
1. Tech-report of Hackystat evaluation 2008 is revised. More analyses of data on per student bias are added in order to gain further insight into the logged and survey data. It is interesting to find that some students' responses are far from their reality: the use frequencies they claimed are much lower than the actual frequencies logged by the system. Though it is hard to verify if the error is intended or not, it does reveal some interesting point from their answers to other question: those students are the ones who concerned with sharing their data, especially DevTime and Commit. It is reasonable to infer that they were not happy with the data showing their laziness to their teammates.

2. All functionality for initial release of the self-report tool is complete. Currently the application takes a time period denoted by start and end time, resource file, tools and label to generate the DevTime data. The UI is shown below.
Also the application is capable to manage the data you sent. It is able to retrieve data in a given data, filter the data to a given tool if available, show it on a table, and allow user to delete data from it. The following image shows an example of this feature. The image is captured on the experimental implementation that the data is not filter to be self-reported only, which will be implemented in actual release.
The current state of the manager is actually not quite useful, or even annoying. This is because the approach of devtime sensor data: a piece of data make a five mintes period as active devtime. So for every event that user reported, there is not a single data relative to it, instead, there are a set of data, each departed by five mintes, to present the length of the action period. When editing, these pieces of data are shown and treated as separated instance, and are deletable separately. This does kind of distrupting the concept behind the sensor data. In order to avoid this, the data should grouped by events and managed as events. This will be the next priority of this project.

Plan for this week

I have a paper presentation on Wednesday morning, that will probably take all my time till then. But after that, I can have a small break from my course work and put more time to the lab projects and my thesis. So here is the plan for this week:

1. Continue the self-report tool. It is very close to it designed funtionality now.
2. Revise my thesis.

Presentation Finished!

The biggest this for me last week is the presentation of my thesis project on seminar course. My slides can be found here. It was the biggest presentation I ever made and make me nervous to dead because I did not get much time to practice the talk. Fortunately it came out to be a successful one. I was planning to revise my thesis before start preparing the presentation but I found I was running out of time. So the thesis is still untouched yet. As discuss with Philip and Robert, my presentation did not include enough information about the evaluation result. I was thinking adding more to the slide but the result is too literal and long that it is hard to summarize good with a few slides. And insufficient analyze of the logging data is another reason of this difficulty. From Philip's inspiration, I started making more analysis charts over the data and they do reveal some additional information. They will soon be added to the evaluation tech-report.

Plan for this week:

1. Finish further analysis of the data and add the new result to the evaluation tech-report.
2. Finish the first release of self-report sensor. The remain thing for initial release is the ability to delete self-reported data. This is most involved with displaying an inner data object with JTable.
3. Revise my thesis. It is long postponed and should be caught up sooner. I still want to finish the thesis before submission deadline in order to keep the initiative of my graduation.