Carnet de notes

Catégorie : Technique

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

  • La commu­nauté JS est actuel­le­ment une machine à créer de la dette tech­nique

    on est dans la phase de l’ado­les­cence. Ça cri, ça bouge, ça a plein d’éner­gie, et ça mérite des baffes.

    — par Sam & Max

    L’ins­tal­la­tion est deve­nue un enfer. Entre les dépen­dances dépré­ciées, les libs incom­pa­tibles, les diffé­rents outils de build, et les options de config et les plugins, c’est une merde incom­men­su­rable. Plusieurs stan­dards d’ins­tal­leurs (et outils joints) se tirent la bourre : AMD, CommonJS et Harmony. Vous vous souve­nez du temps ou on copiait juste jQuery dans le réper­toire static ?

    […] On peut faire plus de choses qu’a­vant. De manière plus propre […] Mais l’éco­sys­tème, c’est le bordel géné­ral, l’anar­chie totale, et ça conti­nue d’avan­cer, en lais­sant tout le reste derrière.

    Les projets JS s’ac­cu­mulent, de free­lances en SS2I qui se pointent, codent ou (surtout) recodent, et repartent en lais­sant un projet qu’il sera imbu­vable à reprendre, dépré­cié avant même d’être terminé, non docu­menté, non testé.

    Livré sans commen­taire, mais j’ai­me­rais bien les vôtres.

  • Deploying PHP 7

    Il y a de tout et de rien dans cette présen­ta­tion de Rasmus à Paris, mais je reste impres­sionné par le gain en perfor­mance annoncé partout pour PHP 7. Si on en obtient même la moitié de ça, ça reste une révo­lu­tion pour PHP.

    On parle de +30% de requêtes trai­tées dans le même temps au mini­mum, souvent +50% et plus, le tout en utili­sant moins de mémoire.

    J’ai envie de mettre des graphiques mais on va me dire qu’il ne sont pas repré­sen­ta­tifs, alors faites les vôtres.

     

  • Phan – Static analy­zer for PHP

    • Checks for calls and instan­tia­tions of unde­cla­red func­tions, methods, closures and classes
    • Checks types of all argu­ments and return values to/from func­tions, closures and methods
    • Supports @param, @return, @var and @deprecated phpdoc comments inclu­ding union and void/null types
    • Checks for Uniform Variable Syntax PHP 5 -> PHP 7 BC breaks
    • Unde­fi­ned variable tracking
    • Supports names­paces, traits and varia­dics
    • Gene­rics (from phpdoc hints – int[], string[], UserObject[], etc.)
    • Expe­ri­men­tal dead code detec­tion

    Je me rappelle les bidouilles sur PHP_Code_Snif­fer à SQLi à partir du toke­ni­zer, et les essais d’ana­lyse statique de Pascal sur les montées en version de PHP à TEA.

    Là Phan semble un vrai outil, basé sur un AST natif au langage. Je suis certain qu’on n’en est qu’au début des possi­bi­li­tés offertes par l’AST de PHP 7. Rien que l’aide à la migra­tion ne va pas être inutile.

    J’ai un peu peur qu’on entre dans le monde Java, d’au­tant plus que les type hints sont main­te­nant la norme et que le langage se complexi­fie, mais pas mal de portes s’ouvrent en ce moment pour PHP, et c’est sacré­ment cool.

  • So You Think You Can Program An Eleva­tor

    Many of us ride eleva­tors every day. We feel like we unders­tand how they work, how they decide where to go. If you were asked to put it into words, you might say that an eleva­tor goes where­ver it’s told, and in doing so goes as far in one direc­tion as it can before turning around. Sounds simple, right? Can you put it into code?

    J’adore l’idée : Le défi de program­mer un ascen­seur, avec une expli­ca­tion initiale, quelques tests, et le défi de tout faire… pour se rendre compte que c’est quand même bien plus complexe que ça ne semble à-priori.

    C’est du python mais la syntaxe ne repré­sente très clai­re­ment qu’une très faible part de l’exer­cice. Avec la doc en ligne ça doit être faisable sans être limité par l’uti­li­sa­tion d’un langage qu’on ne connait pas vrai­ment.

    J’ai presque envie d’es­sayer, mais juste peur de commen­cer, me rendre compte que ça va me prendre des jours, et aban­don­ner. Je sais que c’est un peu l’objet de l’exer­cice, mais si je commence sans arri­ver à quelque chose ça ne va pas me mettre dans un état d’es­prit très posi­tif.

  • Fluent inter­face are evil

    1. Fluent Inter­faces break Encap­su­la­tion
    2. Fluent Inter­faces break Deco­ra­tors (and some­times Compo­si­tion)
    3. Fluent Inter­faces are harder to Mock
    4. Fluent Inter­faces make diffs harder to read
    5. Fluent Inter­faces are less readable (perso­nal feeling)
    6. Fluent Inter­faces cause BC breaks during early deve­lop­ment stages

    — Fluent Inter­face are Evil

    J’ai parfois l’im­pres­sion d’être dans les dino quand je me bats contre cette mode alors je suis heureux de voir ne pas être le seul.

    Ce type d’écri­ture est juste magique pour créer des filtres succes­sifs, essen­tiel­le­ment dans les objets de construc­tion (buil­der).

    Pour tout le reste, c’est juste un faux raccourci d’écri­ture. On casse beau­coup de choses pour gagner quelques carac­tères. Le plus souvent on ne les gagne pas vrai­ment puisqu’il faut bien penser à faire le return $this/self dans la méthode appe­lée et à gérer correc­te­ment l’in­den­ta­tion dans la méthode appe­lante.