De plus, l’article propose une méthode pour aller vers cet objectif. La méthode proposée et je trouve très interessante, elle propose de définir les domaines à travailler, d’identifier le but de tavailler ce domaine, puis de définir un ensemble d’actions concrètes. Rien de bien nouveau, cependant, j’ai trouvé intéressant la méthode qui est de travailler de manière incrémental, plutôt que de travailler full time un sujet. Mieux vaux travailler un ensemble de sujet et d’itérer dessus pour monter en compétence. Cela donne plus de recul et une meilleure vision d’ensemble. A titre d’exemple, l’année dernière en travaillant Spring,  je travaillais en parallèle les design pattern, le fait de comprendre des design pattern comme le « template » ou le « stategy » m’ont aidé à avoir une meilleure compréhension de Spring et de son utilisation.

Après avoir lu l’article j’ai créé mon propre tableau d’objectif, je vous le livre dans sa version alpha :

Je pense que cela vaut le coup de se définir des objectifs et d’y travailler quotidiennement. En effet, on a malheureusement tendance à ne se focaliser que sur les sujets que l’on connait ou qu’y sont les plus faciles. Or, être expert c’est justement avoir l’esprit ouvert et connaître tous les sujets connexes au sujet maitrisé.

Lorsque l’on atteint un niveau correct dans un domaine on a tendance à s’arrêter sur cet acquis et à ne plus voir le reste. Le schéma ci-dessous que j’ai piqué à Kathy Sierra l’illustre bien :

D’un autre coté, le premier article nous fait bien comprendre que l’on ne peut pas se reposer sur nos employeurs pour nous prendre la main et nous guider vers ce genre d’objectif. Nos buts ne sont pas les mêmes :

Your company expects results from your work: reliable, with minimal mistakes and focused on the company main goal – make money. Your employer could provide minimal training to help you with job requirements. However, your growth will be constrained by company needs, timelines, work assignments and acceptable methods.

En développement logiciel les technologies vont tellement vite que l’on ne peut surtout pas se permettre de se reposer sur une compétence acquise.

Enfin, je terminerai sur cet article, qui nous explique les qualités qui font selon lui un véritable expert  :

• les connaissances
• l’expérience
• des capacités de communications
• un réseau
• la curiosité

Pour y parvenir, il nous propose de travailler sur ces axes :

• travailler continuellement
• pratiquer
• se faire un réseau
• acquérir des capacité de présentation (plutôt au sens marketing, savoir en mettre plein la vue)
• partager son expertise

Rendez-vous dans 2, 3 ans pour voir si la méthode marche

Vendredi dernier Sun organisait une journée de conférences gratuites dans ces locaux rue de Iena à Paris. Pour cette journée, Sun faisait une tournée de ces programmes OpenSources.
Malgré des salles parfois un peu petite, l’organisation était très correcte et le contenu des sessions très intéressant. Avec deux salles en parallèles j’ai porté mon choix sur ces conférences : JavaEE 6, Grizzly Comet, OpenSSO, GlassFish V3 prélude, JavaFx, JavaFx tools, Xwiki, Hudson. Beaucoup de choses intéressantes dont je vais vous faire part ci-dessous.

Présentation du Business Model pour les produits OpenSources Sun

Sun a commencé cette journée par nous présenter son Business Model pour l’OpenSource. Du grand classique, Sun apporte principalement du support, de l’assitance et de la formation pour l’ensemble de ses softs et fournis pour certains cas des distributions commerciales en parallèle de distribution free.
J’y apprend deux/trois infos intéressantes, Sun pense être le premier contributeur OpenSources (au monde ou de ses produits ???) je découvre le logiciel de virtualisation virtualbox (www.virtualbox.org) qui a l’air assez puissant et simple (en plus d’être gratuit).
Parmi les avantages de l’Open Source Sun met en avant une meilleure interopérabilité entre les logiciels, par contre le point sur la sécurité et le nombre de bugs portent plus à débat.
Une petite apparté sur MySQL : Sun pense qu’Oracle est sur utilisé. Parce qu’un gros projet nécessitant des fonctionnalités très avancé choisie Oracle, alors tous le SI devient Oracle. Sun essaye de casser ce schéma en ventant la facilité et la souplesse d’un MySql. Je suis relativement d’accord, reste à convaincre les DSI.

Retour d’expérience par SFR

Cette présentation m’a laissé très dubitative. Certes ce n’était pas le speaker prévu, mais bon je n’ai pas bien compris le message et je n’ai du tout était convaincu.
En gros la personne de chez SFR présentation la migration d’une de leur offre sur une stack « full Sun ». Passer d’un Tomcat, Axis (et je ne sais plus le reste) vers une solution Glassfish + Grizzly + Metro. Pas vraiment de données techniques intéressantes, pas de justification pour ce choix. J’ai juste eu l’impression que le choix a été plus marketing qu’autre chose (on a pris parce que c’était Sun). D’après le speaker Tomcat+Axis supporte mal la scalabilité.
Seul info intéressante : « SFR veux de – en – de produit à licences », ce qui confirme la tendance.

JavaEE6 par Roberto Chinnici (spec leader JavaEE6)

Certainement la présentation la plus intéressante de cette journée. Pour moi qui suivais ça de loin j’y ai appris pas mal de chose sur l’avancement de la specs ainsi que des specs liés.
Tout d’abord Roberto à mis en avant les grands axes de cette nouvelle mouture :

• Facilité d’apprentissage
• Facilité d’utilisation
• Flexibilité

On est clairement dans la continuité de J2EE 5.
Ce qui m’a interpellé par contre c’est : « L’agilité de la plateforme pour interchanger les composants ». En gros c’est de pouvoir rester sur un serveur d’application JavaEE6 mais de pouvoir par exemple rajouter la nouvelle API Servlet 4 lorsqu’elle sortira. Cet axe m’a l’air très intéressant mais je me demande encore comment cela sera mis en œuvre. Roberto pense à la possibilité pour les serveurs d’applications de faire des updates (un peu à la manière de GlassFish qui contient un module d’update). Je trouve ceci très intéressant en tout cas, car le gros problème de J2EE est que l’on est dépendant de la version du serveur d’application choisi par la production. A suivre donc…

Pour les grandes nouveautés on a droit :

Profils

Les profils permettent de découper la norme en sous ensemble cohérent et donc de ne pas devoir implémenter l’énorme stack entière J2EE. Le seul profil pour le moment validé (en plus du profil complet) et le profil web. En gros un clone de tomcat + JSF + JPA + JTA + EJB Lite (+ peut-être JAX-RS et WebBeans).
Il est parlé de profil type portail ou intégration, mais rien d’encore concret à priori.

Elagage

L’élagage permettra enfin aux développeurs de serveurs d’application de ne plus avoir à implémenter de vieilles normes complètement dépassées. Parmi celle-ci on retrouve notamment JAX-RPC, Entity Bean, JAXR, JSR-88. Ces normes seront facultatives et il y aura un marqueur particulier dans la javadoc pour préciser.

Extensibilité

L’extensibilité permettra l’enregistrement automatique de la configuration sans passé forcément par un fichier de configuration du type web.xml. Les servlets, filtres, listener… seront découverts à la volée par le serveur. De plus, les frameworks (style Spring MVC, Struts, etc.) pourront mettre dans leur jar la définition des listeners par exemple (dans META-INF/web-fragments.xml) ainsi le développeur n’aura plus besoin de faire la configuration explicitement.

Nouvelles API

Il nous a été présenté plus en détail les nouveautés de Servlet 3 et des EJB 3.1 mais je me contenterai de vous renvoyer vers d’autres articles en parlant plus précisément.

Nouveau packaging des applications EJB

Il n’y aura plus besoin de créer un jar pour ces EJB que l’on incorpore derrière avec un war dans l’ear. A la place l’EJB pourra se greffer directement dans le war. C’est quand même bien plus simple…
Concernant les EJB j’ai été content d’apprendre que le nommage JNDI serait enfin standardisé. Cela permettra donc de pouvoir créer des applications qui soient totalement portable d’un serveur EJB à un autre (en attendant d’autres problèmes ?).

Grizzly Comet par Jean-François Arcand

http://weblogs.java.net/blog/jfarcand/archive/2008/11/writing_a_twitt.html

OpenSSO par Alain Barbier

Alain Barbier qui est architecte chez Sun nous présentait la problématique du « Single Sign On » et de la fédération d’identité. J’avoue n’être que moyennement intéressé par le sujet et j’ai donc suivi plutôt la présentation des concepts plus que le projet OpenSSO en lui-même.

GlassFish V3 prelude par Alexis Moussine Pouchkine

Alexis Moussine Pouchkine nous a présenté la future version de GlassFish V3 nommé prélude. Cette nouvelle version est une réécriture du noyau de GlassFish basé sur HK2 pour la flexibilité et sur OSGI pour la modularité. Même si certains sont resté sur leur faim j’ai bien aimé la présentation qui démontrait vraiment la légèreté de cette nouvelle version.
Un démarrage très rapide, un rechargement automatique lors de la modification de classe tout en conservant la Session (tout comme Jetty) et enfin pour la grande nouveauté un mode embedded. C’est-à-dire la possibilité de livrer une webApplication tout en y intégrant un GlassFish packagé dedans (Jetty permet déjà de le faire également).
La modularité donné par OSGI est intéressante également, on peut désormais télécharger indépendamment les modules de GlassFish et surtout on peut les loader ou unloader à chaud suivant les besoins.
Pour la partie J2EE GlassFish3 souhaite coller aux dernières avancées et implémente déjà la préversion de JSF2.
Pour conclure, en tant que développeur j’ai été assez séduit par cette version de GlassFish que je vais m’empresser de tester. Alexis promet que cette version est aussi particulièrement pensée pour les équipes de production. Espérons que la mayonnaise prenne.

JavaFx

JavaFx était l’attraction phare de la journée. Sortie la semaine précédente, c’était LE sujet que j’attendais le plus. Voir en live les possibilités visuelles et surtout la facilité à produire du code. Avec 3 speakers arrivant directement de devoxx et une salle pleine à craquer on se languissait de voir la bête.
La première impression fut un peu ratée. En effet, le début de la présentation était axé sur la partie langage de script de javaFx. A première vu ça m’a fait pensé à du Groovy … en moins bien. J’ai bien aimé par contre la notion de bind qui permet de lier une variable au résultat d’une expression. Ce qui a raté c’est le fait que l’on à pas reçu les paillettes que l’on attendait et que les slides était écris en petit en blanc sur fond noir.
Puis vint la deuxième présentation qui était centrée sur l’outillage autour de JavaFx. On nous a principalement montré l’intégration faites avec Netbeans. J’ai trouvé ça assez sympa. La première version a l’air bien abouti bien qu’incomplète. Le mode de simulation qui permet de voir le rendu en tant que client lourd, de page web ou d’émulateur pour mobile est assez sympa. J’ai découvert en passant le profiler de netbeans, super simple à utiliser très sympa.
J’ai bien aimé ensuite l’intégration avec Photoshop ou Illustrator, il suffit de bien séparer en calque puis d’exporter pour JavaFx. Ensuite en JavaFx on manipule les calques. A priori beaucoup plus simple que de manipuler une flopé de sprites.

Xwiki par Thomas Mortagne

Certainement la présentation la plus décevante. J’y suis allé uniquement parce que GlassFish3 m’avait intéressé et que j’espérait en apprendre plus (la présentation s’intitulait « Xwiki et GlassFish »). Au final, je n’ai pas bien compris cette présentation. Il a été présenté les nouveauté de Xwiki (mais je connaissais pas vraiment les anciennes) et l’accent était mis sur les parties techniques notamment l’intégration de velocity, la création d’un langage de requête, …
Au final je suis assez déçu car je n’ai pas compris le but de cette présentation.

Hudson par Vincent Linsolas

En tant que grand fan de l’intégration continu, je me devais d’aller jeter un coup d’œil à cette présentation. D’autant plus, que jusqu’à présentation je n’ai utilisé que CruiseControl et Continuum comme serveur d’intégration continu).
Après une bonne présentation du but de l’intégration continu, Vincent Linsolas nous a présenté en live Hudson. Mon bilan : c’est sexy je veux essayer !
Hudson à l’air facile à installer et à configurer. Tout peux se paramétrer via l’interface (contrairement à CruiseControl avec ces xml et xsl…).
De plus, il est à priori aisé d’étendre Hudson via un système de plugin assez poussé.
J’ai été notamment intéressé par l’existence de nombreux plugin dont Nant et Nunit. Nous avons actuellement ce problème de vouloir utiliser le serveur d’intégration continu à la fois pour un projet Java et pour un projet .Net.
Enfin, cerise sur le gâteau, l’interface GWT est vraiment super bien faites, notamment l’avancement du build qui défile dans une page web, un peu comme si on avait une console DOS ouverte.
Je vous conseille d’y jeter un coup d’œil, notamment ici.

La première présentation de Guillaume Laforge sur Groovy était très intéressante et axée sur le point de vue d’un développeur Java. L’argument majeur que je retiens est que tout code java est lui même du code Groovy (mais pas l’inverse naturellement!). La prise en main est donc très bonne car on écrit du code java au début que l’on groovyse au fur et à mesure que l’on maîtrise les tricks du langage. Je vous épargne les détails ici car Xebia en fait un compte rendu très complet ici. Le seul aspect au final qui me laisse encore perplexe dans Groovy est le faible pouvoir de détection d’erreurs à la compilation. Guillaume Laforge estime que l’aide des IDE (notamment IntelliJ) combiné à un set minimaliste de test unitaire résout le problème, à voir…
La présentation finit par une présentation des DSL (Domain Specific Langage), je ne suis pas persuadé que n’importe quel utilisateurs puissent les utiliser, mais c’est en effet un vrai moyen de se rapprocher de son client et d’essayer de parler la même langue.

La deuxième présentation était une introduction à Grails faites de manière assez ludique. Le point de vue mis en avant (et c’est l’un des atout majeur de Groovy/Grails) était vraiment la productivité. Avec aussi une partie sur le fait que Grails produisent bien une applis standard J2EE (un War). Il est en effet bluffant de voir en 10 minutes tout ce que l’on est capable de produire. Entre une syntaxe très simplifiée (merci Groovy), un boulôt de génération massive pour la BDD et l’IHM (merci Rails) et le fait de pouvoir s’abstenir de redémarrer le serveur d’application, il est clair que la productivité est au rendez-vous. De plus, d’après les retours d’expériences il semblerait que Grails tiennent globalement bien la montée en charge.
A l’issu de cette présentation, j’ai appris que la communauté Groovy était en train de sortir un équivalent de Grails pour Swing, en cherchant un peu je viens de découvrir Griffon. A tester!

Dernier petit bonus de la soirée, j’ai gagné le livre « Filthy rich client » ce qui vraiment cool, merci au ParisJug!

Pour ceux qui n’auraient pas pu participer à la soirée, vous n’avez pas tout perdu car 2 présentations équivalentes sont disponibles, ce sont globalement les mêmes, celles du ParisJug étant justes un poil mise à jour et rallongées.

Présentation de Groovy sur parleys

Présentation de Grails : T18 – Innover sans contraintes, intégrer sans ruptures (s’inscrire gratuitement sur le site de l’université du SI).

• La première est l’utilisation des regex dans l’éditeur « rechercher/remplacer ». Comment peut-on gagner beaucoup de temps et s’éviter un boulot à la con ?
• La seconde est l’utilisation des « tasks » (TODO, FIXME, …). Comment bien les utiliser, comment créer les siennes ?

Astuce 1 : gagnez du temps, utilisez les regex

Il n’y a rien de plus chiant quand l’on code que de faire des séquences répétitives comme par exemple : (appui sur la touche « fin », « ; », « flèche du bas » ) * 20 …

Plutôt que d’effectuer des tâches répétitives, je préfère bien souvent plutôt utiliser le temps que je passe d’habitude à effectuer ceci et ensuite à corriger les erreurs (qui s’insèrent souvent lorsque l’on fait ce genre de chose) par plutôt chercher une expression régulière qui effectuera ce boulôt.

Eclipse propose un support basique mais assez efficace des regex dans l’écran « Rechercher/Remplacer » (raccourci ctr+F). Pour celà, il suffit de cliquer sur la checkbox « Regular Expression ».

La syntaxe est identique aux expressions régulières java : « . » pour tout caractère, « * » pour répéter 0 ou n fois, « () » pour capturer un groupe, « [\w] pour récupérer uniquement les caractères de mots, etc…

Pour récupérer les groupes que l’on a capturé, on utilise dans la partie « replace with » les expressions $1 pour le premier groupe, $2 pour le suivant, etc…

Un petit exemple bateau :

A partir de l’exemple ci dessus, imaginez que l’on veuille vérifier que toutes les variables de classes ne soient pas nulles.

On copie colle la définition des variables dans notre méthode (voir image1).

On recherche l’expression : « Private String ([\w]*) = «  »; »

Que l’on remplace par exemple par : « if($1 != null && !($1).equals(«  »)){}

Ce qui produit comme résultat :

Marvellous!

Astuce 2 : n’oubliez rien, utilisez les tasks

Je suis un fan des TODO/FIXME. C’est à dire que plutôt que d’écrire sur trois milles post-it les choses restant à faire, ou à corriger ou bien d’utiliser l’éternel « Nouveau document texte.txt » posé sur le bureau. Je préfère que tous ces éléments soient directement intégrés dans le code.

La vue des tasks se présente comme suit :

On remarque tout de suite que l’avantage est que les tâches sont localisés à l’endroit ou elle doivent être. Un clic et on s’y rend. De plus, elle sont priorisable (high, normal ou low).

On peut de plus créer ses propres tâches personnalisées. Pour cela, se rendre dans les préférences -> Java -> Compiler -> tasks tags :

Le seul inconvénient, est que l’on sera le seul dans l’équipe à les voir si les autres ne rajoutent pas ces mêmes tâches. Dans l’exemple, j’ai rajouté une tâche NAT avec une priorité haute. J’ai aussi pour habitude de descendre la tâche XXX en priorité faible.

Un autre truc cool avec les tâches est la gestion facile des filtres. Ces filtres ressemblent pas mal à ceux de la vue « Errors » :

Ce qui est intéressant est de placer le filtre sur uniquement la classe ouverte lorsque l’on code (radio « On selected Element Only ») et éventuellement de filter sur les priorités. Quand on veux ensuite faire du refactoring global on enlève ces filtres, pratique!

Bonus :

En petit bonus aujourd’hui, je vous propose cet article que j’ai découvert hier, présentant diverses astuces Eclipse.

Une astuce utile à laquelle je n’avais pas réfléchi et de remplacer dans les templates la génération du try/catch pour insérer dans le catch :

logger.severe(« Exception caught:  » + ${exception_var});

Tout bête, mais pratique.

C’est tout pour aujourd’hui. En espérant vous avoir fait gagner 5 minutes sur votre prochaine journée

| View

Cette Présentation propose une présentation rapide de Spring puis s’attarde plus sur Spring IOC et Spring MVC, les 2 parties qui nous ont le plus intéressé sur notre projet.

Telecharger en PDF.