Hey Philip,
> * My mockup included an output file name specification, yours does not.
> Perhaps it would be good to support explicit file name specification in the
> Ant task?
Yes. I saw that and really liked it. I hadn't come to that point
yet. One minor issue is that I also want to save the HTML snippet
that defines the client side map that gives the "hover" effect for the
data values. So I'd like to save one PNG file, and one HTML file.
> * Using 'showLast' has pros and cons over an explicit 'startDate' and
> 'endDate' specification. It's a bit easier to use, but does not allow
> specification to intervals that do not end with the current time interval.
> I'm fine with it to start, and we can see if we ever need more general
> interval specification.
With the way that the objects are defined, I planned to have one
interval option that has "showLast" and another that is "start" and
"end". I really want both available for use, and it's pretty easy to
offer it.
> * The 'ProjectStatus####Global' approach to specifying the Telemetry Report
> seems a bit weird to me. I think I understand why you need it (you need to
> get the '(Global)' string into the URL parameter). I'm thinking it would
> be much better if the user could just specify the 'real' Telemetry Report
> name (i.e. 'ProjectStatus'). If we want to do that, either (a) Cedric
> needs to change the analysis to not include the '(Global)' string, or (b)
> You need to make two requests, one with the '(Global)' and one without, and
> only fail if neither of them work out.
I agree this is a bit awkward. Technically this is the Project Name
and "scope" or something, right? Perhaps I could split it into two
attributes and build the URL value from the two.
> * I am hoping that your Ant task generates a request to the Telemetry Chart
> analysis on the Extras page, not the Telemetry Report analysis on the
> Analyses page. The reason why I think Telemetry Chart is better is because
> it returns a single png file, while Telemetry Report returns one or more
> png files depending upon the specifics of the report definition. Since all
> of the Telemetry Charts that make up a Telemetry Report are available via
> the Telemetry Chart command, there's no loss of functionality by
> translating your <telemetry> tag into an invocation of the Telemetry Chart
> command. It just means that (a) each <telemetry> tag returns a single png
> file, and (b) if you want to get a Telemetry Report, you have to invoke
> <hackyDownload> multiple times, once for each component Chart in the
> Telemetry Report.
I can do this easily, but it may not be as needed as you might think.
I'd like each analysis tag (<telemetry> and such) to figure out all
the stuff it needs to download and take care of it properly. So if we
have an analysis that uses Telemetry Report, it should get all the
PNGs and corresponding HTML snippets properly. I already have to make
two HTTP requiests: one to get the HTML and another to determine which
tmpZZZZ.png files I should request -- making a few others shouldn't be
too bad. That said, I think it's easier to deal with just one PNG, so
I'll start with it using the Telemetry Chart.
In addition, I've designed <hackyDownload> to handle as many analyses
as you want. You should be able to do something like this (many
details removed):
<hackyDownload>
<telemetry ...> <!-- get last 7 days of Active Time -->
<telemetry ...> <!-- get code churn from Feb to Aug -->
<telemetry ...> <!-- get project status by week for the last 8 weeks -->
</hackyDownload>
> If you're OK with that, then I suggest that you change the name of the
> interior tag <telemetryReport> to <telemetryChart> to be consistent with
> the parameter to the Telemetry Chart analysis.
I'll make this change. It's pretty easy.
> I can't wait for this to be available! I see a lot of potential
> applications!
Thanks. I'm excited as well. I'll keep you posted on my progress,
and please let me know if you've got some more ideas on how it could
be improved.
Thanks,
Tim
> --On Wednesday, November 10, 2004 11:24 PM -0700 Tim Shadel
>
>
> <[EMAIL PROTECTED]> wrote:
>
> > Hey all,
> >
> > Philip asked what the ant task looked like. Here's the idea so far,
> > most of it's working, and some is just prototype.
> >
> > <hackyDownload>
> > <fileSensorProps/> <!-- looks at
> > ${user.home}\sensor.properties -->
> > <telemetry>
> > <reportType type="chart"/>
> > <hackyProject name="asrs-all"/>
> > <interval type="month" showLast="12"/> <!--
> > Uses calendar to
> > choose only valid drop down choices, NOT like old style show last X
> > number of days -->
> > <telemetryReport
> > name="ProjectStatus###Global"/>
> > <templateValue>**</templateValue>
> > </telemetry>
> > </hackyDownload>
> >
> > Here's a slightly different one:
> >
> > <hackyDownload>
> > <!-- Don't look up info in sensor.properties, just
> > use this info -->
> > <provideAccountInfo hackystatKey="afLz98YBt8ja"
> > serverUrl="http://hackystat.ics.hawaii.edu/"/>
> > <telemetry>
> > <reportType type="chart"/>
> > <hackyProject name="JBlanket-2004"/>
> > <interval type="week" showLast="9"/>
> > <telemetryReport
> > name="ProjectStatus###Global"/>
> > <templateValue>**</templateValue>
> > </telemetry>
> > <telemetry>
> > <reportType type="chart"/>
> > <hackyProject name="JBlanket-2004"/>
> > <interval type="day" showLast="9"/>
> > <telemetryReport
> > name="ProjectStatus###Global"/>
> > <templateValue>**</templateValue>
> > </telemetry>
> > </hackyDownload>
> >
> > I chose to use nested elements instead to allow for extensions and
> > alternatives. Right now you could use <telemetry>, but any <analysis>
> > will do. I'll send more info tomorrow.
> >
> > What do you think?
> >
> > --Tim
> >
> >
> > On Wed, 10 Nov 2004 11:11:10 -1000, Philip Johnson <[EMAIL PROTECTED]>
> > wrote:
> >> [Tim forgot to reply-all]
> >>
> >>
> >>
> >> ------------ Forwarded Message ------------
> >> Date: Wednesday, November 10, 2004 2:02 PM -0700
> >> From: Tim Shadel <[EMAIL PROTECTED]>
> >> To: Philip Johnson <[EMAIL PROTECTED]>
> >> Subject: Re: [HACKYSTAT-DEV-L:270] Re: Sharing hacky2004-all information
> >>
> >> I've already got it downloading Telemetry charts. Those are where I
> >> started. It still needs some cleanup, but it's done in a fairly way.
> >>
> >> It's actually quite easy to grab any analysis because of the way your
> >> web UI is setup. The API is just the URL parameters. I read the
> >> sensor.properties, like you indicated, but beyond that it's really
> >> simple to get anything. You've used the same controls to indicate
> >> start and stop dates, so those parameters are easily applied to many
> >> analyses. The report type is the same way, so I can simply choose
> >> "Chart" on anything. Project applies to many analyses. And the
> >> Command is simply the analysis name.
> >>
> >> Between those right there I can get: Project Active Time and Active
> >> Time Trend. If I add the Telemetry Report and Template Values I've
> >> got any Telemetry analysis I want. I don't use any of the code from
> >> the Telemetry package, since I'd like to keep its dependencies to only
> >> the URL API and the page setup. I already have to grab the <map>
> >> element to reproduce the tooltip hover effect you get when you put
> >> your mouse over a data point. Since I'm already doing that, it's a
> >> small jump to get the HTML from table based analyses. At that point
> >> I'd be able to get: Project File Time, the sequence analysis stuff,
> >> and many of the extras. I'm not likely to actually jump into that
> >> now, but it's really not too difficult.
> >>
> >> Another easy jump is to provide the Telemetry Expert Analysis, since
> >> we'd just need to pass a string through.
> >>
> >> Once it's to a point where you can play with it, I'll let you know.
> >> But I was pretty excited at how easy it was run any analysis given the
> >> standard controls you've used. I guess it seemed just too easy to get
> >> more than I wanted for a fraction of the price. :-)
> >>
> >> Either way, I have been and will continue to focus on Telemetry.
> >>
> >> What do you think?
> >>
> >> --Tim
> >>
> >> On Wed, 10 Nov 2004 10:32:00 -1000, Philip Johnson <[EMAIL PROTECTED]>
> >> wrote:
> >> >
> >> >
> >> >
> >> >
> >> > --On Wednesday, November 10, 2004 12:20 PM -0700 Tim Shadel
> >> > <[EMAIL PROTECTED]> wrote:
> >> >
> >> > > On Wed, 10 Nov 2004 08:55:33 -1000, Philip Johnson
> >> > > <[EMAIL PROTECTED]> wrote:
> >> > >> Hi Aaron,
> >> > >>
> >> > >> Yes, that's an excellent, excellent idea, and in fact that's pretty
> >> > >> much exactly what the hackyMaven project is intended to support.
> >> > >> The idea is that Maven-generated project websites would (a) run
> >> > >> analyses during construction that send data to a hackystat server,
> >> > >> and then (b) suck charts from Hackystat and display them in a
> >> > >> reasonable place on the project website.
> >> > >>
> >> > >> Given that we don't use Maven, at least not yet, it might be nice
> >> > >> for us to hack something together for hackydevsite. Maybe we can
> >> > >> adapt the telemetry viewer code to simply download once day a
> >> > >> bunch of jpgs from the hackystat server, rename them to something
> >> > >> standard, and then build a static page that displays them?
> >> > >
> >> > > That's exactly the approach I'm taking on hackyMaven. Since nearly
> >> > > all maven goals are truly rooted in Ant tasks, I'm developing a
> >> > > simple Ant task that should be able to download any type of analysis
> >> > > to a local directory. What you do with the .jpg or .html files
> >> > > (containing the client side map that puts labels over the data
> >> > > points) after the download is an open question.
> >> > >
> >> > > Maven has a second step that generates a coherent project website.
> >> > > During that phase I planned to put together the report with all of
> >> > > the analyses. I've been concentrating on the download portion thus
> >> > > far, so I haven't jumped into the report design much. It may also
> >> > > be an Ant task that would assemble the pieces into a coherent
> >> > > document. Maven often uses a specific DTD for XML docs it'll
> >> > > transform, but it may be trivial to allow both a straight HTML or
> >> > > XML output.
> >> > >
> >> > > That's my current working path. What do you think?
> >> > >
> >> > > --Tim
> >> >
> >> > Sounds excellent! However, rather than create a completely generic
> >> > analysis retriever (or perhaps as a wrapper over it), I would propose
> >> > that you create an Ant task specialized to telemetry chart retrieval,
> >> > since I think that is going to be the target analysis 99% of the time.
> >> > It might look like the following:
> >> >
> >> > <taskdef name="hacky-chart"
> >> > classname="org.hackystat.app.maven.ant.HackyTelemetryChartRetriever"/>
> >> > <property file="${user.home}/.hackystat/sensor.properties"/>
> >> > <hacky-chart host="${HACKYSTAT_HOST}"
> >> > key="${HACKYSTAT_KEY}"
> >> > telemetrychart="ActiveTime-Member"
> >> > project="hacky2004-all"
> >> > intervaltype="Day"
> >> > intervalstart="01-Nov-2004"
> >> > intervalend="07-Nov-2004"
> >> > templatevalues="**"
> >> > outputfile="ActiveTime-Member-Last-Seven-Days.png">
> >> > </hacky-chart>
> >> >
> >> > This would login to the host using the key, run the Telemetry Chart
> >> > Analysis on the associated chart, project, interval, and template
> >> > values, storing the resulting chart image in the file
> >> > ActiveTime-Member-Last-Seven-Days.png. Note that the "Report Type"
> >> > always defaults to "Chart", so that we know we have a file to
> >> > download. Each time this example task runs, it will overwrite
> >> > ActiveTime-Member-Last-Seven-Days.png with a new copy of the image
> >> > (which is presumably what one would typically want to have happen).
> >> >
> >> > Although I hardcoded the dates in this example, in reality the user
> >> > would probably want to use the <tstamp> task to build the interval
> >> > dynamically, to do things like make the start date <today minus seven
> >> > days>, and the end date <today>. That's quite simple as well.
> >> >
> >> > I think you'll find that implementing this is substantially easier
> >> > than the general case, and will allow you to get an initial version of
> >> > hackyMaven up and running more quickly. I also think this interface is
> >> > easier to use and understand than a general Hackystat analysis invoker
> >> > would be. Though this version of hackyMaven would be limited to
> >> > retrieving individual Telemetry Charts at first, we might find that
> >> > even this limited functionality satisfies everyone for quite a while.
> >> >
> >> > Comments?
> >> >
> >> > Cheers,
> >> > Philip
> >> >
> >> >
> >>
> >> ---------- End Forwarded Message ----------
> >>
> >>
>
>
