Parce que je n'avais pas de valeur de comparaison pertinente : dans l'immense majorité des cas, le processeur est en fin de vie non pas parce qu'il est intrinsèquement hors service, mais parce qu'il est dépassé pour l'usage qui en est fait par du matériel plus récent (puissance supérieure, consommation inférieure, processeur encore OK mais plus les composants autour…)
Parce que du coup on se retrouve avec un problème d'échelle dans le sens inverse : 5 ans réels en nanosecondes, c'est 1,6 x 1017 donc l'équivalent, comme tu le dis, c'est 5 milliards d'année, une durée que personne ne se représente vraiment.
D'autant que les échelles de vie et de réactivité ne sont pas les mêmes : tu pourrais te dire que sur 5 milliards d'année tu pourrais te permettre sans souci de passer 100 ans sur un calcul en tant que processeur ; mais ça serait l'équivalent de plus de 3 secondes pour un utilisateur… donc probablement beaucoup trop long.
Non mais tu fais bien ce que tu veux de mes retours, comme dit en début de message, il n'engage que moi… Mais c'est sûr que si tu n'attends que des retours de professionnels du milieu avec des contre-propositions de design, il ne faut pas demander l'avis des gens. Parce que ce n'est pas comme ça que fonctionne le logiciel libre, tu es mainteneur de ton application, c'est à toi d'en assurer la maintenance, pas d'exiger que toute critique se fasse à grands coups de screenshots (ce qui ça aussi prends du temps, figure-toi que les gens qui veulent utiliser ton application n'en ont pas forcément).
C'est d'autant plus dommage que j'ai essayé d'être factuel : je n'ai jamais critiqué ce qui est du ressenti pur, comme les polices ou les couleurs (tant que les couleurs sont lisibles). De plus, il y avait une proposition en creux derrière chaque point que j'ai soulevé ; je n'ai pas le temps tout de suite mais je peux tout à fait te les expliciter. Tout ce que je dis, c'est ce qui m'est passé à l'esprit en arrivant sur ton site. Notamment le coup des onglets : aussi mal que ça puisse te faire, je n'ai véritablement pas compris du premier coup que c'en était. Ce n'est pas pour ça que je saurais te dire exactement ce qu'il faut corriger pour améliorer ça.
Je n'ai pas le temps maintenant, mais je le prendrai volontiers dans la journée pour expliciter chaque proposition derrière chaque ligne.
Après, libre à toi de faire comme toute personne de bonne volonté face à une critique plus détaillée que « c'est moche » : tu reprends les points, et tu décides si :
C'est effectivement un problème et tu le corriges (et tu n'as pas à attendre que la personne le fasse pour toi, c'est ton logiciel après tout),
C'est effectivement améliorable mais trop compliqué / trop spécifique / whatever donc ça restera en l'état,
À l'époque révolue où je perdais mon temps sur Mastodon, à chaque fois que je postais une capture de Pétrolette, il se créait carrément des fils de discussion entiers sur le mode "c'est moche, je l'utiliserai si c'était plus joli, mais c'est moche" d'où ne ressortait ja-mais aucune proposition concrète.
Je n'utilise plus Mastodon mais… pour une fois je suis d'accord avec les commentaires qui en ressortent. Et parce que je ne suis pas un chien qui va te dire « c'est moche » sans précision, voici une liste personnelle et non exhaustive de ce qui ne va pas, selon mon avis personnel.
La première chose que je remarque, c'est qu'il y a tellement de détails qui ne vont pas que c'est long et fastidieux d'en faire la liste, ce qui limite effectivement l'envie de faire des propositions concrètes. En gros, le problème c'est que tu ne respecte pas les règles classiques de design et d'ergonomie, ce qui fait qu'en arrivant sur ton site on est perdus dans son interface.
Et donc, sous Linux Mint 19 avec un Chromium à jour et sans ordre précis :
Les boutons ne ressemblent pas à des boutons.
Les styles des différents composants est incohérent selon les composants.
Le système d'onglets, je n'ai pas compris à l'origine que c'était des onglets, et une fois que j'ai compris ça je pensais qu'ils ne s'appliquaient qu'à la première colonne.
Les marges sont incohérentes : parfois elles sont presque inexistantes (autour du titre, des images, des textes dans les listes), parfois elles sont classiques (onglets), parfois elles sont énormes (boutons de gestion des colonnes).
Dans les colonnes, le texte et l'image sont déséquilibrés.
Pourquoi il y a une grosse bordure pointillée autour des boutons de gestion des colonnes ? J'imagine que s'il y a un élément de design spécifique c'est que ça correspond à un comportement spécifique, non ?
Au survol des éléments de liste, le texte devient rouge sur fond sombre, ce qui est difficile à lire.
L'icône « pointillés verticaux » de déplacement d'un bloc-flux n'est ni une icône standard pour ce genre de manœuvre, ni à un endroit habituel pour ce faire.
Pourquoi l'icône de repliement du flux n'apparait qu'au survol du titre à la place de l'icône du flux ?
Les zones d'action sont parfois énormes (bouton d'ajout d'un flux), et parfois microscopiques (suppression d'un onglet)
(onglet « music ») Il n'y a aucune différence claire entre un bloc de flux déplié et un bloc de flux vide.
Le design est incohérent avec lui-même : par exemple les croix de fermetures sont différentes selon le contexte (celle des onglets, celle des popins).
Pour ajouter un flux j'ai une icône « lampe torche ». Ce n'est pas un symbole habituel ou évident, il n'y a pas de tooltip pour me dire ce que fait ce bouton, donc je ne sais pas ce que peut faire cette action.
Les boutons ont une largeur incohérente : parfois le bouton est adapté à une largeur d'interface (ajouts de colonnes, types de flux dans la popin), parfois il est adapté au contenu (boutons d'annulation / validation de la popin).
Pourquoi les boutons d'édition / suppression / sélection d'un flux ne s'affichent qu'au survol du bouton « rafraîchir » ?
D'ailleurs, qu'est-ce que « sélectionner un flux » et pourquoi cette icône ?
Dans les titres des flux, le texte de l'URL est décentré vers le haut, mais les icônes de flux et de rafraichissement sont décentrées vers le bas.
On est vraiment censés lire les prévisualisations du contenu des éléments des flux dans des tooltips (en plus elles ont le design standard du système, qui est incohérent avec le reste de ton style).
Voilà, je pourrais continuer mais je pense que c'est déjà suffisant
Dans ce cas c'est les deux phrases au singulier que je ne comprends pas. Si on parle bien de deux personnes, ça devrait être « En fait, c'est pour les 20 ans de [deux] très bon·ne·s ami·e·s ! » (ou quoi que ce soit de plus élégant) et « deux ou trois de leurs invité·e·s geeks libristes ».
En fait, c'est pour les 20 ans d'un·e très bon·ne ami·e !
Je sais que je suis complètement hors sujet, mais je ne peux pas m'empêcher de m'interroger sur cette phrase : quelle que soit la façon dont j'essaie de déplier les points médians, j'arrive à une erreur de syntaxe. Mes hypothèses sont :
C'est quelqu'un dont tu ne veux pas donner le genre (un peu lourde pour un intérêt que je comprends mal, mais admettons) ;
C'est quelqu'un dont tu ne connais pas le genre (mais si c'est un ou une amie proche, c'est étonnant) ;
C'est quelqu'un de non-binaire (mais c'est une utilisation maladroite du point médian, toutes les personnes que je connais dans ce cas donnent les pronoms qu'elles veulent voir utiliser, que ces pronoms existent ou soient inventés pour l'occasion) ;
C'est un réflexe malheureux à force de mettre des points médians un peu partout ;
Autre chose que je n'ai pas compris.
Si tu avais l'occasion d'éclairer ma lanterne sur cette utilisation du point médian qui m'était encore inconnue, je t'en serais reconnaissant.
(Note que le « deux ou trois de ses invité·e·s geeks libristes » ne me pose pas de problème de compréhension, lui me semble logique)
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.
[^] # Re: durée de vie
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le microprocesseur, ce monstre de puissance qui passe son temps à attendre. Évalué à 7.
Je ne l'ai pas mis pour deux raisons :
Parce que je n'avais pas de valeur de comparaison pertinente : dans l'immense majorité des cas, le processeur est en fin de vie non pas parce qu'il est intrinsèquement hors service, mais parce qu'il est dépassé pour l'usage qui en est fait par du matériel plus récent (puissance supérieure, consommation inférieure, processeur encore OK mais plus les composants autour…)
Parce que du coup on se retrouve avec un problème d'échelle dans le sens inverse : 5 ans réels en nanosecondes, c'est 1,6 x 1017 donc l'équivalent, comme tu le dis, c'est 5 milliards d'année, une durée que personne ne se représente vraiment.
D'autant que les échelles de vie et de réactivité ne sont pas les mêmes : tu pourrais te dire que sur 5 milliards d'année tu pourrais te permettre sans souci de passer 100 ans sur un calcul en tant que processeur ; mais ça serait l'équivalent de plus de 3 secondes pour un utilisateur… donc probablement beaucoup trop long.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et la RAM ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le microprocesseur, ce monstre de puissance qui passe son temps à attendre. Évalué à 3. Dernière modification le 22 novembre 2018 à 09:32.
J'avoue, je n'ai pas donné la correspondance dans le langage informatique « habituel » pour ce point.
La connaissance libre : https://zestedesavoir.com
[^] # Re: peut en en deduire
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Libre mais.... moche ?. Évalué à 9.
Non mais tu fais bien ce que tu veux de mes retours, comme dit en début de message, il n'engage que moi… Mais c'est sûr que si tu n'attends que des retours de professionnels du milieu avec des contre-propositions de design, il ne faut pas demander l'avis des gens. Parce que ce n'est pas comme ça que fonctionne le logiciel libre, tu es mainteneur de ton application, c'est à toi d'en assurer la maintenance, pas d'exiger que toute critique se fasse à grands coups de screenshots (ce qui ça aussi prends du temps, figure-toi que les gens qui veulent utiliser ton application n'en ont pas forcément).
C'est d'autant plus dommage que j'ai essayé d'être factuel : je n'ai jamais critiqué ce qui est du ressenti pur, comme les polices ou les couleurs (tant que les couleurs sont lisibles). De plus, il y avait une proposition en creux derrière chaque point que j'ai soulevé ; je n'ai pas le temps tout de suite mais je peux tout à fait te les expliciter. Tout ce que je dis, c'est ce qui m'est passé à l'esprit en arrivant sur ton site. Notamment le coup des onglets : aussi mal que ça puisse te faire, je n'ai véritablement pas compris du premier coup que c'en était. Ce n'est pas pour ça que je saurais te dire exactement ce qu'il faut corriger pour améliorer ça.
Je n'ai pas le temps maintenant, mais je le prendrai volontiers dans la journée pour expliciter chaque proposition derrière chaque ligne.
Après, libre à toi de faire comme toute personne de bonne volonté face à une critique plus détaillée que « c'est moche » : tu reprends les points, et tu décides si :
C'est ce que j'ai appliqué comme méthode pour mon propre site, et il me semble que ça a pas mal fonctionné, alors que mes compétences en design sont proche du 0 absolu.
Bref, c'est d'autant plus dommage que tu te braques comme ça que je suis intéressé par un bon lecteur de flux RSS.
PS : je veux bien que tu m'expliques en quoi mon message est « bourré de fautes ». Antidote me détecte :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Chipotage
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le microprocesseur, ce monstre de puissance qui passe son temps à attendre. Évalué à 8.
Exact et la précision est toujours bienvenue même pour ce genre d'exercice.
La connaissance libre : https://zestedesavoir.com
[^] # Re: peut en en deduire
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Libre mais.... moche ?. Évalué à 7.
Je n'utilise plus Mastodon mais… pour une fois je suis d'accord avec les commentaires qui en ressortent. Et parce que je ne suis pas un chien qui va te dire « c'est moche » sans précision, voici une liste personnelle et non exhaustive de ce qui ne va pas, selon mon avis personnel.
La première chose que je remarque, c'est qu'il y a tellement de détails qui ne vont pas que c'est long et fastidieux d'en faire la liste, ce qui limite effectivement l'envie de faire des propositions concrètes. En gros, le problème c'est que tu ne respecte pas les règles classiques de design et d'ergonomie, ce qui fait qu'en arrivant sur ton site on est perdus dans son interface.
Et donc, sous Linux Mint 19 avec un Chromium à jour et sans ordre précis :
Voilà, je pourrais continuer mais je pense que c'est déjà suffisant
La connaissance libre : https://zestedesavoir.com
[^] # Re: Besoin?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au message Modèle de trottinettes et/ou vélo électrique. Évalué à 2.
Dans ce cas c'est les deux phrases au singulier que je ne comprends pas. Si on parle bien de deux personnes, ça devrait être « En fait, c'est pour les 20 ans de [deux] très bon·ne·s ami·e·s ! » (ou quoi que ce soit de plus élégant) et « deux ou trois de leurs invité·e·s geeks libristes ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Besoin?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au message Modèle de trottinettes et/ou vélo électrique. Évalué à 7.
Je sais que je suis complètement hors sujet, mais je ne peux pas m'empêcher de m'interroger sur cette phrase : quelle que soit la façon dont j'essaie de déplier les points médians, j'arrive à une erreur de syntaxe. Mes hypothèses sont :
Si tu avais l'occasion d'éclairer ma lanterne sur cette utilisation du point médian qui m'était encore inconnue, je t'en serais reconnaissant.
(Note que le « deux ou trois de ses invité·e·s geeks libristes » ne me pose pas de problème de compréhension, lui me semble logique)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les priorité
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Libre mais.... moche ?. Évalué à 3.
Ça ne fonctionne que si tu as un historique virtuellement illimité des modifications (cf ce que font les IDE JetBrains).
La connaissance libre : https://zestedesavoir.com
[^] # Re: perf de Timeshift en mode 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.
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: sauvegardes et points de restauration
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é à 3.
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é à 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