Carnet de notes

Catégorie : Développement informatique

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

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

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

  • 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

  • No, You Don’t Need To Struggle Testing React

    Writing tests in such an envi­ron­ment need to satisfy two rules:

    1. Writing specs should take the least amount of time possible.
    2. Each spec should test as much code as possible.

    Now I’ve proba­bly already lost half of you reading this. « Each spec should test as much as possible? How do you isolate failures?” Yeah, yeah, I agree, but at the end of the day, the only purpose of my testing suite is to make sure that the little CircleCI dot on Github turns red whene­ver I merge a brea­king change.

    — Stephen Grider

    C’est voir un seul côté du miroir, et au travers de lunettes de soleil.

    Le test auto­ma­tisé n’est pas là que pour l’in­té­gra­tion conti­nue. Il est aussi là pour prou­ver que le code qu’on a produit corres­pond bien à ce qui est souhaité. Il est aussi là pendant le déve­lop­pe­ment pour ne pas faire du pas à pas et du test manuel encore et encore jusqu’à ce que ça semble fonc­tion­ner. Il est là pour permettre à un tiers de comprendre et repro­duire.

    Je n’ai rien contre le fait d’avoir un scéna­rio avec plusieurs asser­tions – qui est le fond du billet cité – mais avec des tests les plus gros possibles, on loupe la moitié des objec­tifs. Pire : on se créé une jolie dette tech­nique pour quand on aura quelque chose à chan­ger. Au lieu de reti­rer ou modi­fier quelques tests bien précis, on a un gros truc qui passe au rouge, qu’on va devoir modi­fier au risque d’obli­té­rer des cas limites.

  • Intro­duc­tion to Post­greSQL physi­cal storage

    Should you know about how Postgres handle the physi­cal storage? Maybe not, but knowing how it works can be useful if you need to inves­ti­gate some problems.

    — Rachid Belaid

    C’est long mais excellent. J’ai­me­rais en lire plus des comme ça.