The preceding sections of this chapter presented various ways to measure process and product attributes of Java and Ant-based software development, and send that data to a Hackystat server.
The remaining sections of this chapter will focus on what you might do with your process and product data after it is sent to the Hackystat server. This section illustrates an important initial step: identifying which sensor data is actually associated with the StackyHack software system. Hackystat assumes that software developers work on more than one software projects at the same time, and thus there must be a way to organize the streams of sensor data being sent to the server.
Associating sensor data with a particular system consists of two steps: defining a "Workspace Root" that specifies the parent directory of the directory where your project files live, and defining a "Project" that specifies who is working on the software system and a time period of development to be associated with the Project.
In the example use of StackyHack data collection shown above, the system files were located in the directory called "c:\svn-csdl\StackyHack". The first step in enabling the Hackystat server to identify which sensor data should be associated with the StackyHack system is to define "c:\svn-csdl" as a Workspace Root. To do this, I logged in to the Hackystat server, brought up the Preferences page, and moved the "c:\svn-csdl" from the "Workspace" column to the "Workspace Roots" column, as illustrated in Figure 4.30, “ A section of the Preferences page showing the Workspace Root Config command ”.
Of course, if you are doing this locally, you will need to specify some other directory as your Workspace root. For example, if you have downloaded the StackyHack system into /usr/local/home/johnson/projects/stackyhack-7.4.314, then you would find the workspace named "/usr/local/home/johnson/projects" in the workspace column, select it, and click the link to move it into the Workspace Roots column.
Once the workspace root is set, any workspaces that began with that root have this prefix stripped from their name. Thus, "StackyHack" (or "stackyhack-7.3.313") will now appear as a workspace.
Now that the workspace root is correctly, it is a simple matter to define a Hackystat Project for StackyHack.
Figure 4.31, “ The Project definition for StackyHack ” illustrates the Project definition page after the StackyHack data has been filled in. As you can see, the StackyHack project contains just one member (johnson@hawaii.edu) and one workspace (StackyHack). If you are using a released version of StackyHack, your StackyHack workspace will include a version number, such as "stackyhack-7.3.313").
One of the goals of Hackystat is to allow Project definitions that can aggregate together sensor data collected from different people. This is one of the motivations for the "Workspace Root" concept. As you can see, the Project definition allows you to specify one or more workspaces whose sensor data should be included in the Project. In this case, the workspace is "StackyHack". The Workspace Root representation allows two users to place the StackyHack project directory in different areas of their file system, yet enable the Hackystat server to understand that their sensor data refers to a common system. For example, it allows two smith@hawaii.edu to keep the StackyHack system in c:\svn-csdl\StackyHack, and jones@hawaii.edu to keep the StackyHack system in /usr/home/jones/project/StackyHack, and then define a Project with these users as members and the single workspace "StackyHack".
![]() | Note |
|---|---|
For simplicity, each Hackystat server maintains a "global namespace" of Project names, where duplicates are not allowed. What this means is that if one user on a server has defined a Project named "StackyHack", then no other user can use that Project name. In this case, the Project definition page will indicate that the name is already taken when you attempt to define it. If this happens to you, simply try a new Project name, such as "StackyHack-YourNameHere". | |