Carnet de notes

Catégorie : Technique

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

  • GPG keysi­gning and govern­ment iden­ti­fi­ca­tion

    Ok, je n’uti­lise pas GPG. J’ai tenté par le passé mais trop peu de gens en face l’uti­lisent pour que ce soit perti­nent de mon côté (oui, je sais que l’ar­gu­ment est cyclique).

    Have you been a US barten­der before? Or held any other posi­tion where you’ve had to verify an ID? It’s not an easy thing to do. People in those posi­tions have books of valid IDs from different states. They have lights that show the secu­rity marks. They still get it wrong regu­larly. A very amateur fake ID, or borro­wed real ID, will fool just about everyone in any infor­mal context.

    Par contre j’ai toujours trouvé idiot la procé­dure qui demande à ce qu’on véri­fie physique­ment l’iden­tité du corres­pon­dant. Ce qui m’in­té­resse c’est que la personne à qui j’écris ou qui m’écrit est bien celle que j’at­tends. Pour ça la seule solu­tion c’est de faire un ou plusieurs aller-retours écrits.

    Non seule­ment je ne serai abso­lu­ment pas capable de détec­ter une fausse carte d’iden­tité, même une mal faite à 30€, mais en plus je n’ai que faire de son iden­tité civile. Ce n’est pas du tout ce que je cherche à certi­fier.

    Entre ceux qui véri­fient l’iden­tité civile à la légère en lieu et place de l’iden­tité numé­rique, et ceux qui ne véri­fient rien, le « web of trust » est assez illu­soire aujourd’­hui. Il nous faut des outils qui auto­ma­tisent et guident nos pas, sans quoi rien ne chan­gera.

  • John Oliver (HBO) – Neutra­lité du net

    Ok, le ton est humo­ris­tique, et pas des plus fins, c’est déli­rant, ridi­cule, mais au final il y a des éléments sérieux et c’est un des meilleurs argu­men­taires que j’ai vu sur la neutra­lité du net.

    Ça se regarde jusqu’au bout.

  • Free SSL Certi­fi­cates for Open Source Projects

    Je colle ça ici au cas où ça serve à quelqu’un, ou moi plus tard : GlobalSign donne des certi­fi­cats SSL gratuits pour les projets Open Source (license OSI).

    Visi­ble­ment ils offrent même des wild­cards. Bon, ça ne leur coûte rien, mais ça peut être pratique.

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

  • Faire table rase, et cacher le passé

    C’est malheu­reu­se­ment habi­tuel, mais je ne peux m’em­pê­cher de secouer la tête à chaque fois.

    Le gouver­ne­ment ou l’élu change, la première action publique juste après la confé­rence de presse est toujours suppri­mer très très vite le site web précé­dent pour mettre quelque chose de neuf, quasi­ment vide au départ.

    La première. C’est urgent.  Pas juste mettre une nouvelle version, chan­ger les noms, biogra­phies et attri­bu­tions, mais suppri­mer le contenu du précé­dent. Qu’on fasse semblant de ne pas savoir qu’il y avait un précé­dent. Qu’on retire toute réfé­rence à ce qu’il a fait.

    Vous voulez réfé­ren­cez un contenu publié par l’an­cien président, l’an­cien gouver­ne­ment ? oubliez, il a été supprimé. Dans le meilleur des cas il sera remis en ligne ailleurs, bien caché dans des archives et sans redi­rec­tion à partir de l’an­cienne adresse.

    Il est hors de ques­tion que le site puisse parler d’autre chose que LE nouveau président ou LE nouveau gouver­ne­ment et faire de l’ombre à leur personne. Vous devriez avoir honte d’y avoir pensé.

    Même si on n’a aucun contenu à y mettre et juste un PDF à lier en page d’ac­cueil, même quand il y a conti­nuité dans le gouver­ne­ment avec la même couleur poli­tique et nombre d’in­chan­gés, même les pages d’aides, même les pages sur les insti­tu­tions elles-mêmes, non, on supprime tout.

    On peut rigo­ler, expliquer, justi­fier, person­nel­le­ment je n’y vois qu’une person­ni­fi­ca­tion désas­treuse des élus. Ils n’en­dossent pas un rôle ou ne prennent pas une charge, ils deviennent le nouveau roi. Il est temps d’ar­rê­ter tout ça. Le SIG joue le jeu, et c’est bien dommage (désolé, je ne peux pas faire de lien vers la page web du SIG, elle a été suppri­mée avec tout le reste, elle était sur l’an­cien site du gouver­ne­ment…).

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

  • Talents publi­ci­taires – star­tup

    Quelle honte d’ac­cor­der 33% de son revenu à son espace de vie. À l’édu­ca­tion que l’on a reçu, aux soins dont on béné­fi­cie. Mais rassu­rez-vous, vous pouvez en être dispensé grâce au fabu­leux statut de JEI qui fait pâlir d’en­vie outre-atlan­tique

    […]

    Et cerise sur le gâteau, on peut virer ses sala­riés dans les 6 mois sans aucun risque. Sous réserve de rester en-dessous des 50 sala­riés (excluant les stagiaires bien entendu). Et puis un déve­lop­peur français est si peu cher, pourquoi s’en priver ?

    Voilà, Tariq, les talents français du code sont au mieux de la chair à canons publi­ci­taires US

    Voici la meilleure réponse à l’article du NewYork Times. Parce que oui, la France est attrac­tive pour des star­tup. Les 33% de coti­sa­tions sociales ne sont en réalité pas payées par les JEI, et la préten­due rigi­dité des contrats de travail ne l’est pas tant que ça. Factuel­le­ment la plupart des études mettent la France comme bien moins chère pour les star­tup tech­nos que les US ou Londres.

    D’autres ont fait des réponses sur les critères finan­ciers (pas de meilleure foi) mais on tape à côté. Pourquoi est-il si choquant de payer 30% du salaire en retraite, assu­rances et santé ? C’est encore plus crétin quand on compare avec des pays où ces frais sont décomp­tés du salaire net que reçois le sala­rié au lieu d’être pris plus haut au niveau de l’em­ployeur.

    Mais même en dehors de la compa­rai­son, nous devrions être heureux d’avoir un tel équi­libre. Comment est-on arri­vés à s’enor­gueuillir de ne pas payer de pres­ta­tions sociales, d’échap­per à l’im­pôt collec­tif, de payer moins cher nos déve­lop­peurs ou de pouvoir les virer faci­le­ment ? Est-ce vrai­ment de ça que le monde a besoin ? L’in­no­va­tion et les nouvelles tech­nos ne savent-elles se déve­lop­per que sur ce terreau ? Si vous répon­dez « oui » alors il faut vite arrê­ter ce désastre.

    D’au­tant que c’est juste crétin. Si Google ou Github attirent autant c’est par l’en­vi­ron­ne­ment qu’ils offrent (ou offraient). Sur le campus il y a tout ce qu’il faut, au restau­rant d’en­tre­prise on fait venir les meilleurs chefs, l’es­pace de travail est large, éclairé, atti­rant, en interne on glori­fie ceux qui agissent et renforce les déve­lop­peurs.

    Ici on se fait concur­rence au moins disant social, on abaisse les déve­lop­peurs à de l’exé­cu­tion tech­nique, on leur retire l’idée qu’ils peuvent être le moteur.

    Ce n’est pas d’un Github à la française dont nous avons besoin, mais d’une multi­tude de projets citoyens. Pour créer du lien social, du lien inter-géné­ra­tio­nel, du lien local, du lien poli­tique. Pour se sentir utile en tant que déve­lop­peur, pour se sentir agile en tant qu’hu­main.

    Notre objec­tif ne doit pas être de créer des socié­tés de 50 milliards et de copier le voisin en étant plus profi­table ou plus gros finan­ciè­re­ment. L’in­no­va­tion se nour­rit du lien, de l’uti­lité, d’une culture. La réduire à son sens écono­mique et aux copy-cat ne ne mènera nulle part.

    Il y a une culture à avoir, et ce n’est pas une culture busi­ness, c’est une culture de l’uti­lité, de colla­bo­ra­tion sociale. On ne la créera pas en jouant à celui qui propose le moins au niveau social pour un meilleur profit des inves­tis­seurs.

    À lire entiè­re­ment : Talents publi­ci­taires de David Larlet

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