Carnet de notes

Catégorie : Développement informatique

  • 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,…

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

  • [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…

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

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

  • [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: It’s called Things That Rock It happens every week Everyone shows some­thing No prepa­ra­tion needed 10 minutes per person Critique comes in the…

  • [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…

  • [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,…

  • 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: Writing specs should take the least amount of time possible. 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,…