After an initial attempt that ended up posting on what was accomplished last year, time has now come to discuss the plans for Sonar in 2011 and the associated roadmap !

In 2010, Sonar has progressively become a “must have in software factories” as are already Jenkins, Jira, Nexus or Subversion for instance. With Sonar, a quality platform can now be considered as a commodity which can be installed and used by everybody with only little investment whether it is time or money. We will still focus our effort in 2011 to increase the value of the platform and make teams capable of continuously assessing and reimbursing their technical debt even easily than today.

Read the rest of this page »

A few weeks ago, Evgeny described how Sonar can be used with its JaCoCo plugin to measure code coverage by Integration Tests. By adding this new feature to Sonar, Evgeny has actually done more than closing the most voted issue in Jira at the time : he has made a first baby step towards closing some gaps that exist in the world of Software Quality.

Read the rest of this page »

Prior to Sonar 2.2, the home page was simply the list of projects under quality control. Beyond the fact that it did not add much value to the platform, it was unreadable with more than 100 projects and could not even load with more than 800 projects ! This is why we switched the default Sonar home page from an “All Projects” service to a “Filters” service in Sonar 2.2.

Read the rest of this page »

Up to version 2.1, Sonar was relying only on external coding rules engines such as Checkstyle, PMD and Findbugs to report violations on Java applications. But since version 2.1, Sonar also provides its own rules engine to work on Java dependencies. This rules engine is based on Squid and three rules are currently available :

Read the rest of this page »

When learning Object-oriented programming, two of the concepts are fairly difficult to understand and therefore to digest : classes must be loosely coupled and highly cohesive. In today’s post, I am going to explain why this is important and how Sonar can help you evaluating how cohesive are your classes.

A few weeks ago, I started a discussion on how to Fight Back Design Erosion by Breaking Cycles with Sonar in which I mentioned that good design should enable to replace any part of a system by a new piece of code with little pain. The first aspect to look at is really the “macro level”, i.e. packages, to ensure for instance that there are no cycles between packages. But to obtain modularity at any level of the design you also need to consider the “micro level”, i.e. the classes / methods, by keeping it loosely coupled and highly cohesive.

Read the rest of this page »

Codehaus has been officially accepted into Google Summer of Code 2010. Based on the great job done by Ben Walding previous years, we expect that several projects get funded at The Haus this year.
Ben has open a page for Codehaus projects to propose ideas they wish student could pick and develop. We have proposed 3 ideas that we think are interesting challenges for students and a great addition to the Sonar platform :

Read the rest of this page »

With version 2.0, Sonar now embarks the seventh and last axis of source code quality : Design & Architecture. The objective of this post is to start discussing what it can be used for and why it is so important.
To know if the design of your software is in a good shape, having a sense of observation and a good memory can most of the time do the trick. No real need to use a tool (whether it is UML diagrams, Sonar…) or to look at source code. If month after month, your software is able to evolve as quickly as the business requires and can handle the changes at a constant cost throughout time, then you can confidently conclude that the design of your application is in a good shape (and believe me, it is fairly unusual in the software development market !). If not, you should focus some attention on design as it is not going to get better over time and will become costly in the medium to long term.
To handle fearlessly upcoming changes, it is key that the software design has great modularity. That is to say, you can replace part of the system by a new piece of code with little pain. Reaching true modularity can only be achieved in a programming environment that has two main capabilities (two dimensions) : ability to assemble pieces of software and ability to recursively split a piece of software. However, these capabilities are necessary but not sufficient.

Read the rest of this page »

When used out-of-the-box, Sonar is a code quality radiator accessible by everyone at anytime. Like for JIRA, Hudson, a post-it dashboard or any other piece of the development toolset transparency is a key success factor for adoption. So, by default in Sonar, anyone can access any project under continuous inspection and navigate through it.

But of course, there are situations where securing Sonar is necessary. Let’s imagine for 2 minutes a consulting company that does development for customers and wishes to allow those customers to follow their own projects in Sonar. Since the company has many customers, it is necessary that group of projects can be isolated to make sure each customer only has access to his own projects. Prior to Sonar 1.12, this was only possible by having one instance of Sonar per customer.

Since Sonar 1.12 there are services available in the web interface to handle this and to cover the following use cases :

• Secure a Sonar instance by forcing login prior to access to any page
• Make a given project non accessible to anonymous
• Allow access to source code (Code Viewer) to a given set of people
• Restrict access to a project to a given group of people
• Define who can administer a project (setting exclusion patterns, tunning plugins configuration for that project, …)
• Define who can administer a Sonar instance

All those use cases can be implemented through the Sonar web interface and will take effect immediately. The way security is handled in Sonar is pretty classic as the security policy is based on the following three concepts : user, group and role (global or by project). Let’s take the example of the “Project roles” page available at project level :

Three roles are available at project level : Administrator, User and Code Viewer. Users and/or a groups of users can be associated to each of those roles to get the required permissions.

User and group can be first created through the “Users” and “Groups” services available in the administration configuration section. Here is the screenshot of the “Groups” service :

That was authorization, let’s now talk about authentication. By default, user authentication is done against the Sonar DB (user table) but an external authentication engine can also used : OpenLDAP, Microsoft Active Directory, Apache DS, Atlassian Crowd … Three identity plugins already exist : two open source LDAP Plugin, Crowd plugin and a commercial one Identity Plugin. They all use the public Sonar authentication extension point.

To conclude, it is possible since Sonar 1.12 to easily implement a robust enterprise security policy. Those new functionality have been done with no impact whatsoever on Sonar users who do not want to activate security and want to keep full transparency.

A change of year always gives to teams an opportunity to look back and measure what was accomplished… and then to start thinking of what the new year should be made of. I thought I’d share the output of the Sonar team retrospective.

At the end of 2008, very few people knew Sonar. The platform was made of a small community of early and eager adopters who were supporting the product strongly by giving feedback, asking for more functionality, making suggestions and testing new versions. It was also made of Sonar 1.5 that, looking back, was the foundation version of the platform. From this version, here is what was achieved in a year :

• A dynamic development activity on Sonar core with 7 major releases since 1.5.
• The transformation of Sonar from a tool to an extensible platform with more than 20 extension points.
• More than 30 open source plugins have been build to extend Sonar core using those APIs, and more that are not open source.
• the number monthly downloads has been multiplied by 10 during the year from 300 to 3,000.
• Sonar has been given a heart called Squid that makes Sonar much more than an integration tool. Several metrics that do not exist elsewhere are calculated by Squid.
• More than 4’000 emails exchanged on mailing lists and 1,000 Jira issues created.

So after all this, what could be an exciting challenge for 2010 ? We have set ourselves 2 very ambitious objectives for 2010 which should make the Sonar community continue growing :

• Design analysis : we like to say that there are seven technical axes of code quality analysis (we call them the seven sins of the developer). Sonar currently covers sixth of them and the last one is for us the most important one with unit tests : Design & Architecture. Sonar 2.0 planned for February will start covering the 7th axis with O.O. metrics like LCOM4, RFC, DIT … cycles detection and DSM at package and class levels. All those information will be of course provided by Squid. Moreover, an architecture rule engine should quickly appear after Sonar 2.0.
• Multi-languages : last but not least, give a real go at other languages. By the end of the year, we expect that plugins are available to cover properly : Java, PL/SQL, Flex, C/C++, Cobol, PHP and maybe more :-)

Here is a part of the program for 2010. I have now to leave you to start working on this as I think I will not have much spare time this year !

There have been numerous debates around commented-out lines of code (line or block of code that was commented out at some point) and whether they should be left in the code or taken out. The outcome of those debates is almost systematically that they should be taken out sooner rather than later : in the Sonar Team, we generally consider than later means after code check in.
Here are the main reasons why old commented-out code is an abomination :

• It always raises more questions than it gives answers
• Everybody will forget very quickly how relevant the commented code is
• This is distraction when going down the code as it stops the flow of eyes
• It is a bad SCM engine : Subversion, CVS and Git are really more trustworthy !
• The simple fact of understanding why code was commented out in the first place can take a lot of time

But the worst of all is in my opinion the fact that commented-out code appeals commented-out code, similarly to The Broken Windows Syndrome ! All this was reinforced by Uncle Bob a few months back in his Clean Code Tip of the Week #7.

Read the rest of this page »