Databases overkill !

Beaucoup d'applications développées de nos jours souffrent d'avoir été basées à priori sur une architecture avec une base de données. Cette décision systématique est la cause de grand maux. Cela faisait un moment que cette réflexion me démangeait, mais je n’arrivais pas à en sortir quelque chose. C’est parfois comme ça quand l’émotion occupe trop le champ. Comme cela m’énerve que les bases de données aient une telle “légitimité”. Et voila que je viens de lire le dernier poste de Martin Fowler.

Comment traduire "user story" en français ?

Qu’est-ce que c’est qu’une “user story” ? Dans les projets agiles, on ne commence pas par écrire un document de spécification dans une phase initiale qui serait ensuite suivie par une phase de réalisation et enfin de validation. Non. A la place, on initialise une liste de “user story”, ou “histoires utilisateur”. Dans la stratégie SCRUM, cette liste s’appelle un “product backlog”. Ces “histoires utilisateur” sont de petites descriptions très courtes d’un besoin utilisateur.

Lire du code

Qu’est-ce qu’on apprend en lisant du code ? Il existe 5 raisons qui font que le code est ce qu’il est : - limitation de la machine - limitation du langage - limitation du programmeur - historique - specification (at last!) «There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at the code from the outside rather than by reading it.

Un coding dojo aux Valtech Days 2008

Avez-vous déjà observé un dessinateur en action ? Avez-vous déjà ressenti la fascination de voir apparaître quelques traits qui ne semblent avoir aucun sens puis finalement, de voir le dessin surgir comme par magie. Étant le fils d’une dessinatrice de bandes dessinées, j’ai souvent observé ce phénomène. Je l’ai remarqué aussi en voyant par exemple Cabu dessiner quelques Grand Duduche en direct à la télévision. Quand je regarde un dessinateur, je me rends compte qu’il utilise certaines techniques spécifiques pour obtenir son dessin.

Developpement Web en Java !

Java bean Spring bean Hibernate bean web bean service bean backing bean … Ça y est, j’ai une métaphore pour mon application : c’est un cassoulet !

La programmation defensive n'est pas agile

A votre avis, qui est le plus agile ? Le chevalier avec ses 90 kg d’armure ou le paladin en tunique avec sa hache ? Supposons qu’au cours de l’écriture de mon programme je rencontre soudainement le besoin d’une fonction d’affichage. def affiche (a, b) Supposons, dans un premier temps, que je sois sûr que cette fonction n’est jamais appelée avec des paramètres nuls. Deux tactiques sont possibles ici: -* Programmation défensive: -** J’écris un test unitaire pour vérifier que ma méthode affiche bien a et b dans le cas où ils sont tous les deux non nuls -** J’ajoute immédiatement dans le corps de ma fonction, au début, quelques lignes de code pour retourner une exception si l’un des deux paramètres est nul1.

Dans la vie, on peut parler de ce qu'on ressent.

Ce soir, je lisais un livre très intéressant à mon petit bonhomme : “Tous différents” par Todd Parr. Je me suis en particulier arrêté sur la page suivante: On peut parler de ce qu'on ressent Voila quelque chose qu’on oublie trop facilement dans les projets professionnels. Par exemple, que penser d’un chef de projet qui insisterait pour être vouvoyé ? Ne serait-ce pas le meilleur moyen de fermer ce type de communication ?

Ne pas tapper sur le cycle en V! Ça fonctionne.

L'agilité à ses balbutiements, avant même que le manifeste agile ne soit écrit, c'est à dire avant que le terme "agile" ne soit inventé, était identifiée par l'intitulé "processus légers" (lightweight processes) par opposition aux processus classiques de type cascade ou cycle en V qui se trouvaient de fait qualifié de "lourd" the founding of the agile alliance. Connaissez vous l’histoire de Galilée telle qu’on la raconte aux élèves de collège ?

Retour d'Agile Open France

Extraordinaire ! Voila mon sentiment général au retour de cette conférence de 2 jours et demi. Il s’est passé quelque chose pendant ces quelques jours. malheureusement, pour les lecteurs qui aimeraient bien comprendre, je n’ai pas d’autre réponse à donner que “il fallait venir”. Ce type d’évènement apporte directement aux participants “là où ça les chatouille”. C’est la magie de l’auto-organisation qui a opéré, magie en partie due à l’extraordinaire largeur de la bande passante d’une communication orale et spontanée entre personnes passionnées par le même sujet.

AgileOpen France

Mercredi, jeudi et vendredi, je serais à AgileOpen France, une conférence au format OpenSpace Technologie (en français Forum ouvert) sur le thème des méthodes de développement logiciel agiles. Cette conférence sans orateur identifié, ni programme préétabli, réunira très certainement de nombreuses personnalités de l’agilité francophone. Cela promet d’être passionnant. L’inscription est encore possible.