Carnet de notes

Catégorie : Technique

  • Pagi­na­tion sans limit ni offset

    TL;DR: La pagi­na­tion c’est bien™, le faire avec des para­mètres limit/offset c’est mal™.

    C’est très simple à expliquer : Si les données sont mises à jour entre deux requêtes d’une même pagi­na­tion, au mieux vous manquez des données et en visua­li­sez d’autres en double, au pire vous corrom­pez tous vos calculs.

    Hyper­me­dia

    La solu­tion magique c’est que vos API retournent un nombre limité de résul­tats avec des liens dans les entêtes, proba­ble­ment un rel=next pour les données suivantes et/ou un rel=prev pour les données précé­dentes. Le client n’a qu’à suivre les liens.

    En pratique

    OK, je triche parce que je n’ex­plique rien, alors je vais prendre un exemple : Un hypo­thé­tique client Twit­ter sur une hypo­thé­tique API Twit­ter (je m’au­to­rise donc à ne pas préci­ser ce qui se fait sur les API actuelles).

    Lorsque Twit­ter vous retourne les 100 derniers tweets de votre time­line avec les iden­ti­fiants 3245 à 3566, il peut vous renvoyer deux liens dans les entêtes :

    • Un rel=last qui mène en fait vers l’exacte requête que vous avez faite mais avec en plus un para­mètre since_id=3566. Quand vous voudrez rafrai­chir votre time­line, il vous suffira de suivre le lien. Il vous retour­nera les nouveaux messages jusqu’au 3566 non compris, mais jamais ceux que vous avez déjà reçu.
    • Un rel=prev qui mène vers l’exacte même requête que vous avez faite, mais avec en plus un para­mètre max_id=3245. Quand vous voudrez aller cher­cher les messages plus anciens, il vous suffira de suivre le lien.

    Si vous suivez un rel=prev après avoir suivi un rel=last vous fini­rez avec un lien qui contient et un since_id et un max_id, vous assu­rant de combler les trous que vous avez dans votre time­line, sans jamais renvoyer un message en double ni en oublier.

    Si vous souhai­tez faire une synchro­ni­sa­tion complète, il suffit de stocker tous les liens rel=prev que vous rece­vez dans une liste, et d’al­ler les suivre un à un à la fréquence que vous souhai­tez. Vous pouvez avoir un autre fil d’exé­cu­tion en paral­lèle qui suit le rel=last de temps en temps (il n’y en aura qu’un seul à la fois, vous en aurez un nouveau à chaque fois que vous suivez le précé­dent).

    Bon, dans la vraie vie vous aurez géné­ra­le­ment un rel=next (messages juste suivants) plutôt qu’un rel=last (derniers messages), mais Twit­ter est parti­cu­liers : Ça va si vite qu’en géné­ral la prio­rité est d’avoir les derniers messages à date, quitte à géné­rer des trous dans la time­line qui seront comblés plus tard.

    Twit­ter est aussi facile parce qu’on trie toujours pas date, et que l’iden­ti­fiant unique de chaque message est toujours ordonné lui aussi. Ailleurs on utili­sera peut être la date de dernière modi­fi­ca­tion comme pivot pour gérer la pagi­na­tion. L’im­por­tant est que le critère de tri soit cohé­rent avec la donnée utili­sée comme pivot

     

  • Front-end desi­gner ou inté­gra­teur web ?

    On m’a toujours séparé la notion de graphiste web en deux : D’un côté la créa­tion, l’illus­tra­tion. De l’autre le maquet­tage, l’agen­ce­ment, l’er­go­no­mie et les inter­faces.

    Côté déve­lop­peur web il y a les back-end pour le code métier et le code serveur, ainsi que les front-end pour le code inter­face.

    Inté­gra­teur

    Faire du pur HTML/CSS, c’est parfois pris par des déve­lop­peurs front-end, parfois par des graphistes d’in­ter­face. C’est typique­ment ce qu’est l’inté­gra­teur web. Le métier a pris une forte spécia­li­sa­tion depuis 10 ans. Il faut bosser dans un envi­ron­ne­ment très hété­ro­gène, avoir des notions d’er­go­no­mie, beau­coup de connais­sances sur les navi­ga­teurs, y compris tech­nique, faire face à des tech­no­lo­gies en pleine évolu­tion, consi­dé­rer les perfor­mances, etc.

    Je lis les tenta­tives de nommage de desi­gner front-end suite aux inter­ro­ga­tions de STPo. J’avoue avoir un peu de mal parce que ce que j’en lis ressemble quasi­ment parfai­te­ment à ce que j’au­rais nommé inté­gra­teur.

    Has-been ?

    Si je devais envoyer une pique, j’ai l’im­pres­sion qu’il y a un petit complexe face aux nouveaux front-end deve­lo­per, c’est à dire ceux qui font de l’ap­pli­ca­tif JS avec une compé­tence HTML/CSS/HTTP (et déjà, vous notez qu’on manque d’un terme vu que le déve­lop­peur PHP on l’ap­pe­lait déjà front-end deve­lo­per dans pas mal de boites, par oppo­si­tion à celui qui gère le code métier dans des serveurs dans inter­face client).

    Oui il y a une demande de ces nouveaux front-end deve­lo­per, et ça fait perdre un peu de contrats aux inté­gra­teurs qui ne couvrent pas cet aspect. Mais si vous accep­tez de délais­ser ce terme en le quali­fiant de has-been, c’est vous-même qui reti­rez de la valeur au métier. Il faudrait le renfor­cer, commu­niquer dessus, montrer la valeur… D’au­tant que trop de front-end deve­lo­per sont juste­ment du coup plus faibles en inté­gra­tion, à connaitre le support de tous les navi­ga­teurs, les bugs louches de CSS, la compa­ti­bi­lité qui ne se résume pas à la dernière version de Chrome, etc.

    N’ou­bliez pas que c’est comme ça qu’on a créé ce terme dans le web il y a moins de 10 ans. Avant il y avait les webmas­ter d’un côté, et les déve­lop­peurs de l’autre. Le terme d’in­té­gra­teur on l’a juste­ment à l’époque imposé comme l’ex­pert qui savait faire ce code HTML/CSS avec un peu de javas­cript si besoin, et soit une tendance graphiste soit une tendance avec un peu de PHP, souvent les deux.

    Tenter un nouveau terme juste pour rajeu­nir l’image, c’est pour moi une vision non seule­ment très court terme, mais aussi défen­sive en aban­don­nant la valeur au lieu de la renfor­cer à valo­ri­ser le métier.

    Desi­gner

    Reste la ques­tion de l’an­glais, où le terme d’in­té­gra­teur web ne semble pas exis­ter. Propo­ser un terme autre que front-end deve­lo­per peut avoir du sens, mais je ne suis pas convaincu qu’il faille cher­cher dans une spécia­li­sa­tion de desi­gner.

    Je sais que les gens qui parti­cipent à la discus­sion en lien sont quasi­ment tous graphistes *et* inté­gra­teurs. Pour autant, quitte à parler spécia­li­sa­tion des métiers et valo­ri­sa­tion de celui d’in­té­gra­teur, j’au­rais aimé un terme qui regroupe tous les inté­gra­teurs plutôt que de mettre ceux qui débordent côté graphisme dans la case maitresse desi­gner et ceux qui débordent côté program­ma­tion dans la case maitresse deve­lo­per.

    C’est oublier ceux qui sont au milieu et croire que fina­le­ment le métier inter­mé­diaire n’existe pas en soi. Bref, aller là aussi à l’en­contre de la valo­ri­sa­tion du métier spéci­fique d’in­té­gra­teur, en le relé­guant comme une cartouche secon­daire d’un graphiste ou d’un déve­lop­peur.

    S’il est sain de créer des termes pour des spécia­li­sa­tions, ne créons pas des termes pour décrire ceux qui sont à la fois sur deux ou trois spécia­li­sa­tions précises, sinon on ne s’en sortira jamais et on ne fera que divi­ser. Si vous couvrez plusieurs cases – ce qui est non seule­ment très bien mais carré­ment souhaité – dites simple­ment que vous êtes inté­gra­teur et graphiste d’in­ter­faces, ou inté­gra­teur et déve­lop­peur front, ou encore autre chose. Cumu­lez, ne divi­sez pas.

    front-end

    Indé­pen­dam­ment de tout ça, même si on veut clas­ser les inté­gra­teur dans les desi­gner (qui en anglais ne recoupe pas que la notion de graphisme au sens français, je le conçois), je ne comprends pas le quali­fi­ca­tif de front-end ici. Pour le déve­lop­pe­ment il y a du back et du front, mais sauf erreur de ma part le desi­gner s’oc­cupe toujours du front – et ce qu’il fasse de l’in­té­gra­tion tech­nique, de la concep­tion d’in­ter­face ou de l’illus­tra­tion/créa­tion.

    Inter­face desi­gner m’au­rait déjà moins choqué mais je crois que c’est déjà occupé par un poste moins tech­nique. Je n’ai pas mieux à propo­ser mais front-end desi­gner ne me semble rien vouloir dire.

    Je m’amuse de voir que pour une fois, nous avons foison de termes spécia­li­sés en français alors que les anglais n’ont qu’une poignée de termes très géné­riques.

    Et moi ?

    J’ai toujours eu du mal à me mettre dans une seule case, et j’es­père qu’il en va de même pour beau­coup de gens dans le web. Même quand je ne faisais que de la tech­nique, je n’ai jamais su si j’étais déve­lop­peur ou inté­gra­teur.

    J’étais les deux. Certai­ne­ment pas « simple­ment front-end deve­lo­per » dans le sens « inté­gra­teur qui déve­loppe », parce que j’ai toujours vu inté­gra­teur comme une casquette à part entière, qui demande une exper­tise gigan­tesque qui éclipse large­ment le côté « qui déve­loppe ».

    Bref, je ne me retrouve certai­ne­ment pas dans cette sépa­ra­tion des graphistes d’un côté et des déve­lop­peurs de l’autre, en éclip­sant les inté­gra­teurs au milieu. Très dommage.

  • Google Drops Support for Secu­rity Ques­tions

    Google Drops Support for Secu­rity Ques­tions

    …et fran­che­ment il était temps. Ces systèmes de ques­tions person­nelles sont tota­le­ment aber­rants. Bref, merci.

    Il s’agit géné­ra­le­ment de ques­tions dont on peut trou­ver la réponse avec un mini­mum de recherches sur le net. Les amis et les proches connaissent déjà toutes les réponses ou peuvent les obte­nir rela­ti­ve­ment faci­le­ment à force de discus­sion.

    À l’in­verse, mon profes­seur préféré ? La rue de là où j’ai habité petit ? J’au­rais plusieurs réponses possibles. J’hé­site à chaque fois. Il est même possible que certains de mes proches répondent plus rapi­de­ment que moi-même à ces ques­tions – tout en donnant la bonne réponse.

    Un ou plusieurs numé­ros de télé­phone, un ou plusieurs emails, une liste de codes de secours à usage unique… Google fait très bien tout ça. L’avan­tage de ces solu­tions c’est que même si quelqu’un usurpe le compte, le service client peut les réuti­li­ser pour authen­ti­fier le vrai proprié­taire des données.

    Tout au plus on pour­rait imagi­ner de deman­der au service de confir­mer cumu­la­ti­ve­ment par plusieurs moyens, du genre mon télé­phone de bureau, plus le numéro person­nel de mes parents, plus l’email de ma femme. Peu probable que quelqu’un réus­sisse à avoir accès aux trois simul­ta­né­ment sans que je n’en ai connais­sance. Si je perds vrai­ment tous mes accès, cette diffi­cul­tés sera surmon­table.

    Visi­ble­ment des gens se permettent de remettre en ques­tion les pratiques dont le coût est supé­rieur au béné­fice : Je vois des banques désor­mais sans ces claviers virtuels inutiles et je me rappelle Mozilla qui avait arrêté de deman­der le renou­vel­le­ment régu­lier des mots de passe.

    Bon, tout n’est pas gagné partout : Linke­din ne véri­fie pas les emails des nouveaux comptes, et ça ouvre de jolies failles chez tous ceux qui ont un « authen­ti­fie-moi avec Linke­din ».

    Photo d’en­tête sous licence CC BY par Zuerichs Stras­sen

  • Working with desi­gners

    Working with desi­gners

    J’ai lu récem­ment le Working with desi­gners, et ça me donne l’oc­ca­sion de publier une réflexion qui me trotte dans la tête depuis long­temps :

    Vous avez besoin d’un graphiste dans votre équipe.
    En interne, à demeure.

    Oui, on peut très bien faire un peu tout sans graphisme, et trou­ver un pres­ta­taire quand il s’agit quelques fois dans l’an­née de faire une charte, un design ou une illus­tra­tion. Vous manquez juste 80% de la valeur ajou­tée.

    En fait c’est plus large que ça. On peut tech­nique­ment avoir juste un CEO, qui achète des pres­ta­tions de déve­lop­pe­ment infor­ma­tique à une SSII, délègue le cahier des charges à un cabi­net d’as­sis­tance MOA, fait distri­buer la solu­tion par des vendeurs multi­cartes.

    Ça peut même fonc­tion­ner, dans de rares cas. Vous manquez juste la valeur qui est de réflé­chir au produit, de faire des évolu­tions perma­nentes et progres­sives, de lais­ser les gens s’ex­pri­mer, colla­bo­rer, avoir des initia­tives, appor­ter de la valeur, de l’ému­la­tion… On ne parle pas que de produc­tion sur le projet, mais de parti­ci­per et enri­chir la vie de l’en­tre­prise à tous les niveaux.

    * * *

    En régime de croi­sière, pour une boite techno web, vous aurez besoin d’un déve­lop­peur back, d’un déve­lop­peur front, d’un expert produit/métier, d’un graphiste, d’un commer­cial/marke­ting, d’une personne pour le support client, et d’une personne pour gérer l’ad­mi­nis­tra­tif.

    On peut bien entendu parler aussi d’un direc­teur des opéra­tions ou d’un sys admin, mais ils ne font pas autant parti du même coeur mini­mum pour moi.

    Chacune de ces sept personnes vous appor­tera quelque chose dans l’en­tre­prise,mettra de l’huile dans les rouages, même en dehors du projet lui-même.

    *

    Au départ il n’y a pas le choix, il faut porter plusieurs casquettes et faire quelques impasses. Par la suite vous avez tout inté­rêt à ce que les rôles soient poreux, que chacun soit incité à travaillé sur plus que sa petite case.

    Si par contre vous êtes une dizaine et que vous n’avez pas une personne diffé­rente qui joue le guide pour chacun des rôles, vous ne faites pas une écono­mie, vous vous ampu­tez d’une grosse valeur ajou­tée.

    *

    Votre boite n’est pas une boite techno web ? Dans ce cas vous pouvez peut être éviter d’avoir deux déve­lop­peurs distincts, mais il faudra au mini­mum les rempla­cer par un bidouilleur infor­ma­tique à tout faire (au sens noble, si vous croi­sez le terme anglais hacker, c’est de ça qu’on parle), qui devien­dra vite indis­pen­sable.

    Dans ce cadre, j’aime beau­coup la notion « hacker in resi­dence » et « desi­gner in resi­dence » de eFoun­ders. C’est la compré­hen­sion que même parta­gés entre plusieurs projets, pour faire émer­ger de la valeur il faut des gens impliqués à demeure, au milieu des équipes.

    Photo d’en­tête sous licence CC BY-SA par Axel Hart­mann

  • Date dans les API : Préci­ser l’heure et le déca­lage horaire

    Date dans les API : Préci­ser l’heure et le déca­lage horaire

    – Cette méthode donne la date et l’heure de publi­ca­tion
    – L’heure dans quel réfé­ren­tiel ? c’est l’heure UTC ?
    – Non, nous avons des conte­nus français, c’est l’heure française
    – OK, je suppose qu’on parle de la métro­pole et de l’heure de Paris donc. Comment gérez-vous les chan­ge­ments d’heure légale ? Si je prends comme réfé­rence 2h30 du matin le 26 octobre 2014, je risque d’opé­rer certains trai­te­ments deux fois, ou dans le désordre.
    – Pas de problème, nous livrons en réalité à des heures program­mées et il n’y a norma­le­ment pas de livrai­son entre 1h et 3h du matin, donc le cas n’ar­ri­vera pas.

    Je brode un peu mais la conver­sa­tion a déjà eu lieu, plus d’une fois dans ma vie profes­sion­nelle. Je passe sur ceux qui ne compre­naient pas qu’une date devait être soumise aux fuseaux horaires, parce que c’est en réalité toujours une heure (minuit précises) et que le 26 octobre n’est pas le 26 octobre partout en même temps.

    Règle simple :
    Toujours préci­ser l’heure et le fuseau horaire quand on donne une date dans un échange infor­ma­tique.

    On peut argu­men­ter que trans­mettre toutes les heures en UTC pour­rait suffire, et que le fuseau horaire est super­flu. En pratique ce serait oublier une autre règle essen­tielle : « tout ce qui peut être mal inter­prété le sera ». Un jour, quelqu’un pren­dra votre date et l’uti­li­sera comme une date locale et pas une date UTC. Promis, garanti. OK, ça ne sera pas de votre faute, mais si vous voulez que ça fonc­tionne et pas simple­ment renvoyer les respon­sa­bi­li­tés, il va falloir préci­ser.

    Seule solu­tion : Préci­ser le fuseau horaire ou le déca­lage horaire. J’irai même plus loin : Le préci­ser direc­te­ment dans la date elle-même, pour qu’il ne puisse pas être ignoré à la lecture et qu’il ne puisse pas être un simple para­mètre par défaut à l’en­voi qu’on reco­pie sans y penser. La conven­tion de base sur les échanges Inter­net c’est la section 5.6 de la RFC 3339.

    Exemples simples :
    2014–10–26T02:30:59+01:00 et 2014–10–26T01:30:59Z

    L’avan­tage de cette syntaxe est qu’il existe des solu­tions pour la lire dans tous les langages de program­ma­tion, et que toutes ou presque sauront gérer le déca­lage horaire correc­te­ment. Il faut être sacré­ment tordu pour tenter de l’ana­ly­ser soi-même et donc risquer d’igno­rer la partie liée au déca­lage horaire.

    Même à l’écri­ture, préci­ser expli­ci­te­ment le déca­lage horaire va gran­de­ment limi­ter les erreurs d’inat­ten­tion ou d’in­com­pré­hen­sion liées aux ques­tions de fuseaux horaires.

    De toutes façons il faut utili­ser UTC

    Rien ne vous impose pour autant d’ac­cep­ter des heures avec n’im­porte quel déca­lage horaire. L’idée est unique­ment d’avoir une syntaxe expli­cite sur le réfé­ren­tiel utilisé.

    Si vous souhai­tez impo­ser des heures UTC, faites-le. Tout ce que je vous demande c’est d’uti­li­ser une syntaxe expli­cite à ce niveau, et de reje­ter en entrée les dates qui ne seraient pas elles aussi expli­cite quant au déca­lage horaire.

    Photo d’en­tête sous licence CC BY-NC-SA par John Britt

  • Usure mentale de la non-qualité

    Usure mentale de la non-qualité

    Vous pouvez argu­men­ter à propos du retour sur inves­tis­se­ment de haus­ser un peu le niveau de qualité – je l’ai fait aussi – mais il faut avouer que sauf à connaitre le futur, ces chiffres auront la même fiabi­lité et la même préci­sion que l’ho­ro­scope de l’an­née dernière.

    Tout au plus peut-on tracer une ligne en dessous de laquelle le manque de qualité rend vrai­ment le travail diffi­cile, mais en réalité nous cher­chons tous à mettre la barre bien plus haut.

    Le coût de non-qualité est en fait bien plus basique. Il se cache dans la fatigue mentale, l’épui­se­ment, mais aussi la baisse d’en­vie, de moti­va­tion, de résis­tance à la frus­tra­tion ou de celle aux petits accrocs trop fréquents du quoti­diens…

    Le terme anglais est burn-out, et c’est bien plus une ques­tion de qualité et de bien-être que de temps de travail ou de pres­sion.

    C’est Nico­las qui le forma­lise le mieux :

    Ces petites erreurs aux grandes consé­quences font de plus en plus mal. Autant sur les personnes (le moral, l’es­time de soi, la frus­tra­tion) que sur le busi­ness (image, etc.). […] Je crois que ces galères de coûts de non-qualité et l’usure sur nos corps et nos esprits sont trop souvent sous-esti­mées.

    La ques­tion est : Où avez-vous envie de travailler ? Où vos colla­bo­ra­teurs ont-ils envie de travailler ? Combien de temps tien­dront-ils avant d’être usés et rési­gnés, sans moti­va­tion ni initia­tive ? Qui voulez-vous atti­rer ?

    Cet aspect est trop souvent oublié dans la logique produc­ti­viste du retour sur inves­tis­se­ment, pour­tant ce sont les ques­tions essen­tielles : À côté de l’im­por­tance du dyna­misme de l’équipe, tout gain de produc­ti­vité lié à une baisse des exigences revient à travailler à la bougie pour écono­mi­ser l’élec­tri­cité.

    Photo d’en­tête sous licence CC BY par Intan­gi­bleArts

  • Archi­ver le web

    Archi­ver le web

    J’adore le prin­cipe de la wayback machine de l’ini­tia­tive Inter­net Archive. Ils indexent le web et gardent une archive des versions rencon­trées. On peut revoir les conte­nus qui ont disparu du web, ou consul­ter des anciennes versions de conte­nus qui ont changé entre temps.

    Et si on réuti­li­sait l’ini­tia­tive à titre person­nel ? Pouvoir retrou­ver les conte­nus déjà visi­tés, même s’ils ont été reti­rés ou ont été amen­dés. Avec un peu de bidouille on pour­rait même recher­cher à travers nos archives.

    C’est ce que propose l’IIPC avec le projet open­way­back. Pour ceux qui ne veulent pas utili­ser pywb.

    Je pense de plus en plus à me consti­tuer mon archive : Au moins avec les pages que je mets en favori, celles que je lie à partir de mon blog, les liens que j’en­re­gistre dans Pocket, que je lis dans mon flux Twit­ter ou que j’y pose moi-même. Peut-être même que ça vaudrait le coup d’en­re­gis­trer tout ce qui passe dans mon histo­rique de navi­ga­tion.

    Pour l’ins­tant je n’ai jamais sauté le pas, mais est-ce si complexe ? pas certain. Il suffi­rait d’un peu de temps, d’un peu de code et de stockage en assez grande quan­tité. Rien d’in­fai­sable.

    Entre temps, d’autres se mettent en tête d’ar­chi­ver le web, tout le web. Rien que ça. L’In­ter­net Archive n’est qu’une compo­sante parmi d’autres reliées grâce à Memento. L’Archive Team fait un travail paral­lèle : Eux réus­sisent à archi­ver les conte­nus de quelques services en vue avant qu’ils ferment, les conte­nus des redi­rec­teurs d’URL, et même les conte­nus FTP.

    Le web gros­sit à une vitesse formi­dable mais les possi­bi­li­tés de stockage restent suffi­sam­ment impor­tantes pour qu’ar­chi­ver le web soit du domaine du possible.

    Photo d’en­tête sous licence CC BY-NC-ND par Pietro­mas­simo Pasqui

  • We’ve streng­the­ned our passs­word complexity requi­re­ments

    1. We’ve streng­the­ned our passs­word complexity requi­re­ments. We’ve noti­ced that the recur­ring pass­word expi­ra­tion often results in the use a poor or weak pass­words. The new pass­word requi­re­ments are:

    • Mini­mum length for 16 charac­ters
    • Mini­mum of 4 words when using a pass­phrase (a sequence of unre­la­ted words)
    • Maxi­mum length of 100 charac­ters
    • No pass­words that reuse the same words too many times, contain a birth­date suffix/prefix, etc.

    We stron­gly encou­rage the use of pass­phrases, instead of a tradi­tio­nal pass­word with multiple charac­ter classes. Example pass­phrases are displayed on the pass­word reset site.

    2. We’re remo­ving pass­word expi­ra­tion enti­rely. After chan­ging your LDAP pass­word one last time, it will no longer expire. The only reason you will need to change your change your LDAP pass­word in the future is if it has been acci­den­tally leaked, or if one of your compu­ters/mobile device were lost, stolen, or compro­mi­sed.

    Je ne saurais trop remer­cier Mozilla d’avoir sauté ce pas, quand bien même je ne suis pas concerné. Les poli­tiques de mots de passe n’ont géné­ra­le­ment ni queue ni tête, et l’obli­ga­tion de chan­ger régu­liè­re­ment de mot de passe est proba­ble­ment la superbe mauvaise idée du siècle en termes de sécu­rité.

    Je râle encore contre tous ces sites qui ont une procé­dure de réini­tia­li­sa­tion mais qui t’em­pêchent de saisir de nouveau un mot de passe que tu avais oublié préa­la­ble­ment.

    Juste un point pour Mozilla : Pour les appa­reils perdus ou volés, la solu­tion est plus la possi­bi­lité d’avoir des mots de passe unique dédiés. Le mot de passe géné­rique n’est utile que là où il est tapé régu­liè­re­ment.

    Partout où le mot de passe est à demeure (par exemple la confi­gu­ra­tion du client email), le système devrait permettre d’uti­li­ser un mot de passe unique, dédié. Si l’ap­pa­reil est compro­mis on ne change pas le mot de passe géné­rique, on se contente de « griller » le mot de passe dédié dans la liste des auto­ri­sa­tions.

    Google le fait très bien pour ceux qui ont activé l’au­then­ti­fi­ca­tion en deux étapes.

  • Tomber en marche

    Celle ci je ne peux me rete­nir de la copier car elle est magni­fique :

    $override = null;
if ($notify_admin and $conf['browser_language'])
{
  if (!get_browser_language($override['language']))
  {
    $override=null;
  }
}

    À première vue, le code ne fait rien. À la seconde lecture non plus, je vous rassure.

    Après expli­ca­tion, la méthode get_browser_language utilise un passage par réfé­rence (oui, avec ce nom là…), c’est à dire que la variable qui est passée en argu­ment pourra voir sa valeur modi­fiée.

    Eureka! En sortie de code on pour­rait bien avoir une variable $override qui contient quelque chose. On a au passage fait une créa­tion de tableau impli­cite en utili­sant la syntaxe avec crochets sur une valeur nulle (conseil : ne jamais faire ça si vous souhai­tez rester lisible).

    La seconde affec­ta­tion $override=null sert si jamais get_browser_language a bien modi­fié $override['language'] mais a renvoyé une valeur évaluée à false.

    Mais pourquoi cette seconde affec­ta­tion à null ? Et bien il se trouve que la fonc­tion get_browser_language renvoie false si elle ne modi­fie pas la variable passée par réfé­rence. Dans ce cas le code d’ap­pel aurait quand même créé un tableau dans $override à cause de override['language'], il faut donc reve­nir en arrière et écra­ser ce tableau créé impli­ci­te­ment.

    À rete­nir :

    1. Ne jamais créer de tableau implic­te­ment avec l’opé­ra­teur crochet sur une valeur null.
    2. Ne jamais attendre un retour par réfé­rence sur une fonc­tion qui s’ap­pelle « get_* »
    3. Globa­le­ment, ne quasi­ment jamais utili­ser le passage par réfé­rence pour récu­pé­rer une simple valeur.

    Ici en plus vu qu’on utilise déjà l’éva­lua­tion à true ou false du retour de get_browser_language, autant lui faire retour­ner direc­te­ment la langue, ou null si aucune n’est trou­vée.

  • Dead­line

    Dead­line

    La plupart du temps la dead­line est une manif d’une fausse urgence créée par une absence de déci­sion
    — Raphaël

    Je ne saurais mieux dire. Esti­mer puis mesu­rer le niveau d’ef­fort est impor­tant pour pilo­ter la déci­sion. Parfois la date de livrai­son est un élément néces­saire, mais le plus souvent il ne s’agit que d’un élément arti­fi­ciel qui se veut moti­vant et qui ne vient que d’une inca­pa­cité à pilo­ter l’ef­fort en continu, à s’adap­ter aux situa­tions qui se présentent.

    Qu’im­porte quelle était l’es­ti­ma­tion précé­dente, la date qu’on a pu maladroi­te­ment en déduire. L’im­por­tant est quelle est la déci­sion la plus perti­nente à prendre aujourd’­hui, en fonc­tion de la valeur produite, et du niveau d’ef­fort encore à four­nir pour ce qu’on envi­sage.

    Le reste est simple­ment hors sujet, y compris savoir si on est « en avance »,  « en retard » ou même « parfai­te­ment dans le plan­ning » par rapport à la date prévue en direc­tion. Le pilo­tage par la date est juste une inca­pa­cité à prendre ce recul et à s’adap­ter au présent plutôt qu’aux plans passés. Tout envi­sa­ger en un bloc et sous forme de retard ou d’avance est juste telle­ment plus rassu­rant, plus simple… Ça n’ap­porte malheu­reu­se­ment aucune valeur.

    Photo d’en­tête sous licence CC BY-NC-SA par João Almeida