Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Serie of article about Sonar installation
By Jean-Pierre Fayolle, 7 April 2013
Jean-Pierre Fayolle continues his series of articles about Sonar installation with 5 new articles:
Install Sonar – The Sonar webap
Install Sonar – Sonar Runner
Install Sonar – First analysis with Sonar Runner
Install Sonar – Jenkins
Install Sonar – The Sonar Jenkins plugin

Sonar is a super-radiator for code quality and as such, you can expect it brings value to all stakeholders in a development group. To achieve this, Sonar must be able to show only relevant information in a certain context and shut off the noise to facilitate investigation and decision making. In this post, I will show how to customize Sonar to fit your needs by:

• creating filters that choose components and metrics to report on
• building your own widgets and dashboards
• selecting default dashboards displayed
• using the notification services and stay tuned

To start customizing Sonar, you first need to log in.

Creating Your Own Filters

The mesures service located in the top navigation bar enables to choose which components you wish to retrieve and which measures you want to display for these components. Once you have chosen these criteria, you will get what we call a filter. A filter can be saved, updated… Filters are fully compatible with differential services, so you can display variations as well.

We will see later on how to display a filter in a dashboard. See the Measures Service documentation page to learn more on filters.

Building Your Own Dashboards

To make sure you maximize value in Sonar, you have the ability to create your own dashboards and select the widgets they display. Two types of dashboard are available:

• Projects dashboards: to display quality indicators on a component such as a Project, a View or a Developer. Once you create such dashboard, it will be available to any component.
• Global dashboards: to mix any information on different projects. A global dashboard will only be available on the home page. You can look at Nemo for an example.

To create a new dashboard, you can use the Manage Dashboard link from the home page (for a global dashboard) or from a project page (for a project dashboard). Once the dashboard is created, you can then configure by a drag & drop of widgets.

There are many available widgets, but to configure a widget that uses your own filter, you should pick the “Measure Filter as List” or “Measure Filter as Tremap” widgets and choose the filter you created.

Choose Default Dashboards

Now that you know how to customize Sonar for your own needs, you also might want to customize the default dashboard that anyone can see. Once you have created the dashboards you want to use by default, you will need to share them. Once they are shared, go to settings, configuration and Default Dashboards. You can pick from there what you want as default for global and project dashboards.

Subscribing to Notifications

Finally, to stay tuned, you can subscribe to notifications that you will receive by email. Go to YourUserName > My Profile and tick what you want to subscribe to in the Notifications section.

You may also want to receive a quality report on a regular basis. Thanks to the Report plugin, you can select which global dashboards you would like to receive by email as a PDF report and how often.

Time now to give it a try. Enjoy and give us feedback!

Edit: iceScrum R6#4 has been replaced by two successive minor versions that fix these bugs:

• ICESCRUM-648 – Estimation with « . » as decimal separator isn’t saved when creating a task (fixed in R6#4.2)
• ICESCRUM-524 – Impossible to delete stories from the backlog (fixed in R6#4.2)
• LDAP configuration is reinitialized (iceScrum Pro, fixed in R6#4.1)

Hello everybody,

This new version of iceScrum brings the following bug fixes:

R6#4.2 – R6 – Sprint 4 (08/03/2013 – 12/04/2013) Bug fixes

• ICESCRUM-523 – Tags lost when updating an element in table view
• ICESCRUM-645 – Better error handling on file and network interface exception when starting iceScrum
• ICESCRUM-643 – Display issue in the modal window when batch accepting stories in the sandbox
• ICESCRUM-629 – It is often impossible to delete a project
• ICESCRUM-637 – Sometimes, stories can’t be deleted
• ICESCRUM-632 – It is impossible to delete the last sprint
• ICESCRUM-636 – Pushed data don’t have the proper charset
• ICESCRUM-634 – Attachment limit is also displayed in tags (iceScrum Cloud)

Some changes require additional explanations, here they are:

• ICESCRUM-516 – Unstable language

Some users reported random language changes when using the tool. Please not that this may have lead to errors in iceScrum regarding invalid dates. Indeed, dates have two format depending on the language. Your feedback is welcome in order to ensure that all language / dates problem are solved by this fix.

• ICESCRUM-641 – No more IE6, IE7 and IE8 support at all

We wrote a blog post in order to explain why iceScrum won’t be accessible anymore for outdated Internet Explorer versions, and why we think it’s good for the future of iceScrum: https://www.kagilum.com/blog/about-browser-compatibility/

• ICESCRUM-640 – Unwanted logout after 30 min of inactivity

In the previous sprint, some technical changes under the hood restored the default behavior of our security system, which logs out users after 30 minutes of inactivity. Such a behavior is quite common on web applications so we decided to give it a try. However, agile development is user driven and your feedback isn’t very positive about that so this timeout will disappear in R6#4!

iceScrum Pro users, here are manual operations required in order to ensure this upgrade works smoothly.

• ICESCRUM-644 – Disabling LDAP plugin doesn’t work (iceScrum Pro)

Because of this issue, LDAP authentication may be disabled after the upgrade. Please ensure that you re-enable it so your users can log in!

• After upgrading, there is a corner case where your licence can be displayed as invalid. If such a problem occurs, please contact us and we will solve it immediately.
  

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Code Quality Tools Review for 2013: Sonar, Findbugs, PMD and Checkstyle
By Adam Koblentz, 12 March 2013
When we released our Developer Productivity Report last year, it was the first time we asked our respondents about Code Quality Tools. Code quality tools fulfill a growing need, as our code bases become larger and more complex, and it’s important to try to automate your code checks as much as possible. They are pretty versatile and customizable, and typically they are integrated into your build process, but can also be run manually in a one-off fashion.

Dependency Inversion Principle
By Monte Wingle, 13 March 2013
This 20 minute video demo shows: How to install and start Sonar, A very simple java project with no dependency cycles, What creates a red mark (dependency cycle) on the Design page, A Sonar analysis showing the cycle, How to fix that red mark using the Dependency Inversion Principle, A final Sonar analysis showing a clean design page again with the functionality unchanged.

Install Sonar – Oracle Loopback Adapter
By Jean-Pierre Fayolle, 10 March 2013
We will discuss in this post how to install a Loopback Adapter needed to use Oracle on a standalone station, such as a laptop for example. The first thing to do is to check if you already have one on your machine.

Analyze a Web Dynpro Java project with Sonar
By Tobias Hofmann, 21 March 2013
Sonar offers two “basic” profiles to analyze a project. Sonar uses Findbugs to analyze not only the source code, but the binary version for violations and possible bugs too. “Sonar way” is looking at the source code. This allows for finding the most common violations with minimum effort. “Sonar way with Findbugs” also takes the CLASS files into consideration.

Install Sonar – Oracle user
By Jean-Pierre Fayolle, 25 March 2013
Today we will use this console to create an Oracle User that will allow us to have a SONAR schema in our database. If you did not keep the url of the Oracle console, no problem. You should have a Windows menu that allows to launch it. Note that you have as many consoles as databases installed, and a corresponding Windows service. We shall see at the end of this article how to disable it.

This is it! After talking about it, internally at SonarSource, for 2 years and after a failed attempt last year, we are discontinuing the support of Java 5 runtime for the Sonar platform. Here are a few questions you might have on this:

What does it means exactly?
This means that you will require a JVM greater than 6 to execute Sonar Server or Sonar Analyzers. So far, these could be run also on a JVM 5.

Can I still analyze my Java 5 project with Sonar?
Absolutely, you will still be able to analyze your Java 5 projects the very same way.

What is the reason for this?
There are 2 main reasons for doing this:

• Oracle stopped Java 5 support a long time ago and it is now time to move on for us
• This will enable us to benefit from many libraries or versions of libraries that only support a JVM 6

It also has nice side effects on the performances. For example, our parsers will run 20% faster when you move from Java 5 to Java 6.

Why did we back out last year?
We made an attempt last year, but encountered a couple of issues. The main one was that Sonar Jenkins plugin did not let you choose the JVM you want to use for the Sonar analysis – it had to be the same as the one configured for the job. This was fixed in version 2.0 of the plugin.

Can I still execute Sonar with a JVM 5?
You might be able to but we will only provide support if you use a JVM 6.

Please come on the user mailing list, should you have any question or wanted to discuss this further.

Bonjour à tous,

Voici une nouvelle version d’iceScrum. Suite à des problèmes de stabilités, nous avons décidé de ne pas sortir de version à la fin du Sprint 2. Par conséquent, cette version inclut les développements du Sprint 2 et du Sprint 3. Nous avons nommé cette version d’après ce dernier par souci de cohérence.

IMPORTANT : pour les utilisateurs de Tomcat 6, une opération manuelle est nécessaire !

Cette opération préviendra l’erreur suivante : « java.lang.NoClassDefFoundError: javax/servlet/http/Part »

• Instructions : comme avant toute mise à jour, sauvegardez votre base de données. Ensuite, au choix :
  - Migrer vers Tomcat 7. Si possible, préférez ce choix. Dans ce cas, n’oubliez pas de supprimer le jar tomcatDir/lib/tomcat-jdbc.jar comme indiqué dans la documentation d’installation.
  - Ajouter le jar geronimo-servlet_3.0_spec-1.0.jar au répertoire lib de Tomcat 6.

• Explication : Dans le but de vous fournir une meilleure expérience à chaque nouvelle version d’iceScrum, nous mettons à jour les bibliothèques que nous utilisons lorsque cela apporte de la valeur. Ainsi, l’opération présentée ci-dessus est requise (pour utiliser Servlet 3.0) suite à la mise à jour de la bibliothèque Atmosphere. Celle-ci nous a permis d’améliorer les performances du Push et de préparer iceScrum à l’utilisation des WebSockets. A terme, le support de Tomcat 6 sera abandonné au profit de ces nouvelles technologies.

R6#3 – Sprint 2 (29/01/2013 – 08/02/2013)
et Sprint 3 (09/02/2013 – 01/03/2013) Nouvelles fonctionnalités et améliorations

• ICESCRUM-347 – Reste à faire initial pour les tâches
• ICESCRUM-354 – Commenter les tâches
• ICESCRUM-4 – Email à la création d’une tâche urgente (sprint en cours)
• ICESCRUM-15 – Email à la suppression dans le bac à sable (la raison de la suppression peut être indiquée)
• ICESCRUM-446 – Email au déplacement vers la Icebox (iceScrum Pro)
• ICESCRUM-476 – Plus grande zone de texte pour la description des stories et les tests d’acceptation
• ICESCRUM-481 – Amélioration du formatage du texte riche
• ICESCRUM-497 – (Technique) Mise à jour de la technologie de push pour de meilleures performances
• ICESCRUM-624 – Logs détaillés pour la sécurité et l’authentification
• ICESCRUM-493 – Changer le type d’authentification de l’utilisateur (externe LDAP / interne) dans l’administration (iceScrum Pro)
• ICESCRUM-499 – Mettre à jour l’identifiant utilisateur dans l’administration (iceScrum Pro)
• Documentation LDAP réécrite (iceScrum Pro)
• Documentation Email Hooks (iceScrum Pro)

Corrections de bogues

• ICESCRUM-443 – Information perdue lors de la copie de story (pièces jointes, commentaires…)
• ICESCRUM-469 – Seul le format de date US est supporté pour la locale anglaise
• ICESCRUM-616 – Le reste à faire maximum du sprint burndown est incorrect
• ICESCRUM-610 – La mauvaise release est affichée par défaut dans le plan de release
• ICESCRUM-486 – Les lignes vides ne sont pas affichées dans les commentaires et tests d’acceptation
• ICESCRUM-487 – Les emails ne sont pas envoyés si une adresse est incorrecte
• ICESCRUM-463 – Les filtres du Finder disparaissent avec un zoom à 110%
• ICESCRUM-596 – L’ordre de la liste déroulante pour le type de tâche est incohérent
• ICESCRUM-594 – Le plan de sprint n’est pas affiché s’il n’y a pas de sprint à faire
• ICESCRUM-597 – Lorsqu’un permalien requiert une authentification, celle-ci ne redirige pas vers le lien initial
• ICESCRUM-611 – Les liens des pièces jointes de l’aperçu sont brisés
• ICESCRUM-488 – Les liens des stories du flux RSS sont brisés
• ICESCRUM-612 – Les indicateurs embarqués pour la release on un bouton « fermer » inutile
• ICESCRUM-618 – Les infobulles ne disparaissent pas quand on change de vue (post-it / table)
• ICESCRUM-495 – Le bouton « Parcourir » pour attacher des documents ne s’affiche pas pour certaines locales
• ICESCRUM-500 – Les pièces-jointes sont perdues lors de la modification d’un élément en vue table
• ICESCRUM-626 – Le plan de release se charge indéfiniment lorsque le nom de la release comporte une apostrophe
• ICESCRUM-628 – La locale brésilienne affiche de l’anglais
• ICESCRUM-498 – Aucun document ne peut être attachés au niveau projet / release / sprint (iceScrum Cloud)

Notice et téléchargement

N’oubliez pas, vous pouvez essayer iceScrum Pro gratuitement afin d’évaluer ses fonctionnalités. Pour plus d’informations, rendez vous sur la page du produit ou dans sa documentation.

As many of my pair programming partners could tell you, I have the annoying habit of saying “Stop thinking” during refactoring. I’ve always known this isn’t exactly what I meant, because I can’t mean it literally, but I’ve never had a better explanation of what I meant until now. So, apologies y’all, here’s what I wished I had said.

One of the challenges of refactoring is succession–how to slice the work of a refactoring into safe steps and how to order those steps. The two factors complicating succession in refactoring are efficiency and uncertainty. Working in safe steps it’s imperative to take those steps as quickly as possible to achieve overall efficiency. At the same time, refactorings are frequently uncertain–”I think I can move this field over there, but I’m not sure”–and going down a dead-end at high speed is not actually efficient.

Inexperienced responsive designers can get in a state where they try to move quickly on refactorings that are unlikely to work out, get burned, then move slowly and cautiously on refactorings that are sure to pay off. Sometimes they will make real progress, but go try a risky refactoring before reaching a stable-but-incomplete state. Thinking of refactorings as horizontal and vertical is a heuristic for turning this situation around–eliminating risk quickly and exploiting proven opportunities efficiently.

The other day I was in the middle of a big refactoring when I recognized the difference between horizontal and vertical refactorings and realized that the code we were working on would make a good example (good examples are by far the hardest part of explaining design). The code in question selected a subset of menu items for inclusion in a user interface. The original code was ten if statements in a row. Some of the conditions were similar, but none were identical. Our first step was to extract 10 Choice objects, each of which had an isValid method and a widget method.

before:

if (...choice 1 valid...) {

  add($widget1);

}

if (...choice 2 valid...) {

  add($widget2);

}

... 

after:

$choices = array(new Choice1(), new Choice2(), ...);

foreach ($choices as $each)

  if ($each->isValid())

    add($each->widget());

After we had done this, we noticed that the isValid methods had feature envy. Each of them extracted data from an A and a B and used that data to determine whether the choice would be added.

Choice1 isValid() {

  $data1 = $this->a->data1;

  $data2 = $this->a->data2;

  $data3 = $this->a->b->data3;

  $data4 = $this->a->b->data4;

  return ...some expression of data1-4...;

}

We wanted to move the logic to the data.

Choice1 isValid() {

  return $this->a->isChoice1Valid();

}

A isChoice1Valid() {

  return ...some expression of data1-2 && $this-b->isChoice1Valid();

}

Succession

Which Choice should we work on first? Should we move logic to A first and then B, or B first and then A? How much do we work on one Choice before moving to the next? What about other refactoring opportunities we see as we go along? These are the kinds of succession questions that make refactoring an art.

Since we only suspected that it would be possible to move the isValid methods to A, it didn’t matter much which Choice we started with. The first question to answer was, “Can we move logic to A?” We picked Choice. The refactoring worked, so we had code that looked like:

A isChoice1Valid() {

  $data3 = $this->b->data3;

  $data4 = $this->b->data4;

  return ...some expression of data1-4...;

}

Again we had a succession decision. Do we move part of the logic along to B or do we go on to the next Choice? I pushed for a change of direction, to go on to the next Choice. I had a couple of reasons:

• The code was already clearly cleaner and I wanted to realize that value if possible by refactoring all of the Choices.
• One of the other Choices might still be a problem, and the further we went with our current line of refactoring, the more time we would waste if we hit a dead end and had to backtrack.

The first refactoring (move a method to A) is a vertical refactoring. I think of it as moving a method or field up or down the call stack, hence the “vertical” tag. The phase of refactoring where we repeat our success with a bunch of siblings is horizontal, by contrast, because there is no clear ordering between, in our case, the different Choices.

Because we knew that moving the method into A could work, while we were refactoring the other Choices we paid attention to optimization. We tried to come up with creative ways to accomplish the same refactoring safely, but with fewer steps by composing various smaller refactorings in different ways. By putting our heads down and getting through the other nine Choices, we got them done quickly and validated that none of them contained hidden complexities that would invalidate our plan.

Doing the same thing ten times in a row is boring. Half way through my partner started getting good ideas about how to move some of the functionality to B. That’s when I told him to stop thinking. I don’t actually want him to stop thinking, I just wanted him to stay focused on what we were doing. There’s no sense pounding a piton in half way then stopping because you see where you want to pound the next one in.

As it turned out, by the time we were done moving logic to A, we were tired enough that resting was our most productive activity. However, we had code in a consistent state (all the implementations of isValid simply delegated to A) and we knew exactly what we wanted to do next.

Conclusion

Not all refactorings require horizontal phases. If you have one big ugly method, you create a Method Object for it, and break the method into tidy shiny pieces, you may be working vertically the whole time. However, when you have multiple callers to refactor or multiple implementors to refactor, it’s time to begin paying attention to going back and forth between vertical and horizontal, keeping the two separate, and staying aware of how deep to push the vertical refactorings.

Keeping an index card next to my computer helps me stay focused. When I see the opportunity for a vertical refactoring in the midst of a horizontal phase (or vice versa) I jot the idea down on the card and get back to what I was doing. This allows me to efficiently finish one job before moving onto the next, while at the same time not losing any good ideas. At its best, this process feels like meditation, where you stay aware of your breath and don’t get caught in the spiral of your own thoughts.

September 2014

To Whom It May Concern,

I am writing this letter of recommendation on behalf of Kent Beck. He has been here for three years in a complicated role and we have been satisfied with his performance, so I will take a moment to describe what he has done and what he has done for us.

The basic constraint we faced three years ago was that exploding business opportunities demanded more engineering capacity than we could easily provide through hiring. We brought Kent on board with the premise that he would help our existing and new engineers be more effective as a team. He has enhanced our ability to grow and prosper while hiring at a sane pace.

Kent began by working on product features. This established credibility with the engineers and gave him a solid understanding of our codebase. He wasn’t able to work independently on our most complicated code, but he found small features that contributed and worked with teams on bigger features. He has continued working on features off and on the whole time he has been here.

Over time he shifted much of his programming to tool building. The tools he started have become an integral part of how we work. We also grew comfortable moving him to “hot spot” teams that had performance, reliability, or teamwork problems. He was generally successful at helping these teams get back on track.

At first we weren’t sure about his work-from-home policy. In the end it clearly kept him from getting as much done as he would have had he been on site every day, but it wasn’t an insurmountable problem. He visited HQ frequently enough to maintain key relationships and meet new engineers.

When he asked that research & publication on software design be part of his official duties, we were frankly skeptical. His research has turned into one of the most valuable of his activities. Our engineers have had early access to revolutionary design ideas and design-savvy recruits have been attracted by our public sponsorship of Kent’s blog, video series, and recently-published book. His research also drove much of the tool building I mentioned earlier.

Kent is not always the easiest employee to manage. His short attention span means that sometimes you will need to remind him to finish tasks. If he suddenly stops communicating, he has almost certainly gone down a rat hole and would benefit from a firm reminder to stay connected with the goals of the company. His compensation didn’t really fit into our existing structure, but he was flexible about making that part of the relationship work.

The biggest impact of Kent’s presence has been his personal relationships with individual engineers. Kent has spent thousands of hours pair programming remotely. Engineers he pairs with regularly show a marked improvement in programming skill, engineering intuition, and sometimes interpersonal skills. I am a good example. I came here full of ideas and energy but frustrated that no one would listen to me. From working with Kent I learned leadership skills, patience, and empathy, culminating in my recent promotion to director of development.

I understand Kent’s desire to move on, and I wish him well. If you are building an engineering culture focused on skill, responsibility and accountability, I recommend that you consider him for a position.

 

===============================================

I used the above as an exercise to help try to understand the connection between what I would like to do and what others might see as valuable. My needs are:

• Predictability. After 15 years as a consultant, I am willing to trade some freedom for a more predictable employer and income. I don’t mind (actually I prefer) that the work itself be varied, but the stress of variability has been amplified by having two kids in college at the same time (& for several more years).
• Belonging. I have really appreciated feeling part of a team for the last eight months & didn’t know how much I missed it as a consultant.
• Purpose. I’ve been working since I was 18 to improve the work of programmers, but I also crave a larger sense of purpose. I’d like to be able to answer the question, “Improved programming toward what social goal?”