Fabien Bézagu

Claviers et dispositions

Au boulot, je passe souvent pour un extraterrestre. La raison ? J'ai un clavier différent. J'entends donc souvent les questions suivantes :

— « Qu'est-ce qu'il a de mieux ton clavier ? »
— « Ah oui, je connais, c'est un clavier BÉPO, c'est ça ? »
— « Il existe en QWERTY/AZERTY/BOUZANBA… ? »
— « C'est bien pour programmer ton clavier ? »

Je pars donc généralement dans de grandes explications — ce qui ne déplaît pas — mais j'ai parfois le sentiment de beaucoup me répéter et d'en oublier en route. Je m'adresse donc en tout premier lieu à toi, cher collègue, que je viens d'envoyer lapidairement sur ce billet ;-) Je reste bien entendu ouvert aux questions.

Un clavier est un clavier

Tout d'abord, je tiens à corriger une erreur très fréquente. Un clavier AZERTY n'existe pas. Un clavier BÉPO n'existe pas. Un clavier QWERTY n'existe pas. C'est clair ou je continue ? Comme dirais nos amis anglais : un clavier est un clavier est un clavier. Tout ce que fais un clavier, c'est envoyer un code technique indiquant la touche qui vient d'être appuyée. Par exemple, la touche la plus à gauche de la première rangée a le code <AD01> sous Linux. Ce code n'a rien à voir avec ce qu'il peut être imprimé sur cette touche par votre fabricant. Qui n'a jamais appuyé sur cette touche en espérant voir un « A » apparaître et voir un « Q » s'afficher ?

Ok, un clavier est un clavier. Mais il y a bien des différences non ? Bien sûr. L'impact, le ressort des touches, le toucher, l'emplacement des touches sur le clavier, la largeur, hauteur, etc. sont autant de critères permettant de choisir son clavier. C'est vrai que le mien est « différent » :

Sans entrer dans le détail ni le discours commercial, ses avantages sont :

  • petite largeur pour plus de place pour la souris
  • petite hauteur et pas d'inclinaison pour éviter aux poignets d'être cassés
  • alignement orthogonal
  • touches Entrée et Effacement au centre

Pour plus d'info, c'est un TypeMatrix.

Dispositions

Une fois le clavier branché, il faut dire au système d'exploitation quelle disposition utiliser. Une disposition n'est ni plus ni moins qu'un tableau associatif entre code de touche et lettre à afficher :

  • <AD01> -> A
  • <AD02> -> Z
  • <AD03> -> E

La disposition la plus répandue en France est l'AZERTY. C'est une version adaptée du QWERTY mais je vous laisse lire cette petite BD pour connaître son histoire : http://www.dvzine.org/. Des alternatives existent, notamment la disposition BÉPO dont le but est de dresser une carte plus adaptée pour une langue ou une utilisation précise.

Si vous m'avez bien suivi jusque là, vous avez compris que le clavier que vous avez sous les yeux peut tout à fait vous servir à taper avec la disposition BÉPO ! Génial non ?

Personnellement, j'ai réappris à taper sur un clavier en 2008 en utilisant la disposition BÉPO et le TypeMatrix en photo plus haut.

Et la programmation ?

Oui, question récurrente : « Est-ce que la disposition BÉPO est adaptée pour programmer ? ».

Réponse courte : est-ce qu'AZERTY est adapté pour programmer ? Et QWERTY ?

Je n'ai pas de certitude dans ce domaine. Je ne suis pas certain de voir les avantages de rester en AZERTY dans ce domaine spécifique. Quelques développeurs jurent qu'il faut passer au QWERTY. Les IDE et les langages de programmation ont été créés avec QWERTY en tête, j'en suis convaincu. Cela veut dire que les caractères spéciaux et les raccourcis seront peut-être un peu plus accessibles avec cette disposition. Ce que je sais également, c'est que le projet BÉPO est né d'un milieu plutôt geek composé de nombreux développeurs qui ont pris en compte ces besoins particuliers. Je ne dis pas que c'est la panacée mais je trouve l'accès à plusieurs caractères que j'utilise souvent très pratique ({, }, (, ), [, ], ~, \, |, etc.)

Conclusion

J'espère que maintenant vous saurez bien faire la différence entre clavier et disposition. Le site http://bepo.fr est un point d'entrée d'une richesse incroyable pour découvrir ces aspects trop méconnus de l'ergonomie du poste de travail. Pour finir, mon conseil : quelle que soit votre disposition, apprenez à taper en aveugle !

JUG Summer Camp 2010

Le vendredi 10 septembre prochain se tiendra une journée de conférences à La Rochelle : le JUG Summer Camp. Je pense que j'y serai rien que pour le plaisir de revoir mes anciens collègues de Serli, une des rares société à m'avoir laissé un souvenir positif et que j'ai quitté avec regret. Serli est sponsor principal de l'évènement.

Conférence Agile France 2010

Lundi et mardi dernier se tenait la Conférence Agile France 2010. Mon but dans ce billet, cher lecteur, est de ne pas te faire perdre ton temps. Je vais donc partir du postulat que tu ne veux pas savoir tout ce qu'il s'est dit, mais ce que j'ai pensé et retenu des sessions auxquelles j'ai assisté. Tout ceci se fera donc en toute subjectivité.

PNL (Programmation Neuro Linguistique) - Bruno Sbille

Le triangle dramatique, composé de la victime, du sauveur et du persécuteur, est intérressant. J'y ai retrouvé plusieurs situations familières. Les points à retenir, c'est qu'on peut tour à tour endosser plusieurs de ces tempéraments et que, quoi qu'il arrive, ils sont tous à bannir d'une équipe, même le sauveur.

DDD (Domain Driven Design) - François Wauquier et Nicolas Martignole

Mon but était essentiellement de préparer une présentation similaire à l'Agile Tour Bordeaux. Je pense qu'ils sont allés un peu trop loin en voulant parler des patterns stratégiques et qu'ils n'ont pas assez creusé les points de recouvrement avec XP. Mon sentiment est donc mitigé sur cette présentation.

Commencer petit pour finir grand : l'art de la construction incrémentale - Étienne Charignon

J'ai beaucoup apprécié cette session présentée avec humour et fébrilité. Des dessins des enfants d'Étienne apportaient notamment une touche humaine.

Il a introduit le concept des abstractions qui fuient. Le terme "fuir" est une traduction de leaky mais il a aussi pensé à "transpirer", que j'aime bien, parce que la transpiration, ça pue. L'idée est que les abstractions posent parfois problème car on doit se préoccuper de ce qui est derrière. Enfin c'est ce que j'ai compris. Ce que je ne suis pas certain d'avoir compris, c'est le rapport avec la conception incrémentale. Mais c'était bien. J'ai aussi retenu qu'on devait se satisfaire de son niveau de connaissance de confort. À défaut, on se retrouve très vite dépassé.

10 leçons apprises en rétrospectives - Stéphane Hanser et Emmanuel Gaillot

C'était une piqure de rappel bienvenue sur l'importance des fondamentaux. Les plus importants selon moi :

  • avoir un processus stable permet d'expérimenter,
  • il est très important de clarifier les positions de l'équipe sur des sujets polémiques qui se transforment régulièrement en bataille rangée entre deux protagonistes virulents,
  • il faut garder des tests automatisés légers, quitte à mocker ou sortir les tests d'intégration,
  • afficher une ou deux pistes d'amélioration par itération,
  • rester volontairement vocalisé, notamment en diminuant les blagues et autres digressions au moment des rétros et des démos,
  • intégrer le remboursement de la dette au processus de développement,

Agilité sous contraintes - David Brocard

Je passe. Rien à retirer.

Kata Robozzle en Haskell - Emmanuel Gaillot

Super moment passé à regarder Emmanuel développer ce kata. Propre, sans bavure. Je ne connaissais pas du tout Haskell et je ne me suis pas senti perdu un instant.

Self-help for Self-Organising Teams - Esther Derby

Je ne suis pas sûr d'avoir pu retirer tout ce que je pouvais de cette keynote car elle était en anglais, et c'est chaud de rester concentré. J'ai retenu que les équipes heureuses l'étaient toutes la même façon (petite, approche commune, humaines...) tandis que les équipes malheureuses l'étaient chacune à leur façon. Dans ces dernières, on retrouve souvent des schémas répétitifs qu'il faut casser et le premier endroit où commencer, c'est soi-même.

Satisfaire complètement son client avec le Problem Driven Development - Régis Médina

Comment résumer une heure de pur plaisir ? Allez, je me lance. Les méthodes agiles, c'est mieux que le cycle en V MAIS, il faut, en plus de faire un logiciel qui fonctionne, faire un logiciel qui satisfait le client. Il ne faut donc pas faire littéralement ce que dit le client, sinon on fait une usine à gaz. Une première idée intéressante est donc de demander à son client, pour chaque histoire livrée 1) si elle est conforme à sa demande et 2) si elle le satisfait. Attendons-nous à des surprises. Le métier du client n'est pas le développement et il est donc de notre ressort de pouvoir le conseiller et de lui apporter des solutions à son problème. C'est le principe du Problem Driven Development (PDD) : résoudre complètement le problème du client. Pour cela deux principes :

  • PDCA,
  • le gemba : réflexe d'aller voir dans les faits.

Il est important de savoir ce que veut réellement le client. D'une manière générale, il ne veut pas qu'on lui fasse perdre son temps (muda) et que la solution qu'on lui apporte lui permette de réduire son lead-time (temps d'utilisation du système pour un problème donné). Il faut que ce temps soit le plus court possible : "No service is good service". Finalement, il y a un déplacement de l'approche "on ajoute de la valeur" à "on résoud efficacement son problème". Régis a ensuite longuement parlé de l'importance de mesurer, de voir, de constater par soi-même grâce à des tests d'utilisabilité. Tout cela m'a rappelé les propos de Steve Krug dans "Je ne veux pas chercher". Enfin, il nous a parlé des deux malédictions qui pesaient sur nous, pauvres développeurs :

  • malédiction de la connaissance : nous connaissons trop bien notre système pour nous mettre à la portée de ses utilisateurs,
  • mélédiction de l'ignorance : nous ne connaissons pas assez bien le problème de l'utilisateur.

Bravo Régis, super présentation.

Consensus workshop - Thi Lan Huong Le

Il s'agissait d'un atelier pendant lequel nous avons mis en oeuvre une méthode pour répondre à une question très ouverte. Je résiste pas à l'envie de mettre une image qui résume la méthode :

Le consensus reste cependant assez frustrant sur un plan individuel même s'il faut reconnaître l'efficacité pour obtenir une réponse...consensuelle.

Le modèle d'acquisition des compétences de Dreyfus - Emmanuel Hugonnet

J'ai retenu la définition de cinq profils : le novice, le débutant avancé, le compétent, l'efficace et l'expert. Tout cela était présenté autour d'une métaphore sur la conduite automobile. Emmanuel a beaucoup insisté sur l'importance de ne pas forcer les experts à suivre des règles car cela est contre-productif pour eux qui fonctionnent à l'instinct et qui doivent pouvoir casser les limites pour innover.

Réussir ses projets à coûts, délais, périmètres et qualité fixes - Bernard Notarianni

Quand on prône un changement fort, ça grince. Bernard a voulu une session dynamique en laissant la parole à qui voulait la prendre. Et les débats ont fusé. La solution qu'il propose est très intérressante : le client fixe le délai et le coût, les développeurs définissent le périmètre et la qualité qui, évidemment, est au maximum. Le prérequis pour que ça marche est que les développeurs soient en contact avec le client. Le problème, c'est qu'on ne peut prendre n'importe quel développeur pour ça. Une des idées que j'ai trouvé pertinente, c'est que les développeurs peuvent, s'ils ont besoin, s'adresser à une équipe d'expert métier qui n'est pas en frontal avec le client et qui vient donc en support des développeurs. Le client n'est en effet pas forcément un expert du métier.

Conclusion

Ces deux journées ont été intensives mais valaient le coup. Pour résumer, je retiens trois leçons :

  • les agilistes renommés sont des valeurs sûres,
  • je vais m'intéresser au lean prochainement,
  • je me ferai quelques katas en programmation focntionnelle, juste pour voir (haskell ? clojure ? ocaml ?).

ROA et DDD

L'histoire retient des couples légendaires : Roméo et Juliette, Bonnie and Clyde, le pâté et le saucisson... Je suis aujourd'hui convaincu que ROA et DDD ont leur place parmi ces couples légendaires.

Parmi les livres que j'ai lus cette année, c'est indiscutablement RESTful Web Services qui m'a le plus apporté. En deux mots, puisque ce n'est pas le sujet de ce billet, ce livre prône la simplicité en montrant que HTTP est suffisant pour créer des services web puissants sans ajouter de complexité inutile. Il introduit également Resource Oriented Architecture (ROA) qui est une approche pour créer des services web RESTful en mettant les ressources au coeur de l'architecture.

Plus je m'imprègne de ROA, plus je suis frappé par les parallèles qu'il est possible de faire avec DDD.

Des objets, encore des objets

Avec une conception orientée par le domaine (DDD), le paradigme objet est totalement utilisé. On pousse au maximum l'imbrication des données et des méthodes qui travaillent sur ces données. On cherche à modéliser le métier au travers de design patterns adaptés (stratégie, spécification, composite...). A contrario, les services (un objet qui fait plutôt qu'un objet qui est) doivent être utilisés avec parcimonie.

Il en est de même avec ROA. Cette approche s'oppose en effet à un style Remote Procedure Call (RPC) à la façon de SOAP, Corba et les autres. La procédure fait quelque chose et je me permet de citer le livre :

A resource is something, so I take an object-oriented approach to designing resouces. In fact, the resource-oriented design strategy could be called "extreme object-oriented."

Ah ! Qu'ils sonnent bien à mes oreilles ces deux termes mariés ensemble (je vous avais dit que je parlerai de couples légendaires).

Avec une architecture orientée services (SOA), ce sont les procédures qui sont mises en avant et il est alors légitime de vouloir y associer une approche RPC comme les WS-* (manière de désigner les gros services web à base de WSDL et de SOAP, qui n'a de simple que le nom).

ROA et DDD se marient parfaitement pour mettre en avant les entités et les objets du domaine.

URI et identité

En DDD, on reconnaît une entité car elle est identifiable. Deux entités différentes auront des identités différentes. HTTP s'appuie sur le même type de concept : l'identifiant uniforme de ressource (URI). Chaque ressource est ainsi identifiée de manière unique.

Il est également très important de ne pas confondre la ressource et son identifiant, pratique malheureusement largement répandu qui consiste par exemple à mélanger joyeusement la référence d'un client et le client lui-même. L'URI découle de la modélisation d'une ressource, pas l'inverse.

Associations et connectivité

Pour naviguer dans un graphe d'objets complexe, DDD incite à modéliser les relations qui existent entre les entités via des associations. Les entités sont connectées comme dans un grand réseau, oserai-je dire toile ? Ça y est j'ai osé ! La connectivité est ce qui a permis au Web de devenir aussi riche et populaire. Sans lien, chaque ressource serait condamné à vivre sa vie isolée des ressources qui lui sont voisines. Là encore DDD et ROA sont vraiment similaires.

Conclusion

Je n'ai fait qu'effleurer le sujet et je suis sûr qu'on peut trouver beaucoup d'autres similitudes entre ROA et DDD. Ces deux approches sont, à mon avis, très similaires et complémentaires. Elles sont basées sur la modélisation de la complexité tout en restant très simple. En parlant de simplicité, je ne résiste pas à l'envie de recopier la citation en préface du livre sus-cité :

A complex system that works is invariably found to have evolved from a simple system that worked.
John Gall, Systematics

Ne m'appelez plus Mister

Sous ce titre douteux, j'aimerais faire un petit rappel des règles et usage concernant la dénomination des personnes.

Régulièrement, je me retrouve dans des situations où je constate que les règles typographiques, de bienséance et légales ne sont pas respectées. Régulièrement, il m'arrive de faire aimablement (ou pas) remarquer ces erreurs, voire de me battre pour les faire corriger. Malheureusement, quasi systématiquement, on me répond la phrase que vous avez tous entendu : « Ahhh...C'est l'informatique !!! »... Y en a marre !

Comme je suis vaguement bien placé pour le savoir, derrière l'informatique, il y a des...informaticiens. Et pas n'importe lesquels : des développeurs. Donc, chers camarades développeurs, c'est à vous que j'adresse cette supplique : arrêtez de vous assoir sur les règles du français !

Nom d'usage et nom de famille

Je vais d'emblée tordre le cou à une croyance tenace : sauf cas exceptionnel, une personne ne change jamais de nom.

Il existe des usages qui permettent de porter un autre nom que celui qui nous a été transmis à la naissance :

  • une femme mariée a le droit d'utiliser le nom de son mari ou l'accoler au sien,
  • une célébrité peut prendre un pseudonyme qu'elle utilisera au quotidien,
  • dans d'autres cas plus marginaux ou que je ne connais pas.

Cependant, et malgré l'utilisation d'un nom d'usage, le nom de famille ne change jamais. Il existe deux types de nom :

  • le nom de famille, celui qu'on a tous à la naissance,
  • le nom d'usage.

Toute autre type de nom n'existe pas sur un plan juridique. Par exemple :

  • nom de jeune fille
  • nom patronymique

Le nom d'usage est un choix personnel et ne doit ni être imposé, ni être empêché. Pour l'anecdote, ma femme ne porte pas mon nom et je ne peux pas m'empêcher de vous relater cet échange surnaturel entre ma femme et une personne digne de François Pignon :

« - Vous êtes mariée ?
- Oui.
- Quel est le nom de votre mari ?
- Bézagu.
- Votre nom c'est donc Bézagu, c'est ça ?
- Non, c'est Grimaud.
- Ah, vous n'êtes pas mariée alors !
- ... »

Dans le bon ordre SVP

Lorsqu'il est utilisé, le prénom doit être placé avant le nom de famille ou d'usage.

Comme le terme l'indique le prénom vient avant le nom. Si des listes doivent être affichées dans l'ordre alphabétique des noms, cela ne pose pas de problème tant que cela n'a pas de répercussion sur des courriers qui pourraient par exemple être automatiquement générés.

Ne m'appelez plus Mister

Cette partie est la plus controversée et concerne l'usage de l'abréviation pour « Monsieur » « Mr » au lieu de « M. ». Comme le souligne l'article Wikipédia, la recommandation actuelle est bien d'utiliser uniquement « M. ».

Il convient donc d'écrire : « M. Jean Dupont ».

Majuscules et accents

Seules les premières lettres du prénom et du nom doivent être en lettres capitales (j'ai d'ailleurs appris cela en écrivant ce billet donc ne me hurlez pas dessus si j'ai fait la faute par le passé, je ne la ferai plus).

Si une ou plusieurs de ces lettres prend un accent en minuscule, celui-ci ne doit pas être perdu avec le passage en majuscule.

Exemple : Éric Épée

Cela vaut également pour le « C cédille » : ç donne Ç.

Conclusion

Comme le dit un collègue, je suis un peu le Jean-Pierre Coffe de l'informatique. Tant pis. Mais si nous tous, développeur, pouvions faire un effort pour respecter ces quelques règles, on verrait peut-être moins souvent des âneries devant nos écrans et dans nos boîtes aux lettres.

Jouons à TDD

Voici une façon ludique de s'entraîner à TDD, technique pas forcément évidente au premier abord.

  • Joueurs : 2
  • Âge : 7 à 77 ans
  • Genre : Collaboratif
  • Matériel : un ordinateur, xUnit et un langage au choix

Dans les règles qui suivent le joueur le moins expérimenté sera appelé Kevin et le joueur ayant un peu plus d'expérience, Yoda.

Déroulement de la partie :

  1. Kevin se fixe un objectif secret qu'il ne dévoile pas à Yoda,
  2. Kevin écrit un test trés simple,
  3. Yoda fait passer le test de la maniére la plus bête possible,
  4. Kevin a alors le choix :
    • Il considère que son objectif est atteint et la partie est terminée,
    • Il complète son test avec une nouvelle assertion,
    • Il écrit un nouveau test.
  5. Si la partie n'est pas terminée, on revient à l'étape 3.

Ce type de partie est très enrichissante et il n'y a ni vainqueur ni vaincu. Yoda veillera juste à calmer le jeu lorsqu'il sentira que Kevin commence à sérieusement s'énerver (ce qui ne manquera pas d'arriver) en lui rappelant que ce n'est qu'un jeu.

		

Campagne Anti "If"

I have joined Anti-IF Campaign

J'aime pô les "if"s !

Agile Tour à Bordeaux

L'Agile Tour 2009 passera par Bordeaux !

Je fais partie du comité d'organisation et j'essaierai de relayer les informations donc restez à l'écoute. Si vous avez des questions, des suggestions ou envie de mettre la main à la pâte, n'hésitez pas à me contacter.

Dvorak

Je suis en train d'apprendre à taper en dvorak. Késako ? Pour faire court, il s'agit d'une disposition de clavier plus adaptée que l'azerty. Une petite bande-dessinée explique tout ça très bien : DVzine.

Un wiki en français très complet m'a permis de réellement me lancer et j'ai choisi mon prochain clavier.

Quel rapport avec l'agilité ? Tout ! Et en particulier :

  • Amélioration continue,
  • Acceptation du changement,
  • Qualité de vie.

PS : j'ai tapé ce billet en dvorak alors ne m'en voulez pas de ne pas être entré dans les détails :-D

56% du projet inutiles

Je me suis livré à une expérience naïve (ou pas) avec un projet sur lequel je travaille actuellement.

Et si j'essayais de supprimer tout ce que je peux sans faire passer un test au rouge ?

L'expérience interdite

J'ai donc fait une copie de mon projet et j'ai commencé mon labeur destructif. Je ne me suis donné qu'une limite : ne pas supprimer les pom.xml des projets. Hormis cela, j'avais quartier libre : le code Java, les annotations Spring MVC, les fichiers de configuration Hibernate, les pages JSP, les pages HTML, les images (très peu), le web.xml...

Environ deux heures plus tard, les tests claironnaient toujours que tout allait bien... Mais j'avais tout de même supprimé 248 fichiers (environ la moitié), 56% de la totalité du projet (en octets) étaient repartis dans le chaos électronique de mon PC et le projet dans son ensemble était aussi utile qu'un anorak dans le Sahara.

Motivations

Avant de tirer des conclusions sur ces résultats, je suppose qu'il faut que je revienne un peu sur les raisons qui m'ont poussé à faire cette expérience.

Tout d'abord, ce projet est né d'une volonté de montrer les bienfaits des pratiques d'Extreme Programming dans un contexte idéal et sans compromis. TDD est une des pierres angulaires de ces pratiques. Ecrire chaque test avant de coder permet d'éviter une dérive classique que tout développeur a déjà rencontré : le bazar ! Parce que les tests donnent le courage de changer la structure du code sans crainte d'introduire des régressions. Pour en revenir à mon projet, nous avons récemment souffert d'un bazar croissant dans la partie Web engendrant des bugs que les tests n'ont pas vu.

La deuxième raison, c'est que vendredi dernier, j'ai regardé cette vidéo de Bob Martin (dit Uncle Bob). Une claque. Une bonne claque qui remet sur le droit chemin en rappelant les règles de bases. Dont celle-ci : tout code écrit doit être justifié par un test rouge.

Digression sur les outils de couverture

A ce stade de mon billet, j'ai droit à ma sempiternelle digression. Que le lecteur qui souhaite passer son chemin ne s'en prive pas ;-)

Sur ce projet j'ai fait apparaître la couverture des tests grâce à un outil de mesure de couverture, en l'occurence Emma. La couverture mesurée par Emma sur chaque module du projet est affichée clairement dans Hudson : selon le module, la couverture du projet oscille entre 90 et 99% ! Etonnant, non ?

Pour tirer des informations valides d'un tel outil, un minimum de compréhension et de recul est requis. Pour mesurer la couverture, Emma "instrumente" le code en insérant des drapeaux qui sont levés lorsqu'un test passe par le code. Comment pourrait-il faire plus ? Un code peut donc avoir une excellente couverture sans qu'aucune assertion ne soit faite en sortie. Il est très facile de tricher avec ce genre d'outil.

Dernier point : Emma est bien sûr incapable de vérifier autre chose que du code Java et c'est en partie le drame.

La seule information valable à retirer d'une telle mesure est la suivante : les zones non couvertes ne le sont vraiment pas et les zones couvertes le sont peut-être.

Et maintenant ?

Soyons clair : la plus grosse partie de l'application que j'ai pu supprimer, c'est l'application Web. Sans le fichier web.xml déjà, un serveur d'application comme Tomcat ne peut plus rien faire. Ensuite, il y a le cas des pages JSP qui sont difficilement testables.

Mes question actuelles sont les suivantes :

  • Peut-on avoir une démarche TDD pour vérifier la sortie correcte du HTML par le serveur d'application ?
  • Tomcat, qui prend plusieurs secondes à démarrer, est-il adapté pour faire du TDD où les tests sont exécutés tout le temps ?
  • Est-ce qu'en testant les sorties des pages Web et en simulant des envois de formulaire, on fait encore des tests unitaires et pas des tests d'intégration ?
  • Est-ce que c'est important de distinguer test unitaire et test d'intégration ?

Je n'ai pas de réponse définitive à toutes ces questions et je serais très curieux d'avoir des retours d'expérience sur ces points.

Allez, pour finir, je ne résiste pas à l'envie de recopier un petit dicton glâné ici :

Si ça vaut la peine d'être construit, ça vaut la peine d'être testé.

Si ça ne vaut pas la peine d'être testé, alors pourquoi tu perds ton temps dessus ?

Geetitude et regexp

Alimenter mon blog avec des trucs de geek, vraiment, c'est n'importe quoi.

Mon jeu du moment ? Ecrire des expressions régulières pour refactorer mon code :-D Les possibilités de recherche/remplacement fournies avec Eclipse sont très puissantes. Pour preuve, voici mon dernier refactoring (quoique là franchement, je sais pas si on peut encore appeler ça un refactoring) :

Rechercher :

^.*new ([a-zA-Z]*Stat)((.*)\);$\n^.*setDate((.*)\).*$\n
^.*Repositories.stats\(\).add.*$\n

Remplacer par

\tRepositories.stats().add(new $1($2).withDate($3));\n

Le premier qui me donne un exemple avant/après gagne...pas grand chose parce que bon 1) j'ai rien à offrir et 2) faut vraiment se vanter de savoir lire ça ???

Grosse brute

Ma brute recrute des élèves !

Fluent NHibernate

Magnifique ! C'est le premier mot qui me vient à l'esprit lorsque je vois cette nouvelle API.

Cette bibliothèque permet de remplacer les fichiers XML de mapping NHibernate par du bon vieux code .NET. Les avantages sont clairs :

  • Compilation du mapping, puisque c'est du code,
  • Meilleure testabilité, puisque c'est du code,
  • Refactoring assisté, puisque c'est du code.

Pour en savoir plus et voir quelques exemples de mapping :

Un petit portage en Java serait parfait pour montrer à de nombreux développeurs qu'il n'y a pas que XML dans la vie ;-)

Tableau d'information

J'aime partager mes petits plaisirs. Le dernier en date est un tableau qui nous permet d'afficher les histoires utilisateurs (le nous en question n'est pas très important mais pour la petite histoire, il s'agit des personnes impliquées dans LE projet). Voici la bête :

Pour refaire la même chose à la maison, il vous faut :

  • un tableau en tissu (une trentaine d'euros); les dimensions de celui-ci sont de 120 par 90.
  • des fiches bristols 75x125 (un euro environ les 100)
  • de l'auto-agrippant adhésif (plus connu sous le nom de Velcrow). J'insiste sur le côté adhésif sauf si vous êtes suffisamment joueur pour coudre du carton !

Il suffit ensuite de coller un petit morceau d'auto-agrippant au dos de chaque histoire :

(désolé pour la qualité de la photo mais je n'ai pas réussi à faire mieux)

En conclusion, pour une somme raisonnable, nous avons un système d'affichage des histoires super pratique car les histoires s'enlèvent et se remettent au tableau très facilement.

Planning eXtreme Programming

Le titre de ce billet est le titre de mon nouveau livre. Je viens de le recevoir ce soir et je ne résiste pas à faire partager à mes nombreux lecteurs (je m'emballe un peu là non ?!) mon plaisir de feuilleter un livre neuf, la douceur du papier, la qualité de l'impression.

A première vue, celui- est de bonne facture, les dessins agrémentant les chapitres très jolis (j'ai cru reconnaître ce cher Martin Fowler au coin du feu en train de raconter une histoire).

J'essaierai de faire un compte-rendu de ma lecture dans quelques temps.