BodySplash.fr

2 commentaires aucun rétrolien

samedi 20 novembre 2010

Bilan Agile Tour Bordeaux 2010

Par Jean-Baptiste le samedi 20 novembre 2010, 19:35 - Agilité

Je m'y prend bien tard, mais je me colle enfin à faire mon petit bilan de l'agile tour bordeaux, en tant qu'organisateur/orateur/spectateur. Je le fais bien sûr uniquement car je ne peux décemment pas faire mon retour sur l'Agile Tour Toulouse avant celui de Bordeaux

Organisateur

Le fait de nous y prendre très en avance ne nous a pas vraiment empêché de frôler plusieurs fois la catastrophe

Le programme a été très dur à monter : mélanger des sessions d'1h30, d'1h et 2h, c'était vraiment un sacré casse tête si on ne veut pas forcer les gens à rester dans la même salle toute la journée. Du coup, nous avons du mettre en concurrences certaines sessions que nous aurions préféré pouvoir proposé en suivant. Je pense qu'il va falloir que l'on revienne à un format plus homogène. Trouver un équilibre dans le niveau des sessions est également toujours un beau défis, mais l'agilité étant fondamentalement simple à apprendre mais excessivement difficile à digérer, je ne pense pas que l'on puisse vraiment proposer des sessions soit disant "pour experts". Soit on a la culture agile, et donc on sait que tout au plus, on va trouver à l'agile tour des pistes à creuser, soit on est au début du chemin, et dans ce cas l'agile tour va tenter d'insuffler les prémices de cet état d'esprit. L'Agilité s'acquiert sur une longue durée, et une journée comme l'Agile Tour ne peut en aucun cas remplacer un travail d'expérimentation et d'apprentissage de longue haleine.

Nous avons eu pas mal de demandes de sponsoring comme ça s'est vu. Je tiens bien à souligner que nous avons gardé une indépendance totale vis à vis d'eux: être sponsor ne donnait en aucun cas le droit de faire pression d'une quelconque manière sur le contenu de la journée. Le soucis du coup a plus été l'effet défilé pendant le mot du matin, nous verrons bien comment régler le soucis la prochaine fois.

Orateur

Je suis assez satisfait du retour d'expérience que Michael et moi avons animé. J'ai déjà écrit un retour à ce sujet sur le blog d'Arpinum, je ne vais pas trop y revenir. La difficulté tenait dans l'angle à adopter pour ce retour, car résumer 3 ans en 1h n'est vraiment pas évident. La vidéo, scindée en deux parties, est disponible avec les autres sur vcasmo.

Spectateur

Comme on peut s'en douter, je n'ai pu voir voir grand chose, ce qui est excessivement frustrant. J'ai tout de même eu l'occasion d'entamer quelques conversations intéressantes, même si parfois un peu écourtées.

Kata marrant, par la paire Gaillot/Perret :

Je ne pensais pas pouvoir autant rire devant un kata. J'ai eu littéralement mal aux côtes en les regardant. Il est juste dommage qu'il y eu une grosse baisse de régime au bout d'un certain temps, mais dans l'ensemble, c'était juste énorme. L'idée était donc de jouer un kata classique, mais y ajoutant toutes les 5 minutes des contraintes inventées par le public en les piochant au hasard. Cela a entrainé des moments épiques que j'aurais vraiment du mal à décrire correctement ici. Le reproche qui a été fait à cette session est que passé le côté fun, finalement elle ne servait à rien : impossible de convaincre un timide du tdd de se mettre à l'utiliser, et les vieux routiers ont bien ri mais n'ont rien appris. Personnellement, je ne suis pas d'accord. Déjà, il se trouve que si, une personne dans la salle a découvert le TDD par cette session, et a été bluffée. Ensuite, cette session je trouve a servi d'une sorte de piqure de rappel : il FAUT s'amuser en travaillant. L'opposé du travail n'est pas le jeu, mais l'oisiveté. S'amuser en travaillant est indispensable pour le rendre intéressant, et par la même nous permettre d'être plus productif, plus créatif et nous faire prendre le recul nécessaire à mieux appréhender les situations. L'auto-dérision, la curiosité et le

Stubs et mocks montent sur scène :

Voilà un atelier original animé par le très toulousain Olivier Azeau. L'idée est de faire jouer les différents composants intervenant dans un développement piloté par les tests par des personnes réels, permettant ainsi de mieux mettre en évidence leurs rôles, interactions et motivations. Honnêtement, je n'ai jamais attaché une grande importance à faire la différence entre les différents doubles de tests, et cette session m'a inculqué ce savoir sans douleur.

Bref

Et, voilà tout ce que j'ai pu voir. Le reste du temps, j'étais soit à l'accueil, soit en train de discuter avec quelques personnes, ce qui est d'ailleurs également un format fort intéressant. Cela me fait dire d'ailleurs que l'année prochaine il faudra vraiment que j'aille faire un tour à l'Open Space.

Je garde une bonne impression de cette journée : pas mal de monde, un beau lieu, des conférences que j'aurai toutes eu envi de voir, des conversations intéressantes et des gens sympas. L'Agile Tour est toujours l'occasion de croiser pas mal de monde que je ne vois pratiquement que là, comme la très sympathique équipe toulousaine qui je l'espère se reconnaitra . Nous allons bien sûr réfléchir à comment améliorer encore l'expérience l'année prochaine, et tous les retours sont les bienvenues à ce sujet là.

vendredi 17 septembre 2010

Frameworks productifs

Par Jean-Baptiste le vendredi 17 septembre 2010, 18:24 - Code

J'aimerai ici faire un billet pour faire une petite mise au point. Les frameworks "productifs" type RoR, Grails, Play! et j'en passe ont clairement le vent en poupe. L'idée au combien louable, est bien sûr d'automatiser au maximum les tâches rébarbatives du développeur lorsqu'il s'attaque à une application web. J'imagine que toute cette mouvance a pu naître d'un écoeurement bien naturel vis à vis des piles ou frameworks plus anciens, comme Struts, toute la pile JEE et même ASP.NET avec ses bons vieux WebForm.

Ce qui me chagrine dans l'histoire, c'est que philosophiquement, je suis de tout coeur derrière ces idées de simplifications : je n'ai jamais pu encadrer le xml au kilomètre de Spring à l'époque, les Web Form me faisaient faire des cauchemars tant leur opacité était grande et je n'ai jamais été pour une multiplication des couches sans une grande nécessité.

Ceci dit, ne jetons pas le bébé avec l'eau du bain. Je m'explique. Pour paraphraser Eric Evans dans DDD, la complexité d'une application réside dans le métier qu'elle tente de représenter. Comment cela se traduit? Pour moi, cela veut dire que quelque soit les frameworks que j'utilise, ils ne devront jamais entamer ma capacité à modéliser le métier. Le succès, la richesse et l'efficacité de mon application dépendent essentiellement de ma capacité à capter la subtilité du métier. Comment mettre le maximum de chance de mon côté? En développant le modèle en isolation de tout autre considération, à l'aide d'une approche objet, d'un bon framework de tests unitaires et de bons outils de refactoring. La présentation, la persistence, le cache, tout le reste est superflu et doit le moins possible, voir pas du tout, impacter mon domaine.

Bref, après autant de blabla, voilà donc enfin ce qui me chagrine dans ce que j'ai pu voir des quelques frameworks productifs que j'ai essayé : ils sont invasifs. Le choix d'Active Record pour la persistance est une friction dans le développement du métier, car la persistance n'est alors plus transparente. Pour respecter le principe de responsabilité unique, vu que les "entités" gèrent la persistance, nous devons développer les véritables objets métier à part, et ils doivent agréger alors ces entités. Cela implique une complexification non négligeable du développement du domaine. Du coup, beaucoup des exemples que j'ai pu observer se contentent de montrer une application CRUD, avec un métier anémique contenu dans les contrôleurs, mais aucune application n'est réellement du CRUD au final.

La véritable productivité est liée à la maintenabilité, et la maintenabilité est très liée à l'isolation du métier (et aux tests bien sûr ). Oui du coup, avec cette philosophie en tête sur Tiron, nous n'avons pas choisi un de ces beaux frameworks à la mode, et nous avons du construire notre propre pile (jQuery/Restlet/Freemarker/Hibernate pour les curieux), et je pense que notre productivité actuelle en considérant la complexité du métier que nous devons gérer n'a pas à pâlir face à la concurrence.

P.S : je ne suis pas un expert de ces frameworks je l'avoue. Si quelqu'un peut me démontrer le contraire de ce que j'avance, j'en serai très heureux.

Agile Tour 2010 Bordeaux

Par Jean-Baptiste le vendredi 17 septembre 2010, 09:30 - Agilité

Vous le savez sans doute déjà, mais cette année j'ai rempilé pour l'organisation de l'étape bordelais de l'Agile Tour.

Comme il est indiqué sur le site, l'évènement aura lieu le 7 octobre dans les locaux de l'ENSEIRB. Au programme, il y a un peu de tout, et j'espère que nous avons réussi cet équilibre difficile entre sessions techniques et sessions plus généralistes. Je vous laisse regarder ça et faire votre marché.

Enfin, n'oubliez pas que comme l'année dernière, même si l'inscription est gratuite, elle n'en est pas moins obligatoire pour nous aider à mieux préparer la journée. Donc, inscrivez-vous

mercredi 9 juin 2010

Le secret de la productivité

Par Jean-Baptiste le mercredi 9 juin 2010, 14:20 - Code

Je vais peut être enfoncer une porte ouverte pour certains, mais j'ai envi de parler du secret si bien gardé par les grands professionnels pour être productif avec un IDE : les raccourcis clavier! Oui, c'est ironique, mais l'année dernière lors de la session TDD, et plus récemment suite à d'autres retours, j'ai été assez étonné des remarques du genre "ah je ne savais pas qu'on pouvait faire tout ça avec Eclipse". Un des intérêts premiers d'un IDE est tout de même de nous aider à faire les tâches de base du développement :

autocomplétion
refactoring
exécution des tests
navigation facile dans les sources
assistance contextuelle

Oui, je ne met pas sciemment tout ce qui est éditeurs WYSISYG, car leur utilité est finalement assez anecdotique et bien souvent alourdissent les IDE pour rien tout en étant pas si productif que ça. Ils sont d'ailleurs peut être la cause majeure qui fait que pas mal de gens n'aiment pas les IDE. Ceci dit étant dit, même si la plupart des fonctionnalités citées plus haut sont accessibles par la souris, leur usage ne devient systématique et efficace à mon avis que si on les associe à des raccourcis claviers.

Prenons un petit cas d'exemple. Imaginons que j'ai écrit un test ressemblant à ça (désolé, je ne me suis toujours pas motivé pour mettre en place une coloration syntaxique sur ce blog):

@test
public void peutRécupérerNomComplet() {
    Client client = new Client();

    assertThat(client.nomComplet(), is("prenom nom");
}

au plus simple, le code pour faire passer ce test est le suivant :


public String nomComplet() {
   return "prenom nom";
}

Cette méthode est un appel au refactoring, car il y a duplication entre la méthode de test et la méthode de production (la constante est répétée). Je vais peut être vite en besogne, mais nous devons alors faire apparaître du coup le nom et le prénom. Pour éviter d'être verbeux plus longtemps, voici une petite vidéo pour montrer comment je m'y prend en m'appuyant sur les capacités d'Eclipse:

(Si jamais la vidéo ne s'affiche pas, vous pouvez toujours allez directement ici)

Il y a bien sûr plusieurs chemins pour arriver au même résultat, mais j'espère que si vous n'utilisez pas souvent les raccourcis clavier, les refactorings ou les aides à la génération alors cette vidéo vous aura convaincu d'essayer de vous y mettre un peu plus. Beaucoup de développeurs reprochent aussi aux IDE leur lourdeur. C'est parfois justifié (je ne citerai personne), mais dans cette vidéo, avez-vous vous eu l'impression qu'Eclipse était lent et se mettait sur mon chemin?

mercredi 2 juin 2010

Blog Arpinum

Par Jean-Baptiste le mercredi 2 juin 2010, 14:36 - Le projet

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é.

mercredi 17 mars 2010

Tiron

Par Jean-Baptiste le mercredi 17 mars 2010, 12:42 - Le projet

Je ne l'ai peut-être pas encore assez crié sur tous les toits, mais Tiron est sorti dans sa première version publique. Plus besoin de parler Du Projet, je peux maintenant officiellement l'appeler Tiron, même si le mot avait déjà du m'échapper. Ceci n'est bien entendu pas la fin, finalement en terme de rythme de développement, ça ne change pas grand chose pour nous, modulo bien entendu certaines nouvelles tâches très marranteS comme maintenir le site de présentation, faire le support et déployer la nuit. A ça bien sûr il faut ajouter les joies du marketing et de la communication, car c'est bien d'avoir un bon produit, mais c'est mieux si tout le monde le sait.

Si vous avez suivi un peu ce blog, vous savez sans doute qu'un des objectifs premiers, avant même de penser à une exploitation commerciale, était de mieux nous former à l'agilité, et à XP en particulier. Et oui, il a plus de deux ans maintenant nous n'étions pas les extrémistes que nous sommes aujourd'hui. Même si nous avions déjà acquis un certain nombre de pratiques d'ingénieries, il nous manquait beaucoup du second côté de la pièce : la gestion du projet et la planification. On peut dire que de ce point de vue, l'objectif de Tiron est pleinement atteint. Nous avons non seulement très largement consolidés nos pratiques, mais nous avons également énormément appris sur la planification et la négociation avec le product owner. La particularité bien entendu du rythme de développement était que nous ne travaillons tous ensemble que deux demi-journées par semaine, et ce mode particulier a bien entendu beaucoup influencé Tiron. Tout d'abord, car le temps était très précieux, donc la priorisation par la valeur et toujours faire le plus simple qui fonctionne a été cruciale pour sortir quelque chose dans un temps raisonnable; ensuite nous avions du coup énormément de temps pour réfléchir sur nos décisions, ce qui n'était pas toujours un avantage d'ailleurs. Maintenant que nous avons une démarche commerciale, cette agilité sans concession nous fournit certains avantages sur la concurrence. Nous sommes réactifs, il n'y a moins de gaspillage (globalement toutes les fonctionnalités sont utilisées), et nos coûts de développement et d'exploitation sont inférieures nous permettant de pratiquent un prix plus attractif.

La nouvelle grande difficulté maintenant est que l'équipe est seulement partiellement à temps plein, et synchroniser le travail fait "le soir" et le travail de la journée est assez épineux, sans compter les soucis de rythme soutenable et de diffusion de la connaissance.

Pour conclure, bien sûr nous attendons de voir le succès que va remporter notre logiciel, mais l'agilité est clairement ce qui nous a permis de sortir un produit de qualité, concurrentiel et dans un délais raisonnable par rapport au temps que nous avions. Je pense que c'est un bon début de preuve empirique pour dire que rien n'est utopique, que non l'agilité et XP en particulier ne sont pas un ensemble de pratique ou l'en prend ce que l'on veut : l'agilité fonctionne vraiment à son plein potentiel que par la synergie de l'ensemble de ses pratiques, et bien entendu par les valeurs de ce qui la pratique.

samedi 6 mars 2010

Redécouvrir JavaScript

Par Jean-Baptiste le samedi 6 mars 2010, 20:49 - Code

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

mardi 19 janvier 2010

Atelier "Embrassez le changement"

Par Jean-Baptiste le mardi 19 janvier 2010, 21:56 - Agilité

J'essaye de rattraper le retard pour faire un rapide retour sur un atelier animé par Colin Garriga-Salaün, membre très actif et bien connu des bordelais d'Okiwi ^[1]. Donc oui j'ai beaucoup de retard, car on parle tout de même d'un atelier du 4 janvier, et rapide non pas car je n'ai pas aimé, mais car il est difficile d'en parler sans spoiler son contenu.

Du coup, le but de ce bilet va plutôt être de tenter de vous convaincre d'aller le voir quand Colin va le refaire ^[2].

En ce qui concerne le déroulement, la soirée s'est divisée en 4 parties :

Présentations de différents modèles de changement
Jeu de l'oie modifié ^[3]
Debriefing libre et commun
Bières

oie

La présentation d'ouverture était peut être un peu dispensable, mais le jeu et sutout les réactions après coup valaient vraiment le détour. Je ne peux pas en dire trop, mais j'ai appris des choses sur des notions que j'aborde rarement comme le conditionnement culturel ou la force de l'habitude (entre autre). En plus, j'ai mangé des carambars.

source photo

Notes

[1] Co-organisateut de l'Agile tour Bordeaux 2009. Site ici

[2] pas de date fixée pour le moment, juste une promesse du principal concerné

[3] Plus de détails chez Satir Workshop, mais garre aux spoilers

lundi 18 janvier 2010

.NET vs JEE

Par Jean-Baptiste le lundi 18 janvier 2010, 12:42 - Code

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é.

lundi 21 décembre 2009

Intégration continue

Par Jean-Baptiste le lundi 21 décembre 2009, 18:26 - Le projet

Ce billet n'est pas nécessairement dès plus intéressant, mais je ne me peux pas m'empêcher de partager avec vous notre dernier petit plaisir sur Le Projet :

Ce petit boitier posé sur ma bête de course est donc notre serveur d'intégration flambant neuf. Je tiens à vous en parler car il nous a juste coûté une petite centaine d'euros, et il ne consomme pratiquement rien en électricité. En ces temps de développement durable et de crise économique, c'est toujours bon à prendre.

La configuration est à base d'intel Atom 330 et d'un boitier antec qui va bien. Le tout a été complété par le don généreux d'un disque dur 2.5" 5400tr/min par Charles, et d'une barette de ram d'1Go de roxxor de Michael C'est donc pour ça qu'il ne nous a coûté que 100€. Disons qu'il faut ajouter 50€ si vous n'avez pas de pièces en stock.

La morale de cette histoire, et c'est ce qui a motivé mon billet, c'est que vous n'avez pas besoin d'une bête de course hors de prix pour votre intégration. Nous faisons tourner hudson, selenium, svn, nexus, postgresql et les deux applications que nous développons dans leur dernière version stable, en permanence sur une machine théoriquement très légère techniquement. Je vous rassure, le buid fait toujours moins de 10mn. Ce faible coût peut peut-être également convaincre votre hypothétique service d'achat frileux à investir le moindre euros dans votre équipe qu'il est possible de s'en sortir sans faire des chèques avec plein de 0. 100€ pour autant de valeurs, j'ai rarement vu un investissement aussi rentable.

P.S : je rassure le lecteur en disant, que non, nous n'avons pas attendu deux ans pour faire de l'intégration continue sur Le Projet, nous l'hébergions juste salement avec la prod.

mardi 8 décembre 2009

AppEngine

Par Jean-Baptiste le mardi 8 décembre 2009, 11:34 - Code

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

vendredi 13 novembre 2009

Vidéos de l'agile tour

Par Jean-Baptiste le vendredi 13 novembre 2009, 16:08 - Agilité

Choses promises, choses dues, quelques vidéos de l'Agile tour Bordeaux 2009 sont d'ores et déjà en ligne.

Voici, en deux parties, la session que nous avons animée avec Charles sur TDD.

Pour voir le reste des vidéos déjà en ligne, ça se passe par là

lundi 2 novembre 2009

Les deux écoles de TDD

Par Jean-Baptiste le lundi 2 novembre 2009, 16:37 - Agilité

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.

4 commentaires aucun rétrolien

vendredi 30 octobre 2009

Et voilà

Par Jean-Baptiste le vendredi 30 octobre 2009, 11:31 - Agilité

L'Agile Tour c'est (presque) fini pour 2009. Aujourd'hui, Strasbourg et Lille accueillent les dernières sessions, et ensuite, direction l'année prochaine.

Dans tous les cas, l'édition bordelaise s'est de moins point de vue, assez bien passée. Je n'ai pu pratiquement rien aller voir personnellement, mais le retours que j'ai glanés étaient tout de même assez positifs. Un peu plus de 150 personnes ont fait le déplacement pour profiter des viennoiseries et des sessions.

Certaines sessions ont eu plus de succès que prévu, et du coup, nous avons généré je pense un certain nombre de déçus. Nous essaierons de faire mieux l'année prochaine.

Il faudra aussi que je retienne ne pas réinstaller mon MacBook de zéro la veille d'une présentation sur TDD, car nous avons eu la joie de nous rendre compte en live de ce que j'avais oublié de reconfigurer. Ceci dit nous étions flattés de la vitesse à laquelle s'est remplie la salle, et de la présence d'Emmanuel Gaillot, grand stratiguerre des Dojos XP Parisens depuis 5 ans. Jean-Pierre Vickoff était également présent, nous avions donc beaucoup de pressions à avoir autant de sommités dans le public Si jamais toi lecteur hypothétique tu faisais partie de ces heureux élus, sache que je suis très friand de connaître tes retours. Je suis au courant de notre schizophrénie à faire partie de la Anti-If campaign alors que le design que nous avons obtenu à la fin de la session en était rempli

Il y aurait sans doute des milliers d'autres choses à dire, je vais m'arrêter là, en remerciant encore tous ceux qui ont rendu cette journée possible, et tous ceux qui ont fait le déplacement, montrant que l'agilité peut mobiliser les foules, même à Bordeaux.

P.S: allez, une photo bonus avec presque tous les orgas et orateurs :

mercredi 28 octobre 2009

C'est demain

Par Jean-Baptiste le mercredi 28 octobre 2009, 14:11 - Agilité

logo

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).

speaker 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.

2 commentaires aucun rétrolien

vendredi 23 octobre 2009

Arg

Par Jean-Baptiste le vendredi 23 octobre 2009, 14:23 - General

En changeant d'hébergeur, je pensais ne pas avoir de soucis vu que le nom de domaine restait le même, ainsi que le contenu et le moteur de blog. Mais hélas, j'avais oublié un détail qui avait son importance : j'avais laissé toutes URI au format Dotclear 1 lors de mon passage en v2, pour éviter justement que toutes les références google and co ne se mettent à pointer dans le vide.

Et là bien sûr, c'est le drame, car sur cette nouvelle plate-forme, je ne peux pas choisir le format ou un installer un plugin qui contournerait le problème. Voilà donc que plusieurs années d'indexation viennent de partir à la poubelle. Je me console comme je peux en me disant que maintenant, mes URI sont restfull.

Bilan de cette histoire, si toi hypothétique lecteur tu lis ceci car ton flux rss ne te donne plus de mes nouvelles, change ton abonnement, car l'adresse n'est plus la même.

Agile Tour Toulouse 2009

Par Jean-Baptiste le vendredi 23 octobre 2009, 11:02 - Agilité

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

mercredi 14 octobre 2009

Changement d'hébergeur

Par Jean-Baptiste le mercredi 14 octobre 2009, 11:10 - General

Je suis en train de changer d'hébergeur, donc il se peut que ce blog ne soit plus accessible pendant quelques jours.

J'avais pris un hébergement "gros" à l'époque, car je voulais héberger d'autres éléments, mais le fait est que 4 ans après, je ne tiens toujours que ce blog. Donc, adieu Online.net, qui devient trop cher, et bonjour Gandi.net, dont j'aime l'esprit depuis mal d'année, et qui font maintenant plate-forme de blog.

mardi 8 septembre 2009

Inversion de contrôle

Par Jean-Baptiste le mardi 8 septembre 2009, 10:40 - General

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é.