Carnet de notes

Catégorie : Développement informatique

  • Conti­nuous Deli­very: The Dirty Details

    Il n’y a rien d’ex­cep­tion­nel­le­ment nouveau mais ça permet quand même de prou­ver certaines pratiques : Préfé­rer des déploie­ments en perma­nence plusieurs fois par jour plutôt que de faire un événe­ment une fois de temps en temps à date program­mée avec vrai proces­sus autour.

  • SQL Tabs

    SQL Tabs is an open source cross plat­form desk­top client for Post­gresql with

    • Data­base explo­rer
    • Rich scripts output
    • Charts from query result
    • Mark­down rende­ring
    • Dark and bright themes
    • Clas­sic and vim editing modes

    and many more useful features.

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

  • Product Mana­gers, Product Owners, and Scalable Models for Agile Product Teams (Cisco)

    Le titre dit déjà tout. Peut être rien de révo­lu­tion­naire, mais quelques rappels et défi­ni­tions bien inté­res­santes.

    Je refor­mule mais « les commer­ciaux ont pour rôle de faire tout ce qui est raison­nable ou dérai­son­nable pour boucler le gros deal à venir, dont les un ou deux trucs que que le produit n’a pas et qui sont spéci­fiques à ce pros­pect » parle sérieu­se­ment à mon expé­rience. C’est aussi une façon très claire d’ex­pliquer pourquoi les socié­tés qui veulent créer un produit ne doivent pas être diri­gés par les commer­ciaux, et doivent avoir des respon­sables produit indé­pen­dants.

    Inté­res­sante aussi la distinc­tion entre product mana­ger et product owner. Pour tenter de la mettre en place depuis quelques mois, c’est parfois loin d’être évident.

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

  • How we do large scale retros­pec­tives

    In late 2014 we had an oppor­tu­nity to run a program level retro for an inno­va­tion initia­tive that span­ned across 80–90 people in NYC and Stock­holm.  Instead of a large session, we opted to try some­thing bit different – and we found it to work better for these types of initia­tives.

    — Labs at Spotify

    Et vous ? comment gérez-vous vos rétro ? Arri­vez-vous à rester construc­tifs à plus de dix ?

  • Mycli is a command line inter­face for MySQL, MariaDB, and Percona

    Mycli is a command line inter­face for MySQL, MariaDB, and Percona with auto-comple­tion and syntax high­ligh­ting.

    — Mycli