Carnet de notes

Catégorie : Technique

  • Arrê­tez avec les git squash

    Je ne suis pas enthou­siasmé par l’an­nonce de Github. Ok, on peut faire désor­mais un squash sur une branche avant de lancer le merge.

    Je n’aime pas géné­ra­le­ment les squash et les rebase, c’est un fait, mais le cas de Github est proba­ble­ment le cas où le squash me semble toujours une mauvaise idée.

    Cas d’usage : Vous avez fait une branche, envoyé plusieurs commit dessus, publié la branche pour que d’autres fassent une revue, peut-être corrigé un ou deux trucs et repu­blié la branche. Il est temps de fusion­ner votre code avec la branche prin­ci­pale.

    Pourquoi diable cher­cher à faire un squash de la branche ? La seule raison qu’on m’a donné est « avoir un joli histo­rique ». Plus basique­ment ne pas avoir plein de commit en vrac quand on fait un git log sur master.

    Si votre outil de visua­li­sa­tion d’his­to­rique est mauvais, chan­gez votre outil de visua­li­sa­tion, ne bidouillez pas l’his­to­rique à la source ! squash, rebase et fast-forward sont simple­ment de mauvaises pratiques de contour­ne­ment, malheu­reu­se­ment trop répan­dues.

    Il est tout à fait possible de voir les choses sous la forme de branches et de ne pas être pollué par les commit unitaires des autres branches. Il y a plein de bons outils. En fait même git log est tout à fait viable, il suffit de ne pas lais­ser les options par défaut. Vouloir réécrire l’his­toire et effa­cer l’his­to­rique me semble une pratique plus que contes­table pour juste contour­ner le problème.

    Vous voulez ma pratique idéale ? Des branches pour tous les déve­lop­pe­ments, même les fix unitaires. Jamais(*) de fast-forward, de squash ou de rebase une fois le code publié (chez vous vous faites bien ce que vous voulez). La branche prin­ci­pale ne contient que des merge, toujours en –no-ff.

    Pour l’his­to­rique, le plus souvent, on ne devrait même pas regar­der les commit réali­sés sur d’autres branches que celle en cours – le commit de merge qui résume ce qui a été fait devrait suffire.

    Le résul­tat c’est une visua­li­sa­tion linéaire, sans détail inutile, simple à lire, et qui ne néces­site jamais de tricher en suppri­mant ou modi­fiant l’his­to­rique réel.

    Si vous avez besoin, l’his­to­rique complet existe toujours et peut être exploré. Il y a des outils ou para­mètres qui permettent d’avoir une très bonne vision de l’ar­bo­res­cence quand vous en avez besoin.

    C’est quand même dommage d’uti­li­ser un outil de version­ne­ment qui est excellent avec les branches et le travail en paral­lèle pour ensuite en faire une bouillie de commit linéaire et virtuels.

  • Que se passe-t-il le jour où je ne suis plus là ?

    Je peux passer sous un bus et me retrou­ver soit sur un lit d’hô­pi­tal soit dans une boite en chêne. Que se passe-t-il le jour où je ne suis plus là ?

    Les données infor­ma­tiques ne sont pas forcé­ment les premières choses auxquelles mes proches pense­ront mais j’ai la désa­gréable habi­tude de chif­frer les disques et avoir de vrais mots de passe. Pire : je suis l’in­for­ma­ti­cien de la maison et donc le seul à déte­nir certaines clefs.

    Photos, docu­ments, tout ceci risque d’être perdu si le NAS arrête de fonc­tion­ner. Les fichiers qui peuvent trai­ner sur un Google Drive ou un Drop­box ont eux un compte à rebours. Il y a des vraies données qu’il faut faire vivre plus long­temps que moi.

    Livres, textes, codes sources, qu’est-ce que ceux qui restent vont faire de ça ? Sauront-ils même les iden­ti­fier et quelles sont les possi­bi­li­tés ?

    Pour le reste – blog, réseaux sociaux, noms de domaine – je ne sais pas bien quel sens ça a mais je n’ai pas envie de lais­ser un parcours du combat­tant pour que mes survi­vants les éteignent ou les archivent s’ils le souhaitent.

    * * *

    J’ai beau­coup de ques­tions, peu de réponses. Je peux faire un docu­ment qui explique des choses. Le plus compliqué va être qu’il survive et puisse être trouvé faci­le­ment. Le papier peut brûler s’il y a vrai­ment un acci­dent grave, plus proba­ble­ment il sera perdu avant 20 ans. L’in­for­ma­tique n’est guère mieux : j’ai des sauve­gardes mais qui saura y avoir accès sans moi ? qui saura les exploi­ter et retrou­ver l’in­for­ma­tion ?

    Même avec ce docu­ment, est-ce suffi­sant pour qu’un non-infor­ma­ti­cien se débrouille ? Je n’ai de toutes façons pas envie que ma famille fasse de l’ar­chéo­lo­gie infor­ma­tique.

    Aujourd’­hui je demande à deux proches en qui j’ai toute confiance s’ils peuvent prendre cette lourde charge : trans­mettre et porter assis­tance sur ces ques­tions le jour où je ne le pour­rai pas. Je ne sais pas comment ça tien­dra 50 ans, quelle forme ça pourra prendre.

    * * *

    Il restera de toutes façons le point central : les clefs, les mots de passe, les iden­ti­fiants. Je ne peux pas lais­ser un docu­ment avec tout ça, ni sous forme de papier ni sous forme infor­ma­tique, ni chez moi ni chez d’autres.

    Il y a la ques­tion de sécu­rité et de confi­den­tia­lité tant que je suis encore là, mais aussi que les mots de passe vivent. Comment mettrai-je à jour systé­ma­tique­ment ce docu­ment tout en gardant sa confi­den­tia­lité et sans peser sur les deux proches qui accep­te­ront d’être mes relais ?

    On me propose des fichiers chif­frés à poser d’un côté et la clef ou le mot de passe à poser de l’autre. Je ne sais pas quelle péren­nité j’ai côté humain. Je crains aussi la tech­nique : Quel est le risque que le chif­fre­ment soit cassé de mon vivant et que les données fuitent ? Quel est le risque que le chif­fre­ment ne soit pas cassé mais que les tech­no­lo­gies changent et deviennent diffi­cile à exploi­ter à ce moment là ?

    * * *

    Plein de ques­tions, et diable­ment l’en­vie de monter yet another side project pour créer ce qui n’existe pas : une plate­forme et des outils pour s’oc­cu­per de tout cela, simpli­fier ce qui est déjà diffi­cile humai­ne­ment et qui ne doit pas être aussi diffi­cile tech­nique­ment.

  • [Vidéo] Public key cryp­to­gra­phy – Diffie-Hell­man Key Exchange

    J’ai déjà vu l’ex­pli­ca­tion des pein­tures, mais là on va plus loin, et l’ex­pli­ca­tion de Diffie-Hell­man est juste excel­lente.

  • [Lecture] Most soft­ware already has a “golden key” back­door: the system update

    Réflexions à partir d’un article sur Ars Tech­nica

    Q: What does almost every piece of soft­ware with an update mecha­nism, inclu­ding every popu­lar opera­ting system, have in common?

    A: Secure golden keys, cryp­to­gra­phic single-points-of-failure which can be used to enable total system compro­mise via targe­ted mali­cious soft­ware updates.

    Mine de rien, la plupart de nos appa­reils modernes ont un système de mise à jour, souvent auto­ma­tique. Celui qui détient les clefs peut injec­ter ce qu’il veut, ou simple­ment attendre que vous le fassiez vous-même en croyant mettre à jour.

    On parle de Google, Samsung, Apple, Nokia, Micro­soft et les autres. Des gens parfois recom­man­dables, toujours avec leurs propres inté­rêts.

    On parle aussi des États qui, offi­ciel­le­ment ou non, auraient pu avoir accès à ces clefs. Main­te­nant qu’on connait un peu PRISM et l’éten­due des griffes USA, et l’en­vie de la plupart des pays de les imiter, par la force ou par la loi, ce n’est pas rien.

    On parle ensuite de tous les indi­vi­dus qui ont pu avoir accès à ces clefs et les faire fuiter, volon­tai­re­ment ou non.

    This problem exists in almost every update system in wide use today. Even my favo­rite opera­ting system, Debian, has this problem. If you use Debian or a Debian deri­va­tive like Ubuntu, you can see how many single points of failure you have in your update authen­ti­city mecha­nism with this command:

    sudo apt-key list | grep pub | wc -l

    For the compu­ter I’m writing this on, the answer is nine. When I run the apt-get update command, anyone with any one of those nine keys who is sitting between me and any of the webser­vers I retrieve updates from could send me mali­cious soft­ware and I will run it as root.

    Et si je fais rela­ti­ve­ment confiance à la PKI de Apple, Google et Micro­soft, c’est bien moins vrai pour la plupart des indi­vi­dus isolés derrière les logi­ciels open source.

    Person­nel­le­ment mon Debian perso fait confiance à 14 clefs, certaines proba­ble­ment mal sécu­ri­sées, d’autres parta­gées par plusieurs acteurs, et proba­ble­ment toutes sans le niveau de sécu­rité d’un Apple face aux incur­sions des États.

    La sécu­rité c’est défi­ni­ti­ve­ment trop compliqué pour le monde réel dès qu’il s’agit de se proté­ger contre les très gros acteurs.

    Je ne suis même pas certain que ces très gros acteurs le puissent entre eux. La France utilise des postes sous Micro­soft Windows pour l’ar­mée. Même les postes sous Debian, à ma connais­sance la France n’a pas son armée de déve­lop­peur pour faire une revue de tout le code source et le compi­ler eux-même (et même là, on tombe sous le problème du compi­la­teur qui a lui-même une porte déro­bée qu’il repro­duit dans ce qu’il compile, ça s’est déjà vu dans l’his­toire). En cas de vrai conflit, nous sommes tota­le­ment à genoux.

  • La langue des signes et Paris Web racon­tés par une licorne

    Une des choses dont je suis le plus fier vis à vis de Paris-Web, c’est l’ar­ri­vée de la langue des signes et de la vélo­ty­pie.

    Les inter­prètes LSF font un boulot magni­fique au milieu d’un trou­peau de geeks qui parlent en fran­glais plein de jargon et d’acro­nymes, à toute vitesse. En octobre dernier l’équipe a proposé à une de ces inter­prètes de racon­ter comment ça se passe de l’in­té­rieur. C’est une des trois confé­rences à ne pas manquer de cette édition, et elle est pour vous en vidéo :

    Confé­rence LSF from Paris-Web on Vimeo.

    Il s’agit d’un gros budget, pour quelques uns. Ce n’est pas facile tous les ans et à chaque fois que c’est un peu tendu je suis certain que la ques­tion revient sur la table. Pour autant à chaque fois ça tient, même quand il y a un défi­cit.

    Pour moi c’est dans les valeurs de l’évé­ne­ment mais c’est aussi une façon de montrer par l’exemple qu’on peut tenter d’in­clure tout le monde.

  • [Lecture] How we run design critique sessions

    Lu sur le web :

    Recently, we totally chan­ged our design critique sessions. After care­fully analy­zing what was wrong with our previous format, we esta­bli­shed the follo­wing pillars for our design critique sessions:

    1. It’s called Things That Rock
    2. It happens every week
    3. Everyone shows some­thing
    4. No prepa­ra­tion needed
    5. 10 minutes per person
    6. Critique comes in the form of ques­tions
    7. The session ends by a vote

    Let’s go over each point in more details.

    — chez Blabla­car

    Inté­res­sant. On rejoint un peu le système des revues de pair mais avec une autre approche, moins systé­ma­tique et plus bran­chée sur comment parta­ger l’ex­pé­rience pour s’en­ri­chir. J’aime beau­coup l’idée qu’en montrant ce qui fonc­tionne on finit par monter le niveau d’exi­gence.

    Qui fait quelque chose de simi­laire côté déve­lop­pe­ment ? Tout ce que j’ai vu finit par tour­ner dans des présen­ta­tions de tech­nos et moins dans le « voilà ce que j’ai fait ».

  • [Lecture] On a testé fonc­tion­nel­le­ment notre app JS

    Lu sur le web :

    L’uti­lité des tests fonc­tion­nels pour les appli­ca­tions web n’est plus à démon­trer (comment ça, vous ne testez pas encore vos apps ?). Malheu­reu­se­ment, tout ne peut pas être tota­le­ment testé fonc­tion­nel­le­ment, ou de façon aisée : je pense par exemple au player chez nous, un compo­sant stra­té­gique mais pauvre­ment testé fonc­tion­nel­le­ment de par sa nature un peu hybride (mélange de flash et de JS). Dans tous les cas, pour ce qui peut l’être, nous sommes parti­sans dans l’équipe Cytron d’user sans mesure (ou presque !) de cet outil de manière à être le plus zen possible au moment d’ap­puyer sur le bouton “deploy”.

    — chez M6 Web

    Inté­res­sant, mais à deux moments j’ai l’im­pres­sion de tâton­ne­ments, de tests qui peuvent échouer sans raisons et qu’on relance pour s’as­su­rer que ça passe. Je trouve ça assez risqué comme approche. Ai-je mal compris ?

    il nous arri­vait que le compor­te­ment “hover” ne soit pas déclen­ché, mettant en échec la suite du test. Nous avons donc changé notre manière d’ef­fec­tuer le rollo­ver : on répète l’ac­tion grâce au waitUntil tant que l’éle­ment devant appa­raître au hover n’est pas visible

    Pourquoi l’évé­ne­ment n’est-il pas déclen­ché ? Et l’uti­li­sa­teur risque-t-il d’avoir le même bug ?

    Elle permet de stocker dans un fichier texte la liste des scéna­rios en échec pour les relan­cer ensuite afin de véri­fier qu’ils le sont réel­le­ment.

    Des faux posi­tifs ? Et si parfois le test échoue alors qu’il ne devrait pas, il y a-t-il un risque qu’il réus­sisse alors qu’il ne devrait pas ? Combien de fois le relan­cer pour être certain du résul­tat ?

    Le retour d’ex­pé­rience est extrê­me­ment inté­res­sant, mais ça laisse un goût de bidouille qu’il serait préfé­rable de corri­ger avant de consi­dé­rer la solu­tion comme stable.

  • [Lecture] Refac­to­ring a Docker­file for image size

    Lu sur le web :

    There’s been a welcome focus in the Docker commu­nity recently around image size. Smal­ler image sizes are being cham­pio­ned by Docker and by the commu­nity. When many images clock in at multi-100 MB and ship with a large ubuntu base, it’s greatly needed.

    — sur Repli­ca­ted

    J’aime bien l’ap­proche de l’ar­ticle, qui tient plus à reti­rer le super­flu qu’à partir sur des confi­gu­ra­tions peu stan­dard. Main­te­nant, qu’y gagne-t-on ?

    L’es­pace disque est-il vrai­ment un enjeu majeur aujourd’­hui par rapport au temps qu’on y passe et à la perte éven­tuelle de souplesse ?

    Le système de système de fichier par couche devait mutua­li­ser les télé­char­ge­ments et les espaces de stockage. Ai-je mal compris ?

  • Amazon’s custo­mer service back­door

    Wow. Just wow. The atta­cker gave Amazon my fake details from a whois query, and got my real address and phone number in exchange. Now they had enough to bounce around a few services, even convin­cing my bank to issue them a new copy of my Credit Card.

    — Amazon’s custo­mer service back­door

    Rien de neuf, on a déjà vu des récits de comptes twit­ter pira­tés et de commandes VPC rerou­tées, voire de vraies usur­pa­tions d’iden­tité. C’est désor­mais à chaque fois via de l’in­gé­nie­rie sociale.

    Les ques­tions « secrètes » sont de la bonne blagues et un peu de culot accom­pa­gnés d’un télé­phone permettent d’à peu près tout savoir via votre famille ou vos amis. Les supports tech­niques de vos diffé­rents pres­ta­taires ont telle­ment d’in­for­ma­tions sur vous qu’ils sont des cibles privi­lé­giées.

    De fil en anguille, en récu­pé­rant un bout chez l’un, un autre bout chez l’autre, on peut remon­ter jusqu’à avoir quelque chose de fort.

    Peu de solu­tions. Très peu de gens sont prêts à se faire éjec­ter de leurs services et de leurs données s’ils ont simple­ment changé d’adresse et oublié de la mettre à jour, ou perdu leur mot de passe de l’an­cien compte email, etc. Les service de support client ne font que ce que tout le monde attend.

  • Compo­ser paral­lel install plugin

    Bench­mark Example
    288s -> 26s

    — hirak/pres­tis­simo, compo­ser paral­lel install plugin

    Non testé, mais je me dis qu’il y a peu de chances que ça fasse du mal