Carnet de notes

Catégorie : Développement informatique

  • 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

  • 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

  • Auto­pre­fixer

    Je note ici autant pour ceux qui ne connaissent pas que pour mon moi de plus tard : Auto­pre­fixer, qui prend une CSS clas­sique et qui ajoute les versions préfixées utiles pour les diffé­rents navi­ga­teurs.

    Ça ne le fait pas bête­ment, genre pour flex­box ça sait gérer les diffé­rences de syntaxes. Bref : utile.

  • The empe­ror’s new clothes were built with Node.js

    Atten­tion ça va réagir :)

    I want to address one-by-one all of the strange and misgui­ded argu­ments for Node.js in one place.

    C’est chez Eric Jiang, et si c’est plein d’opi­nion, d’iro­nie et de cari­ca­ture, c’est quand même vrai sur le fond.

  • Code Reviews: Just Do It

    After parti­ci­pa­ting in code reviews for a while here at Vertigo, I believe that peer code reviews are the single biggest thing you can do to improve your code. If you’re not doing code reviews right now with another deve­lo­per, you’re missing a lot of bugs in your code and chea­ting your­self out of some key profes­sio­nal deve­lop­ment oppor­tu­ni­ties. As far as I’m concer­ned, my code isn’t done until I’ve gone over it with a fellow deve­lo­per.
    — Code Reviews: Just Do It

    Des Pull-Request systé­ma­tiques ont été instau­rées à TEA, et je m’en féli­cite sans aucune ombre de doute. Cette revue de code forcée améliore bien évidem­ment la qualité, mais elle permet de faire circu­ler l’in­for­ma­tion, de diffu­ser la connais­sance, de parta­ger les expé­riences, et d’aug­men­ter la valeur de tous.

    Certes, au niveau temps c’est proba­ble­ment comp­ta­ble­ment une erreur. Main­te­nant si on prend en compte l’aug­men­ta­tion de valeur que l’en­semble de l’équipe en retire, l’équa­tion est toute autre. Une fois qu’on impute ce temps aussi aux cases forma­tion, culture interne, diffu­sion des pratiques, redon­dance des connais­sances, le coût n’est fran­che­ment plus énorme.

    Merci à Anne Sophie et Olivier d’avoir parlé de nos pratiques au Mix-IT d’il y a deux semaines. C’est proba­ble­ment ces PR systé­ma­tiques qui ont généré le plus de surprises. Ce n’est visi­ble­ment pas encore fréquent ailleurs.

    Tentez pendant un mois et reve­nez en parler avec nous un soir autour de verre.

  • One Product Team

    One Product Team: We are not a sepa­rate group of desi­gners, gang of deve­lo­pers, bunch of testers, with a king product owner, who only meet each other when it is needed.

    We sit toge­ther as a team. We talk and play every­day. And we all love what we are buil­ding.

    — User expe­rience and design in BBC Play­lis­ter: how to be David Fincher

    La sépa­ra­tion stricte des rôles, avec un process, un enchaî­ne­ment, une hiérar­chie, des bureaux distincts… comment avons-nous pu construire de telles habi­tudes ?

  • The Expert (Short Comedy Sketch)

    J’hé­site toujours avant de parta­ger des vidéos, et encore plus quand il s’agit juste de renfor­cer les poncifs et stéréo­types. Celle là est cari­ca­tu­rale, mais elle repré­sente telle­ment ce que j’ai vu tout au long de ma carrière que je la mets ici, pour pouvoir la citer en réfé­rence, et vous permettre de faire de même.

  • Sur-Javas­cript

    J’avais regardé CoffeeS­cript il y a long­temps, mais sans être convaincu. Si j’ai besoin de faire du Javas­cript, je fais du Javas­cript. Coffee apporte bien des amélio­ra­tions sur la syntaxe, mais le langage n’est lui-même pas parfait et je doute que le rapport béné­fice/coût soit très élevé.

    J’en ai à peu près autant au service de Dart même si, sans réel­le­ment percer pourquoi, j’ai l’im­pres­sion qu’ils ont réussi à mieux se déta­cher de Javas­cript, et donc avoir un vrai langage distinct qui « compile » du Javas­cript (c’est bien l’es­prit de Coffee aussi, mais je n’ai pas eu ce ressenti).

    Je suis proba­ble­ment plus ouvert à TypeS­cript ou Traceur, qui sont plus proches du langage d’ori­gine et dont les objec­tifs et syntaxes sont presque « le prochain Javas­cript ». On a plutôt une couche de compa­ti­bi­lité arrière, et c’est un bon système.

    L’im­pres­sion que ça donne est tout de même qu’ils ont fait leurs propres exten­sions qui n’ap­par­tiennent qu’à eux.

    Est-ce qu’on a quelque part un projet simi­laire, qui implé­mente un maxi­mum de nouveau­tés des futurs EcmaS­cript mais qui évite d’ajou­ter trop de syntaxes diver­gentes au cœur du langage ?

    Quelles sont vos expé­riences avec l’un ou l’autre de ces systèmes ?