Comments on: Groovy’s the elixir for report overload syndrome http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/ Can you dig it man? Mon, 13 Oct 2008 18:47:01 +0000 http://wordpress.org/?v=2.6 By: Glean gets a dashboard | Brugge Blog http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-19783 Glean gets a dashboard | Brugge Blog Thu, 19 Jul 2007 12:07:59 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-19783 [...] I’ve wanted to have an all-in-one-page view of a project’s metrics for years now, ever since seeing the Maven 1.x dashboard plugin. And now, thanks to the inspiration from a blog post by Andy Glover and the leverage of a language like Groovy, I’ve managed to pull one together, and have added it to the latest release of Glean. [...] [...] I’ve wanted to have an all-in-one-page view of a project’s metrics for years now, ever since seeing the Maven 1.x dashboard plugin. And now, thanks to the inspiration from a blog post by Andy Glover and the leverage of a language like Groovy, I’ve managed to pull one together, and have added it to the latest release of Glean. [...]

]]> By: Glean 1.1 Released | Brugge Blog http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-10363 Glean 1.1 Released | Brugge Blog Thu, 03 May 2007 03:33:03 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-10363 [...] In that same theme of getting information out of the collective results, I’m still looking for good ways to put together an “at a glance” summary of the different metrics. Andy Glover has a start on something like this built in Groovy, and I think something like that could plug in to Glean pretty easily. I’m also going to look at XRadar and Hackystat, but at first glance those are a bit more involved to set up. [...] [...] In that same theme of getting information out of the collective results, I’m still looking for good ways to put together an “at a glance” summary of the different metrics. Andy Glover has a start on something like this built in Groovy, and I think something like that could plug in to Glean pretty easily. I’m also going to look at XRadar and Hackystat, but at first glance those are a bit more involved to set up. [...]

]]> By: The Disco Blog » Blog Archive » Sketching complexity with Groovy http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7701 The Disco Blog » Blog Archive » Sketching complexity with Groovy Fri, 30 Mar 2007 21:17:25 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7701 [...] Sketching complexity with Groovy Not long ago, I wrote up a nifty dashboarding application, à la Groovy, in an effort to abate the visual pain associated with report overload syndrome. These kinds of applications are perfect for languages like Groovy as you can knock them out in a matter of hours (including a test suite to verify kosherness). [...] [...] Sketching complexity with Groovy Not long ago, I wrote up a nifty dashboarding application, à la Groovy, in an effort to abate the visual pain associated with report overload syndrome. These kinds of applications are perfect for languages like Groovy as you can knock them out in a matter of hours (including a test suite to verify kosherness). [...]

]]> By: John Brugge http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7440 John Brugge Mon, 26 Mar 2007 17:34:41 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7440 Andy, My first thought would be to see how this might fit in to Glean as just another tool, albeit something of a meta-tool; the fit might not be perfect, since this would have to run after the other tools (ordering is not important for any of the other tools), but I would like to arrange it so that people could choose whether or not to include this just as they do any of the other tools. All of the XML data from the other tools would be there already, so with some property values to point at the different locations to slurp it from, I would think it could fit in pretty well. Each of the tools in Glean has their own script, so the dashboard Ant script would live by itself too; the snippet you've got above would be the heart of it, and the rest would just be property setup. I could also imagine allowing users to define some threshold settings for the different tools. These could either be interpreted in the XSLT when you generate the dashboard page, or possibly by the Groovy app. Either way, it would be one way to provide green/red binary feedback on the values as well. John Andy,

My first thought would be to see how this might fit in to Glean as just another tool, albeit something of a meta-tool; the fit might not be perfect, since this would have to run after the other tools (ordering is not important for any of the other tools), but I would like to arrange it so that people could choose whether or not to include this just as they do any of the other tools.

All of the XML data from the other tools would be there already, so with some property values to point at the different locations to slurp it from, I would think it could fit in pretty well. Each of the tools in Glean has their own script, so the dashboard Ant script would live by itself too; the snippet you’ve got above would be the heart of it, and the rest would just be property setup.

I could also imagine allowing users to define some threshold settings for the different tools. These could either be interpreted in the XSLT when you generate the dashboard page, or possibly by the Groovy app. Either way, it would be one way to provide green/red binary feedback on the values as well.

John

]]> By: Andy http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7372 Andy Sun, 25 Mar 2007 02:02:42 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7372 John- you bet! I was going to dontate the code to <a href="http://www.qualitylabs.org" rel="nofollow">Quality Labs</a>. I'd love to see how we can put this stuff and Glean together. Thoughts? John- you bet! I was going to dontate the code to Quality Labs. I’d love to see how we can put this stuff and Glean together. Thoughts?

]]> By: John Brugge http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7303 John Brugge Thu, 22 Mar 2007 02:43:10 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-7303 Andy, I've been jealous of Maven 1's Dashboard plugin since someone showed it to me long ago, and have since dreamed of how that could be done for Ant. It looks like our dashboard is yet another example of things that Groovy opens the doors to. Very slick! I haven't really used Groovy yet, but you've whet my appetite. I've got a small framework of Ant scripts, that I call <a>Glean</a>, that drives a set of open-source code feedback tools. My goal with the first incarnation was to make something that teams could easily drop into their current build system and quickly get an extensible feedback system going. One of the things on my list to add to it later version is a summary of the results, and I haven't had any big inspirations. When I saw your description here, though, my ears perked up. I'm wondering, then, if your dashboard implementation is something that you are considering sharing (and I completely understand if you aren't). If not, I'm wondering if you could share what your experience was in building it - hard, easy, frustrating, quick? Were there any particularly useful aspects of Groovy that helped? (besides the points you already shared - thanks much for those as well) In any event, it looks very cool, and I'm glad you at least planted the seed of possibilities in some of us. Thanks, John Andy,

I’ve been jealous of Maven 1’s Dashboard plugin since someone showed it to me long ago, and have since dreamed of how that could be done for Ant. It looks like our dashboard is yet another example of things that Groovy opens the doors to. Very slick!

I haven’t really used Groovy yet, but you’ve whet my appetite. I’ve got a small framework of Ant scripts, that I call Glean, that drives a set of open-source code feedback tools. My goal with the first incarnation was to make something that teams could easily drop into their current build system and quickly get an extensible feedback system going. One of the things on my list to add to it later version is a summary of the results, and I haven’t had any big inspirations. When I saw your description here, though, my ears perked up.

I’m wondering, then, if your dashboard implementation is something that you are considering sharing (and I completely understand if you aren’t). If not, I’m wondering if you could share what your experience was in building it - hard, easy, frustrating, quick? Were there any particularly useful aspects of Groovy that helped? (besides the points you already shared - thanks much for those as well)

In any event, it looks very cool, and I’m glad you at least planted the seed of possibilities in some of us.

Thanks,
John

]]> By: The Disco Blog » Blog Archive » Currying maximum favor with Groovy http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-4087 The Disco Blog » Blog Archive » Currying maximum favor with Groovy Sun, 04 Feb 2007 02:51:33 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-4087 [...] Currying maximum favor with Groovy As a side project to building a small build results dashboard with Groovy, I found myself writing a copasetic application, which analyzed a code base using JDepend’s programmatic API. In both instances, I found myself needing to determine the maximum numeric value in a collection. Now, in Groovy (and in any language, for that matter), there is a cornucopia of ways to obtain a maximum value– either through brute force logic or more creatively hip mechanisms. [...] [...] Currying maximum favor with Groovy As a side project to building a small build results dashboard with Groovy, I found myself writing a copasetic application, which analyzed a code base using JDepend’s programmatic API. In both instances, I found myself needing to determine the maximum numeric value in a collection. Now, in Groovy (and in any language, for that matter), there is a cornucopia of ways to obtain a maximum value– either through brute force logic or more creatively hip mechanisms. [...]

]]> By: Andres Almiray http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-3528 Andres Almiray Sun, 28 Jan 2007 19:00:52 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-3528 Andy, JWatson is the project I mentioned a while ago at my blog (http://jroller.com/page/aalmiray?entry=a_code_metrics_dashboard), the idea is to mix and match several metrics with scm data and get and overall view or your project's health, think of it like fisheye + cobertura + static analisys. I have rounded up PMD, JDepend and JavaNcss so far (run and process reports) and FindBugs (process report only). Some plugins are not that easy to setup for internal running (FindBugs and Lint4J) so I'm moving at a slow rate. I definitely think that throwing Groovy into the mix is an excellent idea. Andy, JWatson is the project I mentioned a while ago at my blog (http://jroller.com/page/aalmiray?entry=a_code_metrics_dashboard), the idea is to mix and match several metrics with scm data and get and overall view or your project’s health, think of it like fisheye + cobertura + static analisys. I have rounded up PMD, JDepend and JavaNcss so far (run and process reports) and FindBugs (process report only). Some plugins are not that easy to setup for internal running (FindBugs and Lint4J) so I’m moving at a slow rate. I definitely think that throwing Groovy into the mix is an excellent idea.

]]> By: Andy http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-3491 Andy Sun, 28 Jan 2007 14:22:30 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-3491 Andrew-- yeah, CQ2 appears to be a slick tool-- metrics trending is quite valuable. The tool's ability to montior KPAs is interesting. I'm also familiar with another tool-- <a href="http://www.borland.com/us/products/silk/gauntlet/index.html" rel="nofollow">Borland's Gauntlet</a>, which appears to be similar in some ways to CQ2. Andrew– yeah, CQ2 appears to be a slick tool– metrics trending is quite valuable. The tool’s ability to montior KPAs is interesting. I’m also familiar with another tool– Borland’s Gauntlet, which appears to be similar in some ways to CQ2.

]]> By: Andrew Binstock http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-3466 Andrew Binstock Sun, 28 Jan 2007 07:58:07 +0000 http://thediscoblog.com/2007/01/27/groovys-the-elixir-for-report-overload-syndrome/#comment-3466 There is at least one commercial dashboard that automates collection and integration of metrics from multiple tools and sources: <a href="http://www.enerjy.com" rel="nofollow" rel="nofollow">Enerjy CQ2</a>. I recently reviewed it in <a href="http://www.infoworld.com/article/06/08/18/34TCenerjy_1.html" rel="nofollow" rel="nofollow">InfoWorld</a> and was failry impressed. It's a cool tool and, of course, keeps a repository of the metrics so you can see trends over time in addition to the current time slice. Nice hack! It shows exactly what Groovy is great at. There is at least one commercial dashboard that automates collection and integration of metrics from multiple tools and sources: Enerjy CQ2. I recently reviewed it in InfoWorld and was failry impressed. It’s a cool tool and, of course, keeps a repository of the metrics so you can see trends over time in addition to the current time slice.

Nice hack! It shows exactly what Groovy is great at.

]]>