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.
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.
[^] # 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.
# Migrer vers XWiki
Posté par raphj (site web personnel) . En réponse au journal Atlassian SaaS.... Évalué à 10. 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 (site web personnel) . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 3.
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 (site web personnel) . En réponse au journal JPEG XL ne fait pas consensus au sein de l'union des vendeurs de navigateurs. Évalué à 6. 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.