Carnet de notes

Catégorie : Développement informatique

  • Comment déve­lop­pera-t-on demain ?

    Les déve­lop­peurs de mes équipes demandent depuis un moment des licences Github Copi­lot. J’ai vu quelques personnes parler de l’édi­teur Cursor.sh.

    J’avoue que j’ai eu envie de tester un peu. Sur un projet perso j’ai tenté l’ap­proche « allons-y tota­le­ment ». Je suis bluffé.

    Bon, j’ai encore le réflexe de cher­cher tout ce que je ne sais pas dans les docs. Ça veut dire que je demande prin­ci­pa­le­ment des choses que je saurais déjà faire, et poten­tiel­le­ment aussi rapi­de­ment seul qu’en saisis­sant ma demande dans l’in­ter­face. Je ne sais pas si je gagne vrai­ment du temps mais, même ainsi, l’in­ves­tis­se­ment de 2x 20$ par mois me semble une évidence.

    Avec le temps je risque de me repo­ser vrai­ment dessus et là ça fera certai­ne­ment une énorme diffé­rence. Pour un débu­tant qui apprend à coder direc­te­ment avec ces outils, ça doit être juste une révo­lu­tion.

    Le métier de déve­ve­lop­peur est en train de chan­ger radi­ca­le­ment. Je ne sais pas s’il sera le même dans 10 ans. Je ne sais même pas si ça a du sens d’en­sei­gner le code à mon fils de 11 ans.

    ⁂

    On est en train de tester ça au boulot, plus Code rabbit pour les revues de code. Si je trouve d’autres choses perti­nentes j’ai une propen­sion assez forte à ajou­ter aussi. Même sur un budget total de 100 ou 150 $ par mois et par déve­lop­peur, ce serait assez mal avisé de reje­ter la chose.

    Reste l’éner­gie néces­saire à tout ça, et là on touche vite la limite du modèle :

    « OpenAI’s CEO Sam Altman on Tues­day said an energy break­through is neces­sary for future arti­fi­cial intel­li­gence, which will consume vastly more power than people have expec­ted.

    Reuters, 16 janvier 2024

    Je n’ai pas de conclu­sion. L’as­pect produc­ti­vité ne fait aucun doute. La limite éner­gé­tique aussi. Malheu­reu­se­ment les deux ne vont pas du tout dans le même sens.

  • Move fast and break things

    Les discus­sions sont cycliques. Au détour d’un article sur la sonde Voya­ger j’en vois encore ironi­ser sur les équipes qui se refusent à déployer le vendredi après-midi.

    C’est un équi­libre des risques.

    Je ne veux pas les latences au déploie­ment que peut avoir la NASA. Je ne veux pas les coûts d’as­su­rance qualité de la NASA. Je suis prêt à casser des choses ponc­tuel­le­ment si c’est pour avan­cer vite.

    « Move fast and break things » ce n’est pas qu’un Moto. C’est un vrai choix stra­té­gique.

    Et si on assume le risque casser des choses, en fonc­tion du contexte et des besoins, ce n’est pas forcé­ment décon­nant de choi­sir quand gérer ce risque.

    La règle de la mise en produc­tion du vendredi, pour les équipes qui en ont une, n’est parfois que cela : un arbi­trage entre le risque de casse, le béné­fice à livrer main­te­nant, la dispo­ni­bi­lité des équipes dans les heures ou jours a venir, la faci­lité ou l’en­vie de rappe­ler les personnes concer­nées hors heures ouvrées si néces­saire, la dispo­ni­bi­lité d’équipes d’as­treinte, la possi­bi­lité de lais­ser un site dysfonc­tion­nel tout un week-end ou pas, etc.

    En géné­ral les équipes arbitrent ça très bien elles-mêmes. À chacun de voir si livrer un vendredi soir avant de partir est perti­nent pour son propre contexte. Les deux seules options fautives sont de ne pas y réflé­chir et d’igno­rer le risque.

    « Si ta CI est bien faite, tu n’es sensé rien casser »

    La plate­forme d’in­té­gra­tion conti­nue ne va tester que ce que l’équipe a pensé à lui faire tester. L’équipe ne pensera jamais à tout. D’ailleurs même la NASA fait des erreurs, et l’ar­ticle cité en haut de billet relate juste­ment une anoma­lie décou­verte au cours de la vie de la sonde.

    Avoir une bonne plate­forme d’in­té­gra­tion conti­nue dans laquelle on a confiance n’em­pêche pas de prendre en compte le risque dans ses choix.

    Même si je pouvais avoir une CI parfaite, pour ma part, je ne le voudrais d’ailleurs pas. Le jour où je n’au­rai plus aucun inci­dent ni anoma­lie, je consi­dé­re­rai qu’on a mal fait notre travail en surin­ves­tis­sant dans la qualité par rapport à nos besoins réels.

  • Petite anti­ci­pa­tion du 22 avril 2023

    Je parti­cipe à l’édi­tion de SudWeb à venir.

    Je ne sais pas ce que devien­dront ces rendez-vous physiques dans le nouveau monde où tant de personnes semblent préfé­rer le télé­tra­vail. SudWeb a fermé ses portes un moment. ParisWeb aurait très bien pu le faire et l’équa­tion semble diffi­cile.

    Je suis heureux de retrou­ver de nouveau, au moins cette fois, la bande d’amis et de connais­sances qui partagent quelques unes de mes valeurs. Ça reste des moments de repos même si, forcé­ment, le nombre de personnes fait que ça me demande une éner­gie monstre.

  • VSCode Live Share

    J’ai régu­liè­re­ment le senti­ment d’une avan­cée extra­or­di­naire des pratiques et des outils en 15 ans.

    Aujourd’­hui on peut faire du travail à deux avec flux audio, vidéo, et code à quatre mains sur les mêmes fichiers.

    Je peux suivre chacune des actions de mon collègue et suivre son déroulé en l’écou­tant. Quand il parle d’une dépen­dance à chan­ger je peux aller le faire en paral­lèle sans l’in­ter­rompre dans son avan­cée. Il voit ses tests passer au vert au fur et à mesure de mon travail annexe. Je peux à tout moment reve­nir vers ce qu’il fait si ce qu’il dit m’in­té­resse ou m’in­ter­roge, et il en est de même dans l’autre sens.

    On alterne suivi et travail paral­lèle, sur le même code, avec la possi­bi­lité de se complé­ter pour éviter la charge mentale de « j’ai ça qu’il faudra que je fasse » et les micro-inter­rup­tions pour gérer toutes ces micro-tâches annexes.

    Dites, est-ce moi qui suis dans la phase de sur-valo­ri­sa­tion ou est-ce qu’on ne devrait plus travailler que comme ça ? (à distance en visio ou côte à côte à l’oral, peu importe).

    J’ai l’im­pres­sion de cumu­ler à la fois les avan­tages du pair progra­ming et du travail en paral­lèle.

  • Donnée acces­sible dans l’es­pace public

    Une donnée acces­sible dans l’es­pace public n’est pas une donnée libre d’uti­li­sa­tion

    Il y a le droit d’au­teur, le droit des bases de données, les règles d’uti­li­sa­tion des données person­nelles, le cas spéci­fique des infor­ma­tions appar­te­nant à l’État, et proba­ble­ment bien d’autres choses.

    La licéité de l’in­for­ma­tion ou de certains usages de l’in­for­ma­tion n’en­traine pas celle d’un autre usage de cette même infor­ma­tion

    C’est parti­cu­liè­re­ment vrai pour tout ce qui est données person­nelles, où chaque trai­te­ment et chaque fina­lité est indé­pen­dante des autres.

    C’est vrai aussi de manière géné­rale : Que la donnée soit utili­sable dans certains cas n’im­plique pas que tout ce que vous en ferez sera forcé­ment légi­time, ni mora­le­ment ni léga­le­ment.

  • Promise Maps

    J’aime beau­coup Simon Willi­son depuis des années. Il tient un carnet de notes en guise de blog, comme j’au­rais long­temps voulu avoir le courage de faire.

    Il relaie là un commen­taire ycom­bi­na­tor :

    When caching the result of an expen­sive compu­ta­tion or a network call, don’t actually cache the result, but cache the promise that awaits the result.

    This way, if a new, unca­ched key gets reques­ted twice in rapid succes­sion, ie faster than the compu­ta­tion takes, you avoid compu­ting/fetching the same value twice. […] In other words, the promise acts as a mutex around the compu­ta­tion, and the resul­ting code is unders­tan­dable even by people unfa­mi­liar with mutexes, locks and so on.

  • Le plus compliqué en dev, c’est de faire des choses simple

    Hier j’ai corrigé un test tech­nique d’un candi­dat ayant 55 ans. Un des plus beaux tests que j’ai pu voir.

    – BORING code, clair, concis, effi­cace, très compré­hen­sible

    – pas d’over archi, pas de démons­tra­tion tech­nique, straight to the point

    – tous les use case testés, le bon algo sélec­tionné et implé­menté

    Et … rien de plus à dire ! Et c’est LE point ! Le plus compliqué en dev, c’est de faire des choses simples.

    Là, c’est un gros ✅

    Sur un groupe de CTO, 17 juin 2022

    Je ne saurais confir­mer trop fort ce message. Comprendre les motifs habi­tuels d’ar­chi­tec­ture c’est impor­tant mais c’est un outil dans la trousse, pas l’objec­tif.

  • Today I lear­ned : font-variant-nume­ric

    Conseil CSS : utili­sez `font-variant-nume­ric: tabu­lar-nums;` pour aligner soigneu­se­ment les nombres dans un tableau, des comp­teurs de progres­sion, etc.

    https://twit­ter.com/javan/status/1486059026064584711

  • Avec des lettres de A à Z

    Le truc que j’ai du faire avec quasi­ment tous les langages mais pour lequel j’ai rare­ment trouvé une solu­tion satis­fai­sante : trans­for­mer un texte en reti­rant tous les accents et conver­tis­sant les lettres pour ne garder que les a à z.

    Tant que je me limite au français, italien et espa­gnol, j’ai une suite de recher­cher-rempla­cer qui me suffit : 

    const ascii_replacements = [
  ['áàâä', 'a'],
  ['éèêë', 'e'],
  ['íìîï', 'i'],
  ['óòôö', 'o'],
  ['úùûü', 'u'],
  ['ñ', 'n'],
  ['æ', 'ae'],
  ['œ', 'oe'],
].map(([search, replace]) => [
  [new RegExp(search, 'gu'), replace],
  [new RegExp(search.toUpperCase(), 'gu'), replace.toUpperCase()],
]).flat()

function ascii(text) {
  return ascii_replacements.reduce(
   (text, [search, replace]) => text.replace(search, replace),
   text
  )
}

    Le gros problème c’est qu’il faut tout lister et que dès que je m’aven­ture hors du français, je risque d’en oublier.

    Via Le Hollan­dais Volant, une solu­tion qui utilise normalize :

    text.normalize("NFD").replace(/\p{Diacritic}/gu, "");

    C’est plus court, presque magique, mais en géné­ral j’ai aussi besoin de conver­tir æ et œ, qui seront oubliés ici. Il faut donc ajou­ter ces deux cas et leur version en majus­cule. Du coup c’est mieux mais pas encore ça.

    On peut se dire qu’en échange ça fonc­tionne pour toutes les langues, pas que le français, mais c’est passer à côté des spéci­fi­ci­tés locales. Si en français ö peut être dégradé en o, en alle­mand c’est l’équi­valent de oe.

    Reti­rer les signes diacri­tiques ne suffit pas pour obte­nir une version accep­table. La conver­sion dépend de la langue. L’al­le­mand est loin d’être la seule langue avec ce type de spéci­fi­ci­tés. Il faudra aussi ajou­ter les lettres propres à chaque langues, comme ß qui donne­rait ss.

    Par le passé j’ai utilisé iconv en PHP. Je me souviens que ce n’était pas parfait mais ça faisait ce type de job. 

     iconv('UTF-8', 'ASCII//TRANSLIT', $text)

    Il faut juste penser à bien défi­nir la bonne locale avant. Ce n’est pas un défaut, c’est une fonc­tion­na­lité : Le résul­tat sera diffé­rent pour diffé­rentes locales.

  • Vidéos de We Love Speed

    Les vidéos de We Love Speed 2021 sont sorties sur Youtube.

    J’ai la tris­tesse de ne pas avoir pu y assis­ter. Je suis preneur de vos recom­man­da­tions sur quelles présen­ta­tions regar­der.