Goffi a écrit 1537 commentaires

Merci pour les encouragements

Je souhaite vraiment que ton projet réussisse à percer, mais si tu fais l'impasse sur iOS (et dans une moindre mesure Android, ça va être chaud.

Pour précision : je ne fais pas l'impasse, le problème est plus du côté de la licence (AGPL v3+) qui pose problème avec l'Apple Store. Techniquement Kivy pourrait déjà permettre de porter le frontend pour appareils mobiles sur iOS, et je ne suis pas opposé à du Electron ou similaire si ça permet d'avoir un truc fonctionnel.

L'autre problème c'est les ressources : c'est un projet trop gros pour pouvoir le maintenir correctement tout seul sans y laisser sa santé. J'aimerais trouver un modèle économique pour pouvoir monter une équipe, et la subvention que j'ai eu la chance d'avoir a déjà été une grande bouffée d'air.

Bon puisque Libervia est cité, et que j'en suis le développeur principal, je vais répondre moi même et te dire honnêtement que ça n'est pas encore adapté à ton cas parce que ça n'est pas suffisamment stable. Toutes les fonctionnalités que tu souhaites sont présentes ou prévues ceci-dit (enfin sauf l'applications iOS, qui reste incertaine).

Je développe pratiquement tout seul (pratiquement parce que ça m'arrive d'avoir des aides ponctuelles), et c'est un boulot énorme de maintenir ça, surtout que je développe (et spécifie) encore certaines fonctionnalités.

En dehors de Nextcloud déjà cité, il y a aussi Elgg qui peut être intéressant (la décentralisation n'étant pas indispensable dans ton cas), mais je n'ai pas de retour d'utilisateurs comme tu demandes.

J'espère pouvoir monter quelque chose autour de Libervia à l'avenir, mais ça demandera une équipe et un moyen de payer des salaires. Peut-être à la rentrée 2023 ? Si jamais, je ferai probablement un journal ici même pour en parler de toute façon.

XEP-0277 c'est ce qu'utilise movim, c'est bien ça ? Mon petit doigt me dit qu'il y a déjà une passerelle activitypub/xmpp en cours de préparation par des gens plus compétents que moi. ;-)

Oui voilà c'est ça. La XEP-0277 en elle même n'est pas bien compliquée (c'est surtout un moyen de mettre des éléments Atom dans XMPP), mais pour une passerelle ça signifie qu'il faut faire un serveur pubsub. C'est un peu de boulot, mais une fois fait c'est réutilisable, il faut voir que que slixmpp propose là dessus.

C'est bien plus adapté que les messages pour tout ce qui se rapproche d'un blog/microblog/forum, surtout quand il y a des réponses voire des arbres (comme Reddit, HackerNews… ou LinuxFr par exemple).

Effectivement c'est ce que j'utilise pour la passerelle ActivityPub, et j'aimerais bien à terme l'utiliser pour une passerelle avec les courriels et notamment les listes de diffusion.

Tu pensais à quelque chose en particulier ? Facebook, Twitter, par exemple ? Ça a l'air horrible, donc j'ai envie d'essayer maintenant.

J'ai vu FB dans ton tableau, c'est pour ça que je me suis posé la question, mais je suppose que c'est le messenger que ton projet gère.

Oui, ce tableau est pourri, les icônes ne marchent même pas tous sur Firefox de mon macbook (du boulot, j'ai pas eu le choix, pas taper), mais le texte entier ça fait un tableau trop large trop moche. Juste une légende en dessous c'est probablement une bonne idée, je vais faire ça.

Oui une légende c'est très bien, et ça permet de mettre un peu plus de texte pour expliquer si nécessaire.

Bonne continuation en tout cas, j'espère que ton projet va avoir une longue vie :)

Super de voir des nouveaux projets dans les passerelles, et de voir que que tu cherches à faire une belle intégration avec des fonctionnalités récentes.

Est-ce que tu comptes te concentrer sur les messages, ou tu envisages à terme de faire des passerelles vers les blogs (XEP-0277) aussi ?

Petit détail : ça serait pas mal dans ton tableau de mettre en plus de l’icône le nom de la fonctionnalités (soit en tooltip, mais c'est pas super accessible et ça ne va pas sur appareils tactiles, soit écrit quelque part). Il y a un lien vers les XEP concernées ce qui est super, mais c'est très technique pour l'utilisateur lambda, et tout le monde ne connaît pas tous les numéros des XEPs par cœur (et ça éviterait de cliquer pour chaque colonne du tableau).

Bravo et bonne continuation.

Petite question sans mauvaise pensée du tout, mais comment arrivez-vous à regarder autant de chaînes ? Je me rends bien compte qu'il y a des publics variés sur ce site, à différentes phases de la vie, et avec plus ou moins de temps libre, mais même en regardant en accéléré ça représente un sacré paquet d'heures de visionnage. Vous regardez systématiquement toutes les vidéos ? vous sélectionnez ? Vous n'écoutez que l'audio ? Vous regardez aussi des films/séries ? Vous faites d'autres activités, du sport ?

Pour le coup les podcasts/baladodiffusions sont intéressants parce comme pour une émission de radio, on peut faire autre chose en même temps (si ça n'est pas trop demandant intellectuellement). D'ailleurs un journal du même ordre sur les podcasts m'intéresserait.

Bon puisqu'on parle de Python dans le navigateur et que c'est un sujet que je suis depuis des années, on peut mentionner aussi :

• Transcrypt qui transpile du Python en JavaScript : c'est du "plus ou moins python" avec des fonctionnalités activables via des options, et comme on a du JavaScript à l'arrivée, il n'y pas ou peu de pénalités par rapport à du JS natif.

• Brython qui transpile à la volée en JS aussi, avec une couche de compatibilité Python. Là on a du vrai Python, la compatibilité est très bonne, avec une légère pénalité au démarrage (surtout la première fois, après le cache aide) et à l’exécution. L'auteur principal est très actif et réactif si on rapporte un problème, et il y a une petit communauté autour.

J'utilise le dernier pour le frontend de mon client XMPP (Libervia), et c'est devenu un petit framework pour développer en Python avec XMPP en backend (pour gérer les données avec en prime la décentralisation, la gestion des comptes, et tout ce qu'apporte XMPP).

Par contre tout ça c'est sans l'IDE.

Pour faire un truc de style RAD, je pense qu'aujourd'hui j'utiliserais Godot : même si c'est un moteur de jeu à la base, il y a des options pour rendre la boucle principale plus adaptée à une application, et ça permet de produire facilement sur de nombreuses plateformes (les bureaux des OS les plus utilisés, le Web, Android, iOS, etc).
Le langage principal, GDScript, est inspiré et proche de Python (c'est aussi possible d'utiliser autre chose, Mono notamment). Il y a une communauté très active autour, et le développement d'applications avec semble être pris de plus en plus au sérieux (ils font en ce moment un appel aux développeurs d'applications pour faire un showreel, c'est à dire une vidéo de démo).

Enfin il y a RustPython à surveiller : un interprète Python en Rust, qui via WebAssembly peut tourner sur le web aussi. Le problème dans ces cas là (interpère Python complet via WebAssembly), c'est qu'on finit souvent avec des très gros fichiers à télécharger, pas idéal pour le web.

J'en passe quelques unes, notamment Pyodide, et probablement d'autres.

salut,

tu peux utiliser --user avec le pip système, ça installera dans ton ~/.local.

Je suis étonné de ne pas avoir vu cette info alors je l'ajoute :

Si toi ou quelqu'un·e d'autre a des choses à ajouter dans la newsletter/infolettre, on peut soit faire une PR rédigée sur https://github.com/xsf/xmpp.org/milestone/3, soit indiquer l'info (et si possible rédiger quelque chose) sur le pad à https://yopad.eu/p/xmpp-newsletter-365days, soit en parler sur la salon MUC commteam@muc.xmpp.org.

Et j'en profite pour dire merci à la commteam et aux traducteurs·rices/relecteurs·rices pour leur boulot régulier et très apprécié.

utilisateur de vim depuis très longtemps, j'ai voulu mettre un peu à jour les plugins il y a quelques mois.

Je n'en avais pas spécialement ressenti le besoin jusqu'ici parce que je fais majoritairement du Python et que c'est un langage suffisamment peu verbeux pour qu'il n'y ait pas vraiment besoin de complétion de partout (j'avais quand même YouCompleteMe et UltiSnips depuis quelques années).

Je suis passé à neovim (principalement parce que ça m'a permis de scripter facilement un changement de thème quand je passe sur un écran e-ink) et j'ai installé coc. C'est vraiment pas mal, faut reconnaître que le Language Server Protocol a permis de regrouper les efforts, et que ça apporte un certain confort.

Tout ça pour dire que sans utiliser directement Visual Studio, les outils que j'utilise en héritent en partie (mais sont libres).

Ah oui je me sens un peu con du coup !

Faut pas, l'informatique c'est très large et personne n'est omniscient.

Content d'avoir aidé.

Salut,

Hors, lorsqu'on remplace simplement le contenu d'une balise html avec le texte saisi, les retours chariot passent naturellement à la trappe. Pas terrible d'avoir toute la description d'un film condensée sur une seul longue ligne !

j'ai peut-être mal compris le problème mais les retours à la ligne peuvent être gardés avec la propriété CSS white-space (cf. https://developer.mozilla.org/fr/docs/Web/CSS/white-space), en utilisant la valeur pre-line par exemple.

Bon après ton projet semble gérer des langages de balisage, donc c'est plus poussé que ça.

C'est toujours le nom de l'association loi 1901. Ça m'a chagriné aussi, mais en dehors du monde francophone ça posait problème (à prononcer, ou des gens pensaient que c'était réservé aux français). C'était aussi l'occasion de simplifier les noms, des noms pour chaque frontaux ça perdait tout le monde, y compris des utilisateurs de la communauté XMPP.

Pour la petite histoire, quand on a créé l'association, on a envoyé un courriel aux bérus en disant en gros « on utilise ce nom informellement depuis quelques années, maintenant on aimerait créer une assoce et on aimerait vérifier que ça ne vous pose pas de problème avant ». Ils (PariA au nom du groupe) nous ont répondu très gentiment, en disant non seulement qu'ils connaissaient déjà (tombés dessus avec le nom) mais aussi que ça avait l'air dans l'esprit, ça nous avait bien fait plaisir.

Merci beaucoup à l'équipe de Linuxfr.org ainsi qu'aux éditions Eyrolles et ENI.

Linuxfr fait partie de ma vie numérique depuis de nombreuses années et il a su traverser les années en s'améliorant tout en gardant son esprit d'origine. C'est un gros boulot de maintenir et modérer un tel site (sans compter les mises en demeures, spams et autres trolls), et c'est vraiment apprécié. Bravo à vous, et bonne continuation.

Merci ! Oui NLnet est une sacrée bouffée d'oxygène, ils aident beaucoup le libre, et plusieurs projets XMPP en bénéficient ou en ont bénéficié. C'est un gros projet qu'ils ont validé pour Libervia, et ça devrait aider au développement d'XMPP en général et ne pas seulement profiter à ce client.

Bonjour,

j'ai répondu il y a peu de temps, vous avez dû recevoir. Et merci beaucoup !

Ah oui en effet, désolé. J'ai adapté la note de version de mon blog où les personnes qui suivent sont supposées connaître le projet, mais il serait judicieux de rapidement le présenter ici en intro.

Est-ce qu'un modérateur ou une modératrice peut ajouter le petit texte suivant dans le chapeau ? Merci :)

Libervia est un client XMPP multi-interfaces qui ne se concentre pas uniquement sur la messagerie instantanée et intègre des fonctionnalités telles que le blogage, le partage de fichiers, les albums photos, ou encore la gestion d'événements. Il a été mentionné plusieurs fois sur ce site sous son ancien nom « Salut à Toi ».

J'ai aussi noté une typo :

Le site officiel a été mise mis à jour

Merci, ainsi que pour la modération rapide.

C'est exact, si on n'est pas en UTC c'est toujours bien de préciser la TZ.

Même en UTC, dans ce cas il faut ajouter un Z à la fin. La raison est que tu montres que la zone est spécifiée, autrement tu ne peux pas savoir si c'est UTC ou un indicateur de fuseau manquant.

Tiens petite note rigolote au passage, UTC est un mélange de l'abréviation comme elle devrait être en anglais (CUT pour « coordinated universal time ») est en français (TUC pour « temps universel coordonné »), histoire de mettre tout le monde d'accord (enfin au moins les anglophones et francophones).

Ça dépend du contexte. Quand t'es à l'école par exemple, et que t'as des devoirs à rendre, c'est souvent quelques jours après. L'année t'es censé déjà la connaître, et le mois probablement aussi, du coup l'info qui t'intéresse le plus c'est le numéro du jour, et c'est ce qui est mis en premier. Ça ne t'arrive jamais d'omettre l'année pour un RDV par exemple ? Genre « RDV le 30/11 » ? Ou tout simplement « On se voit le 4 » ou même « on se voit samedi » ?

Si tu veux classer des fichiers sur plusieurs années, là oui la date au format ISO est nettement plus intéressante. Et si tu veux vraiment être « civilisé » comme tu dis, tu spécifies le fuseau horaire et pas juste yyyy-mm-dd HH:MM:SS ;)

Le truc que j'ai toujours trouvé complètement illogique par contre, c'est les dates format É-U : mois/jour/année . Si quelqu'un a une explication rationnelle à ça, je suis preneur.

oui AngularJS, désolé (en plus je connaissais la subtilité).

edit: on utilise aussi typescript depuis un bon moment dans le frontend.

Alors je ne suis pas la personne la mieux placée pour en parler parce que je fais principalement du backend et je touche assez rarement au frontend.

D'un côté React a été introduit par l'équipe qui a commencé à travailler sur le planning (composant additionnel mentionné dans la dépêche), et de l'autre Angular a vue une nouvelle version qui cassait beaucoup de choses. Il y a eu des réunions (VueJS a aussi été mentionné à l'époque), et après avoir discuté les avis des un·e·s et des autres, il a été décidé de passer à React parce que c'est un cadriciel très utilisé, avec un développement soutenu et qu'on ne risque pas de voir disparaître de jour au lendemain. React est aussi très rapide, et c'est important pour nous parce qu'on a beaucoup d'éléments qui peuvent être affichées sur une page.

D'autre part, et c'est sans doute le plus important, les dévs frontends sont contents avec.

Ça serait sans doute utilisable, mais au prix de pas mal d'adaptations. Par exemple, dans Superdesk tu as plutôt un·e rédacteur·ice qui écrit l'article, qui est relu et commenté/corrigé par quelqu'un d'autre. Dans DLFP, tu as une édition collaborative où n'importe qui avec un compte peut modifier l'article en cours, c'est différent et ça demanderait du développement spécifique.

Il n'y a pas de tchat/tribune dans SD (ça a été discuté, mais personne n'en a actuellement vraiment besoin, il y a souvent d'autres messageries déjà en place).

Superdesk est vraiment un outil conçu pour le monde professionnel, avec beaucoup d'options, un vocabulaire très spécifique, les articles ont généralement nombre de métadonnées (parfois remplies automatiquement, parfois manuellement), etc. DLFP nécessite quelque chose de plus simple et accessible.

Sans doute que Publisher pourrait être utilisé pour développer une interface utilisateur similaire au DLFP qu'on connaît, mais là encore ça demanderait du développement.

Bref, DLFP est un site spécialisé avec une interface particulière. On est dans un site destiné au grand public (même si c'est un public plutôt technique) et où tout le monde peut rédiger un article ; il faut donc une interface accessible et relativement simple, avec juste des permissions privilégiés pour les modérateurs et admins.

Superdesk est un site destiné à un milieu professionnel, l'interface est nettement plus complexe (bien qu'accessible, je pense que l'interface est bien faite, mais ça reste un outil pro qui demande de pouvoir faire beaucoup de choses). Ce sont plutôt des articles qu'une équipe bien définie peut rédiger (plus potentiellement des rédacteurs externes), avec d'autres personnes pour les relectures et corrections, et un système de revue pour la validation.

Tout est toujours possible si on y consacre le temps et les moyens nécessaire, mais a priori SD n'est pas l'outil le plus adapté pour un site comme DLFP.

Il me semble que le moteur actuel fonctionne bien, pourquoi changer ?

Est-ce qu’il est possible de chiffrer les données sur le serveur pour les chiffrer / déchiffrer dans le navigateur ?

Pour être sûr de bien comprendre : tu parles de chiffrement de bout en bout ? En gros un article serait entièrement chiffré dans le navigateur, et le serveur ne ferait que du stockage de blob ? Si c'est bien ça ça n'est pas possible à l'heure actuelle, mais cette approche aurait beaucoup de problèmes : on perd la recherche (qui est un outil indispensable pour des journalistes) vu que le serveur ne voir plus rien et ne peut donc plus indexer (et pas question de faire de la recherche dans le navigateur, il faudrait toutes les archives, c'est potentiellement énorme), et il faudrait partager des clefs entre collaborateurs, ce qui complique beaucoup. Je ne dis pas que c'est impossible, il faudrait voir un cas d'usage très précis et peser les conséquences. Il serait sans doute possible de ne chiffrer qu'une partie des données, et en garder quelques-unes pour l'indexation.

Si tu parles de chiffrement au repos, on utilise MongoDB/ElasticSearch, donc les méthodes compatibles avec sont disponibles.

Quels sont les langages utilisés pour l’implémentation.

Le backend est en Python (avec Eve, Flask, Celery) et le frontend est, sans surprise, en JavaScript (initialement avec Angular, c'est désormais du React et les parties encore en Angular sont portées petit à petit).

Merci pour les encouragements, je ferai suivre à l'équipe.

Ça me semble un peu trop pour un particulier, c'est un logiciel vraiment fait pour le travail en équipe, et je pense qu'il y a des solutions plus simples pour faire un blog ou similaire. Pour un journaliste indépendant ça pourrait être intéressant ne serait-ce que pour la gestion des sources et des archives.

Pour des petites structures par contre, surtout tout ce qui s'occupe de la rédaction régulière d'articles, là ça commence à être plus adapté.

Évidemment dès qu'on tape dans le journalisme, même pour des organisations petites, là on est en plein dans le cœur de métier.

L'installation n'est pas très compliquée avec docker, pour voir si ça correspond à un cas d'usage, le mieux est encore d'essayer.

Non non je suis là, vraiment je ne disparais pas, et j'ai dis que j'allais compléter Superdesk dans les semaines à venir il n'y a pas si longtemps ! J'ai juste un emploi du temps très, très chargé, mais il n'y a pas de date de péremption sur les dépêches en cours non ?

Kivy idem, il n'y pas tant de boulot pour la finir, il ne faut pas la supprimer. Quand on m'a relancé en fin d'année dernière, j'ai dis que ces 2 dépêches seraient finies dans l'année, ça laisse encore près de 2 mois :)

Je comprends que c'est frustrant de voir ces dépêches qui mettent du temps, j'en suis désolé, c'est vraiment difficile de composer avec tout, mais elles ne sont pas oubliées (en tout cas pas celles que j'ai initiées).