A new video has been added to Sonar TV. After “Install Sonar”, “Chasing duplications” and “TimeMachine”, Configuring coding rules is now part of the collection…

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
• Hotspots

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_bring_complexity_below_threshold

Where :

Duplications	=	cost_to_fix_one_block * duplicated_blocks
Violations	=	cost_to fix_one_violation * mandatory_violations
Comments	=	cost_to_comment_one_API * public_undocumented_api
Coverage	=	cost_to_cover_one_of_complexity * uncovered_complexity_by_tests (80% of coverage is the objective)
Complexity	=	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…

In the last couple of weeks, we’ve started making short videos on Sonar, each one showing a dedicated feature in 1 or 2 minutes. Those videos are a good starting point for people wanting to have a rapid but comprehensive view of the Sonar platform. Our animation studios are still pretty young but here are the first three films : chasing duplications, installing Sonar and TimeMachine. Your feedback to improve the next productions is highly welcome.
In order to make the videos, we tested several tools and decided to buy Screenflow. From all the ones we tested, Screenflow is really the best : easy to use, fast with just the effects we were looking for… and all that for $99. Its only weakness : it runs on Mac, but is it really a weakness ;-)

Read the rest of this page »

Amongst Sonar built-in strengths, we mentioned extensibility several times without giving many details. Time has come to discuss it further as anyone can now easily contribute to the Sonar plugins ecosystem.
We do know extensibility of a tool is a key aspect to get it widely adopted. That is why we built Sonar around a very light core that consists mainly in an extension mechanism. Everything else in Sonar is a plugin. However, having such a mechanism in place is only one step amongst four to reach extensibility and leverage this capability :

• An easy to use API
• A forge
• An active community
• A “Getting started” documentation with examples

We believe that we have today a sufficient base on all four points.

Read the rest of this page »

For many, it is getting very tempting to switch to Sonar to centralize the quality management of source code and take advantage of the numerous functionality such as TimeMachine, Classes clouds, Consolidated dashboards, Drill downs… In Sonar 1.7, we have added a very useful feature that we did not discuss too much so far : the possibility to re-use reports generated by external quality systems in order to smoothly evaluate Sonar without having to break the legacy quality platform. Today, were going to discuss two use cases where this feature can be leveraged.

1. Switching from Maven Site to Sonar

This is a very common situation : you are already managing the quality of your source code through the Maven Site by generating sites on 250 projects, for instance, with every quality reports activated. Your team uses the maven site extensively and switching to Sonar in a big bang approach is simply not possible.

You have read the post “Maven Site, Sonar or both of them ?” on the Sonar blog but you don’t feel right to suddenly ask everybody to switch to Sonar. You realize that you need to run them both in parallel for some time. But given the fact that it takes already a long time to generate the sites, it is not possible to double this time by doing the analysis in Sonar as well.

That is where the “ReuseReport” functionality of Sonar 1.7 comes into play, it is now possible to have a staged approach ! The principle is fairly simple, it consists of indicating to Sonar that it should use reports that have already been generated by the Maven site, the ones that are the most hungry in CPU and memory : unit tests execution and/or code coverage calculation. This can be achieved by simply adding “-Dsonar.dynamic=reuseReports” to the Sonar maven command line.

It is then possible to keep both systems running in parallel for some time at a slightly higher cost until you decide to make a complete switch to Sonar. When you have switched off the quality reporting in the Maven site, you can even reference Sonar in the Maven site by using the Sonar Maven report plugin.


2. Using Sonar in its full capability in an ANT environment

If you are using ANT to build your applications, the main weakness so far in Sonar was that it did not allow to display Unit tests results nor Code coverage. I am sure that now you have read the first use case, you know that by using the “-Dsonar.dynamic= reuseReports” parameter, this limitation does not exist anymore. You simply need to specify where those reports to reuse are going to be found, by using the following properties : sonar.cobertura.reportPath, sonar.clover.reportPath, sonar.surefire.reportsPath…

With this new functionality, Sonar gives a similar level of quality information on ANT projects that there is on Maven projects.

Did we ever mention why, two years ago, we chose Sonar as a name for the open source platform to manage quality we wanted to build ? It was obviously to make an analogy with a sonar that is an acronym for SOund Navigation And Ranging ! Sonar sounds the sea of your projects to identify flaws and evaluate part of your technical debt. To do so it offers 3 main functionality :

• Quality profiles Manager
• Project and portfolio dashboards
• TimeMachine

The first one sets the base to tune your Sonar, the next two are being used to quickly see where projects stand and how they evolve in time according to the following axes :

Read the rest of this page »

Last month, Sonar 1.6 was released. The main feature of the new version is the ability to manage quality profiles. The purpose of this post is to explain what gap the functionality fills, to define what is a quality profile and to explain how to use it.
Prior to Sonar 1.6, it was only possible to run analysis with one set of defined coding rules per instance of Sonar. It means that within an instance of Sonar, it was not possible to process differently various types of projects (legacy application, technical libraries, new projects, …). They were all analyzed with the same set of rules. Therefore there was sometimes unnecessary noise around the quality data that made it difficult to see quickly what real action was required. Sonar 1.6 turns off this noise by allowing to define and simultaneously use several quality profiles.

Read the rest of this page »

As we get more and more questions about possible overlaps between Sonar and Maven Site, I think it is time to explain the clear vision we have on this important subject. Let me start by answering three questions :

• What is the Maven Site made for ?
  Provide a static portal to publish documentation on projects. By the way, this portal is used by many Open Source projects as their main web site (for instance Commons Collections or Cargo).

• What is Sonar made for ?
  Provide an enterprise OSS capable of handling, managing and reporting all data related to source code quality

• What are the possible overlaps?
  
  All the quality reports available in the Maven Site under “Project Documentation -> Project Reports”, such as CPD Report, PMD Report, Cobertura Tests Coverage, …

Read the rest of this page »

I have spent roughly 10 years in software development, continuously aiming to improve team collaboration. Two months ago, I was convinced that we had a complete set of very good tools for Sonar development, and that even if they were not the bests, switching would not make a big enough difference to be worth it. In other words, I could not possibly imagine that we might adopt instantaneously a $75 product, wondering two days later how it was possible to not have it before.

The miracle product is called Balsamiq Mockups. That’s a pretty simple Flash application, with a minimalist user interface, allowing to draw almost any kind of graphical interfaces in minutes just like if you have a pencil in hand. I know what you think : PowerPoint or OpenOffice Presentation are good enough to design mockups. I thought so too… Give a try to Balsamiq and I bet you’ll fell in love in less than 5 minutes.

Read the rest of this page »