Carnet de notes

Catégorie : Technique

  • Recom­mençons à zéro — Javas­cript 101

    PHP a été mon langage favori pendant presque 10 ans. Ruby l’a suivi pour à peu près la même durée. Javas­cript a été l’ou­til secon­daire pas très atti­rant pour quand il n’y a pas d’autre choix, c’est à dire sur navi­ga­teur.

    Avant-hier j’ai eu un petit pince­ment de frus­tra­tion en cher­chant à déstruc­tu­rer un diction­naire lors d’une affec­ta­tion. Ruby n’a toujours qu’une demie solu­tion pas très élégante. PHP et Javas­cript ont tous deux énor­mé­ment évolué entre temps, au point qu’on ne les recon­nait qu’à peine.

    Si Ruby garde des capa­ci­tés inéga­lées pour faire de la méta-program­ma­tion, 10 ans c’est peut être le bon moment pour reprendre un autre langage de zéro.

    Je fais du web, j’aime beau­coup l’idée de l’iso­mor­phisme, il me faudra donc quelque chose qui sache compi­ler en Javas­cript. Elm pour­rait me faire du pied vu sa gestion des types mais c’est un pari osé consi­dé­rant qu’il est encore absent côté serveur.

    Ça sera donc Javas­cript. D’abord pour quelques scripts en ligne de commande, puis peut-être des appli­ca­tions plus sérieuses.

    Reprendre de zéro c’est l’oc­ca­sion de lais­ser le passé derrière soi et recom­men­cer comme si c’était un nouveau langage. Je ne prends que les dernières versions et outils récents dans la chaîne, voire ce qui n’est pas encore sec mais qui arri­vera demain.

    Il s’agit aussi de reprendre de zéro, pour apprendre. Exit donc les boiler plate et autres kits de démar­rage rapide.

    Première étape : instal­la­tion de npm (3.10.3) et nodejs (6.3.1).

    # Sur Mac avec Homebrew (http://brew.sh/)
brew install nodejs

    et initia­li­sa­tion du projet (un peu de doc si besoin pour aider à remplir)

    mkdir my-js-project
cd my-js-project
npm init

    Ensuite l’idée c’est d’uti­li­ser le nouveau Javas­cript moderne et ne cher­cher aucune compa­ti­bi­lité passée. Instal­la­tion de Babel pour gérer ES2015 et + :

    npm install --save-dev babel-cli

    La plupart des sites recom­mandent des preset pour ES2015 ou React mais visi­ble­ment Nodejs 6.x gère déjà l’es­sen­tiel des fonc­tions nati­ve­ment. Il existe au moins trois preset spéci­fiques pour Nodejs 6 mais la seule confi­gu­ra­tion commune aux trois est le plugin qui trans­forme les modules ES2015 en modules Commonjs. Je suis donc reparti de là :

    npm install --save-dev babel-plugin-transform-es2015-modules-commonjs

    Puis l’édi­tion du .babelrc :

    {
  "presets": [ ],
  "plugins": [ "transform-es2015-modules-commonjs" ]
}

    Si quelque chose manque à Nodejs 6, il faudra que j’ajoute le plugin corres­pon­dant. Voici les plugins sur lesquels mes trois presets étaient en désac­cord :

    • trans­form-es2015-func­tion-name,
    • syntax-trai­ling-func­tion-commas,
    • trans­form-es2015-destruc­tu­ring,
    • trans­form-es2015-para­me­ters,
    • trans­form-object-rest-spread,
    • trans­form-es2015-sticky-regex,
    • trans­form-es2015-unicode-regex,
    • trans­form-es2015-modules-commonjs,
    • et trans­form-class-proper­ties.

    Je n’ai pas pris le temps de les tester un par un pour voir lesquels étaient réel­le­ment néces­saires pour pas. Si quelqu’un a le courage de faire le travail…

    Reste à enfin permettre d’exé­cu­ter un premier script. J’ai tenté de suivre les usages en mettant les sources dans src/ et les fichiers compi­lés dans lib/ avec un index.js comme fichier prin­ci­pal.

    mkdir lib
echo "Compiled files will go here." > lib/README.md
echo "Leave these files untouched"  >> lib/README.md
echo "and modify ../src/* instead." >> lib/README.md

mkdir src
echo "Source files will go here." > src/README.md
echo "They should be compiled before any use." >> src/README.md
touch src/index.js

    Et la confi­gu­ra­tion du package.json pour lancer tout ça (notez le main qui prend en compte notre nouveau chemin et le scripts qui liste nos deux nouvelles actions) :

    {
  "name": "my-project",
  "main": "./lib/index.js",
  "scripts": {
    "build": "babel src -d lib --source-maps",
    "watch": "babel src -d lib --watch --source-maps"
  },
  "devDependencies": {
    "babel-cli": "^6.11.4",
    "babel-plugin-transform-es2015-modules-commonjs": "^6.11.5"
  }
}

    Un npm run build permet de compi­ler tous les fichiers, un npm run watch permet de surveiller en temps réel les modi­fi­ca­tions des fichiers sources pour mettre à jour les fichiers desti­na­tion corres­pon­dants.

    J’ai ajouté un README, le .giti­gnore proposé par Github pour un projet Nodejs, une licence, et ‘op, vous trou­ve­rez le tout sur Github.

    Ça fait déjà pas mal pour toujours aucune ligne de Javas­cript utile.

    Quelques feed­back après ce tout petit premier pas :

    1– C’est long et complexe

    Oui, j’ai cher­ché les ennuis, il existe des boiler plate tout faits, mais je ne crois pas avoir le même problème avec Python, Ruby, PHP ou d’autres.

    Le fait d’avoir une étape de compi­la­tion avec Babel n’aide pas mais Java pour­rait en dire tout autant. Pourquoi n’existe-t-il pas un babel init qui lit la version courante de Nodejs, m’ins­talle un .babelrc adapté à cette version et me modi­fie mon package.json pour m’ajou­ter les raccour­cis build et watch ?

    Oui, je pour­rais faire une pull-request, mais fallait-il m’at­tendre ?

    2– La doc aide peu

    Fran­che­ment c’est la plaie. Je ne dirais pas qu’il n’y a aucune doc, mais il y en a dans tous les sens. La plupart ne sont pas à jour, toutes semblent incom­plètes, et il est bien diffi­cile de savoir si telle ou telle a pris en compte les dernières évolu­tions.

    Peut-être n’ai-je pas trouvé la bonne réfé­rence ? Dites-moi.

    Rien que le npm init n’était indiqué sur aucune doc que j’ai croisé. Pire : si on l’ou­blie il n’y a pas de message rouge très expli­cite pour indiquer que les npm install –save-dev n’au­ront pas l’ef­fet demandé. Il a fallu comprendre qu’il fallait créer un package.json, puis décou­vrir qu’il n’était pas néces­saire de le faire à la main.

    Ce n’est que le début. Quand il va s’agir de choi­sir une biblio­thèque ou des outils, je sens que ça va être toute une histoire pour d’y retrou­ver. La doc de setup de Babel en donne un premier aperçu.

    J’ai l’im­pres­sion qu’à chaque étape la roue est en pleine recons­truc­tion, et qu’on en a fait plusieurs versions diffé­rentes en paral­lèle, pour tout.

    3– Qui a eu l’idée d’uti­li­ser des fichiers de config JSON ?

    Je suis aussi assez peu fana aussi des config dans des fichiers Json. J’ai l’im­pres­sion de retrou­ver les fichiers de confi­gu­ra­tion XML de Java. Je n’ai pas l’im­pres­sion que ce soit beau­coup plus lisible.

    La grosse diffé­rence c’est que Java a créé ces confi­gu­ra­tions avec tout un outillage autour. Le déve­lop­peur n’avait que rare­ment besoin d’y plon­ger manuel­le­ment. C’était géré auto­ma­tique­ment par les IDE et les scripts.

    J’ai ajouté un plugin au .babelrc décrit plus haut. Ce plugin a une option. Je me retrouve avec un Json de 7 lignes dont 4 qui contiennent autre chose que des crochets et acco­lades fermantes.… et déjà un diction­naire dans un tableau dans un tableau dans un diction­naire. Rien que ça.

    Même mon petit package.json me parait déli­cat à mani­pu­ler malgré l’in­den­ta­tion. Heureu­se­ment que les dépen­dances sont ajou­tées auto­ma­tique­ment par npm lors de leur instal­la­tion.

    Là, dès qu’on dépasse le simple clef valeur, j’ai l’im­pres­sion de me retrou­ver avec une double peine : Un fichier de confi­gu­ra­tion peu aisé à mani­pu­ler, mais pas pour autant d’ou­til pour le faire à ma place.

  • Et si on agençait des photos sur une page ?

    J’ai cher­ché à agen­cer des vignettes de photo de façon harmo­nieuse sur une page web. Le problème à l’air simple mais j’ai des photos de tous formats, dont certains vrai­ment atypiques.

    La grille

    La méthode la plus simple c’est de choi­sir un format d’images, choi­sir un nombre de colonnes, et de s’y tenir. Si une image n’a pas le bon ratio, il suffira de couper ce qui dépasse. 500px utilise encore ce système pour la plupart de ses vues.

    grillePour aller plus loin on peut mettre quelques photos en grande taille en prenant la place de plusieurs autres. On casse la mono­to­nie tout en permet­tant de mettre en avant les images les plus impor­tantes.

    En prévoyant plusieurs agen­ce­ments diffé­rents prédé­ter­mi­nés on peut réus­sir à caser des images en format diffé­rent, et ne pas trop déna­tu­rer  les formats portraits ou les images très étirées. On reste toute­fois fixés à des formats prédé­ter­mi­nés.

    Le système de grille est rapide et effi­cace. La seule contrainte est de choi­sir entre la capa­cité de respec­ter scru­pu­leu­se­ment l’ordre des photos et celle de choi­sir manuel­le­ment lesquelles seront mises en avant.

    L’al­go­rithme de Packery va encore plus loin sur ce chemin. À partir d’une grille fixée, il propose de défi­nir un nombre de lignes et de colonnes pour chaque image et de la placer à l’es­pace le plus adapté. L’ordre n’est alors qu’in­di­ca­tif et on doit toujours rogner les images pour les faire tenir sur un nombre fixe de lignes et colonnes, mais on y place des formats et des tailles très diffé­rentes. Pas de secret toute­fois, cet agen­ce­ment lais­sera forcé­ment des blancs. À vous de voir si c’est accep­table, quitte à tenter de les combler par quelques mots.

    Quel que soit le système de grille, le réel enjeu est de savoir ce qu’on peut couper ou pas dans chaque image pour qu’elle colle aux formats prévus. Certains algo­rithmes y arrivent main­te­nant assez bien, surtout quand il y a des visages.

    Même si mon cas d’usage me permet­trait de choi­sir manuel­le­ment comment décou­per chaque image au cas par cas, intel­lec­tuel­le­ment ça me gêne de couper des pixels que j’avais volon­tai­re­ment choisi de garder lors de la créa­tion initiale de l’image. Je crains aussi que le visi­teur s’en fasse une idée faus­sée et au final n’ouvre pas l’image dans son format voulu. C’est parti­cu­liè­re­ment vrai pour les images très en hauteur ou très en largeur, qui ne pour­ront jamais donner le même ressenti si elles sont tronquées.

    On empile

    L’autre méthode est d’em­pi­ler les photos par lignes ou par colonnes en respec­tant leur ratio.

    Tumblr le fait par colonnes en mettant chaque image sur la première place dispo­nible. On obtient une sensa­tion de vrac où l’ordre des images n’est qu’à moitié respecté mais le résul­tat est parfait pour leur cas d’usage. Toutes les images ne terminent pas à la même hauteur mais c’est là encore tout à fait légi­time pour le système de flux sans fin que repré­sente un Tumblr.

    On peut imagi­ner de mettre en avant des images en les passant sur deux colonnes mais, sauf à espé­rer un cas excep­tion­nel où les deux images du dessus s’ar­rêtent pile à la même hauteur, il faudra soit lais­ser du blanc soit couper un peu la plus longue des deux.

    Avec un algo­rithme un peu intel­li­gent on peut tenter de repé­rer quand deux images arrivent presque à la même hauteur et donc ne couper que quelques pixels qui ne se verront pas, mais ça veut aussi dire que l’image mise en avant est quasi­ment lais­sée au hasard. La proba­bi­lité d’en avoir une dépend direc­te­ment de la quan­tité de pixels qu’on accepte de rogner sur les images.

    Pour quelque chose de plus struc­turé Flickr a choisi une dispo­si­tion par lignes. On choi­sit une hauteur cible et on empile toutes les images une à une jusqu’à la fin de la ligne. Ça ne tombe jamais juste mais Flickr se permet alors de faire varier légè­re­ment la hauteur de la ligne à la hausse ou à la baisse. Si on respecte les ratios des images concer­nées, on finira forcé­ment par tomber sur la largeur de ligne souhai­tée. On peut choi­sir de garder la dernière image ou pas (respec­ti­ve­ment en dimi­nuant ou augmen­tant la hauteur de ligne) en fonc­tion de la dispo­si­tion la plus proche de la hauteur idéale.

    Avec un peu de complexité on doit pouvoir éviter les lignes incom­plètes en fin de page. Il suffit de tenter plusieurs combi­nai­sons sur les x dernières lignes puis voir laquelle respecte le mieux la hauteur cible pour chaque ligne parmi celles qui n’ont aucune ligne incom­plète. Je ne suis cepen­dant pas tota­le­ment certain que ça vaille le coup, et ça peut faire varier signi­fi­ca­ti­ve­ment la hauteur des dernières lignes.

    Ce système permet des mises en avant simples en mettant une image en pleine largeur de temps en temps. On peut même, si on le souhaite, avoir des mises en avant à largeur arbi­traire. Il suffit alors de mettre les mises en avant sur un des bord et de reprendre l’al­go­rithme stan­dard sur la largeur restante. Une fois arrivé proche du bas de l’image mis en avant, on la réduit ou l’agran­dit légè­re­ment (avec pour effet d’agran­dir ou de réduire propor­tion­nel­le­ment l’es­pace hori­zon­tal sur le côté, et donc la hauteur corres­pon­dante) jusqu’à ce que les deux corres­pondent.

    On peut aussi imagi­ner ne pas se limi­ter à une seule mise en avant par hauteur et les empi­ler sur un ou deux côtés, y compris sur des hauteurs diffé­rentes. La contrainte va être de toujours avoir les plus hautes à l’ex­té­rieur.

    Il reste que la dispo­si­tion en colonnes de Tumblr flatte les images verti­cales et vigné­tise à l’ex­cès des images orien­tées format paysage. La dispo­si­tion en lignes de Flickr fait l’op­posé et rend diffi­cile la lecture des images au format portrait.

    Si un format est très forte­ment majo­ri­taire, on peut imagi­ner utili­ser le système des mises en avant pour compen­ser.

    Je n’ai pas vu d’adap­ta­tion de l’al­go­rithme Flickr en ce sens. Il faut dire que ça complexi­fie­rait nette­ment un système qui est sinon rela­ti­ve­ment simple. Si j’ai un peu de temps, je vais peut-être tenter l’ex­pé­rience.

    Quelques liens si le sujet vous inté­resse :

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