Carnet de notes

Catégorie : Développement web

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

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

     

  • Extre­mely Defen­sive PHP

    Comment faire un code qui évite les mauvaises pratiques et reste main­te­nable en élimi­nant les risques ? La présen­ta­tion de Marco Pivetta est à regar­der.

    Il y a pas mal d’idées. Tout n’est pas forcé­ment à reprendre tel quel à mon avis, mais ça permet au moins d’y penser.

  • Perfor­mances et ressenti

    Être obligé de donner une illu­sion de ralen­tis­se­ment pour que les gens comprennent que la page est char­gée, ça me donne un petit tic nerveux, je ne sais pas pourquoi.

    Au contraire, dès que je vois un site qui se charge presque instan­ta­né­ment, je suis ravi.

    — Stéphane, à partir d’un billet qui conti­nue chez David

    Peut-être que le terme de perfor­mance n’est pas le bon. Est-ce vrai­ment la vitesse qui pose problème ou l’ab­sence de compré­hen­sion de ce qu’il se passe ?

    Je ne crois pas me rappe­ler avoir lu des études critiquant de trop bonnes perfor­mances. En fait c’est tout le contraire. Ce que j’ai lu milite systé­ma­tique­ment pour des chan­ge­ments infé­rieurs à 10ms, y compris sur le web.

    En revanche, il en existe un bon paquet qui critiquent l’ab­sence de tran­si­tion ou l’ab­sence de feed­back sur action. Parfois rien que propo­ser un état « enfoncé » sur un lien ou un bouton, pour les quelques milli­se­condes où le bouton de souris ou touch­pad reste en bas de course, ça suffit à faire effet. Les appli­ca­tions mobiles natives, plutôt bonnes en perfor­mance, ajoutent elles-aussi beau­coup d’ani­ma­tions, simple­ment parce que c’est une façon de donner du feed­back du type « regarde, je fais ce que tu m’as demande, j’ai bien pris en compte, voilà ce qu’il se passe ». C’est d’ailleurs un des prin­ci­paux trucs qui font préfé­rer les appli­ca­tions natives aux sites web, même si personne ne s’en rend compte.

    Je me dis, chez David, c’est peut être que les deux pages avant et après se ressemblent beau­coup. Avec un chan­ge­ment immé­diat sans tran­si­tion certains sont peut être un peu perdus, par exemple ne sachant pas s’ils sont remon­tés en haut ou sur une nouvelle page. La tran­si­tion CSS joue peut être plus parce qu’elle amène le nouveau contenu et le présente bien comme du nouveau qui appa­rait de zéro, et pas forcé­ment grâce à la lenteur retrou­vée.

    Je réflé­chis à haute voix, peut-être suis-je à côté de la plaque. Il faudrait tenter des tests A/B, diffé­rentes vitesses d’ani­ma­tion

  • Approa­ching coding style ratio­nally

    […] in most cases, there is no need to have Interface in the name of an inter­face.

    — Matthieu Napoli

    Et d’en­chaî­ner de la même façon avec le suffixe Excep­tion, avec des exemples concrets et parlants.

    Les préfixes et suffixes sont jolis pour la clas­si­fi­ca­tion et l’es­prit ingé­nieur avec plein de tiroirs hiérar­chi­sés, mais on finit avec des noms à rallonge, un code plus complexe, moins lisi­ble…

    Pour moi c’était la diffé­rence entre Java et PHP il y a quelques années. Je la vois de moins en moins aujourd’­hui. Bien dommage, parce que si on ne se rend pas immé­dia­te­ment compte de la charge cogni­tive qu’ap­porte toutes nos sur-archi­tec­tures, l’im­pact est bien réel, lui.

  • Pattern: Backends For Fron­tends

    On a desk­top app I might allow you to look at the items for sale, order online or reserve in store. On the mobile device though I might want to allow you scan bar codes to do price compa­ri­sons or give you context-based offers while in store. As we’ve built more and more mobile appli­ca­tions we’ve come to realise that people use them very diffe­rently and there­fore the func­tio­na­lity we need to expose will differ too.

    So in prac­tice, our mobile devices will want to make different calls, fewer calls, and will want to display different (and proba­bly less) data than their desk­top coun­ter­parts. This means that we need to add addi­tio­nal func­tio­na­lity to our API backend to support our mobile inter­faces.

    Another problem with the gene­ral-purpose API backend is that they are by defi­ni­tion provi­ding func­tio­na­lity to multiple, user-facing appli­ca­tions. This means that the single API backend can become a bottle­neck when rolling out new deli­very, as so many changes are trying to be made to the same deployable arti­fact.

    — Sam Newman

    Pas forcé­ment convaincu par tout, aucune recette miracle, mais inté­res­sant à lire pour amor­cer une réflexion. La couche d’API doit-elle être géné­rique ou spéci­fique à chaque appli­ca­tion ?

  • Cere­bral (React)

    Je manque d’ex­pé­rience en React / Flux, mais je partage quelque chose qui m’a eu l’air d’avoir du sens à partir de la vidéo (je partage un lien et pas direc­te­ment la vidéo parce que ça commence à 5h44m30s, ils ont visi­ble­ment filmé tout en une passe) : Cere­bral

    Le passage qui montre le scéna­rio de l’ap­pli­ca­tion et permet de comprendre tout le fonc­tion­nel et l’en­chaî­ne­ment sans aucun code est tout de même assez sympa (même si l’im­bri­ca­tion fait peur).

  • PsySH

    A runtime deve­lo­per console, inter­ac­tive debug­ger and REPL for PHP

    — PsySH

    Le php -a est quand même inuti­li­sable par rapport à ce qui existe par exemple en ruby. Voilà une solu­tion.

    Le site ne le dit pas, mais si vous êtes sous mac, l’ins­tal­la­tion passe logique­ment par home­brew:

    brew install homebrew/php/psysh

  • Which Input When?

    The inputs we inter­act with in real life follow some pretty basic rules, and we can get really confu­sed if they don’t. If you’re trying to mani­pu­late the tempe­ra­ture of a tap, for instance, only the range slider input makes sense. But if you were trying to mani­pu­late the tempe­ra­ture of your kettle, it’d be best to use the step­pers on the right.

    real-life

    Unfor­tu­na­tely, what can seem obvious in real life can get confu­sing when we move to soft­ware. Soft­ware is more abstract, and can deal with really complex sets of data that simply don’t appear in your kitchen. Here are some simple rules which can help guide which type of input you should use when, to make your design as intui­tive to use as possible.

    — Morgan Carter

    Aucune révo­lu­tion mais c’est bien fait, visuel, et fina­le­ment inté­res­sant à garder dans un coin.

  • Seriously, Don’t Use Icon Fonts

    So it’s really no wonder that icon fonts became such a hit. Icons displayed via @font-face were reso­lu­tion-inde­pendent and custo­mi­zable in all the ways we expec­ted text to be. Sure, deli­ve­ring icons as a type­face was defi­ni­tely a hack, but it was also useful, versa­tile, and maybe even a little fun.

    But now we need to stop. It’s time to let icon fonts pass on to Hack Heaven, where they can frolic with table-based layouts, Bullet-Proof Roun­ded Corners and Scalable Inman Flash Repla­ce­ments. Here’s why…

    — Cloud Four Blog

    On peut résumé par « utili­sez SVG » mais le fond est bien plus complet.

    L’ar­ticle lie aussi Bullet­proof Acces­sible Icon Fonts, où on se rend compte que tout est loin d’être simple si on veut faire les choses bien. Ce dernier lien devrait être la réfé­rence de ceux qui veulent quand même s’y essayer.