new Blog( perso );

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Microsoft publie le positionnement de IE9 sur le blog MSDN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mvn clean install -Dmaven.test.skip=true

sur le HD “classique” :

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

sur le RamDisk :

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

 

Reste à voir ce que ça donne sous Eclipse …

Autres pistes à creuser :

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

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

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

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

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

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

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

Voici donc pour info la procédure à suivre :

1- installer Ubuntu server 64 (sans blague ?)

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

3- ajouter les paquet bc et libc6-i386

$ sudo apt-get install bc libc6-i386

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

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

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

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

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

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

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

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

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

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

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

$ sqlplus /nolog

CONNECT SYS/password AS SYSDBA

EXEC DBMS_XDB.SETLISTENERLOCALACCESS(FALSE);

EXEC DBMS_XDB.SETHTTPPORT(‘8081’);

 

et voilà ! :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

Arnaud a (enfin) trouvé notre bouquin dans les rayons de la FNAC. On sera un peu surpris par la catégorie dans laquelle il a été mis, mais au moins il est dispo en vrai cette fois ;)

Le projet Mojo publie ce week-end les signatures des diverses JRE, à utiliser avec le plugin animal-sniffer.

Kezako-qu’est-ce-donc ?

Animal Sniffer est un outil que l’on doit à Kosuke Kawaguchi, également créateur de Hudson et développeur chez SUN de JAXB et JAX-WS, enfin un gars bien occupé quoi. L’objectif de ce truc au nom improbable est de vérifier qu’un programme Java utilise uniquement des API qui seront disponibles au runtime.

 

Comme le compilateur javac vous autorise à cibler une JRE (option target) différente de celle qui compile, il n’est pas exclu d’utiliser des classes ou méthodes qui ne seront pas fournies par le runtime – gloups. Animal Sniffer va donc contrôler tout ça pour nous. On peut donc vérifier qu’on utilise pas de méthodes spécifiques au runtime Java6 en utilisant le compilo JDK6 et en ciblant Java 5 !

Mais animal Sniffer peut aller plus loin, car en pratique chaque JRE a ses petites extensions. Il est par exemple bien tentant d’utiliser la classe com.sun.binary.Base64, ce qui posera bien évidement quelques soucis si le runtime est un JRockit ou un IBM JDK !

Le projet Mojo est donc en train de nous publier les signatures de toutes les JRE, IBM JDK et Apache Harmony comprises, dans les versions courantes (1.3, 1.4, 5, 6).

Dans le même esprit, pour le développement d’un plugin Google App Engine sur Mojo (délaissé depuis, manque de temps et %#@! de SDK – contributions are welcome), j’ai utilisé animal sniffer et une signature spécifique pour valider la non-utilisation des API du JRE qui ne sont pas supportées sur cet environnement un peu particulier.

Super, mais encore ?

Prenons un instant pour nous intéresser au JDK7, “OpenJDK”. Contrairement aux précédentes version de Java, il n’est pas piloté par une JSR bien cadrée, mais vit sa vie en opensource, avec ce que ça implique d’innovations, mais aussi de conflits divers et de retards – encore 6 mois dans la vue :)

Alors qu’on pouvait en principe se baser sur la JSR Java6 pour définir les API accessibles, que fera t-on avec les implémentations de Java7 autres que OpenJDK ? Bien sur, elles sont sensées être compatibles, mais comment définir si un élément d’OpenJDK est une implémentation spécifique ou bien un élément officiel de la plateforme ?

Animal Sniffer pourra répondre à cela : en validant l’utilisation exclusive des API de l’environnement cible, il nous évitera un NoSuchMethodError qui fait bien mal sur le serveur de production.