Adrien Dorsaz a écrit 505 commentaires

  • [^] # Re: Ça a l'air super

    Posté par (page perso) . En réponse à la dépêche Extension LibreOffice pour générer des factures Factur‑X. Évalué à 5 (+3/-0). Dernière modification le 02/01/20 à 08:41.

    Wow, c'est effectivement étonnant, je ne pensais pas que LibreOffice faisait des PDFs non-standards avec cette option.

    Je trouve aussi que l'argumentation de l'utilisateur kurt.pfeifle est vraiment mauvaise: avec ce genre de discours, on ne corrige jamais aucun bug… genre "pas vu, pas pris".

    Par contre, je pense que ça serait intéressant d'ajouter un commentaire pour expliquer que, si LibreOffice corrige ce bug, ça sera utile pour pouvoir inclure facilement des factur-x.

  • # Piste: vote sur des commentaires de comptes supprimés ?

    Posté par (page perso) . En réponse à l'entrée du suivi Entrée redis louche "users//diff_karma". Évalué à 3 (+1/-0). Dernière modification le 01/01/20 à 10:57.

    Hello,

    Au sommet denode.rb, il y a une note qui dit que le user peut être NULL:

    class Node < ActiveRecord::Base
      belongs_to :user     # can be NULL

    J'imagine que ça peut être pareille pour les commentaires.

    C'est peut-être des votes sur des contenus/commentaires de comptes supprimés ?

    Une piste pour comprendre la production serait de lancer des requêtes SQL du style:

    select count(1), DATE(created_at) as creation_date
    from nodes
    where user_id is NULL
    and score <> 0
    and creation_date > DATE_SUB(CUR_DATE(),INTERVAL 1 MONTH)
    order by creation_date desc;
    
    select count(1), DATE(created_at)
    from comments
    where user_id is NULL
    and score <> 0
    and creation_date > DATE_SUB(CUR_DATE(),INTERVAL 1 MONTH)
    order by creation_date desc;

    Dans le where, on peut ajuster la condition sur la date de création pour l'analyse.

    Pour éviter d'avoir ces clés bizarres, on pourrait ajouter une condition à la fin des lignes que tu as trouvés (dans node.rb et comment.rb, ça devrait suffir):

    unless self.user_id.nil?
  • [^] # Re: Ça a l'air super

    Posté par (page perso) . En réponse à la dépêche Extension LibreOffice pour générer des factures Factur‑X. Évalué à 2 (+1/-0). Dernière modification le 01/01/20 à 10:22.

    Je ne sais pas si on est dans le même cas, mais LibreOffice est déjà capable d'inclure le fichier odt dans le PDF. C'est accessible via une option à cocher quand on utilise la fenêtre d'export

    Il faudrait voir si l'odt est une pièce jointe du PDF, je ne sais pas…

  • [^] # Re: La base de la base

    Posté par (page perso) . En réponse au journal Restaurer l’historique de zsh. Évalué à 3 (+2/-1).

    Je me demande s'il parle de l'historique qui est en RAM et n'est pas encore enregistré sur le disque ?

    Si je me souviens bien, l'historique de la session en cours s'enregistre par défaut à la fin de la session. D'ailleurs c'est un peu ennuyeux comme comportement quand on a plusieurs terminaux ouverts en même temps: l'historique n'est pas partagé directement entre eux.

  • [^] # Re: « de simples fichiers YAML »

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 6 (+4/-0).

    D'une part si tu édites encore des fichiers de conf directement sur les serveurs en 2019 c'est que t'as déjà tout faux et pas ta place dans l'industrie

    Merci pour ce chaleureux message, j'avais peur de ne pas savoir où est ma place…

    Je peux te rassurer: je ne suis pas administrateur système en industrie :-)

    d'autre part tu n'as pas besoin d'utiliser l'éditeur présent sur le serveur pour y éditer un fichier (hello points de montages ssh)

    Ok, c'est quand même un échec pour un fichier de configuration : pour pouvoir bien l'éditer, tu dois sortir une autre machine.

    pour finir avoir de la coloration syntaxique et du linting n'est qu'à un jet de pierre pip/gem/yum/dnf/gem.

    Le problème pour un utilisateur normal, c'est qu'il va casser sa configuration puis se rendre compte après qu'il a besoin d'un linter.

    Pour du code, ça ne me pose pas de problème, mais pour un simple ajustement de configuration, c'est hyper lourd.

  • [^] # Re: « de simples fichiers YAML »

    Posté par (page perso) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 10 (+9/-0).

    Je pense que la grande différence est le contexte: quand je travaille sur un code python, j'utilise généralement un IDE, car je sais qu'il y a beaucoup de conventions à respecter. J'espère que tout le monde se rend compte que modifier un code, n'est pas du tout un acte anodin et qu'il y a beaucoup de règles à respecter.

    Les tabulations / espaces, c'est un des premiers trucs que l'on apprend en lisant des tutos sur python.

    Par contre, quand je modifie un fichier de configuration, ça doit être un acte anodin. Il doit être possible de le faire sans IDE (emacs, vim ne sont pas toujours installés sur tous les postes/serveurs).

    Un exemple typique, est que je vois un comportement par défaut que je veux changer. J'ouvre le fichier de configuration, je voit que c'est du texte et je l'adaptes selon le reste du fichier. Je le fais avec un simple éditeur de texte (qui ouvrirait un fichier de config avec un IDE ?) et je ne vois pas la différence entre espace/tabulation. Maintenant, avec un fichier .ini tout se passe sans problèmes, avec un fichier .yml, il y a 9 chances sur 10 que je vienne de casser mon service/programme.

    Je pense que le contexte fait vraiment la différence pour l'édition: pour un code, les gens savent qu'il faut suivre une formation, mais pour une configuration, des administrateurs systèmes, des utilisateurs doivent pouvoir les modifier.

    Maintenant, dans le cas de reqman, je comprends l'utilisation de yaml: c'est un outil destiné à des développeurs / testeurs, ça ne me choque pas :)

  • # wow :-)

    Posté par (page perso) . En réponse au lien Microsoft commence à utiliser Rust dans Windows. Évalué à 3 (+1/-0). Dernière modification le 09/12/19 à 08:01.

    L'article est très intéressant : le développeur semble conquis par Rust et il présente quelques qualités du langage.

    En fait, il ne soulève quasiment pas de points négatifs ! Le point négatif le plus important est l'intégration de Cargo (le système de build/test/…) dans d'autres système de build.

  • [^] # Re: Gtk et le C++

    Posté par (page perso) . En réponse au journal Mes activités open sources / libres "récentes". Évalué à 2 (+0/-0).

    Merci beaucoup pour ce retour, c'est intéressant.

    Mon objectif était d'apprendre le C++-17 avec la création de ce nouveau projet. Comme j'avais déjà pas mal jouer avec Glib/Gtk récemment, je voulais l'utiliser pour la Gui simplement.

    Si j'ai bien compris, un des grands intérêts d'utiliser Gtk 3, c'est que cette version implémente Gobject Introspection. Cet outil devrait permettre de ne plus avoir besoin de faire manuellement les binding dans le langage cible (comme tu expliquais que c'était le cas pour le C++ gtkmm, glibmm…).

    En fait, ça définit la syntaxe d'un fichier .gir qui expose l'interface de manière abstraite du langage d'implémentation (C en l'occurrence pour Gtk). Ce fichier est généré directement par le projet source (donc Gtk).

    En lisant ce fichier avec un programme (cppgir pour le C++), il serait possible de générer de manière automatique les interfaces dans le langage cible (ici, C++).

    Donc, en théorie, cppgir devait résoudre mon problème, mais je n'ai pas réussi à l'utiliser :-) Peut-être qu'on ne peut pas faire de C++-17 avec, je ne sais pas.

  • [^] # Re: Merci

    Posté par (page perso) . En réponse au journal Mes activités open sources / libres "récentes". Évalué à 5 (+3/-0).

    De rien :)

    Pour LinuxFr, c'est agréable d'être entouré d'une bonne équipe: Mathieu trouve de bonnes idées d'améliorations et de test et Bruno réagit vite aux demandes de fusion et donne de bons conseils.

    Ça prend un peu de temps à écrire les comptes rendus, mais c'est assez chouette pour moi aussi de voir ce qui s'est passé.

  • [^] # Re: Au sujet des TMS : pédaliers USB

    Posté par (page perso) . En réponse au journal NoComprendo, la commande vocale pour Linux. Évalué à 5 (+3/-0). Dernière modification le 30/11/19 à 07:15.

    Ah ben voilà, je me disais bien que c'était inhumain d'utiliser Emacs avec 2 mains ! Ils devraient ajouter dans leur documentation que pour pouvoir l'employer correctement, il faut utiliser ses pieds :)

  • [^] # Re: OpenWrt + SQM

    Posté par (page perso) . En réponse au journal QOS à la maison : comment vous faites?. Évalué à 3 (+1/-0).

    A ce sujet, on avait eu un journal très intéressant l'année dernière :-)

  • [^] # Re: En effet

    Posté par (page perso) . En réponse à l'entrée du suivi régressions à cause du PR #258 (nouvel espace de rédaction). Évalué à 2 (+0/-0).

    Pour les titres, oui, je me suis souvenu, c'est ce que je suis en train d'ajouter avec l'image d'illustration.

    Il y avait déjà eu pas mal de boulot à faire pour le panneau latéral et les barre d'outils, alors j'avais laissé ça de côté, mea culpa.

  • [^] # Re: En effet

    Posté par (page perso) . En réponse à l'entrée du suivi régressions à cause du PR #258 (nouvel espace de rédaction). Évalué à 2 (+0/-0).

    Ahahah, vu la discussion, je crois que j'avais compris tout de travers :)

    Quand tu as dit:

    J'en profite pour t'informer que de moins en moins de dépêches utilisent la deuxième partie (c'est très casse-pied en modération).

    Est-ce que ce qui est pénible, c'est que les rédacteurs n'utilisent plus la deuxième partie ?

    Moi, j'avais compris ce matin quelque chose du genre "L'équipe de modération trouve la deuxième partie très casse-pied"… Autant te dire que j'étais un peu surpris :-)

    Si je me suis bien trompé, tout va bien, car, justement, la suite des évolutions de l'espace de rédaction va être de mieux agencer tout ça avec l'image d'illustration qui permettra de bien séparé les notions de "chapeau", "illustration" et "contenu" (je dois justement mettre plusieurs titres dans ce contenu).

  • [^] # Re: En effet

    Posté par (page perso) . En réponse à l'entrée du suivi régressions à cause du PR #258 (nouvel espace de rédaction). Évalué à 3 (+1/-0).

    J'en profite pour t'informer que de moins en moins de dépêches utilisent la deuxième partie (c'est très casse-pied en modération).

    Mmhh, c'est embêtant ça, parce que le nouveau design a une autre vision: l'idée c'est que la première partie soit un texte d'accroche très court (genre, 1-2 phrases) qui sera associée à une image d'illustration.

    Ceci permet de supprimer ces ciseaux pour la rédaction collaborative pour rendre plus simple l'interface et aussi de faire des jolies vignettes dans la liste des dépêches.

    L'idée que mjourdan avait donné:

    accueil avec chapeaux et illustrations

    Un essai d'implémentation pour une dépêche en cours d'édition:

    dépêche en cours

  • # A ajouter dans la page wiki de l'aide détaillée ?

    Posté par (page perso) . En réponse à l'entrée du suivi Ajouter l'aide pour les liens wikipedia non francophones. Évalué à 2 (+0/-0).

    Hello,

    On avait perdu le lien vers la page wiki d'aide à l'édition, on l'a rétabli.

    Tu peux donc ajouter cette documentation directement dans le wiki :-)

    Sinon, je ne suis pas sûr d'avoir bien compris le code, mais j'ai l'impression qu'il faut écrire [[en:Programming]] pour avoir un lien vers une page wikipédia anglaise: Programming

  • # En effet

    Posté par (page perso) . En réponse à l'entrée du suivi régressions à cause du PR #258 (nouvel espace de rédaction). Évalué à 3 (+1/-0).

    Hello,

    Merci pour le retour !

    C'est bien vu pour le lien, on l'a effectivement perdu. J'ai fait une demande de fusion pour l'ajouter à nouveau.

    Pour le second point, si je comprends bien, tu parles de la 2ème partie quand on est en mode "réorganisation" ?

    Si c'est bien ça, la situation va s'améliorer quand les liens seront déplacés après la seconde partie (c'est en cours avec l'ajout d'image d'illustration).

  • [^] # Re: Matrix

    Posté par (page perso) . En réponse à la dépêche Lettre d’information XMPP, 1ᵉʳ octobre 2019, FOSDEM 2020, modernisation de XMPP, réseaux de pairs. Évalué à 3 (+1/-0). Dernière modification le 16/11/19 à 16:35.

    Ok, il semble que tu connaisses déjà des différences. Du coup, tu pourrais préciser la question ?

    Là elle est très large, c'est pour ça que je t'ai donné le lien de la FAQ de Matrix 😉

  • [^] # Re: Matrix

    Posté par (page perso) . En réponse à la dépêche Lettre d’information XMPP, 1ᵉʳ octobre 2019, FOSDEM 2020, modernisation de XMPP, réseaux de pairs. Évalué à 3 (+1/-0).

  • # Patch

    Posté par (page perso) . En réponse à l'entrée du suivi Les bloques de code et les tableaux cassent le rendu mobile. Évalué à 2 (+0/-0). Dernière modification le 14/11/19 à 09:55.

    Hello,

    J'ai proposé le patch ici pour régler ce problème: https://github.com/linuxfrorg/linuxfr.org/pull/259

    Le seul soucis, c'est que pour pouvoir utilisé la propriété table-layout des tableaux, je suis obligé de définir la taille width: 100%. Je pense que c'est pas si mal, mais ça va changer un peu le rendu des tableaux qui sont dans des contenus (les statistiques ne sont pas affectées :)).

    Pour voir les cas que j'ai testé, c'est à la fin de cet article et dans le premier commentaire.

  • # La limite actuelle est de "100 messages"

    Posté par (page perso) . En réponse à l'entrée du suivi Limitation de l'historique de la tribune de discussion des dépêches. Évalué à 2 (+0/-0).

    Hello,

    Si je ne m'abuse, actuellement, toutes les tribunes (/board, celle de modération, celle des rédacteurs, celles pour chaque dépêche) est limité à 100 messages:

    # encoding: utf-8
    
    # It's the famous board, from DaCode (then templeet)
    #
    class Board
      include ActiveModel::Model
      include Canable::Ables
    
      NB_MSG_PER_CHAN = 100
    
    ### Constructors and attributes ###
    
      attr_accessor :id, :user_name, :user_url, :user_agent, :object_type, :object_id, :message, :created_at

    Rendre le contenu illimité et sauvé en tout temps, ça me semble un peu exagéré, car chaque dépêche a sa propre tribune et car elles ne sont pas vidées à la publication d'une dépêche (la modération a toujours accès à cette tribune).

    Personnellement, je comprends que la tribune dans une dépêche comme un lieu de discussion rapide et informelle pour les personnes qui sont en train de collaborer ensemble. De ce point de vue, je ne vois pas l'intérêt de conserver un nombre illimité de messages.

    Par contre, on pourrait imaginer augmenter la limite à quelque chose de plus adapté ?

    Sinon, pour les messages et prises de décisions les plus importantes pour la collaboration en rédaction, autant écrire leur résumé directement dans la dépêche: ça permet de s'assurer que tout participant à la dépêche voie ce texte puisqu'il est dans le corps de la dépêche.

    Finalement, je serais donc plutôt pour augmenter la limite un peu, mais ne pas la supprimer pour éviter de surcharger les disques dures de LinuxFr (et le service Redis). A voir si Bruno est aussi de cet avis.

  • [^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction

    Posté par (page perso) . En réponse à l'entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 3 (+1/-0).

    Pour cette série, je viens de proposer un PR qui remanie pas mal le layout pour le passer à nouveau à 2 colonnes:

    Après plusieurs essais de design avec @mjourdan pour la réorganisation de l'espace de rédaction (voir les discussions dans le PR #242), le résultat est le suivant:

    • Le layout est de nouveau sur 2 colonnes
    • La colonne de droite est un panneau qui prend tout l'espace vertical et qui peut être caché.
    • Quand le panneau de droite (#toolpanel) est affiché, la zone de rédaction est légèrement réduite
    • La barre d'outil a été ajoutée dans ce layout (#toolbar) et, contrairement aux autres pages, elle ne contient que 2 bouttons sur la droite: un pour afficher/cacher le panneau de droite et un second pour afficher / cacher un sommaire
    • Pour gérer le fait d'afficher / cacher des portions de la page, un nouvel outil JavaScript popup a été crée.
      • Ce système est réutilisable pour d'autres parties de l'espace de rédaction. Par contre, je le déconseillerai sur le reste du site, car ça rend JS indispensable (ce qui est déjà le cas pour l'espace de rédaction)
      • Lors d'un clique:
      • Le JavaScript lit l'attribut data-popup-id de l'objet cliqué.
      • Cet identifiant doit correspondre à un id d'un élément de la page. Le JS retrouve cet élément et lui ajoute (ou retire) l'attribut data-popup-shown
      • Comme plusieurs éléments peuvent déclencher ce JS, le JS retrouve tous les déclencheurs qui ont l'attribut data-popup-event-#{id retrouvé plus haut}
      • Enfin, il est possible d'ajouter également des listeners qui souhaitent "écouter" les changements d'état d'un élément. Dans l'élément à afficher/cacher, il faut ajouter l'attribut data-popup-listner-ids avec une liste d'identifant séparé par des espaces.
      • Le JS ne gère que les attributs des éléments du DOM. Tout ce qui est affichage et transitions est géré directement par CSS (à créer à la main selon les besoins).

    D'après mes tests, ce code est compatible jusqu'à IE 10, je n'ai pas essayé de navigateurs plus vieux. Si vous voulez tester, ce code est actuellement installé sur https://dlfp.adorsaz.ch (utilisateur: moderateur, mot de passe identique).

    PS: Je n'ai pas le courage de faire le ménage dans les commits, on y voit donc tout l'historique de rechreche de design… Est-ce que vous voulez que je fasse un squash avec toutes les modifications ? Ça ferait un gros commit, mais ça éviterait de polluer l'historique git…

  • [^] # Re: Quelles limitations technologiques ?

    Posté par (page perso) . En réponse à l'entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 3 (+1/-0).

    Pour l'instant, je me limite au navigateur Internet Explorer 10 (sorti en 2012). Il permet de faire déjà pas mal de choses et il a quand même déjà 7 ans :)

  • # Il faut utiliser les forums pour les questions

    Posté par (page perso) . En réponse à l'entrée du suivi SVP retirer erreur du pitcher. Évalué à 2 (+0/-0).

    Hello,

    Le gestionnaire de suivi de LinuxFr (ici même donc) est prévu pour faire des demandes d'améliorations et de corrections du site web LinuxFr lui-même.

    Il faut donc poser cette question sur les forums de LinuxFr pour avoir l'aide de la communauté.

    A bientôt sur les forums !

  • [^] # Re: Configurer Nginx ?

    Posté par (page perso) . En réponse à l'entrée du suivi Ajouter un réglage de cache aux nouvelles polices. Évalué à 2 (+0/-0).

    Merci, ça semble bien fonctionner :-)

  • [^] # Re: Configurer Nginx ?

    Posté par (page perso) . En réponse à l'entrée du suivi Ajouter un réglage de cache aux nouvelles polices. Évalué à 2 (+0/-0).

    Ahaha, je me suis trompé, le cache est activé pour 86400*0* secondes et donc 10 jours, pas juste 1 :-)

    Je me suis rendu compte quand j'ai préparé un PR qui active le mimetype pour woff2 et le cache pour ces polices:

    https://github.com/linuxfrorg/admin-linuxfr.org/pull/5

    J'ai fais ces modifications à la main et je ne les ai pas testées, alors il pourrait y avoir une erreur qui s'y est glissée…

    Bon en vrai, la branch master de ce dépôt git n'a pas bougé depuis 2017, c'est peut être pas le bon endroit.