★ SudWeb 2016

Beaucoup d’inventions utiles n’ont pas été le fruit d’un problème. Penser « positif », c’est peut-être juste ça : laisser tomber les problèmes et rêver un peu…

4 changements qui émergent dans les projets (cache)

Les éditions de cette conférence se suivent mais ne se ressemblent pas si ce n’est dans leur recherche de singularité. Chaque intervention donne envie d’aller interagir avec l’orateur pour échanger plus que d’ouvrir son laptop. Derrière ces sujets non-techniques se cachent des réflexions plus profondes qui n’interrogent plus le comment mais le pourquoi et de plus en plus le pourquoi pas ?

Les sujets des élaboratoires en format Forum Ouvert sont assez révélateurs d’une communauté qui devient plus mature (c’est la façon polie de dire vieille :-p).

  • J’ai eu le plaisir de m’initier au handlettering avec Hellgy pour éventuellement s’amuser en duo.
  • J’ai initié une discussion sur l’enseignement et le web qui a permis de vérifier la diversité des expériences et des méthodes employées. Beaucoup de discussions ont finalement été relatives au ratio théorie/pratique et à la pertinence du contenu transmis. Bien que les questions aient été posées, on n’a pas tenté de définir ce qu’était le Web ni si une culture pouvait être enseignée. De quoi alimenter ma réflexion :-).
  • J’ai participé à une discussion sur Progresser dans son métier qui soulevait des pratiques intéressantes. Je retiens qu’un domaine en perpétuelle évolution demande de progresser même lorsqu’on souhaite simplement rester à niveau. Personne dans la salle n’a mentionné les formations traditionnelles pour progresser, c’était assez surprenant.
  • Enfin, j’ai assisté au retour d’expérience de Vincent sur son travail itinérant ou néomadisme. Il faudrait que je fasse un billet sur le fonctionnement actuel de scopyleft car j’ai eu beaucoup de questions à ce sujet au cours des deux jours.

Je vais terminer sur le témoignage de Roxanne qui se pose des questions sur son entrée dans le monde professionnel et sur les relations entre son futur emploi rémunéré et ses travaux bénévoles actuels. Cette articulation est tout à fait possible et rejoint pas mal de réflexions que nous avons eues au cours de la création et de l’évolution de scopyleft. Par contre, il s’agit clairement de la face nord car cela nécessite un alignement des bonnes énergies des bonnes personnes au bon moment. Ou pas, il faut expérimenter pour le vérifier ;-).

★ Enseigner le Web

Teaching will make you more humble, because it will painfully show you how limited your knowledge is. Teaching is the best way to learn. Only by testing your knowledge against others are you going to learn properly. This will also make you more respectful regarding other developers and other technologies; every language, no matter how humble or arcane, has its place within the Tao of Programming (cache), and only through teaching will you be able to feel it.

Being A Developer After 40 (cache)

Contexte

Le titre est clairement pompeux, plus qu’enseigner le Web il s’agit d’un retour d’expérience sur ces deux dernières années où j’ai tenté de transmettre les concepts du Web et mes expériences de développeur à une cinquantaine d’étudiants. Ces apprenants étaient alors en troisième année de licence dans le domaine du Web mais n’avaient pour la plupart jamais fait de programmation. Ayant eu beaucoup de confiance et de liberté de la part de la responsable de la licence, j’ai pu essayer des choses.

J’ai eu cette proposition un peu par hasard et par bouche à oreille suite au désistement d’un intervenant, un premier coup de fil mi-septembre et un premier cours mi-octobre. Cela m’a laissé peu de temps pour préparer quoi que ce soit ce qui s’est révélé être intéressant pour la suite. Il s’agissait initialement de faire une initiation à HTML/CSS et cela s’est étendu à JavaScript et PHP au cours de l’année. La seconde année, j’ai réussi à écarter PHP pour me focaliser sur le web mobile. Au final, cela a représenté 150 heures d’enseignement.

Détail qui n’en est pas un, les promotions étaient composées à 80% d’étudiantes. J’avais besoin de vérifier à titre personnel à quel moment cette tendance s’inversait dans les équipes de développement web et si les études pouvaient être en cause (réponse : non, il faut donc remettre en question ce qu’il se passe ensuite mais ce n’est pas l’objet de cet article).

Attentes

J’avais une contrainte d’espace et de temps avec les créneaux horaires fixes et les salles de classe peu adaptées à l’accompagnement d’une acquisition de savoirs. J’avais aussi une contrainte au niveau des thématiques du contenu mais celle-ci était surtout guidée par mon expérience professionnelle. La responsable était consciente du décalage actuel entre ce qui était enseigné et la réalité du marché ce qui me conférait une grande liberté autant sur le fond que sur la forme, ses attentes portaient sur la pertinence des savoirs transmis.

De mon côté, je voulais voir ce que j’étais capable de partager en ayant été complètement autodidacte dans le domaine. Je voulais pouvoir essayer des choses et l’introduction de l’agilité dans des cours me motivait. Je trouvais important de documenter ces expériences afin de partager mes apprentissages et de constituer une mémoire de mon ressenti à ce moment là.

En ce qui concerne les étudiants, ils avaient vraiment du mal en début d’année à formuler leurs attentes qui se focalisaient beaucoup sur des technologies et/ou des connaissances superficielles. C’est assez déroutant au début et cela m’a fait réaliser à quel point l’apprentissage est guidé par le besoin, le rôle de l’enseignant devenant en quelque sorte de créer artificiellement ce besoin.

Je retiens toutefois qu’ils souhaitaient globalement devenir plus autonomes et améliorer la qualité de leurs productions ce qui est encourageant !

Valeurs

  • rendre possible l’Autonomie
  • encourager la Bienveillance
  • éveiller la Curiosité.

ABC de l’apprentissage

Je n’ai réussi à publier ces valeurs qu’à la fin de la première année et elles m’ont guidé lors de l’année scolaire suivante. Elles sont difficiles à mettre en pratique car elles sont assez éloignées de ce qui est mis en valeur lors d’un cursus scolaire.

Si le motto de Maria Montessori est « aide-moi à faire seul », j’ai essayé d’aller plus loin vu leur maturité et leur niveau de connaissances en allant vers le : Accompagne-moi pour faire ensemble.

Cela signifie changer de paradigme en passant de la compétition à la collaboration, ce qui pose notamment certains problèmes en matière d’évaluation.

Co-construction

A lot of what beginning programmers need isn’t just good learning materials, but confirmation that not knowing is normal.

@hcatlin sur Twitter

Il était important pour moi que les étudiants soient acteurs dans l’acquisition de leurs savoirs. Autant dans l’expérimentation que dans les choix de la matière qu’ils souhaitaient travailler. J’essayais de lister avec eux les différents sujets que nous étions capables d’aborder et nous établissions ensuite un ordre de priorité dans ces technologies/concepts.

C’était loin d’être évident car ils (on ?) avaient du mal à évaluer leur niveau collectif et l’inertie du groupe. Mais ce n’est pas grave, on s’autorisait à se planter comme lorsqu’on a voulu aborder Angular avant de comprendre JavaScript. D’autres fois, il était difficile pour moi de leur faire prendre conscience des bienfaits d’une bonne pratique car sa pertinence requerrait du temps de vie et de complexité. Tant pis, ils s’en rendront peut-être compte plus tard.

J’ai trouvé très intéressant de creuser avec eux le pourquoi de leurs choix. J’essayais dans la mesure du possible d’adopter une position de pair plus qu’une relation hiérarchique prof/élève. Je leur ai toujours dit que la somme de leurs savoirs et expériences dépassaient la mienne (cache) de plusieurs ordres de grandeur. Sans compter leur puissance de recherche et de réflexion. J’ai réussi à leur démontrer cela plusieurs fois.

Itérations

Je suis souvent intervenu par demi-journées que je découpais en six moments :

  • Un quart d’heure pour se remémorer ce que l’on avait fait la fois précédente et échanger sur nos veilles respectives ;
  • quatre sessions de 45 minutes sur lesquelles je reviendrai ensuite ;
  • un quart d’heure pour prendre du feedback sur ce cours et décider ensemble de ce que l’on va faire et améliorer la fois suivante.

Les sessions étaient effectuées en groupe ou seul, avec plus ou moins de contraintes artificielles de ma part. Elles consistaient généralement en un concept technique à travailler avant une courte période théorique/magistrale pour mettre tout le monde au même niveau. Cette théorie pouvant être effectuée par un étudiant.

L’avantage de procéder par itérations est de pouvoir expérimenter de très nombreuses choses en un temps réduit. La prise de risque devient bien moindre lorsqu’on sait qu’elle sera limitée dans le temps et collectivement améliorée lors de l’itération suivante.

Un autre avantage est d’introduire de la répétition favorisant l’apprentissage. L’introduction de légères variations sur un même exercice permet de voir la classe progresser par paliers au cours d’une même session.

Agilité

  • Prescriptive → Iterative
  • Content → Culture
  • Evaluation → Visible Feedback & Reflection
  • Control → Trust
  • Competition → Collaboration

Agile In Education (cache)

Tout ce travail itératif prend bien sûr ses sources dans les pratiques agiles et empreigne peut-être les élèves d’une autre culture. Une culture où l’échec est permis et où l’on essaye de travailler ensemble pour que l’intelligence collective du groupe fasse progresser chacun individuellement. Une culture où la réaction est plus importante que la défense.

C’est un vrai défi car les apprenants manquent cruellement d’outils pour collaborer. J’aurais aimé prendre le temps de les initier à Kanban ou Git(hub) mais notre capacité à assimiler de nouvelles choses est limitée et je ne voulais pas introduire trop de nouvelles notions qui ne pouvaient qu’être survolées.

Aussi les pratiques agiles ont davantage été des expérimentations agiles. Il y avait l’inspiration bien sûr mais après cela tout était à découvrir ensemble car ces approches sont peu employées/documentées par ailleurs.

Notation

Je suis contre les notations/classements mais il s’agit d’une contrainte forte dans l’univers scolaire. Aussi j’ai essayé de mettre les étudiants dans des situations qui pourraient leur servir rapidement à travers des candidatures spontanées, des critiques de sites ou des compte-rendus d’expérimentations techniques. Les résultats étaient parfois assez surprenants et les discussions suivant ces exercices toujours passionnées.

Ils avaient globalement du mal à faire le lien entre ce qu’ils avaient appris/expérimenté et la valeur qu’ils pouvaient apporter à une entreprise, se contentant de faire des lettres/CV génériques pour arroser le plus de boîtes possibles (ils font un stage de fin d’année). J’ai essayé de leur montrer qu’une autre voie est possible en ciblant quelques entreprises dans lesquelles ils voulaient vraiment travailler et en personnalisant leur approche : audit de performance, problèmes de validité, d’ergonomie, d’accès mobile, etc.

Ici j’avais beaucoup de mal à être pertinent car je n’ai jamais eu à faire cette démarche de recherche d’emploi/stage donc il était difficile de les accompagner. J’ai plutôt essayé de me mettre dans la peau de quelqu’un d’expérimenté qui recevrait une telle candidature par exemple.

Holisme

Ce qui m’a cruellement manqué au cours de ces années c’est l’impression de faire partie d’un tout au sein d’une formation cohérente qui permet à chaque étudiant de s’accomplir dans sa singularité. Mettre en pratique l’agilité d’un côté et voir qu’à la session suivante ils ont de la gestion de projet des années 90 c’est dur. Expliquer les failles de sécurité et regarder ce qu’ils codent en PHP par ailleurs c’est flippant. Si la communication est difficile entre élèves, elle est catastrophique entre enseignants.

Cela soulève tout un tas de problématiques sur la mise à jour des compétences, le financement de ces moments d’échanges, l’alignement dans les valeurs et les motivations, etc etc. Il y aurait beaucoup de choses à expérimenter dans ce domaine également. De la co-construction d’un programme cohérent à l’accompagnement d’étudiants dans leurs projets professionnels.

Peut-être aussi que cela demande de pouvoir suivre les étudiants pendant plusieurs années pour mieux les connaître et adapter les interventions en fonctions de leurs motivations.

Confiance

Years later, when I did well in programming classes in high school and college, a part of me was dismissive of those results. Because of that initial experience programming, I was subconsciously held back by the fear of finding another brick wall concept that I wouldn’t be able to grasp. It’s taken a decade to reverse this thinking and stop having a fixed mindset about my engineering abilities, but it’s been worth the effort. Now, because I believe that I can grow as an engineer, I’m motivated to invest in myself. The intrinsic belief that I can get better keeps me confidently striving in my career for more responsibility and new challenges.

On Confidence (cache)

Établir un climat de confiance au sein d’une promotion est difficile. Les groupes sociaux se forment rapidement et ajouter la contrainte de les mélanger à celle de collaborer demande parfois un effort trop important. C’est compréhensible et c’est le genre de moments où je ne sais pas s’il faut forcer la diversité qu’ils retrouveront peut-être dans leur futur emploi (ce n’est pas mon cas donc c’est difficile à imposer…).

A team is not a group of people that work together. A team is a group of people that trust each other.

Simon Sinek sur Twitter

En revanche, j’ai toujours essayé d’encourager les réflexions et les échanges de la part de tous les apprenants. Parfois une simple remarque fait l’objet de l’itération suivante pour confirmer ou réfuter une hypothèse en groupe. Je ne voulais pas forcément qu’ils aient confiance les uns envers les autres mais qu’ils aient de l’attention pour les questionnement de leurs pairs.

J’ai aussi été surpris du manque de confiance en eux qu’ils pouvaient avoir vis-à-vis de la programmation, ce qui m’a fait beaucoup réfléchir aux abstractions possibles. Je suis encore en plein doute sur le sujet.

Prise de recul

Le fait de donner des cours m’a permis de réaliser à quel point nos outils sont complexes et élitistes. L’expression japonaise 「灯台下暗し」 (tōdai moto kurashi) prendre du recul pour avoir de la lumière (littéralement : il fait sombre sous la lanterne) me semble appropriée, ce sont les étudiants qui sont arrivés avec leurs lanternes et ont commencé à me faire sérieusement douter. Je leurs suis extrêmement reconnaissant de m’avoir ouvert les yeux et d’avoir pu creuser ensemble quelques approches possibles pour simplifier l’apprentissage des briques du Web.

Simplicité par défaut

Les cours ont clairement été moteurs dans ma réflexion sur le minimalisme et l’esthétique puis la simplicité. Le fait de transmettre permet de se remettre en question sur l’intérêt de perpétuer certains concepts ou pratiques. J’ai dû reprendre certaines lignes de code caractère par caractère pour vérifier leur bien-fondé.

Ce qui m’a amené à une approche dirigée par le validateur pour ce qui est du HTML par exemple. À partir de quel moment une page s’affiche dans un navigateur ? À partir de quel moment devient-elle valide ? Est-ce qu’il y a vraiment besoin de plus ? Etc.

J’ai aussi pu reprendre JavaScript depuis zéro, questionner les abstractions et bien creuser ES6/2015/Next car je souhaitais leur enseigner le Web d’aujourd’hui et demain sans forcément leur mettre le fardeau de la rétro-compatibilité tout de suite.

Contraintes spatiales

La salle de formation est une cellule eucaryote : un noyau contenant l’ADN-livres, des ribosomes-élèves transformant l’information-ADN en connaissances-créations-protéines.

D’une sélection artificielle à une sélection naturelle dans un écosystème complexe (cache)

Là où Christian den Hartigh organise sa classe comme une cellule eucaryote, il faut bien voir que les élèves de l’IUT sont par défaut dans une configuration qui leur fait regarder un écran qui est adossé au mur. Autant dire qu’ils me tournent tous le dos ! On fait mieux en matière d’échanges (et de position de travail) à la fois avec moi mais aussi et surtout avec les collègues.

Pour inverser la tendance et essayer de recréer un centre d’intérêt j’essayais au moins de prendre un moment pour qu’ils viennent présenter leur travail au groupe de manière répétée et interactive. J’ai aussi ré-agencé les postes de travail lorsque c’était possible, les salles ayant des machines qui sont généralement boudées (à juste titre vu les limitations) par les étudiants qui préfèrent amener leur propre ordinateur.

Digital na(t)ives

Le niveau de votre classe est celui de la personne la plus faible techniquement. [Paraphrase]

Giving better code reviews (cache)

Les articles (cache) ne manquent pas (cache) pour rendre compte d’une génération qui utilise le Web comme de l’électroménager. J’ai malheureusement pu le vérifier également lors de mes interventions. Savoir enregistrer un fichier avec une autre extension que celle proposée par défaut ou un autre encoding n’est pas évident du tout. Jongler avec des navigateurs et des résolutions non plus. Taper certains caractères correctement peut même révéler quelques surprises…

La difficulté vient du grand écart de niveau qu’il y a entre les étudiants qui ont déjà des difficultés à savoir se servir d’un ordinateur et ceux qui font déjà des sites en auto-entrepreneurs !

Attention toutefois, ceux qui arrivent avec un certain bagage technique vont potentiellement mettre plus de temps à oublier certaines mauvaises habitudes. Ou à essayer de comprendre certaines de leurs lignes de code qu’ils copient-collent depuis un moment et qui marchent. Le désapprentissage est parfois douloureux.

Capitalisation

Teams are immutable. Every time someone leaves, or joins, you have a new team, not a changed team.

Richard Adalton sur Twitter

Pour une classe, c’est pareil, sauf qu’il y a 25 personnes qui partent. Autant dire que la capitalisation est bien maigre d’une année sur l’autre et ça a probablement été l’une de mes erreurs de partir un peu trop confiant la seconde année. La confiance acquise aurait davantage dû me motiver à expérimenter plein de nouvelles choses plutôt que de reproduire certains patterns qui avaient bien fonctionné la première fois.

Là où ça devient intéressant, c’est sur les différentes approches que j’ai pu tester.

Mémoire

Misleading headlines notwithstanding, no one really has the slightest idea how the brain changes after we have learned to sing a song or recite a poem. But neither the song nor the poem has been ‘stored’ in it. The brain has simply changed in an orderly way that now allows us to sing the song or recite the poem under certain conditions. When called on to perform, neither the song nor the poem is in any sense ‘retrieved’ from anywhere in the brain, any more than my finger movements are ‘retrieved’ when I tap my finger on my desk. We simply sing or recite – no retrieval necessary.

Your brain does not process information and it is not a computer (cache)

La façon de retenir des informations est encore très difficile à comprendre (cache). On dispose de quelques pistes via la discussion (cache) ou le jeux (cache) mais elles restent ténues. Ce constat est génial, il y a tout à tester !

Notre profession est particulière car on a le savoir technique à portée de clavier. Cela ne signifie pas que l’on sache l’exploiter pour autant ni en connaître toutes les applications pratiques mais c’est un bon début. Une fois que l’on considère que la technique est externalisée sur le web, il nous reste à assimiler les concepts pour assembler ces notions. Je pense que les mécanismes de mémorisation d’un développeur web sont très différents d’autres professions car il a affaire toute ses journées à des liens. Je me souviens bien souvent d’une chose que je sais pouvoir retrouver et cette simple croyance me suffit pour considérer cela comme une mémorisation. Il faudrait que je développe dans un futur billet.

Jeux

On a joué à Flexbox Froggy, Starwars ou Flexbox Defense qui ont été assez appréciés des étudiants. J’ai découvert plus tard Python Tutor qui n’est pas limité au langage Python. Une visualisation très intéressante de ce qu’il se produit au niveau de l’affectation des variables. Un bon candidat pour une prochaine expérience.

Pour des jeux que l’on qualifie de plus sérieux, j’ai tenté des Remember the future et je terminais régulièrement les cours — voir les itérations — par des rétrospectives pour identifier les points d’amélioration.

Après pour moi le Web est un jouet convivial par excellence. Mais ce n’est pas forcément partagé :-).

Disposition

Toute ma démarche est de les faire passer de la chaise au tableau, de l’écoute passive au partage actif. Pour favoriser cela, il faut briser la barrière entre la position assise de l’apprenant et celle debout du sachant. J’ai tenté de les faire participer en inversant souvent les rôles : si tu prends ma place, je prends la tienne, physiquement. J’ai tenté de changer la disposition de la salle. J’ai fait des rétrospectives en étant tous debout, souvent en cercle.

La simple disposition change souvent la façon de communiquer.

Certains auront davantage d’aisance lorsque l’on passe des questions-réponses à la discussion libre. D’autres vont avoir besoin de plus de temps pour préparer une intervention construite. La prise de parole en public devient moins stressante lorsqu’on est en situation de confiance/bienveillance et la disposition des individus est importante pour faciliter cela.

Communication

J’avais testé jadis des accompagnements sur Blog, Twitter, Facebook, mais je n’avais jamais été pleinement satisfait. J’ai conservé Facebook avec les élèves pour rester en relation avec les anciens, ceux qui le souhaitent, et les accompagner pour des aides ponctuelles, ou garder un simple contact.

Etendre la salle de classe hors des murs : Slack pour l’éducation et l’instruction (cache)

Je regrette de ne pas avoir pris le temps d’introduire Slack ou équivalent comme canal de discussion car même en annonçant que je réponds aux mails en dehors des heures de cours j’ai eu très peu de questions.

J’avais par exemple introduit un temps de veille qui était très apprécié la première année et qui n’a pas suscité la même appétence la seconde. Peut-être qu’un espace en ligne pour partager des liens eut été mieux accueilli plutôt que d’abandoner purement et simplement.

Retours

Les retours sont limités aux temps de cours et je n’ai malheureusement pas eu de mails une fois l’année terminée. C’est frustrant mais Christian m’expliquait avoir fait le deuil d’une quelconque impact une fois l’année écoulée. Il faut savoir se focaliser sur le présent et sur la relation qui se vit pendant les cours.

Il se trouve que j’ai du mal à lâcher prise là-dessus car j’ai besoin de ce feedback pour pouvoir m’adapter. Je n’ai jamais travaillé en agence et mes 3 mois en SSII sont bien éloignés aussi les conseils que j’ai pu leur donner sont potentiellement à côté de la plaque. Je ne veux surtout pas leur mettre mes propres œillères.

J’aurais aussi aimé pouvoir suivre des étudiants sur plusieurs années pour répondre individuellement à leurs souhaits et construire quelque chose de cohérent ensemble.

Durée

Être en position de transmettre n’est pas une carrière mais un bref état transitoire.

Transmission et durée

Je suis tiraillé sur cette partie, car d’un côté la classe change totalement d’une année sur l’autre et l’on peut apprendre de nouvelles choses à chaque cours. Mais de l’autre j’ai besoin d’avoir davantage d’inspirations d’une année sur l’autre pour avoir le sentiment de faire un accompagnement qui soit utile. Cela me fait penser au temps nécessaire entre deux conférences, je ne pourrais jamais faire plusieurs fois la même intervention. J’aurais l’impression de m’ennuyer et donc d’ennuyer le public. J’ai besoin de reconstruire une réflexion à chaque fois. De refaire le vide pour avoir l’espace de cuisiner de nouvelles idées.

Est-ce que j’aurais continué sans mon départ au Canada ? J’ai du mal à répondre à cette question (tiens au passage, si vous avez envie de partager vos connaissances sur Arles, il y a une place qui se libère, contactez-moi :-)). Outre le temps que ça prend, l’enthousiasme des apprenants est un peu en dent de scie et c’est difficile à gérer et à s’en contenter.

D’un autre côté, j’ai toujours envie de ré-expérimenter dans d’autres contextes d’apprentissage.

Conclusion

Je dirais que la plupart des expériences biographiques sont de ce type. La plupart du temps, nous allons là où le monde social nous aurait envoyés de toutes façons, mais nous y allons contents. C’est ce qu’on appelle la vocation. Il y a évidemment des exceptions, et elles sont très importantes : il suffit qu’il y en ait une seule pour que cela change tout – et c’est la liberté.

Pierre Bourdieu

Je ne sais pas vraiment s’il y a une conclusion à cette expérience. J’avais soumis le sujet à ParisWeb pour pouvoir en discuter avec davantage de personnes mais il n’a malheureusement pas été retenu. Ç’eut été l’occasion de débattre de ces problématiques car je sais que d’autres travailleurs du web font leurs propres expérimentations, peut-être qu’un espace d’échange dédié serait plus adapté. L’initiative TrainDrop mériterait d’être étendue avec un espace de discussion pérenne pour échanger sur nos expériences, nos doutes et pourquoi pas aider de nouvelles personnes à se lancer. Qui serait motivé ?

Je vais profiter d’être à SudWeb pour insuffler un peu d’énergie dans le projet.

★ Consultation offline

Fusionner, cela signifie que l’IDPF va disparaître, pour devenir un groupe de travail du W3C, dédié au format EPUB, et que celui-ci ne sera plus uniquement le format des livres numériques mais le format de tous les documents numériques que l’on souhaitera encapsuler pour qu’ils puissent notamment être lus hors ligne.

IDPF et W3C : books and browsers (cache)

J’ai des envies assez simples pour ce site :

  1. avoir la possibilité de le parcourir dans son intégralité sans connexion ;
  2. avoir la possibilité de chercher un mot-clé dans ces sources ;
  3. ne pas voir les ajouts/corrections/retraits facilement.

J’ai exploré pour cela les Service Workers, DCVS, IPFS/ZeroNet, EPUB, Electron et… un simple fichier d’archive. Spoiler: aucune de ces solutions techniques n’est satisfaisante.

Service Workers

Les Services Workers sont intéressants pour mettre en cache quelques kilo-octets et fluidifier la navigation en récupérant les liens suivants mais l’intégralité du HTML de ce site fait 27 mega-octets (dont 11 de cache). Ça commence à faire beaucoup pour l’espace de stockage par défaut. C’est limitant également au niveau du support des navigateurs.

IPFS, ZeroNet, etc

Les solutions de décentralisation ne créent pas une copie locale intégrale du site mais uniquement des pages consultées (à ma connaissance) sans compter que ces solutions sont encore trop récentes/élitistes pour être employées sereinement vu que ça doit être bloqué par la moitié des proxies de la planète.

EPUB

J’ai suivi avec grand intérêt le retour d’expérience d’Antoine sur sa création de livre web (cache) et j’ai essayé de m’en inspirer mais cela pose le problème de la navigation lorsqu’on arrive à des milliers de pages. Sans compter la soupe de tags à laquelle je suis arrivé en raison de mon incompétence dans ce format. J’espère que l’inclusion de l’IDPF au sein du W3C permettra de débloquer la situation d’ici… quelques années.

Electron

C’est le moment où je me suis dit que la transformation du site en application pourrait être la solution. Si vous avez envie d’app-ifier du HTML statique vous allez devoir ajouter ces lignes au quick start :

mainWindow.webContents.on('will-navigate', function (event, url) {
    // Deal with local links.
    event.preventDefault()
    mainWindow.loadURL(`file://${__dirname}/app/${url.substr('file:///'.length)}index.html`)
})

pour les liens locaux et :

app.on('ready', function () {
    // Deal with static/local resources.
    electron.protocol.interceptFileProtocol('file', function (request, callback) {
        var pathname = url.parse(request.url).pathname
        if (!request.url.includes(__dirname)) {
            pathname = path.join(__dirname, 'app', pathname)
        }
        callback(pathname)
    })
})

pour les ressources locales.

C’est tellement mal documenté que j’ai passé un long moment à comprendre comment y arriver. Et je ne parle pas de la complexité pour générer une application cross-platform avec cela. Toujours est-il qu’une fois l’application générée, elle faisait 260 Mo pour 140 Mo de sources. Sans compter l’impossibilité de faire des recherche dans les sources.

DCVS

Peut-être qu’un dépôt git pourrait être pertinent et c’est d’ailleurs ce que proposent par défaut la plupart des solutions de sites statiques comme Jekyll, Pelican ou Hugo. Sauf que je ne souhaite pas exposer les sources dans un gestionnaire de versions, entre autre pour ces raisons. Sans compter que ces outils sont peu adaptés au stockage des fichiers générés qui sont régulièrement tous mis à jour (hash de cache ou modification du design par exemple). J’en arrive par exemple à un .hg de 500 Mo pour ce site…

Simple archive

J’en suis donc revenu à une simple archive mais cela demande de la générer côté serveur, ce que je n’ai pas encore mis en place. Je suis toujours hésitant sur ce que je pourrais mettre dedans, surtout en terme de media pour garder un ratio intéressant en terme de bande passante, autant pour vous que pour moi. Il y a aussi la problématique des liens qui nécessitent de lancer un serveur local. En Python 3 via python3 -m http.server ou en Python 2 python -m SimpleHTTPServer mais ça reste une (fausse pour OSX/Linux ?) dépendance dont j’aimerais me passer.

En conclusion, je suis un peu à court d’idées sur la façon d’exposer un site statique offline, si vous avez des idées ça pourrait même être un sujet pour les élaboratoires SudWeb.

★ Stages en informatique

Ça va la gestion de l’hystérie ? Y a pénurie d’anxiolytiques en plus de celle de l’essence ? Cool de se baser sur un article un peu sensationnaliste du Monde pour descendre des jeunes essayant de faire quelque chose de leur vie. Perso je suis l’un des « exploités » dont tu parles, et j’ai jamais autant kiffé ma life et autant progressé de ma vie. Les stages à 2Francs on m’en a proposé partout ailleurs. Ici on vit, on trime pas. Je crée, je ne subis pas. J’ai une paie de stagiaire ? Je côtoie des gens brillants et j’apprends au quotidien. 200€ de plus par mois remplace le savoir ? Le jour où je sors d’ici j’aurais appris assez pour créer MON entreprise. L’indépendance c’est mal selon toi ? Ou je devrais plutôt passer mon temps à me branler au lieu d’apprendre pour prendre mon envol je suis payé décemment oui. J’ai ma petite paie, ma chambre, je ne dépense rien pour la bouffe et les restos. J’crois bien qu’il y a des cotisations sur les stagiaires. Pour l’instant ce n’est qu’un stage a temps partiel de 4 mois pour moi j’sais bien qu’on est loin d’être parfaits. La boite n’a que quelques mois. On est tous étudiants ici. À chaque stage que j’ai fait, j’étais un stagiaire. Point. Grosse boite, ptite boite. J’vois pas où est le problème ici j’sais pas si t’as raté le passage où j’t’ai dit que j’étais payé. Et bien au dessus des 3.5€/heure qu’on m’a proposé ailleurs Et les stages où on te met dans un coin pour faire un site en solo, j’en ai vu défiler. Google mon tuteur de stage, merci bcp des boites confortables où des stagiaires avaient des gueules de déterrés j’en ai vu aussi. Tu t’en fous de ça ? Perso je me lève quand je veux, bosse, fais du sport, sors faire la fête, voir ma copine quand je veux. Garde tes stages carrés c’est vrai que je regrette les tickets resto. Sinon, on ne m’offrait pas de vacances ni de tickets pour les grands matchs avant. Vous êtes drôles avec vos histoires de secte. On vole haut. Autant les histoires de statut j’comprend mais là... Bah ouais. Après mes 7-8h à faire semblant de bosser en bon designer, j’suis chez moi. J’fais ce que je veux. Le plus c’est que je le fais à l’heure que je veux. Je gère mon temps. Personne ne me dit oui ou non. le truc c’est que je ne cours pas après l’argent. J’ai juste envie de devenir très bon dans mon domaine. C’est mon objectif. J’ai vu le salariat, la zone de confort et le quotidien branlette, sans défis, sans goût. Je veux créer, pas suivre bêtement. Nan mais, pour la énième fois. On est payés. Il n’y a que les fondateurs qui ne touchent pas de salaire. Pour l’instant je suis à temps partiel et je suis mieux payé que mon précédent stage à temps plein dans une grosse SSII. Ça va ? Libre à vous d’écouter ce que je vous raconte plutôt que de camper sur vos aprioris. c’est pas beau c’est sûr mais c’est pragmatique. Et faut se dire que pour une start up qui débute c’est plutôt normal la prise de recul me fais voir ce que j’y gagne vraiment. Peut-être pas des de gros sous, mais des compétences et c’est la capitalisation sur ces compétences qui m’intéresse pour la suite. Je regardes sur le long terme. Le salariat à vie ne m’intéresse pas en fait. Aller à l’étranger, varier les domaines, créer, innover me passionne plus. Merci de votre intérêt en tout cas. J’espère juste avoir réussi à partager mon point de vue ! C’est un tremplin ici !

@HiD3f sur Twitter

Plus que l’article à sensation (cache) ou la réponse facile (cache), c’est l’avis d’une personne en interne qui m’intéresse. Et là on a de la matière. On pourrait y voir un syndrome de Stockholm ou de l’immaturité. J’y vois la réalité du marché du stage. Directe. Brutale.

Pour avoir un peu côtoyé des étudiants cherchant un stage, ils sont désespérés. Vraiment. On les oblige à en trouver un pour valider leur cursus et au fil des semaines qui s’écoulent ils sont prêts à accepter n’importe quoi. C’est avant tout ce système là qu’il faut dénoncer. Les dérives qui s’ensuivent ne sont qu’une illustration de la main invisible de l’exploitation lorsque l’offre devient supérieure à la demande. C’est la terrible violence du capitalisme. Prendre à parti des jeunes qui ont envie d’apprendre et soif d’entreprendre c’est se tromper de cible.

Si vous voulez inverser la tendance, augmentez la demande qualifiée dans vos entreprises, accompagnez des étudiants, prenez le temps de former la prochaine génération. Montrez-leur qu’une autre voie est possible. Concrètement. Prendre cinq minutes pour dénoncer sur Twitter c’est bien mais ça n’aura aucune conséquence si ce n’est que chacun reparte frustré et incompris dans sa bulle. Prendre trois/six mois pour transformer un étudiant en pair c’est autrement plus enrichissant.

Par ailleurs, lorsqu’un boulot peut facilement être effectué par un stagiaire sans que le commanditaire ne s’en rende compte c’est qu’il y a un problème. Soit de sur-formation (fut-elle autodidacte), soit de sous-qualité. J’ai la douloureuse impression qu’il s’agit davantage de la seconde option dans notre profession… Cela nécessiterait une bonne dose d’éducation côté client pour savoir apprécier le travail bien fait et être en capacité d’arbitrer en connaissance de cause. Nous sommes les seuls à avoir les compétences pour faire ce travail.

The obvious source of failure no one talks about

despair

Every time I see a startup dying, I can’t help but trying to understand what went wrong. Unfortunately, you can’t turn back time or get a time lapse of a multiple years history.

Unlike success, a startup failure might be hard to understand. Obvious reasons exist: lack of product / market fit, co founders issues, poor execution, lack culture, failure to build a great team, but it doesn’t explain everything.

Before 2011, Twitter was well known for its “fail whale” and inability to scale. Early Google was relying on (poor) competitors data before they had a big enough index. And Docker was once a Platforms As A Service (PAAS) before they pivoted to focus on Docker. Before they became the success story we hear about all over the Internet.

Semi failure is even harder to analyse. How can you know what made a promising company barely survive after 5 or 10 years without diving into an insane amount of data? Beside the company internals, such as product evolution, business model pivots, execs turnaround — a sign something’s fishy, not necessary the reason — and poor selling strategies, you need to analyse the evolution of the market, their clients and indeed their competitors.

There’s something else no one talks about when analysing failure. Something so obvious it sounds ridiculous until you face it.

Yesterday I wanted to see a friend whose startup only has 1 or 2 months cash left. Yesterday was also an optional bank holiday in France, but I didn’t expect their office door to be closed.

I was shocked. If my company was about to die, I would spend the 30, 45 remaining days trying to save it by all means. I’d run everywhere trying to find some more cash. I’d have the product team release that deal breaker differentiating feature. I’d try to find a quick win pivot. I’d even try to sell to my competitors in order to save some jobs. But I’d certainly not take a bank holiday.

Then I remembered every time I went there during the past 2 years, sometimes dropping for a coffee, sometimes using their Internet connection when I was working remotely and did not want to stay at home. There was no one before 10:00AM, and there was no one after 7:00PM. There were always people playing foosball / the playstation / watching a game on TV. Not like they were thousands people, more like a dozen. I remember late lunchs and, early parties.

Despite a fair product and promising business plan, they missed something critical. “Work hard, play harder” reads from left to right, not the other way around. In the startup world, the obvious source of failure no one talks about is the lack of work.

The myth of the "always at 200%" team

From Paris Marathon 2008

In the past decade, I’ve met many entrepreneurs asking their team to be as dedicated to their job as they are.

When I hire someone, I want them to be at 200%, 24/7, 365 days a year. If I send them an email at 2:00 AM, I expect an answer within 10 minutes. That’s the way you build a great business.

They all failed.

I experienced that state of mind, and it didn’t turn well. Employees of the company would stay awake late to be sure they would not miss an email from the boss. They wanted to be the first ones to answer to show how reactive and motivated they were. The ugly truth was, none of us was working efficiently building a great company. We were slacking on the Web late at night, checking our email from time to time, just in case something would happen. After one year, we all stopped pretending, and an incredible percentage of the team divorced.

Building a great team is hard. Keeping it is harder, and an important turnover is already a failure.

Quoting Richard Dalton on Twitter,

Teams are immutable. Every time someone leaves, or joins, you have a new team, not a changed team.

This is even more true for small teams where losing someone with specific skills can make the whole team at stake.

When one of my guys had to take a 3 months sick leave, I had 2 options. The first one was to divide his projects to the whole team, putting more pressure on them, asking them to do extra hours and working during the weekend so we could finish all the projects in time as expected. The second one was rescheduling the less critical projects and explaining my management why we would postpone some of them, and why it was OK to do it.

Would I have been in a huge corporation where the Monday morning report meeting is a sacred, well oiled ceremony with all your peers looking at each other, expecting them to fall from their pedestal as the leader gets mad at them for sliding their projects, I might have picked up the first option.

Forcing the whole team to work harder because of one of them missing would have been a huge mistake with terrible results. You can’t expect a team already working under pressure to work more to catch up with their absent pal projects without getting poor results and ressent towards the missing guy. Even more, this would have lead to someone else leaving for a sick leave after a few weeks, or leaving at all, destroying the team and all the efforts done to build it during more than one year.

As a manager, your first duty is to make sure the whole team succeeds, not to cover your ass from your management ire. For that reason, I decided to reschedule our projects, because the “always at 200%” team on the long run is a myth. And a planned failure.

Building an awesome Devops team on the ashes of an existing infrastructure

Devops Commando

5AM, the cellphone next to my bed rings continuously. On the phone, the desperate CTO of a SAAS company. Their infrastructure is a ruin, the admin team has left the building with all the credentials in an encrypted file. They’ll run out of business if I don’t accept to join them ASAP he cries, threatening to hang himself with a WIFI cable.

Well, maybe it’s a bit exaggerated. But not that much.

I’ve given my Devops Commando talk about taking over a non documented, non managed, crumbling infrastructure a couple of time lately. My experience on avoiding disasters and building awesome devops teams rose many questions that led me into writing down everything before I forget about them.

In the past 10 years, I’ve been working for a couple of SAAS companies and done a few consulting for some other. As a SAAS company, you need a solid infrastructure as much as solid sales team. The first one is often considered as a cost for the company, while the second is supposed to make it live. Both should actually considered assets, and many of my clients only realised it too late.

Prerequisites

Taking over an existing infrastructure when everyone has left the building to make it something viable is a tough, long term job that won’t go without the management full support. Before accepting the job, ensure a few prerequisites are filled or you’ll face a certain failure.

Control over the budget

Having a tight control of the budget is the mosts important part of getting over an infrastructure that requires a full replatforming. Since you have no idea of the amount of things you’ll have to add or change, it’s a tricky exercise that needs either some experience or a budget at least twice as much as the previous year. You’re not forced to spend all the money you’re allowed, but at least you’ll be able to achieve your mission during the first year.

Control over your team hires (and fires)

Whether you’re taking over an existing team or building one form scratch, be sure you have the final word on hiring (or firing). If the management can’t understand that people who use to “do the job” at a certain time of the company’s life don’t fit anymore, you’ll rush into big trouble. Things get worse when you get people who’s been slacking or under performing for years. After all, if you’re jumping in, that’s because some things are really fishy aren’t they?

Freedom of technical choices

Even though you’ll have to deal with an existing infrastructure, be sure you’ll be given free hands on the new technical choices when they happen. Being stuck with a manager who’ll block every new technology he doesn’t know about, or being forced to pick up all the newest fancy, not production ready things they’ve read on Hackers News makes one ops life a nightmare. From my experience, keeping the technos that work, even though they’re outdated or you don’t like them can save you lots of problems, starting with managing other people’s ego.

Freedom of tools

Managing an infrastructure requires a few tools, and better pick up the ones you’re familiar with. If you’re refused to switch form Trac to Jira, or refused a PagerDuty account for any reason, be sure you’ll get in trouble very soon for anything else you’ll have to change. Currently, my favorite, can’t live without tools are Jira for project management, PagerDuty for incident alerting, Zabbix for monitoring and ELK for log management.

Being implied early into the product roadmap

As an ops manager, it’s critical to be aware of what’s going on on the product level. You’ll have to deploy development, staging (we call it theory because “it works in theory”) and production infrastructure and the sooner you know, the better you’ll be able to work. Being implied in the product roadmap also means that you’ll be able to help the backend developers in terms of architecture before they deliver something you won’t be able to manage.

Get an initial glance of the infrastructure:

It’s not really a prerequisite, but it’s always good to know where you’re going. Having a glance of the infrastructure (and even better at the incident logs) allows you to setup your priorities before you actually start the job.

Your priorities, according to the rest of the company

Priority is a word that should not have a plural

For some reasons, most departments in a company have a defined, single priority. Sales priority is to bring back new clients, marketing to build new leads, devs to create a great product without bugs. When it comes to the devops team, every department has a different view on what you should do first.

The sales, consulting and marketing expect stability first to get new clients and keep the existing ones. A SAAS company with an unstable infrastructure can’t get new clients, keep the existing ones, and get bad press outside. Remember Twitter Fail Whale era? Twitter was most famous for being down that everything else.

The product team expect you to help deliver new feature first, and they’re not the only ones. New feature are important to stay up to date in front of your competitors. The market expects them, the analysts expect them, and you must deliver some if you want to look alive.

The development teams expect on demand environment. All of them. I’ve never seen a company where the development team was not asking for a virtual machine they could run the product on. And they consider it critical to be able to work.

The company exec, legal team, your management expect documentation, conformity to the standards, certifications, and they expect you to deliver fast. It’s hard to answer a RFP without a strong documentation showing you’ve a state of the art infrastructure and top notch IT processes.

As a devops manager, your only priority is to bring back confidence in the infrastructure, which implies reaching the whole company’s expectation.

The only way to reach that goal is to provide a clear, public roadmap of what you’re going to do, and why. All these points are critical, they all need to be addressed, not at the same time, but always with an ETA.

Our work organisation

I’m a fan of the Scrum agile methodology. Unfortunately, 2–3 weeks sprints and immutability do not fit a fast changing, unreliable environment. Kanban is great at managing ongoing events and issues but makes giving visibility on the projects harder. That’s why we’re using a mix of Scrum and Kanban.

We run 1 week sprints, with 50% of our time dedicated to the projects, and 50% dedicated to managing ongoing events. Ongoing events are both your daily system administration and requests from the developers that can’t wait for the following sprint.

Our work day officially starts at 10AM for the daily standup around the coffee machine. Having a coffee powered standup turns what can be seen as a meeting into a nice, devops-friendly moment where we share what’s we’ve done the day before, what we’re going to do, and which problems we have. If anyone’s stuck, we discuss the various solutions and plan a pair-working moment if it takes more than a minute to solve.

Sprint planning is done every Friday afternoon so everybody knows what they’ll do Monday morning. That’s a critical part of the week. We all gather around a coffee and start reviewing the backlog issues. Tasks we were not able to achieve during the week are added on the top of the backlog, then we move the developers requests we promised to take care of, then the new projects. People pick up the projects they want to work on, with myself saying yes or no or assigning projects I consider we must do first in last resort. We take care of having everyone working on all the technologies we have so there’s no point of failure in the team and everybody can learn and improve.

Each devops work alone on their projects. To avoid mistakes and share knowledge, nothing ships to production without a comprehensive code review so at least 2 people in the team are aware of what’s been done. That way, when someone is absent, the other person can take over the project and finish it. In addition to the code reviews, we take care about documentation, the minimum being operation instruction being added in every Zabbix alert.

Managing the ongoing events Managing the ongoings is a tricky part because they often overlap with the planned projects and you can’t always postpone them. You’ll most probably take a few months before you’re able to do everything you planned to within a week.

During the day, incident management is the duty of the whole team, not only the oncall person. Oncall devops also have their projects to do so they can’t be assigned all the incidents. Moreover, some of us are more at ease with some technologies or part of the infrastructure and are more efficient when managing an incident. (Backend) developers are involved in the incidents management when possible. When pushing to production, they provide us with a HOWTO to fix most of the issues we’ll meet so we can add them to Zabbix alert messages.

We try to define a weekly contact who’ll manage the relationships with the development team so we’re not disturbed 10 times a day and won’t move without a Jira ticket number. Then, the task is prioritised in the current sprint or another one, depending on the emergency. When managing relationships with the development teams, it’s important to remember that “no” is an acceptable answer if you explain why. The BOFH style is the best way to be hated by the whole company, and that’s not something you want, do you?

In any case, we always provide the demander with an ETA so they know when they can start working. If the project is delayed, we communicate about the delay as well.

When you have no one left

Building a new team from scratch because everyone has left the building before you join is a rewarding and exciting task, except you can’t stop the company’s infrastructure while you’re recruiting.

During the hiring process, which can take up to 6 months, I rely on external contractors. I hire experienced freelancers to help me fix and build the most important things. Over the year, I’ve built a good address book of freelancers skilled with specific technologies such as FreeBSD, database management or packaging so I always work with people I’ve worked with, or people who’ve worked with people I trust.

I also rely on vendors consulting and support to help on technologies I don’t know. They teach me a lot and help fixing the most important issues. When I had to take over a massive Galera cluster, I relied on Percona support during the 6 first months so we’re now able to operate it fully.

Finally, we work a lot with the developers who wrote the code we operate. That’s an important part since they know most of the internals and traps of the existing machines. It also allows to create a deep link with the team we’re going to work the most with.

Recruiting the perfect team

Recruiting the perfect devops team is a long and difficult process, even more when you have to build a small team. When looking for people, I look for a few things:

Complementary and supplementary skills

A small team can’t afford having single points of failure, so we need at least 2 people knowing the same technology, at least a bit when possible. We also look for people knowing other technologies, whether or not we’ll deploy them someday. Having worked on various technologies give you a great insight on the problem you’ll encounter when working on similar ones.

Autonomy and curiosity

Our way of working requires people to be autonomous and not wait until we help them when they’re blocked. I refuse to micro manage people and ask them what they’re doing every hour. They need to be honest enough to say “I don’t know” or “I’m stuck” before the projects delays go out of control.

Knowledge of the technologies in place and fast learners

Building a team from scratch on an existing platform requires to learn fast how to operate and troubleshoot it. Having an experience in some if the technologies in place is incredibly precious and limits either the number of incidents or their length. Since hiring people who know all the technologies in place is not possible, having fast learners is mandatory so they can operate them quickly. Being able to read the code is a plus I love.

Indeed, every medal has two sides, and these people are both expensive and hard to find. It means you need to feed them enough to keep them on the long term.

Knowing who are your clients

The first thing before starting to communicate is to understand who your client, the one you can get satisfaction metrics from, is. Working in a B2B company, I don’t have a direct contact with our clients. It means my clients are the support people, sales persons, project managers, and the development team. If they’re satisfied, then you’ve done your job right.

This relationship is not immutable and you might reconsider it after a while. Sometimes, acting like a service provider for the development team does not work and you’ll have to create a deeper integration. Or, on the contrary, take your distance if they prevent you from doing your job correctly, but that’s something you need time to know.

Communication and reporting

Communication within the company is critical, even more when the infrastructure is considered a source of problems.

Unify the communication around one person, even more when managing incidents

We use a dedicated Slack channel to communicate about incidents, and only the infrastructure manager, or the person oncall during the night and weekend communicates there. That way, we avoin conflicting messages with someone saying the incident is over while it’s not totally over. This also requires a good communication within the team.

Don’t send alarming messages.

Never. But be totally transparent with your management so they can work on a communication when the shit really hits the fan, which might happen. This might mean they’ll kick you in the butt if you’ve screwed up, but at least they’re prepared.

Finally, we always give an ETA when communicating about an incident, along with a precise functional perimeter. “A database server has crashed” has no meaning if you’re not in the technical field, “People can’t login anymore” does. And remember that “I don’t have an ETA yet” is something people can hear.

We do a 3 slides weekly reporting with the most important elements:

  • KPIs: budget, uptime, number of incidents, evolution of the number of oncall interventions.
  • Components still at risk (a lot in the beginning).
  • Main projects status and ETA.

Discovering the platform

So you’re in and it’s time for the things to get real. Here are a few things I use to discover the platform I’ll have to work on.

The monitoring

Monitoring brings the most useful thing to know about the servers and services you operate. It also provides a useful incident log so you know what breaks the most. Unfortunately, I’ve realised that the monitoring is not always as complete as it should and you might get some surprises.

The hypervisor

When running on the cloud or a virtualised infrastructure, the hypervisor is the best place to discover the infrastructure even though it won’t tell you which services are running, and which machines are actually used. On AWS, the security groups provide useful informations about the open ports, when it’s not 1–65534 TCP.

nmap + ssh + facter in a CSV

Running nmap with OS and service discovery on your whole subnet(s) is the most efficient discovery way I know. It might provide some surprises as well: I once had a machine with 50 internal IP addresses to run a proxy for 50 geo located addresses! Be careful too, facter does not return the same information on Linux and FreeBSD.

tcpdump on the most central nodes

Running tcpdump and / or iftop on the most central nodes allows a better comprehension of the networking flows and service communication within your infrastructure. If you run internal and external load balancers, they’re the perfect place to snif the traffic. Having a glance at their configuration also provides helpful information.

Puppet / Ansible

When they exist, automation infrastructure provide a great insight on the infrastructure. However, from experience, they’re often incomplete, messy as hell and outdated. I remember seeing the production infrastructure running on the CTO personal Puppet environment. Don’t ask why.

The great old ones

People working in the tech team for a while often have a deep knowledge of the infrastructure. More than how it works, they provide useful information on why things have been done this way and why it will be a nightmare to change.

The handover with the existing team

If you’re lucky, you’ll be able to work with the team you’re replacing during 1 or 2 days. Focus on the infrastructure overview, data workflows, technologies you don’t know about and most common incidents. In the worst case, they’ll answer “I don’t remember” to every question you ask.

In the beginning

In the beginning, there was Jack, and Jack had a groove. And from this groove came the groove of all grooves. And while one day viciously throwing down on his box, Jack boldy declared, “Let there be HOUSE!”, and house music was born. “I am, you see,  I am the creator, and this is my house! And, in my house there is ONLY house music.

So, you’re in and you need to start somewhere, so here are a few tricks to make the first months easier.

Let the teams who used to do it manage their part of the infrastructure. It might not be state of the art system administration, but if it works, it’s OK and it lets you focus on what doesn’t work.

Create an inventory as soon as you can. Rationalise the naming of your machines so you can group them into clusters and later on, automate everything.

Restart every service one by one, under control to make sure they come back. Once, I had postfix configuration into a sendmail.cf file, and the service had not be restarted for months. Another time, a cluster did not want to restart after a crash because the configuration files were referring servers that had be removed 1 year sooner.

Focus on what you don’t know but works, then look at what you know but needs fixes. The first time I took over a sysadmin-less infrastructure, I left the load balancers away because they were running smoothly, focusing on the always crashing PHP batches. A few weeks later, when both load balancers crashed at the same time, it took me 2 hours to understand how everything was working.

Automate on day one In the beginning, you’ll have to do lots of repetitive tasks, so better start automating early.

If I have to do the same task 3 times, I’ve already lost my time twice.

The most repetitive thing you’ll have to do is deployment, so better start with them. We’re using an Ansible playbook triggered by a Jenkins build so the developers can deploy when they need without us. If I didn’t want, I could ignore how many deployments to production are done every day.

Speaking of involving the developers, ask the backend developers to provide the Ansible material they need to deploy what they ask you to operate. It’s useful both for them to ensure dev, production and theory are the same, and to know things will be deployed the way they want with the right library.

Giving some power to the development team does not mean leaving them playing in the wild. Grant them only the tools they need, for example using Jenkins builds or users with limited privileges through automated deployment.

Resist in hostile environments

Hostile environment: anything you don’t have at least an acceptable control on.

Developers designed servers are a nightmare to operate so better talk about them first. A developer designed server is a machine providing a full feature without service segregation. The processes, database, cache stack… runs on the same machine making them hard to debug and impossible to scale horizontally. And they take a long time to split. They need to be split into logical smaller (virtual) machines you can expand horizontally. It provides reliability, scalability but has an important impact on your network in general and on your IP addressing in particular.

Private clouds operated by a tier are another nightmare since you don’t control resources allocation. I once had a MySQL server that crashed repeatedly and couldn’t understand why. After weeks of searches and debugging, we realised the hosting company was doing memory ballooning since they considered we used too much memory. Ballooning is a technic that fills part of the virtual machine memory so it won’t try to use everything it’s supposed to have. When MySQL started to use more than half of the RAM it was supposed to have, it crashed because it didn’t have enough despite the operating system saying the contrary.

AWS is another hostile environment. Machines and storage might disappear anytime, and you can’t debug their NATted network. So you need to build your infrastructure for failure.

Write documentation early

Finally, let’s talk about documentation. Infrastructure documentation is often considered a burden, and with the infra as code fashion, automation scripts are supposed to be the real documentation. Or people tell “I’ll write documentation when I’ll have time, for now everything is on fire”.

Nothing’s more wrong (except running Docker in production). But yes, writing documentation takes time and organisation, so you need to iterate on it.

The tool is an critical part if you want your team to write documentation. I like using Git powered wiki using flat Markdown files like the ones on Github or Gitlab, but it does not fit everyone, so I often fallback to Confluence. Whatever the tool, ensure the documentation is not hosted on your infrastructure!

I usually start small, writing down operation instructions in the monitoring alert messages. It’s a good start and allows you to solve an incident without digging into the documentation looking for what you need. Then, we build infrastructure diagrams using tools like Omnigraffle on Mac, or Lucidchart in the browser. Then we write comprehensive documentation around those 2.

Conclusion

Well, that’s all folks, or most probably only the beginning of a long journey in turning a ruin into a resilient, blazing fast, scalable infrastructure around an awesome devops team. Don’t hesitate to share and comment if you liked this post.

The downside of loving your job too much

Bored monkey

A few weeks ago, we were discussing what we’d do after we leave our company before starting another job. Most of us wanted to take a 1 month break during the summer vacation so they can profit from their family. Having a tough job including 24/7 oncalls at least once a month, I was more radical:

“When I leave Synthesio after leveraging my stocks for a few millions (I hope), I’ll take a 6 months vacation. My wife smiled at me and said:
– I don’t believe you. After one month you’ll get so bored that you will start another company and we won’t see you for another 5 years.”

After thinking about it for a second, I told her she was wrong. I’ll probably get bored to tears after 2 weeks.

Migrating a non Wordpress blog to Medium for the nerdiest

Caves Pommery à Reims

I’ve just finished migrating 10 years of blogging from Publify to Medium. If you’re wondering, I’ll keep this blog online and updated, but I wanted to profit from the community and awesome UI Medium brings since I’ve never been able to do a proper design.

In this post, I’ll explain how you can migrate any blog to Medium since only Wordpress is supported so far.

To migrate your blog to Medium, you need:

  • Some dev and UNIX skills.
  • A blog.
  • A Medium account and a publication.
  • A Medium integration API key.
  • To ask Medium to remove the publishing API rate limit on your publication.

Installing medium-cli

There are many Medium SDKs around but most of them are incomplete and won’t allow you to publish in publications, but there’s a workaround. I’ve chosen to rely on medium-cli, a NPM command line interface that does the trick.

$ (sudo) npm install (-g) medium-cli

Medium-cli does not allow to push to a publication so we’ll have to patch it a bit to make it work. Edit the lib/medium.js file and replace line 38 with:

.post(uri + ‘publications/’ + userId + ‘/posts’)

Since medium-cli also cleans unwanted arguments, we’ll have to add 2 lines at the end of the clean() function, lines 61–62.

publishedAt: post.publishedAt,
notifyFollowers: post.notifyFollowers

These are 2 important options:

  • publishedAt is a non documented API feature that allows to back date your old posts.
  • notifyFollowers will prevent Medium from spamming your followers will all your new publications.

Setting up medium-cli to post to your publication

To post to Medium with medium-cli, you need:

  • Your Medium user id.
  • Your Medium publication id.

We’ll get it using the API with some curl foo.

First, get your own information:

$ curl -H “Authorization: Bearer yourmediumapikeyyoujustgenerated” https://api.medium.com/v1/me
{“data”:{“id”:”1234567890",”username”:”fdevillamil”,”name”:”Fred de Villamil ✌︎”,”url”:”https://medium.com/@fdevillamil","imageUrl":"https://cdn-images-2.medium.com/fit/c/200/200/0*IKwA8UN-sM_AoqVj.jpg"}}

Now, get your publication id

$ curl -H “Authorization: Bearer yourmediumapikeyyoujustgenerated” https://api.medium.com/v1/users/1234567890/publications
{“data”:[{“id”:”987654321",”name”:”Fred Thoughts”,”description”:”Fred Thoughts on Startups, UX and Co”,”url”:”https://medium.com/fred-thougths","imageUrl":"https://cdn-images-2.medium.com/fit/c/200/200/1*EqoJ-xFhWa4dE-2i1jGnkg.png"}]}

You’re almost done. Now, create a medium-cli blog and configure it with your API key.

$ medium create myblog
$ medium login
$ rm -rf myblog/articles/*

Edit your ~/.netrc file as the following:

machine api.medium.com
 token yourmediumapikeyyoujustgenerated
 url https://medium.com/your-publication
 userId 987654321

Here we are (born to be king) we can now export the content of your blog.

Export your blog content

There are many ways to export your blog content. If you don’t have a database access, you can crawl it with any script using the readitlater library.

For my Publify blog, I’ve written a rake task.

desc “Migrate to medium”
task :mediumise => :environment do
 require ‘article’
dump = “/path-to/newblog/”
Article.published.where(“id > 7079”).order(:published_at).each do |article|
 if File.exists? “#{dump}/{article.id}-#{article.permalink}”
 next
 end
 Dir.mkdir “#{dump}/#{article.id}-#{article.permalink}”
 open(“#{dump}/#{article.id}-#{article.permalink}/index.md”, ‘w’) do |f|
 f.puts “ — -”
 f.puts “title: \”#{article.title}\””
 f.puts “tags: \”#{article.tags[0,2].map { |tag| tag.display_name }.join(“, “)}\””
 f.puts “canonicalUrl: https://t37.net/#{article.permalink}.html”
 f.puts “publishStatus: public”
 f.puts “license: cc-40-by-nc-sa”
 f.puts “publishedAt: ‘#{article.published_at.to_time.iso8601}’”
 f.puts “notifyFollowers: false”
 f.puts “ — -”
 f.puts “”
 f.puts article.html(:body)
 f.puts “”
 f.puts article.html(:extended)
 f.puts “”
 f.puts “Original article published on <a href=’https://t37.net/#{article.permalink}.html’>#{article.title}</a>”
 end
 end
end

Nothing really complicated indeed. Whatever your solution, export in your myblog directory. Then

$ mkdir archives
$ mkdir failed
$ cd myblog
for i in $(ls | egrep -v ^articles | sort -n | head -n 10); do 
mv $i articles
foo=$(medium publish | grep Done)
if [ -z “$foo” ]; then
 echo failed: $i
 mv articles/$i ../failed
else
 echo OK: $i
 mv articles/$i ../archives/
 fi
foo=””
done

That’s all folks! Hope it will help you while you’re waiting for Medium to provide an easier way to do it.

ElasticSearch cluster rolling restart at the speed of light with rack awareness

At the speed of light

Woot, first post in more than one year, that’s quite a thing!

ElasticSearch is an awesome piece of software, but some management operations can be quite a pain in the administrator’s ass. Performing a rolling restart of your cluster without downtime is one of them. On a 30 something server cluster running up to 900GB shards, it would take up to 3 days. Hopefully, we’re now able to do it in less than 30 minutes on a 70 nodes with more than 100TB of data.

If you’re looking for ElasticSearch rolling restart, here’s what you’ll find:

  1. Disable the shard allocation on your cluster.
  2. Restart a node.
  3. Enable the shard allocation.
  4. Wait for the cluster to be green again.
  5. Goto 2 until you’re done.

Indeed, part 4 is the longest, and you don’t have hours, if not days. Hopefully, there’s a solution to fix that: rack awareness.

About Rack Awareness

ElasticSearch shard allocation awareness is a rather underlooked feature. It allows you to add your ElasticSearch nodes to virtual racks so the primary and replica shards are not allocated in the same rack. That’s extremely handy to ensure fail over when you spread your cluster between multiple data centers.

Rack awareness requires 2 configuration parameters, one at the node level (restart mandatory) and one at the cluster level (so you can do it runtime).

Let’s say we have a 4 nodes cluster and want to activate rack awareness. We’ll split the cluster into 2 racks:

  • goldorack
  • alcorack

On the first two nodes, add the following configuration options:

node.rack_id: "goldorack"

And on the 2 other nodes:

node.rack_id: "alcorack"

Restart, you’re ready to enable rack awareness.

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "cluster.routing.allocation.awareness.attributes" : "rack_id"
    }
}'

Here we are, born to be king. Your ElasticSearch cluster starts reallocating shards. Wait until complete rebalance, it can take some times. You’ll soon be able to perform a blazing fast rolling restart.

First, disable shard allocation globally:

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable": "none"
    }
}'

Restart the ElasticSearch process on all nodes in the goldorack rack. Once your cluster is complet, enable shard allocation back.

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable": "all"
    }
}'

A few minutes later, your cluster is all green. Woot!

What happened there?

Using rack awareness, you ensure that all your data is stored in nodes located in alcorack. When you restart all the goldorack nodes, the cluster elects alcorack replica as primary shards, and your cluster keeps running smoothly since you did not break the quorum. When the goldorack nodes come back, they catch up with the newly indexed data and you’re green in a minute. Now, do exactly the same thing with the other part of the cluster and you’re done.

For the laziest (like me)

Since we’re all lazy and don’t want to ssh on 70 nodes to perform the restart, here’s the Ansible way to do it:

In your inventory:

[escluster]
node01 rack_id=goldorack
node02 rack_id=goldorack
node03 rack_id=alcorack
node04 rack_id=alcorack

And the restart task:

- name: Perform a restart on a machine located in the rack_id passed as a parameter
  service: name=elasticsearch state=restarted
  when: rack is defined and rack == rack_id

That’s all folks, see you soon (I hope)!