Le jour 1 ce sont les structures de contrôle et les types. Rien d’extraordinaire mais je me tiens à ma résolution d’aller lentement sans griller des étapes.
J’avais déjà tenté de me mettre à Rust il y a quelques années mais je me suis retrouvé un peu noyé. Je crois que j’ai voulu aller trop vite, tout lire sans manipuler jusqu’à me retrouver bloqué par manque de réflexes. Là je vais prendre l’option opposée.
J’ai beaucoup aimé le retour implicite de Ruby. La dernière instruction de chaque bloc est sa valeur de retour. Rust a choisi un mécanisme un peu plus explicite, probablement pour simplifier la gestion des types de retour : Il s’agit d’une valeur de retour si la dernière instruction n’est pas suivie d’un point virgule.
Je trouve ce choix trop discret, et cassant l’automatisme du point virgule systématique. J’ai bien conscience que le compilateur va m’éviter l’essentiel des erreurs mais quitte à ne pas avoir un retour implicite systématique j’aurais probablement préféré avoir un retour plus explicite avec un symbole ou un mot clef en début de ligne, quitte à faire un return complet.
Et, justement, les points virgules en fin de ligne me sortent par les yeux. C’est quelque chose dont j’ai réussi à me débarrasser en JS et en Ruby, que je ne retrouve pas en Python non plus. Je suis dans l’incompréhension qu’un langage conçu relativement récemment ait fait le choix de les rendre obligatoires.
Tout le monde m’avait loué le compilateur. Je n’ai pas fait d’erreur assez forte pour vraiment juger des messages mais j’ai l’impression de revenir plusieurs années en arrière tellement c’est lent. C’est pour moi un vrai point noir dans l’utilisation alors que je n’en suis qu’à des équivalents « hello world ». Comment les développeurs Rust font-ils pour accepter des attentes de ce type à chaque compilation ?
Pas que du négatif. En fait à part ces trois points de détails, je retrouve mes petits assez facilement et ça semble assez fluide sur les mécanismes de base.
Je cherche un bon moyen d’évaluer la compétence technique d’un développeur. Aujourd’hui j’ai un test qui semble bien fonctionner pour notre usage mais que je trouve clairement trop long avec 4 heures.
J’ai toujours été réticent aux exercices tableau blanc de type parcours d’arbre, calculs sur tableau et autres jeux d’algorithme. J’ai quand même voulu tester un peu les classiques leetcode que certains utilisent comme lors des tests d’entrée.
Quelques conclusions après une vingtaine d’exercices de difficultés variables d’un parcours qui m’est présenté comme représentatif :
Ces exercices dépendant plus du bachotage préalable que de l’expérience ou de la compétence.
Pour une bonne partie, le faire bien demande d’avoir vu le truc une fois, ou de connaître le bon algo. Ce ne sont pas des choses qui se trouvent simplement en réfléchissant, a fortiori pas pendant un test technique en temps limité avec une dose de stress.
J’en ai un ou deux dont je ne connaissais pas l’algorithme et je n’ai pas été capable de trouver une bonne solution en termes de récursivité, complexité de calcul ou espace mémoire. Ça ne s’invente pas.
À l’opposé, sur la plupart je connaissais le truc et le temps passé était sur la syntaxe ou des erreurs d’inattention. Zéro intérêt. Même là où l’expérience a pu jouer, sur les parcours avec des pointeurs, je classe ça dans les connaissances qui ne m’ont presque jamais servi et pas dans les acquis de l’expérience.
Je suis convaincu qu’un débutant sorti d’école avec un peu de bagage théorique et pas mal de bachotage s’en sortira bien mieux, y compris à expliquer sa solution, qu’un développeur senior avec un super impact en entreprise.
Je ne vois pas comment ça va aider à justifier de ma valeur ou à évaluer celle des autres
Je ne dis pas qu’on n’a jamais à jouer avec les pointeurs, les tris, les parcours et ce genre de choses, mais ce n’est clairement pas représentatif des problématiques qui seront rencontrées.
Le cas échéant, ce sont justement des problèmes pour lesquels on va utiliser des bibliothèques existantes ou pour lesquels on trouvera très bien la réponses sur un moteur de recherche.
Il est évident que l’exercice va permettre de faire un tri dans les candidats mais je n’ai pas l’impression que ce soit sur le bon critère.
Bien évidemment ça doit dépendre des métiers. Un ingénieur sur le cœur d’une base de données doit certainement être assez près de ces problématique, mais ça ne me semble pas être le cas de 90% des ingénieurs.
Peut-être que je n’ai pas vu les bons tests, mais je reste assez dubitatif.
Pour ceux qui utilisent ces tests ou des similaires, y compris ceux à l’aspect un peu plus ludique, qu’y cherchez-vous exactement ?
Les développeurs de mes équipes demandent depuis un moment des licences Github Copilot. J’ai vu quelques personnes parler de l’éditeur Cursor.sh.
J’avoue que j’ai eu envie de tester un peu. Sur un projet perso j’ai tenté l’approche « allons-y totalement ». Je suis bluffé.
Bon, j’ai encore le réflexe de chercher tout ce que je ne sais pas dans les docs. Ça veut dire que je demande principalement des choses que je saurais déjà faire, et potentiellement aussi rapidement seul qu’en saisissant ma demande dans l’interface. Je ne sais pas si je gagne vraiment du temps mais, même ainsi, l’investissement de 2x 20$ par mois me semble une évidence.
Avec le temps je risque de me reposer vraiment dessus et là ça fera certainement une énorme différence. Pour un débutant qui apprend à coder directement avec ces outils, ça doit être juste une révolution.
Le métier de déveveloppeur est en train de changer radicalement. 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’enseigner 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 pertinentes j’ai une propension assez forte à ajouter aussi. Même sur un budget total de 100 ou 150 $ par mois et par développeur, ce serait assez mal avisé de rejeter la chose.
Reste l’énergie nécessaire à tout ça, et là on touche vite la limite du modèle :
« OpenAI’s CEO Sam Altman on Tuesday said an energy breakthrough is necessary for future artificial intelligence, which will consume vastly more power than people have expected.
Je n’ai pas de conclusion. L’aspect productivité ne fait aucun doute. La limite énergétique aussi. Malheureusement les deux ne vont pas du tout dans le même sens.
Je ne veux pas les latences au déploiement que peut avoir la NASA. Je ne veux pas les coûts d’assurance qualité de la NASA. Je suis prêt à casser des choses ponctuellement si c’est pour avancer vite.
« Move fast and break things » ce n’est pas qu’un Moto. C’est un vrai choix stratégique.
Et si on assume le risque casser des choses, en fonction du contexte et des besoins, ce n’est pas forcément déconnant de choisir quand gérer ce risque.
La règle de la mise en production du vendredi, pour les équipes qui en ont une, n’est parfois que cela : un arbitrage entre le risque de casse, le bénéfice à livrer maintenant, la disponibilité des équipes dans les heures ou jours a venir, la facilité ou l’envie de rappeler les personnes concernées hors heures ouvrées si nécessaire, la disponibilité d’équipes d’astreinte, la possibilité de laisser un site dysfonctionnel 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 pertinent pour son propre contexte. Les deux seules options fautives sont de ne pas y réfléchir et d’ignorer le risque.
« Si ta CI est bien faite, tu n’es sensé rien casser »
La plateforme d’intégration continue 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’article cité en haut de billet relate justement une anomalie découverte au cours de la vie de la sonde.
Avoir une bonne plateforme d’intégration continue dans laquelle on a confiance n’empê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’aurai plus aucun incident ni anomalie, je considérerai qu’on a mal fait notre travail en surinvestissant dans la qualité par rapport à nos besoins réels.
Je ne sais pas ce que deviendront ces rendez-vous physiques dans le nouveau monde où tant de personnes semblent préférer le télétravail. SudWeb a fermé ses portes un moment. ParisWeb aurait très bien pu le faire et l’équation semble difficile.
Je suis heureux de retrouver de nouveau, au moins cette fois, la bande d’amis et de connaissances 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 énergie monstre.
Voilà qu’on reparle de modération de Mastodon. L’histoire de départ c’est une instance (« Infosec ») qui a choisi d’en mettre une autre (« Journa ») sous silence pour ne pas subit les propos que cette dernière a choisi de laisser en ligne.
Hein ? Une instance ?
Mastodon fonctionne à travers un réseau fédéré. Son petit nom est le fédiverse. Les utilisateurs sont regroupés en ilots plus ou moins gros qu’on appelle les instances. Certains utilisateurs ont leur propre instance personnel. D’autres instances regroupent plusieurs dizaines de milliers de personnes.
Si un Tom d’Infosec est abonné à Alice de Journa, alors les deux instances communiquent entre elles pour que Journa envoie les messages d’Alice à Infosec. Infosec fera ensuite en sorte de les présenter à Tom.
Différentes instances
Vous connaissez déjà ça avec les emails, qui fonctionnent sur le même principe. On a un îlot Gmail, un Outlook, un Yahoo, un Orange, un Free… et chaque entreprise créé le sien avec son propre nom.
Ok, mais c’est quoi le blocage d’une instance ?
Si Infosec choisit de bloquer entièrement Journa, alors elle ne traitera plus les nouveaux messages de cette dernière et n’y enverra plus les siens. On parle de défédérer une instance.
Cette procédure n’influera que sur l’instance qui réalise qui le blocage (Infosec) et les utilisateurs de cette dernière. L’instance ciblée (Journa) continuera à converser avec toutes les milliers d’autres instances du réseau.
Blocage d’une instance par une autre.
En réalité il y a un niveau intermédiaire qu’on appelle la mise sous silence.
Mastodon a trois flux : le flux personnel qui présente uniquement les abonnements, le flux local qui présente uniquement les messages locaux à l’instance, et le flux fédéré qui présente tous les messages reçus par l’instance.
La mise sous silence masque les contenus concernés dans le flux fédéré mais permet de recevoir des messages dans le flux personnel à condition de s’y être explicitement abonné.
C’est ce niveau de blocage intermédiaire (la mise sous silence) qui a été mis en œuvre par Infosec.
Mais pourquoi faire ça ?
La vraie réponse : Peu importe. Si tu choisis de ne pas écouter CNews chez toi, tu n’as pas à donner d’explication. C’est ton choix.
C’est la même chose pour l’instance Infosec et ses utilisateurs : Ils font ce qu’ils veulent chez eux.
Le plus souvent on bloque une instance quand elle est la source de spam, de harcèlements, ou de propos racistes, transphobes, handiphobes, pédopornographiques ou injurieux.
Chaque instance a ses propres sensibilités. Certaines tiennent à une liberté d’expression très large, d’autres préfèrent exclure la pornographie ou certains sujets pour créer un espace qui leur convient.
Certains préfèrent une modération légère quitte à subir parfois quelques contenus problématiques là où d’autres préfèrent une modération forte quitte à limiter certaines interactions externes légitimes.
C’est un choix local, qui ne concerne qu’eux.
Ici Infosec a jugé que certains propos venant de Journa étaient transphobes et les utilisateurs d’Infosec souhaitaient s’en protéger (c’est à dire ne plus les voir ni en assurer la transmission chez eux).
On bloque toute une instance et tous les utilisateurs pour un unique message problématique ?
Mastodon prévoit un moyen de signaler les propos gênants à l’instance d’origine. Le plus souvent les blocages d’instance interviennent quand l’instance d’origine (ici Journa) refuse d’agir, ou que le problème survient trop régulièrement.
Pour faire un parallèle, si je sais que CNews invite régulièrement des invités que je ne supporte pas, je peux préférer ne plus du tout regarder CNews pour m’en protéger, quitte à ne plus entendre certains autres invités qui seraient eux acceptables à mes yeux. Je n’interdis pas CNews, je choisis juste de ne pas diffuser cette chaîne dans mon salon.
J’avoue que sur ce sujet, si j’avais eu à modérer, avec une seule occurrence qui n’est qu’un partage d’un contenu d’un journal de référence, j’aurais mis sous silence uniquement l’utilisateur concerné et pas l’instance, mais ce n’est que mon choix lié à mes équilibres personnels.
Infosec a fait un autre choix, et il ne regarde qu’eux.
Pourquoi est-ce que Journa a refusé d’agir sur des propos transphobes ?
Les équilibres de liberté d’expression sont très subjectifs. Tous les pays n’ont déjà pas le même socle de base en interne. Les communautés peuvent en plus choisir d’aller au-delà de ce socle de base. Certaines le font, d’autres pas, et pas toujours sur les mêmes sujets.
Enfin, parfois il y a simplement désaccord sur ce qui est ou pas injurieux, ce qui est ou pas transphobe, ce qui est ou pas raciste, ce qui est ou pas un constitutif d’un harcèlement, etc.
Les communautés se regroupent autour de politiques, valeurs et cultures communes, mais n’ont pas forcément les mêmes que le voisin.
C’est ce qu’il se passe ici. Soit Journa a considéré que l’article du New York Times relayé était suffisamment étayé avec des avis de docteurs et chercheurs à propos des effets indésirables de certains traitements, soit Journa n’a pas agit en pensant que ce n’est pas son rôle de trancher une telle question et remettre en cause le New York Times.
D’autres personnes sur Infosec ont, elles, considéré que le contenu était transphobe et qu’il valait mieux bloquer l’instance si elle n’agissait pas pour empêcher la diffusion de contenus transphobes à l’avenir. Infosec a agit en fonction de ses propres utilisateurs, et ça ne regarde qu’eux (oui, je me répète mais c’est important).
Ça pose quand même un sacré problème de liberté d’expression, non ?
En fait, pas vraiment, pas beaucoup plus que tous les gens qui comme moi font le choix de ne jamais allumer la TV sur CNews.
Personne n’empêche les membres de Journa de s’exprimer, ou d’être entendu, ou même d’être relayé sur la très grande majorité des instances Mastodon.
Dans le schéma de tout à l’heure, le blocage est à la périphérie de l’instance Infosec et pas à la périphérie de l’instance Journa. Tant qu’Infosec n’est qu’un des très nombreux acteurs du réseau, ça ne pose pas de problème majeur.
Blocage d’une instance par une autre.
Les seuls pour qui il y aurait potentiellement un enjeu de liberté d’expression, ce sont les membres de l’instance d’Infosec.
Ahah ! Tu vois, tu le dis toi-même, il y a bien un problème pour eux !
Ça dépend. Si je participe à une association, qu’il y a une TV dans la salle de pause et qu’il a été décide que cette TV diffuserait Arte plutôt que CNews, est-ce une atteinte à la liberté d’expression parce que je ne peux pas y écouter les chroniqueurs de CNews ?
Probablement pas : Je peux encore écouter CNews chez moi, ou dans une autre association, ou même monter ma propre association qui aura des règles différentes. Cela ne commencera à être un problème que si ma capacité à aller voir ailleurs est limitée ou complexe, ou si on donne à l’association d’origine une autorité quelconque.
C’est exactement la même chose avec Infosec. Ses membres peuvent toujours aller lire Journa ailleurs avec un second compte, ou déménager leur compte principal sur une autre instance, ou même monter leur propre instance. Ajouter un second compte ou migrer ailleurs est facile, sans limite.
Non seulement personne ne bride l’expression des membres de Journa mais en plus personne ne limite la capacité à aller les lire facilement.
Pourtant tu disais toi-même que…
La question surgirait différemment si Infosec avait une situation de quasi-monopole, ou que toutes les instances bloquant Journa avaient en se regroupant une situation de quasi-monopole limitant de fait la capacité à accéder au contenu dont on parle.
Ce n’est pas le cas aujourd’hui.
Ce serait aussi un sujet pour un blocage litigieux réalisé de façon cachée. Ici l’administrateur d’Infosec a publié un billet sur le sujet et le fait même que j’en parle ici montre qu’on est loin de ce cas.
Ça pose au moins une question de démocratie interne d’Infosec
Pas à mon avis. Tout fonctionnement interne n’a pas forcément à être démocratique. C’est important pour un pays ou une collectivité territoriale parce qu’on ne choisit pas son pays d’origine et qu’on ne change pas facilement de pays ou de territoire.
La démocratie c’est « le pouvoir au peuple ». Sur Mastodon l’utilisateur a le pouvoir vu qu’il peut choisir à tout moment une instance avec des règles qui lui conviennent, sans avoir de conséquences négatives significatives.
C’est d’autant moins un sujet que le message de l’administrateur d’Infosec laisse entendre que ce sont des utilisateurs de l’instance qui l’ont fait agir et pas lui qui a pris la décision unilatéralement.
Mais alors il n’y a aucun problème ?
Il y a plein de problèmes, mais pas forcément des questions de liberté d’expression ou de démocratie, et pas forcément sur le cas Infosec – Journa.
Un premier problème est la transparence. Infosec a agi en transparence mais ce n’a pas toujours été lé cas de toutes les instances par le passé. Quand c’est transparent on fait nos choix, éventuellement on va voir ailleurs. Quand c’est caché ça veut dire manipuler l’information reçue et influencer des personnes sans qu’ils ne le sachent, et ça c’est déjà beaucoup plus litigieux.
La contrainte est un second problème. Ce ne semble pas le cas ici mais par le passé la menace de défédérer a été utilisée comme une pression pour forcer une autre communauté à changer ses propres règles et valeurs (« si tu ne bloques pas l’instance xxx alors on bloque ton instance aussi »). On est là dans une démarche où l’outil a été détourné pour devenir une arme plutôt qu’un bouclier.
Enfin, il y a un sujet si une instance ou un groupe d’instances peut avoir suffisamment de poids pour que ça devienne effectivement un sujet de liberté d’expression. C’est particulièrement le cas si on cumule avec le problème précédent. Là ça peut être aussi moche qu’un réseau centralisé, ou créer plusieurs sous-réseaux indépendants et qui ne communiquent pas entre eux.
Du coup le système de Mastodon est problématique ?
Oui, non, ça dépend de tes propres choix.
C’est juste qu’il n’y a pas de système parfait ni de façon universelle de positionner les équilibres entre les différents enjeux.
Le choix de Mastodon est un choix qui répond à des problèmes vus sur Twitter ou d’autres réseaux centralisés, qui ouvre d’autres possibilités et d’autres façons de penser les équilibres. C’est déjà pas mal.
Que peut-on améliorer ?
Inciter à plus de transparence à l’intérieur d’une instance, sur ce qui est bloqué globalement et pourquoi.
Refuser globalement les guerres de modération entre instances et les instances qui veulent contraindre les règles des autres (le « si tu ne bloques pas l’instance xxx alors on bloque ton instance aussi »)
S’assurer qu’aucune instance ne représente plus de 20% des utilisateurs actifs, et qu’un groupe d’instances ne devienne majoritaire au point de pouvoir devenir un problème.
Faire en sorte que jamais la procédure de déménagement de compte ne soit limitée, même en cas de blocage d’instance.
J’ai régulièrement le sentiment d’une avancée extraordinaire 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’écoutant. Quand il parle d’une dépendance à changer je peux aller le faire en parallèle sans l’interrompre dans son avancée. Il voit ses tests passer au vert au fur et à mesure de mon travail annexe. Je peux à tout moment revenir vers ce qu’il fait si ce qu’il dit m’intéresse ou m’interroge, et il en est de même dans l’autre sens.
On alterne suivi et travail parallèle, sur le même code, avec la possibilité de se compléter pour éviter la charge mentale de « j’ai ça qu’il faudra que je fasse » et les micro-interruptions pour gérer toutes ces micro-tâches annexes.
Dites, est-ce moi qui suis dans la phase de sur-valorisation 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’impression de cumuler à la fois les avantages du pair programing et du travail en parallèle.
We found that people are not more hostile online than offline; that hostile individuals do not preferentially select into online (vs. offline) political discussions
New research suggests that the internet is not responsible for making people become more aggressive when engaging in political discussions online, but rather makes the behaviour of more aggressive people more visible.
Qui sont des vulgarisations de l’étude suivante :
we test the mismatch hypothesis but only find evidence for limited selection effects. Instead, hostile political discussions are the result of status-driven individuals who are drawn to politics and are equally hostile both online and offline. Finally, we offer initial evidence that online discussions feel more hostile, in part, because the behavior of such individuals is more visible online than offline.
Une donnée accessible dans l’espace public n’est pas une donnée libre d’utilisation
Il y a le droit d’auteur, le droit des bases de données, les règles d’utilisation des données personnelles, le cas spécifique des informations appartenant à l’État, et probablement bien d’autres choses.
La licéité de l’information ou de certains usages de l’information n’entraine pas celle d’un autre usage de cette même information
C’est particulièrement vrai pour tout ce qui est données personnelles, où chaque traitement et chaque finalité est indépendante des autres.
C’est vrai aussi de manière générale : Que la donnée soit utilisable dans certains cas n’implique pas que tout ce que vous en ferez sera forcément légitime, ni moralement ni légalement.
J’aime beaucoup Simon Willison depuis des années. Il tient un carnet de notes en guise de blog, comme j’aurais longtemps voulu avoir le courage de faire.
When caching the result of an expensive computation or a network call, don’t actually cache the result, but cache the promise that awaits the result.
This way, if a new, uncached key gets requested twice in rapid succession, ie faster than the computation takes, you avoid computing/fetching the same value twice. […] In other words, the promise acts as a mutex around the computation, and the resulting code is understandable even by people unfamiliar with mutexes, locks and so on.
