new Blog( perso );

Après des années à trainer sur la mailing list de Maven, j'ai été invité dans la communauté Mojo qui héberge une large panoplie de plugins Maven "non stratégiques" - comprendre non supportés par le projet Maven lui-même. J'y ai lancé les javascript-maven-tools (à l'état dormant depuis) et repris le flambeau sur le plugin GWT. Ce projet, relativement ouvert aux nouveaux contributeurs, fonctionne sur ce modèle : proposer, supporter, passer la main. Un plugin n'y vit que si des développeurs sont là pour le soutenir, développeurs qui sont souvent ses premiers utilisateurs.

Je suis ensuite passé dans le code d'Archiva pour des besoins internes. Ayant du temps plus ou moins officiellement dégagé sur cette tâche j'ai pu m'investir et faire des évolutions intéressantes, créer des liens forts avec les développeurs, qui m'on finalement invités à rejoindre le projet Maven - à l'époque non différenciée d'Archiva. Nous sommes fin 2007.

Depuis cette date, j'ai continué à oeuvrer sur le plugin Mojo GWT et j'ai quelquefois apporté ma pierre à l'édifice Maven, via quelques contributions mineures (release:stage, c'est moi). Mes tentatives pour rentrer dans le "core" se sont soldées par un échec : soit j'ai clairement fait des boulettes et j'ai été vite renvoyé dans les cordes [svn rollback], soit mes propositions sont restées sur le pavé. En 30 mois je n'ai donc rien committé de concret dans le svn Maven.

Par contre, j'ai activement participé à la com' sur Maven, à travers les JUGs et ce fameux bouquin dans lequel j'ai réussi à embarquer Arnaud. Tout ça c'est du temps libre, ça ne rapporte rien en dehors de l'estime de la communauté - ce qui est déjà beaucoup.

Mon activité pro ne consiste pas à développer Maven, déjà que contribuer à corriger des bugs ou à améliorer quelques plugins ne soit pas une tâche tout à fait officielle. Mon temps libre est déjà largement amputé par l'organisation du BreizhJug. Je n'ai plus le temps pour élaborer des idées, développer un POC et le faire challenger par ceux qui passent leurs journées sur le projet. Même si cela parait nécessaire le coût est trop important pour un simple contributeur comme moi.

J'ai donc fait le choix symbolique de me retirer de la liste des développeurs Maven. Cela ne me retire pas le droit de commit, rassurez-vous, je pourrais donc encore venir appliquer quelques patchs intéressants pour corriger un bug que je rencontre dans mon boulot de tous les jours. Par contre je ne compte plus m'impliquer dans le développement de Maven.

Hudson utilise un modèle assez étrange au premier abord : pour devenir committer, il suffit de montrer patte blanche. "Bonjour, j'ai écrit un patch pour l'ano ###" (et/ou) "J'ai écrit un plugin rigolo boite-à-meuh-hudson-plugin". La réponse ne tarde pas : "Quel est ton ID java.net, comme ça tu pourras le committer toi même". Hudson fonctionne sur la confiance : ceux qui participent sont déjà une toute petite sous-catégorie de gens motivés, il ne faut surtout pas les freiner. Un plugin hudson ne vit que parce qu'un ou deux développeurs le supportent, et le projet a besoin de sang neuf pour vivre et s'épanouir.
C'est vrai que lorsqu'on regarde sous SVN, Hudson paraît particulièrement bordélique. C'est un effet de bord totalement assumé ! Obliger les développeurs à suivre des conventions trop rigides c'est créer une barrière aux contributeurs. Si un plugin est proposé, même dans un état discutable, mais avec de la motivation et du temps pour s'en occuper, alors feu vert. S'il devient vraiment utile et attire d'autres développeurs il sera toujours temps pour le "nettoyer". Jusqu'ici, le projet n'a pas eu à souffrir de ce qui ressemble a priori à un manque de rigueur. Les versions se succèdent à un bon rythme, avec des corrections rapides et de nouvelles idées.

Deux approches opposées,

• le modèle Apache Maven : les règles et les consensus à la Apache, et un pilotage "business-driven", 
• le modèle Hudson : "open-bar" ouvert à toutes les bonnes volontés. 

Les deux outils ont fait leurs preuves et sont devenus l'un comme l'autre des incontournables, avec un excellent niveau de stabilité. Comme quoi tout n'est pas gravé dans le marbre

Nicolas Romanetti m'a fait l'autre jour une remarque sur un manque dans mon livre Apache Maven concernant le chapitre sur JavaEE : Dans le modèle JavaEE (pré-6), on met les classes et les ressources dans un WAR, lui même dans un EAR, et on balance tout ça sur le serveur. Où placer la configuration de l'application ?

Si on lit la spec JavaEE, elle prévoit un rôle d'assembleur d'application, qui va prendre l'EAR, éditer ses fichiers de déploiement XML pour faire le lien entre les ressources de son serveur (DataSource, files JMS, ...) et l'application. Personnellement je n'ai jamais rencontré ce cas de figure, et mes clients attendent plutôt une application prête à fonctionner avec au plus un fichier de configuration properties externe à l'EAR.

Option 1 : embarquer la conf en fonction de l'environnement cible

Si on veut suivre l'esprit JavaEE on peut utiliser des profils Maven pour packager dans le WAR les ressources associées à l'environnement cible :

<profile>
      <id>dev</id>
      <build>
        <resources>
          <resource>
            <directory>${basedir}/src/env/dev</directory>
          </resource>
        </resources>
      </build>
    </profile>
    <profile>
      <id>prod</id>
      <build>
        <resources>
          <resource>
            <directory>${basedir}/src/env/prod</directory>
          </resource>
        </resources>
      </build>
    </profile>

il suffit donc d'ajouter un petit "-Pprod" pour générer l'application dans sa configuration de production. Par contre, la configuration ne peut pas être éditée simplement une fois l'application installée.

Option 2 : passer par le JNDI

L'autre option respectant l'esprit JavaEE est de se baser sur les ressources JNDI, et donc d'accéder à une donnée d'environnement de type URL ou String qui pointe vers notre fichier de properties. Dans le web.xml j'ajoute donc un petit :

<env-entry>
      <description>Chemin de la configuration locale</description>
      <env-entry-name>appli.home</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>/valeur/par/defaut</env-entry-value>
    </env-entry>

Je n'ai plus qu'à définir cette ressource dans le JNDI de mon serveur d'application, ce qui va par contre être spécifique à chaque serveur - Tomcat par exemple ne permet pas de définir une ressource URL, alors que Websphère le supporte (pas classique de dire du bien de celui-là, n'est ce pas ?).

Pour y accéder, il faut faire un lookup JNIDI ce qui n'est pas léger léger, et si on veut passer par Spring et ses PlaceHolder ${truc} on regardera du côté de SPR-3030.

Option 3 : passer par une propriété système

Dernière option, la version "light" : dans de nombreux cas, je constat que le serveur d'application n'héberge qu'une seule instance de l'application, aussi on peut positionner des variables systèmes au niveau de la JVM pour lui passer un paramètre, typiquement notre appli.home. Et là, rien de spécial à faire pour activer le configuration Spring en dehors d'activer le SYSTEM_PROPERTIES_MODE_OVERRIDE.
Dans le même esprit, on peut externaliser la configuration log4j en ajoutant un -Dlog4j.configuration=file:///monlog4j.xml.

Perso je préfère cette dernière variante, la plus légère à mettre en oeuvre et la plus simple à expliquer aux développeurs. JNDI reste un truc assez mystérieux, qui plus est avec des variations pour sa configuration en fonction des serveurs d'application. L'accès au DirContext se fait trop souvent via un mauvais copier-coller qui référence les classes du serveur d'application (alors que justement le but est de s'en découpler !) et/ou en ajoutant au petit bonheur la chance des java:comp/env ... peut être le sujet d'un autre billet :)

Option 4: compléter le classpath du serveur

Suite au commentaire de Sylvain François, une 4ème option, comparable au system properties : ajouter au Classpath de l'application le chemin d'un répertoire contenant les fichiers de conf. En jouant sur l'ordre de chargement du ClassPath on peut ainsi surchager les fichiers de conf "par défaut" présents dans le WAR/EAR.

Ces deux dernière options sont assez comparables et leur mise en ouvre va dépendre de la liberté qu'on a pour configurer le serveur d'application. Certaines équipes d'exploit' donnent la main sur la commande de lancement de la JVM, d'autres préfèrent la blinder mais laissent libre accès aux répertoires de libs ...

Qu'en pensez vous ? Donnez votre avis : http://doodle.com/d4qdxc87w76i524c

Lors du dernier ParisJug, toute l'équipe du JUG Rennais à fait le déplacement, prétextant l'organisation de son Assemblée Générale. Occasion bien choisie, vu que nous revenons après une conf d'exception de Mme "Docteur" Holly Cummins, première speakeuse invitée au ParisJug, avec en bonus clé USB et casquette offertes par IBM - on a pas gagné l'iPad, faut pas rêver non plus.

Seul bémol de la soirée, arrosée avec abondance de champagne par la générosité d'octo pour un buffet démesuré, qui a eu ses effets pervers : les bouteilles circulant dans la salle lors de la seconde conférence, l'ambiance s'est vite échauffée pour devenir un peu débordante - votre serviteur ne montrant pas le meilleur exemple.

Il en résulte un état à la sortie de la session qui ressemblait plus à une fin de 3ème mi-temps qu'à une fin de conférence, avec les effets très négatifs que cela pourrait  avoir sur les relations du ParisJug avec l'école qui les accueille gracieusement, avec les sponsors qui payent le déplacement d'un speaker depuis Londres, et bien sûr avec l'invitée d'honneur du jour qui n'avait sans doute pas prévue de présenter OGSi devant une bande de pochtrons.

Je présente mes excuses pour mon attitude excessive auprès de tout ceux que cela a pu choquer, blesser, ou simplement déranger. J'ai promis à Antonio de faire le prochain JUG au diabolo-menthe (en tout cas, avant la 3ème mi-temps). Je présente aussi mes excuses aux sponsors qui s'impliquent pour faire des JUGs des rendez-vous d'exception. Je réserve enfin mes plus plates excuses à Holly Cummins, qui avait sans doute déjà entendu parler du "French Touch" mais n'avait sans doute pas mesuré l'ampleur de la chose.


Bizarrement, je n'arrive plus à me connecter au site du ParisJug, j'ai systématiquement une

406 Not Acceptable

Lors de la conf "Maven3" au ParisJug avec Arnaud Héritier, nous avons indiqué que le remplacement du coeur de Maven (Plexus) par Google Guice était repoussé à une version 3.1 de Maven. Les choses semblent cependant s'accélerer.

Pour les besoins de Nexus, Sonatype a développé une couche d'abstraction "Spice" qui permet d'utiliser la syntaxe Plexus avec un conteneur autre, typiquement Google Guice qui est le nouveau moteur de Nexus. Cette expérience réussie donne une sérieuse crédibilité à cette option de migration en douceur.

La même approche a été testée par Sonatype pour Maven3, et Olivier Lamy a importé ces modifications dans une branche du SVN Apache. Ce code passe déjà les tests IT de Maven, même s'il reste quelques incompatibilités liées à de mauvaises pratiques dans certains plugins (modification des composants internes de Maven) que ce nouveau moteur n'autorise plus. Ces signaux plutôt positifs pourraient aider à faire passer Guice comme moteur de Maven dès la version 3.0, ce qui aurait de nombreux effets bénéfiques :

Pour les utilisateurs ou développeurs de plugin, ce changement n'apporte rien de visible, sinon des logs plus clairs quand la configuration est incorrecte - ce qui, avec Plexus, donne parfois le signal de départ pour de longues heures d'analyse. A plus long terme, l'utilisation de Guice permet d'envisager une migration plus profonde des "bons usages" de développement de plugins Maven vers les annotations @Inject (JSR330). Ceci supposera cependant que les plugins qui suivent cette voie soient dédiés Maven3, ce qui promet de longues discutions sur la liste de dev :)

Pour ceux qui veulent embarquer Maven3 dans un autre outil par contre, ce changement est significatif. La configuration de Guice dans ce mode est nettement plus simple. L'intégration de Maven 3 sur Hudson nécessite ce genre d'acrobatie, et Guice sera le bienvenu pour ne pas inutilement compliquer la tâche.

Maven 3 est donc bien en mouvement, mais avec sa très large base d'utilisateurs il ne peut pas se permettre de changements brutaux sans fournir de harnais de sécurité. C'est ce qui le différencie de quelques concurrents comme Gradle, qui apportent de nouvelles idées, mais ont surtout la liberté de tout casser s'ils ont pris une mauvaise orientation.

Lors du premier anniversaire du ParisJug, j'avais annoncé qu'un de mes objectifs pour cette année serait d'organiser Devoxx à Rennes.

En dehors de la boutade adressée à Stephan Jansen présent exceptionnellement ce soir là, j'ai l'impression que l'idée n'est pas tombé dans l'oreille d'un sourd : Le PoitouCharentesJug organise le vendredi 10 septembre le JugSummerCamp !


Lors de cette journée (éligible au DIF, si votre employeur ne voit pas son intérêt de vous y envoyer d'office) ce sont les top-speakers francophone qui vont enchaîner des sessions. La crème de la crème du super poid lourd :

• Emmanuel Bernard
• Julien Dubois
• Alexis Moussine-Pouchkine
• Christophe Jollivet
• Damien Gouyette "c'est pas dur"
• Jérôme Benois

sans oublier (le meilleur pour la fin, en toute modestie)

• Nicolas De loof

Tout ça gratuitement, dans un cadre particulièrement agréable : la rochelle ! Voilà qui promet une pause repas à la plage et une belle after beach-volley (speakers vs groopies ?)

Pour résumer : une journée au top, en français, pas loin, imputable en formation, gratuite, et avec un peu de bol on aura du soleil en plus. Alors qu'est ce que vous attendez pour vous inscrire ?

Vous en avez une belle console comme ça vous ? Si avec ça on est pas submergé de propositions par les speakers de la terre entière, je ne sais plus ce qu'il faut faire ;)

En rachetant SUN, Oracle a par la même occasion hérité de pas mal de choses dont il ne sait que faire. Entre autre, la très large communauté des Java User Groups.
SUN a toujours été très fair-play avec ses User-Group. Pas de contrainte significative pour être accepté comme JUG (on pouvait même éventuellement créer plusieurs JUG pour la même ville!), et le soutien complet de SUN - y compris matériel avec un joli kit de lancement de JUG - sans aucune exigence de leur part.

Oracle, de son côté, à déjà des Oracle User Group, mais en dehors des deux dernières lettre de l'acronyme la comparaison s'arrête là. Les OUG sont des "Product" User Group, où sont présentés les produits Oracle avec la bénédiction, le soutien matériel, mais aussi l'avis parfois un peu intrusif de l'éditeur. De l'aveu même du responsable d'Oracle qui se récupère le bébé, il n'ont pas l'expérience des "Technology" User Groups - c'est déjà bien de savoir faire la différence.

Après une période de flou, Oracle nous propose maintenant son modèle : trois catégories de groupes,

1. les gros gros, plus de 1000 membres et un statut juridique : un soutien en force d'Oracle
2. les moyens, moins de membres et pas forcément de statut : soutien d'Oracle
3. les petits : on vous aime bien

En dehors des quelques JUGs dont l'adhésion est payante, tous les autres n'ont pas une notion de "membre" qui permet de trouver sa place dans ce modèle. Par ailleurs, les JUG français sont souvent des associations loi 1901 alors que de gros JUG peuvent ne pas avoir de statut juridique explicite. Le ParisJug par exemple peut compter 3 membres légaux, 200 "visiteurs" par session, et 2000 adresses enregistrées. Alors, catégorie 1, 2 ou  3 ?

Ensuite, Oracle demande que les JUG ne s'affilient pas entre eux, et tendent à se regrouper par secteur géographique. Hors, depuis un an, on constate l'inverse : des umbrella-JUG se sont formés pour aider le développement de plus petits JUGs locaux (JUG-USA, JUG-AFRICA, JUG-ASIA, JUR.RU ...) en fournissant un cadre juridique et organisationnel.  L'idée pour Oracle semble d'avoir un minimum d'interlocuteurs (pour dispenser la bonne parole ?), et de faire entrer les JUG-Leaders sélectionnés dans un Nième niveau hiérarchique, le Oracle User Group Community. La liste des JUG-Leaders hébergée par java.net suffisait à SUN pour cela, quel intérêt pour nous ? pour eux ?

Enfin, et c'est ce qui passe le plus mal, Oracle veut nous faire rentrer dans un moule - peut être pour doser ses contributions en fonction de la taille du moule ? L'intérêt des JUG est pourtant leur liberté et leur diversité. Certains prennent en charge l'organisation d'événements majeurs (Devoxx), d'autres se contentent de faire vivre une communauté locale entre potes sans se prendre la tête. Est-ce qu'on s'apprête à tuer les "petits" ?

Quoi qu'il en soit, les JUG continueront d'exister avec ou sans le soutien d'Oracle, mais voilà bien des remous qui n'étaient pas du tout nécessaires.

Aaron, revient !

Au cours de ses deux années d'activité, le BreizhJug s'est équipé en matos audio-vidéo, en particulier suite à de nombreux déboires avec les salles "tout équipées" qu'on nous prête : micro HS, piles essoufflées, ...

Je profite donc de ce beau grand week-end - pendant lequel je suis bloqué à la maison pour garder les enfants pour cause de concours hippique - pour mettre un peu d'ordre dans tout ça avec un flight-case : tout le matos bien à l'abri et pré-branché pour fonctionner out-of-the-box. Moins de prise de tête à chaque session du Jug et de risque d'oublier un truc (mais où j'ai mis ce %#@! de câble USB ?).

Un petit détour par Leroy-Merlin et SonoWest et c'est parti !

Step 1 : Assemblage du socle du flight-case dans les règles de l'art pour contenir le matos

(les cales sur la photo serviront à fixer le récepteur du micro sans-fil qui est au format rack 19")



Step 2 : Ajustage du couvercle pour une fermeture fiable et solide
Le couvercle ferme la caisse en plaquant les éléments via des blocs de mousse, paré pour les risques du transport. Les fermetures "papillon" assure une fermeture à toute épreuve. Les poignées sont dés modèles de cuisine, plus pratique que les modèles "Flight" standard (j'ai de mauvais souvenir de mon époque Sono-Supélec avec la régie de 30kg...)

Dire que j'ai failli acheter une boite de 50 rivets en pensant que ça suffirait... 108 rivets de posés !
(et il en manque ...)

Step 3 : Aménagement pour l'installation à poste fixe du matos


de droite à gauche :

• récepteur 4 micros HF 
• console de mixage 6 voies
• boitier de capture VGA
• (manque) switch VGA deux caneaux (pour basculer d'un speaker à l'autre sans débrancher le câble et donc interrompre la capture)

Au fond à gauche la zone "alims", loin du micro HF et des câbles audio (-> "bzzzz").
A l'arrière la zone "stockage" pour les accessoires mobiles (micros main et serre-tête).

La disposition est bien, reste à faire une cloison de séparation AV/AR, de belles découpes dans une mousse "qui va bien" pour les accessoires, trouver une astuce de rangement pour les câbles, et fixer le tout.

Step 4 : Soigner les finitions (TODO)

• pose d'une couche de moquette en fond comme amortisseur + esthétique plus "finie", 
• colliers plastique pour bloquer les cables en position, 
• casiers en mousse découpée "pile poil" pour le stockage des objets mobiles. NB : la mousse pour flight case est hors de prix, on va essayer de trouver un équivalent pas trop cher.
• 
  
  
  coinceurs pour les câbles afin qu'ils ne s'emmêlent pas pendant le transport : de bonnes vielles pinces à linge !

Step 5 : Tester en "live"

Rendez-vous le 7 juin pour la soirée Terracotta ! Et comme bon développeur, je laisse le soin à Julien de béta-tester ;)

Quand on manipule des services web, des schémas XSD et des louches entières de XML, on rencontre des développeurs qui sont complètement perdus dans les concepts de namespaces. Une idée trop largement répandue est que le namespace donne l'emplacement du schéma considéré, idée basée sur l'utilisation courante d'URL pour définir ces namespaces, lesquelles pointent effectivement assez souvent sur le schéma considéré.

Petit rappel donc.

En XML, les namespaces permettent de mixer plusieurs grammaires dans un même document, on associe donc un identifie chaque grammaire (schéma XSD) un namespace, auquel on associe un préfixe utilisé dans les balises du document XML.

Le namespace est un identifiant de la grammaire XSD. Techniquement parlant, c'est une URI, soit un identifiant unique répondant à des contraintes assez simple, mais en aucun cas un lien pour la consulter.

Une URI (Uniform Resource Identifier [FR]) est juste un formalisme commun pour l'écriture d'identifiants portables. La principale chose à en retenir est qu'elle commencent pas "préfixe:", ce que la norme appelle le 'scheme" -- "programme" , ou "plan", d'après google translate, parfois traduit par nom de shéma, mais alors on peut confondre avec le schéma XSD ...

Les URL (Uniform Resource Locator) sont une forme particulière d'URI qui permettent de définir une localisation pour une ressource (les fameux liens hypertexte du web). On PEUT donc les utiliser comme identifiant pour les namespace XML, et c'est d'ailleurs pratique pour faciliter la vie des développeurs si ce lien pointe en effet vers le schéma XSD, seulement rien ne l'impose.

Une autre option, ce sont les URN (Uniform Resource Name), une autre variante des URI qui permettent de définir un nom, et non un emplacement, qui par définition peut changer.

Que choisir ?

L'intérêt apparent des URL comme namespace introduit une incompréhension qui n'est pas bénéfique. Par ailleurs, le risque de voir l'URL ne plus pointer vers le schéma pour X raison (changement d'hébergement, changement de nom de domaine ...) est perturbant.

Les URN sont a priori plus adaptées, mais pas très courantes. Il est pourtant plus sain de définir un schéma comme
  urn:schema:monprojet.org:Domaine/1.0
que comme
  http://monhebergementpourlemoment.free.fr/xsd/Domaine_1.0.xsd

Pour aider le développeur (via son éditeur XML préféré) il suffit d'exploiter le mécanisme de localisation des schémas lui aussi prévu par la norme :


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schema:monprojet.org:Domaine/1.0
                    http://qqpart.org/xsd/Domaine_1.0.xsd"

Vous noterez en passant que les namespaces choisis pour les normes XML sont des URL, ce qui participe très activement à la confusion...


Pas convaincu ? lisez cette (traduction de la) note officielle du W3C : http://www.yoyodesign.org/doc/w3c/uri-clarification/

Java 5 apporte son lot de nouveautés, entre autre l'autoBoxing. Sauf qu'il ne s'agit pas d'une évolution au sein de la JVM mais uniquement au niveau de la syntaxe et du compilateur, donc écrire :

Double d = ...;
truc.setValue( d ); // signature : public void setValue( double );

se traduit (en pseudo-code) dans le .class compilé par

Double d = ...;
truc.setValue( d.doubleValue() );

Je serais le 11 mai au ParisJug pour présenter en compagnie de mon Arnaud Héritier préféré une synthèse rapide des nouveautés de Maven 3. Rapide parce que le ParisJug ne nous laisse que 30 minutes, aussi nous avons choisi pour notre sujet une formule ... inhabituelle.

Si vous avez aimé le bouquin, le ton que nous allons (essayer de) donner à cette intervention devrait vous plaire. Et pour ceux qui ne peuvent se contenter de 30 minutes, un petit détour par la troisième mi-temps devra combler ce manque.

Infos, inscriptions, et toute ce genre de choses sur ParisJug.org.

Depuis quelques années, je travaille à mettre en place des outils de "forge logicielle", mutualisés ou dédiés à un projet; voici les outils que j'aimerai assembler pour fournir un environnement clé en main sur projet :

• une machine dédiée (ou une VM) sous Ubuntu, système facile à installer, bien documenté. Le passage sur un Linux permet déjà de tester toutes les problématiques d'encodage de caractères et de séparateurs de fichiers;
• un SVN, un Git ou Mercurial, selon les goûts; 
• un Nexus pour la conservation des artefacts et l'économie de bande passante;
• un serveur Hudson, qui s'installe via un paquet DEB que c'est tellement simple que ça fait pleurer;
• un build Maven (sans blague ?);
• idéalement, une conf magique pour que le build n'ait pas accès au Net, par exemple via http.proxyHost. L'idée est d'empêcher le parser XML de récupérer les schémas XSD sur le Net - si, ça arrive !
• un serveur de démo/test/perfs, sur lequel la dernière version NIGHTLY est déployée automagiquement;
• un job dédié pour alimenter un Sonar en build nocturne; Je préfère prendre Sonar avec sa conf par défaut puis voir ce qui en émerge et comment ça évolue, pour voir là où l'équipe doit progresser et réduire la gravité des règles qu'elle considère inutiles APRES les avoir violées trop régulièrement (au moins, on s'est posé la question). En général, les indicateurs de complexité s'envolent rapidement ;)
• un wiki projet, j'aime bien xWiki qui est puissant et colle bien dans cette forge "tout java". Les plugins Eclipse et Office (pas testé) peuvent aussi aider à faire apprécier le principe du Wiki même aux plus classiques d'entre nous;
• un gestionnaire de tâches/bugs. Sauf à avoir un JIRA en centralisé, il peut être intéressant de le conserver sur la machine projet avec le reste et de gérer les sauvegardes d'ensemble de la forge. Je n'ai pas de préférence faute d'avoir pu tester autre chose que cette bouze de Quality Center;
• pourquoi pas un serveur iceScrum pour ceux qui pratiquent;
• un outil de revue de code, dans l'esprit de Crubicle, et dans l'idéal intégré à l'IDE... je n'ai pour l'instant rien trouvé;
• un environnement de dev prêt à installer. Pour l'instant je fais un gros ZIP d'Eclipse + JDK + Maven + Tomcat + ... mais c'est pas le top, surtout pour gérer les mises à jour.

Je suis sûr qu'il manque plein de briques intéressantes à rajouter à cette wishlist, j'attend vos suggestions ;)

La grande mode en ce moment en terme de gestionnaire de code c'est Git. La différence avec Subversion, la grande mode de juste avant, c'est que Git est distribué. Super, et alors ?

Prenons une journée type. Vous bossez sur un item qui vous fait modifier du code un peu partout et quelques refactorings bien sympatoches. Arrive alors une urgence bien trempée, un point fonctionnel pas clair qui oblige à temporiser, ou encore une soudaine envie de passer à autre chose parce que là, vraiment, ça n'avance pas.

Que faire ? Lancer un nouveau checkout pour partir sur autre chose et switcher entre deux workspaces Eclipse ? Idéalement, il aurait fallu travailler dans une branche, comme ça passer à autre chose se ferait sans perdre l'état en cours... sauf qu'il aurait fallu le prévoir à l'avance et que la manipulation ne dépende pas de votre réseau de %@! qui semble être basé sur des modems 56k.

Et bien c'est ce que propose Git ! 

Git gère un repository rien qu'à vous dans lequel vous pouvez brancher, switcher, commiter, comparer et tripatouiller tout ce que vous voulez. Etant 100% local, ces opérations sont extrêmement rapides, donc deviennent naturelles (alors que sous SVN elles sont méconnues)

Pour bosser, on commence par créer une branche pour la tâche considérée, et committer dessus à chaque fois qu'on le juge utile. A tout moment on peut changer de branche, tout annuler, revenir en arrière, etc.

Evidemment, à un moment il faut bien envoyer tout ça à ses petits camarades. Mais comme le repo Git est local, on peut remanier les commits effectués pour en faire quelque chose de plus cohérent, ce qui évite l'effet "fix" qu'on constate sur SVN : 1 gros commit suivi de quelques autres pour les fichiers "oubliés". Du coup la synchronisation entre repos Git est nettement plus atomique. Idem pour travailler à deux, on se synchronise entre binômes sans perturber le repository de référence (avec Git, personne ne fait particulièrement référence, mais dans la vraie vie il faut bien se mettre d'accord pour livrer !).

Bref, Git c'est une autre façon de bosser qui va rapidement devenir indispensable, comme à l'époque où on avait pas de SCM et où on partageait tous un montage réseau...

Les points faibles de Git ?

Outil en ligne de commande, il reste particulièrement obscur sur ces options. L'intégration dans les IDE est moyenne avec un retard notable d'Eclipse (quelle surprise). Enfin, le concept étant relativement nouveau il faut apprendre à l'apprivoiser.

Pourquoi se préoccuper de Git ?

Après tout, Subversion marche plutôt bien. Et bien, si le cas d'usage exposé ci-dessus vous laisse froid, sachez que la prochaine version suivante  de SVN (la N+2 quoi) incorporera un mécanisme de distribution, sans doute inspiré par le succès de Git et consorts. Ce n'est donc pas qu'un effet de Geekitude,  mais bien une évolution profonde des SCM, autant être dans les premiers à savoir en tirer partie.

Comment commencer avec Git ?


Pour faire mumuse, Google Code propose un hébergement Mercurial, assez comparable à Git mais qui a moins le vent en poupe ces temps ci (sans de raison évidente).
Le plus concret est d'utiliser Git au dessus de SVN. Le repo local Git peut en effet se synchroniser sur un SVN classique, ce qui permet d'en profiter sur son poste sans perturber l'organisation de l'équipe. Et une fois le pli pris...

Reste à apprendre les commandes assez obscures de Git et l'utilisation du GitBash sous Windows - plateforme qui n'est pas à l'honneur pour cet outil.

Une nouvelle licence vient de voir le jour, la plus restrictive jamais imaginée à ma connaissance (mais je peux me tromper)

Ce n'est pas de la GPL ou d'une de ses variantes, qualifiées de "virales" - terme qui semble taillé pour faire dresser les cheveux des DSI.

Ce n'est pas non plus d'une licence calculée au nombre de coeurs CPU, ce qui est pourtant un concept déjà assez étonnant qui oblige à acheter plusieurs machines là où une seule suffirait.

Non, je parle de la licence qui accompagne le lancement de l'iPhone de 4ème génération, licence qui dicte purement et simplement l'environnement de développement autorisé. Vous devez donc EXCLUSIVEMENT utiliser le SDK Apple et le langage de programmation ObectiveC pour avoir accès à l'AppleStore. Pas de traduction de langage, d'èmulateur ou d'interpréteur JIT, rien que du "made by Apple" et rien d'autre.

A ce rythme, la version 5 imposera de développer sur MacBook Pro 15" ou supérieur exclusivement, ou encore de disposer d'un abonnement internet d'un partenaire Apple pour uploader sur l'AppleStore, ou peut être de boire exclusivement de la Budweiser, qui sait.

Alors, oui, Apple dispose d'ergonomes de génie, d'un marketing à faire pâlir n'importe qui, mais faut pas pousser. Si c'est la seule arme de l'iPhone pour couper l'herbe sous le pied des développements compatibles iPhone + Android via un langage pivot, ça ne va pas dans le sens de belles applications innovantes et universelles à des prix accessibles.

Une grande majorité des projets basés sur Maven suit la convention de décomposer le projet en modules, selon l'architecture ou les domaines fonctionnels de l'application. Assez fréquemment on retrouve donc quelques modules bas niveau sur lesquels sont basés des module plus avancés, services web, batchs ou IHM web.

Un build "classique" enchaîne la construction de ces modules sans tirer parti du parallélisme de l'architecture de la machine. Si les I/O restent un élément important dans la vélocité du build (pour ma part, mon repository local est dans un RamDisk ce qui booste bien les choses), il est dommage de laisser nos quad-core dormir en attendant la prochaine compilation.

Depuis la semaine dernière, le trunk de Maven3 intègre une évolution qui était pour l'instant développée sur GitHub en pure expérimentation : il s'agit de la parallélisation du build. Pour expérimenter cette option, vous pouvez récupérer un nightly-build de maven 3 sur l'intégration continue du projet.

L'option -T permet de définir le nombre de threads qui vont supporter le build. Maven se charge de répartir la construction des modules du projet sur ces différents Threads et de réordonner le log pour qu'il reste lisible selon un ordre "classique".

Pour ma part, je n'ai pas réussi à le faire fonctionner sur des projets significatifs. Avec mon "gros" projet, je tombe sur une ConcurrentModificationException lors de la compilation AspectJ. Sur un build Archiva qui trainait sur mon disque (nostalgie...) c'est l'instrumentation JPox qui échoue.

Il est probable qu'aucun plugin maven ou outil impliqué dans le build n'ai prévu jusqu'ici d'être utilisé dans un cadre multi-threadé de ce type... il va donc y avoir une grosse campagne de test et d'évangélisation à prévoir. En attendant, Maven est à ma connaissance le seul outil de build a expérimenter cette voie, qui devrait prendre tout son sens sur les fermes d'intégration continue disposant de multi-coeurs et qui pourraient ainsi devenir très réactives.

Wait & See...

Les gars de Google se sont bien amusés avec Google GAG, mais l'idée était intéressante. Pour faire suite à mon billet sur le plugin Sonar de revue de code, passer directement par le code source sous SVN pour associer les commentaires de revue et le code considéré, c'est une solution pratique.

Je lance donc avec mes petits camarades du BreizhJUG une super top toute nouvelle librairie d'annotations : CRADoc. Les suggestions/contributions sont les bienvenues !

public class Sample
{
    /**
     * Moi y'en a faire du JavaDoc pour le fun qu'il décrit rien de
     * qu'est ce que dont ça fait la chose dessous là
     */
    @tesSouhaits( value = "t'as avalé un becherel de travers ?", 
                  reviewer = "jtoubon" )
    public void codeDeMerde()
    {
        @ttention( "il y a plus simple pour créer des double..." )
        double d = new Double( "1.0" ).doubleValue();

        @bracadabra( "fun, mais ça sert à quoi exactement ?" )
        double k = ( d + 2 - 2 );
    }
}

Koshuke Kawaguchi, développeur de génie a qui on doit (entre autre) le célèbre serveur d'intégration continue Hudson, annonce son départ de SUN/Oracle. Mauvaise nouvelle pour SNORCL, mais les utilisateurs d'Hudson n'ont pas de soucis à se faire car Koshuke se lance dans un nouveau projet visant à propulser son bébé à un autre niveau.

L'idée ne semble pas nouvelle, reste à savoir si ce pas aurait été franchi aussi rapidement sans le rachat de SUN... Il va y avoir quelques cadavres dans cette fusion.

Pour Pâques, méfiez vous des lapins-vampires.


Plus sérieusement (si on peut dire), et si la présence exceptionnelle d'Emmanuel Bernard ne suffit pas à vous motiver, le BreizhJUG va se transformer en chasse aux oeufs dans le grand amphi de Supélec. Contrairement à d'autres notre JUG a la chance de ne pas être limité en nombre de places, alors c'est l'occasion de le faire découvrir à vos collègues : passez le mot !

Ce week-end pascal est consacré à une longue réflexion pleine de conséquences. Dans ces cas là, j'ai une astuce : la tondeuse.

En plus d'entretenir le jardin, cet instrument possède un pilotage simple qui libère l'activité neuronale. Il m'arrive donc couramment d'avoir recours à cet ustensile - de jardinage a priori - pour réfléchir activement ou prendre des décisions.
J'ai trouvé une explication théorique à cette pratique : d'après cet article, le développement neuronal du jeune enfant est favorisé par le quatre-pattes et par les mouvements saccadés qu'il impose à la boîte crânienne. Ma théorie est donc qu'on peut extrapoler ce résultat à l'âge adulte, les vibrations d'un engin à moteur favorisant ainsi le bon fonctionnement de la matière grise et la résolution de problèmes qui paraissaient hors de portée.

Je propose donc qu'on équipe tous les bureaux d'études de grands espaces verts, en plus ça sera plus joli.

Vous avez été nombreux à colporter mon poisson d'avril 2010, ce qui a amené plus de 450 visiteurs à douter un court instant de la véracité de ma fausse page 01Net. Le pot aux roses était assez évident et je n'ai pas pris le temps de masquer un peu mieux l'URL pour laisser planer un peu le doute.


Une petite victoire tout de même, car parmi quelques collègues moins "geeks" que les habitués de ce blog, plusieurs se sont bien fait prendre au piège. Sans parler d'un client particulièrement réceptif qui a tellement plongé que personne n'a osé lui dire qu'il s'agissait d'un fake. Il faut tout de même qu'on lui dise la vérité, sans quoi la prochaine réponse à appel d'offre risque d'être comique.

De mon côté je me suis bien marré de voir l'inventivité des habitués de la bloggosphère, entre xebia qui nous invente des lunettes de réalité augmentée qui ajoutent des post-its partout, le touilleur qui se croit revenu en 1999 à l'aire des dot_com, et Google qui nous sort des librairies délirantes MAIS fonctionnelles - le poisson d'avril qui pourrait cacher une vraie bonne idée ? Je ne sais pas si quelqu'un a essayé Google Street View avec des lunettes 3D pour voir si ça marchait vraiment, mais on se demande si c'est un vrai pur gag ou une idée délirante qui deviendra notre quotidien dans 5 ans...

Quand au traducteur Français / Chien sur android, figurez vous que ça existe en vrai (mais pas sur android) - certes, pour les gogos fortunés qui n'ont plus que leur caniche comme amis.

Suite à l'action du gouvernement français pour sauver la langue française d'anglicisme honteux, Google se voit contraint de changer le nom de sa fonctionnalité Google Buzz dans la version française de gMail.


Reste à savoir si Google Ramdam connaîtra un meilleur accueil que son prédécesseur...

Avec la finalisation de Maven 3, Sonatype commence à sortir des outils autour de ce nouveau coeur, enfin extensible à souhait. MavenShell est un de ceux-ci, conçu pour les fans de la ligne de commande, mais qui veulent aussi un outil pointu et rapide.

Le secret de MvnShell c'est tout simplement qu'il conserve en cache les POM et la configuration des plugins déjà exécutés dans le shell. En pratique, une fois le premier build passé il permet de gagner un peu de temps sur les builds successifs.

Bien sûr, si la majorité du temps passé sur un build concerne le passage des tests ça ne va pas changer grand chose, mais c'est toujours ça de pris.

Autre bonus de ce shell, via l'intégration de JNA, il permet d'avoir une console colorée, agréable pour éplucher plus efficacement le log du build. Il faut dire qu'un log peut parfois être particulièrement inexploitable, avec un mix des divers plugins impliqués et de la sortie console des tests. Le log Maven3 dans le shell fait ainsi ressortir chaque plugin avec son exécution et le module maven considéré, ça aide bien.

Pas de quoi faire une révolution tout ça, mais tout de même un exemple de ce que va permettre Maven 3 : de nouveaux outils, de nouvelles extensions. Je pense au support dans les IDE bien sûr, mais aussi à l'intégration continue (plutôt que les hacks actuels pour scruter le build Maven2), à la manipulation des méta-données dans le repository, pouquoi pas aussi aux outils de Q&A, à une meilleure exploitation du parallélisme, etc.

Vous me direz, tout ça c'est pour les projets Maven3. Et bien détrompez-vous, je fais mes tests avec un projet qui utilise "officiellement" Maven 2 et je n'ai pour l'instant rencontré aucun problème de compatibilité, que ce soit avec ce shell ou avec la dernière mouture de m2eclipse.

Alors, c'est vrai, Maven 3 ce n'est pas encore pour tout de suite, mais ce n'est plus de la science fiction.

Je viens de lire cet excellent article qui compare le chemin parcouru par Spring et JBoss au travers de la normalisation de leurs technologies par le Java Community Process (JCP).

L'article sait garder un bon niveau de neutralité et expose très clairement ses arguments. Spring a toujours joué les pieds dans le plat et la critique - justifié dans de nombreux cas - alors que la ligne prise par JBoss a toujours été claire vers la normalisation d'Hibenate et de Seam par le JCP.

Si les deux protagonistes n'ont de toute façon pas toujours été très fair-play, il en sort :

• un Seam 3 basé sur les normes de JavaEE6, et une image de JBoss comme moteur sur ce sujet;
• un Hibernate, déjà standard de fait, sorti renforcé par la norme JPA (il y a encore des gens qui ne veulent pas entendre parler d'Hibernate, amusez vous bien les gars ...);
• un Spring 3 qui déçoit pour son peu de contenu (pour ceux qui n'ont que faire d'OSGi en tout cas);
• une norme @Inject qui a le mérite d'exister mais qui fait un peu court. Spring implémente bien cette norme mais elle ne suffit pas à bâtir une application;
• une image déplorable de Spring sur son intervention tardive et polémique dans le JCP. Autant la critique du modèle EJB était argumentée, autant la participation de SpringSource à la JSR JavaEE6 aurait pu être bien plus constructive. C'est bien de taper dans la fourmilière mais au bout d'un moment il faut aussi savoir reconstruire;

Sur l'adoption tardive des technologies par Spring je suis plus réservé. Les dates indiquées semblent montrer un retard à l'allumage de ~3 ans, je ne les met pas en doute, mais ces technologies nécessitent un temps d'appropriation et de maturation. Si Spring s'était jeté sur JSF 1.0 dès sa conception on aurait jamais eu SpringMVC. Le rôle que c'est donné Spring de ce point de vue est de proposer un regard critique et argumenté sur la mise en oeuvre de ces standards, je ne suis pas choqué que ça nécessite un peu de recul.

Quand on parle d'interface web sexy, on pense souvent à Flash. Il faut dire que les années IE6 (qui se prolongent pour certains) ont fait des dégâts pour la réputation de JavaScript et que Flash était la seule solution viable.
Aujourd'hui HTML5 est mature et bien supporté par les navigateurs récents. Le ralliement d' IE 9 est un signe des temps qui montre que c'est bien la plateforme du futur.

OK mais qu'en est-il de la productivité des développeurs ?

Personnellement je suis fan de GWT car il me permet de rester dans le même langage sur toute ma chaîne de développement. Mais ceux qui ont franchi le pas d'apprendre ActionScript et d'acheter FlexBuilder n'ont pas ce genre de considérations.

Je tombe via Ajaxian.com sur ce billet, qui décrit l'abandon de Flash pour HTML5 (canvas). L'intérêt de ce billet n'est pas la prouesse technologique de faire "aussi bien" que la référence Flash - quoi que c'est déjà intéressant pour ça - mais qu'il argumente le pourquoi et les avantages de cette migration.

• moins de code et un "livrable" plus compact. Une bonne baffe pour ceux qui voyaient dans le format binaire de Flash un argument de compacité;
• un meilleur support sous Linux (j'y ajouterais les plateformes mobiles, qui ne sont pas la cible ici);
• une chaîne de production plus simple, en l'absence de phase de compilation;
• une meilleure intégration avec le reste de la page web (événements clavier, gestion du curseur ...)

Cependant, le billet met aussi en évidence les points forts de Flash :

• support des polices de caractères embarquées;
• des manques dans HTML5 sur la manipulation de fragments HTML, le clipping et le rafraichissement

HTML5 n'est donc pas la solution miracle à tous les problèmes (chaque techno passe par une phase où tout le monde y voit le messie avant de comprendre qu'elle a ses limites et ses faiblesses). Par contre c'est une alternative viable et performantes à Flash pour de nombreuses utilisations. Dans certains cas, cela peut même être une solution plus universelle et plus performante (il n'y a toujours pas de lecteur Flash sur l'iPhone à ma connaissance)

Au premiers temps, j'ai géré un "maven_proxy", lequel s'est rapidement noyé sous une masse de jars hétéroclites. Il faut dire qu'à cet époque il n'y avait pas de consensus sur le référencement des apis Java, sans parler de la migration vers Maven2 qui s'est jouée pour nous à cette époque. Il en ressort un répertoire maven_repo avec des doublons, triplets, voir plus (6 versions de EJB2.jar).

Je cherche depuis un moment un outil pour accompagner la revue de code, autre chose que l'impression des listings et le stabilo. Il y a évidemment l'excellente suite Atlassian, mais bien sûr accompagnée de son tarif - sans doute justifié - qui limite sensiblement mes chances de le voir accepté dans la boite à outils standard.

Julien Viet m'a suggéré une évolution sur Fonzie : Utilise le processeur d'annotations (APT) de JavaC à la place du compilo AspectJ.

@Entity
public class User
{
public native void persist();
}

Pour un projet utilisant le JDK6 pour compiler, et sans rien faire sauf ajouter Fonzie-0.4-SNAPSHOT en dépendance, le fichier .class décompilé donne ceci :

@Entity
public class User
{
  public void persist()
  {
      Fonzie.instance();
  }
}

Pour ce premier jet, le code introduit dans la méthode n'est pas passionnant, mais au moins le squelette est en place. Reste à construire via l'AST le code d'invocation Fonzie qui va bien -- et ça, ça va être tout de suite plus toochy.

Microsoft publie le positionnement de IE9 sur le blog MSDN

Après avoir pesté toute la journée d’hier sur Eclipse, je viens de penser à une piste pour résoudre mon problème :

J’ai utilisé dans mon POM le pseudo-plugin org.maven.ide.eclipse::lifecycle-mapping que proposait m2eclipse 0.9.9 pour activer la compilation incrémentale. En conservant ce plugin activé, m2eclipse 0.10 ne prend plus en charge la configuration d’Eclipse et je me retrouve donc avec mes soucis de WTP pas configuré et de target/generated-sources absents.

En virant ce plugin, m2eclipse 0.10 retrouve son mode nominal et la configuration se passe donc “comme dans le manuel”.

mea culpa donc, je suis un bête gars qui a essayé les pré-version et a cru que la compatibilité serait au rendez-vous, mais quel boulet celui-là.

J’ai tout de même posté sur le sujet sur user@m2eclipse.codehaus.org,  en espérant que ça puisse servir à d’autres.

L’actu Maven du mois de février est chargé :

Le plugin Maven-Release passe (enfin) en 2.0, vous pouvez donc profiter d’un mécanisme très complet et bien ficelé de gestion des releases sans reposer sur un statut “beta”, ce qui pouvait en effrayer quelques-un.

fini les m2eclipse-0.9.9-dev, avec la sortie officielle de m2e 0.10.0

Non ce n’est pas un erreur, il ne s’agit pas d’une 1.0.0 de m2eclipse, celle qui aurait annoncé enfin l’intégration efficace de Maven dans Eclipse. C’est plutôt une milestone de ce que sera cette intégration .. un jour.

Sans compter que Sonatype a choisi de mettre de côté l’intégration SVN, WTP ou AJDT faute de ressources pour les supporter efficacement, et préfère ce concentrer sur le noyau. Si le principe semble assez logique (on ne peut pas courir plusieurs lièvres à la fois) les utilisateurs vont vite être déçus de voir qu’il ont attendu 8 mois (la précédente version stable 0.9.8) pour ne toujours pas avoir un résultat complètement fonctionnel.

Pour ma part, la configuration de WTP ne marche tout simplement pas, alors qu’elle fonctionnait avec une 0.9.9 récente (?). Aux questions sur ce sujet la réponse est systématiquement, “nos efforts se concentrent sur le code, on verra le reste après”.

Je ne leur jetterais pas la pierre, car en tant que mainteneur de l’intégration m2eclipse / eclipse-checkstyle je me rend compte que le développement de plugin Eclispe est un art délicat et que j’y suis bien malhabile. Reste qu’on a pas fini de se plaindre de la piètre intégration du couple Eclipse + Maven comme environnement de développement. Wait & See, encore et toujours…

Julien Dubois a lancé le débat sur son blog en présentant ses astuces pour un build plus réactif. Entre autres idées, il utilise un disque SSD pour espace de travail.

Je ne suis pas du tout convaincu par cette option, vu que ce type de disque n’est pas très tolérant aux écritures multiples. Je pense que, si les perfs peuvent être meilleures sur le coup, la durée de vie de la bête risque d’en prendre un coup.

Une autre option que je suis en train d’expérimenter, suite à la même analyse venant de Julien -- l’autre Julien, celui du BreizhJug ;)

Comme mon PC est sous Windows XP 32bits je ne peux pas profiter à 100% de mes deux barettes de RAM de 2Go. Windows ne voit que 3Go adressables. Même le mode “PAE” n’y a rien changé. Cependant, il existe des RamDisk comme Gavotte RAMdisk qui savent contourner ce problème et récupérer cet espace perdu. Un RamDisk de 1Go, bien assez pour mettre mon workspace.

mvn clean install -Dmaven.test.skip=true

sur le HD “classique” :

[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 48 seconds

sur le RamDisk :

[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 30 seconds

 

Reste à voir ce que ça donne sous Eclipse …

Autres pistes à creuser :

• Tuer cette saloperie de process MacAffee
• Utiliser JRebel (des licences offertes au BreizhJUG !)
• Utiliser un disque SSD pour le repository maven (moins sujet aux écritures)
• Se payer un PC (voir un Mac ?) plus adapté aux devs !

Update (pour ceux qui ont la flemme de lire les commentaires)

Placer le workspace en ramdisk booste un peu les perfs, mais pas autant que de placer le repository Maven ! Il faut dire que nos outils passent leur temps à charger des libs en tout genre. En plus, c’est un moyen simple pour faire du ménage dans le repo – à condition d’avoir un repo manager qui fournit les artefacts via le réseau local :)

Ca pourrait être pas mal non plus de mettre l’OS en ramdisk :p

JavaEE 6 est sorti (oui je sais, ça fait déjà deux mois) et JPA 2.0 avec. Il est donc tentant de passer à Hibernate 3.5 (Beta 4 actuellement) et à Spring 3.0.0 ... sensé être JavaEE 6 compliant

J’utilise Oracle eXpress pour les développement. Dans l’esprit “une base par développeur”, cette édition allégée (faut le dire vite) d’Oracle est bien pratique. Le dialecte SQL propre à la base est ainsi testé en phase de développement.

Pour l’intégration continue, j’installe la base sur un système Ubuntu dans une VM, et c’est là que ça se complique … oracleXE n’étant dispo qu’en version 32 bits dans le dépot debian d’oss.Oracle.com

Voici donc pour info la procédure à suivre :

1- installer Ubuntu server 64 (sans blague ?)

2- ajouter le paquet open-ssh. La console VMWare est pas terrible, alors qu’un putty permet de faire des copier/coller à la souris ;) -- se loguer en ssh pour la suite

3- ajouter les paquet bc et libc6-i386

$ sudo apt-get install bc libc6-i386

4- créer un gros swap, nécessaire pour OracleXE

$ sudo dd if=/dev/zero of=/swpfs1 bs=1M count=1000
$ sudo mkswap /swpfs1
$ sudo swapon /swpfs1

5- télécharger les binaires d’oracleXE et de sa dépendance libaio en version i386

$wget -c http://oss.oracle.com/debian/dists/unstable/main/binary-i386/libaio_0.3.104-1_i386.deb http://oss.oracle.com/debian/dists/unstable/non-free/binary-i386/oracle-xe-universal_10.2.0.1-1.1_i386.deb

6- installer tout ça, en demandant à Ubuntu de ne pas tenir compte du conflit d’architecture 64/x86

$ sudo dpkg -i --force-architecture libaio_0.3.104-1_i386.deb
$ sudo dpkg -i --force-architecture oracle-xe-universal_10.2.0.1-1.1_i386.deb

7- configurer OracleXE. Je vous déconseille de changer la conf par défaut, chez moi le choix d’un port autre que 8080 fait que l’appli d’admin Oracle est injoignable. On changera ça après coup

$ sudo /etc/init.d/oracle-xe configure

8- un petit vi pour mettre à jour votre ~/.bashrc

ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_HOME
export ORACLE_SID=XE

9- on va maintenant changer la conf de l’appli d’admin d’OracleXE, sans quoi on ne peut pas y accéder – seul localhost est autorisé, et sur notre ubuntu server, y’a pas de navigateur puisque y’a pas d’environnement graphique ! sqlplus est dispo sous /usr/lib/oracle/…./server/bin

$ sqlplus /nolog

CONNECT SYS/password AS SYSDBA

EXEC DBMS_XDB.SETLISTENERLOCALACCESS(FALSE);

EXEC DBMS_XDB.SETHTTPPORT(‘8081’);

 

et voilà ! :)

Au printemps dernier j’ai proposé à des collègues de “jouer” avec Google App Engine for Java en développant une application pour gérer l’inscription au BreizhJug. Comme beaucoup nous utilisons JugEvents et comme beaucoup nous trouvons cette appli très moche, sans parler de ses plantages réguliers.

Nous sommes partis sur un truc bien trop gros pour nos petites épaules et ça a donc fait plouf en moins de deux.

La conférence de Didier Girard m’a donné envie de repartir sur ce développement, en utilisant une approche plus pragmatique et plus économique :

Les soirées BreizhJUG sont déclarées dans un Google Calendar public. Lieu, date et sujet y sont indiquées, la description servant à définir le(s) speaker(s) – première ligne – et le sujet du jour. L’intérêt ? L’appli Juggers n’a plus à gérer la saisie des événements et les droits d’accès !

L’application utilise gwt-gdata pour accéder à ce Calendar, et récupère donc une liste d’objets structurés, de manière (presque) aussi simple qu’un appel GWT-RPC.

L’inscription elle même n’est pas développée, peut être dans un premier temps sur la base d’une simple Google Form. L’idée est de progresser par tout petits pas, histoire de ne pas finir le bec dans l’eau.

J’en profite pour expérimenter uiBinder, et comme je commence tout juste un projet Wicket je ne peux pas m’empêcher de faire un parallèle : uibinder c’est la facilité de Wicket + la force de GWT, de la bombe atomique ! J’ai ainsi maquetté un widget sympa en HTML/CSS, et je peux le convertir rapidement en widget GWT utilisable partout.

L'appli est également rendue plus sexy grâce à gwt-Fx, en quelque sorte un portage de scriptaculous en GWT (pas juste un wrapper). La dernière version est vraiment bien et très souple d’utilisation.

Vous voulez-voir ce que ça donne ? http://www.juggers.org/ – attention, ce n’est ni une béta ni même une alpha, c’est un early prototype snapshot ;)

NB : ne cherchez pas, ça rend rien de bon sous Internet Explorer. Qui aurait l’idée d’utiliser ce truc de toute façon ?

Pour noël, une idée cadeau amusante : offrez google chrome à vos amis !

Google Chrome est le navigateur massivement adopté par les geeks et autres développeurs technophiles, mais encore peu connu du grand public – un peu comme l’était FireFox à ses débuts.

Pour étendre les parts de marché de ce navigateur, rien de mieux que le bouche à oreille, c’est donc ce que propose http://www.givechrome.com. Une bonne façon de passer un petit mot de “bonnes fêtes” à belle maman pour les fêtes sans dépenser un centime ;)

Vu que pour ma part j’utilise déjà Chrome, je vous suggère une autre idée cadeau : je n’ai toujours pas de MacBook :)

Nous sommes toute une génération de développeur qui a été bercée par la course au Méga-Hertz, et si nous constatons un plafond les vieux réflexes perdurent. Face à un programme trop lent, la solution reste le “plus gros” processeur.

Seulement, l’offre des fondeurs de puces est explicite : n’espérez plus de GHz supplémentaire – à la place, on vous propose des cœurs en plus.

La conférence de Brian Goetz à Devoxx ainsi que son livre “Programmation Java Concurrente” sont basés sur ce constat. Fini le Free Lunch sur la puissance CPU. Pour faire plus rapide il va falloir apprendre à penser et à parler parallélisme, concurrence et synchronisation, des sujets particulièrement pointus et mal connus.

Pas encore convaincu ? Intel annonce avoir dans ses labs un processeur à 48 coeurs ! Vers 2012, un serveur haut de gamme se basera sur ce type de puce, et votre PC portable entrée de gamme en 2020 aussi. Croyez-vous vraiment que vos logiciels sauront en profiter ? Votre super batch d’import de données tire t-il profit d’une architecture à 48 coeurs, ou ressemble t-il plus à un bête programme séquentiel, comme décrit dans votre document de spécification ?

Les traitements lourds comme les encodeurs vidéo, traitement d’image et autres manipulations massive de données ont déjà franchi le pas, mais que penser des milliers d’autres softs, … à commencer par ceux que nous développons nous même !

Aujourd’hui, les mots incontournables sur un CV sont Spring, Hibernate ou Scrum (encore que ça devienne de plus en plus banal). Qui sera le premier à mettre en avant (à bon escient) “Parallélisme” pour sortir du lot ?

Antonio Goncalves vient lundi animer la session BreizhJug en présentant JEE6

 

Pour lui rendre la politesse, je viendrais le lendemain faire un tour au ParisJUG, en tant que simple spectateur, pour un match JEE6 vs Spring3.

La session sera filmé et retransmise sur NT1 dans Catch Attack :)

L’occasion de participer à une séance dédicace pour souligner la forte présence francophone dans le monde de l’opensource : Antonio pour son livre sur JEE6, Julien Dubois pour Spring par la pratique, Emmanuel Bernard pour Hibernate Search in Action, et Arnaud Héritier accompagné de votre serviteur pour Apache Maven. Pour avoir les liens je vous suggère de passer par le blog d’Arnaud qui a déjà fait le boulot et m’économise ainsi de nombreux copier/coller.

… enfin, à condition de ne pas être bloqués par la grève SNCF qui s’annonce :-/

Pour les besoins d’une chouette appli web, je me retrouve avec la casquette de Web Designer pour quelques semaines. Et une fois de plus, pas de HTML5 à l’horizon mais plutôt notre bonne vielle bouse de service : IE6.

S’il existe de nombreux hacks et autres astuces éprouvées pour faire rentrer au forceps dans ce navigateur maudit les CSS et événements JavaScript de nos applications “modernes”, un problème tout bête se pose : comment tester ?

Et oui, je suis passé sur mon PC à IE8, et même en le désinstallant (en supposant que le résultat soit bien un retour à l’état initial) je me retrouve avec IE7 qui ne réagit pas comme IE6 – bien que pas fantastique il est nettement plus conforme aux standards !

J’ai finalement découvert ce petit soft : http://ietester.softonic.fr/

D’autres astuces visant à installer IE6 en “standalone” sont infectées par le navigateur présent et ne permettent pas de reproduire les bugs / défauts spécifiques à ce navigateur. IETester par contre intègre les diverses versions d’IE et on peux bien constater les comportements CSS ou JavaScript différents entre IE6 / IE7 et IE8 (et même IE5.5 pour les passionnés d’archéologie).

Je proposerait bien comme solution de développer l’appli en intégrant Google Chrome Frame, solution à mon avis idéale pour migrer des intranet dans un environnement up-to-date SANS changer pour autant le navigateur “corporate”. Cela supposerait cependant que ceux que j’ai en face soient conscient que leur indécrottable IE6 pénalise leur SI en imposant un socle technique dépassé – discours qui semble se répéter sans fin année après année…