Final Summary of GSoC 2009

As the fall semester 2009 begins, the GSoC 2009 goes to an end. During it I again successfully complete the project to the excepted goal.

At the beginning of the project, problems of the Issue sensor and its data structure design draw me quite back from the original schedule. However, after I settle it down, the further process become amazingly smooth. It took me like 2~3 weeks to finish Issue DailyProjectData analysis, and another week for Telemetry, and, several minutes to put it into Software ICU! I again experience how a well designed extensible system can boost new developments upon it. Though I am the main developer of the Software ICU, I really have not much to do in previous development of DPD and Telemetry, so it is not my previous experience lead to the boost development.

To add Issue analysis to Software ICU only involves editing a single configuration XML file(I was adding to the default configuration, but it is OK to add to your own configuration, if the developer did not upgrade the code in time =P). The main thing to newcomer may be to find out which file to edit and where it is. I just found that there is no documentation about it on hackystat-ui-wicket. I will add it in soon. Another maybe issue is that, none of the current stream classifier looks to fit the conception of Issue analysis. On the other hand, I do not yet have clear idea of how the Issue stream should be indicate the performance of developers. This can be one of the future study of Issue analysis.

In conclusion, last year, I followed the path of extensible system design to build the system. This year, I experience the benefit of building a system that way, and I am so thankful that we have done it that way. I am pretty sure this will be the way I keep following from now.

Almost done in summer project

Till today, Telemetry analysis of Issue, and the Issue DailyProjectData page in Project Browser is finished. As the way Telemetry service and Telemetry page in Project Browser implement, the new issue telemetry chart will just show in Project Browser and no modify needed. That means most of expected feature of summer project is done. Only thing not yet finish is put Issue analysis into Software ICU.

What I need to do now most is to put Issue sensor in use in Hackystat's hudson service, so that daily issue data will be collected. When Issue Telemetry analysis available, Software ICU can easily utilize it by modifying the configuration xml file.

We are in good shape here.

Experiencing Telemetry

Work of the past week is on development of hackystat-analysis-telemetry, to include telemetry analysis of Issue data into Hackystat system. Deal to the well constructed system as example and the sufficient documents, it is again quite straight forward to the goal. However, during coding, I found the telemetry language is kind of weird.

The language defines Telemetry Charts using some redefined language components, such as Reducers, which generate stream point value from DPD analysis, and axis. In the Chart definition, after define the name and parameters, the kernel part will look like this:

chart Issue(member, status) = {
"Issue invocations",
(IssueStream(member, status), yAxisZeroBased("Issue Count"))
};

Then we need to define the Stream called IssueStream, and after parameter description, the kernel part look like this:

streams IssueStream(member, status) = {
"Issue counts for the given mode for this Project",
Issue(member, status)
};

The definition of Streams seems redundant to me because it add no additional information to the reducer. So why not using the reducer directly in the Chart definition? I think it will be cooler that the telemetry language can directly use normal reducer like DevTime to generate the member level chart, so that no need to write in Java the member level reducer again.

Now I am coding the test cases for the Issue Telemetry analysis, need to make up Issue data again.

Finish milestone to DPD

It is a critical week of the hackystat issue project that the functionalities from issue sensor up to DailyProjectData are ready to release, along with updated documentation found in
Ant Task Reference
SensorDataTypeSpecification
DPD API

The new build of Hackystat including these feature should be release very soon. And it will be deployed in our daily hudson build to start gathering issue data.

Next setp is to implement Telemetry analysis. Then put all these things into Project Browser, including Software ICU of course.

DPD almost done

Issue analysis for DailyProjectData is almost done. The process is quite straight forward with the existed analyzes as examples. There is nothing interesting to mention in my opinion. It contains a total count of open issue on the dpd data for convenient.

When coding for DPD, I actually found some bugs in issue sensor. When testing the sensordata parser, I realize I can makeup some issue instance as CSV for testing. It should be used in tests for issue sensor as well.

Just keep working.

Moving step forward

After a week's waiting, my little MacBook Pro had come back home on Sunday safe and sound, did not lose a single piece of useful data. As soon as I got him back, I start finishing up the issue sensor to ready for commit.

After a serious consideration, I decide to discard the RSS feed as data source completely, because firstly it does not provide much more useful information than extract data from issue summary table, secondly the RSS feed service seems more unstable than the issue tracking system,which make the sensor unstable as well, and thirdly it make the code more complex and hard to validate data completeness. My opinion is, if the user really don't want to miss a single update information, just run the sensor as often as he like.

I also found it kind of hard to test the issue sensor, because it is almost impossible to have a fully controllable and repeatable test environment. The content of Google Project Hosting will keep changing. For current state, I test it by run it twice, and make sure the first run generate some issue data, and the second run did not detect any changes. The better way to exam if the sensor working properly is to actually use it. So my job this week is to work on DailyProjectData to use the issue sensordata to generate issue DPD.

Commit Early, Commit Often

I just get a painful lesson of the Commit Early, Commit Often principle. The thing is, my laptop (MacBook Pro bought at 07) died on Sunday. I brought it to Apple store and lucky I can get it fix for free, which will take 1 to 2 weeks. However, the code of the new version of issue sensor is still lying on its hard drive, and the data is not guarantee to be undamaged. That means my work for 3 weeks are gone, at least for the coming week or two. In fact, functional code is finished already. I was just waiting for completing the unit tests before commit the code. I am now so regret that I did not commit the code early.