31 juillet 2009

35 ans, presque mort...

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

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

30 juillet 2009

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

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

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

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

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

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

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

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

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

0 commentaires
Libellés : ,

28 juillet 2009

Maven et Hudson main dans la main


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

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

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


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

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

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

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

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

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.
2 commentaires

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.

0 commentaires
Libellés :

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
0 commentaires

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 ?"



1 commentaires

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 :

0 commentaires

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 :)
0 commentaires

25 juin 2009

Laser Saber Extreme Feedback Device (TM)


Ca le fait, non ?
1 commentaires

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
2 commentaires
Libellés :

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 :)
0 commentaires

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"
0 commentaires
Libellés :

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 ;)
1 commentaires
Libellés : ,

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

4 commentaires

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 ;)
2 commentaires

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 ;)
0 commentaires
Libellés :

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.
1 commentaires

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...

3 commentaires
Inscription à : Articles (Atom)