Tu as déjà un disque source et un disque destination différents, ce qui n'est pas mon cas sur ce PC. D'autre part, ce qui compte le plus c'est probablement le nombre de fichiers à analyser puis sauvegarder.
Cette métrique est très pertinente pour juger de la qualité d'un code :
Elle l'est aussi pour juger de la qualité d'un langage. Et on dira ce qu'on voudra, mais JS a quand même un taux de WTF/minute assez hallucinant (cf les exemples que j'ai donné dans l'article).
Alors, oui, y'a des bonnes pratiques dans tous les langages. Mais je ne connais aucun autre langage (destiné à être utilisé, pas la peine de me sortir Brainfuck ou d'autres exotismes) dont les bonnes pratiques consistent à se priver de plus de la moitié des possibilités du langage.
Pour le clavier, je me suis habitué à la disposition bépo. J'ai retrouvé une vitesse de frappe normale (55 mots par minutes). Par contre, j'ai du mal à taper en azerty désormais. Ce qui m'inquiète parfois.
Depuis que je tape en bépo, j'ai aussi du mal avec azerty. Je m'en étais inquiété à l'époque et les témoignages que j'avais eu en ce sens étaient d'accord pour dire que :
C'est normal.
Si tu tapes assez souvent en azerty (ce qui n'est pas mon cas), tu reviens assez vite à la vitesse que tu avais avant.
C'est peut-être parce que j'ai de grandes paluches, mais je ne constate pas de mouvement significatif, sauf quand je dois aller chercher les deux touches en haut à gauche du bloc principal du clavier – et dans ce cas, c'est plus tout l'avant-bras qui bouge vers le haut.
En admettant que tu n'aies pas de problèmes de conformation de la main et de l'avant-bras, si réellement taper sur un clavier classique te « force à avoir la main gauche qui se contorsionne vers la gauche en mouvement inverse de l'avant-bras », il me semble urgent de vérifier et de corriger ta posture, et éventuellement d'apprendre la dactylographie. Parce que ce n'est pas normal du tout d'en arriver à ces extrêmes.
Je viens de vérifier ; même avec une disposition BÉPO (qui est conçue pour que les mains soient correctement disposées et qui fait en sorte qu'elles bougent le moins possible), la différence dans les mouvements des mains gauches et droite est très minime, c'est plus une tendance générale de là où vont les doigts plus que des « contorsions ».
C'est peut-être une bonne occasion pour apprendre le BÉPO d'ailleurs :)
Le JS écrit et le JS compilé (« transpilé ») sont exactement comme ton langage « natif » préféré et le binaire compilé : tu ne t'occupes que de ce que tu écris, sauf cas exceptionnels tu n'as pas à te soucier ni de ce qui a été compilé, ni comment ça a été fait, parce que ce fonctionnement est garanti par le compilateur.
Du coup, quand tu fais du JS moderne (ou du Typescript, ou du Coffescript pour les irréductibles qui l'utilisent encore), tu n'as besoin de connaitre que le langage source sans jamais t'intéresser ni à la compilation (qui n'ajoute pas plus de bugs qu'une compilation native) ni au produit de la compilation (qui de toutes façons est aussi illisible que n'importe quel résultat de compilation en n'importe quelle technologie : langage machine, bytecode ou autre langage).
Pour Vue.js vs React vs Angular, les trois ont l'air de se valoir, mais Vue.js semblait « plus propre », être plus agréable à utiliser, et avoir moins de casseroles d'après les moult tests que j'ai lus. Mais c'est très subjectifs (et j'aime pas le concept de JSX de React).
L'utilité et l'intérêt d'un state management pattern et d'une bibliothèque comme VueX est à peu près incompréhensible tant qu'on a pas joué avec de la programmation réactive (et de fait, je ne l'ai pas compris avant d'avoir testé et compris Vue.js).
En gros : ton framework de programmation réactive (j'ai utilisé Vue.js, mais de ce que j'en sais React et consorts fonctionnent pareil) va te permettre de découper ton application en composants. Chaque composant va par défaut gérer les données d'état et l'affichage d'un bout de l'application. C'est très pratique en terme de découpage, mais d'un point de vue « intégrité des données » ça va avoir deux inconvénients :
Les données d'état vont être naturellement éparpillées dans toute l'application, ce qui rends l'état de l'application très rapidement incompréhensible et imprédictible.
Tu as très vite fait de mettre à jour ton état depuis X points d'entrée (c'est d'autant plus facile que JS est souple et permet de faire plein de trucs, donc tu peux très rapidement mettre à jour un objet partagé en pensant qu'il n'était qu'à toi). Et avec X > 1, tu auras forcément un moment ou quant tu veux mettre à jour ton état, tu dois aussi faire le traitement A, mais ce traitement ne sera fait qu'à partir du point d'entrée X1 mais pas X2. Et bim ! État incohérent !
Donc, un outil comme VueX (ou Flux, Redux et leurs amis) te permet de corriger tout ça :
Tu centralises l'état de ton application,
Tu garantis la cohérence de cet état en t'interdisant de le mettre à jour par d'autres moyens que des méthodes clairement identifiées1.
Entre autres effets de bord sympathiques, ça permet de tracer en dev toutes les modifications sur l'état de ton application, et donc de voyager dans le temps.
Voilà, j'espère que c'est plus clair comme ça ?
En réalité dans VueX, pour des raisons de langage tu ne peux pas forcer l'interdiction de modification, et les avertissements « attention cet objet a été modifié en douce hors des procédures » n'est actif qu'avec une configuration spécifique. Qui doit donc impérativement être activée en dev (sinon c'est idiot) et désactivée en prod (sinon c'est lent). ↩
J'aurais tellement aimé pouvoir ne pas être d'accord avec eux sur ce coup là… cela dit, il me semble que je trouve plus de points positifs qu'eux à JS.
Si tu veux utiliser du Javascript moderne dans des navigateurs qui ne sont pas uniquement de la toute dernière génération, tu es obligé de le compiler – ou plus exactement de le transpiler – et de le fournir sous un format compatible avec les différents navigateurs.
C'est le boulot de Babel et de Webpack. En gros, le premier va transformer ton JS moderne en JS moins moderne mais compréhensible par des navigateurs qui ont plus de 6 mois ; le second va packager tout ce bordel dans des fichiers que les navigateurs vont pouvoir utiliser directement. (En réalité, c'est bien plus complexe que ça, mais tu as l'idée). Il y a aussi une phase de transformation SASS → CSS et de minification.
Donc dans un projet JS moderne, le code que tu écris n'est plus interprété directement par le navigateur. Et la phase de transformation est atrocement lente et nécessite une quantité démente d'I/O disques.
Tout dépend de quoi tu part : si tu as déjà un front que tu veux moderniser, Vue.js est un bon framework (et tu as déjà les avantages et limitations sur l'écosystème JS).
Si c'est pour changer un framework côté serveur en SPA, la question mérite effectivement une étude.
Merci, je garde le lien sous le coude ; cela dit pour le projet professionnel, vu les outils déjà utilisés, quitte à changer de langage côté front on partirait plutôt sur quelque chose comme Kotlin (on a déjà du Java et du .NET, mais pas de Python).
En tous cas merci aux personnes qui ont pris la peine de répondre à mon petit questionnaire, c'est très pratique pour moi.
Sur le peu de résultats que j'ai pour l'instant, j'ai pas d'énormes surprises (du type un texte que je n'aimerais pas du tout mais vous oui ou inversement), mais quelques classements auxquels je ne m'attendais pas (plutôt du type « texte que je trouvais moyen mais que vous aimez bien », et inversement).
Je note aussi qu'il y a peu de textes vraiment clivants, ce qui est pratique pour moi. Et que le mieux noté est celui qui parle de cul… (je ne donne volontairement pas d'indications sur les autres votes pour ne pas influencer).
En tous cas n'hésitez pas à répondre, c'est vraiment très utile de mon point de vue !
Justifier sur un téléphone (ou plus généralement sur une colonne étroite) est une mauvaise pratique, sauf en cas de gestion propre des césures – ce que ne font pas les navigateurs. Parce que dans ce cas, certes c'est plus joli, mais bien moins lisible à cause des espaces entre mots qui peuvent devenir énormes.
Encore une fois, qu'est-ce que tu imaginais en postant ce message ?
Concrètement, libérer ce code, c'est :
Soit rendre public le dépôt (qui contient des contenus sous multiples licences : le template du site et les textes sont tous au même endroit, et les textes ne sont pas tous sous la même licence),
Soit extraire le code du template, vérifier/supprimer les identifiants en dur, ajouter le fichier de licence et rendre ça public.
La solution 2 doit prendre une dizaine de minutes, donc c'est vraiment de la flemme. Mais à quel moment ton premier commentaire était censé me motiver pour faire ça ? Relis-le, tu verras que le vocabulaire et le ton n'incitent pas à l'action ou à la discussion.
Quant au premier HS sur la technique, il concerne un point spécifique à ce qui est présenté (mon site, indirectement). La discussion sur « il faut tout libérer », on l'a déjà lue un peu partout sur ce site.
J'ajoute que ton message est en réalité doublement toxique :
Parce que si son but était que je libère le code, c'était le pire moyen de le demander. En fait, il suffit que n'importe qui me demande « Hé au fait ça m'intéresse de voir comment tu as fait » pour que la balance énergie/intérêt bascule et que je me sorte les doigts. Mais en venant m'insulter, tu espérais quoi, sérieusement ?
Parce que une fois de plus, tu fais partir les commentaire sur un sujet qui n'a rien à voir avec le journal avec tes interventions tout en ayant aucun intérêt pour personne (on a déjà lu cette discussion des centaines de fois). C'est un gros défaut de LinuxFR, et tu n'aides en rien à le corriger.
[^] # Re: Retour d'expérience sauvegarde rsync
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 4.
C'est un mauvais vocabulaire de ma part, c'est proposé en tant que « utilitaire de restauration système ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Retour d'expérience sauvegarde rsync
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2.
Pour revenir facilement à l'état précédent en cas de problème à l'installation d'un paquet. C'est l'utilisation par défaut de Timeshift dans Mint 19.
La connaissance libre : https://zestedesavoir.com
[^] # Re: ionice
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2.
Probablement, mais ça nécessite de mettre les mains dans le cambouis, ce qui n'est pas du tout dans la philosophie de la distribution.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Retour d'expérience sauvegarde rsync
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2.
Tu as déjà un disque source et un disque destination différents, ce qui n'est pas mon cas sur ce PC. D'autre part, ce qui compte le plus c'est probablement le nombre de fichiers à analyser puis sauvegarder.
La connaissance libre : https://zestedesavoir.com
[^] # Re: TypeScript
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 10.
Cette métrique est très pertinente pour juger de la qualité d'un code :
Elle l'est aussi pour juger de la qualité d'un langage. Et on dira ce qu'on voudra, mais JS a quand même un taux de WTF/minute assez hallucinant (cf les exemples que j'ai donné dans l'article).
Alors, oui, y'a des bonnes pratiques dans tous les langages. Mais je ne connais aucun autre langage (destiné à être utilisé, pas la peine de me sortir Brainfuck ou d'autres exotismes) dont les bonnes pratiques consistent à se priver de plus de la moitié des possibilités du langage.
La connaissance libre : https://zestedesavoir.com
# BÉPO et AZERTY
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 ans de projets libres : bilan et idées. Évalué à 10.
Depuis que je tape en bépo, j'ai aussi du mal avec azerty. Je m'en étais inquiété à l'époque et les témoignages que j'avais eu en ce sens étaient d'accord pour dire que :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Clavier orthogonal
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Un petit laptop Open hardware. Évalué à 1.
C'est peut-être parce que j'ai de grandes paluches, mais je ne constate pas de mouvement significatif, sauf quand je dois aller chercher les deux touches en haut à gauche du bloc principal du clavier – et dans ce cas, c'est plus tout l'avant-bras qui bouge vers le haut.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Clavier orthogonal
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Un petit laptop Open hardware. Évalué à 2.
En admettant que tu n'aies pas de problèmes de conformation de la main et de l'avant-bras, si réellement taper sur un clavier classique te « force à avoir la main gauche qui se contorsionne vers la gauche en mouvement inverse de l'avant-bras », il me semble urgent de vérifier et de corriger ta posture, et éventuellement d'apprendre la dactylographie. Parce que ce n'est pas normal du tout d'en arriver à ces extrêmes.
Je viens de vérifier ; même avec une disposition BÉPO (qui est conçue pour que les mains soient correctement disposées et qui fait en sorte qu'elles bougent le moins possible), la différence dans les mouvements des mains gauches et droite est très minime, c'est plus une tendance générale de là où vont les doigts plus que des « contorsions ».
C'est peut-être une bonne occasion pour apprendre le BÉPO d'ailleurs :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: On n'est pas limité au JS côté front
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 5.
Le JS écrit et le JS compilé (« transpilé ») sont exactement comme ton langage « natif » préféré et le binaire compilé : tu ne t'occupes que de ce que tu écris, sauf cas exceptionnels tu n'as pas à te soucier ni de ce qui a été compilé, ni comment ça a été fait, parce que ce fonctionnement est garanti par le compilateur.
Du coup, quand tu fais du JS moderne (ou du Typescript, ou du Coffescript pour les irréductibles qui l'utilisent encore), tu n'as besoin de connaitre que le langage source sans jamais t'intéresser ni à la compilation (qui n'ajoute pas plus de bugs qu'une compilation native) ni au produit de la compilation (qui de toutes façons est aussi illisible que n'importe quel résultat de compilation en n'importe quelle technologie : langage machine, bytecode ou autre langage).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 5. Dernière modification le 11 novembre 2018 à 01:26.
Pas vraiment : ton état est immutable en dehors des méthodes prévues à cet effet… et c'est précisément l'une de ces méthodes que tu montres.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 7. Dernière modification le 09 novembre 2018 à 17:47.
Pas vraiment, parce que les responsabilités et l'utilisation sont différentes d'un framework MVC.
Notamment parce que le MVC traditionnel c'est :
Avec aucune communication entre Modèle et Vue, et un mapping à gérer plus ou moins manuellement.
Le modèle réactif avec ce type d'organisation c'est :
(Note que là les flèches ne vont que dans un seul sens, alors qu'elles sont à double sens dans le cas du MVC).
Mais je persiste, l'intérêt de la chose et la différence avec le MVC sont incompréhensibles si on ne maitrise pas déjà la programmation réactive.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas compris ce qu'étais le pattern flux/Vuex
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 3.
J'espère que ce commentaire réponds à ta question ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 9. Dernière modification le 09 novembre 2018 à 16:54.
Pour Vue.js vs React vs Angular, les trois ont l'air de se valoir, mais Vue.js semblait « plus propre », être plus agréable à utiliser, et avoir moins de casseroles d'après les moult tests que j'ai lus. Mais c'est très subjectifs (et j'aime pas le concept de JSX de React).
L'utilité et l'intérêt d'un state management pattern et d'une bibliothèque comme VueX est à peu près incompréhensible tant qu'on a pas joué avec de la programmation réactive (et de fait, je ne l'ai pas compris avant d'avoir testé et compris Vue.js).
En gros : ton framework de programmation réactive (j'ai utilisé Vue.js, mais de ce que j'en sais React et consorts fonctionnent pareil) va te permettre de découper ton application en composants. Chaque composant va par défaut gérer les données d'état et l'affichage d'un bout de l'application. C'est très pratique en terme de découpage, mais d'un point de vue « intégrité des données » ça va avoir deux inconvénients :
Donc, un outil comme VueX (ou Flux, Redux et leurs amis) te permet de corriger tout ça :
Entre autres effets de bord sympathiques, ça permet de tracer en dev toutes les modifications sur l'état de ton application, et donc de voyager dans le temps.
Voilà, j'espère que c'est plus clair comme ça ?
En réalité dans VueX, pour des raisons de langage tu ne peux pas forcer l'interdiction de modification, et les avertissements « attention cet objet a été modifié en douce hors des procédures » n'est actif qu'avec une configuration spécifique. Qui doit donc impérativement être activée en dev (sinon c'est idiot) et désactivée en prod (sinon c'est lent). ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: On t'as démasqué
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 6.
J'aurais tellement aimé pouvoir ne pas être d'accord avec eux sur ce coup là… cela dit, il me semble que je trouve plus de points positifs qu'eux à JS.
La connaissance libre : https://zestedesavoir.com
[^] # Re: compilation
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 10.
Si tu veux utiliser du Javascript moderne dans des navigateurs qui ne sont pas uniquement de la toute dernière génération, tu es obligé de le compiler – ou plus exactement de le transpiler – et de le fournir sous un format compatible avec les différents navigateurs.
C'est le boulot de Babel et de Webpack. En gros, le premier va transformer ton JS moderne en JS moins moderne mais compréhensible par des navigateurs qui ont plus de 6 mois ; le second va packager tout ce bordel dans des fichiers que les navigateurs vont pouvoir utiliser directement. (En réalité, c'est bien plus complexe que ça, mais tu as l'idée). Il y a aussi une phase de transformation SASS → CSS et de minification.
Donc dans un projet JS moderne, le code que tu écris n'est plus interprété directement par le navigateur. Et la phase de transformation est atrocement lente et nécessite une quantité démente d'I/O disques.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est... rassurant ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 3. Dernière modification le 09 novembre 2018 à 11:36.
Ah OK, au temps pour moi :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est... rassurant ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 7.
Tu as été peut-être confusionné par la dernière phrase de la conclusion qui dit :
Ton témoignage me conforte dans mon idée.
La connaissance libre : https://zestedesavoir.com
[^] # Re: merci
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 4.
Tout dépend de quoi tu part : si tu as déjà un front que tu veux moderniser, Vue.js est un bon framework (et tu as déjà les avantages et limitations sur l'écosystème JS).
Si c'est pour changer un framework côté serveur en SPA, la question mérite effectivement une étude.
La connaissance libre : https://zestedesavoir.com
[^] # Re: ne pas faire de js sans pour autant s'en passer
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 6.
Merci, je garde le lien sous le coude ; cela dit pour le projet professionnel, vu les outils déjà utilisés, quitte à changer de langage côté front on partirait plutôt sur quelque chose comme Kotlin (on a déjà du Java et du .NET, mais pas de Python).
La connaissance libre : https://zestedesavoir.com
[^] # Re: "WIP"
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal The Minimum Viable Pull-request. Évalué à 5.
« Work In Progress » = « Travail en cours » et non « Travail en progrès ».
La connaissance libre : https://zestedesavoir.com
# Premiers résultats
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [Écriture][Art libre] Bilan d'Inktober 2018 en textes. Évalué à 2.
En tous cas merci aux personnes qui ont pris la peine de répondre à mon petit questionnaire, c'est très pratique pour moi.
Sur le peu de résultats que j'ai pour l'instant, j'ai pas d'énormes surprises (du type un texte que je n'aimerais pas du tout mais vous oui ou inversement), mais quelques classements auxquels je ne m'attendais pas (plutôt du type « texte que je trouvais moyen mais que vous aimez bien », et inversement).
Je note aussi qu'il y a peu de textes vraiment clivants, ce qui est pratique pour moi. Et que le mieux noté est celui qui parle de cul… (je ne donne volontairement pas d'indications sur les autres votes pour ne pas influencer).
En tous cas n'hésitez pas à répondre, c'est vraiment très utile de mon point de vue !
La connaissance libre : https://zestedesavoir.com
[^] # Re: Contentoob ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal scraplap, pour mouler offline. Évalué à 7. Dernière modification le 06 novembre 2018 à 11:30.
À propos de weboobs…
La connaissance libre : https://zestedesavoir.com
[^] # Re: Justifier
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal scraplap, pour mouler offline. Évalué à 5.
Justifier sur un téléphone (ou plus généralement sur une colonne étroite) est une mauvaise pratique, sauf en cas de gestion propre des césures – ce que ne font pas les navigateurs. Parce que dans ce cas, certes c'est plus joli, mais bien moins lisible à cause des espaces entre mots qui peuvent devenir énormes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: [HS][Tech][#jepreferelescrochetsquelesdieses]
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [Écriture][Art libre] Bilan d'Inktober 2018 en textes. Évalué à 10. Dernière modification le 05 novembre 2018 à 10:44.
Encore une fois, qu'est-ce que tu imaginais en postant ce message ?
Concrètement, libérer ce code, c'est :
La solution 2 doit prendre une dizaine de minutes, donc c'est vraiment de la flemme. Mais à quel moment ton premier commentaire était censé me motiver pour faire ça ? Relis-le, tu verras que le vocabulaire et le ton n'incitent pas à l'action ou à la discussion.
Quant au premier HS sur la technique, il concerne un point spécifique à ce qui est présenté (mon site, indirectement). La discussion sur « il faut tout libérer », on l'a déjà lue un peu partout sur ce site.
La connaissance libre : https://zestedesavoir.com
[^] # Re: [HS][Tech][#jepreferelescrochetsquelesdieses]
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [Écriture][Art libre] Bilan d'Inktober 2018 en textes. Évalué à 10.
J'ajoute que ton message est en réalité doublement toxique :
La connaissance libre : https://zestedesavoir.com