Carnet de notes

Catégorie : Technique

  • 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

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

  • Feature Toggles

    Plus j’avance et moins je crois aux branches et aux livrai­sons unitaires. Pour plein de raisons, quitte à sacri­fier un peu de perfor­mance, je conseille la livrai­son en produc­tion de tout le code, même s’il n’est pas fini.

    L’im­por­tant c’est l’in­ter­rup­teur, la possi­bi­lité d’ac­ti­ver ou désac­ti­ver un compor­te­ment.

    Feature toggles are a power­ful tech­nique, allo­wing teams to modify system beha­vior without chan­ging code. They fall into various usage cate­go­ries, and it’s impor­tant to take that cate­go­ri­za­tion into account when imple­men­ting and mana­ging toggles. Toggles intro­duce complexity. We can keep that complexity in check by using smart toggle imple­men­ta­tion prac­tices and appro­priate tools to manage our toggle confi­gu­ra­tion, but we should also aim to constrain the number of toggles in our system.

    — Martin Fowler

    L’ar­ticle est long, il n’aborde pas vrai­ment le comment, mais résume beau­coup de choses sur l’ap­proche et le quoi.

  • Le baro­mètre des salaires 2015 dévoile ses résul­tats

    Rien de très éton­nant ni nouveau mais tout de même inté­res­sant :

    • une année d’ex­pé­rience corres­pond en moyenne à 3 à 5% de salaire en plus
    • la rému­né­ra­tion variable conti­nue d’être assez rare dans nos métiers
    • on recrute hommes et femmes globa­le­ment au même salaire mais les augmen­ta­tions ne suivent pas le même rythme, pour arri­ver à 20% de diffé­rence dans la dernière tranche d’ex­pé­rience
    • les rému­né­ra­tions en Île de France sont 20% plus hautes que dans le reste de la France.

    Je comprends tout à fait l’ori­gine de cette dernière donnée mais sa perti­nence m’in­ter­roge.

    Pourquoi l’en­tre­prise dépen­se­rait plus pour des infor­ma­ti­ciens sur Paris plutôt qu’en région alors qu’ils vont produire la même chose ? Ou vu de l’autre côté, pourquoi paie­rait-on moins un infor­ma­ti­cien hors Île de France alors qu’en plus les locaux et l’en­ca­dre­ment y coûtent moins cher  pour l’en­tre­prise ?

    Si on consi­dère que c’est unique­ment l’en­tre­prise qui est légi­time à payer le moins possible, pourquoi donc est-ce qu’on conti­nue à tout concen­trer sur Paris ? Je ne vois pas la logique dans tout cela.

    Des entre­prises qui viennent de Paris et qui décident de migrer en région sans en chan­ger les salaires risquent d’avoir un avan­tage compé­ti­tif signi­fi­ca­tif tout en descen­dant leurs coûts (pas sur le salaire, mais sur les locaux, les négo­cia­tions annuelles, les coûts de recru­te­ments…)

    Atten­tion quand vous faites des filtres assez sélec­tifs, la base de réponses reste assez limi­tée.