Adrien Dorsaz a écrit 952 commentaires

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?

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…

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.

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.

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 :)

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.

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.

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é.

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 :)

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

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.

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).

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é:

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

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

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).

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 😉

Non, ça n'est pas pareil.

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.

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.

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…

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 :)

Merci, ça semble bien fonctionner :-)

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.

Hello,

Si je ne me trompe pas, c'est la configuration du serveur nginx qu'il faudrait ajuster.

J'ai regardé le contenu du dossier /public/fonts et je dirai qu'il faudrait activer le cache du navigateur pour tous les fichiers présents (les extensions y présentes sont pour l'instant afm, otf, ttf, woff, woff2).

Voici les résultats avec curl et différents fichiers (on voit bien que cache-control est présent pour une image et pour une police ttf, mais pas pour les nouvelles en woff et woff2):

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/images/markdown.png
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:35:12 GMT
content-type: image/png
content-length: 298
last-modified: Sat, 24 Feb 2018 14:16:08 GMT
etag: "5a9173a8-12a"
expires: Sun, 29 Sep 2019 18:35:12 GMT
cache-control: max-age=864000
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/LinLibertine.ttf 
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:36:20 GMT
content-type: font/truetype
content-length: 509248
last-modified: Wed, 13 Jul 2011 12:40:26 GMT
etag: "4e1d923a-7c540"
expires: Sun, 29 Sep 2019 18:36:20 GMT
cache-control: max-age=864000
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/Lato-Regular.woff
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:35:37 GMT
content-type: application/font-woff
content-length: 309192
last-modified: Sat, 24 Aug 2019 20:47:48 GMT
etag: "5d61a274-4b7c8"
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/Lato-Regular.woff2
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:36:26 GMT
content-type: application/octet-stream
content-length: 182708
last-modified: Sat, 24 Aug 2019 20:47:48 GMT
etag: "5d61a274-2c9b4"
x-content-type-options: nosniff
accept-ranges: bytes

Je suis étonné que l'on ait mis que 86400 secondes, ça fait juste un jour de cache. Personnellement, surtout pour les polices, j'aurais mis quelque chose comme 1 semaine, car c'est vraiment rare de les changer.

Hello,

J'ai regardé un peu le code et il me semble que pour l'instant LinuxFr ne permet pas de retrouver des informations des autres utilisateurs.

C'est bien les avatars de tous les correspondants dont tu aurais besoin ?

Si oui, il faudrait faire une api du style users/{id or name}. Est-ce envisageable par les administrateurs ?

Comme tous les avatars ne sont pas stockés sur LonuxFr, je pense que seule l'API pourra te donnerles bonnes URLs.

PS: je n'ai pas réussi à utiliser l'API avec Insomnia. Je n'ai pas bien compris l'oauth2 je crois… Si tu pouvais me guider je pourrai tester plus facilement :-)