Voici les défauts connus sur la R4#3 :

1. La migration avec PostgreSQL ne fonctionne pas. Ce défaut est corrigé dans la version R4#3.1
2. Dans l’assistant, le changement de rôle de celui qui crée le projet provoque une erreur. Ce défaut est corrigé dans la version R4#3.1
3. Quand iceScrum est installé dans Tomcat et qu’on arrête le serveur, il arrive que le process Java continue à s’exécuter, ce qui ne permet pas de réinstaller une nouvelle version d’iceScrum. Il faut d’abord arrêter le process (avec Linux et Mac, on lance la commande ps -ax pour récupérer le numéro du process puis un kill -1 avec ce numéro), enlever le répertoire icescrum de Webapps, mettre le nouveau war et relancer Tomcat.
4. Quand on modifie la couleur d’une feature, ce n’est pas immédiatement rafraichi au niveau des stories.
5. Le fonctionnement sur tablette et smartphone n’est pas optimisé.
6. Si le serveur est configuré avec un proxy, il peut arriver que l’attachement de fichiers ne fonctionne pas quand le nom du fichier contient des caractères exotiques.
7. L’attribut pour donner la valeur d’une feature propose des entiers dans le formulaire, mais dans la vue table, c’est restreint à la suite de Fibonacci (au lieu des entiers). Ce défaut est corrigé dans le build 220.
8. Erreur quand un membre de l’équipe dont le rôle est développeur quitte le projet (l’équipe).
9. Le drag and drop pour ordonner les stories dans le backlog ou les features ne fonctionne pas quand on agrandit la fenêtre. Ce défaut est corrigé dans le build 222.
10. Une story estimée à 0 passe à ? en vue table ou quand on active le sprint. Ce défaut est corrigé dans le build 233.
11. Selon la résolution utilisée, le dernier sprint du plan de release s’affiche sous le 1er et pas à côté du précédent (avec certaines versions de Firefox).
12. La copie des tâches récurrentes du sprint précédent ne fonctionne pas. Ce défaut est corrigé dans le build 227.
13. Le lien vers le fil RSS ne fonctionne pas. Ce défaut est corrigé dans le build 229.
14. Dans le bac à sable, lorsqu’on ajoute plusieurs stories à la suite en utilisant le bouton « Proposer et poursuivre » et qu’on utilise le template « en tant que … », seule la première story ajoutée conserve les informations saisies dans le template. Toutes les stories suivantes saisies perdent les informations du template. Ce défaut est corrigé dans le build 233.
15. Lorsque le backlog contient suffisamment de stories pour que les post-it remplissent la fenêtre il est impossible de sélectionner les post-it de la derniere ligne pour les déplacer. Ce défaut est corrigé dans le build 229.
16. Lien incorrect dans l’historique utilisateur d’un profil d’une personne.
17. On ne peut pas mettre à jour le reste à faire sur les tâches dans la vue table du plan de sprint.
18. Il est possible de passer une tâche à fini même quand le sprint n’est pas commencé en mettant son reste à faire à 0. Ce défaut est corrigé dans le build 233.
19. L’association d’une story à une feature est perdue lors de l’importation d’un projet exporté.
20. Lors du changement d’état d’une story, il arrive qu’on ait le message « Cannot create a session after the response has been committed ». Dans ce cas là, l’information n’est pas poussée vers les autres utilisateurs connectés, mais le changement d’état est effectué correctement.
21. Avec IE7 et IE8, l’affichage du plan de sprint ne fonctionne pas, à cause d’erreurs JavaScript. Ce défaut est corrigé dans le build 233.
22. Quand une tâche a un fichier attaché, le lien pour le lire en vue Modifer ne fonctionne pas. Solution de contournement : passer par le quicklook.

Si vous en trouvez d’autres sur cette version, merci de les ajouter dans le bac à sable iceScrum.

The Sonar team is proud to announce the release of Sonar 2.13. This new version includes 60 improvements, bug-fixes and also some new features that we believe are worth stopping your daily work for a couple of minutes to check out : ability to create manual reviews / violations anywhere in the code, ability to create action plans and an extended search engine.

Extended search engine

The search engine will now return not only projects but also modules, package and files. A picture is worth a thousand words :

Add a review on any piece of code

Whenever a quality defect is detected “manually”, the person who detected it has the ability to inject a violation directly into Sonar:

The related violation is then displayed within the source code and will be accounted for in metrics after the next analysis of the project:

Action plans

Action plans can be created to group reviews together.

An action plan can be associated to each violation

And then it is possible to review progress in a widget of a dashboard

Hotpots 2.0

The previous release allowed to use hotspot widgets in its own dashboards (see Sonar 2.12 in screenshots). It’s now possible to customize, rename or even delete the default dashboard named “Hotspots”.

Time now to give a try to the new version and to read the installation or upgrade guides.

Le plan de sprint constitue le cœur du suivi d’un sprint par l’équipe. Avec iceScrum les tâches, représentées par des post-it virtuels, sont positionnées dans 3 colonnes : à faire, en cours, fini.
Les possibilités de bouger les tâches varient selon les rôles. Parmi les rôles présentés dans un article précédent, c’est en particulier pour le ScrumMaster que les possibilités sont les plus étendues.

Pour en savoir plus sur ce que peut faire un ScrumMaster -et aussi les autres membres de l’équipe- lire l’article complet.

Nous avons vu les rôles iceScrum dans un précédent article : le ScrumMaster, le Product Owner et les Développeurs qui forment l’équipe Scrum, plus les StakeHolders.

Ceux-ci ne participent pas aux sprints comme les autres et dans iceScrum l’accès qu’ils ont sur les différentes vues est souvent en lecture seule. Cependant, c’est différent pour le bac à sable. Les StakeHolders peuvent notamment proposer des stories et les suivre.

Pour en savoir plus sur ce que peuvent faire les SH et les autres avec les stories, lire l’article complet.

 

iceScrum est d’abord un outil Scrum, on y retrouve naturellement les 3 rôles majeurs que sont le Product Owner, le ScrumMaster et le membre de l’équipe, qu’on appelle aussi Développeur.

Une équipe de développement est donc composée de Développeurs (DEV) et parmi eux d’un ScrumMaster (SM) et d’un Product Owner (PO).

Il est d’usage d’appeler StakeHolders (SH) les personnes qui sont intéressées par les résultats de ce que fait l’équipe, mais qui ne réalisent pas eux-mêmes le travail. Comme un de piliers de Scrum est la transparence, un SH voit ce que fait l’équipe.

Lire la suite de l’article.

Pour démarrer rapidement avec iceScrum dans le but de le tester, une façon simple est d’installer le « bundle » (il y a encore plus simple : allez sur iceScrum Cloud).

Pré-requis :

• Machine Virtuelle Java (JVM) 1.6 ou supérieure : JDK installée, avec les variables JAVA_HOME ou JAVA_JRE présentes et indiquant le chemin (vers la JDK pour JAVA_HOME)
• Navigateurs internet : InternetExplorer 7+, Firefox 3+, Safari 3+, Chrome

Installation :

1. Téléchargez la dernière version du bundle.
2. Décompressez-le dans le dossier de votre choix.
3. Ouvrez ce dossier.
4. Dans le fichier config.properties, changez : grails.serverURL = http://[url_to_icescrum]/[context_name] (par défaut c’est http://localhost:8080/icescrum)
   
5. Exécutez le fichier « start.bat » sous Windows ou lancez « start.sh »  dans un terminal sous Unix/Linux (et Mac). Vérifiez les droits d’exécution (sous Unix, faire un chmod u+x *.sh dans les répertoires bundle et bundle/server/bin) et l’ouverture du port 8080.
6. Dans votre navigateur, tapez l’URL : http://[host_adress]/[web-app] (par exemple, http://localhost:8080/icescrum).
7. Il ne vous reste plus qu’à vous enregistrer : cliquez sur le bouton « S’enregistrer », remplissez le formulaire et validez. Vous pouvez maintenant créer un projet.

L’utilisation du bundle ne constitue pas une installation pérenne, elle doit être réservée à des fins de test.

Veuillez noter que l’utilisateur lançant le serveur Tomcat doit posséder les droits d’écriture sur dossier Tomcat.

Pré-requis

• Machine Virtuelle Java (JVM) 1.6 ou supérieure,
• Serveur d’application web Java compatible servlet 2.4.
• Navigateur : InternetExplorer 7+, Firefox 3+, Safari 3+, Chrome
• L’installation d’une Base de données n’est plus indispensable, iceScrum est maintenant livré par défaut avec une utilisation de HSQLDB (un gestionnaire de BD Java, sur fichiers)

Recommandations

• Votre conteneur web devra bénéficier d’une bonne quantité d’allocation mémoire pour iceScrum : au moins 512 Mo.
• Ajoutez au minimum ces options de paramétrage de la JVM (variable d’environnement JAVA_OPTS) : -Xmx512M -XX:MaxPermSize=512M.

Installation

1. Téléchargez la dernière version du WAR sur le site.
2. Copiez le WAR dans le répertoire racine <web-apps> de votre conteneur ou utilisez l’outil d’administration de votre serveur d’application pour réaliser le déploiement du WAR.
3. Dans le fichier config.properties, changez : grails.serverURL = http://[url_to_icescrum]/[context_name] (par défaut c’est http://localhost:8080/icescrum)
   
4. Dans le cas d’un serveur Tomcat, modifiez votre fichier server.xml de manière à ce que le connecteur catalina possède la configuration suivante :
   
   <Connector port= »8080″ protocol= »org.apache.coyote.http11.Http11NioProtocol »

   			   connectionTimeout="2000"
   			   maxThreads="500"
                  URIEncoding="UTF-8"/>

5. (FACULTATIF) Si votre conteneur est « récent » (Tomcat6, Glassfish, …), il se peut qu’il inclut des librairies utilisées dans le WAR. Dans ce cas, supprimez les fichiers suivants à l’intérieur du WAR (en utilisant un utilitaire d’archives ou en les supprimant du répertoire de déploiement) : el-ri.jar, el-api.jar, jsf-api.jar, jsf-impl.jar, myfaces-api.jar, myfaces-impl.jar
6. Démarrez votre serveur
7. Dans votre navigateur, tapez l’URL : http://[host_adress]/[web-app] (par exemple, http://localhost:8080/icescrum).
8. Il ne vous reste plus qu’à vous enregistrer : cliquez sur le bouton « S’enregistrer », remplissez le formulaire et validez. Vous pouvez maintenant créer un projet.

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

Sonar and JaCoCo
By Raghu, 1 December 2011
I am a fan (and regular user) of Sonar, a platform to manage code quality. The 2.12 release of Sonar, which happened yesterday, introduced a bunch of new features including Java 7 support and the availability of Jacoco into Sonar core.

Industrialiser vos projets Flex avec Hudson, Maven, Sonar, FlexPMD et FlexCPD
By Fabien Nicollet, 5 December 2011
Dans le monde Java, il existe de nombreux outils permettant de vérifier l’intégrité de votre code (tests unitaires) mais aussi pour vous assurer que la qualité de votre code est respectée. Ces outils vous permettent d’assurer la robustesse des applications que vous créez.

My Testing and Code Analysis Toolbox
By Jens Schauder, 11 December 2011
Last week we kicked of a “Testing Skill Group” at LINEAS, a group for exchanging knowledge about testing. One question that came up over and over again in various flavors was: What tools are there for testing and analyzing your code? So here is my personal answer for this, in the approximately order I tend to introduce them into projects…

Open Source & code Legacy
By Jean-Pierre FAYOLLE, 18 December 2011
There are more and more solutions of analysis of code which allow to measure the quality of your applications. Most are sold by software vendors, and we had the opportunity to verify that these solutions are expensive to buy, to implement and to use (Disposable software). In response, the last decade has seen the rise of the Open Source alternative to proprietary software.

Flex + ( Ant | Maven ) + Sonar
By Jozef Chutka, 5 December 2011
The title may sound like there are two possible ways how you can have your source code analyzed and published to sonar, but you better do not rejoice prematurely. After spending couple of hours trying to figure out how to make it work using ant I may have hit some nice articles, however sonar-ant-task seems to have major issues with sonar version 2.8. The solution is maven!

Nous publions une nouvelle version qui corrige 2 défauts de la R4#3 :

1. La migration ne fonctionne pas avec PostgreSQL.
2. Dans l’assistant, le changement de rôle de celui qui crée le projet provoque une erreur.

Ceux qui ont téléchargé la R4#3 et qui ne sont pas touchés par ces défauts n’ont pas besoin de mettre à jour vers la R4#3.1

La version R4#3 apporte des nouveautés intéressantes.

En voici un résumé :

1. Les commentaires sur les stories (visibles dans la vue détails) sont désormais sauvegardés dans l’export, ce qui fait qu’on les retrouve après un import.
2. Les activités sur les stories (ajout, changement d’état, commentaire) sont sauvegardées dans l’export, on les retrouve aussi après un import.
3. Un attribut Id a été ajouté à chaque objet iceScrum : story, feature, tâche, acteur. Cet attribut est conservé après un import, il permet donc d’identifier de façon unique un objet. C’est cet attribut qui est affiché dans les différentes apparitions d’un objet (post-it, ligne de tableau, quick look, détail).
4. Amélioration de la génération de sprints dans une release : correction du défaut sur le dernier sprint, ajout de messages d’information.
5. Les info-bulles sur les stories et les sprints s’affichent à nouveau dans le plan de release.
6. Un message prévient que les tâches seront perdues quand on tente de dissocier une ou plusieurs stories d’un sprint.
7. Le système de push qui était défectueux dans la R4#2 fonctionne correctement (ce qui corrige le problème « session already committed » rencontrés par certains utilisateurs).
8. Améliorations d’ergonomie pour tous les « drag and drop ».
9. On peut maintenant faire du « drag and drop » sur tablette et smartphone (iOS et Android).

Voir les défauts connus sur cette version.

Most IT people know Thoughtworks and its charismatic technical leader / evangelist Martin Fowler. But probably fewer know the Thoughtworks Technology Radar whose first publication was done in January 2010.

According to their authors :

The ThoughtWorks Technology Advisory Board is a group of senior technology leaders within ThoughtWorks. They produce the ThoughtWorks Technology Radar to help decision makers understand emerging technologies and trends that affect the market today. This group meets regularly to discuss the global technology strategy for ThoughtWorks and the technology trends that significantly impact our industry.

In its last publication (July 2011), Sonar platform made its first appearance in the “Assess” circle : “Worth exploring with the goal of understanding how it will affect your enterprise”

Of course, SonarSource team was very proud of this but this is not the point here. Indeed, Sonar is a platform to manage quality among other platforms that have been around for a while : CAST Software, McCabe, Klocwork… So why adding now a QA tool to the radar and why choosing Sonar ? Is this because of its growing open source community : 5,000 downloads and 1,000 emails by month ? For its multi-technology capability in Java, C#, COBOL, PHP, PL/SQL, ABAP… ? Is it for is governance extensions: SQALE or Portfolio Management? Maybe, but I am pretty sure that an additional reason has led Thoughtworks experts to make this choice.

From inception, Sonar was not developed as “just yet an other quality reporting tool” but as a mean to continuously manage and fight back technical debt. This might sound like a subtle semantic difference but this actually makes a big difference. SonarSource team has grown with Agile methodologies and with those methodologies, source code is always very much in the center of focus: it should be able to mutate constantly over time to embrace changes. This key capability to do refactoring at any point in time is so important that the Technical Debt metaphor was early introduced by Agile practitioners.

After 4 years of development and 38 releases of Sonar we, at SonarSource, deeply know what “Change” means! In such evolving context, processes, planing, documentation, specifications, … they all matter but what’s about source code ? Some would like to consider source code as a black box without too much value whose development can be easily outsourced. With such an approach, the goal of a quality platform is just to report from time to time how well a blak box comply to some pre-defined quality standards. We do think this is a mistake !

Source code should be considered as a white box that each stakeholder (developer, project manager, IT director, quality consultant, customer, …) can look at any point of time to understand what happens, to initiate discussions and to make decisions. What ever is the quality of your processes, documentation or specifications, bad code will always lead to failure. Therefore when bad code is injected, it should be immediately detected, fought back and analysed to understand why this crappy code has been injected. Waiting several months to detect technical debt is a huge waste as per Lean principles.

Adopting Sonar means much more than simply installing a tool to comply to some QA or security standards … it means that quality of source code really matters and that the ability to daily manage your Technical Debt is key to sustain a continuous delivery approach and to embrace business changes: Continuous Inspection has entered the game !

La version R4#2 apporte des corrections aux défauts trouvés dans la R4#1, plus quelques améliorations d’usage.

En voici un résumé :

1. Correction du défaut empêchant la migration de la R4 à PostgreSQL
2. iceScrum fonctionne maintenant avec SQL server
3. Correction du défaut sur la création de tâche lorsque Java 1.7 était utilisé
4. Correction du défaut d’affichage lorsque l’on agrandit une zone de saisie de texte (champs « description » lors de la création d’une story par exemple)
5. Un message prévient que s’il n’y a pas de sprint suivant, des tâches associées aux stories non finies peuvent être perdues lors de la clôture du sprint
6. On peut désormais faire des modifications sur plusieurs stories consécutives dans la vue table du backlog
7. Quand on déplace une story du backlog réduit (dans le widget de gauche) vers le plan de release, elle n’apparait plus aux deux endroits
8. Les avatars qu’on se choisit avec des images externes sont bien affichés
9. L’estimation de la valeur des features se pratique avec une suite d’entiers, quel que soit le choix fait dans les pratiques, par exemple Fibonacci
10. La liste Mes projets est désormais limitée à 10 projets, ce qui évite un mauvais affichage quand on avait beaucoup de projets. Un bouton Voir plus apparait lorsqu’on en a plus.
11. La génération de rapport pdf sur le plan de sprint fonctionne à nouveau
12. L’acceptation d’une story en tant que feature qui provoquait un affichage JSON fonctionne à nouveau
13. Lors de l’import d’un projet, le texte de description des tâches qui était échappé à tort est maintenant bien importé
14. La suppression d’une feature avec des stories associées est maintenant possible, les stories sont bien entendu conservées, sans feature associée

Il reste quelques défauts connus :

1. Les info-bulles sur les stories ne s’affichent pas dans le plan de release
2. Quand iceScrum est installé dans Tomcat et qu’on arrête le serveur, il arrive que le process Java continue à s’exécuter, ce qui ne permet pas de réinstaller une nouvelle version d’iceScrum. Il faut d’abord arrêter le process (avec Linux et Mac, on lance la commande ps -ax pour récupérer le numéro du process puis un kill -1 avec ce numéro), enlever le répertoire icescrum de Webapps, mettre le nouveau war et relancer Tomcat.

 

The Sonar team is proud to announce the release of Sonar 2.12. This new version includes more than 100 improvements, bug-fixes and also some new features that we believe are worth stopping your daily work for a couple of minutes to check out: Support of Java 7, Integration of JaCoCo in the Sonar core, Hotspots 2.0 and Display groups of duplicated blocks.

Hotspots 2.0

3 new widgets have been created that enable to embed hot spots into a project dashboard: most violated rules, most violated resources and hot spots on a specific metric. We continue the “widgetisation” effort of of all Sonar UI components in order to sooner or later provide full customization capability of the Sonar UI.

Support of Java 7 Syntax

This was a great opportunity to collaborate with both Checkstyle and PMD teams in order to help them support all java 7 language changes : Strings in switch statements, try-with-resources statements, improved type inference for generic instance creation (“diamond”), simplified varargs method invocation, better integral literals, and improved exception handling (multi-catch).

Integration of JaCoCo in the Sonar core

JaCoCo is now part of Sonar core, along with Cobertura. This means that not only can the coverage by unit test be calculated by JaCoCo natively, but also that coverage by integration tests is now much better integrated. Results are displayed in the same page than coverage by unit tests :

Note that Cobertura is still the default engine … but that’s just a matter of time to make Jacoco the default java code coverage engine. Just need more feedback from the community to make this switch.

Improved Display of Duplication Blocks

The ‘Duplications’ tab in the code viewer has been fully refactored to make it far more usable :

• Duplication blocks are visually grouped in case of “truplications” or more
• A code snippet is displayed by default on each group of duplicated blocks
• Duplicated blocks on external files can be seen without leaving the page

Don’t forget that since Sonar 2.11, the default PMD CPD engine has been replaced by the Sonar CPD engine which brings a unique feature : ability to track duplications across projects.

Project Events Management

The events management has been greatly improved to make it easier to use from the History page introduced in Sonar 2.11.

Time now to let you give a try to the version 2.12. Release notes are available in the download page. Reading the installation or upgrade guides is much recommended.

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

Code Quality Analysis in Deployment Pipeline with Gradle, Jenkins and Sonar
By edvorkin, 31 October 2011
Sonar is a tool that integrate a range of quality analysis tools into a single website. It provide one page visibility into quality of project source code. Developers and managers are interested in test coverage, code duplication, adherence to coding standard, cyclomatic complexity of the code and several other parameters…

Intégrer l’outil de supervision Sonar à Team Foundation Server 2010
By Maxime ARNSTAMM & Simon Lehericey, 13 November 2011
Comme on l’a montré dans l’article précédent, Sonar est l’outil indispensable pour évaluer la qualité des projets d’une DSI au fil de l’eau.
Dans cet article nous aimerions présenter l’installation de différents composants de l’analyse Sonar et comment l’intégrer à votre usine de build TFS…

Lunch-N-Learn Ideas? Use Sonar Hotspots
By Clint Shank, 23 November 2011
Are you eager to get your team together for a lunch-n-learn with free pizza (and beer), but can’t come up with any ideas on which to present?

Or maybe you just want to get heads down and make some high impact, quality improvements to your code base, but don’t know where to start.

Setting up Sonar analysis for C# projects
By John M. Wright, 25 November 2011
In an effort to better understand some of the problematic areas of the C# codebase I work on, I recently setup an instance of the Sonar code analysis platform. Sonar is originally written for Java analysis and later added C# support. This posting walks you through my experience attempting to setup, configure and run the analysis.

Cette version R4#1 a mis un peu plus de temps à sortir que nous l’aurions souhaité. Bon, c’est comme ça, mais nous allons maintenant reprendre un rythme de publication plus soutenu.

Voici un résumé des modifications principales apportées par cette nouvelle version :

1. nouveau système de push avec amélioration spectaculaire des performances
2. nouvelle gestion de l’équipe et des changements de rôle
3. on peut maintenant enlever un membre d’une équipe
4. assistant de création de projet sensiblement amélioré
5. possibilité d’archiver et restaurer un projet
6. connexion Gravatar
7. fuseau horaire au niveau projet
8. publication de toutes les stories à partir du tableau de bord améliorée
9. on peut faire une recherche sur l’ID des objets
10. confirmation demandée sur activation et clôture de sprint et de release
11. affichage du nombre de stories (et des points) dans les bandeaux backlog et bac à sable
12. affichage du nombre d’heures restant à faire dans le bandeau du sprint
13. plan de sprint avec un avancement des tâches simplifié
14. on peut maintenant copier une tâche
15. affichage amélioré pour le texte dans un post-it
16. tri dans les vues tables (sauf dans la vue sprint)
17. affichage du reste à faire sur les tâches avec une décimale
18. web services (plus d’informations à venir)
19. support expérimental des web sockets (détails de la configuration à venir)
20. le russe est ajouté dans les langues (merci à Morozov)

Avant de migrer, faites un backup de la base de données.

SONAR – manage your code quality
By ShamanOfJava, 10 October 2011
Sonar is an open platform to manage code quality. It covers the 7 axes of code quality. Sonar supports a wide range of programming languages such as Java, C, C# etc. Through this article, we are going to see how to set up a Sonar Server and how to integrate a Java Project with it.

Measure Code Coverage of HtmlUnit Based Tests with Sonar and JaCoCo
By deors, 20 October 2011
This blog post is the third one in a series about Integration Tests with HtmlUnit. Finally, in this post we are going to show how to measure code coverage of HtmlUnit tests using Sonar, the popular Continuous Quality Assurance tool, and JaCoCo, a very interesting code coverage tool based on JVM agents instead of instrumenting bytecodes.

Separating Code Coverage With Maven, Sonar and Jacoco
By John Dobie, 23 October 2011
In this example I will expand upon my previous example of keeping your unit and integration tests in separate packages, and explain how to also produce code coverage statistics. For this I continue to use Maven, whilst adding Sonar and Jacoco to provide the code coverage.You can run the example below, but you will need to read the first article here to understand it.

Testing the new Sonar plugin for Gradle
By Luciano, 28 October 2011
If you were looking to convince your boss that Gradle is worth a try for your next project, look no further. Gradle 1 release candidate 5, released on October 25, brings the long awaited Sonar integration, and it works ridiculously well. How well? How about a one-liner.

A Free EC2 Cloud Server With Ubuntu, Jenkins And Sonar
By John Dobie, 29 October 2011
This example shows you how to create a free Amazon EC2 cloud based continuous integration and testing environment on Ubuntu. This is a low power server but it is useful for infrequent use. I personally tend to recommend Cloudbees, but this is handy when you need a free Sonar instance.

Code Quality Analysis in Deployment Pipeline with Gradle, Jenkins and Sonar
By Eugene Dvorkin, 31 October 2011
Sonar is a tool that integrate a range of quality analysis tools into a single website. It provide one page visibility into quality of project source code. Developers and managers are interested in test coverage, code duplication, adherence to coding standard, cyclomatic complexity of the code and several other parameters. Sonar is an open source product and can keep all your code metrics in database, as a matter of fact, in any relational database.

At SonarSource, we like eating our own dog food as much as possible. This is not always the case in software development, but in our case since we develop software for software companies, we can do it. We therefore have an instance of Sonar that analyses all our products daily. We’ve been using it for quite a long time to monitor code quality using features like alerts and SQALE indicators (Technical debt). We have defined a quality gate for the ecosystem that is fairly simple: the SQALE index must be A, the technical debt must not increase between releases and there must not be blocker or critical violations.

This quality gate is good to have but not efficient enough because defects introduced during a sprint have to be fixed all at the end. Instead, they should be fixed as they appear for better efficiency, similarly to code fix when a unit test breaks in continuous integration: this is what we call continuous inspection. We have done a lot of work this year to be able to provide better support for Continuous Inspection in Sonar and have added several services : differential views, SCM information and manual reviews integrated with email notification and with Sonar Eclipse. Manual reviews is really the new hot feature to complements existing services and making code reviews more effective.

How does this all fit together ? Well, this is the subject of this post… Get your Sonar 2.11 started, open Eclipse along with Sonar Eclipse 2.1, and follow the guide!

Develop, test, commit… and sleep well!

Managing code quality is like handling non-regression: while developing, one should not worry about this – a process should do it and notify you in case of an issue. You know already that you can refactor your code serenely because a continuous integration server will check that you did not introduce a regression, don’t you? Same applies when you improve a feature, the integration tests will make sure that you did not break anything, right? Similarly, you can feel comfortable when you think about quality of your code, Sonar will take care of it for you.

If you wish, you can also use Sonar Eclipse during your development to run local analyses and get realtime feedback. This is not yet optimum since you can only run full analysis and we are working hard on supporting incremental analysis.

Morning: code review time

After a good sleep and a cup of coffee, the first thing you want to know is how well you coded the previous day : log into Sonar and activate the “since previous analysis” differential views on your project: in a second, you see if new defects have been introduced. Those may identify – for instance – potential bugs, too complex classes or insufficiently tested methods. But whatever those violations are, you know that they increase the technical debt of your application. Fixing a violation is like fixing a bug: the sooner, the cheaper – as the context of the violation is fresh in your mind.

To track the newly introduced violations, use the differential violations drilldown. For every newly introduced violation – there shouldn’t be too many as you become more and more familiar with quality rules, create a review and assign it (or – when appropriate, flag it as false positive). If your source configuration management tool is supported by Sonar, finding the developer who introduced the violation is even simpler as his identifier appears next to the violation (as long as you installed Sonar SCM Activity plugin).

Though this process should only take a couple of minutes and will maximize the efficiency for reducing the technical debt, the ultimate objective is to provide a mechanism to notify the person who introduces a new violation.

Before developing again, clean your code

Once you’ve created all the reviews for the newly introduced violations, you can get back to your favorite IDE. But before starting coding, maybe you’d like to fix defects that you introduced the day before, wouldn’t you?

If you’re using Eclipse, you are lucky: Sonar Eclipse provides a very efficient way to work with reviews. Thanks to its Mylyn connector, Sonar Eclipse brings all the reviews assigned to you right inside your task view in Eclipse. There too, in a second, you see all the reviews that you have to work on. Open a review, click on a link to open the corresponding file, fix the defect and resolve the review to “fixed” so that it doesn’t show up in your task list any longer: this is that simple to fix a violation! And if it turns out that the fix is not obvious, you can start a thread of discussion on that review by adding a comment.

If you are not using Eclipse, you can still get notified when reviews are assigned to you. Just log into Sonar web application with your account and go to “My Profile” page to activate the email notification for reviews. This way, you won’t miss a single review assigned to you! Actually, you should probably activate email notification in both cases: indeed, if you created a review and assigned it to someone else, you may want to know if the review has been solved, or if the developer added comments on it.

And what about reviews that have been fixed?

Sonar handles code quality for you, but it also makes sure that fixed reviews have correctly been handled. During the next analysis, for each fixed review, if its corresponding violation has actually disappeared, Sonar will set the review to “closed”. If not, Sonar will reopen the review: in the morning, you will then see it again in your task list (or receive a mail) with the “reopened” status.

If you want to monitor more reviews – not only yours, you can use the Sonar review service that allows you to query reviews against their author, assignee, status, resolution, corresponding project or id.

That is it! This is how we are using differential views and manual reviews to run an effective continuous improvement process. Of course, you can adapt it – or even have a different one, to meet your needs. But keep in mind that the most important is to be sure that technical debt is under control!

More features are coming tu support Continuous Inspection further: create reviews on any code, filtering newly created violations by developer… Stay tuned!

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?”