BodySplash.fr

Nous avons à peu prêt fini de bricoler un site pour Arpinum, la société que nous avons créé pour éditer Tiron. Pourquoi est-ce je vous en parle? Et bien car ce site est finalement essentiellement un blog, et il y a de fortes probabilités pour mes futurs billets soient essentiellement publiés chez Arpinum plutôt ici. C'est d'ailleurs déjà le cas pour mon billet concernant le support d'IE6.

Je ne sais pas encore très bien si je dois faire du double post, ou bien signaler ici la publication de nouveaux articles, mais en attendant, si vous êtes toujours intéressés par mes propos et ceux de mes collègues, je vous conseille de mettre à jour votre lecteur de flux rss préféré.

Comme beaucoup de monde, j'avais une certaine aversion pour JavaScript. Ces derniers mois m'ont permis de remettre un peu en perspective pas mal de mes anciennes croyances. Vous allez sans doute me demandez comment la magie à-t-elle opérer (ou pas)? Et bien en fait assez simplement à partir du moment qu'on décide de lui donner sa chance, et d'arrêter de se contenter de hacker quelques bouts copiés/collés à droite à gauche. Voici en tout cas pour moi les grands points qui m'ont permis non pas de devenir un expert, mais de pouvoir m'en servir sans hurler à la mort :

• Le plus gros manque finalement au départ de javascript, c'est un framework de base livré avec l'engin. Sans ça, on a l'impression de réinventer 100 fois la roue, et de perdre pas mal de temps à faire la même chose. Le premier conseil est donc d'utiliser une des fantastiques librairies qui vivent dans le coin. Leur philosophie peut varier, donc méfiance, mais je préfère personnellement m'appuyer sur jQuery, car je le qualifierai bien de plus simple qui fonctionne. Il est malgré tout à la fois très puissant et extensible à souhait. Je dois avouer que du coup je n'ai pas trop essayé la concurrence qui en comparaison semblait bien plus complexe.

• Il faut se rendre compte que JavaScript est un vrai langage, avec son propre paradigme, et qu'il ne sert donc à rien de tenter de ramener toutes ses habitudes de nos langages favoris (java, c#, python ruby, choisissez celui qui vous fait plaisir). Comprendre ce qui se passe et les quelques concepts de base qui animent le langage fait déjà beaucoup pour commencer à l'apprécier. C'est pour cette raison par exemple que encore une fois je préfére jQuery à prototype, car il n'essaye pas d'ajouter un support "classique" de l'orienté objet au langage, il lui demande juste d'être lui même, naturellement. J'aimerais bien vous conseiller un bon tutorial sur le sujet, mais hélas j'ai appris tout ça dans deux bouquins.

• Le conseil bateau maintenant, il faut s'abstraire le plus possible du navigateur en utilisant une bonne librairie : ça recoupe en grande partie le premier point, mais c'est surement le soucis qui retient beaucoup de monde à apprendre Javascript. jQuery fait un boulot fantastique pour faire oublier là plupart des soucis de compatibilité, même s'il reste bien entendu quelques problèmes à droite à gauche.

• Enfin, mais sans doute le point plus important, les bonnes pratiques de programmation ne sont pas à jeter tout simplement car on se trouve côté navigateur. Il n'y a pas de secret, le seul moyen de vraiment tirer partie de javascript est d'appliquer les bonnes pratiques, DRY et TDD en tête de liste. Il existe quelques frameworks de tests unitaires en javascript, même si rien n'est parfait bien entendu pour le moment dans ce domaine, surtout lorsqu'il s'agit de les faire tourner automatiquement pendant l'intégration. TDD fonctionne bien en javascript encore une fois du moment qu'on essaye de pas de tordre le langage dans un orienté objet "classique". Pour reparler, encore, de jQuery, développer ses fonctionnalités sous la forme de plugin pour ce dernier les rend incroyablement plus testable et réutilisable.

Ma conclusion finalement serait qu'il y a encore quelques mois, je lorgnais beaucoup du côté GWT pour les mauvaises raisons : la peur de javascript. Paradoxalement, avoir adopté ces derniers mois Restlet, freemarker et jQuery a beaucoup simplifié le développement que les quelques essais avortés avec GWT. Le plaisir des choses simples il faut croire Ces framework sont solubles dans une approche ROA là ou GWT l'est beaucoup moins.

Pour aller plus loin, javascript commence même à envahir la programmation côté serveur grâce aux deux initiatives CommonJs et Node.js. Il y a un bon article sur le sujet dans le pragpub de ce mois-ci

Voilà un titre de billet accrocheur! En fait, je vais me contenter de réagir à cet article d'Ayende Si vous écoutez un peu les voix alternatives du monde .NET, vous devez surement avoir déjà entendu parler de lui, sinon sachez juste qu'il est contributeur sur NHibernate, qu'il a initié l'implémentation de Linq2NHibernate, et qu'il a fait pas mal d'autres projets open source dans le monde de .Net, ainsi qu'un profiler propriétaire mais excellent pour NHibernate et Hibernate. Bref, ce bonhomme est très bon techniquement, et je suis toujours avec attention ses avis (notamment sur la mutualisation, désolé pour la private joke, mais les initiés comprendront ).

Bref, dans l'article que je donnais en début de billet, il donne donc son avis sur JEE vs .NET. Je suis globalement très d'accord avec lui sur son jugement sur JEE, et sur certains manques du langage Java. Cela fait maintenant un peu plus d'un an que je fais du Java 100% du temps, et que je ne touche plus à .NET, et pourtant je passe encore pas mal de temps à regretter certains fonctionnalités de C#. Ceci dit, cela fait également plus d'un an que je m'efforce le plus possible à ne PAS utiliser JEE. Et je pense que c'est un peu ça la force de Java vs .NET : une communauté réactive qui passe le plus clair de son temps à essayer de ne pas appliquer la philosophie "main stream" et à développer des alternatives . Mieux encore, il est tout à fait possible en entreprise d'utiliser ces projets open source sans rencontrer trop de résistances. Lorsque que je bossais en .NET, convaincre un client d'utiliser NHibernate (à une époque ou Entity Framework n'existait pas) relevait du défis, à tel point que j'ai été contraint dans une mission d'écrire mon propre mapper O/R. A ça ajouter une communauté, si on peut l'appeler ainsi, provenant majoritairement d'un monde VB6 sans bonnes pratiques, et vous obtenez une mini catastrophe. Des mouvements comme Alt.NET sont bien sûr à saluer et regroupent de très bon praticiens, mais je pense qu'ils représentent toujours hélas une minorité dans l'ensemble des développeurs .NET. Biens sûr tout n'est pas rose côté communauté Java, et elle comprend son lot de boulets et de mauvaises idées. Mais le simple fait qu'il soit tout simplement possible d'avoir le choix rend cette technologie plus attractive maintenant à mes yeux. Nous utilisons principalement Restlet dans Le Projet, et à ma connaissance, il ne connait pas d'équivalent en .NET aussi simple d'utilisation et de configuration. Le monde Java est un monde où les idées peuvent plus facilement s'épanouir j'ai l'impression, et où le réflexe "alternative open source" est bien plus ancré.

Aujourd'hui, je vais essayer de parler un peu d'AppEngine.

Rapidement

Commençons par un peu de présentation. Pour ceux du fond qui ne le savent pas, AppEngine, c'est le système d'hébergement mutualisé made in google pour des applications développées soit en Python, soit en Java. L'idée est donc de développer tranquillement son application, et de laisser à google la responsabilité de l'infrastructure et de la montée en charge. Niveau facturation, on ne paie que ce qu'on consomme à partir d'un certain quota.

Déjà, le premier point que j'aimerais souligner, c'est que nous disposons enfin d'une offre solide et abordable d'hébergement mutualisé pour Java (pour python, on pouvait déjà trouver son bonheur en fouillant un peu). Ça n'a l'air de rien comme ça, mais j'ai envie de dire c'est pas trop tôt. Voilà près de 10 ans qu'il est très facile de trouver un hébergement mutualisé pour Php, mais qu'il est très difficile voir impossible de trouver une offre équivalente pour d'autres technologies. Du coup, PHP est presque devenu un standard sur le net, alors qu'il est sans doute difficile de trouver pire environnement de dev (support des TU lacunaire, pas de refactoring, un style très procédural, une communauté globalement très mal formée et sensibilisée aux bonnes pratiques de développement, pas de framework unifié de base, etc. etc.). Alors bien sûr, je ne pense pas qu'AppEngine va réussir à inverser la tendance, mais j'espère juste qu'à l'avenir, des offres d'hébergement pour des technologies/langages plus "agréables" comme Python ou Ruby vont fleurir sur le net. Bref, après un paragraphe qui je suis sûr, va me faire lapider par tous les aficionados de php, passons aux choses sérieuses (vous pouvez m'envoyer vos cailloux par email).

Un peu (beaucoup) de technique

Parlons un peu technique. Je vais me contenter de parler de la partie java d'AppEngine, car je ne suis pas du tout un expert python, et je n'utilise que des langages pour lequel il existe un IDE avec un bon support du refactoring (et ceux qui disent que ces outils ne servent juste qu'à palier les manques d'un langage n'ont juste rien compris à ce qu'est fondamentalement le refactoring).

En terme de développement et de déploiement, si vous utilisez le plugin eclipse de google, tout est excessivement simple, et mérite à peine d'en parler : vous codez, vous testez, et vous déployez en un seul clique. Un serveur de développement AppEngine est fourni pour vous permettre de faire des tests d'intégration, et TDD peut s'utiliser sans aucune contrainte, en fakant rapidement l'accès aux données. IntelliJ IDea dans sa version complète je crois fournit également un support pour tout ça. Là où ça commence à être compliqué, c'est si vous voulez utiliser maven pour automatiser votre build et votre intégration. Clairement, ce n'est pas au point, et j'ai laissé tomber l'idée pour le moment.

Ceci étant dit, abordons les limitaions d'AppEngines. Pour garantir la scalabilité et la mutualisation de votre application, Google a dû imposer des contraintes de taille.

Première contrainte, toutes les fonctionnalités de l'API java ne sont pas à votre disposition. Les deux restrictions qui sautent aux yeux mais qui sont assez logiques sont l'impossibilité bien sûr d'écrire sur le FileSystem, ainsi que l'interdiction de créer des threads. Il y en a d'autres, mais je vous laisse la surprise, je ne veux pas trop spoiler.

Deuxième contrainte très importante, et c'est celle qui va le plus nous intéresser : le stockage de vos données. Et oui, vous ne pouvez pas utiliser votre cher SGBD. C'est assez logique en fait. Pour garantir la scalabilité et la vitesse d'accès à vos données, google fournit son propre système, BigTable, pas du tout relationnel. Bon si cette base n'est pas relationnelle, qu'est-elle donc? Elle est hiérarchique. Ce genre d'approche permet de répartir bien mieux vos données sur N cluster, là ou les SGBD eux ont beaucoup plus de mal. Ce miracle est dû au fait que ces approches ne se concentrent par sur la cohérence des données, mai sur leur accessibilité et leur distribution, là où un sgbd se concentre sur l'accessibilité et la cohérence. Le bémol est donc que vous n'avez pas la garantie qu'à un instant T, une entité donnée est cohérente sur l'ensemble des noeuds. Ok, une base hiérarchique, c'est quoi donc? Vos données sont organisées en entités, contenant des propriétés clef/valeur de types supportés. Ces valeurs peuvent être d'autres entités. Le DataStore regroupe les entités par groupe, chaque groupe ayant une racine. Et là, normalement, si comme moi vous aimez Domain Driven Design, ça doit faire tilt dans votre tête. Entités? Groupe? Racine? Pouvons-nous réécrire ça en Agrégat, racine d'Agrégat et entité? Et bien oui, nous le pouvons. Nous avons face à nous un système de stockage mimant les grands concepts de DDD, et ça, c'est la classe. Nous pourrions normalement sauter de joie, mais hélas non, pas encore. Pour nous permettre de décrire la persistence, Google nous fournit une implémentation partielle de JDO ou JPA. Voilà déjà un premier point noir à mes yeux : pas d'ignorance de la persistance pour nos objets du domaine, vu que le mapping se fait donc nécessairement par annotations. Deuxième gros point noir, pour modélier une relation entre deux racines d'agrégats, nous devons nécessairement passer par la clef. Et oui, pas de mapping transparent entre deux racines : l'un ou l'autre contient la clef qui va nous permettre de faire la requête adaptée.

Dernière contrainte que je vais aborder : le développement itératif. Si vous suivez un modèle de développement agile correctement implémenté (ok disons que vous utilisez XP, ça ira plus vite), vous êtes incrémental et itératif. Itératif veut donc dire que votre modèle évolue au fur et à mesure des besoins et de votre compréhension. Si le modèle évolue, nécessairement sa persistance aussi. Le DataStore n'a pas du tout besoin que toutes les entités d'un même type possèdent les mêmes propriétés, donc on pourrait croire qu'en théorie pas de soucis. Oui mais si vous devez tout de même faire une mise à jour des vielles entités pour une raison X ou Y (notamment si vous avez ajouté un type valeur comme un boolean), comment faire? Voilà tout le soucis, actuellement, même si Google planche sur le sujet, vous ne pouvez pas facilement. Vous avez une limite de 1000 entités par requête, et une requête a un temps de vie très court accordé par le système avant d'être tuée. Il existe bien sûr des solutions de contournement, mais rien de bien simple et de pleinement satisfaisant.

Et pour conclure

Bien voici venu le temps d'une grosse conclusion. Ce que j'aime, voir ce que j'adore chez AppEngine, c'est enfin l'accès à un hébergement abordable et de qualité pour Java. Vous pouvez utilisez si vous développez avec AppEngine en tête dès le début vos frameworks et techos préférés (Groovy, Restlet, Spring, Guice <ajoutez ici votre techo>). J'adore également, et ce n'est pas seulement dû à AppEngine, l'attaque qui est faite aux SGBD traditionnelles. Des technologies solides de remplacement voient enfin le jour grâce à ces nouveaux services, et on peut espérer voir la fin de notre vivant des ces applications codées en procédures stockées, soit disant pour être performantes. Là vous n'avez pas le choix : votre métier est dans votre application, pas dans la base. Bien sûr, ce n'est pas encore complètement au point à mes yeux tant que l'ignorance de la persistance n'est pas atteinte, mais c'est sur une très bonne voie. Si vous ne voulez pas dépendre, à juste titre, de sociétés comme Google et Amazon pour stocker vos données, des implémentations solides et open source de ces nouvelles bases de données sont disponibles.

Enfin, je m'excuse si ma vulgarisation des théories derrière BigTable est vraiment lapidaire, mais je vous laisse bien entendu l'opportunité de me fustiger dans les commentaires

Je ne sais pas pourquoi ces derniers temps, j'entend pas mal de retours comme quoi le refactoring serait ralenti par les tests unitaires. L'explication derrière cette affirmation douteuse est qu'il faut bien souvent modifier les tests en même temps que le code de production.

J'ai tendance à croire que cette idée bizarre est née d'une des deux écoles de TDD. Ces deux approches ont été bien décrites par Martin Fowler dans son article sur les mocks et les stubs.

Je vais me permettre de le paraphraser ici :

• L'approche classique essaye d'utiliser le plus possible de vrais objets, et un "double" s'il est difficile ou gênant d'utiliser l'implémentation réelle (par exemple, l'envoie d'un mail)
• L'approche par Mock va utiliser dans tous les cas des doubles de test pour tout objet ayant un comportement intéressant.

Pour qualifier ces deux méthodes, Mister Fabien parle de tests Boîte Noire et de tests Boîte Blanche.

Appliquer systématiquement une approche par mock implique une chose : on teste plus la chorégraphie de notre objet que ses résultats. Nous allons vérifier que tel méthode de tel mock a été appelé avec tel paramètre, et que si nous retournons tel valeur, alors notre objet va se comporter de telle manière. Ce faisant, nous liions inexorablement notre test avec l'implémentation sous-jacente, rendant par la même plus douloureux le refactoring, car il nous faudra effectivement changer les tests en même temps que le code de production. L'écriture des tests peut être fastidieux en plus, vu la quantité d'éléments à doubler (constat fait par exemple lors du JUG Bordelais sur le sujet

Dans une approche classique, comme nous testons la plupart du temps le comportement extérieur, nous nous moquons éperdument de l'implémentation, pour vu que le résultat soit bon, et nous passons également moins de temps à écrire nos doubles.

Je ne fais que répéter ce que vous savez sans doute déjà, mais demain, c'est le grand jour. Après plusieurs mois de préparation, voici que l'Agile Tour passe demain par le Labri.

Si tout se passe bien et que vous êtes inscrits, vous avez du recevoir les derniers détails par mail, sinon, nous commençons à accueillir tout le monde à partir de 9h (avec un petit déjeuner et du café pour faire bonne figure).

A 14H, nous aurons la joie avec Charles Couillard de faire une présentation/démonstration de TDD, qui espérons le sera instructive.

Je n'ai pas grand chose à ajouter, si ce n'est de dire que demain est l'aboutissement d'une belle course de fond que j'ai apprécié faire avec les autres organisateurs.

Michael a été plus rapide que moi pour faire un retour sur notre visite hier chez nos parains de Toulouse. Mais qu'à cela ne tienne, je m'en vais vous faire un petit compte-rendu de ma journée, sachant que nous n'avons de toute manière pas suivi nécessairement les mêmes séances.

L'organisation

Déjà, je tiens à féliciter, s'ils me lisent, les organisateurs, qui ont fait que cette journée s'est passée sans accroc, avec beaucoup de café, jus d'orange et autres petits gâteaux. A cause d'eux, nous voilà en train de réviser nos plans pour la semaine prochaine, c'est malin En plus, ils ont du être agile face à l'adversité en décalant l'XP Game de deux heures dans une nouvelle salle. Le timeboxing des sessions étaient parfait également.

L'IUT de Blagnac qui nous accueillait a vraiment de très beaux locaux en plus, très bien adapté à cet événement.

Les sessions

Voici mon petit programme de la journée :

• Café
• Les promesses de l'agilité, par Jean-Marie Damas
• Introductions aux Core Protocols, par Emmanuel Etasse
• Café, viennoiseries
• L'agilité dans une SSII, par Guillaume Saint-Etienne
• Repas équilibré donc, à base de crêpes et de flanc de légume en ce qui me concerne
• Café
• Dojo TDD, par Jean-Marie Damas et Olivier Azeau
• Café et petits gâteaux divins
• Enseigner l'agilité, par Jean-Michel Inglebert
• Muscat et Olives

Les promesses de l'agilité

Pas grand chose à ajouter par rapport au retour de Michael. C'était une présentation ciblant les gens ne connaissant pas trop l'agilité, mais mettant bien en avant les "obligations" pour réussir la transition, à savoir adhérer à l'éthique agile.

Introduction aux Core Protocols

Je n'avais jamais eu que des retours indirects, et j'avais d'ailleurs un à priori très négatif sur eux, ayant le sentiment qu'ils sclérosaient la communication en l'enfermant dans un carcan. Premier constat donc, c'est que mes critiques finalement s'appliquaient plus aux implémentations particulières qu'aux protocoles eux-même, qui ne figent pas grand chose apparemment.

Ensuite dans le fond, je pense que je reste tout de même sur mon idée que la communication induite par les protocols n'est pas des plus naturelle. A la rigueur, je pense qu'ils peuvent servir à construire une équipe rapidement avec des personnes qui ne se connaissaient pas, mais passé une certaine période, on peut en abandonner une grande partie. Certains bien sûr gardent de la valeur : j'utilise régulièrement le decider, car il permet de trancher une décision sans s'éternier dans des débats stériles.

Le centre de cette session était plutôt le Perfection Game, que nous avons donc eu l'occasion d'appliquer par groupe de 6 après avoir jugé une magnifique interprétation d'Hotel California par notre orateur C'était sympathique, mais encore une fois, je ne suis pas sûr de voir l'utilité d'encadrer ces échanges du moment qu'on discute entre personnes matures et raisonnables.

Agilité en SSII

Encore une fois pas grand chose à ajouter à ce qu'a dit Michael: très bonne présentation, carré avec de bons arguments. Seul bémol peut être sur une question finale concernant les RAO : la réponse était un peu en déphasage face à la réalité, car on ne connaît pas le budget des clients à ce moment là.

Dojo TDD

A, là, je me suis éclaté Enfin, c'était peut être une auberge espagnole cette session : on y trouvait ce qu'on apportait. Le sujet proposé était l'implémentation d'une calculatrice, qui malgré son apparente simplicité pose pas mal de questions de design, et en tant que membre de la anti-if campaign, je me devais de me passer de switch :D (Frédéric ne pourra pas dire le contraire).

Bref, moi je me suis éclaté car c'est du code, et j'aime ça, et car je pairais avec quelqu'un de moins expérimenté, et j'ai adoré discuter des détails d'implémentation où de l'approche TDD.

Bien entendu, la session à la fin a eu son lot de sceptique, mais comment les blâmer? Il est clairement pas évident de lâcher ses vieilles habitudes d'upfront design et de s'appuyer avec une confiance presque aveugle sur les tests. Je ne suis pas devenu l'extrémiste que je suis du jour au lendemain.

J'ai beaucoup aimé aussi pouvoir comparer donc cette forme de Dojo avec celle que nous animons avec Charles Couillard la semaine prochaine à l'AT Bordeaux. Nous ferons une démonstration plutôt qu"une session ouverte, et je suis curieux de pouvoir comparer les réactions du public.

Enseigner l'agilité

Je n'enseigne pas l'agilité moi même, enfin pas dans un cadre de cours, et j'étais donc assez curieux de savoir comment on pouvait transmettre les valeurs agiles, finalement très pragmatiques quand on s'est déjà confronté à quelques échecs, à des étudiants vierges de toute expérience. Pour résumer, je citerai l'orateur : "Enseigner les tests à un débutant, c'est comme enseigner l'humour à quelqu'un qui commence l'anglais". Je paraphrase assez mal, mais c'était ça l'idée : tester est un art subtile, et il est utopique de l'enseigner à de parfaits débutants. Par contre il semblerait qu'arriver en L2, là l'approche gagne le coeur de pas mal de monde. Peut-être est-ce donc une lueur d'espoir pour l'avenir? Nous pouvons rêver d'un monde où tous les développeurs pratiqueront les tests, dès la sortie de l'école, où les gens ne pratiquant pas tdd seront regardés comme des bêtes curieuses et dangereuses

Je fais assez souvent la réflexion que le métier des SSII s'est dégradé, volontairement ou pas, par rapport aux principes d'origine. J'ai tendance à penser que le rôle premier d'une SSII est de savoir faire des logiciels sur mesure, et mener les projets donc jusqu'à une fin heureuse pour tout le monde. Ceci est bien entendu la vision idéaliste, mais je pense qu'il est censé correspondre à la majorité des cas. La plupart du temps, les clients ne savent pas ce qu'ils veulent, ni comment l'obtenir, et c'est tout à fait notre métier de savoir pourtant extraire un logiciel d'autant de chaos. Il n'y a pas à se plaindre de cet état de fait, c'est une composante normale de notre profession, et s'en indigner est juste une réaction puérile et irréaliste.

Pourtant, ma propre expérience des SSII a prouvé plutôt que le client, ne connaissant pourtant rien à la construction de logiciels, pouvait demander n'importe quoi, même l'échec, car "le client est roi". Le rôle de conseil et d'accompagnement qui me semble indispensable s'est transformé dans la grande majorité des cas en une sorte d'intérim très cher qui produit globalement pas grand chose par rapport au prix investi.

Maintenant, voilà que j'ai deux retours de forfaits ou le client a explicitement demandé l'utilisation de TDD dans le développement de son logiciel. Je ne m'en réjouie pas. Voilà que le client est obligé de demander la qualité contractuellement? Obligé de demander à la SSII de faire son travail, car sinon il sait qu'il va obtenir quelque chose en papier mâché? TDD n'est pas une pratique à négocier, dans un sens ou dans l'autre, mais une obligation pour tout développeur professionnel. Il n'y pas à demander au client, ou à la SSII s'ils sont d'accord pour le faire, c'est une pratique de professionnel au même titre que nous tentons de garder le design propre, de nommer correctement les variables, etc etc. Donc je considère ces deux cas comme un pas de plus dans l'inversion de contrôle qui s'est opéré dans la profession : Les clients n'ont plus seulement à dicter la gestion de projet, mais également les pratiques de développement. Quel savoir-faire reste-il à la SSII?

Quel mal tout de même a été fait à la profession pour que le niveau de confiance soit réduit au point de demander contractuellement ce qui semble aller de soit : la qualité et la fiabilité.

Voilà un titre de billet bien pessimiste, surtout venant de quelqu'un co-organisant l'agile tour bordeaux, et pratiquant quotidiennement XP.

Laissez moi expliquer un peu mon pessimisme actuel. Commençons par deux exemples concrets : au cours de deux conversations différentes, avec deux clients différents, voilà les retours que l'on peut avoir en abordant le sujet de l'agilité :

• "L'agilité, oui on connaît, mais on est beaucoup plus pragmatique que ça nous"
• Ou bien : "L'agilité? oulala non mon bon monsieur, on veut faire les choses simplement nous".

Ces deux réactions sont authentiques, et même si je ne veux pas tirer de deux exemples une généralité, je me pose cependant la question suivante : Comment, alors que l'agilité avait pour but premier de revenir à des choses simples et pragmatiques, comment maintenant a-t-elle l'image de quelque chose de compliquée et éloignée de la réalité?

Mon embryon de réponse n'est pas neuf, mais je vais tout de même essayer de le résumer. Faisons un peu d'histoire voulez-vous? La première méthode agile, alors que le mot agile n'existait pas, était l'eXtreme Programming. Cette méthode avait ça d'assez magique à mes yeux, qu'elle réconciliait le développement avec la planification et la valeur métier. La première de XP Explained est assez explicite :

"Extreme Programming is about social change"

La première idée est donc de réussir à oublier nos anciennes habitudes, désapprendre ce que nous croyions être la bonne approche, et commencer à envisager notre manière de faire d'un oeil plus adulte. Peut être que l'habitude qui a le plus de mal à passer, c'est la sacro sainte séparation entre développeurs et chef de projet/architectes etc etc. Ce besoin compulsif d'être au-dessus des autres, et par la même de les prendre de haut : "oui môôôa tu comprends, je ne fais plus de technique, je suis chef de projet". Pourtant, le manifeste agile est là pour nous rappeler que "les meilleurs architectures, design ou spécifications émergent d'équipes auto-organisées". Le fait que cette phrase soit issue du manifeste, et non pas d'XP, montre qu'elle est normalement universelle : le manifeste est un consensus obtenu entre des professionnels n'entretenant pas nécessairement les mêmes visions.

Au fil des années pourtant, la mode a été de s'éloigner du pragmatisme et de la simplicité qui était le coeur de l'agilité. "On a pris du recul" diront certains, "on a théorisé" etc, etc. et finalement, c'est le bon vieux modèle pyramidale qui est revenu en force. Scrum, en enlevant les pratiques d'ingénierie pour ne garder que le planning a réintroduit cette idée de séparation entre le "management" et le développement. Le rôle de Scrum Master, quoi qu'on en dise, est un rôle de manager dont l'utilité dans une équipe auto-organisée est vraiment discutable. Ensuite, le rapprochement a été fait avec Lean, avec plus ou moins de bonheur. Même s'il y a des choses intéressants à prendre dans Lean, il ne s'agit en aucun cas d'une méthode agile applicable tel quel au monde de l'informatique. Pourtant maintenant c'est très à la mode de ne plus dire qu'on est agile, mais dire qu'on fait du lean. Prenez pour exemple cette vidéo. On y voit en fait, une présentation d'XP, de bout en bout, sans jamais le citer. Alors je ne doute pas que cette équipe fonctionne très bien, mais il n'empêche que cette vidéo est un mensonge : la clef de leur succès provient d'XP, pas du Lean.

Alors pourquoi est-ce que je tiens tant toujours à ramener XP sur le devant de la scène? Car l'agilité perd son sens, et les mauvais retours se multiplient d'équipes qui n'ont pas réussi à mettre en place l'agilité, car on leur a fait croire que ça ne demander pas de changements de techniques, ou une discipline d'ingénierie en acier trempé. Je reviens toujours à la charge, car c'est l'agilité qui va mourrir, du moins dans cette forme là, si autant de gens continuent à la répendre en passant à côté de ses concepts fondamentaux. Oui j'ai rencontré des architectes dans leur tour d'ivoire, des chefs de projet, des sociétés entières, se disant agile, alors que l'équipe de développement n'en avait même pas entendu parler. La diffusion sémantique fait son travail, et il me semble donc indispensable que de loin en loin, certains fassent des piqûres de rappel, pour demander "R U doin it rong?". Je pense que c'est le but premier du Craftsmanship manifesto.

Ce qui devient vraiment dommage dans cette histoire, c'est que nous tenions enfin une vision unifiée de collaboration de tous les acteurs nécessaires à la réussite d'un projet, l'abolition d'un sectarisme corporatiste, mais hélas, nous revoilà à nouveau face à la guéguerre "les techies vs les chefs", et ça, ça me rend vraiment triste. Est-ce qu'il sera jamais possible à grande échelle de dépasser ce réflexe puérile du "mon poste est plus gros que le tien?".

L'agilité va disparaître, mais XP finalement, restera en trame de fond pendant bien longtemps, car en fait, c'est déjà le cas

Voilà un titre bien obscure. Alors de quoi allons parler aujourd'hui? De la manière la plus simple que je vois actuellement de commencer une application web en java. Il y a quelques semaines effectivement un ami me demandait finalement quoi utiliser pour démarrer un projet de 0 e, avec comme postulat de base que finalement, tout était bien compliqué. Je vais donc décrire ici mes environnements/outils/frameworks favoris qui à mon sens, permettent de s'en sortir dans la grand majorité des cas, et tout en fournissant une base à la fois solide et extensible.

L'environnement

Avant même de commencer à développer, mieux vaut savoir comment nous allons développer. Je pense maintenant qu'il y a une base indispensable à tout projet avant même de penser conception et développement.

Build

Avec quoi construire notre appli? Ca a l'air bête comme question, mais ce n'est en fait pas si simple dans le monde de java, ou tout n'est pas aussi intégré et monolithique que dans le monde .NET.

Par défaut, à peu prêt tout le monde utilisait Ant. Personnellement, je n'en peux plus: xml au kilomètre, dépendances gérées à la main, pas user friendly, bref, une horreur à mes yeux. Si vous lisez de temps en temps ce blog, vous devez vous douter que je vais proposer Maven. Avec maven, il va être possible en 2 lignes de xml d'avoir un projet entièrement compilé, testé, packagé. Les dépendances sont téléchargées depuis un entrepôt central, et il les gère en cascade, donc on ne passe plus des heures à linker ou mettre à jour les libs externes, c'est géré. Si on suit ses conventions, c'est bien simple maven permet de faire oublier une grande partie des tâches techniques de base d'un projet.

Une question qui peut venir et savoir comment organiser son projet dans maven: Multi module ou mono module? l'avantage du multi module est qu'il va garantir une séparation entre les couches, là ou le mono module si on ne fait pas attention peut entraîner un certain mélange. Ceci dit, la complexité du multi module au début ne compense pas ce risque hypothétique, et mieux vaut de toute manière enseigner qu'interdire. Donc, jusqu'à le projet atteigne une complexité trop importante, je préfère la simplicité du mono module tout en faisant attention à ne pas mélanger les couches.

SCM

Même si vous êtes seuls, il vous faut quelque chose pour conserver et versionner votre source, ne serait-ce que par sécurité et pour avoir la possibilité de revenir en arrière. Git a beau être une star montant, je ne le connais pas, et je vais donc me contenter de conseiller subversion: simple, efficace, et non intrusif (pas de lock par défaut sur les fichiers).

IDE

Certains puristes vont certainement dire qu'un éditeur de texte suffit pour développer, mais à mon avis, on est loin d'une productivité optimale. Voilà à mes yeux ce que doit ABSOLUMENT faire un IDE:

• intégrer les test unitaires : pouvoir les lancer facilement, et naviguer rapidement dans le code incriminé par un test rouge,
• refactoring : c'est à mon sens l'outil ultime de productivité et de qualité. Sans aides au refacto il est trop facile, par manque de courage ou de temps, de ne pas faire des changements pour clarifier le code. Pourquoi renommer une classe si ça nous prend 10mn de faire le tour de l'appli pour trouver ceux qui l'utilise? Pourquoi extraire une super classe et centraliser du comportement si c'est un long travail fastidieux de copier/coller? Voilà pourquoi je pense qu'il est juste indispensable qu'un IDE intègre un certain nombre de refactorings assistés
• auto-complétion, coloration, indentation: c'est la base, mais il est bon de le rappeler
• navigation rapide dans le code: il doit être possible d'ouvrir rapidement des types ou des fichiers, mais aussi depuis une classe par exemple d'aller directement dans le code d'un objet qu'elle inclue.

Il y aurait être d'autres choses à ajouter, mais c'est déjà pas mal. Les trois IDE les plus connus du monde java (Eclipse, NetBeans, Intellij Idea) assurent tous ces fonctionnalités en plus d'une intégration à Maven indispensable dans notre cas. Je ne vais pas rentrer dans des débats religieux sur lequel est le mieux, mais personnellement j'utilise Eclipse.

Intégration continue

Je pense que l'intégration continue doit être en place dans le premier jour du projet, il ne faut pas attendre de commencer à avoir des soucis pour la mettre en place. Le minimum est bien sur de compiler l'application et de faire tourner les tests.

Il existe maintenant pas mal de solutions gratuites, mais je dois avouer ma nette préférence pour Hudson, grâce à son esprit "on déploie et ça marche". C'est très simple à mettre en place, il marche très bien avec Maven, et il peut être étendu à souhait avec pas mal de plugins. Que demander de plus?

Les technos

Bien, nous avons la base pour commencer à développer, c'est bien, mais ça ne nous dit pas quels frameworks utiliser pour bâtir notre application web. Au risque de spoiler un petit peu, je vous annonce tout de suite que je ne vais pas conseiller JEE, même en version "simple" en n'utilisant que servlet/jsp.

Restlet

Voici un framework qui mériterait un billet à part entière, mais je vais essayer de faire un résumé. Le but de restlet est de servir de base pour produire et consommer des ressources conformément à l'approche Rest. Ce qui est bien avec ça, c'est que l'on peut commencer très simplement, en faisant une application "à l'ancienne" avec des pages html entièrement générées côté serveur, puis commencer à si on veut à faire plus du RIA, avec GWT, Flex, Dojo, peu importe, les ressources restent les mêmes, on négocie juste une représentation différente.

Comme je le disais, Restlet est très simple à mettre en place, pas besoin de conteneur de Servlet ou autre, il peut démarrer son propre serveur web en une seule ligne de code. Les ressources et la configuration se fait également entièrement dans le code, avec quelques recours très discret aux annotations. Bref, Restlet est une base idéale pour toute application web: il est multi-paradigme, peut grossir en même temps que votre application sans vous forcer une grande complexité dès le début, bref, je suis fan. Ah vous de choisir au début si vous voulez faire une application à l'ancienne, du GWT, du flex etc etc, Restlet supporte tout le monde de toute manière. Suivant ce que vous avez décidé, vous pouvez ensuite par exemple utiliser Freemarker ou Velocity pour générer la représentation html de vos ressource selon une approche MVC bien connue.

Hibernate

Ah voilà un choix plus discutable n'est-ce pas quand on cherche à définir les frameworks les plus simples pour démarrer n'est-ce pas? Le plus simple pourrait-on me dire, serait de directement se connecter à la base, et de faire nos requêtes. Le soucis avec cette approche, c'est que jamais elle ne sera capable de gérer correctement une grande complexité. On se retrouvera nécessairement avec du code mort, de la duplication et une très faible réutilisabilité du code. Ceci dit, il doit y avoir plus simple qu'Hibernate non pour accéder à nos données? Sûrement, mais là je vais devoir avouer que je suis complètement perverti par DDD, et je ne conçois pas de ne pas d'abord penser objet, tester, puis seulement ensuite de faire apparaître la base. Seul un mapper O/R par metadata mapping permet d'utiliser cette approche à 100% , et hibernate est la meilleure solution open source gratuite que je connaisse pour atteindre ce but. Ah mes yeux, et pour une fois, l'effort d'écrire et maintenir tout ce XML me semble complètement être compensé par la valeur: pouvoir écrire un modèle du domaine testable et indépendant de toute considération technique. Le point discutable est sans doute, dans le cadre d'une application juste CRUD, est-ce que ça vaut le coup de sortir l'artillerie lourde? Ma réponse habituelle est que je n'ai jamais connu en 7 ans d'applications qui faisaient simplement du CRUD, donc j'ai le sentiment que ce n'est pas la règle mais le cas particulier. De plus, comment savoir à l'avance que l'application ne fera QUE du CRUD quand on la commence?

Quelques remarques

Il y a bien entendu des critiques à émettre sur le choix des technologies de base, notamment sur la productivité. Il y a peu voir pas du tout de travail prémaché dans ce que j'ai proposé, pas de composants déjà utilisables rapidement, ou de scripts pour générer rapidement les "échafaudages", sans doute parce que je ne suis fan d'aucunes des technologies proposant ces options, car trop de choix me déplaisent dedans (Ruby on Rails et Grails sont très contraignants sur pas mal de points, tant ils font de choix pour nous, Wicket, JSF and co sont orientés composants et modèle par page et ne tirent pas partie à mon avis des avantages du web; Spring MVC est déjà plus sympa, surtout en version 3, mais c'est déjà beaucoup plus lourd que Restlet...)