How To Never Give Up on becoming an entrepreneur
De toute évidence, il y a largement de quoi se casser la figure…
Mois : novembre 2013
L’avenir est la seule chose qui m’intéresse, car je compte bien y passer les prochaines années.
Woody Allen
Note de lecture : Alan M. Turing, par Sara Turing
Note : 4 ; Point et contrepoint sur la vie d’Alan Turing
Les parents ne devraient jamais survivre à leurs enfants. C’est pourtant la mère d’Alan Turing qui signe la biographie d’une des plus grandes figures scientifiques du 20ème sciècle décédé à l’age de 42 ans.
En fait, le livre (quoique court) ne compte pas seulement la biographie écrite par Sara Turing. Sur les 166 pages du texte, seules un peu plus de 120 viennent de sa plume. La courte seconde partie est dédiée à deux essais sur le « computing machinery » et « morphogenesis ». S’ils aident en partie à comprendre l’œuvre d’Alan Turing, ils ne sont pas très faciles d’accès, surtout le second. Il faut aussi compter avec la contribution de son frère John qui compte une vingtaine de pages (j’y reviendrais) et aussi sur les 18 pages d’avant-propos qui donnent un éclairage un peu plus neutre.
Revenons sur le texte de Sara Turing.
Sara Turing a écrit cette biographie en 1959, soit 5 ans après le décès de son fils cadet et alors agée de 78 ans. Le texte compte 13 chapitres, chacun étant très court. Je n’ai pas trouvé ce texte facile à lire, le style est de l’anglais ancien qui m’a fait pas mal souffrir et le moins que l’on puisse dire est qu’il manque de souffle épique. On ne peut non plus espérer que ce texte soit objectif. Comme le dit son frère dans sa partie, la lecture donne l’impression d’un Alan Turing parangon de vertu, ce qui est quand même difficile à croire. Le texte est découpée en périodes de la vie du mathématicien. Ce sont surtout des faits et des annecdoctes plus que des pensées profondes. Le texte est décevant à cet égard. Les 4 ou 5 premiers chapitres sont même assez pénibles à lire, la chose s’améliore un peu ensuite.
J’aurais aimé une contribution plus conséquente de son frère John. Mais il n’a écrit ce chapitre que pour offrir un contrepoint à la prose de sa mère qu’il juge biaisée (j’avoue que c’est assez facile à admettre). Sa contribution n’est pas nécessairemnt objective non plus, car il est très critique à propos de son jeune frère à de mains égards, mais il l’est aussi à propos de lui-même. Ce texte se lit mieux et va plus en profondeur que celui de sa mère.
Il eut été illusoire d’aborder ce livre en pensant lire la « biographie définitive » d’Alan Turing. Sara Turing n’est pas une écrivain et le contenu est visiblement emprint de nombreux biais, et même révisioniste à certians égards. A aucun moment elle n’évoque son homosexualité, même si on ne saurait réduire le célèbre mathématicien à ce seul aspect de sa personnalité. Il complète certainement l’image que l’on pourra s’en faire, mais il convient de rester critique par rapport à cette lecture.
Référence complète : Alan M. Turing – Sara Turing – Cambridge University Press 1959, 2012 – ISBN : 978-1-107-02058-0
Point et contrepoint sur la vie d’Alan Turing
L’agilité, une question de feedback
J’avais évoqué, lors d’une présentation en 2012, la question du feedback et son rôle majeur en tant que moteur de l’émergence.
J’aimerais revenir sur ce sujet qui me tient à coeur et le développer plus avant ici. Je vais aussi tenter de lui donner, modestement, un petit éclairage historique.
Les boucles du feedback
Pourquoi focaliser sur le feedback ? En fait, nous pouvons interpréter une grande partie des pratiques d’ingénierie et de projets agiles sous forme de boucles de feedback imbriquées. c’est ce que j’avais fait lors de mon lightning talk sur l’émergence. En voici l’illustration.
Nous reviendrons sur cette illustration un peu plus tard. Car on peut aussi présenter ces boucles de feedback autrement. Elles ne sont pas le fruit de ces 10 dernières années. L’émergence progressive de ces boucles de feedback a commencé il y a bien longtemps. Longtemps avant que l’on parle d’agilité.
Un regard historique sur les boucles de feedback
Compilation interactive
La plupart d’entre-vous n’avez pas connu cette époque, mais vous savez certainement qu’il fut un temps on l’on saisissait les programmes sur ceci
Chaque carte représente une ligne de code, plus exactement 80 colonnes de texte. Le processus est le suivant :
- On écrit son programme sur papier.
- Dès qu’on l’a rédigé (et vérifié, croyez-moi, c’est mieux), on va le saisir sur un terminal produisant une carte par ligne de texte.
- On donne la pile de cartes au centre de calcul. Ce dernier va programmer sa compilation et son exécution. Ce ne sera pas pour tout de suite, probablement dans quelques jours.
- Quand le job est passé … on vous donne le résultat … ou pas !
Une de mes anciennes collègues m’a ainsi racontée qu’elle a reçu un jour en retour sa pile de cartes entourée d’un élastique et d’une note rageusement libellée : “fait planter la machine !”.
Une anecdote hélas probablement pas si rare que ça…
J’ai à peine connu cette époque. mais à mes début, j’empruntais un ordinateur de poche 2 jours par semaine. Je n’avais que ce créneau à ma disposition pour saisir et tester les programmes que j’avais écrit sur papier pendant le reste de la semaine. C’est un peu le même cas de figure.
Cette période est révolue depuis longtemps. Au début des années 80 nous sommes passé de la compilation batch à la compilation interactive. Ou à peu près. On est passé de délais de feedback de quelques jours à quelques minutes (et quelques heures dans le cas de gros projets)
Coloration syntaxique
Il y a certes eu de discrets essais sur des environnement confidentiels dans les années 80 et même avant, mais comme beaucoup j’ai découvert la coloration syntaxique avec un IDE mainstream : Borland C++, au début des années 90.
Je me souviens avoir assisté à la présentation de lancement de l’IDE. Le public a littéralement réagit à la seconde où le présentateur a dévoilé la fonctionnalité.
C’est le feedback sur la syntaxe d’écriture du programme que cette fonctionnalité adresse. Passer de quelques minutes, c’est à dire le délai entre deux compilations, à quelques secondes est une amélioration conséquente.
Complétion de code
De la coloration à la complétion, il n’y a qu’un pas. C’est le feedback sur notre implémentation que cette fonctionnalité adresse en nous proposant les méthodes disponibles.
Vous allez me dire qu’il ne s’agit pas de feedback ici. Vous avez raison. C’est mieux, cette fonctionnalité anticipe le feedback, le rendant inutile. Disponible assez tôt dans les environnements Smalltalk, il faudra attendre la moitié des années 90 pour voir cette fonctionnalité se démocratiser.
Compilation continue
Egalement amorcé par Smalltalk, c’est dans Visual Age Java que j’ai vu pour la première fois cette fonctionnalité faire son apparition, vers la fin des années 90. Cette fois c’est la justesse grammaticale sur laquelle le feedback passe de quelques minutes à quelques secondes.
Agilité et feedback
J’ai dit que nous reviendrions sur l’illustration des boucles de feedback. Nous allons le faire. Mais pourquoi s’intéresser au feedback, en quoi ce mécanisme est-il important et si particulier à la pensée agile.
Parce qu’en tant qu’être humain, et même en fait en tant qu’organisme vivant, c’est notre principal mécanisme d’adaptation. Et l’adaptation au changement, ça figure quelque part dans notre manifeste agile, j’en suis pratiquement sûr…
La rétrospectives
Cette pratique n’est pas à proprement parler nouvelle. les rétrospectives de projets (alors appelés post-mortems) ont probablement plusieurs décennies d’existence. En quoi est-ce différent ici ? Pourquoi faire des rétrospectives plus souvent ?
La rétrospective est le mécanisme d’adaptation de notre processus. Un post-mortem de projet sert surtout à se lamenter, la rétrospective d’itération sert à adapter notre processus et nos pratiques agiles.
Cycles itératifs
J’entends souvent les équipes parler de “lotir” les itérations. C’est ce que l’on fait dans les processus itératifs. Seulement le lotissement n’a rien à voir avec l’adaptation.
Le cycle itératif agile utilise ce que l’on a appris de l’itération qui vient de se dérouler pour réévaluer les priorités et la pertinence des items figurant dans le backlog ou comme opportunité d’émettre de nouvelles idées, d’aller plus loin dans les fonctionnalités venant d’être développées.
Acceptance tests
Nouveau venu de nos pratiques agiles, le test d’acceptance nous permet d’avoir du feedback sur l’implémentation des stories, lorsqu’ils sont exécutés. Mieux encore lorsqu’on les écrit, ces tests d’acceptance donnent du feedback sur les user stories elle-même ! Ecrire des tests d’acceptance, c’est instancier les spécifications, lever les ambiguïtés, se décider sur les cas aux limites, générer de nouvelles questions.
Integration continue
Il y a un temps pas si lointain où l’intégration représentait une phase majeure, longue et risquée des projets. Le feedback sur le fonctionnement conjoint des différentes briques se faisait alors sur des cycles allant de 3 mois à deux ans.
C’est avec émotions que nous repensons parfois à ces périodes particulières des projets qui occupaient nos soirées et nos week-ends avec enthousiasme, au lieu de manger des chips et boire de la bière devant un match de foot…
Avoir la température, non seulement sur l’intégration, mais sur la qualité du code et la couverture de test, cela fait aujourd’hui partie de notre quotidien. Next !
Tests unitaires
En parlant de quotidien, en voilà un sur lequel je ne vais pas non plus m’attarder : les tests unitaires nous donnent du feedback sur le fonctionnement du code : fait-il ce à quoi nous nous attendons qu’il fasse ? C’est aussi de l’acquis : next again !
Pair programming
On pense souvent au pair programming comme à une technique de collaboration. C’est vrai. Mais c’est aussi et surtout une technique de peer review en temps réel et en continue. Un feedback sur l’écriture de code et les choix de conception fait en temps réel.
Mais aussi …
Le feedback des pratiques agiles ne s’arrête pas là. Après tout, toutes ces techniques sont plus ou moins déjà identifiées comme des techniques de feedback.
Management visuel
Les projets agiles aiment s’afficher. C’est aussi une forme de feedback
- De la part de chaque membre de l’équipe envers tous les autres.
- De la part de l’équipe vers tous ceux qui souhaitent savoir ce qu’il s’y passe.
Lean startup et le validated learning
A plus grande échelle, le cycle agile peut servir à donner du feedback, non plus à l’échelle du projet, mais à celle du business. Lean Startup étend la portée des cycles de feedback au-delà du déploiement, jusqu’à l’usage du produit afin de vérifier les hypothèses produit : persévérer ou pivoter.
De la seconde à l’entreprise
L’agilité fonctionne en harmonie avec le feedback. Mieux, elle guide chaque action par cette simple interrogation : comment vais-je évaluer que je suis satisfait du résultat ? C’est la mise en oeuvre du PDCA de Deming depuis les cycles les plus courts jusqu’aux décisions les plus impactantes.
If you want a guarantee, buy a toaster.
Clint Eastwood
De l’agilité pour mon projet, pour quoi faire ?
J’avais évoqué lors de mon teasing de la DevFest 2013 la présentation que Martin Mouterde et moi-même y ferions. Vous trouverez le support de cette présentation ici.
Préparer une présentation à quatre mains n’est pas un exercice facile. Comme j’ai des idées tranchées et personnelles (mais pas nécessairement bonnes, toutefois) de ce à quoi devraient ressembler des présentations, il reste improbable que je sois réellement satisfait du résultat. Ne comptez toutefois pas sur moi pour dire qui a engendré quoi.
J’ai hésité à modifier cette présentation avant de la poster. Finalement je me suis dit qu’elle devrait figurer telle qu’elle a été jouée () . Même si je la modifie de manière substantielle si je sui amené à la rejouer…
Carnet de route : DevFest 2013 à Nantes, en images (2/2)
Pause déjeuner
Suite de notre parcours de la DevFest. La pause déjeuner à la DevFest, c’est standing. Ca change des sandwiches qui sont le quotidien de certaines autres conférences que l’on ne nommera pas…
Le service ne semble pas en reste.
D’un autre côté, il semble qu’il nous faille mériter notre pitance. La file d’attente s’allonge terriblement.
Passant sur le second créneau de l’après-midi, j’ai courageusement choisi de sauter la première séance d’après-déjeuner afin d’être fin prêt. Nous avons une salle “réservée orateurs” à cet effet.
Christophe Addinquy & Martin Mouterde : De l’agilité pour mon projet, pourquoi faire ?
C’est notre tour, à Martin et moi-même. Notre session d’introduction à l’agilité n’est pas vraiment un thème “mainstream” de cette DevFest, il est donc peu surprenant qu’elle n’attire pas foule. Une trentaine de personnes environ.
Je ne vais pas faire de résumé de notre session ici. Je posterais le support plus tard.
Why Google+ Sign In ? Par Ian Barber
Gros fail pour cette session. J’aurais pu me douter qu’elle était en Anglais (et j’avoue que le sujet ne me passionne pas assez pour avoir envie de faire un effort). Mais pire, elle était retransmise par Hang out !
Pour être honnête, je n’ai pas fait d’effort et me suis laissé décrocher assez rapidement. Pas de résumé, donc pour cette session. Je ne suis même pas sûr que le préposé au Hang out ait trouvé cela palpitant !
Break de l’après-midi
Une pause avant la dernière ligne droite. C’est l’occasion de faire un petit tour.
D’aller s’intéresser au paysage, aussi.
Ou de voir ce que j’ai bien pu rater au programme (et essayer de ne pas rater la dernière session).
Web Components, l’avenir des développeurs Web, par Julien Vey
Pour ma part, ce fut la meilleure session de la journée, par son contenu et la maitrise du sujet par Julien. Par exemple, on crée des <div> que l’on masque ou l’on crée du DOM via du Javascript…
Demain, il suffira d’utiliser la balise <template> pour créer des fragments HTML qui seront parsés mais ni chargé, ni exécuté, mais qui pourront l’être en instanciant ce fragment d’arbre en Javascript via cloneNode().
Le shadow DOM est un nouveau moyen d’encapsuler un élément. Il est utilisé par exemple dans le cadre de la balise <video>. Mais ce concept est aujourd’hui fermé. Il sera disponible demain aux développeurs, via la méthode createShadowRoot() qui crééra un élément auquel il suffira d’accrocher des sous-éléments. L’un d’entre-eux pourrait d’ailleurs être une balise <content> pour injecter du contenu dans ce shadow DOM.
On peut apparemment mixer DOM et CSS, mais comme je suis imperméable à ces considérations, le mieux sera pour vous d’aller gambader dans les la vidéo de le session de Julien !
Enfin, les Web Components permettent de créer ses propres balises, via la balise <content>.
Bref, les Web Component, c’est l’avenir. Du moins, ce le sera quand la norme sera finalisée, ce qui n’est pas encore le cas. On pourra alors intégrer des Widgets d’un nouveau genre qui ne ressembleront plus à un amas sordide de <div> et de Javascript ! Toutefois, il n’est pas nécessaire d’attendre ce jour béni. On peut déjà utiliser Polymer qui émule l’état actuel de la norme.
Outre l’excellente présentation de Julien, on peut aller vers le site de référence sur HTML5, à savoir htmlrocks pour en savoir plus et surtout trouver les bons tutoriaux !
Check out
La DevFest touche à sa fin, quelques irréductibles s’essaient encore au zPilot et il sera temps de plier les gaules.
Un bon DevFest en ce qui me concerne. Si les sessions front-end sont assez loin de mon habitat naturel, j’ai réussi à ne pas être trop largué, ce qui est déjà pas mal pour moi…
Dès qu’il y a des gens qui bougent, les immobiles disent qu’ils fuient.
Jacques Brel
Coaching Plain & Simple, par Peter Szabo & Daniel Meier
Note 7 ; Un texte concis et clair pour parler de coaching bref.
J’aime bien les livres très courts pour 3 raisons :
- On se voit avancer rapidement vers la conclusion de l’ouvrage.
- Le format accentue la nécessité d’efficacité du propos. Un point que je suis pas forcément quand is s’agit de rédiger la note de lecture…
- Et ça me permet de produire une note de lecture à pas cher, sans avoir investi terriblement dans la lecture.
Ici, il est question de coaching bref, cela paraît donc cohérent que le support écrit le soit aussi. En l’occurrence, on parle ici d’une centaine de pages sur 12 chapitres auxquels il faut ajouter une FAQ sous forme d’interview avec les auteurs.
Qu’est-ce que le coaching ? C’est une question reccurente, sutout aujourd’hui quand tout le monde s’auto-programme « coach ». Les auteurs nous donnent 2 clés :
- L’importance du cadre, et comment il peut sublimer le contenu, par exemple dans le cas d’une peinture.
- Les 3 clés du coach : la conscience (awareness), la confiance et le choix.
Le chapitre 2 est une sorte de prélude au reste du livre qui est spécifiquement consacré au coaching « solution focus ». Il pose et argumente les 4 postulats sur l’intérêt d’être bref.
Le coaching bref est constitué de conversations qui vont généralement de 1 à 3, guère plus. Les auteurs exposent au chapitre 3 la trame de ces conversations, qui est aussi la trame des chapitres suivants (auquel il faudra quand même ajouter un chapitre sur la prise de contact en amont, et sur le « follow up » en aval) :
- L’agrément sur le coaching, entre le coach et le coaché.
- Le futur préféré.
- L’identification des précurseurs de la solution.
- Les indices de progrès.
- La conclusion de la session.
Chaque point est traité de manière très concise, en une dizaine de pages, voir moins, généralement. Le format étant presqu’un format poche, cela donne une idée du condensé que propose chaque partie. Mais il n’y a pas de miracle non plus, le livre permet de faire sentir et comprendre ce que l’on dot faire dans du coaching « solution focus », il donne autant de clé de travail que possible : comment réagir dans telle ou telle situation, quelles sont les questions clé… mais il ne peut se substituer à la pratique. Les auteurs sont clairs et honnêtes sur ce point : il faut apprendre à « danser » avec le coaché.
Ce n’est pas un livre qui se complet dans la théorie pour autant : les auteurs donnent des exemples et travaillent à partir de cela. En fait, le gros du texte est construit autour de l’étude de cas de Mme K., issu d’un cas réel de coaching des auteurs. Une lecture au ratio temps passé / passage de compétence très important !
Référence complète : Coaching Plain & Simple, Solution-focused brief coaching essentials – Peter Szabo & Daniel Meier – W. W. Norton & Company 2009 (V.O. : Coaching – Erfrischend Einfach : Einführung ins lösungsorientierte Kurzzeitcoaching ; Solutionsurfers Gmbh / Weiterbildungsforum 2008) – ISBN : 978-0-393-70593-5
Carnet de route : DevFest 2013 à Nantes, en images (1/2)
La DevFest, c’est l’évènement Google pour les développeurs. Pour être exact, il n’est pas organisé par Google (bien que supporté par le géant de Mountain View) mais par le GDG Nantes. Je m’étais joins aux festivités pour une session d’introduction à l’agilité avec mon collègue Martin Mouterde.
Check-in
On débute tôt la journée ici, les portes sont ouvertes à 8h20 ! Rien à voir avec notre rythme de bâton de chaise Parisien… Heureusement, Martin et moi étions arrivés la veille pour répéter. Café et croissants sont prévus pour accueillir les participants.
Jusqu’ici tout va bien. Direction la keynote.
Keynote : Des opportunités pour s’associer
On a tranquillement rempli l’amphithéâtre pour cette keynote. A priori, nous étions 350. Julien Landuré a délaissé son polo Zenika pour un T-shirt GDG Nantes pour évoquer l’année écoulée.
L’organisation avait aussi prévu une couverture en image plus solide que celle de vôtre serviteur. J’espère avoir bientôt un lien à vous donner.
Place maintenant à la keynote ! Une keynote surprenante, car elle ne va pas parler de technologie, mais de collaboration. L’orateur y évoque des outils parfois connus comme les modèles DISC, MBTI ou Process Com. Il en évoque d’autres moins connus comme Strength Finder, qui me donne bien l’envie d’essayer !
Connaitre ses forces, c’est une bonne façon de savoir comment les associer, lequelles acquérir pour se renforcer.
S’associer, c’est essayer au travers de Startup Week-ends, Hackathon et autres Roadtrips… si on n’arrive pas à s’entendre sur 2 jours intenses, ce n’est peut-être pas la peine d’insister sur une longue durée…
S’associer, enfin, c’est s’engager :
- En formalisant au plus tôt les statuts.
- En rédigeant une lettre récapitulant ces statuts.
- En s’aidant d’un avocat d’affaire.
Pawel Kozlowsky : AngularJS: making a browser a better development platform
Pawel est l’auteur de ce qui est encore l’un des rare livres sur AngularJS. Il pratique en outre ce framework depuis 3 ans.
Béotien absolu du développement Javascript, je me suis campé dans cette session justement pour cette raison, et aussi pour avoir un peu parcouru les tutoriaux AngularJS…
Pawel le dit lui-même: le développement dans le browser, c’est parfois douloureux ! Les frameworks sont là pour soulager, mais un framework comme JQuery se focalise surtout sur le requêtage du DOM, afin de le rendre plus facile. Ce n’est ni n réel changement de paradigme, ni un “game changer”.
AngularJS propose un binding bidirectionnel entre modèle et vue, sans qu’il soit nécessaire d’enregistrer le modèle, ni procéder à des notifications explicites ! AngularJS est réellement déclaratif ! En fait, une grande partie des fonctionnalités d’AngularJS consiste en propriétés (notées ng-*) qui peuvent être ajoutées aux éléments, tel le ng-repeat qui permet de construire des templates.
AngularJS permet aussi de construire des tags “custom” à l’image des futurs Web Components, ainsi que l’injection de dépendance en JavaScript.
En conclusion, AngularJS, c’est :
- Du data binding bidirectionnel sur un modèle.
- Un DSL customisable au-dessus de HTML
- Un framework complet et solide.
Et une excellente ressource pour commencer : http://egghead.io/
Guillaume Campion : Retour d’expérience sur les Google Glasses
Bien sûr, les Google Glasses, ça attire les badauds, même si la session n’est pas très technique. En fait, même pas du tout !
Les objets connectés, c’est le nouvel eldorado, qu’on se le dise ! Pourtant il n’y en a que 8 paires en France actuellement. Pourtant les “lunettes informatiques” ne sont pas nouvelles. Steve Mann (http://spectrum.ieee.org/geek-life/profiles/steve-mann-my-augmediated-life ) en construit et en porte depuis 35 ans. Chez lui, elles sont vissées à la boite cranienne, car il ne fait pas dans la demi-mesure !
Les lunettes Google disposent des fonctionnalités suivantes :
- Un touchpad sur le côté.
- Un appareil photo de 5 Mega pixels
- 12 GB de mémoire
- Une mise à jour du firmware tous les mois.
Voilà la bête, sur Guillaume :
Prendre une photo n’a jamais été aussi facile. L’orateur objecte cependant à ce que l’on puisse les considérer comme le nouveau gadget du voyeur.
Prendre une photo n’a jamais été aussi facile. L’orateur objecte cependant à ce que l’on puisse les considérer comme le nouveau gadget du voyeur.
L’interface utilisateur de compose de “cartes”. Pour ce qui est du développement, il peut se faire de 2 façons:
- Miror API : Ca passe par une connexion permanente chez Google !
- Natif : C’est un gros un SDK Android (il y a un GDK, mais qui n’est pas encore publié). Ce mode donnera accès aux senseurs des lunettes quand il sera accessible.
En résumé :
- Les Google Glass, c’est un 6ème sens !
- On peut toujours les avoir sur soi, mais elles sont non intrusives (pas une réelle réalité augmentée).
- Un usage plus spontané, ne nécessitant pas les mains et “quasi” see-through
- Une interface utilisateur différente qui nécessite pas mal de boulot.
J’ai eu la possibilité de prendre une photo de plus près des lunettes (mais pas de les essayer) dans la salle réservée aux orateurs. Voilà:
Et si vous voulez la présentation in-extenso :
Présence Zenika
L’une des raisons de ma présence ici était la présence de Zenika en tant que Sponsor. Notre stand proposait des animations autour de jeux video.
De manière générale, l’espace était assez exiguë. Celà renforce l’impression d’affluence générée par les jeux.
Comme à Rennes, une petite photo du staff s’impose
Je vais m’arrêter ici pour ce post, histoire d’en garder pour un peu plus tard.
Software Freethinker 
