After the integration of two Google components (Motion Chart and Timeline), we are releasing the last of a series of three nice and sexy plugins : The Sonar Radiator Plugin, aka big treemap.
The radiator is available in the home page as well as on the project dashboard. It works the same way the standard treemap does : you can choose pretty much any metric to represent the size of rectangles and any qualitative metric for their color.
Read the rest of this page »
Straight after the Motion Chart, the Google Visualization Annotated TimeLine component gets integrated to Sonar with the Timeline Plugin.
This is really a great addition to the TimeMachine functionality as this component offers a higher flexibity : you can select up to 3 metrics and then view their evolution throughout pre-defined periods (last 5 days, last month…) or a custom period. The functionality is as usual available for projects, modules and packages.
To add the functionality to your Sonar instance, you can download the plugin
and start replaying the past.
Last week, the most sexy plugin of the Sonar forge was released : the Motion Chart plugin ! This animated bubble chart as I used to call it can handle up to 4 custom dimensions throughout time : X-axis, Y-axis, color and size of the bubbles.
Once installed, a new link “Motion chart” is available both on the Sonar home page and on each project to respectively play with all projects or all components of a given project. It is really impressive to see bubbles moving along with time and code quality evolution.
Read the rest of this page »
The community has started several months ago to request a plugin to group / aggregate projects in Sonar. This plugin was released a couple of days ago under the name : Sonar Views Plugin. It is a commercial plugin edited by SonarSource that goes beyond the community initial expectations.
The Views Plugin enables to create any kind and any number of aggregation trees. Here are few examples :
- Recreate inside Sonar the company internal organization : projects can be grouped by applications, applications by team, teams by department…
- Group projects by type : libraries, web applications…
- Separate legacy projects from new ones
Read the rest of this page »
No one from SonarSource could attend the event. However we are proud that Sonar is going to be represented there by a company who we share at least 3 values with: Agility, Open Source (GreenPepper) and Human values. This company is Pyxis !
At the same time, the first version of the Greenpepper Sonar plugin has been released. Go and meet the Pyxis’s team at Agile 2009 : they are really nice people, I am sure they will give you a demo of GreenPepper / Sonar… and maybe a Sonar tee-shirt ;-).
You already know Sonar as an enterprise tool to analyze and manage code quality of a projects portfolio. We claim, for very good reasons obviously :-), that it is easy to install and easy to use. Currently, it covers Java and PL/SQL languages.
As a tool, Sonar is more and more often compared to commercial products such as Cast Software or Metrixware for instance. Having said that, if I had the choice, I’d prefer Sonar to be compared to Kalistik (commercial product) that better fits the market evolution and needs.
All this is great, but as you might have realized already, Sonar is more than a simple out-of-the-box product : it is an open source (LGPL) platform to manage code quality, i.e. the foundations on which the community has already started to build new floors. Our aim is that Sonar becomes to quality management what TCP is today to network applications : the central component to go further and faster. That’s our new dream since the command “mvn sonar:sonar” is available :-).
Here are real life examples that support the idea of Sonar being a platform:
- Let’s say you have built a commercial tool (PC-Lint, Simian, SAP ABAP Code Inspector … ) or an open source one (Testability Explorer, Crap4j, Clang Static Analyzer…) or let’s say that you think a new axis of quality analysis would be more pertinent. By developing a plugin in Sonar, you kill two birds with one stone : you immediately have access to a large community of users and you benefit from the built-in functionality (TimeMachine, trends, consolidation…)
- You manage a consulting company and are building a package around quality. By building this package around Sonar, your client gets basically the tool for free and what they are going to pay for is what you have to sell : your expertise on quality
I believe that code quality management is going to become a commodity in the medium term as is continuous integration today; and I do hope that Sonar is going to play a central role in this democratization move.
When dealing with source code quality information within a company, Sonar is the perfect reporting tool as it is accessible to everybody and centralizes the information through its web server . However, in some cases, this information can be at the destination of third party organizations. This situation is common in an enterprise environment, for instance on quality audit projects or outsourced projects. In both cases, a quality measurement deliverable is required. This is the aim of the Sonar PDF Plugin.
As described in a previous article, a Sonar plugin is a simple jar that must be copied to the /extensions/plugins directory of the Sonar web server in order to be loaded at next start. That is not the case for Sonar PDF as it is a maven plugin. The plugin uses Sonar extension points, especially the web services API, so all the data used by this plugin is retrieved through WS API.
The plugin, version 0.2, is currently able to report on :
- Global dashboard
- Violations by categories
A full example of the report is available here.
What about the future? The future is Team Workbook Report, the second report type that will include most deep data as violations per class and line, graphics and more.
The author : Antonio Manuel Muñiz, www.gmv.com (Blog, email)
The technical debt is a well-known concept that was invented by Ward Cunningham in 1992 and that he’s recently talked about in this video. Since then, it has been discussed and developed numerous times in blogs and articles. I am not going to describe it in great details here, I rather recommend that you read what it is considered as the reference article on the subject, by Martin Fowler. Here is an extract of this article that gives a synthetic view of the metaphor :
In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
This metaphor seems to be accepted by many developers already and every day someone tweets about the urgent need to pay back his technical debt. But beyond the concept, when time comes to evaluate the amount to be repaid, there is simply no literature on how to calculate the debt or at least approach it. It’s like borrowing money to buy a house but 2 years later having no way to know what is the remaining debt and how much interest are being paid each month :-).
As stated by Martin Fowler, developers are good and sometimes make deliberate choice to borrow in order to buy time. That’s true when starting a new development as you know exactly the amount of technical debt… that is to say 0. But when extending or maintaining a legacy application, that’s another story as nobody knows exactly how bad it is. Further more you might even not be aware that you are borrowing money, when a developer simply does not follow best practices. That is why, evaluating even roughly the technical debt is very useful.
Before introducing this Sonar plugin, here are few funny and relevant quotes on the concept :
- Maintaining an application without any unit tests is like borrowing money each time you add or change a line of code
- Skipping design phase is like borrowing money to get a very “quick” and “predictable” return of investment
- Refactoring is like paying down the principal
- Development productivity decreases when interests grow up
- Managers don’t care about code quality, just ask them to pay the debt in order get their attention
- Bankruptcy is logical extension of technical debt uncontrolled… we call it a system rewrite
When discussing source code quality, I like to say that there are seven deadly sins, each one representing a major axis of quality analysis : bad distribution of the complexity, duplications, lack of comments, coding rules violations, potential bugs, no unit tests or useless ones and bad design. As you know already, Sonar actually covers 6 of them but the seventh one (bad design) should probably start shaking :-) as it is a matter of time it gets covered as well.
From this observation, we decided to build new metrics that reflect how much effort is required in order to get a perfect score on the various axes. In other words, what is the cost of reimbursing each of the debts in the project. By combining the results, we obtain a global indicator that we report in $$ to keep it fun ! Along with this indicator comes the repartition of each axis, i.e. how much did each axis participated to the technical debt.
The current version of the plugin is 0.2 and uses the following formula to calculate the debt :
|Debt(in man days) =
||cost_to_fix_duplications + cost_to_fix_violations +
||cost_to_comment_public_API + cost_to_fix_uncovered_complexity +
||cost_to_fix_one_block * duplicated_blocks
||cost_to fix_one_violation * mandatory_violations
||cost_to_comment_one_API * public_undocumented_api
||cost_to_cover_one_of_complexity * uncovered_complexity_by_tests (80% of coverage is the objective)
||cost_to_split_a_method * (function_complexity_distribution >= 8) + cost_to_split_a_class * (class_complexity_distribution >= 60)
Beyond the calculation that is a broad approximation of the reality, the technical debt measure is precious as :
- it is a consolidated metric on projects, modules…
- it can be followed in the TimeMachine (historical data, trend)
- it enables to compare projects
- it is possible to drill down on it even to… the class
As a first version, you probably noticed that we took some options, however most of the values for costs can be adjusted in the plugin configuration.
The plugin has been installed on Nemo, the public instance of Sonar, that now calculates the debt of more than 80 Open Source projects. The plugin relies only on the available Sonar extension points and is good example of advanced metrics that can be computed with Sonar.
I am going to stop here on the technical debt for today, but would like to simply mention what we plan to add to it next : interests, debt ratio and project risk profile. I let you now go back to Sonar to install this new plugin as I am sure you want to know what is the technical debt of your project…
A couple of weeks ago, we wrote a post on the “The Ultimate Enterprise Java Build Solution“, to show that nowadays the debate on infrastructure has shifted from open source vs commercial to modular vs integrated. Did we mention that we believe in the modular approach ? I don’t think we did but it was obvious, wasn’t it ? ;-)
The solution described by Christopher Jugg is basically what we have in place to run Nemo, the public instance of Sonar : Maven, Hudson, Nexus, Subversion and Sonar. Here is a diagram that shows our Amazon EC2 infrastructure :
Read the rest of this page »