2ème JUG : Sonar et les 7 péchés capitaux

L'URL courte de cet article est : http://inagua.ch/GRHuI

Arrivé vers 18h avec Johnny et Marc Elian… La salle est déjà bien remplie mais pas encore pleine… Je suis content d’être arrivé à l’heure, car il y a des rumeurs de surbooking dans le sens où des personnes non inscrites viendraient quand même… On en reparle en conclusion.

18h10 : je compte 63 personnes dans la salle… Plus Freddy et Simon “sur l’estrade”… Ah oui, Olivier est là bas, au fond à droite, caché dans la foule… Peut être pour relever le nom des récalcitrants ;))

Au programme, Sonar et les 7 péchés capitaux du développeur…

sonarsource

C’est parti. Xavier commence par présenter le programme du JUG jusqu’à l’été…

  • mars : maven avec Arnaud Eritier
  • avril : lambda-j avec Mario, le créateur du JUG du Tessin (ça c’est nouveau : Xavier n’en n’avait pas parlé le mois dernier !)
  • mai : JEE6
  • juin : Glassfish

Encore un nouveau sponsor pour le JUG qui se présente. Il s’agit de la société Kalyss. Je suis bien content de voir que le JUG “croule” sous les sponsors : c’est un signe de bonne santé.

Juste avant de commencer, Andrew propose à Freddy de dire un mot sur les XP Days… Et Freddy me donne la parole en tant qu’organisateur : je ne me fais pas prier pour promouvoir les prochains XP Day CH à Genève, le lundi 29 mars au Geneva Business Center. Les inscriptions sont ouvertes et les places limitées…

Puis Freddy commence son show…

Les 7 péchés capitaux

“Je connais pas mal de monde dans cette salle, j’ai l’impression d’être à une réunion des anciens combattants. Cela fait plaisir de voir cette dynamique autour des JUG”.

Si c’est pas une superstar ce Freddy ;)

Puis il commence par se présenter, comme co-fondateur de SonarSource, et demande :

  • ” Qui a un IDE toujours ouvert sur son poste ? “… 85% des participants lèvent la main.
  • ” Qui veut finir sa carrière comme développeur ?”… Là, seulement 15% osent courageusement lever la main…

Dont votre scribe et serviteur… Qui au passage se prend une blague amicale de son voisin… Blague néanmoins révélatrice de notre métier !

Au passage je me demande si ces 15% sont ceux qui n’ont pas d’IDE ouvert en permanence ;)

Freddy explique ensuite ce ratio par le fait que notre métier, celui du développement informatique, est jeune, constitué d’autodidactes (nous), et qu’il commence seulement à se professionnaliser

Il ajoute que notre métier est incompris !… Le gens ont des visions différentes de l’informatique et de l’informaticien… Et présente des photos d’une génération révolue de développeurs:

  • Einstein : “Celui là est tellement fort que je ne comprends pas ce qu’il fait”… Le développeur est sur une autre planète, c’est un savant génial.
    einstein

Au début de ma carrière, je me rappelle de ce projet où j’avais été sur  le site, en Espagne, pour du déploiement, accompagné d’un autre membre de l’équipe, plus âgé et expérimenté. Du coup, j’avais été marqué de l’entendre parlé très technique avec un utilisateur qui lui ne l’était pas du tout. Je n’ai pu m’empêcher de lui faire la remarque après. Il m’a alors répondu que cela rassurait le client !… Je pense, hélas, même aujourd’hui, que cette démarche fonctionne ! Quelle horreur.

  • Capitaine Flam : L’informaticien à tout pouvoir, de vie ou de mort, sur une portion (plus ou moins grande) du code… Comme à chaque fois que l’on parle de pouvoir, se pose la question des intentions ! Bonnes ou mauvaises ?
    capitainflam
  • Docteur Jones, l’aventurier, le solitaire : “mes méthodes de travail”… pas de partage. L’autre image associée à l’aventurier : le risque, la peur. Il n’y a pas de développement linéaire : quand va-t-on sortir de cette phase de debug ??
    jones

Attention Freddy, tu respectes mon idole, Docteur Jones ! De toute façon, Junior est plus fort que Superman… Alors si il veut, avec son fouet, il te…

Nous en arrivons donc naturellement à l’industrialisation :

  1. Il y a 10 ans, la gestion de projet était peu répandue (CVS, SVN…)
  2. Il y a 5 ans, c’était l’intégration continue
  3. Aujourd’hui c’est la traçabilité technique et fonctionnelle : quoi dans quelle version (de l’application) ??

Du coup quelle est notre mission (celle de l’informaticien) ?

  • Cela dépend du rôle de la personne
  • Une autre question fuse : “Qui bosse sur une application de moins de 3 mois ?”… 10 personnes lèvent la main dans la salle
  • Freddy reprend : le rôle de la majorité d’entre nous est de faire du neuf avec du vieux (c’est le cas de Play! qui renouvelle Java avec des idées existantes de Rails), tout cela avec un slide qui affiche “REuse/REduce/REcycle”

Il continue en disant que tout est maintenance d’application…

Du coup, d’aventurier on passe à gestionnaire… de code source.

Les méthodes agiles, avec le TDD, l’Intégration Continue, les refactorings… nous permettent d’avoir des démarches de développement linéaire.

Avant j’étais juge et partie : “Est-ce que l’Agilité fonctionne vraiment ??”

La réponse, maintenant, est OUI ! Avec sonar, depuis 1 an et demi on en est à 2500 tests unitaires et 200 tests d’intégration. Si on avait pas ce sentiment d’augmentation du ROI, on ne le ferait pas !

Avant l’arrivée de l’agilité, on avait cette alternance phase de codage de fou, debug, code de fou, debug. Avec l’arrivée de l’Agilité, l’alternance devient : test, code, test, code. C’est du développement linéaire.

Mais avec l’Agilité, les chefs de projet sont tout nus : c’est la transparence. On sait où sont les risques, les problèmes.

*C’est pas le cas du code source encore : pas de transparence totale.*

Puis Freddy nous montre ce slide avec l’évolution de l’Homme du presque singe à l’informaticien. Les outils évoluent tout comme nous. Ainsi, depuis le début du développement, nous avons connu des époques successives :

  1. l’éditeur de texte
  2. le gestionnaire de source
  3. le gestionnaire de projet techno : maven / ant
  4. la gestion de tickets
  5. l’intégration continue
  6. le refactoring  ==> clin d’oeil a mon dernier post sur les éditeurs de texte sans refactoring, ce que je trouve inadmissible à notre époque
  7. les tests unitaires
  8. l’inspection continue, avec des outils comme SONAR

J’aime bien ces prises de recul, ces exposés où l’orateur nous replace modestement dans une chronologie plus large… Cela me rappelle le show de Philippe Stark au TED.com. En dehors de son show, génial, il résumait l’apparition de l’Homme depuis la “soupe primitive”. Reprenant cette métaphore connue, où, considérant la vie de notre Terre sur une année, l’espèce humaine est apparue à la fin du 31 décembre ! Considérant qu’il reste encore plusieurs centaines de millions d’années, voire des milliards, de vie, nous ne sommes assurément le stade ultime de l’évolution de l’Homme, mais simplement un stade intermédiaire. Donc, là où nous en sommes actuellement, y compris dans le microcosme du développement informatique, n’est qu’un état transitoire !… Donc, respect, modestie, ouverture d’esprit sont de rigueur

Puis il a donné une définition d’un “bon” programme informatique : “un programme bien écrit est 1 programme où l’ajout d’une nouvelle/même fonctionnalité est constant dans le temps”.

Il a également donné une définition illustrée, une métrique tout à fait mesurable et donc factuelle d’un bon programme : c’est l’indice WTF ;))

wtf

Cela me rappelle une autre mesure tout aussi pertinente que nous avions identifié avec Coach sur l’un de mes projets : le score au démineur. Ce score est inversement proportionnel à votre investissement sur le projet ;) Dit autrement, plus vous passez du temps à autre chose, plus il est temps de changer de projet !

Derrière ces définitions, ce cache un buzword du moment : ” la dette technique

Freddy a filé la métaphore avec la vie courante : l’endettement c’est bien quand c’est maîtrisé (la maison ou la voiture, c’est maintenant que l’on a besoin, donc il est acceptable de s’endetter pour l’acquérir) : le problème est quand on se sur-endette, et que l’on frôle la banqueroute !

Les péchés capitaux dont on va parler, sont ceux qui alimentent cette dette technique (sur le code source). Il s’adresse alors à la salle en lui demandant quels sont ces péchés :

  • le copier / coller
  • le manque de commentaire [[ARGH !...]]
  • le test unitaire
  • la complexité
  • le code mort [[et même celui qui bouge encore ;)]]
  • la coulée de lave : endettement volontairement fait [[comme pour le crédit personnel : ton chauffe-eau tombe en panne, il faut le remplacer... mais si la voiture tombe aussi en panne, la maison s'effondre, ... c'est le surendettement !!]]

Freddy reprend ensuite les péchés un à un :

Le Code dupliqué : c’est quand on a une méthode getResourceBlock et getResourceBlock**New** juste à côté !

La mauvaise distribution de la complexité :

  • Qu’est ce qui est mieux : 1 méthode de complexité 30 ou 10 de complexité 3 ?
  • C’est pas la complexité globale qui compte mais l’aptitude à l’exploser en plein de petites complexités “gèrables”.

Diviser pour mieux régner !

Le mauvais design

Les bugs potentiels

Peu ou pas de tests unitaires : le cas du “switch” avec 15 “case”… Il faut modifier sans régression !

Le non respect des standards. Par exemple la trace de log d’erreur qui dit “Oups, y a un problème !”

Fonction de l’humeur !

Pas trop de commentaire. Freddy dit qu’il vaut mieux un code explicite peu commenter qu’un code pas explicite et surcommenté. Pour lui, il faut au moins commenter l’API.

Ces discussions ont le dont de me faire bondir !

  • Tout d’abord, l’agilité ne dit pas qu’il ne faut pas de documentation.
  • D’accord pour dire que l’utilisateur d’une méthode ne doit pas avoir besoin d’entrer dans le code pour savoir ce qu’elle fait
  • Mais il ne faut pas restreindre la documentation au commentaire au dessus de la méthode : la signature fait partie intégrante de la documentation.
  • Non, Dieu a dit qu’il fallait tout commenter… Ok, alors dit moi ce que cela apporte d’avoir :

/** Return the name.
*@return name
*/
String getName();

… 5 lignes de code, dont 4 lignes de bruit. Cela peut sembler du détail, mais retirer 80% de bruit dans du source, en phase de maintenance, je ne suis pas sûr que cela reste du détail…

Et puis bon nombre de javateux prônent l’avantage d’utiliser des langages à typage fort comme le Java… Pour moi c’est l’un des seuls avantages (la présence en dur des types de paramètres et du type de retour), alors n’allez pas rajouter du bruit : quand j’ai un getName qui retourne un String, que veux tu dire de plus ?

La démo

Puis, à l’aide de son Man in Black (Simon), Freddy commence la démo, avec ce slide : “Sonar a coeur ouvert”

sonar

Il présente Sonar et ses 3 composantes :

  1. le plugin maven
  2. la base de données
  3. l’interface web, qui n’est pas juste pour le reporting : elle permet aussi d’administrer, configurer les seuils d’alerte…

Arnaud Eritier, l’orateur du prochain JUG, sur Maven, a dit de Sonar que c’est le google earth du code

Puis un cours d’anatomie sur Sonar :

  • Le Tree map sur la page d’accueil permet de croiser 2 axes qualités. Chaque carré indique en effet 2 grandeurs, en fonction de sa taille et de sa couleur

Je trouve cette représentation géniale, mais quelle différence avec un camembert ? La taille et la couleur d’un quartier ne jouent-elles pas le même rôle ?

  • Le dashboard où l’on retrouve les 7 péchés capitaux (vision generale)
  • Et en cliquant sur un péché, on descend sur le détail et les premiers/d’avantage concernés. On peut cliquer pour accéder au code concerné (via le viewer de ressources)

Freddy en vient à aborder les réflexes des développeurs, réflexes qui ont une incidence sur le code.

Sur les projets open source, il y a une volonté de qualité :

  • si on a fait une boulette, on le dit même 5 ans après
  • même ceux qui présentent des patchs ont ce soucis de qualité de code
  • ce reflexe/qualité est moins présent en entreprise

Autre originalité, le service clouds qui présente les mots clefs du code, avec une couleur et une taille fonction de la fréquence.

Au départ, Sonar était une agrégation de package open source (un mashup).

Mais quand l’équipe a voulu mettre la barre un peu plus haut, certaines briques n’ont pas suivi, notamment JavaNCSS, ce qui a donné naissance à Sonar::Squid

D’une activité d’intégration, l’équipe s’est mise à développer ses propres analyseurs

Puis Freddy nous présente les 2 nouveaux widgets de Sonar 2.0 :

Tout d’abord le cycle entre packages. C’est souvent une dégradation dans le temps : quelles sont les responsabilités des packages.

Sonar, en plus de répondre à la question “Combien y a-t-il de cycles ?”, montre les endroits où il faut couper, où casser la dépendance entre des packages : Sonar indique le fichier qui coupable de la dépendance “incestueuse”.

Pour cela, Sonar affiche le DSM des dépendances

Mais d’où leur viennent ces idées de représentation de l’information ?? Chapeau !! C’est clair pour une info complexe !

XAVIER> On peut changer les couleurs : je suis daltonien
FREDDY> Ca c’est du feedback !

Les tests sur site, avec des utilisateurs ! un judicieux panel !

NICOLAS> C’est les classes ou les fichiers qui sont dépendants ??
FREDDY> on revient toujours au fichier

ANDREW> Comment on trie les packages dans la DSM (du moins au plus dépendant)
FREDDY > Il existe des algos de tri

Bientôt, on pourra faire une recherche sur l’utilisation d’une librairie : combien de mes projets dépendent de telle librairie

On revient a SQUID pour l’autre nouveauté.

Squid offre des métriques orientées objet, du classique DIT (le nombre de niveaux dans l’arbre d’héritage entre une classe et Object), à des choses plus novatrices :

  • RFC : le nombre d’appels de méthodes en dehors de notre classe (ce qui est un bon indicateur sur le niveau de testabilité)
  • LCOM4 : 2 notions dans la certification java :
    • la cohésion d’une classe : dans quelle mesure vos méthodes sont liées entre elles (en terme de rôle, de fonctionnalité)
    • et le coupling
    • LCOM4 est le nombre de groupes fonctionnel de méthodes par classe

Je trouve cette dernière métrique très intéressante car c’est une maladie de vieillesse, et donc une maladie grave ! Je m’explique. Dans mes études de biologie, un cours m’avait particulièrement marqué. Ce cher Monsieur Plisson nous avait parlé des maladies d’une façon dont je n’y avais jamais pensé. Les maladies mortelles qui touchent les jeunes, ou les maladies violentes (qui tuent en quelques jours) ne sont pas les plus dangereuses, car elles les premières entraînent la disparition des jeunes avant la reproduction, et les secondes entraînent la disparition des vecteurs avant que la propagation puisse se faire sur une grande échelle. Les maladies les plus graves, à l’échelle d’une population, sont celles qui surviennent tardivement, après que l’individu ai pu se reproduire. Au delà de cette vision un peu brutale, et très cartésienne, c’est exactement la vision que j’ai de ces maladies du code comme celle mise en évidence par LCOM4. Une fois la phase projet passée, la maintenance fait émerger des groupes de méthode viraux dans une classe…

La démo se termine à 19h20

Freddy se dépêche alors de conclure avec un slide intitulé “d’une plate-forme à 1 écosystème”

  • On est passé d’un “simple” outil à une plate-forme le jour ou on a ouvert les plugins (35 dans la forge actuellement)
  • L’intégration avec Hudson, Bamboo, Anthill pro, Jira, SonarJ, Structure101
  • Et surtout, le Sonar IDE (lancé par Evgeny Mandrikov)
    • IDEA, Eclipse (, NeetBeans)
    • Il avance très bien : devrait sortir après sonar 2.0
  • Et d’autres aspects en cours :
    • La gestion de la sécurité (authentification)
    • Couverture de nouveaux langages : plugin flex dans les prochaines semaines, et aussi Cobol

Et Freddy finit en recommandant 2 livres :

  • Clean Code de Robert C. Martin (Oncle Bob)
  • Effective Java

Questions – réponses

Puis c’est le tour des questions…

>> Peut on tester la qualité des tests ??
F> Pour l’instant, non !

MEB> d’abord merci pour la présentation [[bien vu cette politesse !]] Tout est opensource, gratuit : quid du business model ?

Freddy>

  1. Sonar sous LGPL… pas neutre (n’importe qui peut faire un fork) : si on veut le leadership il faut être actif
  2. La plate-forme doit être autonome, autosuffisante : pas besoin d’acheter les plugins commerciaux
  3. Tout repose sur le coeur open source : pas de version payante plus stable, plus fiable

Les plugins commerciaux sont d’avantage adressés aux grandes structures

On part de rien sur Cobol, avec nos propres analyseurs. Là, c’est clairement commercial.

Quant à l’aspect tarifaire, SonarSource est plutôt agressive (Le plugin “views” : 1800 euros par instance… Pour une entreprise, et par rapport à la concurrence / CAST, c’est rien.

>> Existe-il une documentation sur les violations ?
Freddy> Un peu pauvre… Par contre SonarPedia est dans les cartons : au delà de communauté sur les règles de qualité, aussi parler des refatorings pour corriger la violation. Mais c’est encore dans les cartons, je ne peux pas parler.

Très bonne idée d’aller au delà de l’identification des “maladies”, en présentant des remèdes.

>> La demo, c’est sur un snapshot : y a t il une facon de voir l’evolution ?…
F> Oups, j’ai oublié d’en parler ;) le time machine
>> Je sais que c’est oui… mais je voulais en venir à une autre question : Est-il possible d’identifier le développeur à l’origine d’une violation ?

LA SALLE S’ENFLAMME !!

F> Au delà du flicage, sujet à polemique, la vue différentielle : “je ME suis amelioré depuis mon dernier snapshot”
>> De toute facon le code est visible… et par tout le monde dans l’open source
F> Soit c’est du flicage… Soit c’est l’opportunité d’offrir la transparence, même plus besoin de “taper sur les développeurs” : tout le monde sait que si il commit de la <biiip> cela se verra !

Andrew> c’est possible de hierarchiser les violations ?
F> Oui, il y a des possibilités mais pas sur les indicateurs

Jacques> Qu’y aura-t-il dans la 3.0 ?
Freddy> Pas sûre qu’il ait une 3.0 ! Il y a beaucoup de choses dans la 2.0 : il y aura donc certainement des 2.x avec des évolutions des nouveautés. Et puis le Sonar IDE est a lui tout seul une nouvelle version ;)

19h42, c’est la fin du show de sonar : à l’applaudimètre, la note est proche du carton ;)

Freddy termine avec l’offre de licence :

  • 3 licences de Structure101 avec plugin sonar
  • et une licence SonarSource Master Project

… Ces licences seront offertes… aux 3 premières personnes ayant envoyé un mail aux sociétés concernées… Coup commercial à peine dissimulé… La salle rigole ;)

Puis c’est au tour de Xavier pour la tombola [[suite au plantage de l'autre fois sur l'ordinateur, Xavier a appris et amélioré le processus : cette fois avec papier...]] :

  • teeshirt
  • jrebel
  • IDEA
  • JUNIT in action
  • JavaInANutshell

On se donne RDV le mois prochain pour le JUG Maven.

Et puis c’est le buffet : toujours aussi fort les gars du JUG pour les petits fours ! Vraiment bons !

Conclusion

Au final, une soirée intéressante à plus d’un titre.

Je me permets une remarque personnelle. Je pense qu’il est important de faire en sorte que les gens incrits aient une place assise, car sinon il n’y a plus de raison de s’inscrire… Autant venir comme bon nous semble. Les organisateurs s’embêtent à mettre en place un système d’enregistrement, les participants prennent la peine de s’enregistrer en temps et en heure… Alors si on ne respecte pas cette convention… D’un autre côté, il faudrait mettre un vigile à l’entrée ?!…

Sur la forme, Freddy nous a déroulé une présentation zen de référence, avec les premiers mots sur le 5 ou 6 ème slide… Il a su captiver la salle, la faire rire, la faire voter : bref, il nous a cueilli. Du grand Freddy ! Heureusement qu’il n’est pas mal attentionné, car il pourrait amener loin la salle ;))

Même pas le logo de SonarSource ! Respect.

J’ai appris un mot : l’Inspection Continue. Très fort de présenter ces pratiques comme il l’a fait, et au dela de positionner SOnar sur ce créneau. De la façon dont c’est dit, je ne vois effectivement pas de raison pour que notre métier n’évolue pas naturellement vers cette voix… Sonar sera là !

L’autre côté très pertinent de Sonar est d’avoir mis sous Sonar les principaux projets Open Source : je parle de Némo… Une bonne façon de devenir une référence.

Cette session était clairement une session pour présenter sonar, un outil, mais Freddy a eu ce respect d’attendre la seconde moitié de sa présentation pour commencer à parler de Sonar. La première moitié étant dédiée à une session sur la méthode développement.

Par contre il m’a vraiment sapé le moral en me confirmant un sentiment que j’avais : la vie de l’informaticien c’est 80% de maintenance ! Fini les projets depuis une feuille blanche ?

Dans ce contexte, je me dis qu’il ne faudrait pas plus de 20% de bouquins qui parlent d’agilité qui le font comme les bouquins actuels… Et 80% des bouquins devraient présenter l’agilité avec une feuille de route permettant de l’introduire progressivement. Je ne dis pas que faire que des stand-up le matin c’est faire de l’XP (pour moi, faire de l’XP, c’est mettre en oeuvre les 13 pratiques !). Par contre, je me dis qu’aucune équipe travaillant sur un projet, avec une quelconque façon de travailler, peut, du jour au lendemain, passé à l’agilité. Aussi, il faudrait une feuille de route qui permettent de passer progressivement à une méthode agile, jusqu’à être pleinement agile.

Pour revenir à l’outil, j’aime vraiment cette démarche qui consiste à partir des indicateurs de haut niveau sur la première page, puis les détails  pour chaque indicateur, jusqu’à arriver jusqu’au code.

Mais vu le nombre d’écrans l’utilisation de Sonar semble être une activité à part entière. Ce n’est pas ainsi que je vois mon métier de développeur.

Par contre cela conforte mon sentiment que la qualité n’est pas facilement mesurable… Tous ces écrans, ces mesures, crédibilise donc Sonar dans sa démarche d’estimation de la qualité du code.

En tous cas, on est bien loin de Sonar à ses débuts, à l’époque où j’y ai participé, avant même qu’il ne soit un outil avant une plate-forme ;) il y a… 2 ans déjà !!… Je me demande si déjà, à l’époque, Freddy avait cette vision en tête ?? Bien fier d’avoir apporté mes quelques octets à l’édifice ;)

Sacré boulot : chapeau !

Difficile de ne pas croire à la réussite de SonarSource. Avec tous ces utilisateurs de SonarSource en interne, c’est un peu comme le feu qui couve sous les feuilles dans la forêt : quand les flammes surgissent, impossible de les arrêter ! Bon succès !

Et dire que c’est aussi Freddy qui m’a ramené de Paris il y a 3 ans et demi maintenant… Bref, une importance notable dans ma vie.

Pour finir, difficile de ne pas faire l’écho de sa remarque sur la dévalorisation de l’activité de programation dans notre métier… Le chirugien continue de “découper de la viande” même au bout de 20 ans… Et cela n’est pas synonyme de carrière ratée !… Mais cela sera le sujet d’un autre post…

Et un merci sincère à Freddy pour sa relecture.

L'URL courte de cet article est : http://inagua.ch/GRHuI

5 réflexions au sujet de « 2ème JUG : Sonar et les 7 péchés capitaux »

  1. Salut Jacques,
    Merci pour ce post.

    Un commentaire en parenthèse sur ta parenthèse sur les commentaires :
    Je suis totalement d’accord. Cela me fait flipper de voir ces commentaires auto-générés sur les getters et setters et les constructeurs. Leur valeur ajoutée est négative ! Il ne faut mettre un commentaire QUE s’il rajoute quelque chose aux informations dans le code. Ce rajout peut être une information complémentaire, un contexte, voire une simple facilitation de la lecture (ce qui revient à admettre qu’on n’a pas su écire un code assez lucide). Mais il ne doit jamais se contenter de reprendre ce qui est déjà bien lisible, le nom d’une méthode ou d’un paramètre.

    D’accord également sur le fait que ce n’est pas rien que d’enlever ces commentaires inutile en maintenance. Il ne faut pas sous-estimer la valeur de nuisance du bruit dans le code. J’ai vu bien des *.java qui étaient composés pour plus de 50% de commentaires superflus. Sans même parler de leur effet sur le travail mental de lecture, rien que le temps passé à faire défiler le fichier est coupé en deux à partir du moment où on les supprime.

  2. N’ayant pas pu assister à cette présentation en raison d’une indisponibilité, j’ai trouvé ce post très intéressant et très riche.

    Merci pour ce récit.

    Je serais présent à la prochaine présentation.

  3. Merci Jacques pour ce boulot de fourmis extrêmement précis et juste !!!! Tes prises de position perso peuvent être encore plus franches mais je préfère que ce soit le cas à partir de la présentation d’Arnaud sur Maven ;-). Bonne chance Arnaud, l’entrée de blog Waves de Jacques Couvreur devient déjà une institution en quelques semaines d’existence !

  4. Ping : Sonar » Sonar in the news

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*


*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>