Depuis que j’ai lancé le blog en 2006, jamais LostInBrittany n’était resté en sommeil aussi longtemps, presque trois mois sans poster. Les raisons ont été multiples et variées, comprenant entre autres un gros dégât des eaux et un déménagement et des projets divers. Je me suis même posé la question de si j’allais continuer, ou si il valait mieux de laisser le blog sombrer dans un état zombie, et me contenter de Twitter et Google+ pour communiquer avec le monde. Mais après des hésitations, j’ai fini par me dire que LostInBrittany était devenu une partie de moi, et qu’il fallait le remettre en route

Et quelle meilleure occasion pour relancer LostInBrittany que la Devoxx 2011 ? Car cette année j’ai à nouveau la chance de pouvoir aller à celle qui est devenue la plus importante conférence Java de l’année (merci Oracle, quand même).

Du point de vue technologique, la Devoxx est une expérience superbe, on prend plein des yeux avec les différents projets, les conférences, les échanges. Mais la Devoxx a aussi un autre intérêt, celui de rencontrer plein de monde, d’échanger avec des gens venant des horizons très divers, unis par une même passion pour le développement.

Et cela nous amène au titre de ce billet, FinistJUG. Car c’est l’année dernière à Devoxx, après avoir beaucoup discuté avec des gens des différents JUGs français, que j’ai décidé de créer Java User Group finistérien, FinistJUG. A l’époque je pensais que cela se ferait rapidement, mais le projet a pris de retard à fur et à mesure que les semaines et les mois passaient. Heureusement que le mois dernier, grâce à un collègue de travail, j’ai rencontré Mik, un architecte Java brestois qui avait un projet semblable de création de JUG à Brest. On a mangé ensembles, on a échangé sur nos projets respectifs et on a décidé de fusionner nos efforts pour réussir à que le FinistJUG devient réalité.

Le projet démarre bien pour le moment : les papiers sont dans la préfecture, on compte faire la prmière session courant décembre, avec un rendez-vous plus informel au retour de Devoxx, la semaine prochaine on présentéra le JUG dans l’Open Coffee de Brest (en visioconférence depuis Anvers), on a un accord de principe avec l’ENIB pour pouvoir faire nos sessions dans leur amphi…

Si vous voulez vous tenir informés, même si je posterai des informations ici, il y a un site web et un compte Twitter.

Formation développement iPhone

J’ai passé la semaine à Paris dans une formation de développement sur iPhone. Etant surtout un développeur Java, je m’était naturellement orienté vers le développement Android, et je n’avais jamais pris le temps de faire des vrais projets pour les téléphones à la pomme. Suite aux différents tutoriels que j’avais fait, j’avais beaucoup d’à prioris sur le développement iPhone, pas toujours positifs. Maintenant, après ces quatre jours de formation, j’ai nuancé un peu plus mon avis.

En effet, même si je continue à trouver l’environnement de développement Xcode inférieur à Eclipse sur la plupart d’aspects, le développement sur iPhone est plus agréable que ce que j’espérais. Même si je continue à trouver les terminaux Apple affreusement fermés et chers, j’avoue qu’ils sont jolis, bien construits, très sexys. Même si je continue à préférer mon Motorola Milestone sur Android, je dois admettre que, en terme d’interface, de fluidité, de bling bling, les iPhones et iPads ont encore une longueur d’avance.

Bref, je pense qu’il va falloir que je passe un peu de temps à essayer de faire quelque chose sur la plateforme iOS…

Paris

Comme chaque fois que je passe quelques jours à Paris, l’un des effets collatéraux du voyage est de me rappeler pourquoi j’aime bien habiter en province. La grande ville est bien pour passer un weekend, quelques jours au plus, mais le métro, la foule et le rythme de vie parisienne ne sont plus faits pour moi…

WordPress 3.1 Reinhardt

Tiens ça fait longtemps que je n’ai pas fait de billet sur WordPress, reprenons donc cette habitude de laquelle mes collègues prennent un plaisir malin à se moquer…

Depuis mardi dernier, une nouvelle version de WordPress est disponible, WordPress 3.1 Reinhardt. Avec cette version, l’évolution de WordPress de simple moteur de blog à un CMS à part entière devient de plus en plus évidente, avec des fonctionnalités comme les types de article personnalisables (jusqu’à présent on n’avait que des billets et des pages) qui permettent de définir de taxonomies complexes. En plus, l’interface d’administration a été revue, avec multitude de petits changements qui rende nt plus simple la gestion du blog : l’interface d’édition des billets a été simplifiée, un nouveau workflow pour la gestion des liens internes, une nouvelle barre d’administration, des nouveaux thèmes…

Pour l’anecdote, suivant l’habitude de WordPress, le nom en code de cette version (Reinhardt) est un hommage à un musicien de jazz, dans ce cas le franco-belge Django Reinhardt, l’un des créateurs du jazz manouche.

Narizones

Le weekend dernier, avant de partir à Paris, j’ai eu le temps d’avancer la peinture des dernières figurines imprimées en 3D que j’avais reçu de Shapeways en fin de l’année dernière. Voici quelques photos de ces narizones :

Je suis assez content du rendu de la peinture sur ces petits narizones, même si la texture rugueuse résultante de l’impression 3D demande du boulot de préparation plus importante qu’une miniature classique.

Comme je vous disais dans mon dernier billet, cette semaine je suis allé à Devoxx à Anvers, le rendez-vous incontournable de la communauté Java européenne, auquel cette année se son joindre aussi beaucoup de participants outre-atlantiques, peut être déçus par la nouvelle version de Java One.

L’expérience était bien enrichissante. J’ai découvert des choses, j’ai comparé ce qui se fait ailleurs, j’ai discuté avec beaucoup de monde, bref j’ai passé cinq jours en immersion avec 3000 développeurs Java, du pur bonheur. Je suis revenu avec des idées et des projets pleine la tête, et avec une envie folle de mettre des idées en pratique, de faire avancer des choses, de partager mon enthousiasme.

Les sujets phare dans la Devoxx de cette année ont été :

• NoSQL et cloud computing: une bonne douzaine de sessions sur ces thèmes, avec des sessions sur Hadoop, HBase, Pig & Hive, MongoDB, Cassandra, Voldemort, la mouvance DevOps… C’est la partie que j’ai trouvé la plus intéressante, où je considère que j’ai appris le plus de choses.

• Les langages alternatives tournant sur la JVM (Scala, Groovy, Fantom…) et les différentes frameworks (GWT, Wicket, Play!, Grails…)
• Le futur de Java, le JDK 7 et ce qu’on pourrait attendre du JDK 8.
• Android, avec plusieurs sessions centrées sur la plate-forme et le développement d’applications tirant profit des capacités des derniers modèles.
• JavaFX, qui après compte il n’est pas peut-être né mort comme on le pensait…

Je comptais faire des résumés journalier sur le blog, un peu comme j’avais fait pour JavaOne 2008, en prenant des notes pendant les différentes sessions de la conférence, et en mettant les photos sur Flickr le soir. Mais c’était sans compter avec Twitter, mon Android et l’excellente connexion WiFi que les organisateurs avaient mis à notre disposition. Du coup, j’ai préféré twitter chaque session à laquelle j’ai assisté, pour remonter l’information d’une façon plus directe et plus rapide qu’en prenant les notes pour bloguer le soir.

Ce curieux comment Twitter a changé la façon comme on vit les conférences. Au JavaOne 2008, Twitter existait déjà (par exemple, mon compte a été créé le 23 mai 2007), mais son usage était loin d’être aussi généralisé que à l’heure actuelle.

Maintenant, avec Twitter plus l’adoption massive des smartphones¹, le live-twitting est devenu une pratique standard et omniprésente, au point que pendant les pauses entre deux sessions, l’écran géant de chaque salle montrait un mur de tweets dans lequel il s’affichaient en temps réel les tweets avec le l’étiquette #devoxx. De cette façons, tout en suivant chacune des sessions auxquelles j’assistais, je twittais ce qui me semblait le plus intéressante, en accompagnant les tweets avec des photos prises avec mon téléphone². Au même temps, en lissant les messages twittés sur #devoxx, j’ai plus ou moins suivi en temps réel les points clés des différentes sessions qui se déroulaient en parallèle. Avec ça, la conférence était encore plus intéressante, même si assez fatigante, car suivre des conférences en anglais, le tout en twittant et en lissant des twitters sans perdre le fil de la session demandait pas mal de concentration.

Maintenant j’ai commencé à réunir mes tweets et mes notes, et à essayer de mettre ça en forme pour pouvoir faire un compte-rendu cohérent au travail, et essayer de voir ce qui peut être mis en application des maintenant, ce qu’il faut tester, et comment peut-on tirer les bonnes leçons de ce que j’ai vu et entendu à Devoxx. Mais cela est une autre histoire…

¹ Le taux d’adoption des smartphones parmi les assistants à Devoxx était simplement impressionnant. Lors d’une session, le speaker a posé directement la question, et il n’y avait pas une dizaine de personnes sans smartphone dans la salle. Curieusement, ou pas trop étant donné qu’il s’agisait d’une conférence de développeurs Java, les téléphones Android étaient prédominants.

² Les photos prises avec mon Android ont été toutes ratées, avec une résolution bien trop petite pour être exploitable. Je n’ai pas encore trouvé le pourquoi, quoi que je soupçonne la version beta d’Android 2.2 que j’ai flashé sur mon Motorola Milestone il y a une quinzaine de jours. De fois je me dis que je devrais arrêté de jouer avec des betas… mais je m’ennuierais sinon.

La semaine prochaine je serai à Anvers, pour Devoxx 2010, conférence qui grâce à Oracle est devenue le plus important rendez-vous de l’année dans le monde de Java.

Je pars donc dimanche matin vers Anvers, et je reviens vendredi prochain. J’espère avoir le temps d’écrire quelques billets en racontant la conf au jour le jour, mais ce qui est sûr c’est que je vais live-twitter mon séjour, avec le hashtag #devoxx.

En autre ordre de choses, Oracle persiste dans son attitude méprisable vis à vis de la communauté de logiciel libre autour de Java. Avec leurs actions, ils montrent soit une effroyable méconnaissance de l’écosystème Java et du logiciel libre en général, soit ce qui serait pire, une volonté acharnée de saborder le langage et la plate-forme même. Le dernier exemple, pas plus tard que mardi dernier, l’annonce de la future sortie de plusieurs versions de la machine virtuelle Java, afin de monétiser la JVM.

Afin de me joindre donc aux voix qui réclament que Oracle change d’attitude vis à vis de Java, je vais donc me suivre l’appel de James Gosling et porter pendant la conférence un t-shirt Java doit être libre. Sauf que à la place du Duke inspiré de celui de Gosling que j’avais préparé la dernière fois, cette fois je me suis amusé un peu avec Blender et j’ai préparé un Duke en 3D.

Avec du papier transfert et un fer à repasser (que je n’utilise que dans des occasions spéciales comme celle-ci), j’ai maintenant deux beaux t-shirts pour Devoxx 2010 !

Si vous travaillez de près ou de loin avec le langage Java, vous êtes sûrement au courant du feuilleton politico-juridico-technologique autour du langage depuis l’acquisition de Sun parOracle l’année dernière.

L’un des premiers chapitres était le départ de James Gosling, le concepteur de Java. Après, les actions d’Oracle autour de Java sont devenus de moins en moins claires, de il y a eu le procès contre Google sur l’utilisation de la JVM sur la plate-forme Android.

En réponse, Google a annoncé que ils n’iront pas à JavaOne. Cette absence est très symbolique, compte tenu que beaucoup d’anciens employés de Sun, parmi lesquels des grands noms de Java comme Joshua Bloch travaillent à présent sur Google. Mais lorsqu’on sait que James Gosling ne sera pas là non plus, on voit à quelle point Oracle a réussi à se couper du noyau dur des développeurs du langage.

Les actions d’Oracle sont vues par beaucoup de développeurs Java comme une attaque contre la communauté de logiciel libre autour de Java. Lundi dernier, James Gosling a posté sur son blog un billet en proposant un t-shirt à porter lors du prochain JavaOne, pour rappeler à Oracle ses engagements de libérer Java.

Pour apporter ma petite pierre au bâtiment, j’ai fait une version française du motif du t-shirt :

Je n’ai pas retouché le dessin de Mr Gosling, je suis parti de zéro avec Inkscape. Cependant, le dessin est sont idée, il est donc propriétaire, et s’il me demande de retirer ma version je le ferai sans hésitation.

Je compte me faire un t-shirt à titre personnel, et si Mr. Gosling m’autorise, je vais le proposer aussi en t-shirt sur Comboutique et Spreadshirt. A prix coûtant bien entendu (pas question de faire un bénéfice quelconque sur ça).

Mise à jour

Suite à des suggestions reçues par mail, j’ai changé sur le dessin la phrase Faites Oracle tenir parole par Incitez Oracle à tenir parole.

Compatibilité ascendante et descendante

L’un des avantages de Java lorsqu’on doit entretenir un parc applicatif étendu c’est la compatibilité ascendante de la machine virtuelle Java.

En effet, à quelques exceptions près, un code Java compilé en 1999 avec le JDK 1.1 marche aujourd’hui lorsqu’on l’exécute avec une JVM 1.6. Par contre, l’inverse n’est pas vrai, la machine virtuelle Java n’assure pas une compatibilité descendante, i.e. une classe compilée pour la JVM 1.6 ne s’exécuterait pas sur une JVM 1.5.

Normalement cela n’est pas un problème… sauf quand on doit impérativement exécuter un code dans une ancienne version de la machine virtuelle. Dans ce cas là, on a intérêt à s’assurer que le code a été compilé pour cette JVM (ou pour une JVM plus ancienne) avant d’essayer de l’exécuter.

Comment peut-on donc savoir la version de la JVM utilisée comme cible de la compilation une classe Java ?

Pour garantir que les applications Java puissent d’exécuter à l’identique sur les différents plateformes, les fichiers .class ont un format figé. De cette façon, lorsqu’on compile du Java sur n’importe quel plateforme, on obtient les mêmes fichiers .class.

Les fichiers .class ont donc une structure fixe, ils sont découpés en dix sections (certaines à taille variable), et c’est dans la deuxième section qu’on va trouver la réponse à notre question.

La première section, c’est le magic_number. Ce paramètre, codé sur 4 octets, permet à la JVM de reconnaître le fichier comme une classe Java. Le valeur de ce magic_number est 0xCA 0xFE 0xBA 0xBE (CAFEBABE).

Les 4 octets suivantes définissent la version de la JVM utilisée comme cible de la compilation. Les deux premiers octets sont la version mineure (normalement 0) et les deux suivants indiquent la version majeure. C’est cette version majeure qui donne donc la réponse à notre question :

Pour voir donc la version de la JVM utilisée comme cible lors de la compilation d’une classe, il suffit d’ouvrir la classe avec un éditeur hexadécimal (moi j’utilise la commande hexdump -C) et regarder le début du fichier, qui sera de la forme CA FE BA BE 00 00 00 XX où XX indique la version.

Par exemple, pour une classe compilée pour JVM 1.5 on aurait CA FE BA BE 00 00 00 31

Merci à Mathias de m’avoir mis sur la piste. Ce soir je me coucherai moins bête…

En regardant les logs dans eclipse/.metadata/.log, j’ai vu que au moment de la construction de l’interface, Eclipse tombait en erreur :

Après avoir regardé un peu à droite et à gauche, il se trouve que cette erreur est due à des problèmes avec XulRunner, l’environnement d’exécution d’applications XUL utilisé par Eclipse pour son interface.

J’ai actuellement trois versions de XulRunner installées sur ma machine : XulRunner 1.9.0 (correspondant en gros à Firefox 3.0), XulRunner 1.9.1 (correspondant à Firefox 3.5) et XulRunner 1.9.2 alpha (qui serait celle qui correspond à Firefox 3.6 alpha). En faisant xulrunner -version, j’ai vérifié que la version de XulRunner utilisée par défaut est la 1.9.1.

Apparemment, XulRunner 1.9.1 casse la compatibilité des binaires compilés pour XulRunner 1.9.0, dont Eclipse 3.4. J’ai donc modifié le fichier eclipse/eclipse.ini en ajoutant le path de mon XulRunner 1.9.0 :

Et le problème a disparu. Reste à savoir pourquoi le problème est apparu d’un coup ce matin, car j’ai XulRunner 1.9.1 installé depuis des mois, mais cela est une autre histoire…

Après l’humour geek, revenons à un billet un peu plus technique…

Je l’ai dit souvent, et je le répète, internet arrivera toujours à me surprendre.

Hier je discutais avec de collègues sur comment faire communiquer un script shell avec une application web en Java sur l’intranet. La solution la plus simple était sans doute de faire un point d’entrée sur l’application Java, une petite servlet à laquelle on appellerait depuis le script shell via wget ou curl.

Quelqu’un a suggéré, à moitié en blaguant, d’implémenter la communication sur la forme d’un vrai web service (WS) en SOAP, avec son WSDL et tout. Je ne vais pas rentrer dans les avantages ou les inconvénients des WS en SOAP vs une approche REST, car c’est un peu philosophique comme débat. Il suffit de dire que pour ce petit besoin c’était un peu exagéré de devoir implémenter un WS SOAP, et on est donc partie sur l’approche REST avec une simple appelle sur l’URL de la servlet.

Ce matin le sujet est revenu dans la conversation et je me suis mis à penser comment on aurait pu faire si on avait eu vraiment besoin d’utiliser des WS complexes, avec SOAP, sécurité, cryptage…. Dans ma tête il aurait fallu développer le client WS à part, en Java par exemple, et appeler ce client depuis mon script shell.

Et là, je me suis dit qu’à coup sûr il y aurait quelqu’un sur le net qui a implémenté un client WS SOAP fait pour être appelé depuis en ligne de commandes, une sorte de wget pour des appels webservice. Un passage rapide par Google m’a permit de confirmer mon intuition, il y en a bien des implémentations de clients SOAP utilisables depuis un script shell !

Je suis allé donc voir WSF/C, un framework pour des WS écrit en C standard, compatible avec les implémentations Apache WS-* (dont Axis2). Ce framework inclut un client WS en ligne de commandes, wsclient, que on peu utiliser d’une façon semblable à wget ou curl.

L’implémentation est assez complète, pouvant supporter des différentes schémas d’authentification et cryptage. Le programme se pilote depuis la ligne de commandes, d’une façon assez simple pour ceux habitués à utiliser des programmes sur le shell.

Par exemple, pour appeler les WS Amazon, il suffit de faire :

où item_search.xml est un fichier XML respectant le format SOAP des WS Amazon. Par exemple :

Est-ce que c'est utile ? Peut-être pas pour une utilisation quotidienne, mais lorsqu'on veut faire des tests sur un serveur n'ayant pas d'interface graphique (ne pouvant donc pas utiliser des outils telles que SoapUI), c'est une façon beaucoup plus rapide, simple et sympa que devoir tout faire avec curl ou devoir programmer un client Java pour le faire.

Bref, un petit outil curieux pour garder sous la main au cas où on pourrait en avoir besoin...

En septembre dernier j’ai commencé à préparer la certification SCJP (Sun Certified Java Programmer), avec l’idée de qu’elle soit une première étape dans la chaîne des certifications Sun, suivie par d’autres certifications jusqu’à éventuellement culminer dans la SCEA (Sun Certified Enterprise Architect).

Après avoir passé la certification SCJP en novembre, je m’étais donc engagé dans la phase suivante, la préparation de la SCWCD (Sun Certified Web Component Developer).

Mon manque de temps de ces derniers mois, et le conséquent ralentissement du blog, ont fait que je n’ai pas parlé de la préparation de cette certification comme j’avais fait avec la précédente.

J’ai donc passé l’examen mardi dernier, à Rennes cette fois, et je l’ai obtenu ma certification SCWCD avec 84% de bonnes réponses.

Comme pour la dernière fois, les derniers jours de préparation ont été assez intenses, sauf qu’à différence de la dernière fois, je n’ai pas pu encore trop me reposer, car j’ai une semaine assez chargé au travail. Vivement le week-end !

Avant de finir le billet, je tiens à féliciter mon collègue Raphaël, qui a aussi obtenu sa SCWCD avec un très remarquable score de 97% !

Je vous ai souvent parlé ces dernières semaines de ma préparation pour la SCJP, et je vous ai raconté comment j’avais du mal à me mettre dans une logique d’étude semblable à celle que j’avais en école d’ingénieurs.

Le passage de la SCJP était une première étape dans la chaîne des certifications Sun, qui devait se suivre par d’autres certifications jusqu’à éventuellement culminer dans la SCEA (Sun Certified Enterprise Architect). A priori j’avais pensais faire une pause après la SCJP et commencer à préparer la certification suivante en début d’année, question de ne pas me mettre de la pression. Mais après le succès à la SCJP je me suis dit qu’il me fallait profiter de m’être enfin mis dans une démarche d’étude régulier, et que si je m’arrêtais un mois et demi j’allais ensuite avoir encore du mal à m’y remettre.

En conséquence, en fin de semaine dernière j’ai commandé le bouquin pour la SCWCD, Head First Servlets & JSP. Je l’ai reçu lundi dernière, et j’ai commencé de suite à le lire.

Etant donné que ça fait quelques années que les applications web Java sont une partie centrale de mes activités professionnelles, pour l’instant tout me semble connu. Mais avec la SCJP j’ai appris à me méfier, car il y a plein de petits détails qui peuvent s’avérer problématiques dans l’examen, même pour un développeur chevronné.

Maintenant il me faut réfléchir pour la date…