We are doing a code review on This Wednesday (03.09.2005) at noon in POST 307.
Thanks for reviewing the code, aaron
Date: Sat, 05 Mar 2005 22:06:29 -1000
From: Aaron Kagawa <[EMAIL PROTECTED]>
Subject: [HACKYSTAT-DEV-L] Review Request 03/09/2005
Sender: Discussion list for hackystat developers <[email protected]>
To: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Greetings, folks:
This Wednesday (03.09.2005) at noon in POST 307, we will be reviewing packages from hackyPRI.
1) org.hackystat.app.pri.model.workspace
2) org.hackystat.app.pri.model.workspace.measure
I know this is a really early review announcement. But, everyone has a lot to do.. So, I figured this would help people budget their time....
----------------------------------
To perform this review:
1) Install and/or update (a) the Eclipse Jupiter plug-in and (b) The Hackystat Jupiter sensor.
2) Checkout/Update the hackyPRI module from CVS. hackyPri depends on [hackyBuild, hackyKernel, hackyReport, hackyStatistics, hackyStdExt, hackyReview, hackyTelemetry, hackyVCS, hackyDependency, hackyIssue]. Please check out any of these modules if you do not have them.
3) Select "PriModel" as the ReviewID.
----------------------------------
Please focus your attention on:
1) org.hackystat.app.pri.model.workspace.ProjectWorkspaceRanking
- more specifically: the constructor and methods: buildWorkspacePriValuesMap(), lastBuildDay(), calculateMeasure()
2) org.hackystat.app.pri.model.workspace.measure.WorkspacePriActiveTime
- more specifically: methods: getInstance(), calculate()
3) org.hackystat.app.pri.model.workspace.measure.WorkspacePriCoverage
- more specifically: methods: calculate(), getPriRank()
4) org.hackystat.app.pri.model.workspace.measure.WorkspacePriUnitTestResult
- more specifically: methods: calculate()
Background Information:
1) see the Class level javadocs for the general algorithm of the ProjectWorkspaceRanking
2) The classes in the org.hackystat.app.pri.model.workspace.measure package are PRI measure implementations. They provide PRI measures for each workspace in a project.
3) There are two different types of WorkspacePriMeasures; Aggregate and Snap-Shot. WorkspacePriActiveTime is an Aggregate measure, because I add up all the active time. WorkspacePriCoverage is a snap-shot, because I just want the latest coverage values.
----------------------------------
Here are some questions to consider:
1) org.hackystat.app.pri.model.workspace.measure.WorkspacePriUnitTestResult is giving me a lot of trouble. This measure calculates the number of successful, failed, and error unit tests for each workspace. Furthermore, it is an Aggregate measure, so it processes every day from project start to project end day. Sound pretty straight forward. The problem is that this measure takes really, really, really long to compute. There is a lot of Unit Test data and there are a lot of workspaces within hacky2004-all. Each time I call DailyProjectUnitTest.getUnitTestInfo(filePattern) with a different filePattern, the DailyProjectUnitTest reads the data from Disk. That is very, very, very slow. DailyProjectCoverage reads in all sensor data into a temporary data structure, so the lookup is fast. Is there something that I can do to the WorkspacePriUnitTestResult class? Or would I have to improve the DailyProjectUnitTest class?
2) Is the Algorithm and Architecture as configurable as possible? The system should allow future developers to Add and Remove PRI measures fairly easily.
3)
Before the Build SDT improvement I was able to obtain the number of successful builds with this line of code (in the ProjectWorkspaceRanking):
int successCount = dailyProjectBuild.getBuildInfo( "Hackystat-All" ).getSuccessCount();
After the Build SDT improvement.. the code had to be changed to:
int successCount = 0;
for (Iterator i = this .project.getMembers().iterator(); i.hasNext(); ) {
User member = (User) i.next();
if (dailyProjectBuild.getBuildInfo(member) != null ) {
List buildReports = dailyProjectBuild.getBuildInfo(member).getBuildReports();
for (Iterator j = buildReports.iterator(); j.hasNext();) {
BuildReport buildReport = (BuildReport) j.next();
if (buildReport.getContext().getConfiguration().equalsIgnoreCase( "Hackystat-All")
&& !buildReport.getResult().isBuildFailed()) {
successCount++;
}
}
}
}
Is that OK? By the way, I want to know how many times the DailyBuild occurred. Because, the DailyBuild sends all the snap-shot data (like Coverage, UnitTest, Dependency, etc). Is there a better way?
----------------------------------
If we have time, I will also be talking about this (take a look if you have time):
1) A while ago I wrote this email < http://www.mail-archive.com/hackystat-dev-l%40hawaii.edu/msg00349.html >. Please read the responses:
- Hongbing's Response < http://www.mail-archive.com/hackystat-dev-l%40hawaii.edu/msg00351.html >
- Cedric's Response < http://www.mail-archive.com/hackystat-dev-l%40hawaii.edu/msg00350.html >
- Philip's Response < http://www.mail-archive.com/hackystat-dev-l%40hawaii.edu/msg00353.html >
Thanks for reviewing the code!
Aaron
-------------------------------------------------------------
Supplemental Links and Resources:
The Hackystat Code Review Guidelines:
* http://hackydev.ics.hawaii.edu/hackyDevSite/doc/Review.html
The Elements of Hacky Style:
* http://hackydev.ics.hawaii.edu/hackyDevSite/doc/EHS.html
Jupiter Code Review Tool documentation:
* http://csdl.ics.hawaii.edu/Tools/Jupiter/Core/doc/UsersGuide.html
Hackystat Jupiter Sensor documentation:
* http://hackystat.ics.hawaii.edu/hackystat/docbook/apas15.html
