Anthony Patricio’s Blog

La gestion des compétences

Posted in Actu / Anecdote by apatricio on octobre 3, 2012

J’ai lu avec intérêt le billet suivant: http://blog.infine.com/conseils-a-un-jeune-developpeur-java-2133

Je suis sur le fond entièrement d’accord avec l’auteur mais la forme pose problème, ce qui est aussi relayé par certains commentaires. La question de la responsabilité de la formation est forcément soulevée.

Le développeur est-il seul responsable de sa formation? Dans la plupart des corps de métier, la réponse est évidemment non. Sous prétexte qu’il y a tonnes de tutoriels sur le web et/ou que le développeur doit forcément être un passionné, il devrait passer son temps libre à s’auto-former… Soulignons au passage que si tout travailleur doit savoir *apprendre*, tout le monde n’est pas censé être pédagogue et l’auto formation ne sera jamais aussi efficace qu’un échange avec un instructeur qui a la pédagogie innée.

Le cas du débutant

Le développeur (souvent ingénieur, ce n’est pas rien) sort de l’école avec une base plus ou moins bonne, théorique, rarement pragmatique. Souvent en stage de dernière année pré embauche il sera directement vendu comme ingénieur au client (et non comme stagiaire). Certes, c’est plutôt formateur comme première approche s’il est au contact de coachs qui ont le temps de le former. Ce n’est pas souvent le cas, après une introduction d’une demi journée il sera en face de son IDE et devra pondre des lignes. La qualité du code produit laissera forcément à désirer. Peu importe, le client délègue souvent la technique et ne sera donc pas en mesure de capter la pauvre qualité produite. Le développeur débutant n’est clairement pas responsable de cette situation. L’effet papillon d’une telle production est qu’un second développeur non formé intervenant sur ce code bancal par la suite se dira « tiens c’est comme ça qu’on fait ici? » puis le copier/coller fera son oeuvre. De temps à autre un presta tiers spécialisé dans la revue de code (le bon rôle) pointera du doigt le problème et les développeurs s’en prendront forcément plein la figure par le client et par leur chef de projet.

En passant qu’elle est la différence entre un développeur et une personne qui fait de la revue de code? L’un peut ne disposer que de très peu de jours pour implémenter un cas d’utilisation complexe alors que l’autre, pour le coup reconnu pour ses compétences techniques, dispose en proportion de plus de temps pour revoir le code produit et l’incriminer. Au final, il se pourrait très bien que les 2 disposent des mêmes compétences, ils n’ont simplement pas les mêmes moyens.

Coder c’est facile!

Bizarrement, lorsque l’on parle d’informatique d’entreprise, on a le sentiment que la compétence peut facilement être acquise. Hors les outils, frameworks, standards, buzz se multiplient à une vitesse trop élevée pour que les choix de production finaux suivent. Le développeur doit alors constamment jongler entre les oldies (struts, frameworks faits maison,…), les standards de fait et bonnes spécifications (Spring, JPA, JSF 1), les nouvelles specs (JPA 2, JSF 2, CDI)  mais aussi les *nouveautés* (ce terme étant plus ou moins faussé et très relatif) (NoSQL, Scala, …). Les managers, clients et autres RESPONSABLES n’imaginent pas combien il est éprouvant de passer d’une techno à l’autre, c’est intellectuellement épuisant. Car utiliser une techno ne se limite pas à en maîtriser la syntaxe ou même les fichiers de configuration , c’est surtout en comprendre la philosophie et pourquoi/quand l’utiliser et en connaître ses bonnes pratiques et limites.

Administrer des systèmes et gérer des projets c’est difficile sensible

Il est encore plus étrange à mon sens, que les budgets formations et certifications soient si pauvres voire nuls en comparaison aux mêmes budgets de formations et certifications des administrateurs dans leur ensemble. J’ai accès à certains chiffres éloquents, un administrateur OS, DB, réseau et Serveur d’application se verra proposer régulièrement des formations pour mise à jour de ses compétences. Celles-ci se verront validées, mais surtout mises en valeur par l’obtention d’une certification. Pourquoi ce grand écart entre les admins système et les développeurs? La réponse super naïve est de dire que les admins flirtent avec le réseau, l’hardware dans son ensemble mais aussi et surtout la sécurité. En effet, un mauvais admin pourrait laisser ouvertes des failles de sécurité , il plantera une config routeur qui bridera à 10% la capacité réseau ou plantera le DNS, quand à l’admin serveur d’application il pourra planter son clustering en le paramétrant en UDP là où de toute évidence, seule la config TCP est autorisée…

Les managers pensant comme celà sont peut être naïfs ou ils se voilent la face. Ils n’ont pas conscience que tous ces éléments critiques (sécurité, engorgement hardware, scalabilité) peuvent être mis en péril au niveau de l’application elle-même. La plus petite des webapps peut provoquer des désastres. Un mauvais développeur mal formé pourra en 3 classes pourrir votre SI, ouvrir un faille de sécurité béante vers votre BDD (SQL injection) et monopoliser votre réseau inutilement (requêtes faites à la va vite sans réellement comprendre ce qu’il se passe derrière). Vous pensez ces symptômes d’un autre âge? Avez-vous entendu de la dernière grosse faille Yahoo? C’était cette année: http://www.windstreambusiness.com/blog/2012/07/learn-from-yahoo-password-security-breach , cause: SQL injection, chose que l’on peut créer dans n’importe quelle application en utilisant mal JPA, JDBC, iBatis. Etre admin système requiert à mon sens des compétences solides, certaines pas évidentes mais pas vraiment d’un niveau de complexité plus élevé que le développeur.

Passons maintenant aux chefs de projet. Pourquoi m’en prendre à eux? Parce que justement je ne m’en prends à personne, simplement dans beaucoup de domaines, les qualités d’un chef de projet sont reconnues en opposition à celles du développeur que l’on trouve banales, normales, aisées à acquérir. Alors certes, un chef de projet doit impérativement avoir un bon relationnel, être un bon communiquant et posséder un sens de l’organisation et de gestion des *ressources* et compétences _sick!_ de son équipe la plus pertinente possible. En option premium il possédera des bases sur le métier du client et des bases techniques de surface. Une fois écarté le stéréotype du développeur geek qui ne sait aligner 2 mots et qui vit en ermite devant son dual screen, le développeur ne possède t’il pas aussi les qualités que l’on loue au chef de projet? Ou tout du moins une partie commune? Chacun sera libre de répondre.

Après 2 ans en TMA sur une appli delphi, swing ou struts, le pauvre développeur n’a aucune motivation/raison pour aller de lui même se mettre techniquement à jour, pourtant on a tendance à estimer que c’est implicite dans nos domaines. Comment l’empêcher de vouloir se reconvertir/évoluer vers un poste de chef de projet? Un poste qui n’est pas simple certes mais qui au moins ne sous-entends pas de constamment revoir ses compétences techniques et surtout un poste reconnu.

Tout le monde y trouve son compte … sauf le développeur

Les formations ça coûte de l’argent. Dans un domaine hyper concurrentiel, une SSII qui formerait officiellement ses équipes devrait répercuter ces coûts sur les clients. Elle serait moins compétitive. Ainsi on ne peut rendre les directeurs de marché responsables de ce système.

Si j’étais pour la théorie du complot et je ne le suis pas, j’avancerai l’argument suivant:

  • un développeur correctement formé voire certifié produit plus vite mais surtout mieux
  • il en résulte des coûts de maintenance corrective moins élevés
  • mais aussi et surtout des coûts de maintenance évolutive réduits
  • donc globalement moins de business à moyen terme

La vérité est probablement ailleurs. L’ingénierie du logiciel bouge trop et trop vite. On assiste à des évolutions majeures, à l’émergence de nouveaux modèles tous les 2 à 3 ans. Dans ces conditions est-il réaliste d’envoyer son armée d’ingénieurs en développement en formation aussi souvent? Une solution est la spécialisation des effectifs mais là encore, on demande très souvent au développeur de s’adapter à tout et très vite.

Le client qui *pense* qu’écrire une application coûte ce qu’elle coûte avec les TJM (ou forfaits, les proportions restent respectées) constatés de nos jours devraient se poser la question suivante: « et si je demandais à chaque profil qui est amené à travailler sur mes applis qu’il possède dans ses bagages une vraie formation et/ou certification? ». Peut être devrait-il supporter une hausse des tarifs sur le court terme mais il se rendrait compte qu’au final il a tout à y gagner.

Je voterai donc pour une spécialisation plus prononcée des profils, qui serait validée et exigée par le client.

Nouveau livre en français sur JPA ?

Posted in Actu / Anecdote by apatricio on juillet 3, 2012

J’ai reçu plusieurs inputs cette semaine qui font que je me pose la question.

Le premier input est mon relevé de droits d’auteur. J’étais déjà surpris l’année dernière mais mon second livre continue de se vendre, à un rythme à peine inférieur aux 4 années précédentes. Étrangement, je ne suis pas super ravi car à mon sens, il est en partie déprécié. Sur le fond aucun soucis, les démonstrations sont toujours bonnes. C’est plutôt sur la mise en oeuvre de certains exemples que le livre laisse à désirer:

  • absence de maven
  • la partie EE est bien trop lourde, une mise à jour avec JBoss AS7 serait la bienvenue

Sur la forme, quelques ajouts seraient les bienvenus mais pas de révolutions énormes.

Un lecteur m’a récemment posé la question d’une nouvelle édition.

Je partirai peut être plutôt sur une série d’articles concrets et pédagogiques sur ce même blog avec possibilité de télécharger de vrais projets de développement.

Ahhhh si j’avais des journées de 35h ….

 

La fin de Spring Framework ? Oui, enfin peut-être

Posted in Actu / Anecdote by apatricio on mars 14, 2012

Depuis quelques semaines nous assistons à une déferlante d’articles annonçant le « retour » en grâce de Java EE, reprenant en force le terrain qu’il avait concédé à Spring. Spring n’a jamais été un concurrent de Java EE, plutôt un complément.

L’histoire se répète

Le cycle observé avec Struts se répète.
On ne va pas entrer dans des détails rébarbatifs mais globalement, concernant Struts

  • J2EE n’est pas efficient pour le web MVC
  • Une personne de talent va créer un framework en dehors de J2EE,
  • bien entendu ce framework ne ré invente pas la roue mais l’optimise
  • ça apporte tellement que le framework est massivement adopté
  • il devient « standard de fait »

A partir de ce moment, il y a 2 chemins possibles. Le premier est de contribuer à normer/spécifier pour Java EE ces avancées, à les intégrer dans le pack normé, en quelque sorte c’est apporter sa pierre à l’édifice. Le second consiste à se battre contre des moulins et s’obstiner à lutter contre la « norme » (on est dans le monde software hein, je parle pas de l’idéologie humaine de la norme à laquelle je n’adhère pas) ou pire tenter de la saboter et je pèse mes mots.

Se battre contre des moulins

D’une façon ou d’une autre, si l’idée brillante d’un cerveau n’est pas dans une spec, elle le sera tôt ou tard, grâce au cerveau à l’origine de l’idée ou non, telle quelle ou optimisée/évoluée/complétée. C’est inéluctable. La spec est bonne car elle ouvre la compétition à diverses implémentations. Car elle permet de ne pas ré inventer la roue. Elle est un repère. Elle résulte de débats impliquant diverses visions.

Plus important à mon sens, une spec est une garantie d’homogénéisation des compétences. Je m’explique. Le développeur qui a fait ses armes avec Hibernate 2 (standard de fait) est passé sans soucis à Hibernate 3 qui lui a ouvert les portes de manière assez transparente à JPA 1.0 puis JPA 2.0. C’est extrêmement intéressant et surtout pérenne en terme de gestion des compétences. Les projets ayant adopté Hibernate 2 en 2004, les SSII ayant misé sur les compétences Hibernate à cette même époque ne s’en rendent pas compte, mais ils ont fait un choix extrêmement profitable.

La personne qui a fait ses armes sur struts a du ré investir (lui ou son employeur) pour s’adapter aux nouvelles technos front web. C’est fâcheux car coûteux mais pourtant inévitable.

Que reste t-il à Spring ?

Spring s’est toujours posé en lévrier agile et pratique face au mammouth que sont qu’étaient les serveurs d’applications. Je dis « étaient » car avec GlassFish puis JBoss AS7 la donne a changé. J’ai développé une appli relativement complète et complexe sous JBoss AS 5 il y a quelques mois. J’avoue m’être vite lassé des temps de redémarrage du serveur. J’ai même très vite employé Arquillian pour mes tests unitaires. Mais maintenant? A quoi bon? JBoss AS7 démarre en 4 secondes avec mon appli déployée (moins de 2 vide). L’emprunte mémoire a été drastiquement réduite. Où est le mammouth? Qui plus est, si je souhaite toujours alléger mes tests j’utilise encore Arquillian et ShrinkWrap mais c’est un autre sujet.

Reste l’argument de dire qu’il y a trop de choses dans Java EE. Est-ce sérieux? Qui vous force à tout utiliser? Personne mais le jour où vous avez besoin d’un élément plus exotique, plus poussé, si Java EE vous le propose, vous l’avez! et il est prêt à s’intégrer dans votre application et votre environnement d’exécution le supportera. Et s’il n’existe pas? Et bien adoptez un framework hors Java EE, je parie un bras que les serveurs d’application sauront le digérer.

A ne pas vouloir intégrer son idée dans Java EE, on finit par réveiller la concurrence. C’est ce qui est arrivé avec Seam qui est venu concurrencer Spring. Seam n’a jamais été une copie de Spring mais permet aussi la conception orientée composants, l’injection des composants, s’appuie de suite sur les annotations (là où Spring les combat initialement) mais aussi l’apport de divers contextes. Les deux framework sont de très bons framework, assez différents en fait mais qui se chevauchent sur une petite région et c’est cette région qui méritait justement une spécification. La vraie grosse différence est que les gars de Seam, ceux de JBoss, sont en faveur des specs et ont ainsi proposé la spec CDI qui est un joli succès. Il faut bien avoir en tête ce que cela signifie. Lorsque l’on part d’un framework isolé, autonome, en dehors de Java EE, se battre pour une spec c’est:

  • exposer son framework « indépendant » à la concurrence de la spécification, c’est bien se tirer une balle dans le pied
  • faire un cadeau à la concurrence en lui permettant d’implémenter la spécification (pour JPA, Hibernate contre EclipseLink par exemple)

Mort? Enfin peut-être, pas si vite coco

Tout ceci semble donc annoncer la mort lente de Spring. Ce n’est pas de violence donc je fais preuve ici mais bien d’objectivité. Je ne pense pas que ma vision soit biaisée par le fait que je bosse pour JBoss, n’en déplaise à mes contradicteurs. Si je devais retrouver un poste plus indépendant de décideur technique, JBoss AS7 s’imposerait car sérieux, rapide, robuste, intégrant beaucoup de ce qu’une entreprise peut avoir besoin pour développer un application. Il y a une petite chance que j’utilise Spring avec JBoss AS7 pour un temps, histoire de voir comment évolue la spec capable de le remplacer (et de faire plus) mais mon but ultime serait l’adoption de chaque spec sérieuse.

Cependant 3 conséquences pour 3 contextes distincts:

  • Les entreprises ayant investi sur Spring vont continuer de le faire jusqu’à ce que les compétences disponibles sur le marché des développeurs sur ces nouvelles specs atteignent en volume les compétences Spring. Ce n’est pas demain la veille mais ça arrivera! Sauf si Spring se ré invente et sort de son chapeau de nouveaux apports flagrants, ce qui n’est pas le cas actuellement. Je ne dis pas que Spring n’apporte rien de plus ou de différent, je dis que ce n’est pas suffisant pour parer le choix Java EE.
  • N’oublions pas le parc d’applis basées sur Spring actuellement en production, peut être pour une décennie voire plus. Il y a encore moult applications basées sur Struts qu’il faut maintenir mais l’on voit bien justement le problème du coût de maintenance de ces applis. Les profils qualifiés en struts ne sont plus si faciles à trouver. Le développeur qui sera motivé pour intervenir sur une appli Struts est une perle rare (ou maso).
  • Enfin se pose la question des nouveaux projets. Un décideur technique ne foncera jamais tête baissée sur une Spec (ou même un Framework) 1.0 et ce même si les exemples de bonnes spec 1.0 sont nombreux. Que choisiront-ils?

Au delà de cela il ne faut pas oublier ce que les gars de Spring ont apporté à Java, énorme respect pour eux ils sont fait avancer le Schmilblick.

Tagged with: , , , , ,

La certification, pourquoi faire ?

Posted in Actu / Anecdote by apatricio on juillet 29, 2011

Qui ne s’est jamais retrouvé dans une querelle d’experts sur une techno, sur le moyen d’implémenter un cas d’utilisation ou je ne sais quel aspect technique avancé. Lorsque l’on n’est pas initié soit même, et que l’on assiste à un tel débat, on est incapable de trancher, comme si l’on se trouvait au milieu d’une partie de poker face à deux gaillards prétendant tous deux avoir la main maximale, statistiquement proche de l’impossible, situation plutôt gênante lorsque l’on est client, chef de projet métier ou même employeur.

Pour toi développeur, technicien, archi avec la tête dans le guidon, ça peut être encore pire, tu peux te voir dé crédibilisé par un autre alors que tu es persuadé qu’il a tord, oui mais voilà, c’est un client, ou un concurrent qui est mieux vu. Le but ici n’est pas d’avoir raison mais bien de faire avancer le projet au mieux.

Que dire du directeur de marché, d’équipe ou responsable RH qui ne peut pas s’y connaître en technique (ce n’est pas son métier) qui va embaucher une personne selon le nombre de mots compliqués ou buzzables qu’il y aura sur son CV et qui, au premier projet livré, devra faire face à une montagne de bugs techniques plus bloquants les uns que les autres et à des réclamations en tout genre. La processus d’embauche mériterait un débat complet tellement il relève d’une problématique complexe: embaucher une personne compétente sur un domaine précis ça peut être très aléatoire. Pour tester un candidat il faut avoir soit même la compétence et/ou le test, le temps, bref ça coûte de l’argent tout ça et c’est une réelle stratégie de l’entreprise, un investissement, voire un risque si on embauche n’importe comment.

Il existe pourtant un moyen simple d’apporter des garantie de crédibilité: les certifications. Attention toutefois, il existe 2 types de certifications. La première s’apparente au code de la route, à savoir un QCM. A vrai dire, il n’y a que très peu d’intérêt à une telle formation, une bonne mémoire, la lecture d’un bouquin ou deux et hop, nous voilà certifiés. La seconde est plutôt semblable à l’examen de conduite, comment le candidat utilise t’il sa connaissance (et surtout son expérience) face à des cas réels ? Ces certifications là valent de l’or, aussi bien pour la personne certifiée que pour la personne qui va l’employer où faire appel à ses services. Pour l’employeur c’est la garantie de ne pas se tromper, pour le certifié c’est une garantie de pouvoir se faire respecter dans ses choix, ses développements, c’est un argument de taille, c’est aussi l’occasion de valoriser son CV et prétendre à un salaire plus élevé.

Chaque année des études sont faites pour lister les certifications les plus remarquables, généralement cela se traduit en % supplémentaire de salaire que l’on peut négocier si l’on a telle ou telle certification. Par exemple: http://www.reseaux-telecoms.net/fichiers/dossierpdf/la-grille-des-remunerations.jpg. Deux paramètres influent sur le résultat: la compétence testée bien sûr mais aussi indéniablement la qualité de l’examen. Etre certifié sur une technologie pointue, rare, très demandée mais via un examen QCM bateau est facile, ne sera pas reconnu et n’apportera rien à personne. Dans le tableau évoqué précédemment vous noterez la présence des certifications Red Hat sur l’OS entreprise RHEL. Depuis plusieurs années, les certifications Red Hat sont reconnues parmi les meilleures, souvent même au top 10 des certifications IT. Pourquoi?

Bien sûr car la compétences est recherchés mais aussi pour la qualité de l’examen lui même. Imaginez que l’on vous teste sur l’installation, le tuning, la réparation d’un système existant, sur des aspects utilisés par toutes les entreprises. Et bien c’est ce que propose Red Hat: que du cas réel, pas de piège. Tout son savoir faire sur la création de certification a été décliné sur les technologies JBoss. D’abord sur le serveur d’application, puis sur JPA, maintenant sur Seam 2, bientôt sur Portal, JPA 2, …

Conclusion, une certification s’est

  • pour le certifié,
    • valider ses compétences,
    • se faire reconnaître pour ses compétences,
    • valoriser son CV,
    • avoir plus de poids dans les débats et prise de décisions
  • pour l’employeur,
    • limiter les risques lors d’une embauche,
    • valider son investissement dans une formation pour un collaborateur,
    • une valeur ajoutée certaine chez le client dans le cadre de prestations, c’est décliner la garantie chez le client
En savoir plus sur les certifications Red Hat:
Si vous souhaitez formuler un souhait de certification, n’hésitez pas à me contacter.
Tagged with: , , , ,

JBoss Application Server 7, moins de 2 secondes au démarrage

Posted in Actu / Anecdote by apatricio on juillet 22, 2011

Après un long sommeil, je ne peux m’empêcher d’avoir envie de blogger sur JBoss Application Server 7.

Peut-être êtes-vous sur une autre planète et ne l’avez pas entendu mais cette dernière version du serveur d’application est tout simplement étonnante, bluffante, décoiffante. Habitué depuis des années à travailler sous JBoss AS, je connais sa robustesse, son sérieux mais j’en reconnais aussi sa lourdeur, taille au téléchargement, délai de démarrage, emprunte mémoire. Cette lourdeur m’avait même motivé à exploiter Arquillian, que je recommande toujours chaudement, lors de mes phases de développement.

Lorsqu’une équipe de costauds de la technique décide qu’il est temps, après des années, de revoir l’intégralité d’un serveur d’application, de plonger de trois niveaux dans les couches de bas niveau, d’appliquer des optimisations sur le moindre bloc, d’exploiter de nouvelles normes, techniques, frameworks, d’en créer lorsque l’existant ne donne pas 200% satisfaction et bien lorsqu’une dream team comme celle de l’engineering JBoss se met en marche, ça donne JBoss Application Server 7. Peut-être pensez-vous que j’en fais des montagnes, que je prêche pour ma paroisse, mais il faut le vivre de l’intérieur pour comprendre le travail que cela représente, la passion, que dis-je, la foie en une constellation de compétences au service d’un produit, qui plus est open source, c’est ce que je trouve génial, moi qui suis dans ce domaine depuis 8 ans (là je prends un coup de vieux). Alors, oh toi grand développeur au niveau de geekitude avancée, toi dont on ne distingue plus les doigts lorsque tu libères ton code, toi qui hot-déploies plus vite que ton ombre et qui redémarre ton serveur plus de 10 fois par heure, sache que JBoss a pensé à toi.

Stop au bavardages, voici quelques chiffres, je ne compare pas avec la concurrence, je ne suis pas là pour casser un concurrent juste pour montrer l’écart avec la génération d’AS précédentes. Jusqu’à ce jour j’utilisais EAP 5.1 (comprenez la version ‘product’ de JBoss AS 5). Je compare le profil standalone d’AS7 et le profil default d’AS5.

  • Emprunte mémoire: 350M contre 900M
  • Démarrage à vide: 1,8 secondes (je ne mens pas) contre 20 secondes
  • Démarrage avec la même application web basée sur Seam 2 et Hibernate 3: 7,8 secondes contre 28 secondes
  • Taille disque 126M contre 535M
  • Une console d’administration, pas trop tôt certains diront, oui ok je suis d’accord.

Certains me diront que la concurrence (tout du moins un AS concurrent très respectable au demeurant) sait faire depuis un petit moment déjà. A ces personnes je dis que l’intérêt ici est de pouvoir utiliser le même serveur d’app en dev et prod car il faut être réaliste, JBoss AS est très largement employé en production, comme en dev d’ailleurs. (attention je n’ai pas dit que le concurrent en question n’était pas utilisé en prod, ne me faites pas dire ce que je n’ai pas dit.)

Evidemment, tout ceci ne fait pas tout, il faudra juger et attendre pour prendre le recul et juger de la robustesse mais je ne m’en fais pas du tout pour ce point. Qui dit nouvelle génération, refonte totale, dit « j’arrive à rien déployer dans ce foutu AS de m…. ». Je confirme c’est ce que je me suis dit à ma première tentative de déploiement d’une appli que j’avais créée avec Seam 2 et Hibernate 3. Pour info AS7 fournit Hibernate 4. Un article prochain expliquera comment déployer une telle appli et cerise sur le gâteau l’article devrait être très court car il n’y a pas grand chose à faire au final.

Je te laisse l’essayer, sisi, download, unzip ./standalone.sh , tu en as pour 5 minutes dont 2 secondes pour le démarrer.

Ca se passe là: http://www.jboss.org/as7.html

Réflexion: il n’aura fallu qu’un an pour sortir cette version finale de JBoss Application Server 7, certifiée Java EE6 Web Profile. Un an ce n’est rien lorsque l’on connait la complexité d’un tel projet, la variété de compétences requise pour le mener à bien. Ca fait réfléchir sur l’organisation projet, sa gestion, la gestion des ressources, des compétences. Je ne peux m’empêcher de comparer l’évolution de ce projet avec les expériences projet de mes postes précédents, en interne ou en tant que prestataire. Ma conclusion est radicale et sans appel mais je la garde pour moi, je suis fier d’être un RedHat!

Darwin et Java, prochaine étape de l’évolution des applications

Posted in Actu / Anecdote by apatricio on juin 10, 2009

Année 2000, ahhh je me souviens le bon vieux temps où je crachais sur les EJBs et prônais le standalone efficace en développant une allergie hypodermique à tout ce qui se rapprochait d’un serveur d’app.

On développait avec JSP, struts et hibernate, le tout en stateless bien sûr, et on était contents, super contents. Grâce à struts, on passait 1h45 heure au lieu de 2 à concevoir notre JSP, la plugger à notre logique de navigation, coder nos validations de surface. Ahhh ce que c’était chia….

Tous ces aspects m’ont vite persuadé de me focaliser sur la persistance, le développement côté serveur, bref TOUT sauf les vues.

Quelques années ont passé, EJB3 est arrivé et j’ai retrouvé les beans session et le stateful et toute sa puissance. C’est Seam, un next generation framework imaginé par Gavin King, qui a d’ailleurs redoré le blason du stateful.

Les annotations nous ont délivrés de l’enfer du XML et struts, après tant de bons et loyaux services, a doucement passé la main à JSF et là… c’est le bonheur surtout avec RichFaces.

J’espère avoir assez de temps libre pour partager des avis/exemples sur toutes ces technologies, EJB3, JPA, Seam, RichFaces mais aussi Hibernate Search qui marquent un pas décisifs dans le monde des applications Java.

Foutaises, apprenez à les détecter

Posted in Actu / Anecdote by apatricio on mai 15, 2009

Tout travail mérite le respect, la réflexion et le temps passé à concevoir et implémenter une solution ne peuvent être directement et gratuitement fustigés.

Il en va différemment lorsque les auteurs s’exposent eux-mêmes en lançant une information agressive et fausse (aka F.U.D) avec d’autres produits.

C’est ce qu’il s’est passé ici où l’on nous ressort un DataMapper basé sur des patterns anciens voire du millénaire passé comme commenté sur la page:

Honestly, the approach is old. I know that I’ve used similar approach going back to 1999 and it was old back then.

Reprenons depuis le début, le produit présenté n’a rien d’un ORM (Object Relationnal Mapping) dès lors qu’il impose d’énormes limitations au modèle objet, comme la non prise en charge de l’héritage et surtout qu’il ne propose pas de mapping… ben oui forcément. Ici il s’agit en fait d’imposer, via un framework, une organisation/une structuration du code dans des classes stéréotypées. L’idée est louable, toujours meilleures que d’avoir du JDBC pur non organisé et explosé partout dans un projet.

Cependant, c’est assez préhistorique et très franchement pénalisant sur beaucoup de points, lisons entre les lignes :

No lazy loading. Just eager loading because you can expect whatever you want during coding. Eager loading removes n + 1 queries.

Mouais, c’est un peu beaucoup n’importe quoi. Le lazy loading peut effectivement entraîner un soucis de n + 1 requêtes mais uniquement si le développeur est un lazy développeur (= développeur fainéant). Avec un ORM et hibernate en particulier, tout est fait pour pouvoir optimiser les modes de récupération de graphe d’objets. En passant « just eager loading » tend à forcer le chargement entier des graphes d’objets. Ceci est purement unitle et simplement consommateur de ressources. D’où l’existence d’une fonctionnalité comme le lazy loading qui permet de charger uniquement la portion de graphe nécessaire à un cas d’utilisation. Le lazy loading bouchonne le reste du graphe avec des proxies qui permettront eux-même le chargement transparent du reste du graphe en cas de nécessité, comprende? … la boucle est bouclée

an entity object which extends POJO

Comme le dirait un de mes bons amis:  « namuf ? » (= quoi?, kékidi? ou encore C’est une blague?). Pour faire court, simple et pour ceux qui n’ont pas tilté, un POJO est un objet pur, qui ne dépend d’aucun framework, encore moins technique. Un POJO est libre et peut être exploité par un client sans que l’on ait besoin de déployer une quelconque armada de jars de frameworks techniques au risque de se prendre une ClassNotFoundException.

Notre ami nous explique donc que les classes persistantes utilisées avec son framework doivent étendre une classe technique, présente dans son framework, classe qui se nomme très intelligemment POJO. C’est fantastique! Forcément et probablement sans même savoir pourquoi, il a du compléter son framework de convertisseurs:

built-in converter that can be used to convert a Java Object into a frontend String or a frontend String into a backend Java Object. The converter prevents data conversion from scattering different pages and layers.

Beh oui, les objets n’étant pas des POJOS, ils deviennent difficilement manipulables d’une couche à l’autre. Il faut passer par le bon vieux DTO, à savoir un POJO destiné essentiellement à des fins de manipulation de données. Et pour automatiser la transposition d’un « truc » (désolé ses trucs ne sont pas des POJOS pour moi) vers un DTO, que faut-il? Des convertisseurs, bravo. Il va forcément falloir gérer ces conversions de manière systématique, typiquement entre la couche service et la couche web.

Ces traitements sont coûteux en terme de développement et de maintenance, complètement inutile car ne contenant aucune plu value métier et forcément c’est vraiment contre productif. Mais non puisque notre ami nous affirme gratuitement:

High productivity compared to Hibernate.

Sans exagérer 70% de ce que dit l’auteur est faux et je vais arréter là, … euh, … aller une dernière pour la route, lisez attentivement le titre est les premiers mots du commentaire ici (écrit par l’auteur du framework lui-même. ):

No limitation

suivi de

There are no polymorphic queries

Comme c’est beau, il m’a convaincu!

Tout ceci ne veut pas dire que le framework est inutile ou mauvais, il ne répond simplement pas à un outil du spectre d’un ORM. En le aisant délibérement, l’auteur s’est tiré une balle dans le pied.

J’ai connu et connais encore plusieurs décideurs qui se laissent berner par ce type d’argumentation. Résultat: des applications qui utilisent des technos d’un autre millénaire (ce qui n’est pas grave) mais qui passent aussi à côté de technos pouvant résuire sensiblement les coûts de développement, de maintenance et d’évolution. Prenez une application de 50 tables avec 1000 requêtes SQL codées en dure, forcément pas le choix avec un DataMapper, il faut en coder une par cas d’utilisation. Ajoutez une colonne par ci par là lors d’une évolution, vous m’en direz des nouvelles…

Apprenez à lire entre les lignes et si vous êtes décideur sans être expert sur un sujet en particulier, déléguez à un de vos petits gars passionnés. Il vous fera gagner beaucoup d’argent à terme, croyez-moi. De même, méfiez-vous toujours des software marabous qui vous vendent une bidouille propriétaire  sortie du chapeau et qui vous certifie qu’elle est bien meilleure que les frameworks les plus robustes, matures et éprouvés.

Tagged with: , , ,

Comparer des pommes avec des oranges.

Posted in Actu / Anecdote by apatricio on mai 14, 2009

Comparer des pommes avec des oranges est-il si stupide que cela?

Cette phrase amplement utilisée pour signifier que deux sujets ne peuvent être comparés entre eux est-elle réellement pertinente? Pour ma part, les affirmations absolues n’ont pas leur place dans ce monde, tout est question de contexte. Il est ainsi intéressant de comparer des pommes avec des oranges dans différents contextes comme la nutrition ou le goût.

Il y a quelques semaines, j’ai vérifié et corrigé une application destinée à comparer des outils de persistance d’objets java. Il y avait trois produits: un ORM mystérieux couplé à une BDD relationnelle et 2 Bases Objet.

Cette expérience fût l’objet de longs débats plus sémantiques et méthodologiques que techniques entre l’étudiant (préparant son doctorat) et moi-même qui devais valider son code et ses mappings. Au delà des résultats des tests, ce qui m’intéressait était de permettre à l’étudiant de prendre du recul et si cela ressortait dans sa dissertation alors mon objectif serait atteint. Pour lui faire entendre raison il m’a fallu ruser et utiliser une autre comparaison, place aux engins motorisés.

S’il fallait comparer une moto, une formule 1 et un 4×4, beaucoup de questions me viendraient à l’esprit, et malheureusement l’étudiant en question a foncé tête baissée dans le code sans se les poser:

Qui pilote les engins?

  • une personne sans permis
  • une personne avec une expérience significative pour chacun des véhicules

L’expérience semble nécessaire, malheureusement l’étudiant n’avait pas de réelle expérience pratique et, oh mon dieu!, n’a fait que survoler les guides de référence. Résultats: des erreurs graves un peu partout. Après une première passe sur ces erreurs grossières, les performances étaient déjà 2 à 3 fois meilleures.

Où tester les véhicules ?

  • sur un terrain neutre, très difficile à définir ?
  • sur un circuit ?

Tout dépend de l’objectif du test et de l’utilisation attendue par les destinataires du test. Admettons dans notre cas un test sur piste pour tester la vitesse pure des engins, en ligne droite, courbe, blah blah. Ici, le modèle Java utilisé avait du sens, tous les types d’associations étaient présents, ainsi que l’héritage. Petite chose irritante cependant, au lieu de se pencher sur un listing des fonctionnalités de chaque outil, le test cible les performances dans des cas d’utilisation de type batch. Les connaisseurs comprendront de suite le soucis: on ne choisit pas ce type d’outil pour faire des insertions/extractions massives de données mais bien pour permettre de concevoir une application qui nécessite une modélisation orientée objet.

Autorisation de prendre des raccourcis ?

  • Seul le 4×4 est capable de couper à travers champ pour le test
  • Alors que la formule 1 n’y survivrait pas.

Dans ce cas il semble nécessaire d’expliquer que le 4×4 dispose d’un avantage certains, non négligeable sur ces concurrents.

Si tous les véhicules peuvent prendre le raccourcis, la question se pose aussi, tout dépend de l’exhaustivité et de la lisibilité souhaitées. Ainsi un des deux fournisseurs de base objet a essayé de forcer l’étudiant à configurer son architecture autour du mode « stockage in-memory ». Oui mais voilà, des BDD relationnelles in-memory existent aussi, permettant des performances virtuellement explosives. L’étudiant a fait preuve d’impartialité et n’a pas accepté cette requête.

Quels pneus utiliser ?

Certainement l’aspect pouvant impacter le plus les résultats. Utiliser des pneus en mousse pour la formule 1 invaliderait l’ensemble des tests. De nombreux points techniques relevant de ce domaine ont du être rectifiés dans le code. Dans le cas ORM + BDD relationnelle, ce n’est pas l’ORM qui est testé, c’est bien l’ensemble. Il semble donc intéressant de comparer les résultats avec 2 BDD relationnelles différentes.

Épilogue: après différentes corrections et optimisations de bon sens (pas de triche genre cache de second niveau expressément tunné pour les cas d’utilisation), tous les tests (une 15ene) tournent entre 4 fois et 40 (oui 40!!!) fois plus vite.

Conclusion: même si la solution ORM/BDD relationnelle s’en sort une fois de plus grandie, je persiste à penser que, comme la quasi totalité des comparatifs axés uniquement sur la performance, ce test est un nième benchmark peu utile. Posez-vous toujours et en priorité la question de votre contexte d’applications d’entreprise. Pensez d’abord fonctionnalités, pérennité et réputation des produits. Si un produit est réputé et massivement utilisé, c’est déjà un gage de sécurité.