11 novembre 2009

visual management, SCRUM et tout ça

Je sors juste de formation SCRUM Master et (ceux qui suivent ce blog le savent déjà) j'expérimente par ailleurs le management visuel.

Selon le principe du "eat your own dog food", et aussi du "mieux vaut tester d'abord sur un cas simple avant de trop se la jouer" je fais un petit essai @Home :

Je suis en train de faire la déco complète de ma chambre, donc :
  • Delphine joue le rôle du product owner. Elle donne les objectifs, comment les valider, et leur "valeur" relative - exercice un peu étrange auquel elle s'est pliée en me prenant pour un dou-dingue qui sort de sa formation tout frétillant d'excitation.
  • Je joue le rôle de l'équipe, et aussi du ScrumMaster - c'est donc totalement biaisé par rapport à la méthode théorique :)
  • Il n'y a pas vraiment de Sprint, plutôt des heures libres pour bosser par ci par là dans la semaine. Disons qu'on pratique plutôt le ScrumBan pour ceux qui ont lu cet essai.
Au niveau organisation, ça donne ça :

  • plein de choses à faire
  • une tâche entamée qui pose déjà problème et dépasse largement l'estimation en "heures idéales"
  • du mal à intégrer rapidement des tâches à forte valeur métier car elles dépendent d'autres tâches de faible valeur

  • L'objectif est donc atteint :
    • vision claire et immédiate de l'avancement (ou du non avancement dans mon cas) - ça tombe bien, c'est le but
    • vision claire des tâches à prioriser, et de la difficulté de les intégrer
    • la limitation du nombre de tâches en parallèle imposée par le kanban n'empêchent de me disperser (c'est mon gros défaut) - c'est un garde fou intéressant pour ne pas introduire de gaspillage de temps et d'énergie.
    A suivre pour savoir si l'aménagement de cette chambre terminera dans des délais raisonnables et satisfera le Product Owner, ce qui dans mon cas est un objectif non négociable ;)

    04 novembre 2009

    Travailler plus pour ... des prunes ?

    Alors que le spectre des heures sup' du samedi plane sur mon beau projet, et que certains dépassent déjà très largement les 35heures hebdomadaires, je tombe sur ce billet très pertinent. L'idée clé est de remettre en question notre perception du développement informatique, et tout le vocabulaire qu'on lui a associé.

    Il y a encore peu de temps on empruntait le langage du bâtiment pour en parler (je suis moi même "architecte", ce qui me fait un peu mal au bide quand je pense à l'expérience de construction de ma maison). Cela correspondait à une époque où il fallait faire accepter au client l'élaboration de plans et de décisions en amont

    On a ensuite inventé la software factory et l'industrialisation des développement, ce qui - dans le vocabulaire - fait de nous des ouvriers spécialisés du développement. Ce n'est pas juste une question de vocabulaire mais bien un état d'esprit : productivité, maîtrise des coûts et des délais, voila les nouvelles valeurs du développement. Il ne s'agit même plus de qualité logicielle, mais bien de production à coûts réduit.

    Pourtant nous savons tous que notre travail ne ressemble pas du tout à une usine de montage à la chaîne, et qu'au contraire nous devons à tout moment improviser des solutions aussi "pas trop mauvaise" que possible. Le développeur lui même, selon cette logique industrielle, devrait devenir un simple pantin appliquant une méthode bien rodée via des outils bien entretenus (tout ceux qui bossent sous Eclipse savent que c'est loin d'être le cas).

    Alors pour pousser ce rapprochement linguistique entre la Taylorisation et l'informatique, Est-ce qu'on vend à nos clients des projet de folie en deux mois, à condition que ce soit de couleur noire ? Bien sur que non : vive l'agilité, la compétence, la créativité, les équipes réactives et motivées. Tout d'un coup on revient dans le monde de l'artisanat d'art... cherchez l'erreur.

    De mon point de vue, le développement informatique est dans la situation d'un bijoutier qui n'aurait pas le renom de Rolex et subirait la concurrence de Swatch. Comment faire de bons produits à un prix attractif ?
    • Produire en chine et très probablement baisser en qualité (ah, l'offshore ...) ?
    • Trouver des axes d'amélioration internes (ce qui voudrait dire investir !) ?
    • Travailler sur la relation client et l'image de marque - rien de bien nouveau et que se heurte à la politique actuel du "passage obligé par le service achat"
    • Jouer la carte de la compétence, un peu comme on visite un atelier pour découvrir le talent d'un artisan ? Encore faut il avoir du talent à montrer ;)
    Je n'ai pas de solution miracle à proposer - sinon je ne serais pas là :) - par contre je plussoie ce billet d'Octo dans le sens ou de mauvaise images apportent une vision biaisée de notre travail et
    donc de mauvaises solutions.

    24 octobre 2009

    Une nouvelle méthode agile ?

    Pour faire face à une liste de tâches anarchique, j’expérimente une méthode agile de mon cru : SCUM.

    Issu à l’origine d’une faute de frappe, c’est devenu l’acronyme de SCrum for Unique Member (Scrum appliqué à sois tout seul).

    Les mêlées quotidiennes sont faciles à organiser, et en plus c’est rapide. Le simple fait de se demander ce qu’on a fait la veille avant d’attaquer est tout de même pas totalement inutile quelque fois !

    Un sprint dure de 2 jours à une semaine. Tout seul c’est tenable :)

    Jusqu’ici c’est plus du vent qu’autre chose, alors voici le BACKLOG du sprint, et ses célèbres post-it sur le tableau Veleda. L’intérêt énorme de cet outil c’est :

    • qu’il n’a pas toutes les limitations de nos trackers en tout genre avec leur cycle de gestion pourrie, leurs champs obligatoires et autres complications inutiles.
    • qu’il est dynamique – par définition, un post-it, ça se déplace - et naturellement synthétique

    L’air de rien ça permet rapidement de voir où on en est et ce qu’il reste à faire – pour certains ça ferait sans doute peur d’ailleurs, mais ce serait pourtant un bon indicateur !

    J’organise donc la “SCUM’Conf 2010”, il reste encore des places pour ceux que ça intéresse :p

    15 octobre 2009

    Une excellente Idea

    Eclipse est omniprésent, et tout le monde s’accorde pour dire que c’est devenu une usine à gaz ingérable. Je dois moi-même faire face aux excès d’humeur de mes petits camarades qui pestent sur un Eclipse “préparé” par mes soins et qui malgré ça plante allègrement ou rame tout ce qu’il peut.

    La concurrence, c’est NetBeans – qui a vraiment du mal à décoller même si on m’en a dit beaucoup de bien – et Idea, qui a une excellente réputation, mais malheureusement aussi un prix

    logo_bw[1]

    Ca, c’était la situation hier. Jetbrains vient en effet de passer son IDE en opensource

    idea9-community_header[1]

    Toutes les fonctionnalités de la version payante ne sont bien sur pas au rendez-vous, mais la liste est déjà bien assez large pour contenter les utilisateurs d’Eclipse lassés du “building workspace”

    Reste qu’il va falloir franchir le pas de dés-apprendre toute ces (mauvaises ?) habitudes qu’on a si chèrement acquises sous Eclipse, identifier les bons plugins et tout et tout, mais je suis convaincu que ce billet d’entrée sera vite amorti, à commencer par tout ceux qui galèrent avec l’intégration vraiment pourave de Maven dans Eclipse (on attend toujours ce fameux m2e 0.9.9) ...

    Pour ma part, je tente l’expérience dès demain :)

    Pour plus d’infos, ça se passe ici : http://www.jetbrains.com/idea/nextversion/free_java_ide.html

    10 octobre 2009

    Encoding Hell

    ucs-encoding[1]Je viens de perdre une nouvelle journée de boulot sur des %!@$ problèmes d’encodage. Encore un N-ième fichier XML dont l’entête déclare fièrement un encoding=UTF-8, et qui se retrouve charcuté à la sauce CP-1252 (variante MS de l’ISO-8859-1).

    Dire que depuis toutes ces années à inventer des formats interopérables et tout et tout on en est encore là ça fait pitié. J’en suis à me demander s’il n’existerait pas un petit plugin Eclipse bien malin pour convertir à la volée tous nos accents en entités xml ou en échappement Unicode – il y a par exemple le plugin propertiesEditor qui fait ça très bien … pour les fichiers properties.

    C’est peut être l’occasion de devenir totalement bilingue et de tout rédiger en anglais, histoire de ne plus sortir du bon vieux ASCII 7 bits qui est finalement le seul moyen de ne pas se prendre la tête.

    Le build Maven est un peu (!) plus stable grâce à l’option project.build.sourceEncoding mais ce n’est pas encore la panacée : il semble que le générateur de code de CXF (wsdl2java) produise du code source dans l’encodage “local”… pas gagné cette affaire.

    08 octobre 2009

    Lecture du soir...


    Mon éditrice m'a fait parvenir un petit bouquin bien sympa : un petit guide du développeur JavaScript.

    JavaScript est un langage des plus étrange : rendu indispensable par sa présence sur tous les navigateurs web, il est particulièrement obscur pour des développeurs traditionnels et comporte aussi bien des constructions très élégantes et des pièges à c.. dans lesquels on s'embourbe avec bonheur.

    Comme beaucoup, j'ai moi aussi essayé de faire du développement JS avant de tomber dans des complications sans fin, malgré l'aide de frameworks en tout genre - c'est, entre autre, ce qui m'a fait aimer GWT ;)

    Dans ce petit guide, Douglas CrockFord (YahooUI) prend d'office le parti d'écarter tout ce qui fait de JavaScript un langage tout pourri - sans se voiler la face - et ne présente donc que ce qui fait de JavaScript un langage prodigieux. C'est une des raison de la taille réduite du livre : hors sujet le DOM du navigateur, Ajax et ses implémentations merdiques d'un navigateur à l'autre. Ici on se concentre sur le coeur du langage, son fonctionnement et sur les bonnes façons de faire.

    Pour un développeur débutant c'est clairement le livre idéal : comme on y apprend seulement ce qui marche bien, on est au moins sûr de ne pas prendre un mauvais pli. Pour les personnes plus expérimentées, la piqûre de rappel est salvatrice - j'ai enfin compris pourquoi this change si souvent de nature dans une fonction JS :)

    Le livre se termine par plusieurs annexes qui dénoncent les aberrations du langage et ses mauvais éléments. Une bonne façon, une fois les bonnes pratiques acquises, de savoir là où il ne faut pas mettre les pieds et donc savoir les repérer.

    Un excellent ouvrage, concis mais dense. Il donne du sens à ce langage méconnu et si loin de nos bon vieux langages objet fortement typés et basés sur des classes. Un indispensable pour toute personne qui compte se lancer dans un développement JavaScript, probablement plus indispensable que les nombreuses "bibles" du JavaScript en 400 pages qui sont bien plus délicates à exploiter. Bien sûr, pour être applicable en développement il faudra lui adjoindre une bonne référence sur l'API DOM et ses variations entre navigateurs.

    Seul regret, je n'ai pas retrouvé d'information sur les problèmes de fuites mémoire, si caractéristiques des Closures JavaScript - peut être qu'une seconde lecture plus approfondie s'impose ;)


    Disclaimer : bien que lié par contrat à Pearson dans un autre contexte, cette revue ne m'a pas été dictée et je parle donc en toute franchise :D



    05 octobre 2009

    HTML 5 - il va falloir réapprendre à coder :)

    Au moins ceux d'entre vous qui suivent les actualités de Ajaxian.com ont entendu parler des progrèés sur HTML5. En particulier, Chrome 3 - webkit en général - le supporte

    NB : je dis "le supporte", bien que ce soit partiel vu que HTML5 n'est pas une norme définitif mais un travail collectif.

    Jusqu'ici je restais assez dubitatif, jusqu'à ce que je tombe sur cette démo : http://www.raymondhill.net/puzzle-rhill/jigsawpuzzle-rhill.php

    Manipulation d'images à la souris, rotations et autres transformations, des choses dans l'absolu assez simples mais qu'on a pas l'habitude de voir en dehors d'un conteneur Flash. HTML5 promet donc d'ouvrir les portes aux pages riches et animées, sans passer ni par des magouilles de développement, ni par un runtime qui rend le client "léger" semi-lourd.

    Faites donc joujou avec la démo, puis faites l'exercice : si un client me demandais un truc de ce genre, qu'est ce que j'aurais à lui proposer comme solution ?

    02 octobre 2009

    Google Chrome Frame : amusant

    Google nous sort un de ces petits ovnis dont il a le secret : Google Chrome Frame.

    Il s'agit d'un plugin pour IE qui remplace tout simplement le moteur de rendu du navigateur le plus décrié mais aussi le plus installé par le moteur Chrome. Celui-ci n'est actif que sur les pages qui déclarent une balise magique, autrement dit quelques sites de geek et probablement quelques applications Google, mais pas plus. Un petit Script est proposé par Google pour permettre à ces sites de proposer l'installation de Frame sur postes qui ne l'ont pas encore.

    Il est évident que la cible n'est pas l'entreprise, car si on y utilise encore massivement IE6, c'est à cause d'applications utilisant massivement des ActiveX et/ou l'authentification MS Active Directory, ou simplement pour ne pas mettre des sous dans une migration technique risquée (?) et sans R.O.I. facilement chiffrable.

    De mon point de vue, la cible c'est les millions de particuliers qui utilisent IE juste parce qu'il est fournit avec l'OS, qui n'ont aucune idée de ce qu'est un navigateur (je pense à ma belle mère qui "clique sur Internet"). Ceux qui ont déjà installé sans trop réfléchir le plugin Flash par ce que le site de la redoute le demandait, et qui installeront donc Frame un site grand public de renom le propose (par exemple ... www.google.com ?)

    Quel intérêt pour Google ? Faire que le web soit toujours plus consommé par les utilisateurs à la place de l'informatique traditionnelle. Les gMail, gDocs, gCalendar et consorts ne gagneront du terrain que s'ils sont au moins aussi performants que l'équivalent desktop. Ce qui signifie bien sur un moteur rapide - en tout cas plus que celui natif d'IE - et le support du mode déconnecté (google Gears).

    Ceci dit, il y a un intérêt pour Frame en entreprisse : sur un SI massivement MS/IE, proposer une installation 'transparente' de la petite extension magique reste acceptable (enfin, pas pour tout le monde), et cela ouvre aux développeur de nouvelles possibilités (HTML5 !) pour les nouvelles applications. Penses-y, amis lecteur, si tu es DSI - vous êtes probablement plus nombreux à être des geeks furieux, mais sait-on ...


    21 septembre 2009

    AOP et autres instrumentations du bytecode

    Quand on découvre l'AOP (programmation orientée aspect) à travers les blogs et autres résultats que nous propose Google, on tombe immanquablement sur un exemple d'instrumentation du code par des logs.

    Si d'un point de vue didactique c'est un exemple qui a l'avantage d'être parlant pour tout le monde, d'un point de vue technique c'est une aberration :
    • les outils de logs modernes déterminent le nom de la classe/méthode et numéro de ligne à la volée, il serait donc dommage de perdre cette info dans nos logs. Or, en passant par un aspect, ce mécanisme va pointer dans le greffon de l'aspect, et pas là où on l'a appliqué
    • chaque ligne de log va nécessiter l'invocation du greffon, la copie des arguments, peut être même la construction d'un logger pour la classe considérée. Des millièmes de secondes qu'on va répéter des millions de fois, au final un dégradation mesurable des performances du code (si vous n'y croyez pas, j'ai vu une appli perdre 10% de son temps dans des mécanismes de log mal fichus).
    Evidemment, parler de gestion transactionnel pour montrer l'utilisation de l'AOP n'est pas le plus simple...

    Je rebondis cependant sur ce problème pédagogique : l'idée de base est bonne

    Personne n'apprécie de devoir lire des logs vides, mais n'aime pas pour autant passer du temps à ajouter des logs DEBUT/FIN dans tout le code, et voir une méthode initialement si belle et explicite polluée par des lignes de logger.trace( param = truc ).

    J'ai donc créé Logeek, un outil d'instrumentation du bytecode qui ajoute ces fameux logs si indispensables et si disgracieux. Contrairement à un outil d'AOP, Logeek fait de l'instrumentation agressive en ajoutant directement un attribut logger et le traçage des paramètres dans chaque méthode, là où AspectJ déporterait l'appel dans le greffon.

    En gros, partant de ce code :

    public boolean doSomething( String value, int count )
    {
    System.out.println( "done" );
    return true;
    }

    Loggek va modifier le bytecode pour qu'il ressemble à ceci (en pseudo-code puisque le source n'est pas modifié, et le bytecode n'a pas exactement cette structure)
    private static transient Logger __logger
    = LoggerFactory.getLogger( Foo.class );

    public boolean doSomething(String value, int count)
    {
    boolean returnedvalue;
    try
    {
    __logger.debug( "{" );
    __logger.trace( " value = {}", value );
    __logger.trace( " count = {}", count );

    System.out.println( "done" );
    returnedvalue = true;
    }
    catch (Throwable throwable )
    {
    __logger.trace( " throws {}", throwable );
    throw throwable;
    }
    __logger.trace( " return {}", returnedvalue );
    __logger.debug( "}" );
    return returnedvalue;
    }
    Pour comparaison, AspectJ produirait une transformation du bytecode qui ressemblerait plus à ceci :

    public boolean doSomething(String value, int count)
    {
    boolean returnedvalue;
    try
    {
    String arg1 = value.clone();
    int arg2 = count.clone();
    LoggingAspect.aspectOf().before( this, arg1, arg2 );

    System.out.println( "done" );
    returnedvalue = true;
    }
    catch (Throwable throwable )
    {
    LoggingAspect.aspectOf().afterThrowable( this, t );
    throw throwable;
    }
    LoggingAspect.aspectOf().after( this, returnedvalue );
    return returnedvalue;
    }
    La différence est subtile, mais dans ce second cas la source du log est le greffon de l'aspect, pas le code instrumenté, et au passage on paye même en mode TRACE (généralement désactivé) le prix d'une copie d'arguments et de plusieurs appels de méthodes.

    Avec ce mécanisme activé on obtient donc, en TRACE, toutes les infos utiles sur le code exécuté. L'utilisation de SLF4J permet de ne pas s'encombrer de if logger.isDebugEnabled(), mais l'outil pourrait tout aussi bien se baser sur l'API log4j et ajouter ces contrôles.

    Pour marquer le début/fin des méthodes j'utilise des accolades, car dans un éditeur un peu malin (comme NotePad++) le curseur positionné à côté met immédiatement en évidence sa petite soeur - c'est bien pratique ;)

    Tout ça via un plugin Maven, qu'il suffit d'ajouter à son POM.xml (qui sans ça serait bien trop concis)


    <plugin>
    <groupid>fr.loof.logeek</groupid>
    <artifactid>logeek-maven-plugin</artifactid>
    <executions>
    <execution>
    <goals>
    <goal>instrument</goal>
    </goals>
    <configuration>
    <includes>
    <include>**/*.class</include>
    </includes>
    <transformer>fr.loof.logeek.Slf4jLogging</transformer>
    </configuration>
    </execution>
    </executions>
    </plugin>


    Logeek devrait être déployé dans le dépôt Maven central sous peu, en version 0.0.1. Je suis ouvert à toutes vos suggestions pour la 0.0.2 :)

    18 septembre 2009

    premiers pas avec GWT 2.0

    Le plugin gwt-maven-plugin est disponible en version 1.2-SNAPSHOT avec un aperçu du support GWT 2.0. Les fonctionnalités ne sont pas forcément sans bugs et probablement encore incomplètes, mais les nouvelles options du compilateur sont déjà proposées.

    La mise en oeuvre nécessite de récupérer le SDK (prendre par exemple les builds proposés par SFEIR). Configurer ensuite le plugin en affectant le paramètre gwtHome, pour le forcer à utiliser cette version, alors que par défaut il s'adapte à vos dépendances.

    Vous avez alors accès à tout plein de nouvelles fonctionnalités, comme par exemple le draftCompile pour accélérer votre intégration continue, ou le rapport SOYC pour analyser la traduction de votre code Java en JavaScript et ses points noirs.

    Pas de date prévue pour la finalisation de cette version 1.2, mais je vais essayer de coller à l'actualité de GWT 2.0.

    14 septembre 2009

    Hibernate est un sacré comique

    Alerté par Julien, je fais un peu joujou avec les annotations @OneToOne et Hiernate.
    Voici grosso modo ce que je manipule :


    @OneToOne( fetch = FetchType.LAZY )
    private Foo precedent;

    @OneToOne( mappedBy = "precedent", fetch = FetchType.LAZY )
    private Foo suivant;
    Et là, dès que je charge une instance, j'ai autant de select qui partent en base que j'ai d'éléments dans ma chaîne suivant-précédent...

    Le piège, c'est que malgré le LAZY, hibernate veut identifier si la relation OneToOne inverse (mappedBy) est renseignée ou non. En fonction de la réponse il colle un proxy ou null.

    La solution, bien que pas très esthétique dans le code est simple : utiliser des OneToMany et se baser sur des collections de 1 élément :


    @OneToMany( fetch = FetchType.LAZY )
    private Set<Foo> suivants = new HashSet<>();

    public Foo getSuivant()
    {
    Iterator<Foo> it = suivants.iterator();
    return it.hasNext() ? it.next() : null;
    }

    public void setSuivant( Foo suivant )
    {
    for ( Foo item : suivants )
    {
    item.setPrecedent( null );
    }
    this.suivants.clear();

    suivant.setPrecedent( this );
    suivants.add( suivant );
    }


    Ca sent la grosse magouille, mais au moins ça ne casse pas la logique des get/set. Comme quoi la persistance "transparente" c'est pas encore tout à fait ça ;)

    BreizhJUG - saison 2

    Après deux mois de repos (?) pendant l'été, le BreizhJug repart sur les chapeaux de roue avec trois speackers pour une session spéciale "Spring ecosystem".

    Comme toujours, je prépare la session au dernier moment. Je n'échapperais donc pas au gros coup de stress en me rendant compte que j'ai une fois de plus oublié un truc.

    Histoire de se détendre, aujourd'hui c'est livraison au boulot, avec toute la ruche (pardon, l'openspace) attentive au moindre bug qui trainerait sous un tapis - disons que si on arrive au moins à faire passer tous nos tests jUnit ce serait un bon début.

    Rendez-vous ce soir :)

    04 septembre 2009

    Bye bye XP, welcome 7

    Hier soir, bonne surprise, mon processeur a cramé (sur le coup ça ne m'a pas vraiment fait rire).

    Comme j'avais prévu de renouveler ce "bon vieux" PC j'avais déjà sous le coude les composants de remplacement, j'ai donc juste du accélérer un peu les choses... En tant que committer Apache, j'ai droit à un abonnement MSDN et donc j'ai déjà Windows 7 FR alors que vous autres pauvres mortels devrez attendre le 22 octobre ;)

    Première bonne surprise, contrairement au 2h nécessaires pour installer XP, Seven s'installe "à la Linux" en une seule passe : pas de reboot en série et installation directe depuis le DVD - manque plus qu'à en faire un Live DVD ;)

    Seconde bonne surprise : tout mon matos est reconnu. Heureusement vu que Micro$oft a une fois de plus revu son API de drivers (elle doit être encore mieux que celle de Vista qui était déjà bien meilleure que celle de XP qui corrigeait les défauts de celle de 2000 qui remplaçait les défaillances de NT). Donc tous mes CD d'accompagnement conservés soigneusement s'avèrent inutiles.

    Je n'ai pas encore utilisé suffisamment le système pour me faire une opinion, et comme je ne suis pas passé par la case "vista" c'est assez déconcertant au début. J'ai a peu près trouvé mes marques pour l'instant.

    Reste à installer la panoplie des petits softs qu'on accumule au fil du temps et qui deviennent indispensables mais dont on ne sait même plus le nom ;)

    31 août 2009

    les cochons dans l' (open-)space

    Je découvre avec joie les plaisirs de l'openspace. Je m'en sort bien vu que le maxi-bureau est immense et réserve de grands espaces à chacun. Cependant il reste un bruit ambiant assez bas mais malgré tout omniprésent. J'ai horreur de bosser "dans une bulle" avec un casque sur les oreilles donc il va falloir que je m'y fasse, mais la concentration en souffre...
    Par ailleurs, on perd en convivialité puisqu'on a plus vraiment un ou deux collègues de bureau mais un "groupe local" pas vraiment proche.
    La cerise sur le gâteau c'est que le café du distributeur est infect.

    Youpi youpi

    11 août 2009

    la bonne gestion des versions

    Je me suis pris la tête avec une incompatibilité entre deux versions de bibliothèque.

    J'utilise mx4j, et pour faire de l'admin à distance sans RMI (pour diverses raison que je ne vais pas développer) j'utilise un connecteur HTTP. Mx4j utilise pour ça Jetty en mode embarqué.

    J'utilise aussi SoapUI, pour produire des mock des services que j'invoque. Lui aussi utilise Jetty.

    Là où le bât blesse c'est que SoapUI utilise Jetty6, dont le code est complètement revu par rapport aux versions précédentes. L'API totalement incompatible rend mx4j inutilisable. Du coup je regrette presque de ne pas faire de l'OSGi - presque, je n'ai pas encore mis un orteil dans ce truc mais ça à l'air assez casse-gueule ;)

    Je m'en suis sorti pour pas cher en faisant un bout de code pour adapter mx4j à Jetty6, mais j'en retiens une règle de développement : un changement d'API devrait TOUJOURS s'accompagner d'un changement de nom de package. JAXB2 utilise par exemple com.sun.xml.bind.v2. C'est peut être pas très joli, mais au moins on s'évite de nombreux conflits.

    Java Cloud computing - an 1

    Vous faites peut être partie de ceux qui ont reçu un "ID" pour jouer avec Google App Engine for Java.

    Vous avez peut être testé le support "EC2" de Hudson pour bénéficier d'une réserve de puissance lors des piques de charge de votre intégration continue.

    Dans tous les cas vous êtes convaincu que le cloud computing n'est plus une vue de l'esprit mais bien une solution concrète et disponible aujourd'hui ?

    Et bien réjouissez-vous : VMWare vient de se payer SpringSource, dont l'engagement en faveur d'OSGi est bien connu. Imaginez donc une ferme de Spring DM Servers, supervisée par un monitoring Hyperic (racheté par SpringSource), et accessibles en mode cloud via des machines virtuelles sur laquelle vous déployez depuis Eclipse vos bundles OSGi métier ...

    Moi, dans ma vraie vie je fais encore du JEE, et encore je viens juste de migrer en Java5, mais on peut tout de même rêver un peu ;) Quoi qu'il en soit, raisonner en "cloud" va devenir une facette importante du métier, alors préparer vous !

    Besoin de pistes ? Allez lire le blog du touilleur qui vous expliquera tout sur le sujet !

    10 août 2009

    m2eclipse - pas encore près pour la prod !

    Après des mois à essayer de configurer au mieux m2eclipse, d'alléger le workspace au maximum et de trouver des astuces pour que le "build automatically" soit exploitable sous Eclipse la conclusion s'impose : m2eclipse n'est pas prêt !

    m2eclipse prend comme parti de laisser Maven gérer les "ressources" (fichiers de conf, XML...) à la place d'Eclipse. Vu que l'utilisation du filtering Maven reste marginale ça ne concerne que peu de personnes. Cependant, cela signifie pour les autres un cycle mvn process-resource à chaque build incrémental d'Eclipse.

    ... et il y en a un paquet des builds incrémentaux, sans parler des multi-modules ou chaque projet déclenche un build des autres. On termine donc avec des builds maven en pagaille, à reconstruire 10 fois le même module :'(

    Alors, oui, m2eclipse permet à notre générateur de code de prendre en compte la moindre modification de WSDL. Mais qui modifie son WSDL chaque minute ? Le prix à payer est délirant, à moins d'avoir un PC octo-processeur à quatre coeurs (et encore ?).

    Moralité : le bon vieux mvn eclispe:eclipse, bien qu'il soit parfois un peu compliqué à configurer au petits oignons (je pense à AJDT) a de beaux jours devant lui !

    03 août 2009

    Rumeur ...


    J'apprends avec surprise par Messenger interposé que ma collègue du bureau d'à côté est enceinte de 8 mois. Il faut dire qu'avec 40KTM elle cache bien son jeu.

    L'info semble malgré tout se confirmer via une autre personne (désirant rester anonyme) ayant eu une information non-confirmée concernant des triplets à venir...

    L'intéressée refuse tout commentaire (c'est donc très louche), cependant le planning du projet encourage un sérieux doute avec 10 mystérieux jours de congés prévus à la fin du mois.

    Reste à savoir qui est le père ...

    31 juillet 2009

    35 ans, presque mort...

    Amusant de lire ici et ici le même constat que je peux faire :
    dans le système français, soit on devient chef, soit on est une moule. Donc quelqu'un qui fait encore du code après 10 ans d'expérience c'est pas logique, il devrait depuis longtemps diriger des juniors qui codent à sa place, voire diriger des chefs qui ont leurs propres sous-fifres.

    Il va donc falloir que je revoie un peu mon CV pour me propulser chef de software factory (i.e. le gars qui arrive encore à comprendre comment démerder le build maven), ou chef de la cellule d'innovation et de veille technologique, ou chef de la machine à café, enfin chef d'un truc quelconque.

    30 juillet 2009

    maven, eclipse et aspectJ : si si, ça marche

    Mon projet préféré du moment est une énorme usine à gaz avec un bon paquet de modules Maven. Sous Eclipse avec m2eclipse, des builds Maven se lancent en pagaille si on active le "build automatically".

    Soucis, mon projet dépend énormément d'aspectJ (via mon Fonzie à moi que j'ai) et la compilation maven prend des plombes.

    • option 1 :
    décocher le build automatique. Il faut alors lancer des builds à la main et bien sur dans le bon ordre, autant dire que c'est galère aussi et qu'on se retrouve souvent à exécuter du code qui ne colle pas aux sources
    • option 2 :
    ne plus gérer les relations inter-projet sous eclipse en tant que tel, mais passer par les JAR. On lance donc explicitement un gros build Maven avant de tester. Plus prédictif mais pas du tout productif
    • option 3 :
    Utiliser AJDT 2.0, dont le build incrémental est un régal. Soucis : si l'intégration avec m2eclipse configure tout bien comme il faut AJDT, le plugin Maven est toujours exécuté lors des builds maven et on retrouve le problème initial. D'où ce magnifique hack :

    <profiles>
    <profile>
    <id>m2eclipse</id>
    <activation>
    <property>
    <name>osgi.bundles.defaultStartLevel</name>
    </property>
    </activation>

    <build>
    <plugins>
    <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <configuration>
    <excludes>
    <exclude>**/*.java</exclude>
    </excludes>
    </configuration>
    </plugin>
    </plugins>
    </build>
    </profile>

    Avec cette conf magique, AJDT est correctement configuré par m2eclipse et fait parfaitement son boulot (le hotswap permet ainsi d'éditer le code et de constater le résultat à chaud dans Tomcat), ET les build maven sous eclipse sont raisonablement rapides, le plugin aspectj ne faisant plus rien.

    C'est un hack bien pourri, mais ça montre que m2eclipse 0.9.9, une fois le "custom lifecycle mapping" en place et supporté par de nombreux plugins, devrait nous faire oublier toutes ces années de cohabitation difficile entre Maven et Eclipse.

    maven, eclipse et aspectJ : si si, ça marche

    28 juillet 2009

    Maven et Hudson main dans la main


    Mon projet prend 30 minutes pour se construire, tests IT compris. Dans de nombreux cas, les modifications associées à un commit ne concernent qu'un sous ensemble de modules et un échec pourrait être détecté en une dizaine de minutes. Même constat pour le retour au bleu : 30 minutes d'attente pour constater qu'une correction en périphérie du projet est valide, avec une reconstruction de 90% du projet qui n'est pas du tout concerné.

    Pour le rendre plus réactif, j'ai du découper "manuellement" le projet selon ses modules maven (principaux) et prévoir les chemins SVN et autres commandes MVN pour que seuls les projets considérés soient construits. Ca va déjà nettement mieux, mais pour pousser la logique jusqu'au bout il faudrait configurer un job Hudson pour chaque module maven, et assurer la mise à jour de ces jobs à chaque modification de la structure des modules.

    C'est fastidieux, et source de soucis divers, mais bon ça marche et mon build est devenu nettement plus réactif - effet de bord non négligeable, on est passé au grand bleu après de nombreuses heures de gyrophare rouge allumé dans le couloir...


    Je pourrais conclure là dessus, mais Hudson n'en finit plus de métonner :

    Vous le savez peut être, Maven 2.1 permet de spécifier une liste de modules à construire, plutôt que de se coltiner tous les modules d'un multiprojet. Maven se comporte alors à la make, c'est à dire qu'il va construire les modules spécifiés + tous les modules nécessaires. On peut aussi lui demander de se comporter à la hudson, c'est à dire de construire tous les modules qui peuvent potentiellement être impactés par les modules construits.

    Il ne restait donc qu'un pas à franchir pour que Hudson puisse (enfin) construire intelligement les projects Maven un peu trop volumineux en ne sélectionnant que les modules impactés par un commit.

    Avec la révision 138 d'Hudson, prévue en fin de semaine, une nouvelle option avancée dans les options de build Maven devrait apporter cette fonctionnalité tant attendue. Jusqu'ici seul Continuum savait gérer finement les modules Maven, voici donc que son concurrent vient lui couper l'herbe sous le pied.

    Elle est pas belle la vie ?
    (en fait non, il y a encore Eclispe, JBoss, et ma non-augment' de fin d'année à considérer)

    23 juillet 2009

    spam attack

    L'instance Jira qui héberge les rapports d'anomalies et d'évolution des projects Apache et Codehaus subit une attaque en règle de la part d'un spammeur.

    De nombreux tickets sont créés avec des titres à la "Angélina Jolie Nue" et un lien vers une vidéo. Du pur spam pourri, mais l'attaque est sérieuse car le spammer semble disposer d'un grand nombre de compte, ou d'un bon script pour en créer à la demande. Le Jira comporte désormais quelques centaines de références à des stars du showbiz, ce qui change un peu des NullPointers, mais n'est pas vraiment très utile aux projets considérés.

    Comme quoi le contrôler par eMail de confirmation et autre Captcha n'empèche pas ce genre de choses.

    m2eclipse - avec modération

    La dernière version "dev" de m2eclipse (0.9.9) introduit les prémisses de ce que pourrait être un support correct de Maven dans Eclipse.

    L'idée est de marier les plugins Maven avec le build incrémental d'Eclipse, plutôt que de lancer en série des builds Maven (potentiellement bien assez longs) à chaque modification d'un fichier du workspace. Dans la version 0.9.8, avec un bon gros projet multi-module et quelques plugins de génération de code ou d'instrumentation AOP le build automatically est absolument inexploitable.

    On peut donc espérer voir enfin le bout du tunnel ... et effectivement sur un projet de test la différence est significative. On se croirait presque sous InteliJ Idea :)

    Tout irait bien si cette 0.9.9 ne devait pas ce fonctionnement avancé à un build récent de maven 3, ce qui inclut les nouvelles API de gestion des artefacts maven (Mercury). Autrement dit, tout plugin qui dépendrait un peu trop des API de résolution d'artefacts gaufre lamentablement avec cette version. Exemple, la génération de code JAXB (org.jvnet:jaxb2-maven-plugin) :

    java.lang.NullPointerException
    at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(

    Ca peut aussi prendre des formes plus amusantes :

    java.lang.NoSuchMethodError: org.apache.maven.artifact.resolver.ArtifactResolutionResult.getArtifactResolutionNodes()Ljava/util/Set;

    Précisons aussi que l'API des ProjectConfigurator a changé. Elle donnait un avantage à m2eclipse en permettant de configurer automagiquement les plugins Eclipse équivalent de plugins Maven (SVN, Checkstyle, Sysdeo-Tomcat...). Il va falloir attendre la mise à jour des quelques plugins Eclipse qui ont fait l'effort de développer un support Maven2, et/ou la totale compatibilité des plugins Maven2 avec Maven3.

    Moralité : à moins d'avoir un projet vraiment pas bien méchant, ne tentez surtout pas la mise à jour ! Ce numéro de version symbolique "0.9.9" ne signifie pas selon moi qu'on est si proche que ça d'un m2eclipse 1.0-final capable de prendre en charge des projets Maven issus de la vraie vie.

    16 juillet 2009

    ie8 est là


    Surprise ce soir - "des mises à jour sont disponibles : ie8 pour XP"

    La nouvelle mouture du navigateur le plus décrié et le plus installé (à l'insu de votre plein grée) est donc en train d'exploiter ce formidable outil de distribution qu'est windows update pour venir s'inviter sur les PC grand public.

    Je ne vais pas vous raconter ce qu'il y a de nouveau dans ce navigateur (je vous laisse googler) mais on peut espérer un peu mieux que IE7, tout en sachant d'avance qu'on restera en retrait de ses petits camarades.

    La bonne nouvelle c'est que GWT est déjà prèt pour IE8, et que le récent GWT 1.7 permet de produire une version de nos applis web optimisée pour le meilleur support CSS/JS/HTML de ce nouveau navigateur ... à condition que la page hôte ait un Doctype HTML Strict ! Compatibilité oblige avec les millions de sites au code HTML poubelle, en son absence c'est direction "quirk-mode" et fonctionnement équivalent à ie6/7

    Et comme toujours, quel sera le naviagateur majoritaire en entreprise ? IE6 ! Pour ne pas se coltiner une migration dont les effets de bords sont innombrables, couteux et mal maitrisés, aucun DSI ne pousserait en ces temps de restrictions budgétaires à passer à IE7 qui n'apporterait rien, et encore moins à un IE8 qui fait à peine mieux.

    Conclusion : on est pas prèt de voir des applis intranet exploiter CSS3 ...

    ... sauf si une proposition, évoquée sur la liste gwt-contributors, est retenue : utiliser le defered binding pour supporter des fonctions CSS3/HTML5 depuis GWT, en ayant recours à des "hacks" sur IE. Par exemple les boxes à bord rond peuvent être rendus par une simple directive CSS sur tous les navigateurs non Microsoftesques et via un .htc ou une ignoble imbrication de <table> sous IE.

    Le monde du web n'a pas fini de nous surprendre

    03 juillet 2009

    10 jours offline

    A partir de demain va commencer pour moi une épreuve sans équivalent : 10 jours de vacances sur l'île d'Oléron ... sans accès à Internet !

    Je vais donc devoir m'inscrire à l'école de Surf pour me lessiver la boîte à neurones, ou pire, jouer avec les enfants (quelle horreur !). Ma dernière session de Surf remontant à ... 10 ans, sur une Bic Alto (je sais, c'est pas un surf mais un funboard, et bien ça marche pas si mal), la seconde option sera peut-être même la seule possible :'(


    Je pense jalousement à mes collègues qui restent confortablement au boulot, bercés par le doux ronflement du ventilateur, avec une belle connexion permanente et illimité au Net ... bande de veinards.

    update 14/07 :
    Vous connaissez le principe : "en recopiant son dessin, notre dessinateur a commis 7 erreurs. Seras-tu capable de les retrouver ?"



    Le BreizhJUG en vacances


    Pendant l'été, le BreizhJUG organise un super concours photo. Pour participer il suffit d'envoyer à team@breizhjug.org une photo de son lieux de vacance mettant en scène le logo du JUG. L'originalité sera bien sur récompensée, mais l'exotisme peut aussi aider, pour remporter un magnifique lot (non encore déterminé, mais promis il sera chouette).

    Ma modeste contribution, suite à un petit week-end touristique :

    02 juillet 2009

    Le BreizhJUG fait son cinéma

    Comme le BreizhJUG est fermé pendant l'été, il faut bien s'occuper, et surtout ne pas perdre le contact avec nos membres. Aussi nous avons tourné hier soir une vidéo de promotion :


    Le scénario est de moi, d'où sa très grande richesse, ainsi que la réalisation, d'une exceptionnelle qualité merci.

    Un grand merci à Marie-Christine de s'être prétée au jeu et d'avoir afronté les regards quelque peut surpris de ses collègues lorsqu'elle a tenté le high-kick triple-salto dans le couloir (malheureusement coupé au montage).

    Passez le mot :)

    25 juin 2009

    Laser Saber Extreme Feedback Device (TM)


    Ca le fait, non ?

    assembly mon amour...

    Le plugin maven-assembly est probablement le plus énervant de la galaxie Maven.

    Comme de nombreux Mavenistes j'utilise "l'héritage naturel" qui consiste à utiliser un même POM pour définir les modules du projet et comme parent commun.

    Effet de bord : la construction mvn install commence par le parent, puis les modules, ce qui est logique si on veut que les modules "voient" leur parent dans son état final.

    Maintenant, si je veux produire un assembly, ce plugin doit s'exécuter ... après les modules. Le bon vieux problème de l'oeuf et de la poule !

    Une solution simple qui peut servir à d'autres : un POM "pom-assembly.xml" qui ne déclare que le plugin assembly attaché à la phase install et un unique module "."

    <modules>
    <module>.</module>
    </modules>

    <build>
    <defaultgoal>install</defaultgoal>
    <plugins>
    <plugin>
    <artifactid>maven-assembly-plugin</artifactid>
    <inherited>false</inherited>
    ...
    </plugin>
    </plugins>
    </build>

    en lançant un mvn -f pom-assembly.xml install maven va enchaîner l'install des modules mais pas celle de ce POM qui n'est plus le parent global.

    D:\projets\xx>mvn -f pom-assembly.xml
    [INFO] Scanning for projects...
    [INFO] Reactor build order:
    [INFO] xx parent
    [INFO] xx :: Composants GWT
    [INFO] xx :: configuration
    [INFO] xx :: infrastructure
    [INFO] xx :: wsdl
    [INFO] xx :: modele
    [INFO] xx :: services
    [INFO] xx :: persistance
    [INFO] xx :: ordonnanceur
    [INFO] xx :: services web
    [INFO] xx :: batchs
    [INFO] xx :: simulateurs
    [INFO] xx :: ear
    [INFO] xx :: tests d'intÚgration
    [INFO] xx :: assembly
    [INFO] -----------------------------------------------

    Je sais, ça sent le gros hack à deux cents, mais ça dépanne en attendant Maven 3

    24 juin 2009

    Saber light extreme feedback device


    A la demande générale, et pour tous ceux qui comme moi ont rangé depuis bien longtemps leurs cours d'électronique et ne veulent pas réinventer la roue, voici le schéma de mon montage


    Pour l'alim j'ai indiqué 9v mais peut importe, vu qu'on a un suiveur de tension il faut juste "plus de 5v". Je n'ai pas mis de fusible sur le schéma, mais pensez y tout de même.

    Et ne venez pas vous plaindre si vous vous flanquez du 220v dans les didis, j'en ai pris ma dose moi aussi :)

    Le monde méconnu de la sécurité

    Sur cette vidéo, on découvre comment n'importe quel blaireau avec les bons outils peut pirater le compte gMail de ses petits copains.

    En y regardant de près, il ne faut que quelques outils bien ficelés et un peu d'exercice au hacker amateur. La sécurité informatique est un mode étrange dans lequel seuls quelques gars pointus savent comment craquer tel protocole ou application, mais ou l'outillage met cette connaissance entre les mains de tout le monde. C'est un peu l'arme atomique numérique à la portée de tous les Docteurs No du coin.

    Dans le cas de gMail il suffit de configurer son compte pour n'être accessible qu'en HTTPS. Combien d'entre nous ont cette option activée ? Dans mon cas elle ne l'était pas (aucune des options n'était cochée, je ne sais pas quel comportement par défaut s'applique dans ce cas).

    Reste que ce genre de vidéo, avec la petite musique à la benny hill, montre à quel point la sécurité d'un réseau est à la merci de quelques outils bien lêchés et surtout à quel point on y es peu sensibilisé. On trouve sans chercher bien loin des distributions Linux en live-CD toutes prètes pour attaquer un réseau avec la panoplie complète du petite Ethan Hunt amateur. Et quand on parle sécurité avec un développeur on peut être surpris de la méconnaissance totale du domaine et de ses implications. Demandez juste pour rigoler ce qu'est un DOS (non, pas celui de Microsoft) ou un XSS...

    Pour ceux qui auraient raté l'info, en 2007 l'Estonie a été numériquement paralysée (un comble pour un pays qui a tout misé sur le Net) - tout ça pour une histoire de statue déplacée. Un reportage d'Arte sur le sujet suggère que l'attaque provenait non pas des services secrets Russe ou mais de quelques hackers isolés qui ont "protesté" contre une décision en apparence mineure du gouvernement Estonien. Rapidement revenus à des activités plus lucratives ceci expliquerait que l'attaque se soit arrêtée après quelque jours sans que les spécialistes Estoniens aient réussi à faire quoi que ce soit. Comme quoi quelques gars bien outillés et pas manchots peuvent faire bien plus que vous piquer votre compte gMail.

    Tiens, une idée pour le prochain concours de développement sur Androïd :
    Une appli qui cracke automagiquement toutes les connexions Wifi, WEP ou WPA qui trainent, et permettent ainsi de surfer "gratos et anonyme". Les briques de base existent pour le faire (vous croyez être l'abri ? désolé) reste à en faire une belle appli pour neuneu avec un gros bouton bleu "Connect to Internet"

    13 juin 2009

    extrem feedback device


    Comment sensibiliser l'équipe au bonnes pratiques de l'intégration continue ?

    Le contexte :
    • un bon gros projet (50 personnes * 16 mois),
    • un approche "V" pas du tout agile (déjà plus d'un an de conception dans les pattes), ce qui n'interdit pas d'emprunter aux méthodes modernes quelques bonnes pratiques,
    • une équipe hétéroclite, avec de nombreux "juniors", regroupés dans 5 équipes par couche technique - sensées collaborer ;) - et des buils Hudson FAILED à tour de bras.
    Actuellement, certains ont bien pris possession du concept d'intégration continue et suive régulièrement l'état d'Hudson. D'autres par contre semblent peu s'en préocuper et sont dans un esprit "chacun sa m..", ce qui se traduit par des commits qui cassent le projet sans que personne ne réagisse.

    Les piqures de rappel n'ayant pas données de résultats très convaincants, surtout que je suis loin d'être un bon exemple, je voulais expérimenter une approche plus ludique : le feedback visuel

    "Extreme feedback device" : trois lampes qui illuminent le couloir pour indiquer l'état du build - difficile de passer à côté et de faire l'indifférent. Un truc comme ça :


    La commande se fait depuis le PC via le port parallèle - je sais, les PC modernes n'on plus cette relique du IBM PC, mais ici on a pas encore reçu les nouveaux core i7 triple channel, on doit se contenter ne nos Lenovo un peu asfixiés par Eclipse :)

    Le port parallèle, programmé au plus bas niveau, a l'intérêt bien connu des bidouilleurs de se comporter comme un "octet exposé au reste du monde". Ses 8 pins sont contrôlables en 0V / 5V en fonction du byte inscrit sur ce port. Il est donc facile de piloter jusqu'à 8 lampes en y envoyant de 0 à 255.

    1er soucis
    Le "plus bas niveau" est un peu compliqué sous Windows ou le port parallèle est masqué par l'abstraction matérielle. Il existe cependant des drivers bidouille qui corrigent le tir, ainsi qu'un soft qui assure l'accès exclusif à ce port (sans quoi ça merde de temps en temps).
    - le soft qui va bien pour écrire byte par byte sur le port parallèle en Java
    - le soft qui va bien pour un accès exclusif sous windows

    Un premier "proof of concept" pour allumer une led rouge (en ce moment c'est la couleur dominante) et mettre au point le côté logiciel, basique mais fonctionnel. L'occasion aussi d'amuser la galerie et de préparer l'équipe pour la suite.


    Une fois cette formalité remplie et les premier regards amusés des collègues, on sort le fer à souder. Liste de courses :
    • un vieux cable d'imprimante "centronics" (comme quoi faut jamais rien jeter)
    • quelques composants électroniques (~20€)
    • trois ralonges (pour pouvoir placer les lampes à qq mètres de mon bureau),
    • une boîte tupperware pour mettre tout ça à l'abris - c'est tout de même du 220v, faut pas déconner.
    Le montage n'a rien de bien compliqué, mais comme mes cours d'électronique sont un peu loin je me suis reposé sur ce plan. Si vous comptez allimenter un transfo ou un moteur (typiquement un gyrophare 12v) faites gaffe, ce n'est pas exactement le même schéma.

    2ème soucis
    Ce premier essai est un bide : rien ne marche. J'ai d'abord cru avoir grillé les optocoupleurs (c'est tout de même du 220V, on hésite à venir y mettre ses doigts). En fait le montage que j'ai voulu utiliser suppose que la prise parallèle débite suffisement de jus ... ce qui était loin d'être le cas au cous de mes essais. Il faut donc ajouter un "étage" suiveur de tension - ressortez vos cours d'électronique sur les transistors ! Dans ma boîte à bricoles j'ai retrouvé tout plein de ces bidules à trois pattes, l'occasion de (re)découvrir à quoi ça sert.

    Après un test sur plaque d'essai (attention au 220V :-/) implantation sur circuit imprimé et mise en boîte.

    3ème soucis
    On branche et ... les plombs sautent. Après une bonne heure à tester chaque module sans trouver de problème, je décide de couper le circuit en deux sous les opto-coupleurs, de manière à avoir une isolation totale entre 220 et 9V - et ça marche. Comme quoi ma plaque d'essai ne devait pas être au top question isolation.

    Je vous passe les 4ème, 5ème et 6ème soucis (la LED qui s'allume pas, un fil de masse qui se déssoude ...)

    Pour les "signaux visuels" vous pouvez ressortir ces blocs-spots octogonaux en plastique qu'on a tous achetés un jour pour animer une boum - ça peut vous faire un joli feu de signalisation. Moi, j'ai fait une petite folie :
    • trois tubes néons de couleur bleu/jaune/rouge (19€ chez alinea)
    • un gyrophare rouge pour venir épauler le tube rouge (16€)

    et voilà le résultat en action :
    Le "Laser Saber Extreme Feedback Devive (TM)"

    Pas de photo ? Ben non, j'ai oublié mon appareil, revenez en fin de semaine ...

    Effet étonnant : le jour de l'installation, 12 builds bleus alors qu'on plafonnait péniblement à un ou deux par jours au meilleur de notre forme. Pourvu que ça dure !

    Autre option pour ce type de montage, utiliser un circuit programmable, comme par exemple celui-ci qui intègre sur quelques cm² un serveur HTTP avec sa prise ethernet. Mais là, ça devient presque de l'industrialisation. Le côté bricolage facilite le succès du bidule auprès de l'équipe ;)

    09 juin 2009

    Pour une meilleure utilisation d'Eclipse


    Qu'on aime ou qu'on déteste, Eclipse est omniprésent et on doit bien faire avec. Dans la phrase précédente, comprendre "bien faire avec" non pas comme un signe de renoncement mais dans le sens être aussi efficace que possible avec cet IDE. Je n'ai jamais eu le courage pour ma part de changer d'IDE au delà du test express, ayant perdu toutes mes habitudes dans un nouvel environnement. Idea ou Netbeans sont sans doute très bien mais je n'ai vraiment pas le temps de m'y habituer.

    Julien vient de me suggérer le plugin MouseFeed, qui suggére les raccourcis clavier pour chaque opération pratiquée à la souris dans l'IHM, souris bien pratique mais dont la lenteur relative est bien connue. Un excellent moyen pour apprendre les raccourcis (parfois même leur existence) sur les opérations qu'on pratique en boucle.

    Il ne manque plus que le petit trombone animé pour nous tenir la main ;)

    03 juin 2009

    Sun, Oracle, OpenJDK et Java payant ?

    Le rachat de SUN par Oracle a fait couler beaucoup d'encre et lève de nombreuses interrogations (voir inquiétudes). Dans ce contexte, on peut être rassuré que SUN ait passé le code du JDK sous licence GPL peu de temps avant ce changement de propriétaire.

    Exemple concret : le nouveau Garbage collector "G1", dont les performances sont encourageantes pour ce qui en a déjà été présenté (même si on présente rarement de mauvais résultats). Un petit tour par la release-note :
    "Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. G1 is supported thru Sun's Java Platform Standard Edition for Business program." 

    Vous avez bien lu, pour utiliser G1 en production vous devrez passer par le porte monaie et souscrire un contrat de support "business program".

    Donc SUN a d'un côté ouvert le JDK en GPL (ce qui lui permet à la fois d'être libre sans risquer de se le faire piquer) et de l'autre finance des développements plus avancés selon un contrat de support classique. Un modèle de développement opensource assez classique en fin de compte, la version "de base", libre, servant à faire adopter la plateforme tandis que la version "business" est orientée support et fonctionnalités avancées.

    D'autres éditeurs ayant choisis ce modèle redonnent leur code "avancé" à la version libre une fois que son développement a été amorti. Il semble que ce soit l'idée de SUN pour G1, dont le développement et la mise au point sur des applications stratégiques nécessite des ressources significatives. 

    Reste à savoir ce que cela va donner à l'avenir, avec bien sûr la question clé de la position d'Oracle sur le sujet, qui n'a pas montré jusqu'ici un engagement fort dans l'opensource. G1 sera t-il réellement "libéré" et intégré à OpenJDK ou faudra t-il attendre un développement alternatif qui s'en inspire ? Qu'en sera t-il des autres évolutions significatives du JDK de sun ?

    La polémique autour du rachat de SUN n'est pas prète de s'épuiser ;)

    02 juin 2009

    Maven bouge dans le bon sens

    Avec mon précédent billet je me suis attiré quelques foudres de la part de la communauté Maven, mais j'ai aussi mis sur le tapis un état de fait : en dehors des membres de Sonatype qui sont à plein temps sur Maven 3 il est bien difficile de suivre le développement de cette nouvelle version "de l'extérieur".

    Les choses évoluent dans le bon sens : Jason a reconnu que le développement de Maven 3 nécessite un gros investissement personnel ne serait-ce que pour se tenir au courant. Il ne compte pas renoncer à son rôle de développeur pour celui de responsable communication en fournissant à la communauté un joli résumé du 'où c'est qu'on en est', mais ne veut pas pour autant se couper de la base communautaire du projet.

    Dernier rebondissement, l'organisation de conférences téléphoniques hebdomadaires permettant de discuter "live" de l'état et de l'avenir du projet, une idée reprise du fonctionnement de la fondation Eclipse. Enregistrées pour ceux qui ne sont pas disponibles à l'heure dite (17h pour la france), ou dont l'anglais est trop approximatif pour suivre une discussion sans décrocher, ces débats seront consultables dans les jours qui suivent et pourront être poursuivis par des questions plus précises via la liste de dev.

    Ce fonctionnement devrait permettre à plus de monde de mettre un pied dans Maven 3, sans pour autant alourdir le processus de développement. Documenter chaque choix technique mis en oeuvre serait en effet un travail titanesque.

    Bonne nouvelle donc. Après la renaissance de Maven 2.x (une 2.2 est en cours de finalisation), Maven 3 va devenir plus visible pour la communauté. Les devs de Maven 3 se focalisent sur la compatibilité avec l'existant maven 2, via une large batterie de tests d'intégration. Un travail important auquel la communauté peut contribuer en proposant de nouveaux tests IT sur des cas spécifiques. Les résultats sont semble t-il encourageants, aussi on peut espérer avec un Maven3-SNAPSHOT fonctionnel, même si la stabilisation définitive va prendre du temps.

    En parallèle, des membres francophones de la communauté se sont portés volontaires pour traduire le definitive guide en français, travail à long terme vu le pavé que constitue ce bouquin, mais qui va apporter à Maven une documentation plus accessible - en complément, bien sûr, de mon bouquin ;)

    01 juin 2009

    container's hell

    JEE n'a pas vraiment la cote auprès des développeurs qui lui préfèrent des modèles plus léger. Dernière expérience en date pour ma part : j'ai une application Hibernate, j'y ai mis la toute dernière version GA du framework, et je la "déploie"sur un JBoss un peu ancien - prérequis client oblige.

    NoSuchMethodError

    Hibernate tente de détecter la présence de Hibernate-validator, et si c'est le cas active ses fonctions optionnelles. JBoss a eu la bonne idée de nous coller d'office un Hibernate dans son serveur d'appli, comme si nous n'étions pas capable de choisir nous même nos outils. Le Hibernate-validator détécté au runtime est celui de JBoss et évidement incompatible avec la version d'Hibernate que j'utilise.

    Autrement dit, le "conteneur" me rend là un magnifique service en m'obligeant à intégrer une version plus récente d'Hibernate-validator que je n'utilise pas. Je vous passe les problèmes de parser et d'API XML et les diverses Error associées. Même si après tout c'est ce qui me fait gagner ma croute vu que peu de gens comprennent de quoi il s'agit, je me passerais bien de perdre des heures sur ce genre de sotises.

    Question 1 : pourquoi le serveur d'appli devrait-il nous fournir des frameworks, nous privant ainsi du choix d'une version précise ? Il est difficile de faire une mise à jour de serveur sur des machines mutualisées, je me suis coltiné un Websphère 5.0 pendant des années pour cette raison. 

    Question 2 : Pourquoi le classloader isolé (parent-last) n'est-il pas le mode de fonctionnement par défaut ? Tous ceux qui ont galérés avec commons-logging savent de quoi je parle

    Question plus fine : pourquoi le serveur d'appli héberge t-il l'application et pas l'inverse ?

    Dans la majorité de mes applis, en dehors de l'API servelt et d'une DataSource le serveur d'appli ne sert pas à grand chose (je suppose que ces fonctions d'exploitation sont mise à profit par mon client). Pour la DataSource, un bon commons-dbcp fait très bien l'affaire et économise les raffinements de la configuration des liens JNDI. Pour l'API servelt, je préférerais autant démarer au sein de mon application un service d'écoute HTTP, un Jetty embedded ou équivalent, quitte à ce que la classe associée soit configurable.

    Spring DM Server de ce point de vue me décoit un peu car il ne remet pas en cause cette structuration des applications dans un conteneur (et je reste perplexe sur l'intérêt d'OSGi). J'attendrais du serveur d'application idéal de fournir des services à la carte, mais surtout rien de plus. En gros une JVM++, pas une de ces usines à gaz auxquelles JEE nous a habitués.

    29 mai 2009

    Google surfe sur la Wave



    Pour ceux qui ont suivi l'émergence de HTML5, les navigateurs modernes vont permettre de développer des applications nettement plus riches, basées sur un canevas graphique complet et un modèle de communication complètement débridé (très loin de deux connexions HTTP que l'on a héritées de Mosaïc).
    Google suit (anticipe ?) le mouvement en présentant Google Wave, qui se présente comme "ce que seraient le mail et la messagerie instantanée si on les avait inventés aujourd'hui". Ça parait flou ? Explication, basée sur la démo présentée au Google IO :

    On part de ce qui ressemble pas mal à gMail, avec liste de contacts et boite de réception. Sauf que pour chaque personne impliquée dans une discussion, Wave signale de nouveaux événements ou contenu (pas juste de nouveaux messages). A l'intérieur d'une discussion on retrouve donc les outils de messagerie instantanée, de partage de profil et autres services "sociaux" devenus communs sur le web. Plutôt que de répondre à un message, on vient en compléter le contenu avec un complément apporté directement à l'original - on est alors à la limite de Google Docs.

    Wave est donc en quelque sorte une fusion de tout ce qu'on trouve de collaboratif sur le web. Sur la base d'un sujet, on va inviter de nouveaux participants qui vont enrichir le contenu, ouvrir des discutions (globales ou privées), communiquer on- ou off-line et construire ensemble quelque chose de riche via un environnement unifié.

    Subtilité indispensable, la possibilité de "rejouer" l'évolution de ce contenu dans le temps pour retrouver son état à un instant t, bien plus efficace que de remonter l'historique de ses mails !

    Réservé à l'échange de document ? Que nenni, la démo présente une partie d'échec, l'échiquier étant le "contenu" partagé sur la Wave ! Autre exemple, une invitation à un barbecue ou chacun donne sa disponibilité. Les utilisations concrètes restent à inventer.

    Tout ça ... dans n'importe quel navigateur digne de ce nom (donc n'importe lequel sorti en 2009 à l'exception d'IE qui reste comme toujours l'indécrottable poubelle du web). Pas de plugin, pas de siouxerie, et rapidement on met le navigateur en plein écran pour ne plus en sortir.

    Le protocole utilisé par Google Wave est ouvert (http://www.waveprotocol.org/) et les données peuvent ainsi être hébergées sur vos propres serveurs -détail qui freine sensiblement le développement du cloud-computing !

    [mon voyant me prédit l'avenir:ON]
    Une idée comme ça pour tout ceux qui ont pesté sur les lenteurs d'Eclipse : imaginez une appli utilisant Wave comme éditeur de code, avec le "cloud" comme compilateur en tâche de fond ! J'écris du code, je convie Michel et Julien pour une relecture, je fais du Pair-programming en télétravail, je reviens à la version d'hier matin ... Une sorte de TeamCity poussé jusqu'au PC. Le poste de développement reste la seule (bonne ?) raison de conserver un PC surpuissant. A quand l'environnement de dev distribué ?
    [mon voyant me prédit l'avenir:OFF]

    A noter dans la même lignée la version Cloud de gOS (le "g" signifiant "good", et pas "google" comme on est très tenté de le penser) qui veut construire un OS ultra allégé (comprendre : net-PC) qui ouvre seulement un navigateur en plein écran contenant toute l'IHM en mode web - "browser operating system".
    Quand on vous dit que la révolution du web est en marche...

    28 mai 2009

    Continuum vs Bamboo vs Hudson

    Petit retour d'expérience sur les serveurs d'intégration continue.

    J'utilise beaucoup Hudson, qui a le vent en poupe. Interface ultra-conviviale, nombreux plugin et communauté très active. Les builds Maven2 sont découpés en modules automatiquement détectés, ce qui permet de consulter l'état d'un module en particulier. Par contre, le build reste monolithique, c'est à dire qu'Hudson fait un build complet même si un seul module est impacté.

    Bamboo est le seul non-opensource de mon test. J'en avais entendu beaucoup de bien, je reviens plutôt déçu. L'interface est très correcte mais l'intégration de Maven est minimale : aucune gestion des modules, ni au build, ni à l'affichage. Par ailleurs, j'ai eu un peu de mal à m'y retrouver dans les onglets, mais c'est sans doute une question d'habitude.

    Continuum est le plus moche des trois. L'IHM est vraiment old school et mériterait une belle refonte à grand coup d'Ajax et de styles graphiques plus modernes. Par contre, le support de Maven est sans compromis : chaque module d'un multi-projet est identifié comme tel et géré comme tel. Si une modification impacte un sous-module, celui-ci (et seulement celui-ci) est construit, puis Continuum enchaîne les modules ou autres projets qui en dépendent - ce qu'on attend d'une gestion des dépendances Maven !

    Ma conclusion : Hudson est un bon environnement, surtout pour commencer avec l'intégration continue car il est très intuitif. Bamboo n'apporte pas de plus value fondamentale et son support Maven est décevant. Continuum est probablement le meilleur serveur d'intégration continue pour un projet Maven, mais également le moins esthétique et le plus complexe des trois à configurer. Le jour où il sort avec une IHM revisitée et une configuration en trois clics, il risque de déchirer -mais ce n'est qu'une conjecture, encore faut-il trouver les développeurs pour faire le boulot :)


    26 mai 2009

    Maven, Eclipse et GWT main dans la main


    Avec la sortie du Plugin Google Eclipse, il me restait à intégrer proprement le couple Maven + GWT avec l'IDE le plus connu des développeurs java - je n'ai pas dit le meilleur ;p

    C'est désormais chose faite avec le dernier SNAPSHOT du plugin GWT, qui devrait clore une longue liste avant une release que j'espère proche, le temps de fixer les derniers bugs et erreurs de documentations.

    Comme je l'explique sur cette page, la principale difficulté est que le plugin Google Eclipse n'est pas très "maven compliant" et oblige à faire quelques concessions. Cependant, avec l'aide de m2eclipse (ça doit aussi marcher avec IAM, je n'ai pas encore testé) on obtient le résultat suivant, que vous pouvez expérimenter à la maison en utilisant le projet de test it/reactor du plugin, ou sur votre propre projet (dites moi ce que ça donne) :
    • import du projet Maven sous Eclipse par m2eclipse. Les dépendances, répertoires de sources et de génération de code sont identifiées et configurés sous Eclipse, et surtout lesmodules d'un multi-projet et dépendances présentes dans le workspace sont "résolues" en tant que références inter-projet et non via les jars du repository local.
    • ajout du support GWT (étape encore manuelle, j'y travaille) via Google Eclipse Plugin. Soucis ici, le plugin ajoute lui même les dépendances GWT qui font donc doublon avec celles gérées par m2eclipse. Ca n'a pas l'air gênant à condition bien sûr que les versions soient cohérentes. Si quelqu'un à une astuce je prend ;)
    • génération des lanceurs pour les modules de l'application en lançant mvn gwt:eclipse. Cette tâche gère désormais aussi bien les lanceurs "classiques" et ceux exploitant le plugin Google Eclipse (cas par défaut). Au passage, le plugin prépare le répertoire /war du mode hosté.
    • un simple run as > web application sur le lanceur généré et le mode hosté démarre. L'URL de la page web hôte n'étant pas déclarée dans le fichier module, j'ai pris comme convention qu'elle porte le même nom que le module et est présente dans son répertoire public. C'est un peu limitatif mais ça doit être assez courant. Sinon il suffit d'éditer la configuration d'exécution.
    Le gros progrès (en terme de confort et de productivité) c'est que si votre application est découpée en modules maven, une modification dans le code source d'un de ces modules sera directement exploitable dans le navigateur hosté par un simple refresh. Pas besoin de repackager un Jar ou tout autre manipulation - perte de temps.

    Pour aller au delà du serveur hosté et passer sur un "vrai" serveur d'appli (-noserver) il faut jongler un peu entre le plugin maven-war et les chemins "en dur" choisis par Google, mais on s'en sort.

    On a donc enfin une solution productive pour faire du GWT sous Eclipse sans s'empêtrer dans des builds Maven sans fin. Reste à vérifier que tout ça reste bien compatible avec le fonctionnement "hors eclipse" du plugin : La tâche gwt:run a encore ses fans (à moins que ce soit juste du anti-Eclipse ?)

    Je n'ai pas testé le support de GWT sous IDea ou NetBeans, mais si un fonctionnement équivalent est possible je serais ravi de l'intégrer au plugin - les patchs sont bienvenus :)

    18 mai 2009

    m2eclipse vs IAM ? Non m2eclipse + IAM

    Lorsque la fondation Eclipse a annoncé accepter deux plugins concurrents et assez semblables dans son incubateur on pouvait se poser la question : qui va survivre à la course à l'investiture ?
    On aurait pu penser que Eclispe serve de "sélection" pour un unique plugin et encourage le perdant à coopérer, mais il n'en est rien. La fondation a d'ailleurs joué le même tour à Sublcipse / Subversive.

    Nous avons donc d'un côté IAM qui fait un gros boulot (peu visible) pour bien rentrer dans les règles de l'incubateur et m2eclipse qui continue son développement et enchaine les pré-versions. Les discutions qu'on a pu suivre entre les deux groupes ne laissaient pas vraiment présumer d'une fusion. Après une gueguerre "c'est pas moi m'sieur,  c'est lui qu'a commencé", on nous a expliqué en quoi les deux plugins sont fondamentallement différents et donc ne peuvent céder un pouce de terrain.

    Et voila que l'impensable se produit : Michael Poindexter (q4e) travaille actuellement sur la fusion des éditeurs de fichier POM proposé par chaque plugins. Il vient même d'obtenir le sésame utlime : le droit en écriture sur le code de m2eclipse - ce qui doit être nettement plus simple pour faire la fusion :). 

    On assiste donc à un assainissement de la concurrence entre les plugins, qui sont encore loin de n'en faire qu'un (il reste de lourdes incompatibilités) mais commencent à réfléchir ensemble.

    Un peu d'optimisme fait du bien :D

    15 mai 2009

    m2eclipse vs IAM (q4e)

    Après avoir publiquement rennoncé à Archiva pour Nexus on pourrait me croire vendu à Sonatype ... et bien non. Utilisateur de m2eclipse je teste actuellement la dernière mouture de eclipse-iam (aka "q4e") et je le trouve bluffant !
    • le build maven est nettement mieux intégré. 
    Contrairement à m2eclipse, IAM utilise maven 3 exclusivement, ce qui peut paraître gênant à priori mais lui donne la liberté d'une vraie intégration dans Eclipse et sa gestion événementielle. La progression d'un build indique ainsi le démarrage des Mojos et les tâches accomplies.
    • moins de builds inutiles
    L'éditeur de POM est assez intelligent pour ne pas lancer un build "pour rien" lorsque l'édition réalisée n'a aucun impact. Je râle assez souvent sur m2eclipse qui me fait des builds en série pour pas grand chose, et je finis souvent par désactiver le "build automatically".

    Si je trouve le "visuel" de m2eclipse plus sympa, voilà deux bonnes raison qui vont me pousser à changer mes habitudes

    14 mai 2009

    La fin d'une époque

    L'époque ou le monde opensource était associé à des universitaires barbus en tongues (et chaussettes, c'est plus confortable) semble loin derrière nous.

    Nous sommes quelques un à bien devoir admettre que notre projet à nous, développé en mode "temps libre" a bien du mal à tenir la route face à la concurrence. Archiva est bien joli mais est à la ramasse comparé à Nexus, et la liste de tâche pour le "moderniser" est tellement longue, que je vois mal qui pourrait s'y attaquer. Continuum est tout à fait fonctionnel, mais son ergonomie laisse à désirer comparé à Hudson ou Bamboo, sans parler de la richesse du premier en terme de plugins.

    D'où un constat simple : depuis que le modèle opensource n'est plus considéré comme opposé au business, de nombreuses boîtes peuvent mettre du monde à plein temps sur un projet ET en tirer du bénéfice (support, consulting, formation, version "pro", etc).

    Comment l'équipe d'Archiva pourrait-elle rattraper Nexus, qui bénéficie de l'équipe Sonatype à plein temps ? Comment Continuum peut-il rivaliser en terme de ressources avec un outil commercial comme Bamboo ou un Hudson dont le créateur à été affecté à plein temps par SUN ?

    L'opensource du XXIéme sciècle est définitivement professionnel.

    Archiva vs Nexus

    En écho au blog d'Arnaud, j'ai moi aussi envisagé la migration d'Archiva vers Nexus.

    Pour résumer, Archiva à rencontré avec la sortie de maven 2.1 un bug bloquant (une sombre histoire de metadata.xml qui se perdent en route). D'où obligation de migrer, serveur qui ne démarre plus, réinstallation de la base, bugs divers à répétition [ NullPointers :'( ]...

    Ca ne donne pas une super image de l'état de stabilité d'Archiva. A l'usage, je n'ai pas rencontré de problème particulier et je n'ai pas non plus instrumenté mon serveur comme l'a fait Arnaud pour évaluer la consommation des ressources. Il est possible que certains de mes soucis soient liés à la consommation excessive qu'en fait Archiva.

    Bref, déploiement du WAR Nexus et configuration en quelques minutes (l'IHM d'admin est tout de même nettement plus sympa, même si on y passe pas des heures). Mes premiers tests montrent que Nexus est "au moins aussi bien" qu'Archiva. Certains problèmes de timeout ont même été éliminés. 

    Dans un premier temps je vais conserver les deux "repo-managers" en parallèle, et laisser l'instance Archiva mourrir tranquilement de sa belle mort (on a encore pas mal de projets Maven1 qui se basent dessus !)