new Blog( perso );

23 juillet 2009

spam attack

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

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

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

m2eclipse - avec modération

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

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

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

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

java.lang.NullPointerException

at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(

Ca peut aussi prendre des formes plus amusantes :

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

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

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

16 juillet 2009

ie8 est là

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

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

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

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

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

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

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

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

03 juillet 2009

10 jours offline

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

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

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

update 14/07 :

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

Le BreizhJUG en vacances

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

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

02 juillet 2009

Le BreizhJUG fait son cinéma

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

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

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

Passez le mot :)

25 juin 2009

Laser Saber Extreme Feedback Device (TM)

Ca le fait, non ?

assembly mon amour...

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

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

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

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

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


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

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

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

D:\projets\xx>mvn -f pom-assembly.xml

[INFO] Scanning for projects...

[INFO] Reactor build order:

[INFO] xx parent

[INFO] xx :: Composants GWT

[INFO] xx :: configuration

[INFO] xx :: infrastructure

[INFO] xx :: wsdl

[INFO] xx :: modele

[INFO] xx :: services

[INFO] xx :: persistance

[INFO] xx :: ordonnanceur

[INFO] xx :: services web

[INFO] xx :: batchs

[INFO] xx :: simulateurs

[INFO] xx :: ear

[INFO] xx :: tests d'intÚgration

[INFO] xx :: assembly

[INFO] -----------------------------------------------

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

24 juin 2009

Saber light extreme feedback device

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

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

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

Le monde méconnu de la sécurité

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

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

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

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

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

Tiens, une idée pour le prochain concours de développement sur Androïd :

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

13 juin 2009

extrem feedback device

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

Le contexte :

un bon gros projet (50 personnes * 16 mois),
un approche "V" pas du tout agile (déjà plus d'un an de conception dans les pattes), ce qui n'interdit pas d'emprunter aux méthodes modernes quelques bonnes pratiques,
une équipe hétéroclite, avec de nombreux "juniors", regroupés dans 5 équipes par couche technique - sensées collaborer ;) - et des buils Hudson FAILED à tour de bras.

Actuellement, certains ont bien pris possession du concept d'intégration continue et suive régulièrement l'état d'Hudson. D'autres par contre semblent peu s'en préocuper et sont dans un esprit "chacun sa m..", ce qui se traduit par des commits qui cassent le projet sans que personne ne réagisse.

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

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

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

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

1er soucis

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

- le soft qui va bien pour écrire byte par byte sur le port parallèle en Java

- le soft qui va bien pour un accès exclusif sous windows

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

Une fois cette formalité remplie et les premier regards amusés des collègues, on sort le fer à souder. Liste de courses :

un vieux cable d'imprimante "centronics" (comme quoi faut jamais rien jeter)
quelques composants électroniques (~20€)
trois ralonges (pour pouvoir placer les lampes à qq mètres de mon bureau),
une boîte tupperware pour mettre tout ça à l'abris - c'est tout de même du 220v, faut pas déconner.

Le montage n'a rien de bien compliqué, mais comme mes cours d'électronique sont un peu loin je me suis reposé sur ce plan. Si vous comptez allimenter un transfo ou un moteur (typiquement un gyrophare 12v) faites gaffe, ce n'est pas exactement le même schéma.

2ème soucis

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

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

3ème soucis

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

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

Pour les "signaux visuels" vous pouvez ressortir ces blocs-spots octogonaux en plastique qu'on a tous achetés un jour pour animer une boum - ça peut vous faire un joli feu de signalisation. Moi, j'ai fait une petite folie :

trois tubes néons de couleur bleu/jaune/rouge (19€ chez alinea)
un gyrophare rouge pour venir épauler le tube rouge (16€)

et voilà le résultat en action :

Le "Laser Saber Extreme Feedback Devive (TM)"

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

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

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

09 juin 2009

Pour une meilleure utilisation d'Eclipse

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

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

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

03 juin 2009

Sun, Oracle, OpenJDK et Java payant ?

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

Exemple concret : le nouveau Garbage collector "G1", dont les performances sont encourageantes pour ce qui en a déjà été présenté (même si on présente rarement de mauvais résultats). Un petit tour par la release-note :

"Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. G1 is supported thru Sun's Java Platform Standard Edition for Business program."

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

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

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

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

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

02 juin 2009

Maven bouge dans le bon sens

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

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

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

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

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

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

01 juin 2009

container's hell

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

NoSuchMethodError

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

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

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

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

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

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

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

29 mai 2009

Google surfe sur la Wave

Pour ceux qui ont suivi l'émergence de HTML5, les navigateurs modernes vont permettre de développer des applications nettement plus riches, basées sur un canevas graphique complet et un modèle de communication complètement débridé (très loin de deux connexions HTTP que l'on a héritées de Mosaïc).

Google suit (anticipe ?) le mouvement en présentant Google Wave, qui se présente comme "ce que seraient le mail et la messagerie instantanée si on les avait inventés aujourd'hui". Ça parait flou ? Explication, basée sur la démo présentée au Google IO :

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

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

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

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

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

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

[mon voyant me prédit l'avenir:ON]

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

[mon voyant me prédit l'avenir:OFF]

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

Quand on vous dit que la révolution du web est en marche...

28 mai 2009

Continuum vs Bamboo vs Hudson

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

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

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

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

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

26 mai 2009

Maven, Eclipse et GWT main dans la main

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

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

Comme je l'explique sur cette page, la principale difficulté est que le plugin Google Eclipse n'est pas très "maven compliant" et oblige à faire quelques concessions. Cependant, avec l'aide de m2eclipse (ça doit aussi marcher avec IAM, je n'ai pas encore testé) on obtient le résultat suivant, que vous pouvez expérimenter à la maison en utilisant le projet de test it/reactor du plugin, ou sur votre propre projet (dites moi ce que ça donne) :

import du projet Maven sous Eclipse par m2eclipse. Les dépendances, répertoires de sources et de génération de code sont identifiées et configurés sous Eclipse, et surtout lesmodules d'un multi-projet et dépendances présentes dans le workspace sont "résolues" en tant que références inter-projet et non via les jars du repository local.
ajout du support GWT (étape encore manuelle, j'y travaille) via Google Eclipse Plugin. Soucis ici, le plugin ajoute lui même les dépendances GWT qui font donc doublon avec celles gérées par m2eclipse. Ca n'a pas l'air gênant à condition bien sûr que les versions soient cohérentes. Si quelqu'un à une astuce je prend ;)
génération des lanceurs pour les modules de l'application en lançant mvn gwt:eclipse. Cette tâche gère désormais aussi bien les lanceurs "classiques" et ceux exploitant le plugin Google Eclipse (cas par défaut). Au passage, le plugin prépare le répertoire /war du mode hosté.
un simple run as > web application sur le lanceur généré et le mode hosté démarre. L'URL de la page web hôte n'étant pas déclarée dans le fichier module, j'ai pris comme convention qu'elle porte le même nom que le module et est présente dans son répertoire public. C'est un peu limitatif mais ça doit être assez courant. Sinon il suffit d'éditer la configuration d'exécution.

Le gros progrès (en terme de confort et de productivité) c'est que si votre application est découpée en modules maven, une modification dans le code source d'un de ces modules sera directement exploitable dans le navigateur hosté par un simple refresh. Pas besoin de repackager un Jar ou tout autre manipulation - perte de temps.

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

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

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

18 mai 2009

m2eclipse vs IAM ? Non m2eclipse + IAM

Lorsque la fondation Eclipse a annoncé accepter deux plugins concurrents et assez semblables dans son incubateur on pouvait se poser la question : qui va survivre à la course à l'investiture ?

On aurait pu penser que Eclispe serve de "sélection" pour un unique plugin et encourage le perdant à coopérer, mais il n'en est rien. La fondation a d'ailleurs joué le même tour à Sublcipse / Subversive.

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

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

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

Un peu d'optimisme fait du bien :D

15 mai 2009

m2eclipse vs IAM (q4e)

Après avoir publiquement rennoncé à Archiva pour Nexus on pourrait me croire vendu à Sonatype ... et bien non. Utilisateur de m2eclipse je teste actuellement la dernière mouture de eclipse-iam (aka "q4e") et je le trouve bluffant !

le build maven est nettement mieux intégré.

Contrairement à m2eclipse, IAM utilise maven 3 exclusivement, ce qui peut paraître gênant à priori mais lui donne la liberté d'une vraie intégration dans Eclipse et sa gestion événementielle. La progression d'un build indique ainsi le démarrage des Mojos et les tâches accomplies.

moins de builds inutiles

L'éditeur de POM est assez intelligent pour ne pas lancer un build "pour rien" lorsque l'édition réalisée n'a aucun impact. Je râle assez souvent sur m2eclipse qui me fait des builds en série pour pas grand chose, et je finis souvent par désactiver le "build automatically".

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