Beaucoup de gens semblent mélanger modèle de développement et droits sur le code.
Ça m'étonnera toujours.
On peut faire du non libre coopératif (bizarre, mais bon, possible, c'est ce qui se faisait sur le compilateur D dmd avant qu'il ne soit en effet libéré. Ou sur le compilateur sybase du bios de virtualbox. Ou probablement sur tous ces modèles LLM open pas vraiment open. Ou probablement plein de mods de jeux vidéos à licences pas forcément ouvertes voire très claires), et du libre non collaboratif (Des exemples ont été donnés ici, SQLite en est un autre : c'est dans le domaine public dans les juridictions qui permettent de déposer volontairement des choses dans le domaine public, mais ces auteurs ne prennent pas les contributions externes).
Ce genre de confusion de la part d'auteurs de logiciels, ça donne sérieusement l'impression d'un manque de culture dans le monde du développement, et ça fait penser que les décisions ne sont potentiellement pas super bien éclairée.
Je viens de participer à la première édition d'AlpOSS (c'était top !) et un intervenant disait "faut voir aussi l'utilité de mettre une application en open source". Il pensait en terme de développement, mais les droits garantis aux utilisateurs et utilisatrices finales de l'application, c'est déjà une utilité largement suffisante… et même la raison principale qui me motive moi à faire du libre. Je n'ai pas osé intervenir mais c'était un point important, j'aurais peut-être dû.
Les questions de l'open source et des modèles de développement ne sont pas encore assez enseignées dans les écoles d'informatique, et il n'y a pas assez d'information là dessus auprès des dev en poste. Mais bon, ça progresse.
J'imagine que les messages sont rendus par des composants avec des couches d'abstractions sur couches d'abstractions s'empilant les unes sur les autres… (par exemple pour gérer des types de messages subtilement différents, ou des configurations différentes ; et en React ou framework similaires, on n'hérite pas, on compose, donc ça s'ajoute - je ne sais pas ce que WhatsApp utilise) et chaque couche rajoute son div. Et ensuite il y a peut-être un outil qui nettoie les classes HTML non utilisées mais qui laisse les div, ou quelque chose du genre.
Pour Wix je ne peux qu'imaginer un editeur wysiwyg custom qui ajoute connement un span style="XXX" pour chaque style XXX, sans essayer de combiner les spans. J'ose espérer que désactiver un style retire le span correspondant et n'en ajoute pas un qui annule la règle CSS par une autre opposée…
Tout argument pour réduire la consommation des ressources est bon à prendre, et "plus rapide à charger" veut souvent dire amélioration de la consommation des ressources. Mais pas toujours (tu peux toujours faire un premier affichage rapide et envoyer 10 méga de merdasse à parser et exécuter ensuite, c'est d'ailleurs un peu le problème), et ça ne doit vraiment toucher que les très grosses boites. Je pense que si tu peux mesurer du manque à gagner à cause d'une seconde de chargement en plus, tu as déjà un bon nombre de clients… La plupart des boites ne sont pas comme ça je pense.
Dans tous les cas, ce serait cool que les gens et les boites soient sensibles directement à l'écologie, l'accessibilité, et le respect des gens et optimisent pour ces choses, plutôt que devoir passer par l'argument intermédiaire imparfait du profit. Mais bon, je suis peut-être idéaliste.
Posté par raphj .
En réponse au journal [HS] 3 Gigas par semaine ....
Évalué à 6 (+4/-0).
Dernière modification le 19 mars 2024 à 11:05.
Il y a des avantages théoriques à travailler un algorithme d'abord sur papier :
on se concentre théoriquement mieux sur papier que devant un écran
on évite de se précipiter sur le code et tenter des trucs un peu à l'aveuglette, au profit d'une réflexion plus profonde
on évite de galérer avec les détails non pertinent comme la syntaxe précise du langage de programmation
Je pense que c'est notamment pour ces raisons qu'on demande aux étudiants de réfléchir sur du papier. Ça peut être bien pendant l'apprentissage, pour séparer les difficultés.
Il y a aussi le fait que pour des raisons pratiques / économiques, les cours sont découpés en Amphi, TD, TP. Il est commode de faire réfléchir en TD et de mettre en pratique en TP, et lors des TD, il n'y a (en général ? avait ?) pas d'ordinateur.
Maintenant, perso, je n'aimais pas trop réfléchir sur du papier pendant les cours, et surtout devoir utiliser la syntaxe précise et arbitraire imposée par le cours d'algo du jour. Chaque cours ayant bien sûr ses notations, sinon ça ne serait pas drôle. Ça perd l'intérêt de pouvoir se détacher de la syntaxe.
Ça m'arrive quand-même de temps en temps d'utiliser du papier pour réfléchir à des algos compliqués.
C'est probablement très peu pertinent dans la majorité des cas où on écrit de la glue et où la difficulté n'est pas "comment résoudre théoriquement le problème", mais "comment écrire la solution dans le langage, dans le framework et avec les bibliothèques logicielles à disposition".
C'est plutôt facile, tu écris le code, tu écris les tests, tu remplis le Cerfa qui va bien et tu l'envoies à la région Auvergne-Rhône-Alpes en RLAR pour que Najat tape et exécute ton code. Ce service a été mis en place pour ton bien-être et pour réduire ton temps d'écran.
Le Cerfa, une centaine de pages pour la version courte, mais on prend l'habitude, décrit exactement la procédure de construction et d'exécution des tests, ainsi que l'adresse postale où les résultats des tests doivent être livrés. Ça permet de simplifier un peu les processus et c'est une première étape vers les builds reproductibles. Le truc pénible c'est qu'il ne faut pas oublier de joindre un timbre fiscal et une enveloppe vierge, mais ça aussi on s'y fait.
Le plus rigolo, c'est des assertEquals sur des fichiers XML de 5 Mio, ça demande d'envoyer des cartons, et on se fait livrer les résultats par Colissimo. Mais du coup en général on essaie de réduire les tests au minimum, on ne laisse pas trainer des choses inutiles.
Pareil pour le code, ça a l'avantage de rendre la prod très légère au final.
Une annexe du Cerfa permet de donner des instructions de mise en production en cas de résultats de tests concluants, mais du coup il faut éviter d'envoyer la lettre recommandée à un moment où, tenus compte du délai de la poste, du temps de saisie et d'exécution des tests, ceux-ci finiraient de s'exécuter un vendredi, parce qu'on ne veut pas d'une mise en prod un vendredi, évidemment.
Mais c'est pas mal, ça permet d'aller à l'essentiel et ça fait une prod plus légère en général.
le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement
Normalement, si le fichier journal bouge, il faudra que l’utilisateur mette à jour manuellement le fichier de configuration. Le bloc en question (lignes 27 à 37) n’est appelé que pour la première configuration …et donc JOURNAL_FILE n’est plus modifié ;)
J'utilise des guillemets simples, les variables ne sont donc pas interprétées à la création du fichier de configuration. Elle sont interprétées à chaque exécution. Donc ça devrait marcher tout seul, l'utilisateur n'aura pas besoin de mettre à jour son fichier de configuration manuellement s'il XDG_DOCUMENTS_DIR était défini lors de la création du fichier de configuration et que le journal reste à tout moment dans XDG_DOCUMENTS_DIR :-)
C'est l'intérêt de mon code un peu plus complexe qu'il ne pourrait l'être.
Je n'ai plus qu'à trouver pourquoi je n'ai pas XDG_DOCUMENTS_DIR, et éventuellement rapporter un bug auprès de mon environnement de bureau ou de ma distrib.
par quelque chose comme :
Exactement, c'est ce que je comptais faire mais tu m'as battu :-) Je commiterai probablement dans la journée.
Je vois comment cette construction fonctionne mais on est ici dans une partie du script qui écrit un chemin dans un fichier de configuration et ça a des implications spécifiques.
Cette dernière version que tu proposes ne respecte pas XDG_DOCUMENTS_DIR si elle existe. Or, je pense qu'il faut la privilégier par rapport au chemin "plan B" hardcodé.
Ensuite, je veux que le fichier journal ne bouge pas d'endroit si XDG_DOCUMENTS_DIR venait à devenir définie sur mon système.
Cependant, je peux imaginer que quelqu'un déplacerait ses dossiers standard et trouver raisonnable que L suive automatiquement (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement). C'est un cas qu'on ne peut raisonnablement prendre en charge que si XDG_DOCUMENTS_DIR est définie au moment de la création du fichier de config, sauf à faire de la magie dans le fichier de config et je ne suis pas très fan de ça.
Sans ça, hardcoder le chemin du fichier journal dans le fichier de config serait mieux, le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement (mais difficile de faire comme ça et permettre le renommage de ces dossiers standard).
Et j'ai utilisé la syntaxe pour se rabattre sur HOME si XDG_DOCUMENTS_DIR venait à ne plus être définie mais en réalité ce n'est pas terrible. Il faudrait certainement éviter cette syntaxe dans le fichier de configuration. Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre. Et en même temps, je veux vraiment éviter de stocker des chemins qui sortent du HOME dans une config autogénérée dans la mesure du possible. Évidemment, si HOME n'est pas défini, all bets are off, mais aussi ça me parait terriblement peu probable.
Voilà l'explication de mes choix. Ce n'est pas parfait parce que c'est le résultat de compromis subtiles.
Merci, c'est commité ! J'ai retiré le dollar en trop, et tant qu'à faire le point virgule que j'avais laissé là pour aucune raison valable. J'ajoute cette substitution dans ma boite à outils shell pour le futur. Je ne pensais pas avoir une contribution aussi vite après une annonce caché dans un commentaire sur un script sans grande importance xD.
Pourquoi avoir nommé le fichier de configuration Ljournalrc plutôt que Lrc ? Je ne me souviens plus, mais je vois trois raisons qui me pousseraient à reprendre la même décision aujourd'hui :
Clarté : Lrc dans la listes des fichiers dans .config serait potentiellement cryptique. C'est beaucoup plus facile de percuter avec Ljournalrc.
Éviter les clashs : si tout le monde appelle son petit script avec une lettre, ça va vite devenir la foire.
Nom du « projet » : J'avais peut-être, pour ces deux raisons, pensé le nom du projet comme Ljournal plutôt que simplement L, mais opté pour L pour le nom du script. Aujourd'hui, j'appellerais peut-être plutôt le script Ljournal et suggérerais aux gens de mettre en place un lien ou un alias nommé L. Et c'est peut-être ce que je ferai si jamais un jour je m'embête à mettre en place un processus d'installation. Pour l'instant, cette responsabilité repose sur la personne qui va réutiliser mon code.
En général oui. Sinon, je commence avec la première ligne et je complète en ouvrant l'éditeur, donc c'est toujours daté. Il est également possible de prendre en note l'entrée standard : Je lance L - et je tape ou je colle plusieurs lignes et CTRL+D pour finir la note. L e permet ensuite de corriger des choses si besoin. L + et L + - permettent aussi de compléter la dernière note.
Rien n'empêcherait d'enregistrer ces notes dans un système plus complexes que ce bête fichier texte :-)
Je vis pas mal dans le terminal et je suis brouillon. J'ai parfois besoin de noter un truc en vitesse sans friction pour être sûr de ne pas le perdre, pour finalement souvent ne jamais y retourner, mais au moins c'est consigné xD
Du coup, j'ai un petit script écrit en plus ou moins une fois (vous savez, ces hacks qui deviennent définitifs ?) que j'utilise depuis des années (y compris quand j'étais à Algoo :-)).
Son utilisation est simple : dans le terminal, je tape L, puis ce que je veux noter.
L une note
Ça ajoute une entrée dans un fichier texte synchronisé avec Nextcloud, avec la date.
On peut consulter le journal en tapant L. Ça ouvre le fichier avec less (ou autre outil configurable), et comme les notes les plus récentes sont en haut du journal, c'est plutôt pratique.
Une entrée :
Fri, 23 Feb 2024 22:09:36 +0100:
Une note
Et on peut appeler l'éditeur de texte de son choix sur le journal avec L e.
L'aide de l'outil :
Usage:
L - show the content of the journal
L message - add message to the journal, with a date
L + message - add message to the previous entry in the journal
L - - add stdin to the journal
L + - - add stdin to the journal, without a date
L e - edit the journal manually
L h, L -h - show this help
Config file is in /home/raph/.config/Ljournalrc
Ça supporte les étiquettes de la manière la plus débile possible : il suffit d'ajouter "l'étiquette" à la ligne de cette manière : [tag], et une recherche dans le fichier la retrouvera.
Bien sûr, personne ne l'utilisera, parce que chacun a sa manière de prendre ses petites notes, voire de réinventer son outil. Sinon il y a les gens organisés qui écrivent des notes markdown et qui parfois même font des liens entre les notes. Moi, ça m'explose le cerveau xD.
J'ai abandonné l'idée d'utiliser un outil plus complexe que L depuis longtemps. Il faut que l'outil soit discret et immédiat (aucun lag possible, ça peut tuer une pensée. Ça a tendance à marcher sur les smartphones que je peux utiliser aussi (avec Termux sous Android, ou de manière native sur un mobile Linux). C'est extrêmement user-friendly… pour moi. Finalement, ça fait le taf et c'est rentré dans mes habitudes. Je pourrais améliorer ça un peu et respecter un peu la syntaxe Markdown maintenant que Nextcloud prend ça en charge nativement.
Et sinon, pour les gens qui utilisent un shell avec une gestion sensée de l'historique (comme zsh), un petit # avec la note dans la suite marche aussi. C'est un commentaire en shell et ça reste dans l'historique, et ça ne nécessite aucune installation. Mais gare aux historiques corrompus, ça a pu m'arriver de temps en temps.
En tout cas j'espère que vous aurez du succès avec cette nouvelle fonctionnalité de Tracim :-) C'est une bonne idée, et c'est plutôt malin.
Posté par raphj .
En réponse au journal Atlassian SaaS....
Évalué à 4 (+2/-0).
Dernière modification le 14 février 2024 à 07:42.
Je ne saurai parler pour cette entreprise, mais je pense que la question de GitLab n’est pas par rapport à Confluence mais plutôt par rapport à BitBucket et éventuellement Jira (si ça ne fait que des tickets et Epic liés aux codes.)
Ah oui :-)
Il y a aussi OpenProject comme alternative à Jira, en général les gens ont des utilisations complexes de Jira pour lesquelles GitLab peut être un peu léger.
On utilise malheureusement beaucoup Jira, on utilise déjà GitLab pour l'hébergement des projets clients et pour certaines choses pour lesquelles on utilisait Jira, et on est en train d'évaluer OpenProject pour d'autres usages.
Sauf si XWiki fait aussi forge Git
Au secours xD non, je ne parlais que de Confluence.
Posté par raphj .
En réponse au journal Atlassian SaaS....
Évalué à 10 (+8/-0).
Dernière modification le 14 février 2024 à 02:15.
Rester sur Confluence, ça permet de garder le contenu et de ne pas reformer tout le monde à un nouvel outil. C'est un choix naturel.
Mais les nouveaux tarifs et les changements de conditions liées à l'auto-hébergement ne conviennent pas à tout le monde. Beaucoup d'organismes migrent en ce moment vers XWiki et je travaille en ce moment à quasi plein temps sur ces migrations, notamment et en particulier sur les outils de migrations et sur l'accompagnement des clients sur l'aspect migration. Je me retrouve soudainement expert du format d'export Confluence malgré moi. Ou plutôt, comme écrirait le collègue qui a le plus travaillé sur ce code, "format" (avec les guillemets).
Si ta boite venait à revenir sur sa décision de passer au cloud d'Atlassian, c'est une solution possible, libre et auto hébergeable. On accompagne ces migrations au besoin. C'est surtout nécessaire pour la migration de gros wikis. Et on peut former les gens.
Je peine à imaginer une migration vers GitLab ou Gitea, c'est tellement différent… Oui, il y a une fonction de wiki sur ces outils, mais c'est beaucoup plus léger. J'imagine bien commencer une base de connaissances from scratch avec ça, surtout si c'est déjà en place, mais vous utilisez Confluence et ça fait tellement plus. Une migration vers GitLab ne peut probablement fonctionner sans perdre du contenu que si vous avez une utilisation ultra basique de Confluence sans trop utiliser de macros, le système de permissions, etc. Et aussi, si vous avez des outils pour transférer le contenu vers ces plateformes. Migrer vers XWiki, ça ne marche pas trop mal parce que :
la plupart des fonctionnalités et des concepts de Confluence ont leur équivalent dans XWiki (contenus, espaces, commentaires, pièces jointes, macros, formatage du texte, tags, utilisateurs, groupes, permissions… tout ne mappe pas parfaitement mais il y a déjà de quoi faire)
on peut convertir la syntaxe Confluence vers celle d'XWiki sans trop de perte et qu'on peut réimplémenter beaucoup de leurs macros (même plus tard après la migration) pour retrouver la plupart des fonctionnalités.
Dans tous les cas, je ne peux qu'espérer pour ta boite qu'elle fera le choix de récupérer le contrôle de sa base de connaissance (avis perso : idéalement libre, idéalement hébergé chez vous), peut importe l'outil.
Je fais un peu de pub, difficile de résister, c'est pile dans mon quotidien du moment :-)
Ouais, mais derrière un drapeau expérimental (pas activé par défaut). Ça n'encourage pas l'adoption. C'est presque comme si l'accès au pont était barré, pour reprendre la comparaison évoquée par un autre commentaire.
Oui, c'est vrai. Entre autres il y a eu un peu de "comme les mecs n'étaient pas dispo parce que partis en guerre, on a accepté que les nanas sortent de leur foyer pour que le pays ne s'écroule pas complètement".
J'imagine aussi que ça peut être des questions de coûts de maintenance.
Je n'ai jamais vu de JPEG-XL sur le web
Peut-être parce que ça n'est pas pris en charge sur Chrome et Firefox justement, parce que sinon, vu de loin avec un œil distrait, c'est plutôt séduisant, je me pencherais probablement sur la question perso.
Tu fais des raisonnements circulaires et des appels à la nature.
Tes utilisations de "c'est évident que", "il est indéniable que" sont un témoin criant que ta démonstration est fragile.
On observe des différences et des tendances notables entre des catégories de gens : les femmes et les hommes. Maintenant, tout le travail consiste à savoir pourquoi. (et encore, je n'aborde pas la question des trans, non-binaires, intersexes et plus généralement des personnes pour qui sexe ≠ genre ou qui ne se reconnaissent pas dans la catégorie "femme" ni dans la catégorie "homme").
Ta thèse c'est : "pour des raisons biologiques". La thèse que tu réfutes (implicitement ?) c'est : "à cause de biais causés par des constructions sociales".
Observer les différences ne suffit pas à appuyer ta thèse et à réfuter l'autre. Il va donc falloir sortir de l'intuitif, qui est un mode de pensée très pratique qui permet de prendre des raccourcis, d'aller vite, d'être efficace et qui marche plutôt bien mais pas toujours, et enclencher un mode de réflexion plus posé, construit, rigoureux et scientifique. Ton commentaire démontre aussi un manque de documentation sur le sujet. Autrement dit, no offense mais tu raisonnes sans savoir donc on est plus sur le domaine de la croyance.
elle n'ont pas les mêmes goût que les hommes (En général, pas toutes/tous) et cela suffit à expliquer la différence dans nos sociétés occidentale
Non, parce que tu n'as pas expliqué ces différences de goût.
ou la discrimination sexuelle est extrêmement limité dans le domaine de l'éducation
C'est malheureusement faux. À cause de mécanismes parfois très subtiles du style les profs ont plus tendance à poser des questions ouvertes aux mecs et des questions oui/non aux nanas sans même le vouloir. On attend d'un mec qu'il soit plus créatif et on tolère plus qu'il soit pénible et dissipé, et on attend plus d'une nana qu'elle soit sage et disciplinée. Ça explique aussi en partie les meilleurs notes des filles à l'école. On pousse plus les nanas à faire des études littéraires ou sociales que scientifiques pour aucune bonne raison.
Il y a tellement de cas ou les femmes montrent plus d'attrait pour le contact humain, pour le mignon et les hommes pour la technique et la force/violence que je ne comprends pas que ce soit négligé voir nié.
Mais pourquoi ? C'est tout l'enjeu. N'est-ce pas parce qu'on apprend (plus ou moins volontairement) aux petits garçons qu'il faut être fort et aux petites filles qu'il faut être attentifs aux autres, tendre, etc dès le plus jeune âge ? Que ce soit les parents, la société, etc ? Aka construction sociale ? On habille les filles en rose et les garçons en bleu. Sûrement, ça n'a rien à voir avec des choix et des goûts quand on est bébé, on n'a pas encore la carte de crédit pour aller s'acheter nos vêtements nous-même à cet âge ni même les capacités communicationnelles pour exprimer ses préférences sur la question. Non, la société fait sans arrêt des choix genrés pour nous. Ces différences de couleurs qu'on nous impose tout petit est un seul aspect discriminatoire, très évident, parmi les nombreux présents dans la société, variés et parfois subtiles. Ou alors, comment expliques-tu ce genre de différences ?
Par ailleurs, comment expliques-tu que l'informatique, début-milieu 20ème siècle était plutôt mixte, voire majoritairement féminine ? (les personnes qui ont travaillé sur l'ENIAC par exemple, plein de femmes là dedans !). Et pourquoi ça a changé maintenant ?
Peut-être qu'il y a des différences biologiques qui expliquent certaines choses. Peut-être qu'elles expliquent des rapports de domination et des chaines de réactions sociales qui mènent à ces différences qu'on observe dans la société qui n'ont rien avoir avec des différences fondamentales qui causent des appétences différentes. Ou peut-être pas.
On ne peut pas balayer ces problèmes de discriminations et d'inégalités sous le tapis de l'explication biologique et naturelle. Ce tapis est peut-être confortable pour une partie de la population, mais c'est probablement un peu beaucoup une illusion, ou bien existant mais beaucoup plus fin que prévu.
Et dans tous les cas, on a bien un soucis d'égalité à régler, à commencer par les revenus.
Oui, tu as la pile d'appel. Elle est stockée dans la stack, à laquelle le débogueur a accès.
Un (hardware) watchpoint devrait se comporter exactement comme un breakpoint, l'exécution du programme est stoppée par une interruption, à ceci près qu'aucune instruction n'est remplacée par un truc du genre int 3, le processeur prévient l'OS qu'un accès en lecture ou en écriture a eu lieu sur la case mémoire demandée. Et l'OS prévient le débogueur.
[^] # Re: GUI pour python.
Posté par raphj . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 5 (+3/-0).
Félicitations pour Slint, mais… outch, les gros sabots xD.
[^] # Re: Wut?
Posté par raphj . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 5 (+4/-1). Dernière modification le 23 mars 2024 à 14:19.
Beaucoup de gens semblent mélanger modèle de développement et droits sur le code.
Ça m'étonnera toujours.
On peut faire du non libre coopératif (bizarre, mais bon, possible, c'est ce qui se faisait sur le compilateur D dmd avant qu'il ne soit en effet libéré. Ou sur le compilateur sybase du bios de virtualbox. Ou probablement sur tous ces modèles LLM open pas vraiment open. Ou probablement plein de mods de jeux vidéos à licences pas forcément ouvertes voire très claires), et du libre non collaboratif (Des exemples ont été donnés ici, SQLite en est un autre : c'est dans le domaine public dans les juridictions qui permettent de déposer volontairement des choses dans le domaine public, mais ces auteurs ne prennent pas les contributions externes).
Ce genre de confusion de la part d'auteurs de logiciels, ça donne sérieusement l'impression d'un manque de culture dans le monde du développement, et ça fait penser que les décisions ne sont potentiellement pas super bien éclairée.
Je viens de participer à la première édition d'AlpOSS (c'était top !) et un intervenant disait "faut voir aussi l'utilité de mettre une application en open source". Il pensait en terme de développement, mais les droits garantis aux utilisateurs et utilisatrices finales de l'application, c'est déjà une utilité largement suffisante… et même la raison principale qui me motive moi à faire du libre. Je n'ai pas osé intervenir mais c'était un point important, j'aurais peut-être dû.
Les questions de l'open source et des modèles de développement ne sont pas encore assez enseignées dans les écoles d'informatique, et il n'y a pas assez d'information là dessus auprès des dev en poste. Mais bon, ça progresse.
[^] # Re: Certains sites (très utilisés) sont 100x plus lents que PUBG
Posté par raphj . En réponse au lien How web bloat impacts users with slow devices. Évalué à 3 (+1/-0). Dernière modification le 22 mars 2024 à 14:36.
J'imagine que les messages sont rendus par des composants avec des couches d'abstractions sur couches d'abstractions s'empilant les unes sur les autres… (par exemple pour gérer des types de messages subtilement différents, ou des configurations différentes ; et en React ou framework similaires, on n'hérite pas, on compose, donc ça s'ajoute - je ne sais pas ce que WhatsApp utilise) et chaque couche rajoute son div. Et ensuite il y a peut-être un outil qui nettoie les classes HTML non utilisées mais qui laisse les div, ou quelque chose du genre.
Pour Wix je ne peux qu'imaginer un editeur wysiwyg custom qui ajoute connement un span style="XXX" pour chaque style XXX, sans essayer de combiner les spans. J'ose espérer que désactiver un style retire le span correspondant et n'en ajoute pas un qui annule la règle CSS par une autre opposée…
[^] # Re: Dans le même esprit
Posté par raphj . En réponse au lien How web bloat impacts users with slow devices. Évalué à 4 (+2/-0).
Tout argument pour réduire la consommation des ressources est bon à prendre, et "plus rapide à charger" veut souvent dire amélioration de la consommation des ressources. Mais pas toujours (tu peux toujours faire un premier affichage rapide et envoyer 10 méga de merdasse à parser et exécuter ensuite, c'est d'ailleurs un peu le problème), et ça ne doit vraiment toucher que les très grosses boites. Je pense que si tu peux mesurer du manque à gagner à cause d'une seconde de chargement en plus, tu as déjà un bon nombre de clients… La plupart des boites ne sont pas comme ça je pense.
Dans tous les cas, ce serait cool que les gens et les boites soient sensibles directement à l'écologie, l'accessibilité, et le respect des gens et optimisent pour ces choses, plutôt que devoir passer par l'argument intermédiaire imparfait du profit. Mais bon, je suis peut-être idéaliste.
[^] # Re: Certains sites (très utilisés) sont 100x plus lents que PUBG
Posté par raphj . En réponse au lien How web bloat impacts users with slow devices. Évalué à 3 (+1/-0).
Quelqu'un pourrait peut-être les informer qu'on peut mettre plusieurs propriétés CSS dans un même attribut
style="".[^] # Re: Code sur papier
Posté par raphj . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 6 (+4/-0). Dernière modification le 19 mars 2024 à 11:05.
Il y a des avantages théoriques à travailler un algorithme d'abord sur papier :
Je pense que c'est notamment pour ces raisons qu'on demande aux étudiants de réfléchir sur du papier. Ça peut être bien pendant l'apprentissage, pour séparer les difficultés.
Il y a aussi le fait que pour des raisons pratiques / économiques, les cours sont découpés en Amphi, TD, TP. Il est commode de faire réfléchir en TD et de mettre en pratique en TP, et lors des TD, il n'y a (en général ? avait ?) pas d'ordinateur.
Maintenant, perso, je n'aimais pas trop réfléchir sur du papier pendant les cours, et surtout devoir utiliser la syntaxe précise et arbitraire imposée par le cours d'algo du jour. Chaque cours ayant bien sûr ses notations, sinon ça ne serait pas drôle. Ça perd l'intérêt de pouvoir se détacher de la syntaxe.
Ça m'arrive quand-même de temps en temps d'utiliser du papier pour réfléchir à des algos compliqués.
C'est probablement très peu pertinent dans la majorité des cas où on écrit de la glue et où la difficulté n'est pas "comment résoudre théoriquement le problème", mais "comment écrire la solution dans le langage, dans le framework et avec les bibliothèques logicielles à disposition".
[^] # Re: Code sur papier
Posté par raphj . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 10 (+22/-0).
C'est plutôt facile, tu écris le code, tu écris les tests, tu remplis le Cerfa qui va bien et tu l'envoies à la région Auvergne-Rhône-Alpes en RLAR pour que Najat tape et exécute ton code. Ce service a été mis en place pour ton bien-être et pour réduire ton temps d'écran.
Le Cerfa, une centaine de pages pour la version courte, mais on prend l'habitude, décrit exactement la procédure de construction et d'exécution des tests, ainsi que l'adresse postale où les résultats des tests doivent être livrés. Ça permet de simplifier un peu les processus et c'est une première étape vers les builds reproductibles. Le truc pénible c'est qu'il ne faut pas oublier de joindre un timbre fiscal et une enveloppe vierge, mais ça aussi on s'y fait.
Le plus rigolo, c'est des assertEquals sur des fichiers XML de 5 Mio, ça demande d'envoyer des cartons, et on se fait livrer les résultats par Colissimo. Mais du coup en général on essaie de réduire les tests au minimum, on ne laisse pas trainer des choses inutiles.
Pareil pour le code, ça a l'avantage de rendre la prod très légère au final.
Une annexe du Cerfa permet de donner des instructions de mise en production en cas de résultats de tests concluants, mais du coup il faut éviter d'envoyer la lettre recommandée à un moment où, tenus compte du délai de la poste, du temps de saisie et d'exécution des tests, ceux-ci finiraient de s'exécuter un vendredi, parce qu'on ne veut pas d'une mise en prod un vendredi, évidemment.
Mais c'est pas mal, ça permet d'aller à l'essentiel et ça fait une prod plus légère en général.
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 3 (+1/-0).
J'utilise des guillemets simples, les variables ne sont donc pas interprétées à la création du fichier de configuration. Elle sont interprétées à chaque exécution. Donc ça devrait marcher tout seul, l'utilisateur n'aura pas besoin de mettre à jour son fichier de configuration manuellement s'il XDG_DOCUMENTS_DIR était défini lors de la création du fichier de configuration et que le journal reste à tout moment dans XDG_DOCUMENTS_DIR :-)
C'est l'intérêt de mon code un peu plus complexe qu'il ne pourrait l'être.
Je n'ai plus qu'à trouver pourquoi je n'ai pas XDG_DOCUMENTS_DIR, et éventuellement rapporter un bug auprès de mon environnement de bureau ou de ma distrib.
Exactement, c'est ce que je comptais faire mais tu m'as battu :-) Je commiterai probablement dans la journée.
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2 (+0/-0).
Je vois comment cette construction fonctionne mais on est ici dans une partie du script qui écrit un chemin dans un fichier de configuration et ça a des implications spécifiques.
Cette dernière version que tu proposes ne respecte pas XDG_DOCUMENTS_DIR si elle existe. Or, je pense qu'il faut la privilégier par rapport au chemin "plan B" hardcodé.
Ensuite, je veux que le fichier journal ne bouge pas d'endroit si XDG_DOCUMENTS_DIR venait à devenir définie sur mon système.
Cependant, je peux imaginer que quelqu'un déplacerait ses dossiers standard et trouver raisonnable que L suive automatiquement (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement). C'est un cas qu'on ne peut raisonnablement prendre en charge que si XDG_DOCUMENTS_DIR est définie au moment de la création du fichier de config, sauf à faire de la magie dans le fichier de config et je ne suis pas très fan de ça.
Sans ça, hardcoder le chemin du fichier journal dans le fichier de config serait mieux, le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement (mais difficile de faire comme ça et permettre le renommage de ces dossiers standard).
Et j'ai utilisé la syntaxe pour se rabattre sur HOME si XDG_DOCUMENTS_DIR venait à ne plus être définie mais en réalité ce n'est pas terrible. Il faudrait certainement éviter cette syntaxe dans le fichier de configuration. Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre. Et en même temps, je veux vraiment éviter de stocker des chemins qui sortent du HOME dans une config autogénérée dans la mesure du possible. Évidemment, si HOME n'est pas défini, all bets are off, mais aussi ça me parait terriblement peu probable.
Voilà l'explication de mes choix. Ce n'est pas parfait parce que c'est le résultat de compromis subtiles.
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2 (+0/-0).
Merci, c'est commité !
XDG_DOCUMENTS_DIR n'est pas définie chez moi donc j'ai ajouté un fallback sur ~/Documents quand même si le dossier existe.
Tout ça fait de L un de mes projets avec la plus grande proportion de code contribué xD.
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 3 (+1/-0).
Pour moi non plus xD
C'est juste un vieux script qui traine à la base.
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 4 (+2/-0).
Merci, c'est commité ! J'ai retiré le dollar en trop, et tant qu'à faire le point virgule que j'avais laissé là pour aucune raison valable. J'ajoute cette substitution dans ma boite à outils shell pour le futur. Je ne pensais pas avoir une contribution aussi vite après une annonce caché dans un commentaire sur un script sans grande importance xD.
Pourquoi avoir nommé le fichier de configuration
Ljournalrcplutôt queLrc? Je ne me souviens plus, mais je vois trois raisons qui me pousseraient à reprendre la même décision aujourd'hui :Clarté :
Lrcdans la listes des fichiers dans.configserait potentiellement cryptique. C'est beaucoup plus facile de percuter avecLjournalrc.Éviter les clashs : si tout le monde appelle son petit script avec une lettre, ça va vite devenir la foire.
Nom du « projet » : J'avais peut-être, pour ces deux raisons, pensé le nom du projet comme Ljournal plutôt que simplement L, mais opté pour
Lpour le nom du script. Aujourd'hui, j'appellerais peut-être plutôt le scriptLjournalet suggérerais aux gens de mettre en place un lien ou un alias nomméL. Et c'est peut-être ce que je ferai si jamais un jour je m'embête à mettre en place un processus d'installation. Pour l'instant, cette responsabilité repose sur la personne qui va réutiliser mon code.[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 3 (+1/-0). Dernière modification le 24 février 2024 à 23:34.
En général oui. Sinon, je commence avec la première ligne et je complète en ouvrant l'éditeur, donc c'est toujours daté. Il est également possible de prendre en note l'entrée standard : Je lance
L -et je tape ou je colle plusieurs lignes et CTRL+D pour finir la note.L epermet ensuite de corriger des choses si besoin.L +etL + -permettent aussi de compléter la dernière note.Rien n'empêcherait d'enregistrer ces notes dans un système plus complexes que ce bête fichier texte :-)
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 4 (+2/-0).
C'est une bonne amélioration, surtout la dernière version. Ça simplifie le code mais ça fait mieux :-)
Je peux faire un commit avec le bon auteur si tu me donnes le nom et l'email à utiliser.
[^] # Re: L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2 (+0/-0).
Oups, corrigé, merci :-)
# L
Posté par raphj . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 10 (+10/-0). Dernière modification le 23 février 2024 à 22:28.
Je vis pas mal dans le terminal et je suis brouillon. J'ai parfois besoin de noter un truc en vitesse sans friction pour être sûr de ne pas le perdre, pour finalement souvent ne jamais y retourner, mais au moins c'est consigné xD
Du coup, j'ai un petit script écrit en plus ou moins une fois (vous savez, ces hacks qui deviennent définitifs ?) que j'utilise depuis des années (y compris quand j'étais à Algoo :-)).
Son utilisation est simple : dans le terminal, je tape L, puis ce que je veux noter.
Ça ajoute une entrée dans un fichier texte synchronisé avec Nextcloud, avec la date.
On peut consulter le journal en tapant L. Ça ouvre le fichier avec
less(ou autre outil configurable), et comme les notes les plus récentes sont en haut du journal, c'est plutôt pratique.Une entrée :
Et on peut appeler l'éditeur de texte de son choix sur le journal avec
L e.L'aide de l'outil :
Ça supporte les étiquettes de la manière la plus débile possible : il suffit d'ajouter "l'étiquette" à la ligne de cette manière :
[tag], et une recherche dans le fichier la retrouvera.Je l'ai mis en ligne pour l'occasion : https://git.jakse.fr/raph/L/src/branch/main/L
Bien sûr, personne ne l'utilisera, parce que chacun a sa manière de prendre ses petites notes, voire de réinventer son outil. Sinon il y a les gens organisés qui écrivent des notes markdown et qui parfois même font des liens entre les notes. Moi, ça m'explose le cerveau xD.
J'ai abandonné l'idée d'utiliser un outil plus complexe que
Ldepuis longtemps. Il faut que l'outil soit discret et immédiat (aucun lag possible, ça peut tuer une pensée. Ça a tendance à marcher sur les smartphones que je peux utiliser aussi (avec Termux sous Android, ou de manière native sur un mobile Linux). C'est extrêmement user-friendly… pour moi. Finalement, ça fait le taf et c'est rentré dans mes habitudes. Je pourrais améliorer ça un peu et respecter un peu la syntaxe Markdown maintenant que Nextcloud prend ça en charge nativement.Et sinon, pour les gens qui utilisent un shell avec une gestion sensée de l'historique (comme zsh), un petit
#avec la note dans la suite marche aussi. C'est un commentaire en shell et ça reste dans l'historique, et ça ne nécessite aucune installation. Mais gare aux historiques corrompus, ça a pu m'arriver de temps en temps.En tout cas j'espère que vous aurez du succès avec cette nouvelle fonctionnalité de Tracim :-) C'est une bonne idée, et c'est plutôt malin.
[^] # Re: Migrer vers XWiki
Posté par raphj . En réponse au journal Atlassian SaaS.... Évalué à 4 (+2/-0). Dernière modification le 14 février 2024 à 07:42.
Ah oui :-)
Il y a aussi OpenProject comme alternative à Jira, en général les gens ont des utilisations complexes de Jira pour lesquelles GitLab peut être un peu léger.
On utilise malheureusement beaucoup Jira, on utilise déjà GitLab pour l'hébergement des projets clients et pour certaines choses pour lesquelles on utilisait Jira, et on est en train d'évaluer OpenProject pour d'autres usages.
Au secours xD non, je ne parlais que de Confluence.
# Migrer vers XWiki
Posté par raphj . En réponse au journal Atlassian SaaS.... Évalué à 10 (+8/-0). Dernière modification le 14 février 2024 à 02:15.
Rester sur Confluence, ça permet de garder le contenu et de ne pas reformer tout le monde à un nouvel outil. C'est un choix naturel.
Mais les nouveaux tarifs et les changements de conditions liées à l'auto-hébergement ne conviennent pas à tout le monde. Beaucoup d'organismes migrent en ce moment vers XWiki et je travaille en ce moment à quasi plein temps sur ces migrations, notamment et en particulier sur les outils de migrations et sur l'accompagnement des clients sur l'aspect migration. Je me retrouve soudainement expert du format d'export Confluence malgré moi. Ou plutôt, comme écrirait le collègue qui a le plus travaillé sur ce code, "format" (avec les guillemets).
Si ta boite venait à revenir sur sa décision de passer au cloud d'Atlassian, c'est une solution possible, libre et auto hébergeable. On accompagne ces migrations au besoin. C'est surtout nécessaire pour la migration de gros wikis. Et on peut former les gens.
Je peine à imaginer une migration vers GitLab ou Gitea, c'est tellement différent… Oui, il y a une fonction de wiki sur ces outils, mais c'est beaucoup plus léger. J'imagine bien commencer une base de connaissances from scratch avec ça, surtout si c'est déjà en place, mais vous utilisez Confluence et ça fait tellement plus. Une migration vers GitLab ne peut probablement fonctionner sans perdre du contenu que si vous avez une utilisation ultra basique de Confluence sans trop utiliser de macros, le système de permissions, etc. Et aussi, si vous avez des outils pour transférer le contenu vers ces plateformes. Migrer vers XWiki, ça ne marche pas trop mal parce que :
Dans tous les cas, je ne peux qu'espérer pour ta boite qu'elle fera le choix de récupérer le contrôle de sa base de connaissance (avis perso : idéalement libre, idéalement hébergé chez vous), peut importe l'outil.
Je fais un peu de pub, difficile de résister, c'est pile dans mon quotidien du moment :-)
[^] # Re: L'avis de Google...
Posté par raphj . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 3 (+1/-0).
https://linuxfr.org/users/glandos/journaux/jpeg-xl-ne-fait-pas-consensus-au-sein-de-l-union-des-vendeurs-de-navigateurs#comment-1950239
[^] # Re: L'avis de Google...
Posté par raphj . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 6 (+4/-0). Dernière modification le 07 février 2024 à 12:30.
Ouais, mais derrière un drapeau expérimental (pas activé par défaut). Ça n'encourage pas l'adoption. C'est presque comme si l'accès au pont était barré, pour reprendre la comparaison évoquée par un autre commentaire.
[^] # Re: Mais il y a surtout autre chose
Posté par raphj . En réponse au lien Pourquoi si peu de filles en mathématiques ?. Évalué à 5 (+3/-0). Dernière modification le 07 février 2024 à 11:56.
C'est quoi des histoires de femmes ?
Ah bon ?
C'est quoi ?
[^] # Re: Mais il y a surtout autre chose
Posté par raphj . En réponse au lien Pourquoi si peu de filles en mathématiques ?. Évalué à 3 (+2/-1). Dernière modification le 07 février 2024 à 11:53.
Oui, c'est vrai. Entre autres il y a eu un peu de "comme les mecs n'étaient pas dispo parce que partis en guerre, on a accepté que les nanas sortent de leur foyer pour que le pays ne s'écroule pas complètement".
[^] # Re: L'avis de Google...
Posté par raphj . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 4 (+2/-0).
J'imagine aussi que ça peut être des questions de coûts de maintenance.
Peut-être parce que ça n'est pas pris en charge sur Chrome et Firefox justement, parce que sinon, vu de loin avec un œil distrait, c'est plutôt séduisant, je me pencherais probablement sur la question perso.
[^] # Re: Mais il y a surtout autre chose
Posté par raphj . En réponse au lien Pourquoi si peu de filles en mathématiques ?. Évalué à 4 (+3/-1). Dernière modification le 06 février 2024 à 17:26.
Tu fais des raisonnements circulaires et des appels à la nature.
Tes utilisations de "c'est évident que", "il est indéniable que" sont un témoin criant que ta démonstration est fragile.
On observe des différences et des tendances notables entre des catégories de gens : les femmes et les hommes. Maintenant, tout le travail consiste à savoir pourquoi. (et encore, je n'aborde pas la question des trans, non-binaires, intersexes et plus généralement des personnes pour qui sexe ≠ genre ou qui ne se reconnaissent pas dans la catégorie "femme" ni dans la catégorie "homme").
Ta thèse c'est : "pour des raisons biologiques". La thèse que tu réfutes (implicitement ?) c'est : "à cause de biais causés par des constructions sociales".
Observer les différences ne suffit pas à appuyer ta thèse et à réfuter l'autre. Il va donc falloir sortir de l'intuitif, qui est un mode de pensée très pratique qui permet de prendre des raccourcis, d'aller vite, d'être efficace et qui marche plutôt bien mais pas toujours, et enclencher un mode de réflexion plus posé, construit, rigoureux et scientifique. Ton commentaire démontre aussi un manque de documentation sur le sujet. Autrement dit, no offense mais tu raisonnes sans savoir donc on est plus sur le domaine de la croyance.
Non, parce que tu n'as pas expliqué ces différences de goût.
C'est malheureusement faux. À cause de mécanismes parfois très subtiles du style les profs ont plus tendance à poser des questions ouvertes aux mecs et des questions oui/non aux nanas sans même le vouloir. On attend d'un mec qu'il soit plus créatif et on tolère plus qu'il soit pénible et dissipé, et on attend plus d'une nana qu'elle soit sage et disciplinée. Ça explique aussi en partie les meilleurs notes des filles à l'école. On pousse plus les nanas à faire des études littéraires ou sociales que scientifiques pour aucune bonne raison.
Mais pourquoi ? C'est tout l'enjeu. N'est-ce pas parce qu'on apprend (plus ou moins volontairement) aux petits garçons qu'il faut être fort et aux petites filles qu'il faut être attentifs aux autres, tendre, etc dès le plus jeune âge ? Que ce soit les parents, la société, etc ? Aka construction sociale ? On habille les filles en rose et les garçons en bleu. Sûrement, ça n'a rien à voir avec des choix et des goûts quand on est bébé, on n'a pas encore la carte de crédit pour aller s'acheter nos vêtements nous-même à cet âge ni même les capacités communicationnelles pour exprimer ses préférences sur la question. Non, la société fait sans arrêt des choix genrés pour nous. Ces différences de couleurs qu'on nous impose tout petit est un seul aspect discriminatoire, très évident, parmi les nombreux présents dans la société, variés et parfois subtiles. Ou alors, comment expliques-tu ce genre de différences ?
Par ailleurs, comment expliques-tu que l'informatique, début-milieu 20ème siècle était plutôt mixte, voire majoritairement féminine ? (les personnes qui ont travaillé sur l'ENIAC par exemple, plein de femmes là dedans !). Et pourquoi ça a changé maintenant ?
Peut-être qu'il y a des différences biologiques qui expliquent certaines choses. Peut-être qu'elles expliquent des rapports de domination et des chaines de réactions sociales qui mènent à ces différences qu'on observe dans la société qui n'ont rien avoir avec des différences fondamentales qui causent des appétences différentes. Ou peut-être pas.
On ne peut pas balayer ces problèmes de discriminations et d'inégalités sous le tapis de l'explication biologique et naturelle. Ce tapis est peut-être confortable pour une partie de la population, mais c'est probablement un peu beaucoup une illusion, ou bien existant mais beaucoup plus fin que prévu.
Et dans tous les cas, on a bien un soucis d'égalité à régler, à commencer par les revenus.
[^] # Re: watchpoints hardware sur x86_64
Posté par raphj . En réponse au journal En passant par le FOSDEM, avec mes sabots 🎵. Évalué à 4 (+2/-0). Dernière modification le 05 février 2024 à 16:20.
Oui, tu as la pile d'appel. Elle est stockée dans la stack, à laquelle le débogueur a accès.
Un (hardware) watchpoint devrait se comporter exactement comme un breakpoint, l'exécution du programme est stoppée par une interruption, à ceci près qu'aucune instruction n'est remplacée par un truc du genre int 3, le processeur prévient l'OS qu'un accès en lecture ou en écriture a eu lieu sur la case mémoire demandée. Et l'OS prévient le débogueur.