--On Monday, February 27, 2006 11:03 PM -1000 Aaron Kagawa <[EMAIL PROTECTED]>
wrote:
Hey Guys,
Some questions about the sensors.
Ant Log Sensor:
I want to use the Ant Build sensor for CruiseControl builds, but I think I
tried to use
that sensor and I'm not sure if I got it working properly (I don't remember the
problems that I ran into). One idea that I had was to leverage the Ant logs that
CruiseControl creates as a data source and not have to install the Ant Build
sensor
during run time. Do you see any problems with using the Log file opposed to our
current approach? For example, can we get the same information?
Some ideas:
(1) XmlData provides an easy way to generate Build sensor data from the Ant log files.
Write an XSL transform file, and use the <style> task in Ant to input the ant build log
file and output XML containing the Build results you want to send to Hackystat.
(2) Don't necessarily give up on the Ant sensor. Let us know what problems you're having.
Maybe it would be easier for us to fix it than for you to write your own.
(3) The Build sensor data type needs to be evolved to use pMap. If that is a sticky
point for you, let me know.
One last thing. We do not have individual Hackystat accounts. Thus, server side
sensors
send data to one central account (or one account per project). I believe it is
possible to create this mapping in the usermaps, but at what cost? Would
sending this
data in this manner significantly reduce the usefulness of the data?
I'm not sure why I'm trying to stay away from individual Hackystat accounts.
This seems like a perfectly reasonable way to introduce Hackystat into an organization
without creating the fear of Big Brother. In fact, you may have stumbled upon a "best
practice" for Hackystat technology adoption. :-)
You should definitely be able to create the mapping that you need in the
usermaps.
As for the cost/utility question, my belief is that there's no cost for project-level
analyses. You do lose the ability for developers to monitor their own personal statistics
and trends, but at this point, that's probably no big deal.
JUnit Sensor:
Well, this question isn't really about the JUnit sensor; its has to do more
with the
DailyProjectUnitTest class. Like I said earlier we do not utilize client side
sensors,
thus the current DailyProjectUnitTest implementation does more harm than good
in this
situation. Basically, I do not care how many (the aggregation) unit test were
run in a
day, because it always comes from the same user (our automated build user). All
I want
to know is the number of unit test (snapshot) that were ran during the last
official
build. Well, maybe an aggregation and snap shot would be useful.
It seems to me the DailyProjectUnitTest does more good than harm. :-) What it computes
and caches is precisely what you want: the total number of unit tests run, passed, and
failed. There's basically no meaningful overhead incurred by its ability to manage
multiple users in a project.
On the other hand, as I look at the implementation of DailyProjectUnitTest, I notice the
presence of the dreaded JavaClassWorkspaceManager! One thing that will go high on the
list for post-7.3 work is to change the UnitTest sensors to send file path info, and try
to get rid of this class-workspace mapping stuff.
Emma, FindBugs, and PMD Sensors:
These sensors are great, but I do not want to actually run these tools if the
sensors
are not available. And I would want to run these tools only if the sensors are
available (for example in CruiseControl builds). What would be the best
practice on how
to make this possible? Would using the available be the best option? Note that
some of
the developers actually run our cruisecontrol target before committing code.
That's interesting that the developers run CruiseControl targets locally. Here's how I
would do this:
(a) Put both the tool invocation and the sensor invocation into their own targets, such
as runPmdTool and runPmdSensor.
(b) Create a top-level <condition> task that checks to see if it can find the sensor .jar
file, and set a property like pmd.sensor.available if the jar file is found, such as:
<condition property="pmd.sensor.available">
<available file="${ant.home}/lib/pmd.sensor.jar"/>
</condition>
(c) make a top-level task that depends upon both the actual invocation of the tool and
the tool sensor targets and is conditionalized on the presence of the sensor:
<target name="runPmd" depends="runPmdTool, runPmdSensor"
if="pmd.sensor.available"/>
What's nice about setting things up this way is that later, if a developer wants to run
PMD but does not have the sensor installed, they can do it without changing the build
file by invoking runPmdTool explicitly. It seems likely that at least some of them will
want to run it locally at some point.
Jira Sensor:
I haven't been able to get the Jira Sensor (formally Jira2) to work since the
latest
upgrades. I'm not sure if its the upgrades or some settings on my local server.
The
problem is that the extractor can't seem to login through SSL (it was able to
before).
I guess this is not really a question, but just an FYI. I will look into the
problem.
Thanks! The Jira sensor is much better than it was before; hopefully you can help us
figure this out. My guess is that the Jira folks have changed the API for SSL logins in a
release of Jira subsequent to the one in which this feature was implemented initially.
Eclipse warnings about Sensors:
Is there any way how to get rid of those pesky "taskdf class
org.hackystat.sensor.*
cannot be found" warnings in Eclipse without installing the sensors? Those are
probably
especially irritating to my developers who have no clue what Hackystat is. My
current
thought would be to make a separate Ant build file that contains the Ant sensor
targets
and invoke that separately. Any other ideas?
That one sounds best to me.
Telemetry Control Center:
Its my belief that the Telemetry Control Center is much apart of the Hackystat
interface as the Web commands. Any thoughts about allowing that application to
be
downloaded via the Hackystat webpage?
I agree that the TCC is a "first class interface" to Hackystat, and although it's already
available in several configurations, it is currently an undocumented feature. We will
document it in the near future via a docbook chapter in the
hackyApp_TelemetryControlCenter module that will show up in the User Guide (or maybe the
Administrator Guide?) for configurations including this module. The chapter will explain
how to install the TCC (with a link to the .jar file in the download directory of the
server), how to write TCC XML files, and some samples.
Cedric has been desperately wanting to write this chapter, but I've been making him wait
until I finished documenting how to write docbook documentation. :-)
Finally,...
Eclipse Sensor:
At some point, I would like to introduce client side sensors like the Eclipse
sensor. I
belive the "Big Brother" issue would be a factor. One idea that I had was to
send all
DevEvents to one single Hackystat account. Thus, a developer can hide amongst
the rest
of the project members. Would that be a bad idea? I'm just trying to figure
out a way
to minimize the "big brother" feel.
That's an intriguing idea. Here's an alternative. Get your "single account" mode up and
running and producing anonymous project-level statistics that the development group finds
to be of use. This might take you several more months of fine tuning, but just take your
time, there's no hurry, we'll still be here. The point is that you want your development
team to get used to Hackystat collecting metric data, and you want them to see concrete
value from the anonymous data that it collects.
Once you're at that point, then you can show them your _own_ personal data and how you
are using it to help manage your own personal productivity and quality. Then, maybe just
one developer will want to take the plunge. If so, you're on your way.
Cheers,
Philip
