Sara Ford fait quelques précisions intéressantes sur la terminologie en karaté et sur les éventuelles correspondances qu'on peut faire ou ne pas faire lorsqu'on parle de coding dojo :
Coding is not Kata
mercredi 8 septembre 2010
lundi 30 août 2010
Le consommateur n'est pas le client, c'est le produit
The consumer is not the customer, it is the product.
Autrement dit, lorsque nous utilisons, par exemple, Google, facebook, etc. nous ne sommes pas les clients de facebook. Nous sommes en fait leur produit, qu'ils vendent à leurs vrais client.
C'est une des très bonnes remarques faites par Bruce Shneier dans ce très court discours que je vous recommande : http://www.youtube.com/watch?v=I6ZkU2fUM5w
Autrement dit, lorsque nous utilisons, par exemple, Google, facebook, etc. nous ne sommes pas les clients de facebook. Nous sommes en fait leur produit, qu'ils vendent à leurs vrais client.
C'est une des très bonnes remarques faites par Bruce Shneier dans ce très court discours que je vous recommande : http://www.youtube.com/watch?v=I6ZkU2fUM5w
mercredi 25 août 2010
5 questions à se poser sur un projet
Voilà 5 questions à se poser pour diagnostiquer un projet que je voudrais retenir (parmi d'autres). Elles sont extraites du chapitre 2 de Crystal Clear: A Human-Powered Methodology for Small Teams d'Alistair Cockburn :
Have you delivered running, tested, and usable code at least twice to your user community in the last six months?
Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group’s working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?
Can you tell your boss you mis-estimated by more than 50 percent, or that you just received a tempting job offer? Can you disagree with your boss about the schedule in a team meeting? Can people end long debates about each other’s designs with friendly disagreement?
Does it take less than three days, on the average, from the time you come up with a question about system usage to when an expert user answers the question? Can you get the answer in a few hours?
Can you run the system tests to completion without having to be physically present? Do all your developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?
Have you delivered running, tested, and usable code at least twice to your user community in the last six months?
Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group’s working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?
Can you tell your boss you mis-estimated by more than 50 percent, or that you just received a tempting job offer? Can you disagree with your boss about the schedule in a team meeting? Can people end long debates about each other’s designs with friendly disagreement?
Does it take less than three days, on the average, from the time you come up with a question about system usage to when an expert user answers the question? Can you get the answer in a few hours?
Can you run the system tests to completion without having to be physically present? Do all your developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?
Alistair m'a tuer
Extrait du chapitre 2 de Crystal Clear: A Human-Powered Methodology for Small Teams d'Alistair Cockburn :
Even with the best of intentions, developers will work on things that only randomly bring business value if they are not told what will provide business value.
Je suis un peu désespéré de lire ça mais bon... heureusement il y a d'autres choses intéressantes à retenir de cet ouvrage.
Even with the best of intentions, developers will work on things that only randomly bring business value if they are not told what will provide business value.
Je suis un peu désespéré de lire ça mais bon... heureusement il y a d'autres choses intéressantes à retenir de cet ouvrage.
mardi 24 août 2010
agilité, auto-organisation, charrue et boeufs
The best architectures, requirements, and designs emerge from self-organizing teams. (http://agilemanifesto.org/principles.html)
Je suis 100% d'accord avec ce principe.
Mais attention à ne pas mettre la charrue avant les boeufs. Une équipe auto-organisée ne se décrète pas, elle se constate. On peut mettre en place les éléments qui lui permettront de s'auto-organiser, bien sûr, mais quels sont-ils, ces éléments ? Et qui les met en place ? Un leader ? Un manager ? Un chef ? Mais alors cette équipe est-elle auto-organisée ? Ou est-ce que ce qu'on appelle une équipe auto-organisée est simplement une équipe livrée à elle-même ?
J'ai peur que le principe ci-dessus soit parfois mal interprété :
- OK ! Il me suffit de les laisser s'organiser comme ils veulent et ils vont me pondre un super truc.
Ce qui est cher est souvent rare mais tout ce qui est rare n'est pas forcément cher.
Si ce principe nous dit que, souvent, les meilleures choses ont été produites par des équipes auto-organisées, il ne nous dit pas qu'il suffit de livrer une équipe à elle-même pour qu'elle produise les meilleures choses.
Dommage que, parmi les 12 principes du manifeste agile, celui de l'équipe auto-organisée revienne si souvent dans les conversations et celui-ci si peu souvent :
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Si j'étais cynique je dirais que c'est bien pratique, pour un manager, une équipe auto-organisée mais que, a contrario, trouver des gens motivés et accorder sa confiance, est un exercice infiniment plus complexe.
Je suis 100% d'accord avec ce principe.
Mais attention à ne pas mettre la charrue avant les boeufs. Une équipe auto-organisée ne se décrète pas, elle se constate. On peut mettre en place les éléments qui lui permettront de s'auto-organiser, bien sûr, mais quels sont-ils, ces éléments ? Et qui les met en place ? Un leader ? Un manager ? Un chef ? Mais alors cette équipe est-elle auto-organisée ? Ou est-ce que ce qu'on appelle une équipe auto-organisée est simplement une équipe livrée à elle-même ?
J'ai peur que le principe ci-dessus soit parfois mal interprété :
- OK ! Il me suffit de les laisser s'organiser comme ils veulent et ils vont me pondre un super truc.
Ce qui est cher est souvent rare mais tout ce qui est rare n'est pas forcément cher.
Si ce principe nous dit que, souvent, les meilleures choses ont été produites par des équipes auto-organisées, il ne nous dit pas qu'il suffit de livrer une équipe à elle-même pour qu'elle produise les meilleures choses.
Dommage que, parmi les 12 principes du manifeste agile, celui de l'équipe auto-organisée revienne si souvent dans les conversations et celui-ci si peu souvent :
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Si j'étais cynique je dirais que c'est bien pratique, pour un manager, une équipe auto-organisée mais que, a contrario, trouver des gens motivés et accorder sa confiance, est un exercice infiniment plus complexe.
vendredi 23 juillet 2010
SOAP-dust, un client SOAP en Java avec moins de 72 dépendances
La version 0.0.24 de SOAP-dust est disponible sur sourceforge.
Si vous développez en Java. Si vous êtes obligé de faire des appels SOAP vers des webservice externes. Si vous en avez marre de dépendre de 72 jar différents pour pouvoir faire un appel SOAP. Si vous en avez marre de devoir lancer un générateur de code Java avant de pouvoir faire un appel SOAP.
Alors SOAP-dust est fait pour vous. Tentez le coup.
La version 0.0.24 souffre encore de quelques défauts de jeunesse qui disparaitront rapidement. Mais elle est déjà utilisée avec succès sur plusieurs services en production et je pense qu'elle mérite donc qu'on y jette un oeil dès maintenant.
Amusez vous bien !
Si vous développez en Java. Si vous êtes obligé de faire des appels SOAP vers des webservice externes. Si vous en avez marre de dépendre de 72 jar différents pour pouvoir faire un appel SOAP. Si vous en avez marre de devoir lancer un générateur de code Java avant de pouvoir faire un appel SOAP.
Alors SOAP-dust est fait pour vous. Tentez le coup.
La version 0.0.24 souffre encore de quelques défauts de jeunesse qui disparaitront rapidement. Mais elle est déjà utilisée avec succès sur plusieurs services en production et je pense qu'elle mérite donc qu'on y jette un oeil dès maintenant.
Amusez vous bien !
mercredi 21 juillet 2010
Where Do Security Policies Come From?
Un article cité par Schneier qui tente de comprendre le lien entre les contraintes qu'un site web impose à ses utilisateurs pour la composition de leur mot de passe et la sensibilité des données stockées sur ce site : Where Do Security Policies Come From?
Au final il semble qu'il n'y ait aucun lien. Les sites qui imposent le plus de contraintes à leurs utilisateurs pour la composition de leurs mots de passes sont simplement les sites qui peuvent se permettre d'enquiquiner leurs utilisateurs sans risquer de perdre ces derniers au profit d'un autre site :
Our analysis suggests that strong-policy sites do not have greater security needs. Rather, it appears that they are better insulated from the consequences of imposing poor usability decisions on their users.
Une autre lecture instructive au sujet des mots de passe : Security Myths and Passwords.
Au final il semble qu'il n'y ait aucun lien. Les sites qui imposent le plus de contraintes à leurs utilisateurs pour la composition de leurs mots de passes sont simplement les sites qui peuvent se permettre d'enquiquiner leurs utilisateurs sans risquer de perdre ces derniers au profit d'un autre site :
Our analysis suggests that strong-policy sites do not have greater security needs. Rather, it appears that they are better insulated from the consequences of imposing poor usability decisions on their users.
Une autre lecture instructive au sujet des mots de passe : Security Myths and Passwords.
Inscription à :
Articles (Atom)
