24/02/2013

On verra ca en retro

Je me suis souvent posé la question, en cours d'itération, lorsqu'il me vient une idée d'amélioration de la manière de travailler en équipe, s'il fallait la partager, la discuter et la mettre en application rapidement, ou alors attendre la rétrospective.

Il est en effet tentant, devant une petite amélioration rapide à mettre en place, qui semble faire gagner du temps, améliorer la qualité ou éviter des erreurs.

Attendre la rétrospective présente néanmoins de nombreux avantages:

L'équipe est au complet
Chacun est concentré
Les idées sont approfondies, confrontées
L'équipe peut repérer les fausses bonnes idées
Seule la ou les propositions d'amélioration les plus percutantes sont choisies

De plus, cela permet de continuer l'itération en cours sans se disperser. Il faut alors garder un réflexe conservateur "On a toujours fait comme ça". Cela doit être plus dur pour une équipe qui débute scrum, car d'anciennes habitudes restent, mais elle veut beaucoup expérimenter. Pourtant il faut garder en tête le principe "Inspect and Adapt", c'est à dire considérer la situation présente avec du recul, afin de faire mieux. Il y a beaucoup de valeur dans une décision percutante ayant trouvé un consensus pendant une rétrospective.

"À intervalles réguliers, l'équipe réfléchit aux moyens

de devenir plus efficace, puis règle et modifie son

comportement en conséquence."

Je vous conseille donc cette petite phrase: "On verra ça en retro".

Et cela est une bonne raison de faire des itérations courtes.

Styles de Test

Voici un article sur les différents style de test, qui reflète à peu près l'évolution de la manière dont j'ai personnellement écrit des test.

Le test basique:

@Test
    public void testBuildFullName_tooBasic() {
        Person person = new Person();
        person.firstName = "Francois";
        person.lastName = "Wauquier";
        String fullName = person.buildFullName();
        assertEquals("Francois WAUQUIER", fullName);
    }

Les assertions avec Fest:

   @Test
    public void testBuildFullName_Fest() {
        Person person = new Person();
        person.firstName = "Francois";
        person.lastName = "Wauquier";
        String fullName = person.buildFullName();
        assertThat(fullName).isEqualTo("Francois WAUQUIER");
    }

Distinguer les 3 blocs (Initialisations, Action, Assertions):
    @Test
    public void testBuildFullName_BDD() {
        // Given
        Person person = new Person();
        person.firstName = "Francois";
        person.lastName = "Wauquier";
        // When
        String fullName = person.buildFullName();
        // Then
        assertThat(fullName).isEqualTo("Francois WAUQUIER");
    }

Utiliser des constructeurs pour les tests. Permet de consolider les objets métier en se posant la question des attributs obligatoires pour construire un objet, mais c'est un peu intrusif sur le code de production, si le constructeur n'est appellé que par les tests.
    @Test
    public void testBuildFullName_Constructor() {
        // Given
        Person person = new Person("Francois", "Wauquier");
        // When
        String fullName = person.buildFullName();
        // Then
        assertThat(fullName).isEqualTo("Francois WAUQUIER");
    }

Utiliser le pattern builder est à la fois plus facile à lire, à maintenir, et moins intrusif. Il est possible de générer automatiquement les classes builder.
    @Test
    public void testBuildFullName_Builder() {
        // Given
        Person person = new PersonBuilder().withFirstName("Francois").withLastName("Wauquier").buildPerson();
        // When
        String fullName = person.buildFullName();
        // Then
        assertThat(fullName).isEqualTo("Francois WAUQUIER");
    }

Ecrire le test en une seule ligne. On est content d'avoir réussi à l'écrire, mais je me suis aperçu qu'au final c'était plus difficile à lire. De plus, on a tendance à vouloir mettre plusieurs lignes de ce genre là dans une même méthode de test. Cela augmente la granularité du test et empêche de donner un nom à chaque méthode de test
    @Test
    public void testBuildFullName_OneLiner() {
        assertThat(new PersonBuilder().withFirstName("Francois").withLastName("Wauquier").buildPerson().buildFullName()).isEqualTo("Francois WAUQUIER");
    }

Voici comment je préfère écrire un test aujourd'hui. Je me force à écrire au moins 3 lignes, et je place les lignes d'assertions dans un bloc de code anonyme. L'action est forcement la ligne avant le bloc.
    @Test
    public void testBuildFullName_BackToImplicitBDD() {
        Person person = new PersonBuilder().withFirstName("Francois").withLastName("Wauquier").buildPerson();
        String fullName = person.buildFullName();
        {
            assertThat(fullName).isEqualTo("Francois WAUQUIER");
        }
    }

Un Backlog Public - Agile France 2012

http://www.slideshare.net/wokier/un-backlog-public-13117768

http://conf.agile-france.org/

Planning Poker Rapide

Le planning poker est une technique d'estimation utilisant des cartes comportant les chiffres de la suite de fibonacci, représentant des points de complexité.

Je souhaitais partager avec vous une pratique permettant d'accélerer vos planning poker.

Les etapes habituelles du planning poker sont les suivantes:

Description de la story par le Product Owner
Question/réponse pour approfondir la story
Décision si la story est 'ready', selon les critères définis par l'équipe
Evocation des taches nécessaires à la réalisation
Les participants, excepté le PO, choisissent leur carte et la posent devant eux
Les cartes sont retournées en même temps
Les estimations les plus hautes et les plus basses expliquent leurs chiffrage
Répéter les étapes 5,6,7 jusqu'à obtention d'un consensus

Les avantages de cette technique sont nombreux:

Le vote caché limite les influences
Elle utilise l'inteligence collective pour résoudre un problème complexe
Le planning game produit une estimation, mais contribue également à la construction d' un domaine métier partagé par l'équipe
La suite de fibonacci permet d'être moins précis sur les grand chiffres
En cours de planning poker, les story peuvent être remaniées ou découpées

Cependant, l'expérience m'a appris que la recherche du consensus parfait prenait du temps, beaucoup de temps. Au final, ce qui est important, c'est une estimation permettant de dimensionner le sprint de manière réaliste. Si vous trouvez vos planning game trop long, vous pouvez essayer ces petites règles aditionnelles:

Si les cartes sont regroupés sur 2 ou 3 valeurs consécutives, faire une moyenne retombant sur un chiffre de la suite
N'expliquer les chiffrages haut ou bas que si il y a un ecart de 2 cartes
En cas d'égalité, prendre l'estimation la plus haute

Exemples:

2,3,3,5⇒3

2,2,2,5⇒'5' s'explique puis nouveau tour

1,1,5,13⇒ les '1' et le '13' s'expliquent puis nouveau tour

3,3,5,5⇒5

Bon Planning Game

Artisan du logiciel - Traduction

Manifeste pour un artisanat du logiciel

Elever le niveau.

En inspirant des artisans du logiciels, nous élevons le niveau du développement logiciel professionnel, en pratiquant, et en aidant les autres à apprendre ce métier.

Ce faisant, nous privilégions :

Non seulement un logiciel qui fonctionne,

mais aussi un logiciel bien conçu

Non seulement répondre au changement,

mais aussi en apportant continuellement de la valeur

Non seulement les individus et les interactions,

mais aussi une communauté de professionnels

Non seulement la collaboration avec le client,

mais aussi un partenariat bénéfique

En recherchant les éléments de gauche, nous avons découvert que les éléments de droite étaient indispensables.

http://manifesto.softwarecraftsmanship.org/

⇒Insérer caractères spéciaux ✓

Le dévelopement web recherche sans cesse la prerformance, et cela encore plus pour le dévelopement mobile.

La moindre image est à banir.

Et l'on s'appercoit alors qu'il existe un encodage de caractères bien connu, UTF-8, qui cache de petites perles pour faire la ☂ et le ☼

Ces caractères peuvent donc facilement être utilisés à la place d'une image, se mettent automatiquement à la taille du texte. Super!

Cela est également du plus bel effet dans un tweet

faire la ☂ et le ☼
— Francois Wauquier ☁ (@wokier) December 23, 2011

★ New cool stuff on Initializr: With Great Templates Comes Great Responsivity ★ verekia.com/initializr/res… Enjoy! :)
— Jonathan Verrecchia (@verekia) December 21, 2011

Maintenant, ces petits caractères, ils sont où sur mon clavier ?

Des combinaisions de touche permettent de taper certains caractères, mais pas les plus cool .

L'outil charmap, intégré à windows permet de faire l'insertion. Et chaque OS a son équivalent.

On peut aussi passer par des extensions de navigateur :

Chrome:

Firefox:

Avec cette (re)découverte, j'ai eu la même impression qu'en (re)découvrant http avec REST. Les technologies que l'on utilise ont été bien pensées dès le départ, et par notre méconnaissance de celles-ci, nous faisons des surcouches, c'est ce qui s'appelle de la complexité accidentelle.

Il ne reste plus qu'à utiliser ces caractères à bon escient.

Cela marche aussi pour vos carte de voeux.

☃Joyeux nöel☃

♥Bonne année♥

Source d'inspiration :

http://blog.goetter.fr/post/14449665753/des-images-sans-images

Refactoring: Supprimmer le bruit

Je voulais vous présenter un type de réfactoring que j'ai experimenté récemment: Supprimmer le bruit.

Avant tout je précise ce que j'entend par bruit. C'est un terme qui provient du traitement du signal, et qui signifie parasite, la partie du signal qui n'apporte pas d'information. http://fr.wikipedia.org/wiki/Rapport_signal_sur_bruit

Pour du code, le bruit est l'ensemble des caractères qui n'apportent pas d'information, et ralentissent le compréhension du code.

Je l'ai utilisé sur des tests d'integration en regression dont je n'arrivais pas à comprendre le sens. J'ai donc appliqué des améliorations sur les classes de test. Les modifications présentées ci dessous ont la caractéristique de ne pas changer le comportement de production, et permettent donc d'avancer en confiance.

Visibilité

Supprimmer la visibilité dans les interfaces et les attributs des classes de test.

Javadoc vide

Déjà, la javadoc sur une application sans API publique, cela n'apporte que rarement quelque chose de plus q'un bon nommage. En plus, quand c'est sur un méthode de test, et que en plus elle est vide, alors là, je supprime sans etat d'ame.

Getter inutile

Certains tests injectent ou se font injecter les attributs à partir d'un contexte spring ou autre. Le getter n'est pas nécessaire pour cela.

Assertions verbeuses

Pour vérifier la non-nullité et la taille d'un collection, on peut fairre l'assertion en junit

assertNotNull(list);

assertEquals(2, list.size());

... ou avec Fest Assert

assertThat(list).hasSize(2);

Découpage de test

Parfois vous vous rendez compte qu'une methode de test appelle plusieurs fois la même méthode avec des paramêtres différents. Cela signifie que ce sont plusieurs tests distincts. Il convient donc de découper le test en plusieurs méthodes avec un nommage décrivant ces différents cas de test.

Formattage BDD

Cela facilite également la lecture de passer une ligne entre les différents blocs du test:

initialisation (given)
action (when)
assertions (then)

J'ai parfois utilisé des commentaires pour séparer ces blocs, mais lorsque cette simple règle de formattage est connu, cela est beaucoup plus efficace. Par ailleurs, certains framework de mock comme Mockito proposent des méthode utilisant le nommage BDD

Suppression des catch-fail

J'ai souvent retrouvé cet anti pattern du catch-fail, voire du catch-log-fail. Je ne vois pas l'interêt d'avoir un failure plutôt q'une erreur lorsque le méthode testée renverra une erreur. Quelle que soit la manière dont le test sera lancée, cette erreur sera remontée. Par contre je suis sûr que cela freine la lecture du code. Supprimé!

Regroupement des exceptions

Dans la close throws d'une méthode de test, peu m'importe de lister les exceptions que peut renvoyer cette méthode, un 'throws Exception' suffit.

Utilisation de expected pour les exceptions attendues

Transformer

@Test

public void testCasLimite() throws Exception {

try {

service.doSomething();

fail();

} catch (ExpectedException e) {

// success

}

}

... en

@Test(expected=ExpectedException.class)

public void testCasLimite() throws Exception {

service.doSomething();

}

Suppression du constructeur vide

Un constructeur d'une classe de test, vide ou avec le paramêtre 'name', mais pas de code, je le supprimme aussi. (Je conserve par contre volontier un constructeur vide dans une classe de production, afin de faciliter la navigation dans le code, et ne pas oublier ce constructeur vide au cas où l'on en ajoute un autre, mais que l'objet en question est serialisé, et a besoin d'un constructeur vide)

Suppression du message d'assertion

Le message d'assertion apporte peu d'informations par rapport à l'assertion elle-même, et au message construit par cette assertion lorsqu'elle echoue (ex: expected: 1 but was: 2). Parfois le code evolue, mais le message est resté identique, si bien qu'il nomme les objets avec un certain nom au moment où l'on écrit le test, mais que ce message apoprte aujourd'hui une confusion. Un message peut néanmoins être utile s'il apporte des valeurs importantes qui ne sont pas dans l'assertion elle-même.

Renommage de variable locale

Le meilleur nommage pour une variable est le nom de sa classe.

Utiliser les imports statics

Transformer

Assert.assertEquals("expected",actual);

... en

assertEquals("expected",actual);

Les plus attentifs et courageux qui seront arrivé jusqu'ici ont été indigné par cette approche. Quoi? du refactoring sur une barre rouge? n'importe quoi ! Tel que l'a rappellé récement Martin Fowler dans cet article sur le refactoring opportuniste, le refactoring s'effectue sur une barre verte. J' ai fait une entorse à cette règle en choisissant les améliorations qui me semblait sans danger.

J'espère que cela vous donnera des idées pour rendre votre code plus propre. Les commentaires sont les bienvenus.

Pour aller plus loin

Optimisation du Build Maven

Une de mes premières impression à france billet etait le temps du build maven.

Voici l'etat de nos reflexions et exprimentations

Situation actuelle

364 projets
3 artefacts finaux
13 jobs Hudson pour builder, gérer les évolutions du schema de la base et déployer sur plusieurs environnements dont les premiers sont
- 1 Job Compilation + Tests Unitaires
- 1 Job Test IT avec appel à la base de données
- 1 Job Integration avec serveurs démarrés
33min pour un build complet en local sans les tests
1 intégrateur à plein temps pour gérer l'usine logicielle

Done

Bien connaître les options maven

Le réacteur contient le projet courant et l'ensemble de ses modules.

Les options utiles permettant de ne pas builder l'ensemble du réacteur sont:

-pl, –projects Une fois placé à la racine des projets, cette option permet de sélectionner les projets à builder
-am, –also-make Build également les dependances des projets selectionnés lorsque celles-ci sont dans le reacteur, ce qui permet de builder u produit à jour
-amd, –also-make-dependents Build également les projets du réacteurs qui dépendent des projets selectionnés, ce qui permet de propager les modifications
-rf, –resume-from Permet de reprendre un build sur un projet donné, après avoir effectué une correction

http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/

http://blog.aheritier.net/construire-moins-pour-aller-plus-vite/

Régler les paramêtres de JVM

Sur le build, il y a 3 endroits où j'ai pu configurer la taille allouée pour la JVM

Build Maven, avec la variable d'environnement MAVEN_OPTS (Maven indique gentiement la mémoire utlisée en fin de build)
Compilation Java, avec la configuration maxmem du plugin maven-compiler-plugin
Compilation GWT, avec la configuration extraJvmArgs du plugin gwt-maven-plugin

A manier avec précaution, car si le Xms est trop grand, la mémoire est allouée pour rien, s'il est trop petit, l'allocation progressive est plus coûteuese.

Si le Xmx est trop grand, il y a un risque de freezer la machine, et s'il est trop petit, c'est le java.lang.OutOfMemoryError

http://download.oracle.com/javase/6/docs/technotes/tools/windows/java.html

Spécifier le chemin du parent

Préciser un parent permet de faire de l'héritage et d'éviter de la duplication de configuration.

Lorsque l'on précise un parent, toujours ajouter le relativePath. Cela permet d'utiliser la dernière version du pom parent sans avoir à installer ce dernier.

Fixer les versions

Une grande partie de nos projets sont en SNAPSHOT. Nous ne passons pas par l'étape de version Fixe pour ces projets. L' ensemble des projets change de version en même temps.

Quelques projets dit 'ext' sont placés dans une autre arborescence avec des versions fixes car ils ne bougent plus.

Utiliser un build incrémental

Ce plugin permet de détecter si la recompilation est nécessaire. Ce plugin a été fait ici.

http://maven-incremental-build.java.net/site/index.html

Faire du TDD

Avec des tests unitaires, pas question de build, tout se passe dans l'IDE. Et je ne m'attarde pas sur les nombreux intérêts de cette pratique.

Mettre en places des circuits courts pour la partie présentation

Le build peut simplement être évité au cour du developement, suivant la technologie utilisée:

jsp/js: Faire du war:inplace lorsque cela est possible, ou alors faire les modifications dans le repertoire de deploiment utilisé par le serveur (sans oublier de répercuter les modifs - OK ce n'est pas idéal)
GWT: Se placer en mode dévelopement pour éviter la compilation GWT
Code serveur/EJB: Se brancher en debug. Le code peut être remplacé à chaud tant que les signatures de méthode ne changent pas.

Détecter les modifications pour builder moins

Le job construit la commande maven en se basant sur le changelog, afin de ne builder que les projets qui ont changé, et les projets dépendants.

Mieux connaître l'avancement du build

Un plugin nommé progress-maven-plugin de mon cru permet d'ajouter un log de ce type:

Reactor Progress: 32/60 (53.33%) /workspace/module/subModule

Cela permet d'ajouter du feedback:

sur un build local: un 53,33% permet de définir assez précisement la durée de la pause café :)
sur le build hudson: Nous sommes sur des jobs de type FreeStyle, et pas Maven, donc nous n'avons pas l'avancement module par module. D'autres part, les calculs faits par hudson pour prédire la durée du job est faussé par l'aspect dynamique de nos jobs (voir 'détecter les modifications'). Cela est surtout utile lorsque le build est claimé et que la correction est en cours de build.

Générer le Mind Map des relations

Comme un dessin vaut 10 000 mots, il est interessant d'avoir le graphe des dépendances maven. IL existe plusieurs plugin qui génèrent une image, mais à partir d'une taille limite, l'image devient inutilisable. L'interêt de l'avoir sous forme de mindmap, c'est que l'on peut l'ouvrir avec l'outil de son choix, le parcourir, le modifier, afin d'en extraire l'information voulue.

http://blog.xebia.fr/2011/05/05/le-mind-mapping-applique-aux-dependances-des-projets-mavenises/

In Progress

Fixer les versions

Déplacer quelques projets en 'ext' et fixer la version pour ne plus les builder ni les télécharger plusieurs fois.

Casser des dépendances

Puisque notre build détecte le modifications et les propage, il devient critique de ne pas avoir de gros projet utilisés par de nombreux autres projets. Le risque est en effet de builder les projets qui ont une dépendance même s'il n'en utilise qu'une infime partie. Il faut donc continuer à découper, spécialiser les projets afin de builder juste.

Passer à Maven 3

C'est je pense un gros gain possible, mais quelques plugin maven ne sont pas compatibles, et n'ont pas encore été apadptés.

Essayer Jenkins

A ma connaissance, il n'y a pas de gain de performance particulier à obtenir. Ce qui fait la différence, c'est le nombre de plugin et l'activité de la communauté.

To Do

Parralléliser les tests

Cela nécessite d'avoir des tests bien indépendants, sans ordre, ni resources partagées, ni données en base réutilisées.

http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#parallel

Parralléliser le build

Une fois passé à Maven3, il est possible de parralléliser les builds à l'interieur du réacteur, en définnissant la taille du pool de threads.

https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3

Passer les jobs en type Maven

En supprimant la partie script non-maven du job, nous bénéficierons de la vue du build en cours avec le statut de chaque module.

Automatiser la génération du mind Map

Créer un job permettant de générer le mind map et le publier sur le serveur d'intégration continuer, afin de pouvoir consulter la version la plus récente sans le générer en local.

Atteindre le build incassable

Réaliser un build pre-commit.

http://blog.javabien.net/2009/12/01/serverless-ci-with-git/

http://blog.octo.com/integration-continue-performante-part-2/

Parralléliser le déploiement

Nos serveur d'intégration sont déployés en série, rendant la plateforme indisponnible pendant 15min à chaque déploiement (arrêt, copie, démarrage des 2 * 3 serveurs).

Faire du war:inplace partout

Mettre en place le mode de dévelopement inplace sur tous les projets web jsp.

Conclusion

Chouchoutez votre build pour vous faciliter la vie.

Développement logiciel : art ou artisanat?

Traduction d'un article de Patrick Lee Dooley

http://organicprogramming.blogspot.com/2011/04/op-is-software-development-art-or-craft.html

Durant la dernière année et demi, j'ai travaillé sur les fondements de l'approche de développement logiciel appelée "Programmation Organique" (PO). Les résultats de mes recherches sont très intéressants. Je voudrais partager ces découvertes et générer une discussion riche. Je pense que cela est la clé du concept d'Artisanat du logiciel - un sujet qui est cher à mon cœur. Et tant que nous ne l'aurons pas défini, nous ne serons pas en mesure d'énoncer clairement ce que nous entendons par ce terme.

Il y a eu beaucoup de discussions au cours des années pour savoir si le développement logiciel (Software Development) doit être considérée comme un Art. Nous sentons intuitivement qu'il est plus correctement compris comme un artisanat (Craft). Nous sommes plus à l'aise en le considérant comme un artisanat. Nous pensons de cette façon pour la simple raison que nous avons été formés comme artisans, et non pas comme des artistes. Il est inersessant dans la compréhension et le traitement du SD comme un artisanat. Après tout, les fruits de notre profession témoignent de la validité de ce point de vue. Cependant, je ne suis plus convaincu que ce point de vue soit suffisant. J'ai réalisé que le SD est aussi un art.

N'étant pas un psychologue, j'ai récemment réalisé qu'il ya deux façons distinctes de décrire la réalité. La première est très concise et succincte (Craft). Les mathématiques tombent dans cette catégorie. La seconde est élaborée et sophistiquée (Art). La peinture ou la littérature entre dans cette catégorie. Ce sont les deux extrémités du spectre de l'activité humaine. Notre capacité à bien exprimer la réalité dans ces deux approches détermine la façon dont nous pouvons Interpréter, Modèliser et Communiquer la réalité.

Notre capacité à résoudre des problèmes est déterminée par notre capacité à faire ces activités, et aussi - tout aussi important - par notre capacité à déterminer la bonne approche pour ces différents aspects de la réalité. Si nous nous trompons dans le choix de l'approche appropriée, notre capacité à créer des solutions en sera affaiblie. Nous pourions encore être en mesure de résoudre le problème, mais nous ne serions pas en mesure de le résoudre de manière efficace.

Comme exemple simple, si nous souhaitons communiquer la beauté d'un paysage, le choix d'utiliser des représentations en fil de fer pour les éléments dans l'espace du problème entravera notre capacité à transmettre cette beauté. Nous allons être obligés de passer beaucoup plus de temps et d'efforts à tenter de corriger la solution en agitant la main jusqu'à ce que nous soyons en mesure de transmettre cette beauté. Tenter de résoudre ce problème en le réduisant s'avère totalement inefficace.

Le logiciel n'est pas différent. La création efficace d'un système logiciel requiert la capacité à la fois:
- Représenter certains aspects de l'espace de problème avec la sémantique concise et succincte (Craft -. Sémantique à savoir la théorie des ensembles, la sémantique d'analyse, de la sémantique algorithmique etc)
- Représenter d'autres aspects de l'espace de problème avec la sémantique complexe et sophistiquée (Art - c'est à dire le modèle du logiciel des entités et les relations à multiples facettes entre les entités).
Un système logiciel efficace doit être à la fois de l'art et de l'Artisanat. Mais ce n'est pas différent de toute autre profession qui tente de résoudre un problème particulier. Une voiture - quand elle est conçue correctement, est également à la fois de l'art art et de l'artisanat.

C'est vraiment un argument pour le principe selon lequel la forme est définie par la fonction. On pourrait avancer que dans la profession du logiciel - comme dans aucune autre profession - , la fonction véritable dépendent de la forme du logiciel - particulièrement lorsque la sophistication du système augmente. La Nature elle-même fournit de nombreux exemples où la forme permet la fonction. Il y a des discussions étonnantes sur le gecko sur le site TED.

Donc, en résumé, je crois que le logiciel a besoin d'être traitée comme un art, quand cela est nécessaire, et elle doit être traitée comme un artisanat - quand cela est nécessaire. Et nous avons besoin de développer la capacité d'être en mesure de déterminer où se situent ces exigences.

C'est mon expérience, que nous ne sommes pas armés pour faire ce type de distinctions. Nous avons été formés uniquement avec les compétences d'un artisan. Nous avons été amenés à croire que ces compétences sont suffisantes pour l'ensemble de nos problèmes de conception. Nous avons un outil dans notre coffre à outils, et nous nous sentons tellement en confiance avec cet outil qui nous l'utilisons partout. Et pourtant, nous sommes surpris lorsque les résultats sont plutôt satisfaisants. Je pense qu'il est impératif que nous étendions notre ensemble d'outils et d'apprendre leurs usages respectifs.

Pour réaliser cette traduction, je me suis aidé de http://translate.google.fr et http://www.granddictionnaire.com

Merci à Patrick Lee Dooley de m'avoir autorisé à publier cette traduction.

Pour en savoir plus sur la programmation organique :

http://www.organicprogramming.com/2010/08/what-is-organic-programming-op/

http://en.wikipedia.org/wiki/Organic_computing

TEH framework

TEH signifie ToString Equals HashCode

Design

Ce framework utilise les annotations pour implementer toString, equals et hashCode

Par design, il force ces 2 règles

Tout attribut utilisé pour equals sera utilisé pour toString
Tout attribut utilisé pour hashCode sera utilisé pour equals (et toString)

Utilisation

Les 4 annotations sont

@TEH

@ToString

@ToStringEquals

@ToStringEqualsHashCode

Les 3 annotations ToString* se placent directement sur les attributs

On peut activer les annotations sur une classe de 2 manières :

Etendre TEHObject
Surcharger les 3 méthodes en utilisant TEHUtils et ajouter @TEH sur la classe

Approche

TEH ne force pas à utiliser des getter/setter

Les règles sont faites pour faciliter les activités de dévelopement comme le test et le log:

Si dans un test JUnit l'on compare des objets avec assertEquals, le message de failure utilise toString. Il faut que ce message aide à trouver les différences.

hashCode etant une methode utilisée pour de l'optimisation, principalement dans certaines structures de donnée comme les hashMap, si deux objets sont égaux ils doivent renvoyer le même hashCode.

http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode()

Le projet sous github

https://github.com/wokier/TEH

Comme on dit : "Fork me!"

gwt-table-to-excel

Pour l’application de gestion, l’ export excel est déjà un constat d’échec: l’application ne remplit pas toutes les fonctionnalités, et l’utilisateur souhaitera obtenir cet export pour une consolidation X, Y Z, une mise en forme particulière, une impression, etc... Admettons que nous devons faire cet export, qu’il est dans la story avec la plus grande priorité, et/ou parce que cela est moins complexe que d’autres outils de fouille de données, de rapports raffinés.

Imaginons que le produit est développé en java avec GWT.
La solution jusqu’à récemment était d’utiliser des librairies de génération d’ excel :

Mais il y a de fortes chances que l’on propose ces mêmes données dans les écrans de l’application. Nous devons alors manipuler les données et construire un tableau dans le code client ET dans le code serveur, en utilisant des API différentes. Cherchez l’erreur.

Grâce à gwt-table-to-excel, vous n’avez plus qu’à coder la partie cliente, l’ export excel vous rendra ce qui est visible à l’écran.

Elle est pas belle la vie ?

http://code.google.com/p/gwt-table-to-excel

http://gwt-table-to-excel-demo.appspot.com

Article initialement publié sur http://www.insideit.fr/post/2010/12/15/gwt-table-to-excel que je reprend honteusement.

Depuis, j'ai fait une version 0.0.2 avec une configuration de l'encoding côté serveur, et un exemple pour l'utiliser avec UIBinder.

Geek 2.0

Je vous propose de présenter les outils que j'utilise pour veiller, buzzer, et réseauter.

Réseaux professionnels

Connectez-vous à vos collègues pour construire votre réseau.

LinkedIn

Très bon reseau professionnel, où la notion de groupe est mise en avant.

http://www.linkedin.com/in/francoiswauquier

Viadeo

Le francais n'est pas à la hauteur de linkedIn mais s'améliore. Il y a eu à un moment une limite au nombre de contacts, mais cette limite semble supprimée.

http://www.viadeo.com/fr/profile/francois.wauquier

Reconnaissance par les pairs

Encore mieux que le réseau, recommandez vos collègues sur une compétance donnée. Une serieuse alternative à la certification.

Entaggle

Un site permettant de tagguer une personne sur un compétence.

http://entaggle.com/people/wokier

Mixtent

Celui-ci utilise les connections linkedIn et permet de créer une sorte de classement en se basant sur des comparaison de connections sur une compétence donnée.

http://www.mixtent.com/

Micro Blogging

Une simple question : Que faites-vous en ce moment?

Twitter

Incontournable, mais je trouve qu'il a des limites pour la partie partage d'URL car ce n'est pas sa fonction principale. J'ai eu aussi des difficultés à retrouver d'anciens tweets.

https://twitter.com/#!/wokier

Buzz

Le service de google intégré à gmail.

https://profiles.google.com/wokier/buzz

Partage

Ne restez pas dans votre coin, partagez vos lectures!

Google Reader

Je l'utilise comme lecteur de flux et comme outil de partage.

http://www.google.fr/reader/shared/wokier

delicious

Cet outil de bookmarking social récemment revendu par yahoo est bien fait. Il propose des plugins pour tous les navigateurs. Je l'avais laissé de côté, mais il reste utile pour du bookmarking de site (pas d'article de blog). Il manque la fonction de recherche de personne (seulement possible par le login).

http://www.delicious.com/wokier

PostRank

Un autre service de lecture et partage de flux, récemment acquis par Google. J'utilise surtout la fonction de filtre pour quelques sites.

Imaginez qu'il y ait un blog que vous aimez bien, mais qu'il y a trop d'articles publiés. Le filtre permet de ne choisir que les meilleurs en se basant sur un algo, et crée un nouveau flux à intégrer à votre lecteur préféré.

http://www.postrank.com/user/wokier/subscriptions/2

FriendFeed

Je l'utilise plutôt comme un agrégateur, mais ne lit ni ne publie avec lui.

http://friendfeed.com/wokier

TwitterFeed

Permet d'auto-tweeter à partir d'un flux RSS, et d'ajouter un préfixe, ce sont mes [shared article].

http://twitterfeed.com/

Pages personnelles

Présentez-vous en une page...

Google Profile

Vous pouvez donner quelques informations sur vous pour définir votre profil public, qui peut être réutilisé dans les différents services google (par exemple groups), et apparrait dans les résultats de recherche.

https://profiles.google.com/u/0/wokier/about

Du Hachtemeleu et du céesses hebergé chez free, en post-it style.

http://francois.wauquier.fr/

about.me

Un petit service sympa où chacun peut créer sa page en 5min, où l'on retrouve des éléments communs, mais où l'on peut aussi personnaliser le style.

http://about.me/francoisWauquier

Questions / Réponses

Le dernier probleme que vous avez eu, peut-être que quelqu'un l'a eu avant, ou alors quelqu'un a la réponse...

stackoverflow

Pour moi le meilleur outil de question/réponses, qui a même réinventé le forum technique. Le système est très bien pensé: Choix des réponses, votes, réputation, auto-modération.

http://stackoverflow.com/users/32290/francois-wauquier

Quora

Ce truc essaie de mixer question/réponses et réseau social, mais je trouve que la mayonnaise ne prend pas. Je pense que ne sont pas les mêmes questions qui sont posées, ce sont plutôt des question ouvertes, plus proche du débat.

http://www.quora.com/Francois-Wauquier

Reseau Social Open Source

Si vous contribuez à des projets Open Source hébergés chez différents services, ces sites permettent de constituer votre profil de contributeur OpenSource.

Ohloh

Permet de regrouper vos projets, mais aussi de dire quels projets vous utilisez, en les regroupant dans une 'Stack'.

https://www.ohloh.net/accounts/wauquier

Github

Propose un hebergement git public, plus un côté social. Bien sûr les afficionados de git adorent.

https://github.com/wokier

Masterbranch

Comme ohloh, mais en plus vous pouvez importer votre experience depuis votre profil linkedIn. Vous pouvez aussi échanger des bierres, la vraie monaie OpenSource.

https://www.masterbranch.com/developer/wokier

Redirections

Je vais maintenant vous réveller mes recettes secrètes pour faire fonctionner tout cela ensemble sans faire le boulot 2 fois et laisser la liberté à chacun de me suivre comme il le désire.

Et vous, comment faites-vous ?

Agile France 2011

LA conférance annuelle de la communauté agile en france.

http://conf.agile-france.org/
http://agilemanifesto.org/iso/fr/

Jeudi 26 Mai

Jean Claude Grosjean - Dans la peau du manager agile

http://conf.agile-france.org/sessions/4d7758894ff6f7381500008e
Présentation montrant l’évolution de ce poste dans une structure agile: il conserve une partie de ses attributions, mais change de posture vis à vis de l’équipe de réalisation. Au lieu de plannifier, d’attribuer les tâche et de suivre, il donne la vision, priorise, et challenge.
http://www.slideshare.net/jcgrosjean/grosjean-management-agileagile-france2011

Jean-Phillipe Caruana - Buildr : un outil de build moderne, puissant et efficace

http://conf.agile-france.org/sessions/4d8ccbac4ff6f77395000d18
Je n’ai vu que le début de cette session, car je me préparais pour ma session. Mais cet outil est à suivre de près, car les promesses sont grandes: plus performant et plus flexible que maven.

http://buildr.barreverte.fr/
http://www.barreverte.fr/
http://buildr.apache.org/

Francois Wauquier (votre serviteur) - Les frontières de l’équipe

http://conf.agile-france.org/sessions/4d94b7cb4ff6f7089b000094
Je me suis amusé à comparer une équipe de réalisation avec un village gaulois.
Une fois que l’on a vu la frontière, il ne reste plus qu’à la supprimer...
http://www.slideshare.net/wokier/agile-france-2011-les-frontieres-de-lequipe

Gery Derbier - Top Chef : le carpacio de code

http://conf.agile-france.org/sessions/4d9392344ff6f73c470000ae
Une expérimentation de développement en petite équipe avec des stories volontairement floues, afin de mettre en avant le fait que le développement logiciel est avant tout un mécanisme de création de savoir. Une bonne simulation que j’ai eu le plaisir de réaliser avec Etienne Charignon dans un groupe de 3. Petit rappel sur la théorie des jeux coopératifs chère à Alistair Cockburn: Pour bien jouer, il faut réussir le coup et préparer le coup prochain.

Merci “@echar: #agilefrance TopChef avec Gery Derbier. C'était Top !”
— Gery Derbier (@Gery7) May 26, 2011

Eric Lefevre - Le Marsmallow Challenge

http://conf.agile-france.org/sessions/4d70b0974ff6f719b10005e4
Un petit jeu divertissant et instructif: fournir à un groupe un chamallow, des spaghettis (non cuits), du scotch et de la ficelle, et leur demander de placer le chamallow le plus haut possible.
J’ai retenu 3 leçons :
- Ne pas sous-estimer le poids du chammallow (ce que vous aller construire devra porter...)
- Avancer par petits pas afin d’avoir toujours quelque chose à présenter sans casser du spaghetti (ah oui, itératif et incrémental...)
- Les enfants s’organisent mieux que certains professionnels.
Le groupe dans lequel j’ etais a gagné alors c’est encore plus drôle.
http://marshmallowchallenge.com/Instructions.html

45cm! @elefevre lecon#1 ne pas sous estimer le poid du truc lecon#2 iterer lecon#3 les enfants s'organisent mieux! http://twitpic.com/531y1p
— Francois Wauquier ☁ (@wokier) May 27, 2011

http://www.ted.com/talks/tom_wujec_build_a_tower.html

Etienne Charignon - Lire du code

http://conf.agile-france.org/sessions/4d8fa5704ff6f752660009f7
Des bonnes pratiques présentées avec un prezi, et des exercices pratique de lecture du code. J’ai retrouvé plusieurs points de vue lus dans Clean Code. Il distingue plusieurs “causes” d’écriture d’une ligne:

Limitation de la machine
Limitation du langage
Limitations du programmeur
Raisons Historiques
Besoin/Spécifications (enfin)

Je retiens la comparaison avec la partition de musique: Quel musicien écrirait do ré mi en commentaire de sa partition?
http://etienne.charignon.free.fr/spip/spip.php?article106

http://prezi.com/nbdrq2zeihan/lire-du-code/

Damien Thouvenin - Centre de service Agile

http://conf.agile-france.org/sessions/4da6001b4ff6f75e0000004e
Retour d’ expérience d’un centre de service qui se rapproche plus de la TMA que du forfait. Je ne pense pas que ce genre de structure soit le coeur de cible des méthodes agiles, mais je retiens 2 bons principes: l’équipe unique et On ne commence pas la story suivante tant que la précédente n’est pas validée.

Vendredi 27 Mai

Mack Adams - Une carte agile de gestion de produits

http://conf.agile-france.org/sessions/4da8bc6d4ff6f73fde000273
Mack distingue les rôles de Product Owner et Product Manager. Le premier terme vient de Scrum, le second du marketing. Pour un produit de petite taille, ces deux rôles peuvent être tenus par la même personne, mais pour un produit plus complexe, avec beaucoup d’interlocuteurs et/ou une dimension marketing forte, seul superman peut tenir ce rôle. Dans son organisation d’éditeur de logiciel multi-continent, il y a même de nombreux rôles intermédiaires. Son outil préféré pour construire la vision et le backlog initial est le story Mapping, qu’il réalise sur des sessions de quelques jours.

http://www.slideshare.net/mackaraja/mack-adams-agilefrance2011cartographieagileproductmgmtpost

Jonathan Scher & Guillaume Duquesnay - Comment réussir un projet agile très court

http://conf.agile-france.org/sessions/4d984fd94ff6f74ad10001ad
Une session courte, comme les projets de quelques mois que Jonathan et Guillaume ont réalisé récemment. C’est un délai si court que l’équipe ne peut pas se stabiliser. Cela nécessite d’être encore plus discipliné. Ils recommandent de s’engager sur un enjeu, de faire sauter le sprint 0.

Pascal Van Cauwenberghe - Les bases des méthodes agiles Lean

http://conf.agile-france.org/sessions/4d961f234ff6f701570005e1
Une grande présentation avec des thèmes chers à Pascal, du rythme, de l’humour, des anecdotes.

Théorie des contraintes
Real Options
Pilotage par la valeur metier
Auto Organisation
Excellence Technique
Amélioration continue

http://blog.nayima.be/2011/06/07/conf-agile-france-2011-les-bases-des-methodes-agiles-et-lean/

http://www.slideshare.net/agilecoachnet/les-bases-des-mthodes-leanagile

Christophe Addinquy - Quand mon produit est un système d’information

http://conf.agile-france.org/sessions/4d96ec514ff6f7417600015d
Retour d’ experience du Système d’ Iinformation Back de Vidal. J’ai retrouvé beaucoup de similitudes avec les propos de Mack Adams. Ils se posent tous les deux la question de prioriser des ensembles plus gros que la story ou l’epic, que christophe appelle chantier, pour des produits de grande taille et complexes. Et ils utilisent la même image de superman pour la personne qui arriverait à définir la vision et suive dans le détail ce genre de produit.

Alexandre boutin - Lorsque Scrum ne marche pas

http://conf.agile-france.org/sessions/4d837c064ff6f70c2d000054
Plusieurs sujets possibles, mais un temps limité? Alexandre propose de choisir en utilisant la technique Buy a Feature . Le sujet est donc choisit en négociant, en criant et en courant. Le point commun des sujets, c’est une difficulté rencontrée lors de la mise en place de Scrum.
http://www.agilex.fr/

Lucian Précup - La revue de code

http://conf.agile-france.org/sessions/4da87ce64ff6f721eb000823
Cette pratique utilisée par Google, Apache, Mozilla peut être outillée afin de définir des flux de validation, revue, correction. Tout commit est considéré comme un patch. Personnellement, je reste fan du binômage.