new Blog( perso );

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 !)

07 mai 2009

javax.inject - enfin !

L'injection de dépendance aura marqué ces dernières années :

Apache Avalon et dérivés ont montrés la voie, même s'ils étaient sans doute un peu trop précurseurs et largement sous-documentés ;
Spring a enfoncé le clou et définitivement imposé l'idée grâce à une documentation rarement égalée dans le monde opensource et aux qualités de pédagogue de son créateur ;
Google Guice a marqué une étape en proposant une solution légère basée sur les annotations ;
JBoss ne s'y est pas trompé en renommant "sa" JSR299 de Web beans en Java Context and Dependency Injection

sans parler des outsiders que j'oublie probablement... Bref POJO et injection de dépendances deviennent les éléments incontournables de toute bonne architecture moderne.

Comment éviter d'être lié à un framework donnée ? Via une spécification officielle Java (JSR) !

La JSR299 a cet objectif mais ne remporte pas les suffrages. Ni Google Guice, ni SpringSource n'ont répondu à l'appel ... et on sait enfin pourquoi : Google Guice et SpringSource collaborent à l'élaboration d'une nouvelle JSR, permettant en théorie de passer de Spring à Guice au runtime sans toucher à votre code.

Malgré ses limitations, j'étais jusqu'ici un défenseur de l'injection via l'annotation @Resource (jsr250). Bien que supportée uniquement par Spring (et les EJB3) elle avait au moins l'avantage d'être non liée à un framework. Avec cette nouvelle JSR, on aura donc un moyen de spécifier clairement l'injection de dépendance sans se lier à un framework et une réelle alternative au runtime.

Quel intérêt ? Après tout, c'est vraiment rarissime de passer une appli de Spring à Guice juste pour le fun ! Pensez aux frameworks et bibliothèques, qui vont pouvoir exposer leurs composants et dépendances via cette API. C'est déjà le cas pour l'écosystème Plexus, et j'ai développé une passerelle pour pouvoir les utiliser dans un contexte Spring, mais ça reste du bricolage.

A l'avenir, on pourrait donc imaginer récupérer une bibliothèque utilitaire de type "accès à Google Map en Java" utilisant cette JSR et pouvoir l'exploiter depuis Spring ou Guice sans intermédiaire. Un retour des composants de haut niveau "sur étagère" ?

06 mai 2009

Un Leopard dans mon XP

Vu que personne ne veut m'offrir un beau MacBook 17 pouces, j'ai bricolé mon bon vieux Windows XP avec un BricoPack pour le rendre "MacOS Leopard-like". La solution du pauvre, c'est vrai, mais c'est mieux que rien.

Découverte intéressante qui en dit long sur Windoz : l'économiseur d'écran "Flurry" en version Win32 est ultra lent sur ma machine - la faute au chipset Intel Graphics. En renommant le fichier flurry.scr en flurry.sCr (subtil !) ça devient tout à fait fluide.

Windoz est vraiment un système étonnant, qui nous promet chaque jour une nouvelle surprise !

compile, compile pas

Je rencontre un problème jusqu'ici innexpliqué sous Hudson :


[INFO] Compilation failure
/home/hudson/.hudson/jobs/bios/workspace/bios/bios-prise-de-commande/bios-pdc-remoting/target/generated-sources/cxf/com/sfr/pates/PaymentQueryManager.java:[26,18] cannot find symbol
symbol  : method partName()
location: @interface javax.jws.WebParam

Je suis tombé sur ce qui semble bien être un bug "rigolo" :

Voici la description de la classe WebParam (définie par la spec JAX-WebServices) sur un poste Windows :

javap -classpath jsr181-1.0.jar javax.jws.WebParam
Compiled from "WebParam.java"
public interface javax.jws.WebParam extends java.lang.annotation.Annotation{
   public abstract java.lang.String name();
   public abstract java.lang.String partName();
   public abstract java.lang.String targetNamespace();
   public abstract javax.jws.WebParam$Mode mode();
   public abstract boolean header();
}

La même commande, passée sur Hudson (Solaris) :

javap -classpath jsr181-1.0.jar javax.jws.WebParam
Compiled from "WebParam.java"public interface javax.jws.WebParam extends java.lang.annotation.Annotation{
   public abstract java.lang.String name();
   public abstract java.lang.String targetNamespace();
   public abstract javax.jws.WebParam$Mode mode();
   public abstract boolean header();
}

Pas de partName :'(

En gros, la librairie de référence jsr181 que j'ai récupérée est bugguée ... D'ailleurs, elle n'est pas dispo dans le repo maven "central" et le lien dans le POM Maven est cassé - il pointe vers leserveur d'un certain "BEA" :p. Délicat donc de savoir où aller la chercher !

Il existe heureusement une alternative via les jars du serveur Geronimo. J'ai aussi ajouté dans le build Maven un contrôle sur les dépendances qui permet de vérifier qu'on embarque pas cette jsr181 récalcitrante.

01 mai 2009

Retour à la case départ

Mon écart de langage envers le fondateur de Maven n'aura pas eu un grand effet. Quelques autres développeurs ont pris position (de manière plus "diplomate") mais les choses ne bougent pas pour autant.

En résumé :

1. Je me suis pris dans la face un "tu n'as committé que trois fois, et tout ce que tu as fait a du être rollbacké" - ça c'est pour me remettre à ma place.

2. "Maven c'est compliqué, c'est normal qu'on y comprenne rien à moins de s'y mettre à fond". C'est une certaine vision de l'informatique qui s'exprime, je comprend qu'on ait du mal à se mettre d'accord en partant sur cette base.

3. "Va faire mumuse sur maven 2.x, de toute façon l'avenir c'est Maven 3". En un sens c'est presque rassurant, on va au moins pouvoir sortir des versions de maven 2 sans devoir attendre deux ans que ce soit prêt - c'est déjà assez compliqué comme ça !

J'ai bien proposé de rennoncer à mon accès SVN sur Maven si mon état d'esprit ne collait pas avec la "ligne du parti", mais ça ne change pas grand chose. Ce droit sur le trunk ne me sert de toute façon à rien vu que je n'ai tout simplement plus aucune idée de ce qui s'y passe.

Nous en restons donc là, et je vais effectivement essayer de participer plus activement à Maven 2.2. Reste que le développement des plugins Maven reste le moteur le plus significatif pour une grande majorité des committers, et certainement ce que les utilisateurs suivent / attendent le plus. Après tout, maven-core ne fait qu'exécuter ces plugins, peut importe s'il utilise le top-du-top de l'injection de dépendances !

27 avril 2009

Différentes façons de faire de l'opensource

Pour ceux qui auraient raté mon précédent billet, voici une petite explication de texte : il y a de nombreuses façons de faire de l'open-source.

Prennons d'abord la fondation Apache - si on se réfère à la doc de l'incubateur :

The minimum requirements that a Podling SHALL meet prior to being graduated to the ASF are :

(...)

Demonstrate an active and diverse development community
The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

Pour faire court, la Fondation Apache considère qu'un projet open-source est surtout porté par une communauté diverse et active. La qualité intrisèque du code a peu d'importance s'il n'y a pas du monde motivé derrière.

Passons maintenant à CodeHaus :

The Codehaus recognizes that some committers, based upon metrics, longevity and appointed management, have greater say on a project than others
The Codehaus places a high bar on entry for projects
In case of disagreement, The Despots are right

Ici la phylosophie est très différente : un projet opensource se doit d'être bien ficellé, production-ready, et supporté par des développeurs talentueux. Pas forcément "des" développeurs d'ailleurs.

On a donc deux approches très différentes. Apache favorise l'approche communautaire. Les commons-* en sont la meilleure démonstration, certains composant dormant depuis de longues années dans le bac à sable. Codehaus préfère l'excellence technique, quitte à passer par ce qu'ils appellent sans nuance des "despotes"

Qui a raison ? Les deux mon capitaine ! L'opensource est un monde varié, les deux approches ont abouties à des outils remarquables, le tout est de ne pas se tromper d'adresse.

25 avril 2009

Do you have a Mac ?

The GWT-maven-plugin developement is going well and I expect a 1.1 release soon. Still have to fix some issues, check the docs and provide more samples.

I'm now building a IT-test harness to check I don't break things anymore when changing code.

The last "oups, I broke the plugin" is related to running GWT-SDK tools on Mac. I don't have one myself so can't test on this platform.

If you want to support the gwt-maven-plugin, please lend me a Mac Book or Mac mini (low-cost Mac, if 600€ can be considered "low"). If your company want's to support the plugin I'd be pleased to add a sponsoring link on the plugin site.

--> mailto:nicolas@apache.org

22 avril 2009

OPA hostile sur Maven

Notre bon amis Jason, quelques soient ses mérites, à la fâcheuse habitude d'avoir des idées très arrêtées et de les imposer par le fait accompli.

On a eu le droit au développement concurrent d'Archiva et Nexus, le premier - plan de longue date de la communauté maven (cf wiki et mailing list), le second - projet perso de Jason & Friends
On a eu droit à XBR sur maven3 pour remplacer Plexus (vous ne connaissez ni l'un ni l'autre ? comme c'est étrange !)
On a eu droit à la refonte complète du mécanisme de transport de Maven (wagon) par l'équipe de Jetty (-> mercury) sans avoir eu le temps d'en discuter sur la liste dev avant que ce soit déjà en place. C'était peut être utile, voir nécessaire, mais on pourrait en causer un peu avant, non ?
J'ai même eu droit à un mail perso de Jason (on est super pôtes) pour me proposer d'intégrer le plugin GWT à la Sonatype forge - quel honneur !

J'en rate probablement, vu que je ne suis pas au courant de tout (c'est pas facile à suivre), mais nous sommes nombreux à nous être (poliement) accroché avec le Monsieur et à baisser les bras.

Dernier fait d'arme en date, Eugene Kuleshov, développeur émérite de m2eclipse , vient de se faire sortir à coup de pied au c... du projet qu'il soutiens depuis 5 ans. Sans doute n'avait il pas le profil assez "lisse" pour se plier aux idées du "reste de l'équipe" qu'il perturberait (?). Ca doit faire très mal à l'égo, je n'aimerais pas être à sa place.

On arrive donc de plus en plus clairement à un putch en règle sur la direction de l'écosystème Maven, certes par son créateur, mais très loin de l'esprit d'un logiciel communautaire - règle de base de la fondation Apache !

Je crois (encore) au potentiel de Maven, même si les promesses de maven 3 semblent très très très lointaines (depuis le temps qu'on l'attend), mais cette attitude me fait franchement douter. Maven va rapidement souffrir des reproches qu'on peut entendre sur Spring ou JBoss, accusés d'être des projets opensource "fermés". Le développement commence à se faire presque exclusivement sous le contrôle de Sonatype, à quand un "Maven Pro" payant intégrant des extensions propriétaires ?

A ce rythme je vais finir par revenir au bon vieux Ant et son pôte ivy.

20 avril 2009

Sun racheté par Oracle

J'apprend juste l'achat de SUN par Oracle. IBM s'est donc fait couper l'herbe sous le pied.

Reste à savoir ce qu'Oracle va faire de sa nouvelle acquisition. Depuis le rachat de BEA par exemple, il est devenu impossible de télécharger la JRockit, JVM réputée de l'ex-BEA. Les pages téléchargement existent toujours mais plus de liens... sauf peut être à avoir un compte support Oracle.

Difficile de prédire quelle orientation Oracle va donner, et en particulier comment la partie "soft" va s'en sortir. Oracle continuera t-il à investir dans des projets comme NetBeans ou GlassFish ?

18 avril 2009

Appengine Java ... réfractaire à Maven !

En tentant de "Mavenizer" le SDK Java d'AppEngine, je tombe sur de nombreuses librairies du SDK qui ne collent pas aux artefacts Maven (somme md5 différente) :

commons-el, commons-logging, jasper-compiler, jasper-runtime, jstl, standard, ant, ant-launcher

rien que ça !

Une petite recherche me fait découvrir une classe de commons-el dont la taille binaire est différente entre les deux JAR. Google aurait-il eu besoin d'adapter ces classes pour son runtime ? Après décompilation : aucune différence !?

Première hypothèse : Google a recompilé lui-même ces librairies. Pourquoi pas, mais ça parrait un drôle d'idée.

Seconde hypothèse : Google a eu besoin de modifier ces classes, non pas dans leur code source mais dans leur structure bytecode. Après tout, le runtime AppEngine a de grande chance de ne pas utiliser une JRE SUN classique, mais plutôt un JVM Dalvik déjà maîtrisé par Google puisqu'elle est au coeur d'Androïd - mais ce n'est que pure spéculation !

Troisème hypothèse : Goole a pris des jars qui trainaient sur un coin de table (ou de disque dur), de toute façon ils n'ont rien compris au problème des dépendances Maven et s'en tappent : ils ne l'utilisent pas (même problème avec GWT-dev). Hypothèse la moins avantageuse car dans ce cas on est pas près de savoir si on peut utiliser les JAR "standard" du dépôt Maven sans risque.

Quatrième hypothèse : Google n'aime tellement pas Maven (il n'y a qu'à voir combien de ses projets majeurs l'utilisent) qu'ils ont décidé de tripatouiller les JARs juste pour nous emmbêter. Un complot mondial je vous dis !

Dernière hypothèse : Jason (Van Zyl, Mr "j'ai créé Maven") a voulu s'assurer l'exlusivité d'un plugin GAE, augmentant ainsi sa mainmise sur l'écosystème Maven. Il a donc collaboré avec Google (dont les bureaux sont voisins) pour s'assurer que ceux qui ne sont pas dans le secret ne s'en sortiraient pas.

Dans tous les cas, il va falloir patienter encore pour avoir une première SNAPSHOT d'un plugin GAE ... ou alors tenter le coup avec les artefacts "officiels" Maven pour voir.

16 avril 2009

breizhjug channel

Annoncée depuis décembre, avec des démos à n'en plus finir de nous allécher, parleys.com se prépare d'ici une semaine à ouvrir une "private beta" de son publisher, qui permettra de monter et diffuser une présentation vidéo/slides sur le site que vous connaissez déjà tous (!)

Pour avoir testé la précédente bêta en octobre, la nouvelle mouture s'annonce fantastique (par rapport à un montage manuel qui est ultra pénible).

Cerise sur le gâteau, Stephan offre l'hébergement aux JUGs du monde entier, à croire qu'il à un super prix sur son accès Internet ;) Parleys va vite devenir la plateforme vidéo incontournable pour ce type de contenu.

Ajoutez à ça que Adobe vient de m'envoyer une suite complète CS3 production premium en cadeau pour avoir accueilli François en février, et ça vous donne une idée de mon occupation pour le week-en à venir (surtout si le temps se maintien...)

12 avril 2009

Maven @ PoitouCharentesJUG

Le PoitouCharentesJUG m’a invité pour son inauguration à venir présenter Maven. J’ai donc rencontré la communauté enthousiaste et accueillante d’une région que je connais bien pour y avoir fait mon service militaire et déniché ma moitié.

14^ème JUG français, le « bravitudeJUG » (surnom totalement non-officiel mais qui leur va si bien) est l’exemple d’une réussite : organisation sans faille, équipe motivée, public pointu, participatif et très chaleureux. Pour une première, qui plus est la veille du week-end de pâques, les 25 membres présents sont une preuve de la dynamique locale, surtout pour une session organisée en à peine 10 jours !

J’ai très largement débordé des 90 minutes qui étaient prévues pour la session, sans pour autant perdre qui que se soit en route. De très nombreuses questions ont été posées par un public mixte : le monde de l’entreprise rencontre ici les universitaires et le secteur public local – une diversité qui promet des échanges riches !

La vidéo et les slides de la session sont disponibles, en attendant que je puisse la diffuser sur Parleys.com. N’hésitez pas à contacter l’équipe du tout jeune PoitouCharentesJUG pour les encourager ou pour leur proposer votre collaboration. La prochaine session devrait être organisée sur Niort et portera sur les IHM, web (GWT) et desktop (Eclipse RCP). Encore une soirée riche en perspective ;)

09 avril 2009

Google Developer Day – community feedback

Google organisait jeudi en fin d’après midi une soirée pour présenter son AppEngine en version Java à la communauté et récolter un premier feedback. Didier Girard était de la partie, décidément toujours sur les bons coups :)

L'annonce, c'est bien sur Google App Engine for Java + GWT 1.6 + un plugin Eclipse.

Premier point, la plateforme est un pseudo tomcat tournant sur un Java6 « à la sauce Google ». Comprenez que certaines API Java sont blacklistées, soit parce qu’elles n’ont aucun sens sur le « cloud » (java.io.File par exemple), soit pour des questions de sécurité. Il n’est par exemple pas possible de lancer un Thread, et certaines pratiques de réflexion ne sont pas autorisées.

Ces petites limitations ont un gros impact sur les frameworks que nous pouvons utiliser. Guillaume Laforge a fait un gros travail d’analyse sur Groovy pour le rendre compatible (et accompagner ainsi l’annonce très relayée de Google). De nombreux autres frameworks ne sont apparemment pas compatibles. La liste des outils (in)compatibles reste bien sur à construire (je projette d'ailleurs de faire ma première appli AppEngine sur ce sujet).

Autre restriction, la « base de données » de AppEngine n’est autre que BigTable, l’espace de stockage géantissime de Google – et qui n’a rien à voir avec une base relationnelle. DataNucleus (l’ex JPOX) a été choisi pour fournir aux développeurs une approche JDO ou JPA. Bizarrement, c’est la première qui est mise en avant par les wizards et exemples du SDK. JPox était en effet un outil JDO de premier plan, mais la compatibilité JPA n’en est qu’une surcouche. Autre point, déjà JPA a tendance à nous faire faire des choses « pas très bonne au sens relationnel » car on a tendance à oublier trop facilement la base de données qui se cache derrière. Avec BigTable c’est encore pire, car il ne faut pas envisager de passer par des jointures. Autrement-dit, même API qu’en JEE « traditionnel » mais pas mêmes usages et bonnes pratiques !

Pour ceux qui ne veulent (ou peuvent) pas héberger leurs données en dehors de leur SI, Google propose une API « Secured Data Channel », une sorte de trou de souris dans votre Firewall, sécurisée en SSL, et permettant au « cloud » Google d’accéder à vos données. A priori raisonnable, mais ça sent tout de même le hack ;)

Tout ça fait beaucoup de restrictions me direz-vous. Bien sur, pour déployer sur AppEngine une appli « hello world » cela prend deux clics, et l’infrastructure Google peut alors prendre en charge des pics de charge faramineux sans qu’on ait rien eu à prévoir.

Quel est la cible de AppEngine for Java ? Pas les applications JEE, vu l’inconnue sur le bon fonctionnement des frameworks, et surtout pas en l’état vu la nécessité de repenser la persistance des données. Par contre, tout développeur qui fait du JEE au boulot se retrouve en terrain connu pour déployer son appli perso. Et c’est bien la cible de Google : plus d’applications = plus d’utilisateurs du web = plus de revenus. Vous qui n’arrivez pas à vous mettre à PHP, qui ne pipez rien à python, vous allez pouvoir faire votre petite appli Java avec les outils habituels, avec votre API JPA pour stocker des données, avec GWT 1.6 pour faire de supers applis Ajax sans rien y connaître, et publier tout ça sur le Net pour pas un radis. Et si jamais votre site de vente de schewing-gum usagé explose les scores en raison d’un Buzz incontrôlé, l’infrastructure Google tiendra le choc !

Vous cherchiez une solution de cloud-computing pour votre entreprise ? Attendez que AppEngine se stabilise - ou plutôt, qu’on apprenne à bien l’utiliser et que les frameworks évoluent en conséquence.
Vous cherchez à héberger votre idée de super appli délire que personne y avait pensé avant, AppEngine est pour vous ! Au mieux, vous allez lancer le nouveau YouTube, au pire, dans 2 ans, vous vous vendrez comme expert AppEngine à tous les cabinets de recrutement ;)

Surprise pour moi de ne pas voir dans le package Google Guice. Le marketing de Google ne semble pas chercher à pousser ce framework, cela aurait pourtant été une occasion sans équivalent.

Au passage, je prépare un chtit plugin Maven pour ceux qui ne veulent pas se contenter du plugin Eclipse proposé par Google : http://svn.codehaus.org/mojo/trunk/sandbox/google-app-engine-maven-plugin/

Merci à Didier de m'avoir transmit une invitaton pour cette soirée, qui a soulevé de nombreuses questions et beaucoup d'intérêt ;)

08 avril 2009

Google App Engine passe à Java 6

Après être resté chasse gardée des développeurs Python, Google App Engine passe à la vitesse supérieure en répondant à la demande numéro 1 : supporter Java !

Au programme : Java 6, Servlets, JavaMail, mais aussi JPA pour accéder au DataStore google. Autrement dit, la plateforme de rêve pour héberger nos applications Java / GWT ! Google propose même un plugin pour Eclipse afin de fournir un environnement clé en main.

http://code.google.com/intl/fr/appengine/docs/java/overview.html

Si on arrive à coller un Spring (ou plus probablement un Google Guice) là dessus, on pourra déployer sur App Engine la même application que sur notre serveur JEE :D

Il serait bon que Google s'intéresse plus à la JSR 299, qui portait au départ sur jBoss Seam mais c'est réorientée sur l'injection de dépendance. Elle permettrait de ne pas être lié à un framework particulié dans notre code. Les annotations proposées sont inspirées de Google Guice, autant dire un appel à peine voilé au soutien de Google - qui répond absent pour l'instant - et si celui-ci y va, SpringSource sera plus ou moins obligé de suivre (en tout cas, d'y réfléchir).

Je suis invité chez Google France demain soir pour discuter avec la communauté de cette annonce technologique phare (à moins qu'ils veuillent m'embaucher ?). Plus d'infos très bientôt donc !

03 avril 2009

Maven au Poitou-Charente JUG !

Je serais vendredi prochain à l'inauguration du PoitouCharenteJUG pour y présenter Maven.

http://www.poitoucharentesjug.org/

Si vous êtes de la région, que vous connaissez du monde dans le coin, faites passez le mot car nous avons très peu de temps pour faire connaître ce nouveau JUG et faire venir du monde. Nous comptons beaucoup sur le bouche à oreille, un petit coup de main sera le bienvenu !

30 mars 2009

Fonzie Coding Fryday

Vendredi dernier j'ai voulu sortir un peu de quatre jours à corriger des bugs en série pour réussir à faire passer le projet dans l'intégration continue Hudson. Le temps d'appliquer une correction, deux nouvelles boulettes appraissaient sous Subversion.

Vendredi donc, j'ai voulu faire du codage cool. J'ai donc délaissé mes bugs (ils seront encore là lundi, d'ailleurs ça c'est confirmé) pour me lancer dans un code expérimental : recoder Grails en pur Java. Pour commencer modestement, je me suis contenté de GORM, la couche d'accès à la base de Grails, et plus précisément à son mécanisme de requête sur les entités "domaine".

Pour faire court, si je déclare une méthode User.findByNameOrderByBirthDate(String) à votre avis quelle est la requête passée en JPA ? Le concept "Don't Repeat Yourself" (DRY) consiste à s'obliger à chercher des outils et des conventions intelligentes pour ne pas avoir à coder ce genre de méthodes. Si un esprit raisonnablement tortueux arrive à deviner ce qu'elle fait, un soft bien ficellé devrait pourvoir en faire autant.

En Groovy, Guillaume et sa bande nous font ça les doigts dans le nez. Sans Groovy, j'ai fait appel à AspectJ. C'est un peu moins classe qu'avec Groovy, mais on reste en pur Java - ne jamais changer les habitudes des gens sinon ça fini toujours par vous retomber dessus ;)

C'est donc comme ça qu'est né Fonzie (il est comment Fonzie ? Il est cool !)

J'espère bien répéter l'expérience du Fonzie Coding Fryday (TM) vendredi prochain, ça apporte un bon bol d'air et plein de nouvelles idées.

26 mars 2009

spring-test-context, JPA et dbUnit

Sur ma toute belle appli d'en ce moment que j'adore nous gérons la persistence avec JPA. Comme je suis un grand fan de la testabilité par POJOs (ce qui est super original de nos jours), je préconise d'utiliser spring-test-context pour tester la persistence.

Seulement, j'aime bien aussi utiliser dbUnit pour insérer des données de test prévisibles avant mes tests. Et là ça se complique sérieusement, car il faut passer à dbUnit la connexion JDBC associée à la transaction utilisée par l' EntityManager JPA (vous suivez ?)

Le problème, c'est que spring-test-context ne propose par de méthode listener au sein de la transaction (SPR-4365) ; seulement avant ou après. J'ai donc du étendre le "TransactionalTestExecutionListener" pour ajouter dans beforeTestMethod l'injection des données dbUnit.

La mauvaise surprise, c'est qu'en l'absence d'une indication explicite, Spring utilise un DefaultJpaDialect incapable d'identifier la Connection JDBC utilisée, mais ce n'est pas considéré comme un cas d'erreur donc dbUnit ne partage pas la même connexion :'(

Ajoutez à ça une connexion qui est par défaut en autocommit, des tables Oracle AQ$TRUC qui viennent pourrir les données de test et ça vous donne une idée de mes trois derniers jours :-/

Pour résumer, si vous voulez faire comme moi :

N'oubliez pas de préciser le jpaVendorAdapter (HibernateJpaVendorAdapter) dans la définition Spring de votre entityManagerFactory
Utilisez DataSourceUtils pour récuperer la connexion associée à la transaction JPA en cours

et là, miracle, ça marche enfin :)

Etape suivante : faire un merge à la volée entre les deux persistence.xml qui vont constituer mon contexte JPA (SPR-2598), le permier étant "mutualisé" avec une autre application ...

22 mars 2009

IE6 à l'abris grace à nos DSI

Les dernières stats d'utilisation des navigateurs web sont sans appel : IE6 décline face à IE7 et Firefox3 qui se partagent le marché en 50/50

(http://gs.statcounter.com/)

Ce qui est intéressant ici c'est l'effet "dent de scie" sur la courbe, qui montre que de très nombreux utilisateurs sont contraints d'utiliser IE6 5 jours par semaine, et passent sous FireFox le week-end.

Ca ne vous rappelle rien ? Quel est le navigateur "corporate" installé sur vos postes préconfiguré et labellisé par l'entreprise, recommandé par le service technique et nécessaire pour faire marcher correctement vos applications Intranet ?

Autrement dit, les meilleurs clients de IE6 ce sont ... nos DSI, qui continuent à le conserver frileusement (utilisent-ils FF le week-end ?). Malgré toutes les plaintes des développeurs web, ses soucis de performances et tout ce qu'on pourra lui reprocher, IE6 a encore de beaux jours devant lui : avec la crise-qui-fait-peur aucun DSI ne se lancera dans une migration des postes qui ne rapporte rien à court terme.

Et pourtant, avez-vous estimé le temps perdu à adapter votre appli web pour qu'elle marche sous IE6, alors qu'elle fonctionnait déjà très bien sur à peut près tout le reste ?

18 mars 2009

Big Blue croquera t-il Java ?

Vous l'avez sans doute lu un peu partout, IBM pourrait bien s'offrir SUN. La crise aidant, les cours sont au plus bas et donc les rachats deviennent possible, même les plus innattendus.

IBM a beaucoup misé sur Java, aussi devenir propriétaire de la marque Java TM et de la gouvernance de la plateforme serait assez naturel. On peut s'intéroger sur l'orientation qu'IBM donnerait à Java, mais si on considère le temps pris par SUN pour passer à un modèle ouvert pour son JDK, ça ne peut pas être tellement pire.

Pour le reste, que pourraient bien devenir (Open)Solaris, GlassFish et NetBeans face aux projets directement concurrents d'IBM ?

Passons sur Solaris, dont la base d'utilisateur assure au moins la survie. GlassFish vs Websphere, un match qui aurait pu semblé joué d'avance (je n'ai pas testé GlassFish, mais par contre j'ai déjà suffisement subi Websphere). Netbeans est apprécié de ses utilisateurs, mais l'omniprésent Eclispe - malgré ses défauts - est le bébé d'IBM.

Reste les offres "hard" des deux géants. Je ne suis pas spécialistes mais elles semblent plus concurrentes que complémentaires. Alors, un rachat de SUN signifiera t-il le sabordage d'un pan entier de technologies au profit des produits IBM ?

Allez, on a qu'à dire que tout celà n'est qu'un mauvais poisson d'avril ! Ou encore que Google et Oracle vont fonder une Joint-venture pour racheter SUN les premiers...

13 mars 2009

Grails rocks !

Sur mon projet actuel, d'une taille assez colossale, tout (et même le reste) est configurable, si bien qu'il faut une appli de gestion de la conf qui à elle toute seule est déjà une belle appli web.

Les données de configuration qui sont manipulées sont des entités JPA manipulées ailleurs. J'ai donc fait un essai du côté de Grails, que je n'avais fait qu'éffleurer précédement sans rentrer dans le vif du sujet. En quelques heures, j'ai une appli fonctionnelle pour gérer mes données JPA !

Grails permet de définir son modèle en Groovy mais s'accomode très bien d'un modèle "legacy". Les metadonnées Grails (selon une syntaxe de closure Groovy très compactes) peuvent en effet être déportées dans des classes compagnon suffixées "Constraints". Ma belle entité JPA Habilitation peut donc rester 100% java (Groovy fait encore un peu "geek") sans m'interdire de l'utiliser dans une belle application Grails.

Groovy fait son chemin dans le monde professionnel. Les IDE le supportent de mieux en mieux (même Eclipse s'y met, c'est dire :p), les frameworks et plugins pour Grails se multiplient. Reste à le rendre "acceptable" pour nos décideurs ... et paradoxalement ce n'est pas le plus facile. J'ai donc une astuce : plutôt que de coder en Groovy mon application JEE ultra-stratégique holala faut surtout pas prendre de risque avec un truc de geek, j'intégre le support de la JSR 241. C'est la même chose, je sais, mais bizarement ça ne sonne pas pareil ;)

12 mars 2009

A quoi bon ?

Dans le milieu des "architectes Java" on se targe d'appliquer des patterns, de structurer des architectures et d'offrir des applications flexibles, maintenables et évolutives.

Mais dans la vraie vie, ça donne quoi ?

Des concepts abstraits qui perturbent les nouveaux arrivants, de longues heures de formation sur les design pattenrs qui ne laissent que bien peu de traces dans le code produit, un joli tas de voeux pieux qui n'aboutit à rien de concret, et une belle architecture, plus ou moins bien appliquée, mise à mal au moindre bug un peu bloquant qu'il faut corriger en urgence.

Alors à quoi bon. Après tout, du bon vieux code "Plain Old Spaghetti Code" (POSC, à ne pas confondre avec le code de PORC) est-il vraiment si terrible ? De toute façon, d'ici six mois les besoins auront tellement évolués qu'il faudra tout reprendre et que notre magnifique "modèle objet du domaine" sera bon pour la casse - pardon, pour le "refactoring massif". D'ici un an, deux armées de stagiaires seront passées sur le code et auront massacré votre beau modèle en couche faute d'en comprendre les raffinements si subtils. D'ici deux ans, votre magnifique framework de [mettez-ici-le-pattern-que-vous-voulez] sera totalement obsolète. Alors pourquoi se tirer une balle dans le pied ?

Qu'est ce qu'on trouve à pas cher sur le marché ? Des gens pas très expérimentés qui rivalisent difficilement avec leur homologues indiens. Combien celà coute t-il d'en faire des experts à même de comprendre nos architectures hautement modulaires ? Quel bénéfice au final ?

Pourquoi ne pas considérer officiellement le modèle du code kleenex ? Tout pourri, mal ficelé, à peine fonctionnel, mais ça coute de toute façon moins cher de le refaire "from scratch" à bas cout d'ici deux ans que de le maintenir en l'état.

Quelle valeur ajoutée réelle pour nos belles usines à logiciel, toutes automatisées et bardées de contrôle qualité, si personne n'est au commandes ?

Bref je suis de plus en plus dubitatif. D'un côté je voudrais encore y croire, d'un autre côté la réalité est tellement loin de ce beau modèle de développement que je commence à voir venir le sciècle du "code discount" : pas cher, pas terrible, mais pas cher.

Il me reste donc à aller élever des chêvres dans le Larzac ...

08 mars 2009

Des bugs partout !

Ce week-end j'organisais un "apéro Wii". On m'a donc gentillement prêté deux WiiMotes et un Wii Fit, et bien sur les jeux qui vont avec.

Après les 25 écrans de baratin du jeu Wii Fit on peut enfin faire deux trois mini-jeux rigolos. Autant le capteur est une originalité intéressante pour l'interaction, autant les jeux associés manquent cruellement de "fini". Je veux bien croire que la Wii n'a pas les possibilités 3D d'une PS3 mais tout de même...

Quand à Wii Play... à réserver au plus jeunes qui ont du mal à se servir de la WiiMote. Jeux basiques et graphismes à la limite de l'amateurisme.

A croire que Nintendo ne veut pas mettre la barre trop haut pour ne pas dégouter les développeurs ;p

Restait heureusement les lapins crétins pour me sauver la mise. Evidement, ce n'est pas le même public, mais le style comique et décallé du jeu donne à l'ensemble un style caractéristique bien agréable, très loin de l'aspect "c'est offert avec alors n'en demandez pas trop" des jeux Wii-* d'origine de la console.

Je me suis donc vengé en enchainant les mini-jeux des lapins crétins - les enfants aiment bien voir leur papa se trémousser en rythme devant son écran - avant de tomber sur l'impensable : un bug.

Dans le jeu des "radios sur la plage", on doit cogner sur les lapins (les règles sont assez simple) mais bizarement au bout d'un moment on a beau s'exploser le bras rien ne bouge. Il s'avère que c'est un bug qu'on peut corriger en configurant la Wii sur 60Hz :-/ Mais avant de découvrir ça on passe par une sacré suée à s'énnerver sur sa WiiMote.

Terrible pour un informaticien de voir que les bugs nous poursuivent même en week-end... est-ce que le code des lapins crétins est en opensource ? :D

06 mars 2009

Contribution à la doc gwt 1.6

Les petits gars de GWT, n'utilisant pas Maven, sont confrontés à une armée d'utilisateur qui se casse les dents à faire fontionner ensemble les deux outils. En tant que développeur du plugin Mojo gwt-maven-plugin ils m'ont donc demandé de leur accorder un peu de temps pour écrire une page de doc sur le sujet, à intégrer dans GWT 1.6.

N'hésitez pas à me faire part de vos remarques et à improver my english

http://code.google.com/p/gwtx/wiki/GwtWithMaven

Ils aimeraient bien aussi que le plugin maven soit prêt en même temps que la sortie officielle de GWT 1.6.final, mais on en est malheureusment pas encore là. Vous pouvez néanmoins m'aider dans cette voie en testant le SNAPSHOT et en traquant les anneries qui pourrait trainer dans la doc

http://mojo.codehaus.org/gwt-maven-plugin/

24 février 2009

L'informatique du XXIe siècle

Si vous voulez connaître ma vision de l'informatique du XXIème siècle, un petit tour par la vidéo tournée par JavaBlackBelt lors de l'anniversaire du ParisJug s'impose :

http://vimeo.com/3200894

Au programme : EJB1, datacenter d'Amstrad CPC et Offshoring des bugs