jeudi 13 juin 2013
La France, c'est différent
mardi 11 juin 2013
La France, Gruissan et fin du congé de paternité
Martin qui fait du voilier |
Fromage fort qui pue en criss ! |
Saucisson à la cèpe à 20 euros (!!!) |
Port de Barcelone |
Villa de Gruissan |
2e journée á Barcelone
Parke Guell |
jeudi 30 mai 2013
3 jours á Barcelone
Hasta luego pour peut-etre d'autres histoires...
En direction de Barcelone
samedi 27 avril 2013
Citation du jour
Tiré de http://www.happiness-project.com/happiness_project/2009/09/secrets-of-adulthood/
lundi 4 mars 2013
Revue de film : Argo
mardi 26 février 2013
L'informatique : une formidable aventure humaine
vendredi 15 février 2013
Revue de film : Serge Gainsbourg, vie héroïque
mardi 12 février 2013
Revue de film : Trishna

Revue de film : La source des femmes

Un psychologue comme scrum master
vendredi 25 janvier 2013
lol... Dernière citation de programmeur lue
Always code as if the guy maintaining your code would be a violent psychopath and he knows
where you live.
jeudi 24 janvier 2013
Le concept de la métaphore d'Extreme Programming est également un vieux concept
Et oui, les 2 derniers post sont tirés de l'article The Humble programmer écrit par Edsger W. Dijkstra en 1972. C'est fou comme un invente rien...
Quiz : qui a écrit ça ?
On est pas loin du concept de TDD...
Mise à jour (4 février 2014)
Je viens de lire ceci dans un article sur le TDD :
An early reference to the use of TDD is the NASA Project Mercury in the 1960's (Larman and
Basili 2003). Je ne suis pas allé vérifier. Je suis quand même conscient que l'état d'esprit à l'époque était tellement différente que ça n'a probablement rien à voir mais je trouvais ça intéressant de le mentionner.
dimanche 22 juillet 2012
Le patron de conception "Dependency injection"
Management 3.0
Intelligent control appears as uncontrol or freedom. And for that reason it is genuinely intelligent control. Unintelligent control appears as external domination. And for that reason it is really unintelligent control. Intelligent control exerts influence without appearing to do so. Unintelligent control tries to influence by making a show of force.
What you are less aware of is that micromanagement - even if you intend it to be temporary - often prevents the workers from being able to self manage or otherwise show that they could handle more authority. So they continue to work in a dependent way (...)
Jurgen Appelo expliquant "The hidden Power of Social Networks"
They found that people's expertise is not the most important indicator of their performance. Instead, what actually makes a difference is their connectivity in the organization.
Cockburn
Given that much of the knowlege used in projects is tacit knowledge (undocumented and hard to transfert), the people in an organization need to share it through "osmotic communication" and working together. And therefore it is imperative that our software teams consist of people who want to share and work together.
dimanche 15 juillet 2012
Acheter de l'art
mercredi 11 juillet 2012
La théorie de la complexité et la société
mardi 10 juillet 2012
Se sentir connecté
mardi 17 avril 2012
La ligne du cycle de vie
Supposons que c'était possible de mesurer parfaitement tout le travail de plusieurs équipes, peut-être pourrions-nous définir ce qu'est du code impeccable, en faisant du "data mining" sur l'ensemble des différents codes source et en en extrayant les particularités communes. Je réfléchi tout haut. Je crois que nous connaissons déjà les caractéristiques générales du "beau" code. Bon. À approfondir...
vendredi 13 avril 2012
Toute l'histoire du monde
dimanche 8 avril 2012
Nouveaux blogs stimulants
mercredi 15 février 2012
L'absolu
mercredi 14 décembre 2011
Classique : Le manifeste du Parti Communiste
[...] la bourgeoisie depuis l'établissement de la grande industrie et du marché mondial, s'est finalement emparée de la souveraineté politique exclusive dans l'état représentatif moderne. Le gouvernement moderne n'est qu'un comité qui gère les affaires communes de la classe bourgeoise tout entière.J'ai presqu'une larme...
mardi 6 septembre 2011
mercredi 31 août 2011
T'es pas game...
vendredi 26 août 2011
Fast, Cheap, Good - Choose any two
dimanche 14 août 2011
Les langages spécialisés ou "niche languages"
The mythical man-month

En conclusion, ce livre est une sorte d'essai, réfléchissant et faisant le point sur la profession. Il m'a éclairé et montré une perspective très intéressante qui est, je crois, incontournable lorsqu'on s'intéresse au génie logiciel en 2011.
jeudi 11 août 2011
De la complexité des logiciels
Fascinant ! Probablement qu'un partie de la complexité que je rencontre dans mon travail vient d'une lacune de programmation de l'équipe mais il y a surement une partie qui pourrait être attribuable à un processus d'affaire mal optimisé.
In my experience most of the complexities which are encountered in systems work are symptoms of organizational malfunctions. Trying to model this reality with equally complex programs is actually to conserve the mess instead of solving the problems.
mercredi 10 août 2011
Code kata
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes from practicing; applying the theory over and over again, using feedback to get better every time.
How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.
But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions. source
Combien ça coûte mourir ?
Question du jour. Tout le monde sait que l'industrie funéraire ira probablement bien dans les prochaines années à cause de la courbe démographique que l'on connait. Étrangement, un peu comme pour l'industrie du mariage, les prix semblent uniformément et artificiellement gonflés. Imaginons que de nouveaux joueurs entraient dans ce marché et faisaient baisser les prix, croyez-vous que cela se passerait sans représailles ?
mardi 26 juillet 2011
Drogue : la guerre chimérique

vendredi 22 juillet 2011
Le choc de la décroissance

(23-juillet) Je viens de commencer à lire "Le développement a-t-il un avenir." Jusqu'à maintenant, c'est beaucoup plus scientifique et rigoureux. En comparaison, Vincent Cheynet parait plutôt démagogue et excité. Compte-rendu à venir.
lundi 11 juillet 2011
Revue de film : The tree of life

lundi 13 juin 2011
Les coopératives
mercredi 8 juin 2011
L'évolution
mercredi 4 mai 2011
Revue de film : Inside Job
mardi 12 avril 2011
La démocratie, la méritons-nous ?
mercredi 9 mars 2011
Construire des ponts
When your good idea meets resistance, you may be tempted to push your agenda harder, convinced you can enlighten your ignorant audience. But, telling everyone you have the perfect answer rarely makes believers out of them. Don't despair. Instead, ask people to participate in shaping your idea, rather than expecting their unconditional buy in. Connect with them on their terms. Tell them what your vision is and then invite them to critique and add to it. You'll need to be open to other solutions and let go of your certainty that you've got it right. Chances are it will become a better idea and you'll have more people on board to help you make it a reality.
Ça fait un bout de temps que je me demande comment faire pour améliorer ma capacité à convaincre les gens. C'est tellement vrai qu'il ne suffit pas d'avoir une bonne idée : il faut surtout savoir se mettre dans la peau de l'autre lorsqu'on essaie de la vendre. Je suis persuadé qu'une idée est mieux reçu lorsqu'on ne se sent pas bousculé ou en compétition.
lundi 7 mars 2011
De l'enseignement
samedi 5 mars 2011
Citation de Winston Churchill
mercredi 2 mars 2011
Ode a la programmation
lundi 21 février 2011
Le meilleur environnement de développement
Gérer, c'est coacher de Dany Dubé

Il va de soi que je le recommande chaudement à tous et j'espère qu'il vous touchera autant qu'il m'a touché moi.
samedi 19 février 2011
La démocratie détournée ?
The King's speech de Tom Hooper

Nouvelle citation
lundi 31 janvier 2011
Valeurs et principes de programmation
- Single responsibility
- Open-closed
- Liskov substitution
- Interface segregation
- Dependency inversion
Selon Kent Beck
Valeurs :
- Communication
- Simplicity
- Flexibility
- Local consequences
- Minimize Repetition
- Logic and Data Together
- Symmetry
- Declarative Expression
- Rate of Change
dimanche 30 janvier 2011
Les années-lumière : Le volcan de fin du monde
La catastrophe
Dans ce reportage donc, on y mentionne qu'il y a 250 millions d'années, 95% des espèces marines et 70% des vertébrés sont disparus de la Terre. Cette extinction massive serait due à l'explosion d'un important volcan en Sibérie, et à la combustion d'une énorme quantité de charbon qui était présent en quantité dans cette région à l'époque. On croit que cette extinction aurait duré plus de 500 000 ans (suivant l'irruption du volcan). Le charbon et le volcan combinés auraient répandu d'immenses quantités de CO2 et autres gaz toxiques que la mer aurait lentement absorbé et qui aurait acidifié les océans jusqu'à en tuer la majorité des espèces qui y pullulaient. C'est quelque chose qui semble plausible de se reproduire puisque les humains sont maintenant si nombreux à brûler des combustibles fossiles, et cela, en si peu de temps.
Nos valeurs désuètes
Quand je regarde autour de moi, quand je discute, je réalise que les enjeux planétaires sont bien loins dans nos priorités personnelles, incluant les miennes. Il est étonnant de constater tout le chemin parcouru depuis l'aube de l'humanité. Les états, les gens, la liberté, la technologie... tout cela a beaucoup changé. Les technologies nous permettent maintenant de communiquer avec une quantité phénoménale de gens en même temps, pourtant, il est plus difficile que jamais d'arriver à s'entendre alors que certaines ressources commencent à se faire rare compte tenu de la population actuelle. Autant, il peut sembler vertueux et grand de valoriser la liberté individuelle, et je serai le premier à admettre que j'en bénéficie, et pourtant, cela causera probablement notre perte. À travers cette quête incessante de profit (de survie?) individuel, cette compétition finira par nous faire tous nous entre-tuer pour les terres encore fertiles, pour l'eau encore potable et toutes les autres ressources d'une quelconque rareté.
Voyez-vous, ce n'est pas tant que nos valeurs ne sont pas les bonnes, elles sont seulement rendue plus ou moins inapropriées pour le contexte. Malheureusement, les valeurs qui autrefois nous ont sauvées la vie, peuvent maintenant nous la faire perdre. L'inertie de l'attachement non fondé à des valeurs désuètes est considérable et rend toute société aussi rigide et adaptable qu'un kiwi de Nouvelle-Zélande. On persiste à dire qu'il faut travailler fort, qu'il faut être compétitif (nos entreprises notamment). Moi, j'en arrive au seul constat possible : la compétition nous tuera tous au bout du compte. Réalisons-nous pourquoi il faut travailler fort ? Deux raisons, de prime abord. Premièrement, les gouvernements, c'est-à-dire, tout le monde, est endetté jusqu'au cou à cause des générations précédantes, de la non-prévoyance et, oui, de l'individualisme collectif des générations passées (et présentes). Maintenant, on travaille donc aussi fort que les "boomers" mais on a moins en retour. En second lieu, nous voulons conserver notre niveau de vie tout en étant en compétition avec le monde entier, qui en majorité, vie bien en dessous de notre seuil de la pauvreté. Tout ce beau monde nous regarde aller et veulent eux aussi vivre comme nous. Et c'est le cercle vicieux de la compétition... Et c'est pathétiquement comique de réaliser que nos gouvernements occidentaux sont endettés des milliers de milliards (!) de dollars. À qui ? Qui prête cet argent ? Mais qui donc s'en met à ce point plein les poches en intérêts ? Les banques, et quelques autres pays qui vont biens ... comme la Chine.
Comment cuire une grenouille... Ainsi que la conscience et le devoir moral
J'ai longtemps crû que d'être conscient de quelque chose me coinçait dans un espèce de devoir moral d'agir et le conflit m'a habité un bon moment. Aujourd'hui, j'admets que je n'y peux rien, il y a des forces qui nous dépassent et je ne crois plus qu'on peut éviter la catastrophe. Par contre, je trouve cela extrêmement triste. Ce constat désolant que nous allons inéluctablement, petit à petit, détruire notre unique lieu de vie possible connu, ou pire, nous achever en même temps, me rend triste. De la même façon que je suis face à la mort. Je me sens impuissant. J'anthropomorphie (si le verbe existait) la planète, comme si c'était un être humain qui allait mourir et je vis les mêmes émotions. Même si c'est probablement pour dans encore très très longtemps...
Incendie de Denis Villeneuve

vendredi 28 janvier 2011
Message à mes coéquipiers concernant la qualité de notre code
J'ai adressé cette lettre à mes coéquipiers dans l'espoir de faire monter d'un cran le niveau de qualité du code que nous écrivons. Pour le contexte, cette lettre est la réponse à un problème d'engagement que notre patron soulevait par rapports à nos meeting de scrum (un processus de gestion de projet) mais qui avait des ramifications plus profondes, comme on peut le constater plus bas. Je suis fier de cette lettre car je trouve qu'elle résume bien la situation, et que par celle-ci, je fais preuve de leadership.
On ne peut pas être contre la vertue. C'est évident que je suis d'accord avec toutes les propositions pour le scrum.
Toute cette réflexion par rapport à notre identité et notre rôle d'ingénieur logiciel m'a fait réfléchir sur notre travail. Je dois vous admettre que quelque chose me dérange dans notre façon de travailler. Ce n'est pas un blâme, parce que, d'abord, je suis le premier à admettre que j'ai besoin d'aide pour produire du code de qualité. Ceci étant dit, je trouve que la qualité du code qu'on livre, en général, laisse beaucoup à désirer. Le premier indice (bad smell) qui nous indique nous avons un problème, c'est la clarté, la lisibilité et la maintenabilité de notre code. Les métriques de qualité comme la maintenabilité et la clarté sont très difficile à mesurer. Mais pensez seulement aux nombre de fois, qu'on se demande qu'est-ce que fait une méthode, qu'est-ce que fait tel test, pourquoi est-ce que telle variable existe, pourquoi avoir choisi ce design... pourquoi les tests sont aussi difficiles à maintenir. Je pense qu'il faut avoir l'honnêteté intellectuelle d'admettre qu'on a de la difficulté. C'est seulement une fois que nous aurons admis cela que nous pourrons avancer. Ceci étant dit, j'ai quelques solutions à proposer :
Ownership du code et responsabilisation
Nous devons tous avoir l'impression que le code nous appartient. Nous devons nous sentir responsable de ce qu'on fait ET de ce que les autres font. Quand quelqu'un constate qu'une partie du code n'est pas à la hauteur, il faut que ça nous fasse quelque chose. Est-ce que ça ne vous choque pas de voir du code tout croche ? N'avez-vous pas l'impression que c'est intolérable de produire du code tout neuf qui est déjà indéchiffrable et mal conçu ? Il nous faut tous ressentir ça. C'est la conséquence directe de la possession de quelque chose. Quand ce quelque chose nous appartient, on veut en être fier et on veut l'entretenir. Excuse-moi Hugues, je sais que tu n'aimes pas être en vedette mais je vais te prendre en exemple. Tout comme Hugues, il faut qu'on ait tous la rage de rentrer dedans et refactorer sans pitié. Je le sens que Hugues a autant à coeur l'entretient du code que l'entretient de sa maison, parce que, pour lui le code est sien.
Ce qui m'amène à mon second point.
Peer pressure
Je crois que nous sommes beaucoup trop complaisants envers les erreurs. Pas les nôtres ! Celles des autres. Nous n'avons aucune difficulté à admettre nos erreurs , mais encore faut-il être capable de les identifier. Pour cela, le regard des autres est très utile. Par contre, il semble que nous ayons beaucoup plus difficulté à parler des erreurs des autres que des nôtres ! Comment peut-on apprendre si on ne se corrige pas mutuellement. Les collègues doivent absolument pouvoir servir de miroir, pour que l'image qu'ils nous renvoient de nous-mêmes et de notre travail, soit juste. Ce n'est pas notre boss qui va nous corriger sur le code, il ne code pas. Je vais citer un article que je viens de lire concernant les builds pétés:
One of the best solutions to the problem of people not checking their code before they check it in is peer pressure. Anyone who checks in code without compiling it first ought to feel embarrassed by such a mistake, and if not, the other people around them should strongly encourage them to feel embarrassed. Shame, it turns out, is a strong motivator for avoiding antisocial behavior. Like many—or perhaps all—of KV's suggestions, shaming can be taken too far, but I suggest you try it and see how it works.
Depending on Mommy to tell off the misbehaving kids becomes tiresome both for you and the project management after a while. What you want to see is a good working culture develop, one in which people know that breaking the build is like taking a dump in the middle of the break room; funny once, but usually unacceptable.
Je pense que ceci s'applique également à nous. Si on ne réagit pas lorsqu'on voit des conneries, on ne sera pas émotivement affecté et on cela ne nous poussera pas à changer nos mauvaises habitudes. Je crois franchement que s'il est vrai qu'on est une équipe, il faut être solidaire et être engagé et ça passe par le peer pressure. Mais pour avoir envie d'appliquer le peer pressure, il faut avoir à coeur la qualité du code qu'on produit donc l'étape 1 (ownership du code) est un prérequis. Pour favoriser le ownership du code, il faut touchez à toutes les parties du code et participer aux refactor des parties qui nécessitent d'être améliorées.
Ce qui m'amène à ma dernière suggestion.
Pair programming
L'expérience que j'ai gagnée à programmer en paire (en jumelage?) est incalculable et cela s'est confirmé en le faisant avec Hugues depuis 2 jours. Je propose donc que nous pair programmions à tour de rôle en rotation ET/OU qu'Hugues pair programme à tour de rôle avec chacun d'entre-nous. Parce que je crois que grâce à son expérience, il peut apporter beaucoup à l'équipe en nous montrant étroitement comment il pense/travaille.
Voilà,
C'était ma montée de lait. Merci Pascal pour ton rappel à l'ordre. J'ai saisi l'opportunité au vol parce que tout ce dont je viens de parler, c'est aussi ça le professionnalisme et c'est aussi ça, être ingénieur logiciel.
Merci
Martin