Carnet de notes

Catégorie : Technique

  • Objets connec­tés… décon­nec­tés

    J’ai acheté ma TV il y a bien long­temps. À l’époque nous avons accepté d’y mettre plus pour avoir un système de replay inté­gré à la TV. À la sortie du carton le replay ne fonc­tion­nait pas, « prochai­ne­ment » qu’ils disaient. Ça a duré des mois puis on a eu M6, mais sans les séries et fictions phares. Quand elles ont été là nous avons eu des publi­ci­tés avant lectu­re… alors que le site offi­ciel n’en avait pas (ou pas autant, je ne sais plus). Au bout d’un moment le service a été fermé. Voilà pour ma TV. Sony je pense à toi, je n’ai plus rien racheté chez toi depuis.

    En avril c’est le hub Nest qui est arrêté, à peine deux ans après sa commer­cia­li­sa­tion. On ne parle pas d’une fonc­tion annexe de perdue mais d’un appa­reil de 300 $ qui ne sert plus que de presse-papier.

    Il y a quelques jours j’ai vu passer l’an­nonce d’arrêt d’une carte SD wifi. Oui, une simple carte SD qui fait wifi. Le construc­teur peut déci­der de ne simple­ment plus les faire fonc­tion­ner, à peine un an après sa fin de commer­cia­li­sa­tion.

    Et si demain Adobe, Amazon ou Kobo décident d’ar­rê­ter le support de leur DRM de livre numé­rique ? Vos livres risquent de ne deve­nir que des suites de 0 et de 1 tota­le­ment illi­sibles.

    Nous avons de plus en plus d’objets connec­tés, de conte­nus numé­riques contrô­lés par des tiers, sans que jamais nous n’ayons un quel­conque enga­ge­ment de péren­nité.

    Pour du logi­ciel sur abon­ne­ment c’est une chose, pour du maté­riel qu’on achète et qui n’a aucune raison de s’ar­rê­ter de fonc­tion­ner, c’est encore plus diffi­cile à conce­voir.

    Inter­net of things qu’ils disaient. Nous ne contrô­lons plus rien, nous ne déte­nons plus rien. Une société privée peut à tout moment déci­der que notre maté­riel, chez nous, arrê­tera de fonc­tion­ner, simple­ment parce que ce n’est plus rentable pour elle. Peut-être même simple­ment pour promou­voir ou se concen­trer sur une nouvelle version en vente.

    À l’heure où on parle d’ob­so­les­cence program­mée, de garan­tie de dispo­ni­bi­lité de pièces déta­chées, il serait temps d’im­po­ser par la loi une péren­nité mini­mum, ou au moins que le vendeur affiche très expli­ci­te­ment le temps de fonc­tion­ne­ment garanti.

  • Lectures tech­niques en vrac – début juin 2016

    Using React Native: One year later. Où il semble que la réac­ti­vité ne soit pas vrai­ment là. Je me demande si du pur web pose­rait les mêmes diffi­cul­tés.

    Les services publics anglais bannissent les « apps ». À l’op­posé de la tendance gadget, pour ceux qui ont une vraie réflexion sur le long terme et pas seule­ment une volonté de faire des opéra­tions de commu­ni­ca­tion…

    The Soft­ware Deve­lop­ment Poverty Trap. Le piège à pauvreté, où ne pas avoir d’argent fait dépen­ser plus, et donc empêche de passer le palier qui permet­trait de s’en sortir. Superbe analo­gie sur un article pas trop long.

     

  • Compo­si­tion d’une équipe tech­nique produit

    – Dis, on met quoi dans une équipe tech­nique ?

    Ça dépend du temps, du produit, des besoins. Voici ma recette par défaut, à réagen­cer en fonc­tion de la réalité. Il reste qu’à chaque fois je finis par me dire que j’au­rais aimé la voir suivre ce schéma :

    1 et 2 : Donc au début on commence, il faut un ou deux déve­lop­peurs. Idéa­le­ment à ce niveau ils savent toucher un peu de front et un peu de back, et appré­cient de pouvoir inter­ve­nir partout. Pas d’ad­mi­nis­tra­tion système à cette taille, on exter­na­lise un maxi­mum.

    Petit inter­mé­diaire. Il faut une direc­tion tech­nique avant de passer au troi­sième membre de l’équipe. Ce peut être un direc­teur tech­nique à part entière ou un des deux déve­lop­peurs qui a suffi­sam­ment de bouteille mais il faut quelqu’un qui a une vision tech­nique, et pas un néophyte.

    3 : Le troi­sième c’est le grand oublié : le web desi­gner. Il fait de l’UX, de l’UI, et va défi­nir une vraie expé­rience client. Bien évidem­ment tout dépend du métier et du produit mais recru­ter trop tard est habi­tuel­le­ment une erreur. La mode est de consi­dé­rer que ce profil doit même faire partie des fonda­teurs.

    4 : On complète avec un troi­sième déve­lop­peur. On peut commen­cer à envi­sa­ger un spécia­liste qui apporte une exper­tise qui manque aux deux autres mais il faudra quand même qu’il accepte de toucher un peu à tout.

    5 : L’équipe commence à avan­cer, main­te­nant il lui faut quelqu’un pour donner une direc­tion et prendre du recul. On peut l’ap­pe­ler product owner, respon­sable produit, chef de projet fonc­tion­nel, analyste métier… Il aura pour charge de réflé­chir aux usages, imagi­ner le produit, assu­rer la vision. Ce doit être quelqu’un de dédié, sans posi­tion hiérar­chique sur le reste de l’équipe.

    6 (et 7 ?) : L’équipe avance, dans le bon sens, il reste à lui donner un peu de puis­sance avec un ou deux autres déve­lop­peurs. À partir de quatre déve­lop­peurs c’est la taille où l’ef­fort est démul­ti­plié et où on peut commen­cer à assu­rer les impré­vus, ou les congés de chacun. Au delà de 5 déve­lop­peurs on commence à faire des sous-équipes et ça n’a plus grand inté­rêt.
    Les équipes les plus dyna­miques avec lesquelles j’ai travaillé ont des déve­lop­peurs qui travaillent tous sur l’in­té­gra­lité du produit mais on peut aussi avoir quelques experts qui inter­viennent essen­tiel­le­ment sur leur domaine de compé­tence.

    8 : Second grand oublié : Le dev op – ou sys admin, peu importe le nom. Son rôle est d’as­su­rer la produc­tion mais sa réelle valeur est de flui­di­fier tout l’ou­tillage interne, comme la plate­forme d’in­té­gra­tion conti­nue ou les scripts de déploie­ment.
    Il n’a d’in­té­rêt qu’a­vec une équipe qui tourne, mais s’en passer c’est comme conti­nuer en gardant un boulet aux pieds. Avant ce sont les déve­lop­peurs qui sont obli­gés de perdre du temps et du focus avec tout ça.

    9 : Je vais à neuf avant de m’ar­rê­ter mais j’ajoute quand même un dernier profil avec un tech­ni­cien. C’est lui qui va assu­rer les tâches d’ex­ploi­ta­tion courantes, s’oc­cu­per du support tech­nique, du support utili­sa­teur, et soula­ger le product owner.
    On peut s’en passer mais c’est au prix d’un manque de focus non négli­geable, donc d’un peu de gâchis.

    Je n’ai pas parlé de mana­ger mais à neuf le besoin s’est peut-être déjà fait sentir depuis un petit moment. S’il existe, il peut faire le dixième. Le problème du mana­ger mérite plus d’un billet mais je retiens une règle : ni la direc­tion commer­ciale de la société, ni le product owner de l’équipe. Ce peut être le CTO qui gère la direc­tion tech­nique décrite plus haut.

    Je n’ai pas mis de QA non plus. Je conti­nue à penser que l’équipe doit être respon­sable de ce qu’elle livre. Une QA sépa­rée à tendance à déres­pon­sa­bi­li­ser mais aussi à ajou­ter de la distance avec la réalité et du délai lors des livrai­sons. Ça aura du sens quand il y aura plusieurs équipes, pas tout de suite. Le dev op pourra par contre outiller et auto­ma­ti­ser un maxi­mum de tests et de proces­sus entre temps.

    Et vous, vous conseillez quoi comme compo­si­tion ? Qu’ai-je oublié ?

  • Mention bot, cibler la revue de code

    À La Ruche qui Dit Oui, comme dans mon équipe précé­dente, on fait des revues de code avec la règle des deux pouces. Pour qu’une modi­fi­ca­tion appli­ca­tive passe en produc­tion il faut qu’elle soit vali­dée par deux pairs, qui vont mettre un ? (le feed­back par emoji, si vous n’avez pas essayé, vous manquez quelque chose).

    En discu­tant avec les équipes d’Al­go­lia, on m’a pointé mention-bot. L’idée est simple : avec un git blame on repère qui est le déve­lop­peur qui a le plus travaillé sur ces parties de code et on le mentionne expli­ci­te­ment auto­ma­tique­ment comme parti­ci­pant poten­tiel à la revue.

    Do you have a GitHub project that is too big for people to subscribe to all the noti­fi­ca­tions? The mention bot will auto­ma­ti­cally mention poten­tial revie­wers on pull requests. It helps getting faster turna­round on pull requests by invol­ving the right people early on.

    Je ne sais pas si ça va vrai­ment s’in­té­grer à notre struc­tu­ra­tion par équipes ici (le déve­lop­peur ciblé risque d’être sur un autre équipe, donc pas la meilleure personne pour faire la revue sur le projet en cours) mais je partage quand même.

  • [Lecture] Ideal HTTP Perfor­mance

    A common ques­tion about Server Push is “what if the client already has a copy in cache?” Because Push is inhe­rently specu­la­tive, there’s always the chance that you’re sending some­thing that the brow­ser doesn’t need.

    HTTP/2 allows the client to cancel the push in this situa­tion, with a RESET_STREAM. Howe­ver, even then, there’s roughly a round trip’s worth of wasted data in flight that could have been used for better things. Remem­ber, the ideal is to send only the data that the client needs to show the page.

    A propo­sed solu­tion for this is for the client to use a compact Cache Digest to tell the server what it already has in cache, so that the server knows what’s needed.

    Bon article de Mark Nottin­gham sur HTTP 2, qui dépasse les notions de base qu’on voit partout. On y parle même un peu des évolu­tions de TCP.

  • [Lecture] How Etsy Formats Currency

    In order to follow along, you need to know one impor­tant thing: Currency format­ting depends on three attri­butes: the currency, the member’s loca­tion, and the member’s language.

    04_flowchart

    Excellent billet d’Etsy sur la loca­li­sa­tion des montants et devises. Rien que pour la cultu­re…

  • 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.