C'est marrant après cette virgule tu ne parle que de vocabulaire
Ça tombe bien, je caractérisais mon commentaire précédent avec cette expression. Mais ce n'est même pas vrai, après cette virgule, j'explique qu'il y a des problèmes de compréhension de fond, qui ne se limitent pas à un simple problème de vocabulaire.
Et ensuite, je défends effectivement l'utilisation précise du vocabulaire pour limiter ces problèmes. Je répondais à ton avis que ce n'était pas si important, il se trouve que je ne suis pas d'accord.
Évidemment, il faut ne pas être complètement désagréable pour que ça soit possible.
Reprendre quelqu'un qui a de toute évidence parfaitement compris ce de quoi il parlait puisqu'il utilise à son avantage les possibilités que ça lui donne avec une forme assez pédante de « ouai l'autre il sait même pas utiliser les bons mots lol » me semble à l'opposé de ça. Dans son fichier CONTRIBUTING, il parlait de sa licence d'un côté et de son mode de développement de l'autre rendant parfaitement clair ce qu'il voulait dire et l'utilisation des guillemets montre qu'il sait qu'il fait un abus de langage. Le moquer ou le prendre de haut est une chose, mais il est évident qu'il sait parfaitement où il va.
Tu parles du commentaire de Marotte qui demande "Ça ne veut rien dire, non ?"
Je ne pense pas que ça soit pédant, … et puis bah oui, c'est un peu le genre de chose qu'il se passe quand on n'utilise pas les bons mots. Les gens ne se comprennent pas bien. C'est la vie. Maintenant à toi de choisir : tu utilises sciemment des expressions qui ne correspondent pas parfaitement en espérant être compris, ou alors tu es précis et tu peux serrer moins les fesses. Je sais ce que je choisis de mon côté, et je respecte les gens qui choisissent différemment. Par ailleurs, je ne parle pas pour Marotte, je parle pour moi.
Et par ailleurs, le fichier CONTRIBUTING en question a été mal cité dans le journal et était tout à fait exact au final.
Mais j'ai l'impression que tu prêtes des intentions aux gens en présence beaucoup trop malicieuses pour ce qu'elles ne le sont en réalité.
Tu ressent le même problème quand on parle de service libre par exemple ? D'hébergeur libre ? Quand on parle d'imprimante open source ?…
Quel est ton but, me prendre en défaut ? Peu importe ma réponse, ça ne change pas mon point de vue sur le fait qu'il vaut mieux être précis. "modèle de développement open source" n'est pas bien défini parce qu'il existe pleins de modèles de développement différents pour des logiciels open source.
De mon côté, je n'utilise pas ces expressions que tu cites (ça a pu m'arriver, c'est facile de reprendre des expressions présentes dans une discussion sans faire trop attention, et ça ne serait pas scandaleux, évidemment. Service libre et hébergeur libre, ce sont des métonymie, comme "mange ton assiette", c'est commun dans les langues vivantes).
Tout ceci étant dit, la citation du journal n'est pas bonne, le readme dit :
PySimpleGUI is different than most projects on GitHub. It is licensed using the "Open Source License" LGPL3. However, the coding and development of the project is not structured in the same way most open source projects are structured
Cette dernière formulation n'est pas problématique et elle est très claire. Il y a eu une modification malheureuse.
Ce n'est pas sans rapport effectivement, les sujets sont très liées, y compris de la manière que tu décris, mais ça reste des concepts très différents. Et bien sûr que les faits sont plus importants que comment on les décrits, et lors d'argumentations on devrait se concentrer sur le fond.
Mais perso, je ne parlais pas de vocabulaire, mais de réelles confusions sur ces choses, dans le fond. J'ai rencontré des gens qui ne font pas bien la distinction code open source et modèle de développement contributif ("ouvert"). Il n'y a qu'à voir comment les gens réagissent quand un projet libre n'accepte pas de contributions : "C'est pas vraiment open source". Bah… si. Peut importe comment on appelle les choses, mais il faut que les concepts soient claires…
… Mais justement, les confusions dans comment on appelle les choses entraînent des confusions sur le fond. Le discours est de fait notre manière de se comprendre et de mener des argumentations claires aussi. Donc c'est quand même important de parler précisément.
Quand quelqu'un nous dit "bof, c'est nul, c'est pas vraiment open source", on peut chercher à comprendre ce qui est important pour cette personne :
Un développement coopératif ?
Un développement à ciel ouvert ?
les droits garantis par le logiciel libre ?
open core ou totalement libre ?
par une entreprise privée, ou par un particulier, ou par une asso ?
Et en vrai, un vocabulaire carré et bien utilisé, ça aide quand même vachement à débroussailler. Ça permet aussi de mettre les concepts / le fond au clair et de penser clairement.
Très souvent, on a quand même confusion de vocabulaire = confusion de fond. C'est comme un code smell, parfois c'est en fait ok, souvent, c'est quand même un réel problème dessous. Autant éviter le code smell du coup, quand on peut.
Utiliser le bon vocabulaire quand on maitrise bien les choses, ça évite aussi de semer la confusion auprès des gens pour qui les choses sont moins claires. On le leur doit.
Du coup, c'est même pire. Il ne faut pas confondre :
code open source
droits d'auteurs
modèle de développement
Ces trois choses sont très liés mais on a intérêt à pouvoir raisonner clairement en appelant un chat un chat.
C'est ok de se tromper, je le fais moi-même, et je ne vais pas nécessairement reprendre les gens à chaque coin de rue surtout si les idées sont transmises correctement malgré un mauvais terme parce que sinon au secours, mais malgré tout, je pense sincèrement qu'utiliser le bon vocabulaire c'est mieux, tant qu'à faire. Et parfois, une simple correction de vocabulaire a mené à des discussions de fond intéressantes. Évidemment, il faut ne pas être complètement désagréable pour que ça soit possible.
L'idée c'est que ça va être difficile de pousser la prochaine version sur le Play Store sans donner la clé privée de VLC à Google, ce que l'équipe VLC ne veut pas faire parce qu'on ne partage pas sa clé privée (sinon, la personne avec qui on la partage peut lire les messages qu'on nous envoie et/ou se faire passer pour nous)
Ouais, mais en effet, Gof, ça mériterait plus de clarté, on doit aller lire le texte de la licence pour aller deviner l'idée derrière le modèle de distribution / commercial, pas ouf, faudrait que ça soit clair immédiatement sur la première page à mon avis :-)
N'est-ce pas l'occasion parfaite pour inviter les gens à utiliser F-Droid du coup ? Installer un paquet APK manuellement ça devrait être du dernier ressort de chez dernier ressort : il n'y a pas de gestion de mise à jour, et prendre l'habitude de télécharger des APK depuis internet c'est peut-être pas le top quand on a F-Droid qui existe. VLC y est à jour, justement, et F-Droid est cité sur cette page de téléchargement.
Sinon oui, devoir donner sa clé privée à Google, ça n'a pas de sens. S'ils veulent signer un truc, qu'ils le fassent avec leur clé ou alors il faut changer de manière de distribuer et signer. On peut tout à fait signer une même chose avec plusieurs clés. Dans "clé privée", il y a "privée", on ne peut pas être plus clair sur l'intention du système.
On peut utiliser la GPLv3 pour n'importe quoi (Desktop, Web, Embedded)
Mais pour Desktop et Web, si on n'aime pas la GPLv3, on peut utiliser cette licence propriétaire à la place. Je pense que l'idée, c'est faire de la pub à Slint vu les conditions d'utilisation.
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.
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.
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.
[^] # Re: Wut?
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 4.
Ça tombe bien, je caractérisais mon commentaire précédent avec cette expression. Mais ce n'est même pas vrai, après cette virgule, j'explique qu'il y a des problèmes de compréhension de fond, qui ne se limitent pas à un simple problème de vocabulaire.
Et ensuite, je défends effectivement l'utilisation précise du vocabulaire pour limiter ces problèmes. Je répondais à ton avis que ce n'était pas si important, il se trouve que je ne suis pas d'accord.
Tu parles du commentaire de Marotte qui demande "Ça ne veut rien dire, non ?"
Je ne pense pas que ça soit pédant, … et puis bah oui, c'est un peu le genre de chose qu'il se passe quand on n'utilise pas les bons mots. Les gens ne se comprennent pas bien. C'est la vie. Maintenant à toi de choisir : tu utilises sciemment des expressions qui ne correspondent pas parfaitement en espérant être compris, ou alors tu es précis et tu peux serrer moins les fesses. Je sais ce que je choisis de mon côté, et je respecte les gens qui choisissent différemment. Par ailleurs, je ne parle pas pour Marotte, je parle pour moi.
Et par ailleurs, le fichier CONTRIBUTING en question a été mal cité dans le journal et était tout à fait exact au final.
Mais j'ai l'impression que tu prêtes des intentions aux gens en présence beaucoup trop malicieuses pour ce qu'elles ne le sont en réalité.
Quel est ton but, me prendre en défaut ? Peu importe ma réponse, ça ne change pas mon point de vue sur le fait qu'il vaut mieux être précis. "modèle de développement open source" n'est pas bien défini parce qu'il existe pleins de modèles de développement différents pour des logiciels open source.
De mon côté, je n'utilise pas ces expressions que tu cites (ça a pu m'arriver, c'est facile de reprendre des expressions présentes dans une discussion sans faire trop attention, et ça ne serait pas scandaleux, évidemment. Service libre et hébergeur libre, ce sont des métonymie, comme "mange ton assiette", c'est commun dans les langues vivantes).
[^] # Re: Wut?
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 3. Dernière modification le 27 mars 2024 à 18:08.
Tout ceci étant dit, la citation du journal n'est pas bonne, le readme dit :
Cette dernière formulation n'est pas problématique et elle est très claire. Il y a eu une modification malheureuse.
[^] # Re: Wut?
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 4. Dernière modification le 27 mars 2024 à 17:51.
Ce n'est pas sans rapport effectivement, les sujets sont très liées, y compris de la manière que tu décris, mais ça reste des concepts très différents. Et bien sûr que les faits sont plus importants que comment on les décrits, et lors d'argumentations on devrait se concentrer sur le fond.
Mais perso, je ne parlais pas de vocabulaire, mais de réelles confusions sur ces choses, dans le fond. J'ai rencontré des gens qui ne font pas bien la distinction code open source et modèle de développement contributif ("ouvert"). Il n'y a qu'à voir comment les gens réagissent quand un projet libre n'accepte pas de contributions : "C'est pas vraiment open source". Bah… si. Peut importe comment on appelle les choses, mais il faut que les concepts soient claires…
… Mais justement, les confusions dans comment on appelle les choses entraînent des confusions sur le fond. Le discours est de fait notre manière de se comprendre et de mener des argumentations claires aussi. Donc c'est quand même important de parler précisément.
Quand quelqu'un nous dit "bof, c'est nul, c'est pas vraiment open source", on peut chercher à comprendre ce qui est important pour cette personne :
Et en vrai, un vocabulaire carré et bien utilisé, ça aide quand même vachement à débroussailler. Ça permet aussi de mettre les concepts / le fond au clair et de penser clairement.
Très souvent, on a quand même confusion de vocabulaire = confusion de fond. C'est comme un code smell, parfois c'est en fait ok, souvent, c'est quand même un réel problème dessous. Autant éviter le code smell du coup, quand on peut.
Utiliser le bon vocabulaire quand on maitrise bien les choses, ça évite aussi de semer la confusion auprès des gens pour qui les choses sont moins claires. On le leur doit.
Du coup, c'est même pire. Il ne faut pas confondre :
Ces trois choses sont très liés mais on a intérêt à pouvoir raisonner clairement en appelant un chat un chat.
C'est ok de se tromper, je le fais moi-même, et je ne vais pas nécessairement reprendre les gens à chaque coin de rue surtout si les idées sont transmises correctement malgré un mauvais terme parce que sinon au secours, mais malgré tout, je pense sincèrement qu'utiliser le bon vocabulaire c'est mieux, tant qu'à faire. Et parfois, une simple correction de vocabulaire a mené à des discussions de fond intéressantes. Évidemment, il faut ne pas être complètement désagréable pour que ça soit possible.
[^] # Re: 3.5.4 ?
Posté par raphj (site web personnel) . En réponse au lien Why VLC for Android has not been updated in months on the Play Store - N. POMEPUY, via sebsauvage. Évalué à 3.
L'idée c'est que ça va être difficile de pousser la prochaine version sur le Play Store sans donner la clé privée de VLC à Google, ce que l'équipe VLC ne veut pas faire parce qu'on ne partage pas sa clé privée (sinon, la personne avec qui on la partage peut lire les messages qu'on nous envoie et/ou se faire passer pour nous)
[^] # Re: VLC pour Android n'a pas été mis à jour depuis des mois, tout court
Posté par raphj (site web personnel) . En réponse au lien Why VLC for Android has not been updated in months on the Play Store - N. POMEPUY, via sebsauvage. Évalué à 2.
La dernière release semble dater de février 2023:
https://code.videolan.org/videolan/vlc-android/-/tags
https://code.videolan.org/videolan/vlc-android/-/tags/3.5.4
[^] # Re: GUI pour python.
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 2.
Ouais, mais en effet, Gof, ça mériterait plus de clarté, on doit aller lire le texte de la licence pour aller deviner l'idée derrière le modèle de distribution / commercial, pas ouf, faudrait que ça soit clair immédiatement sur la première page à mon avis :-)
# F-Droid
Posté par raphj (site web personnel) . En réponse au lien Why VLC for Android has not been updated in months on the Play Store - N. POMEPUY, via sebsauvage. Évalué à 9. Dernière modification le 27 mars 2024 à 10:39.
N'est-ce pas l'occasion parfaite pour inviter les gens à utiliser F-Droid du coup ? Installer un paquet APK manuellement ça devrait être du dernier ressort de chez dernier ressort : il n'y a pas de gestion de mise à jour, et prendre l'habitude de télécharger des APK depuis internet c'est peut-être pas le top quand on a F-Droid qui existe. VLC y est à jour, justement, et F-Droid est cité sur cette page de téléchargement.
Sinon oui, devoir donner sa clé privée à Google, ça n'a pas de sens. S'ils veulent signer un truc, qu'ils le fassent avec leur clé ou alors il faut changer de manière de distribuer et signer. On peut tout à fait signer une même chose avec plusieurs clés. Dans "clé privée", il y a "privée", on ne peut pas être plus clair sur l'intention du système.
[^] # Re: GUI pour python.
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 6.
À priori quand on clique on y voit plus clair : https://slint.dev/community#community-licenses
[^] # Re: GUI pour python.
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 5.
Félicitations pour Slint, mais… outch, les gros sabots xD.
[^] # Re: Wut?
Posté par raphj (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 5. 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 (site web personnel) . En réponse au lien How web bloat impacts users with slow devices. Évalué à 3. 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 (site web personnel) . En réponse au lien How web bloat impacts users with slow devices. Évalué à 4.
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 (site web personnel) . En réponse au lien How web bloat impacts users with slow devices. Évalué à 3.
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 (site web personnel) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 6. 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 (site web personnel) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 10.
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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 3.
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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2.
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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2.
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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 3.
Pour moi non plus xD
C'est juste un vieux script qui traine à la base.
[^] # Re: L
Posté par raphj (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 4.
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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 3. 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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 4.
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 (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2.
Oups, corrigé, merci :-)
# L
Posté par raphj (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 10. 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 (site web personnel) . En réponse au journal Atlassian SaaS.... Évalué à 4. 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.