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.

Au menu:

• Which style of WSDL should I use?
• JSF: the good, the bad and the ugly…
• Eclipse et mylyn, pour une gestion efficace des bugs et des tâches d’un projet de développement
• SpringSource Tool Suite Released
• Activer un aspect par JMX
• Build time vs. render time
• Choose your managers wisely; they have cookies on the dark side
• Software Architecture Document Guidelines

Which style of WSDL should I use?

Cet article n’est pas tout récent, contrairement aux autres. Cependant, si je vous le propose c’est parce qu’il est très intéressant et très didactique.
Il résume la problématique RPC vs Document et Literal vs Encoded. Cette problématique est toujours d’actualité et ne semble pas forcement résolu, comme par exemple chez mon client, où j’ai du me frotter aux urbanistes à ce sujet.
Pour résumé : RPC/Encoded c’est très mal car très lourd, Document/Literal c’est pas terrible car trop léger et les outils ont du mal à s’y retrouver (c’est le cas d’Axis). Enfin, les deux solutions cohérentes sont RPC/Literal et surtout Document/Literal « wrapped ».

JSF: the good, the bad and the ugly…

Un bref retour d’expérience sur JSF qui illustre bien ce que j’ai pu lire par ailleurs.
En résumé : Pour les plus on a : les managed beans, le support d’AJAX via java et taglib et sans horrible JavaScript, et l’aspect composants.
Pour les moins : un manque de support IDE, la bookmarkabilité des pages impossible de base, la difficulté d’utiliser le scope request, la création de composants personnalisés très obscure.

Eclipse et mylyn, pour une gestion efficace des bugs et des tâches d’un projet de développement

Une brève présentation des fonctionnalités de Mylin, un des projets les plus en vogue d’Eclipse.

Le but de Mylyn est de proposer une interface visuelle destinée à faciliter le traitement de tâches et de bugs directement au sein d’Eclipse. Ceci bien évidemment dans un but de gain de temps, d’efficacité et de synergie entre les outils.
Mylyn n’est pas un gestionnaire de bug, il s’agit d’une interface visuelle entre Eclipse et votre gestionnaire de bugs. Le choix de ce dernier repose donc toujours sur les besoins de cette gestion et les outils disponibles sur le marché.
Mylyn propose un connecteur générique pour n’importe quel outil de suivi mais s’intègre particulièrement bien avec Bugzilla, Trac et JIRA.
L’intérêt ? Disposer dans Eclipse des tâches et des bugs pour faciliter et automatiser les traitements.

SpringSource Tool Suite Released

SpringSource essaye de développer le support de Spring dans Eclipse. Elle a sortie cette semaine la bêta de « Spring Tool Suite », un ensemble d’outils Eclipse.
SpringSource précise bien que cet outil n’a pas la vocation de remplacer le projet SpringIDE.

So lets see what we got:
• Spring Development Tools
• Mylyn’s Task-Focused User Interface for Java, Resources and Spring application blueprints
• Task-Focused Tutorials
• Runtime Error Analysis
• Best Practice and Architecture Review tools

Activer un aspect par JMX

Un article sympa qui donne des idées sur les possibilités du mariage de l’AOP avec JMX. A développer.

Build time vs. render time

Cet article présente le problème de base entre JSF et les pages JSP et les tags JSTL. Ceci provient du fait que les composant et les pages JSP ne sont pas interprétés au même moment :

What I mean by JSF being a component technology, is that HTML is produced by the processing of a component tree by renderers. This design is much more similar to Swing than it is Servlets and JSP.
…
Most of the « work » of a component takes place during rendering. For example, the h:dataTable sets up the var attribute during rendering (and other phases too, but that is not pertinent to this article). This means that EL expressions that rely on variables that only have scope during the rendering phase are not valid during component creation. That is to say, there is no component lifecycle method for when the component is created.

Choose your managers wisely; they have cookies on the dark side

Un article marrant, mais malheureusement assez vrai…

…
I am saying that management is one of the professional areas that is relatively easy to get in to but extremely hard to perform well.
Somehow, in the Netherlands, it is fairly common that once a person becomes the best in his department (in operational sense), they get to lead the department.
Nobody has ever been able to explain that to me though; why does your best programmer/business analyst/etc. make a good manager?
The qualities that lead them to be the best in their field are mostly not the qualities that are required for a good manager.
Besides gaining a potentially bad manager you also lose your best operational person; sounds like a lose-lose situation to me.

Software Architecture Document Guidelines

Ce document donne une ligne directrice pour l’écriture d’un dossier d’architecture. Très intéressant, à lire.

Il s’articule autour des points suivants :

1. Functional View
2. Non-functional View
3. Architectural Principles
4. Architectural Constraints
5. Process View
6. Logical View
7. Interface View
8. Technology Selection
9. Design View
10. Infrastructure View
11. Deployment View
12. Security View
13. Monitoring, Management and Administration View
14. Data View
15. Justification of the Non-functional Requirements

Ce mois-ci à l’honneur :

• Tableau blanc Javapolis
• Pourquoi utiliser Groovy?
• Le pouvoir du « Early Feedback »

Tableau blanc Javapolis et Spring MVC

Cette semaine se déroulait en Belgique la grande messe Java Européenne : JavaPolis
Pour ce genre d’occasion, il est fréquent de disposer un tableau blanc avec un marqueur afin que chacun puisse marquer un message sur un thème donné. Voici le résultat pour ce mini sondage concernant les serveurs d’applications et les frameworks J2EE : tableau blanc J2EE
La surprise pour moi est de voir la relative popularité de Spring MVC, à égalité avec Struts et JSF. Certains semble comme nous séduit par sa simplicité et son intégration avec Spring, et ceux malgrès le support extrèment réduit d’AJAX

Pourquoi utiliser Groovy ?

Groovy est le langage de script dont tout le monde Java parle actuellement. Je me suis longtemps interrogé sur cet engouement que suscite ce langage, avec en tête de file le framework J2EE Grails (pour Groovy on Rails).
La réponse semble être : la productivité ! En effet, la syntaxe est assez proche de celle de Java, mais propose quantité de raccourcis et certaines fonctionnalités que ne possède pas Java telles les closures (prévu pour Java 7), le fait que tout soit objet (contrairement aux types primitifs java), les POGO (équivalent de POJO mais sans la nécessité de getters/setters), des générateurs XML très très simple!

• Je vous propose cette rapide présentation, qui met en avant les fonctionnalités de base du langage : Groovy for Java Programmers
• Cet article est à compléter par la présentation des nouveautés de Groovy 1.5 : What’s new on Groovy 1.5
• Et par le site officiel.

Le gros avantage de Groovy est son intégration avec Java (les fichiers sont compilés en .class). On peut utiliser du code java depuis Groovy et inversement !

Le seul problème qui se pose est la multiplication de langages différents. Cependant comme le propose cet article, n’est-il pas plus judicieux de standardiser sur la plateforme java plutôt que sur le langage java?

Le pouvoir du « Early Feedback »

Le feedback est une valeur forte d’XP, ce témoignage montre l’intérêt d’utiliser le feedback le plus tôt possible et les conséquences qu’y peuvent en découler.
Pour éviter l’effet père noël (même si c’est la période), à méditer.