I have been making a lot of changes to the CruiseControl Statistics replacement I released a while ago. Most significantly I changed it to use the Dojo charting library and divided the information into tabs. It now looks like this:
Reasons for the Changes
The reasons for these changes were as follows:
- The display was becoming cluttered with a lot of information that could be nicely separated into tabs.
- I can now defer the rendering of the tables and historic graphs until the point where the user actually wants to view them. This should dramatically reduce the load time on projects that have a lot of statistics.
- The dojo charting library is significantly more flexible than PlotKit and will allow for more freedom in future versions. I also expect that others may want graphs that use more than one plotter, like a combination bar and line chart.
- I will be able to tweak the charting library to do things like rotate the x-axis tick labels so that more of them can be placed on the axis.
Purpose of the Graphs
In my previous posts I forgot to explain why I wanted to do all of this in the first place. While having good looking graphs instead of an ugly table is great, what I really wanted to get the following from this, is the following:
- Determine whether or not the development teams were following our development process and making certain their code compiles before checking in. A red flag for me is a project that is frequently broken. I chat to the team and determine the root cause and rectify it.
- Being able to easily spot projects that are taking long or progressively longer to build and see how I can ensure that it stays at acceptable levels so that the team continue to use CruiseControl effectively.
- Determine if the teams are fixing their FxCop violations and writing and using unit tests on their projects.
Other future benefits I would like to get from this are:
- The addition of line counting statistics so I can see how much projects are being worked on and get a sense of code churn. Of course line counting is fraught with problems, but at least it's something.
- Track project complexity and ensure that we keep it under control.
Installation
The
installation instructions are the same as the previous version.
| Works well in the following browsers: |
  |
| Has some rendering quirks in: |
 |
| Have not tested: |
 |
Downloads / Updates
- [Version 2.3 - 27 April 2007] - Changes:
- Significant restructuring of the graph configuration logic (now lives in a separate file).
- Removed the timeline logic of the graphs.
- Added coverage graphs (assumes that the coverage information is stored in the Coverage element).
- Added tooltips to the graphs (there are problems in IE).
- Graph rendering is now queued with a "Loading..." message in the graph display area. This has helped improve the user experience on the History tab which can be quite slow when displaying a lot of data.
- Miscellaneous other changes in tick generation etc.
- Table cells of greater than 25 characters now wrap. The exception to this is when you have a word without any spaces that exceeds this and is obviously not wrapped. This sometimes happens in the "Build Error Message" column where the path to a file may be very long. I'm considering implementing a solution that splits these up based on a best guess separator (underscore, full stop, or slash).
- The successful/failed builds are color coded in the detailed table now.
- [Version 2.4 - 28 April 2007] - Changes:
- Fixed a problem that was caused when some statistics had coverage values and others didn't.
- Dramatically improved the performance of the summary logic and it now summarises data on demand. The performance problem here was due to the fact I was using the dojo ArrayList method in the distinct method. On a report with over 1.7MB of data this caused Internet Explorer (it doesn't happen in FF) to display the "A script on this page is causing Internet Explorer to run slowly" message. The performance tweaks have removed this problem, but I'm concerned that it may reappear when processing a much larger file. I created a test case with over 8.5MB of data and I didn't receive the message. However the rendering of the tables on such a report is a bit of a joke. I need to look at further improving the performance of the table rendering functions (I don't believe that doing it in the XSLT is going to render the benefit one would expect due to the amount of HTML the client ends up downloading).
- Split the detailed and summary tables on to separate tabs and now obviously only render them when the user wants to view the respective tab. However this is still too slow.
- Increased the time delay between the rendering of the graphs to 150ms.
- [Version 2.5 - 28 April 2007] - Changes:
- Fixed a bug in the tick mark generation that I introduced while making the changes above. Note that now sometimes the last tick mark on the y-axis does not render. I suspect that this is due to the wonders of JavaScript floating point maths (I still need to investigate this fully), but it is a relatively minor issue so I'm not that phased about it.
- Added the ability to drill down into the detail statistics from the summary table.
- Now only averages, counts, etc the successful builds (except the for the failed count of course :) ).
- Various code refactoring.
- [Version 2.6 - 18 May 2007] - Changes:
- Fixed a bug caused by unescaped string sequences in the JavaScript statistics object literal definition (i.e. \u was causing a hexidecimal value expected error in IE). Thank you Mo for reporting this.
- [Version 2.7 - 22 May 2007] - Changes:
- Have improved the manner in which the graphs are configured thereby making it easier for others to add their own custom settings. The details of how this is setup can be found here.
- Now can jump to the build from the detailed data table.
- Added pre-configured complexity and sloc graphs.
Concerns
- The Dojo getBorderBox method that the tab control uses is really slow. In some test cases it takes over 5 seconds in total.
- When switching out of the statistics page Internet Explorer (not FF) struggles and it can take a few seconds just to go back to the listing page. I'm wondering if this is caused by the Dojo framework in some way or by the graphs etc.
- Internet Explorer is significantly slower than FireFox and Opera. This is inline with the graph rendering performance results at http://www.ajaxperformance.com/?p=58.
- The detailed table rendering performance for projects with lots of builds. A possible solution to this is to introduce paging.
To Do
- Use a frameworks such as JsUnit and JSMock (maybe even J3Unit) to properly test the logic. The JavaScript Coverage Validator may also be of use.
- Cut down the size of the dojo toolkit distributed with the graphs as it takes quite some time to deploy and there is a lot unnecessary files in the deployment package at the moment.. Basically I need to create a modified build of the Dojo Toolkit that only includes the pieces that I am using.
- Find a solution to the single word greater than 25 characters problem in the details table which causes the columns to be very wide.
- Find a solution to the Internet Explorer tick tooltip problem. At the moment only the ticks for the last series rendered display tooltips. I believe this is because of the way the Graphing library nest each series inside of a div and layer them on top of each other, thereby preventing the data points on the underlying series to receive the events required to display the ticks.
- Possibly make the ticks a little more informative (requires modifications to the Dojo library). I could use the Dojo tooltip widget to display detailed build information or I could place the information to the right of the graph.
- Implement filtering in the historic build page that allows graphs to be filtered by date range. I'm a bit concerned about the performance impact of having one master filter that then causes all the graphs to be redrawn.