# Tag #technique — David Larlet
Publications relatives au tag #technique

Les plus récentes en premier, les 3 premières sont dépliées et ensuite c’est à la demande, bonne exploration !

## NostAlgIe (2023-12-03)

Paradoxalement, les LLM qui sont annoncés comme étant l’avenir ne font que reproduire ce qui a eu lieu dans le passé. Comme un auto-correct qui ne saurait pas que la langue évolue. Chaque prompt demande à notre passé de construire notre avenir, une forme d’héritage numérique auquel il va falloir s’habituer.

Considérant que nous sommes à un moment charnière où il faudrait justement dévier d’une trajectoire passée qui nous propulse à +trop-de-degrés, ces outils — par nature — réactionnaires ne sont-ils pas en train de nous conforter dans nos erreurs passées ?

Et c’est là où ça devient intéressant, peut-on de manière éthique choisir d’être orientés et quelles dérives certaines cela aurait ? Il y a déjà des biais énormes sur les jeux d’apprentissage mais est-ce que je pourrais choisir par exemple une saveur de ChatGPT qui ait été définie par Ecosia ? (cache) Quels paramètres politiques sont acceptables ? Et pour qui ?

Bref, c’était mieux avant 🙃.

> 🙄 Provides neutral analysis, fostering open communication and trust.

> LiarLiar.ai

> ✍️ Even if there are no real updates there is always something to say. In those moments, I write about something that happened to me this week. A small anecdote. Something human. Something grounding. No design mic-drops. No condescending words of wisdom.

> An Anchor - Mark Boulton (cache)

> 🧑‍⚖️ The Functional Source License (FSL) is a mostly permissive non-compete license that converts to Apache 2.0 or MIT after two years. It is designed for SaaS companies that value both user freedom and developer sustainability. FSL provides everything a developer needs to use and learn from your software without harmful free-riding.

> FSL

## Perspective (2023-09-27)

> Let’s call the generally pro-Tailwind group Builders, and let’s call the generally anti-Tailwind group Crafters.

> This isn’t to say that Crafters don’t build things, or that the Builders aren’t skilled craftspeople. But as a quick and messy shorthand, let’s go with it for a moment, because I think it hints at the values of these two groups.

> […]

> Builders clearly value getting the work done as quickly and efficiently as possible. They are making something—likely something with parts beyond the frontend—and are eager to see it through to completion.

> […]

> On the other side, the Crafters tend to be seasoned CSS specialists, and almost always enjoy the part of the work that Tailwind is supposed to make easier. It’s fair to say they’ve overcome the challenge presented by CSS—or, at least, that this is where they like to be challenged.

> Crafters may be building holistic products and projects, just like Builders. But Crafters generally are less focused on getting through the frontend as a part of that work, and instead see the frontend as the product itself.

> Classic rock, Mario Kart, and why we can’t agree on Tailwind (cache)

Un article nuancé qui pose le doigt sur la différence de point de vue dans l’utilisation des outils. Oui, c’est le second article technique d’affilé, après je vais prendre mes gouttes.

Le parallèle est intéressant avec les joueurs et les audiophiles car on est toujours dans la recherche de l’accomplissement au-delà de la performance pure. Une histoire de plaisir à arpenter le chemin et à le rendre accessible au plus grand nombre… tout en ayant conscience d’être un peu élitiste en se permettant cela car la face nord offre d’autres défis.

Je respecte — et j’admire de plus en plus — les personnes qui n’ont pas besoin d’entrer à fond dans un sujet pour s’amuser. Il y a une innocence dont émane une forme de beauté. Certain·es pourraient y lire une condescendance mal placée mais pas du tout, cette recherche est bien trop souvent un fardeau chronophage qui pourrit la vie et les relations. Un groupe sain nécessite probablement d’avoir les deux façons d’appréhender les choses pour arriver à l’équilibre instable qui consiste à aller de l’avant.

Oh, et pour revenir aux CSS, pour mon usage qui est de faire des petits outils résilients en équipe réduite, j’utilise de plus en plus des frameworks sans classes (ahum) comme Pico.css qui procurent une base saine, configurable et facilement portable. Est-ce que cela fait de moi un Brafter ? (Non.)

> ✍️ Most people default to one or another behavior but rarely use them exclusively. Writers will often benefit from talking things out when they get stuck; and talkers will find that occasionally writing something down helps solidify their thoughts. Both strategies can be learned. Whether you’re a writer or a talker isn’t about your inability to do one or the other so much as it is a preferred or optimized mode.

> This is, incidentally, a much more valuable way of understanding different working styles than the old maker vs manager canard. Both talkers and writers make things (including decisions), but they means by which they make things—and the needs they have in relation to their colleagues—are not the same.

> Writers and talkers and leaders, oh my! (cache)

> 🐉 But in general, I’d still be wary of using local-first outside real-time / multiplayer / offline use cases. Local-first is definitely still bleeding-edge. You will hit unexpected problems. A good community has rapidly developed, but there’ll still be some stretches on the road where you’ll have to solve novel problems.

> So: if you need local-first, see if it makes sense to isolate the local-first parts and architect the rest of the app (for now) in a more conventional fashion.

> Some notes on Local-First Development (cache)

> 😔 En fait ma plus grande inquiétude dans ses parcours hors-circuits sont les autres humains, ceux qui ne comprendraient pas ma démarche.

> banlieue ou suburb (cache)

## AÏe (2023-05-05)

> Honestly, at this point using ChatGPT in the way that I do feels like a massively unfair competitive advantage. I’m not worried about AI taking people’s jobs: I’m worried about the impact of AI-enhanced developers like myself.

> It genuinely feels unethical for me not to help other people learn to use these tools as effectively as possible. I want everyone to be able to do what I can do with them, as safely and responsibly as possible.

> I think the message we should be emphasizing is this:

> These are incredibly powerful tools. They are far harder to use effectively than they first appear. Invest the effort, but approach with caution: we accidentally invented computers that can lie to us and we can’t figure out how to make them stop.

> We need to tell people ChatGPT will lie to them, not debate linguistics (cache)

Je ne voulais pas trop réagir à chaud sur ce sujet. Aussi, je n’ai pas encore testé tout cela pour de vrai donc tout ce qui suit ne sont que les ruminations d’un vieux mi-Cassandre, mi-raison.

Quand je regarde les expériences de Simon Willison, je compare de plus en plus ces aides pour dévelopeur·euses à un StackOverflow amélioré. Peut-être que ça ne fait qu’accroitre les inégalités entre les personnes expérimentées et celles qui ne le sont pas. À moins que ça ne puisse être qu’une réflexion de personne expérimentée. Difficile de me prononcer mais je doute que cet outil permette de réduire ce fossé.

Bien sûr, ça donne tout de suite envie de faire (cache) des trucs (cache) plutôt fun (cache) avec. Pour ma part, ça me démotive de publier des choses qui vont venir alimenter la machine. Dans une telle proportion d’analyse, chaque réaction à un article ne fait qu’enrichir sa compréhension, chaque texte alternatif à une image ne fait qu’entraîner un générateur, chaque ligne de code sur une forge publique permet d’améliorer un algorithme potentiellement destructeur, chaque étiquette attribuée contribue à confirmer un biais. Les producteurs ont le pouvoir d’orienter un algorithme qui se nourrit de ces productions, d’une certaine manière les vainqueurs racontent déjà l’histoire qu’écrira la génération suivante. Tout change… sans vraiment changer.

Peut-être que, comme pour les échecs, cette aide contribuera à faire monter le niveau général et permettra de s’entraîner contre/avec la machine. Regardant beaucoup de parties commentées en direct, la jauge mise à jour en temps réel nous donne peut-être un aperçu des évaluations futures ou même des recrutements. J’imagine que ça pourrait devenir très pertinent pour générer des tests unitaires, voire de sécurité, sur un code produit.

En creux, il est un peu fou de constater que tout ce qui est publiquement et gratuitement accessible est en train d’être exploité pour le profit de quelques uns sans aucun respect des souhaits des auteur·ices sur ces contenus. Une forme de colonisation dont je prends conscience probablement car je suis — pour une fois — du mauvais côté de la frontière, aussi numérique soit-elle.

> 👴 Based on our findings, if Copilot is used by expert developers in software projects, it can become an asset since its suggestions could be comparable to humans’ contributions in terms of quality. However, Copilot can become a liability if it is used by novice developers who may fail to filter its buggy or non-optimal solutions due to a lack of expertise.

> GitHub Copilot AI pair programmer: Asset or Liability? (cache)

> ✍️ Personal notes (for meetings, books, and coding) seems the most promising but I don’t think AI can do this for me either. When I take notes, I’m only interested in writing out the stuff that matters to me. Every book I read has a hundred summaries on the internet, each more detailed and comprehensive than mine, but I still take book notes because I want to remember what impacted me. Even if an AI knew what those things were, delegating that work would defeat the purpose.

> AIs can write for us but will we actually want them to? (cache)

> 😔 It’s astonishing to me how little people have learned about trusting centralized entities with huge amounts of power in their lives. LLMs are a fundamentally centralized phenomenon — they take a huge amount of human and computer time to make, and are thus only accessible to enormous institutions. I don’t understand if people are simply blind to these power relations, or if they don’t care.

> Scattered ChatGPT thoughts (cache)

> 🤔 Where does this all land? I’m moderately optimistic about AI.

> But I think the thing that excites a lot of people about it is the reorganization, the shift, the reward for opportunism. Navigating that change in market opportunity and being there is its own reward to a lot of people. And it should be: this is the essence of progress in an industrialized society. The relationships, the strategy, matters much more to many people than craft or art: what goes into the production of a thing is just a variable to be minimized.

> How people feel about AI has a lot to do with how they think society should be structured, what makes work valuable, and what they truly enjoy doing.

> The one about AI (cache)

> 💦 Large Language Models are something lesser. They are water running down pathways etched into the ground over centuries by the rivers of human culture. Their originality comes entirely from random combinations of historical thought. They do not know the ‘meaning’ of anything—they only know the records humans find meaningful enough to store.[19] Their unreliability comes from their unpredictable behaviour in novel circumstances. When there is no riverbed to follow, they drown the surrounding landscape.

> Artificial General Intelligence and the bird brains of Silicon Valley (cache)

> 🧊 Depending on the energy source used for training and its carbon intensity, training a 2022-era LLM emits at least 25 metric tons of carbon equivalents if you use renewable energy, as we did for the BLOOM model. If you use carbon-intensive energy sources like coal and natural gas, which was the case for GPT-3, this number quickly goes up to 500 metric tons of carbon emissions, roughly equivalent to over a million miles driven by an average gasoline-powered car.

> And this calculation doesn’t consider the manufacturing of the hardware used for training the models, nor the emissions incurred when LLMs are deployed in the real world.

> The mounting human and environmental costs of generative AI (cache)

> 🪵 Enseignez le code sans ordinateur

> CODE EN BOIS est un système innovant et écologique qui permet d’initier à la programmation en manipulant des briques d’instructions en bois. La seule question qu’on se pose, c’est « pourquoi ça n’existait pas avant ? »

> CODE EN BOIS

> 🌌 J’ai ressenti l’impulsion après qu’une amie a demandé à la cantonade “ma fille voudrait aller voir les aurores boréales, mais ma famille ne prend plus l’avion, vous pensez que c’est possible en train ?”. Ça doit être possible, je me suis dit, mais compliqué à organiser. Et puis j’ai regardé les cartes, les zones de visibilité des aurores, les meilleures périodes de l’année pour les voir, la météo scandinave, les prédictions d’activité solaire… en fait, c’est bien plus accessible que je ne le pensais. Et si j’y allais ?

> Aller voir les aurores boréales en train (cache)

## Livre (2023-02-13)

Déplier pour lire le contenu de la publication

> They both would have been ‘good enough’ for my purposes, but since I’m comfortable with Markdown, HTML, and CSS, using Pandoc made the most sense.

> If you’re comfortable with Markdown then Pandoc is amazing. It integrates out of the box with both Weasyprint and paged.js. Either of them is a decent option for generating PDFs. Paged.js uses headless Chrome, which gives it access to a broader spectrum of CSS features and makes it a little bit flakier.

> Some thoughts on how to make a book, three months after I made one (cache)

Je commence à avoir quelques expériences avec Pandoc si vous voulez que l’on produise un livre numérique ensemble. Pas forcément technique. Potentiellement sur le Web. Dans le meilleur des cas on apprendrait chacun·e des choses et on repartirait à la fois plus autonomes et paradoxalement plus lié·es aussi.

(Dé)livrez-vous.

## Allumage (2023-02-09)

Déplier pour lire le contenu de la publication

Démarrer un nouveau projet avec une nouvelle équipe est un sentiment qui m’est incroyable. J’ai passé mon année 2022 à faire — entre autres — des petits produits pour Scopyleft et je ne réalise que maintenant à quel point ça me permet de démarrer plus rapidement aujourd’hui pour un site que l’on fait avec Maïtané pour la Croix-Rouge.

La structure est toujours un peu la même : des contenus dans du markdown, du déploiement continu de fichiers HTML statiques en utilisant l’intégration continue et l’hébergement de GitLab. Une URL de démonstration dès le premier commit. À partir de là, on peut rajouter des traductions, des images, une navigation particulière mais la base est l’affaire d’un copier-coller de quelques fichiers et d’une centaine de lignes de Python.

Soigner l’allumage technique, c’est avoir plus de temps pour réfléchir à l’accessibilité des données et à l’autonomie des personnes qui vont maintenir le site, c’est permettre de s’adapter aux besoins du public sans être contraint par un cadre, c’est prendre le temps de s’intéresser au problème métier à résoudre. C’est prendre confiance dans de petits outils résilients et frugaux.

Que mon eXpérience de Développeur (DX) s’en trouve être améliorée car j’aspire à cultiver de petits bonsaïs numériques n’est qu’un effet de bord.

> 🦕 I have been using it from day one of this blog (né Year II before LLM).

> The Content Management System of my Dreams (part 1) - A little bit of history (cache)

> 🧱 Think very hard about that word. What exactly is dynamic on your home page? Are you speaking about that Top News thingy? How often do they change? Are you doing this to satisfy yourself (some content editors have the same proclivity than developers to throw a tantrum because their new content does not appear instantaneously on the site)? Is this a business requirement or a real need of your users?

> The Content Management System of my Dreams (part 2) - The trouble with dynamic publishing (cache)

> 🧭 Since every direction is technically “North” from here, we use a grid overlay, to bring some semblance of order to our surroundings. The prevailing winds here come from “Grid North”.

> South Pole Topography (cache)

## Capot (2023-01-24)

Déplier pour lire le contenu de la publication

> En tant que premier projet public depuis mon arrivée chez Gandi, je suis content d’avoir pu tester tant de nouvelles chose—nouvelles pour moi, nouvelles pour l’équipe… la possibilité d’apprendre des nouveaux concepts et des nouvelles pratiques, c’est l’une des principales raisons pour laquelle je pratique ce métier. L’autre raison c’est que ça me permet de réaliser des choses pratiques et utiles dans le respect des personnes qui les utiliseront.

> Un coup d’œil sous le capot (cache)

J’adore ces retours où il « suffit » d’une nouvelle personne pour qu’un partage devienne possible.

En ce moment, je me questionne sur l’accueil potentiel d’une personne en alternance dans Scopyleft. C’est un engagement sur deux ans avec 4 jours par semaine, c’est énorme. Et en même temps, ça permettrait peut-être à cette personne de ne plus être considérée comme totalement débutante et d’accéder à des postes/situations plus enviables.

Peut-être que ce serait aussi l’occasion de publier davantage d’outils et de pratiques que nous avons et qui ne sont pas documentées et/ou pas publiques.

Tellement de choses peuvent se passer en 2 ans…

## Dépendances (2023-01-14)

Déplier pour lire le contenu de la publication

> I suspect one of the reasons for this is that Pinafore is written in Svelte v2 and Sapper – both of which are deprecated in favor of Svelte v3 and SvelteKit. Not only is there no migration path from Svelte v2 to v3, but there isn’t one from Sapper to SvelteKit either. (And on top of that, I had to fork Sapper pretty heavily.) Anyone making a bet on learning Pinafore’s tech stack is investing in a dead framework, so it’s not very attractive for new maintainers.

> Retiring Pinafore (cache)

« Move fast and outdate things. » n’est pas un motto mais une constatation. Je suis assez assidu des écrits de Baldur Bjarnason à ce sujet, que ce soit à travers son site, son livre ou sa newsletter.

Je crois que je commence à dépasser la sidération et le rejet pour tenter de comprendre un peu mieux les raisons profondes de toute cette complexité et cette vitesse que l’on s’impose, avec une composante historique notamment.

2023, l’année de la maturité 😂.

> The symptoms of pop culture:

> - A “disdain for history”. Pop cultures believe history doesn’t have anything to teach them.
> - Newer is automatically better. Pop cultures are built on the assumption that anything new or different is superior to established. Or, in other words, older is inherently inferior.
> - What’s next is going to be superior to what’s now. Pop cultures exist in perpetual anticipation of the next trend. Their disbelief of history appears to outsiders as a belief in progress.
> - The “Pop” in “Pop Culture” stands for “popularity”. If it’s popular then it must be right.

> These traits are deeply irrational but they are the tech industry’s default mode of operation.

> Tech Companies Are Irrational Pop Cultures (cache)

> We’re starting to see the initial decay hit the parts of the web dev ecosystem that are the furthest away from the cheap money fountains Google and Facebook are providing. Core projects run out of money. Git commits stop. A dependency you use breaks when one of its dependencies stops working, leading somebody to fork it with a quick fix or replacement dependency. Bandaid fixes to decaying OSS projects start to crop up in more and more places. We start to see blog posts saying that all we need to do is get enough people to donate money or pay for support. Everything will be fine. Just look at how OpenSSL got turned around.

> All of which is bad enough but also misses the point.

> The Open-Source Software bubble that is and the blogging bubble that was (cache)

> This JavaScript community (if judged by the demographics of this survey) seems to be comprised mostly of folks that are largely building with React, webpack, and Jest. With React on 3.2% of web sites and jQuery at 77.7% (as of January 2023), that’s a pretty small slice of a much larger community.

> We seem to live in different worlds.

> JavaScript, Community (cache)

## Qualité (2023-01-10)

Déplier pour lire le contenu de la publication

> Quiconque cherche à circonscrire une discipline en lui imposant un cadre ne cherche généralement qu’à protéger son œuvre, et il le fait en perpétuant les standards qui ont permis son émergence. Celui-ci essaie de convaincre les générations à venir qu’elles doivent suivre les règles qu’il a édictées si elles comptent parvenir à l’excellence. Mais, comme disait Charles Bukowski, « il est quatre heures et demie du matin, il sera toujours quatre heures et demie du matin… ».

> Nous sommes à ce point focalisés sur le chemin que nous nous efforçons de suivre, en voulant toujours tout faire au mieux, armés d’une dévotion sans faille pour notre discipline alors que les œillères de la peur nous empêchent d’envisager des terrains inconnus, que nos yeux restent fixés sur cette route, sur ces mains qui prennent appui sur des genoux. Et nous ne réalisons pas que nous ne faisons que suivre les règles promulguées par un homme qui a un jour disputé une course contre des chevaux, ou par un autre qui s’est frotté à un sommet de plus de huit mille mètres sans oxygène, ou par un autre encore qui a décidé de laisser chez lui ses pitons, ses cordes et la sécurité pour ne faire qu’un avec les murs à escalader. Nous suivons les lois de ceux qui en ont enfreint de plus anciennes.

> Au-delà des sommets, Kilian Jornet

On parlait de code et de qualité avec Thomas. Je lui faisais part de ma frustration vis-à-vis d’un code qui n’avait pas été écrit par moi et que je trouvais problématique. En creusant un peu (merci !), je réalise que ce qui coince est au niveau de la pérennité et de la transmission. Et j’ai aussi conscience de produire moi-même du code qui serait difficile à reprendre par d’autres personnes n’ayant pas les mêmes aspirations/compétences.

En Python, on a la chance de pouvoir automatiser certaines conversions/vérifications qui tendent à aller vers une certaine uniformisation (et donc universalité ?) : black, flake8, isort ou mypy par exemple.

Pour aller plus loin, le code en lui-même n’est peut-être pas si critique, mais ce que l’on a appris en le concevant et l’utilisant l’est bien davantage. C’est cette transmission qu’il est important de rendre possible au sein de l’équipe. Outiller la base commune est un moyen de plus rapidement passer à l’étape de partage des concepts importants/métiers, en ce souciant moins de la forme.

Et peut-être au contraire, que cette vitesse acquise nous empêche d’échanger sur des concepts importants ? Des envies différentes ? Des choix à côté desquels on peut passer par manque d’attention.

> Tradition (n.): Peer pressure from dead people.

> Lu plusieurs fois sur masto

> 🦋 Depuis quelques années, j’essaie d’écrire un code le plus direct possible.

> Mon objectif : diminuer au maximum ma charge cognitive.

> Keep it simple, stupid le plus longtemps possible (cache)

> ⛵️ Many of the tools that we thought we could rely on broke down, whether it is Apple products, or software that require subscription services, DRM, etc. As an artist you spend time developing a skill, you become a Photoshop illustrator. When your connection to the internet fails and that the software locks up, that skill that you thought was yours was actually entirely owned by someone, and can be taken away.

> Even though we’ve been paying for this sort of software for years, the moment that you can’t have access to authenticate yourself that skill is gone. We didn’t expect this, it scared us.

> weathering software winter (cache)

> 🔎 It’s important to remember concepts and high level approaches, but don’t worry about remembering the details. You can always look that stuff up when you need it.

> You don’t have to remember everything to be a good programmer (cache)

## Dette (2023-01-07)

Déplier pour lire le contenu de la publication

> La dette c’est un problème de riche. Ça arrive après, quand on a trouvé le bon produit, qu’on a trouvé sa cible, qu’on a prouvé qu’on était capable d’acquérir des clients. Là on aura aussi le financement qui va avec pour embaucher des ingénieurs qui vont refaire ce qui doit l’être, et éliminer une bonne partie des travaux qu’on avait remis à plus tard.

> L’enjeu c’est d’arriver jusque là.

> La dette technique - Carnet de notes (cache)

La seule fois dans ma carrière (ouais ça fait tout de suite vieux là…) où on a réussi à éponger une dette technique initiale a été sur MesConseilsCovid lorsqu’on a dû partir comme des fusées avec Ronan parce que le gouvernement français ne pouvait pas se douter qu’on allait déconfiner la population à un moment 🤷.

Les conditions qui ont rendu possible cela sont multiples :

- développeurs expérimentés qui se connaissent et qui se sont déjà pincé les doigts plusieurs fois sur du code non testé/à l’arrache à moyen terme ;
- équipe compréhensive qui a pris en compte nos retours et notre endettement volontaire des premières semaines, effort de pédagogie de notre côté ;
- outil relativement simple qui a consisté au début à une preuve de concept permettant de mesurer les usages et attentes, on n’était pas dans une course à la fonctionnalité ;
- budget suffisant pour savoir qu’il serait possible de financer cette dette à moyen terme (« Quoi qu’il en coûte », etc #haha).

Il faut une sacré conjonction pour que toutes ces conditions soient réunies. De plus, ça a demandé pas mal de rigueur alors que la dette n’était finalement que d’un mois, peut-être moins.

Dans une précédente expérience startup, on avait trop mis l’accent sur la technique/le produit et pas assez sur son adoption/communication, ça peut arriver aussi. J’ai beaucoup appris de cet échec sur l’importance de ce qui est hors du code.

> 😔 The most obvious way an online community is like a bar is that bars serve alcohol, and alcohol makes people loud and stupid. It actually depresses your hearing, so you can’t hear yourself talk as well, so you speak louder. And a room full of people speaking louder means a very boisterous room. And of course, alcohol reduces inhibition, so you say things you might not usually say.

> The parallels to online behavior are easy to see. Online, people are much more willing to type things that they’d never say in person.

> A community isn’t a garden, it’s a bar. (cache)

> 🔙 It can be uncomfortable, that clearing away. It can be deeply unpleasant. But it’s also useful. It’s a sign of what you need to change. What I found was that when I gave myself permission to really feel that unpleasantness, when I didn’t try to get comfortable with it or avoid it, I opened some space to move: towards a reconfiguration or revision or reimagining of what my work was.

> Reentry | A Working Library (cache)

## Instanseul (2023-01-05)

Déplier pour lire le contenu de la publication

> Peut-être que la centralisation d’une identité mastodon est une hérésie. 🤔

> Au même titre que l’on s’adapte au contexte des lieux physiques, je pourrais avoir un compte sur piaille.fr pour parler dans un contexte français, un autre sur jasette.facil.services pour tout ce qui est québécois, etc.

> Une identité distribuée, fédiversifiée, qui serait la représentation numérique d’une personnalité complexe et moins lissée.

> Il y a tant à désapprendre.

> Un pouet du 23 novembre 2022 (ancienne instance)

Un retour sur ma migration Mastodon depuis https://mastodon.social/@dav vers https://fedi.larlet.fr/@david (avec @david@larlet.fr en username) en utilisant masto.host en arrière plan.

Quelques motivations pour bouger :

- la décentralisation rendue possible par les protocoles vs. ma participation à une instance centrale/principale/historique qui n’est pas terrible compte tenu de mes compétences/connaissances ;
- la consommation des ressources des autres (et savoir combien ça consomme en vrai), au-delà de l’argent, je voulais avoir une idée de ce que ça implique sans pour autant l’auto-héberger ;
- la modération (im)possible à une telle ampleur avec une équipe/politique qui n’est pas limpide et des conflits d’intérêts possibles hébergeur/développeur ;
- le contrôle et la pérennité des endroits où je m’exprime en ligne sont importants pour moi ;
- le côté expérimental/geek de la chose en jouant avec les protocoles 🧑‍🔬.

Ce qui est problématique à ce jour :

- la migration a été un peu chaotique car j’avais déjà tenté plein de trucs à la main à base de `webfinger` sur ce domaine et il restait des traces et du cache, ma faute ;
- lors de la migration, il semble y avoir des (serveurs de) comptes qui n’ont pas répondu à temps et qui suivent encore l’ancien profil, sachant que je ne peux initier une redirection/récupération que tous les 30 jours sur mastodon.social ça fait pas mal de personnes qui ne savent pas ce qui se passe, j’imagine que je suis aussi des comptes fantômes sans le savoir ;
- lors du déclenchement de la migration, vous n’avez plus accès à grand chose à part à vos archives, il n’est pas possible de modifier son ancien profil par exemple pour signifier que c’est un compte redirigé auquel il ne faut plus s’abonner ;
- à ma connaissance, si quelqu’un·e fait un message direct à l’ancien compte, iel n’a aucun moyen de savoir que celui-ci est redirigé et que je n’aurai pas les moyens d’être notifié et de répondre ;
- je n’ai pas facilement accès aux réponses de messages hors de mon instance (à part s’il s’agit d’une personne suivie qui répond), il faut que j’aille sur l’URL de l’instance en question pour tout voir, ça réduit beaucoup l’aspect social de la chose, surtout en suivant très peu de personnes ;
- le flux RSS n’est pas redirigé depuis https://mastodon.social/@dav.rss vers https://fedi.larlet.fr/@david.rss ce que je peux comprendre techniquement mais qui n’est pas terrible (issue ici) ;
- je ne sais pas comment fonctionne la découverte des comptes mais il y a clairement moins de personnes (connues) qui s’abonnent depuis la migration, je ne sais pas si c’est un défaut d’eXperience Utilisateur·ice ou autre (je doute que ce soit la timeline locale qui puisse être en cause vu le flux sur mastodon.social) ;
- j’ai l’impression de ne pas voir tous les messages mais ça m’arrivait déjà avant avec deux clients différents donc ça ne doit pas dépendre de l’instance ;
- je n’ai reçu aucune des nombreuses notifications sur mon ancien compte, il m’a fallu le réactiver pour m’en rendre compte !

Ce que j’ai découvert :

- les administrateur·ices d’instances ont un résumé des mots-dièses les plus employés sur l’instance (et la possibilité de les mettre en avant) ;
- je consomme beaucoup d’espace disque (3 Gb à ce jour, après un mois) alors que je publie peu, tout ce qui passe dans ma timeline semble être récupéré localement, je me demande s’il y a un option pour faire le ménage ;
- les interactions avec les personnes suivies restent quasi-instantanées, merci ActivityPub (cache) ;
- je n’ai eu aucun problème de spam jusqu’à présent ni d’instance à bloquer ;
- je ne sais pas si c’est la migration et/ou la vague de novembre (et/ou les activités hivernales) mais j’interagis beaucoup moins sur le réseau, d’une certaine manière ça m’a motivé pour republier régulièrement par ici ;
- j’ai toujours ce truc qui me trotte en tête de ne pas passer par Mastodon mais d’avoir un truc semi-statique et certains ont déjà un peu creusé depuis.

Est-ce que tout cela en valait vraiment la peine ? Ce n’est pas encore bien évident… j’ai une vraie frustration à ne pas voir toutes les réponses, ce qui était déjà vrai auparavant mais sur une instance populaire ça se voit beaucoup moins (ce qui est peut-être encore davantage un souci !). Pareil lorsque je veux suivre une nouvelle personne, il faut que j’aille sur sa page de profil sinon je n’ai pas (toutes) ses publications. Depuis Toot! sur iOS c’est extrêmement fastidieux.

Cela m’a permis d’explorer aussi la résilience du protocole et contrairement à ce qu’il se passe avec les courriels ça ne semble pas retenter les envois. Les interfaces actuelles étant assez silencieuses sur ces erreurs, c’est dommage, même en asynchrone ça serait bien utile.

D’un autre côté, j’ai appris pas mal de choses sur les rouages et le transit des publications et des interactions.

Est-ce que je recommanderais aux nouvelles et nouveaux venu·es de commencer avec une instance solo ? Sûrement pas. C’est déjà fastidieux de comprendre le concept d’instance, si en plus il y a tous les problèmes cités ci-dessus qui s’ajoutent et créent davantage de confusion ça doit donner une expérience décevante.

En même temps, une instance solo fait probablement peu de sens pour un réseau social architecturé comme Mastodon et on en revient à mon pouet initial (oui vous savez, tout là-haut) : plusieurs comptes avec plusieurs identités. En revanche, pour un collectif — au hasard Scopyleft — je vois un intérêt à avoir une instance dédiée. Ça pourrait permettre d’embarquer des personnes en douceur aussi…

> ✍️ Hacking on ActivityPub was a fun project, but it was chaotic. ActivityPub in practice is a grab-bag of specifications and implementation-specific details. It was hard to find documentation for a lot of things and hard to debug requests that didn’t have their intended effect on Mastodon.

> ActivityPub is a distributed architecture, so it’s going to be a lot more complicated than RSS.

> Playing with ActivityPub (cache)

> 😬 I found this one particularly hard - it was almost impossible to find an example of what a Follow message looks like, so I ended up spending a lot of time following my account from a Mastodon client and seeing what data was HTTP POSTed; and I also need to maintain the state of who followed me (so I can send them messages later).

> Adding ActivityPub to your static site (cache)

> 💯 A virtual Mastodon monopoly is not good for almost anyone, I think - I'm actually quite excited for Tumblr to implement ActivityPub, because it stands a chance of forcing protocol changes and improvements to be discussed, rather than directed almost entirely by one project.

> Understanding A Protocol (cache)

> But there’s one major difference to all the problem’s we've witnessed with social media so far. It will stay an open space that we can co-design. Even though Eugen Rochko now seems to be a super nice guy, he has all the freedom to abandon Mastodon, make some bad decisions or to do a hard right turn and follow Elon. It doesn’t matter. Always remember that Mastodon is just one door. You no longer like this door? Open another one. Mastodon is not THE platform.

> Network effect (cache)

> 😅 Self-hosting Mastodon is all the rage, but having to deal with a full-blown installation of Ruby (which is always a pain to install properly, even if you use rbenv), plus the abomination that is Sidekiq and the overall Rube Goldberg-esque architectural approach that is almost mandatory to deal with the complexities of ActivityPub is just something I don’t want to maintain. Ever. Even inside Docker.

> Getting Takahē to run on Piku (cache)

> Having spent time on Mastodon, I now realize how hilariously wrong I was about how moderation would work. I was seeing Mastodon through the lenses of Twitter, rather than as a different culture with different technology. I’m now fairly confident in saying Mastodon is friendlier than Twitter and will remain so, regardless of who and how many join.

> I Was Wrong About Mastodon (cache)