Ç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.
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.
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).
Le nom draft, hérité de l'IETF, portait à confusion et a récemment été renommé en stable justement pour éviter ce genre de mauvaise compréhension.
Jitsi qui est une des solutions les plus populaires pour la visioconférence de nos jours est basée sur XMPP/Jingle, et c'est ce qui est actuellement utilisé dans Matrix aussi pour les visioconférences (à plus de 2).
La bibliothèque libwebrtc de Google qui est utilisé par la grande majorité des implémentations de webrtc et de tout ce qui fait de la visioconférence hérite en partie de libjingle (Jingle est originairement une contribution de Google à XMPP).
Bref je n'ai pas franchement l'impression que Jingle soit un raté.
XMPP gère des appareils multiples (via les ressources) depuis le début, et pendant très, très longtemps ça n'était pas possible sur les autres messageries (Skype te déconnectait par exemple).
L'historique quand tu n'es pas là (ou "backlog") c'est sur XMPP que je l'ai vu en premier. Après sa s'est modernisé avec MAM et Carbon pour suivre l'évolution des usages (et c'est ce qui fait la force de XMPP et que c'est toujours aujourd'hui le protocole le plus adapté à mon avis: il est extensible et s'adapte aux évolutions).
Mais oui il y a eu des erreurs, comme des clients pas très facile à aborder (Psi notamment qui est je pense le premier client que j'ai utilisé n'est pas très ergonomique, et la découverte de services était présenté de manière trop brute aux utilisateurs).
D'un autre côté, il faut aussi garder en tête qu'il y a eu des tâtonnements partout et que les interfaces clonés qu'on a aujourd'hui sont le fruit de ces essais (et des gros budgets de recherche en UI/UX dans les grosses boîtes).
XMPP a mis du temps à s'adapter aux téléphones (un peu), mais ça reste raisonnable quand on pense au peu de ressources par rapport aux gros acteurs (beaucoup de clients sont développés par une poignet de développeur·se·s, voir un·e seul·e).
Côté serveurs il y a un peu plus de moyens chez certains (EjabberD par exemple), et c'est pas pour rien que c'est à la base de gros acteurs comme Whatsapp, de nombreux jeux, ou les notifications push d'Apple.
En tout cas, si toutes les critiques à faire c'est sur des problèmes réglés depuis des années, c'est que ça ne va pas si mal.
Pour vim : il est indispensable de remapper certaines touches, mais le wiki bépo explique très bien comment faire.
Le seul bémol, ce sont les raccourcis claviers pas toujours adaptés et qu'il faut réajuster…C'est même parfaitement chiant. Par exemple, sur Blender, il y a littéralement des centaines de raccourcis claviers et c'est une gymnastique des doigts ou un travail de recomposition qui sont obligatoires…
C'est exactement ce qui me pose problème. Au final je pense opter pour un clavier EurKey, ce qui ne m'empêchera pas de taper en azerty à l'aveugle si besoin, ou d’apprendre le bépo/béop toujours à l'aveugle (certain·e·s recommandes d'ailleurs d'apprendre le bépo à l'aveugle).
Oui ce n'est pas tant une question de vitesse de frappe que de confort pour le développement. Pour les détails je travaille de la maison et je peux utiliser mon ordi perso, le changement de clavier n'est donc pas nécessaire. Je peux taper à l'aveugle, en fait je me pose la question actuellement parce que j'envisage de faire graver une disposition sur un clavier d'ordinateur portable. Si je me déplace j'ai généralement ma machine, et de toute façon ce n'est pas parce que je tape dans telle disposition que je vais oublier les autres.
Pour le moment j'hésite principalement entre l'AZERTY AFNOR et le EurKey, je suis en train de tester ce dernier. A priori je m'en sort pas trop mal avec (je connais déjà à peu près le qwerty), la transition devrait se faire facilement.
Le béop programmeur m'intéresse beaucoup aussi, mais je n'ai pas le temps de m'y investir actuellement, et je veux éviter d'avoir à passer des heures à reconfigurer mes logiciels pour qu'ils soient utilisables.
Pour celles et ceux qui ont connu ce dessin animé/manga, Bébel a servi de modèle au personnage.
Outre les classiques qu'on lit partout en ce moment, il est aussi à revoir dans Week-end à Zuydcoot qui raconte la débâcle de 1940 et l'opération Dynamo, avec une scène impressionnante de mitraillage par avion sur une plage entre Dunkerque et Bray-Dunes, suivie de l'éjection du pilote allemand au milieu de ceux qu'il vient de viser.
merci pour ce chouette entretien, c'est très agréable de lire le travail d'artistes, ça change du développement logiciel.
Petite question pour un non initié, qu'est-ce que le « in-between » ?
Bravo pour réussir à continuer sur la durée, c'est vraiment pas évident de porter un gros projet à bouts de bras quand on est une petite équipe avec peu de moyens.
XMPP est très utilisé, mais ça n'est pas toujours visible ou fédéré. Quelques chiffres sont dispos sur https://xmpp.org/uses/instant-messaging.html (mais j’exclurais Whatsapp qui a utilisé une variante maison de XMPP au début). C'est aussi utilisé dans le domaine du jeu, médical ou militaire, ou comme base pour des services (de mémoire les plateformes de notification — push — d'Apple et de Google utilisent XMPP, enfin si c'est encore le cas). C'est peu utilisé (très peu en comparaison à IRC) pour les projets libres, ça c'est vrai. Avec les évolutions énormes en cours (Snikket, vidéoconférence sur plusieurs projets, interface de Gajim, chiffrement de bout en bout sur Movim, passerelle ActivityPub sur laquelle je travaille), je m'attends à une sérieuse montée en puissance dans les 1 ou 2 années à venir.
Pour Haiku on se pose la question (entre XMPP et Matrix) et pour l'instant le sujet est suspendu en attente d'avoir un bon client natif pour l'un ou pour l'autre.
Qu'est-ce que tu appelles un bon client natif ? Quelles fonctionnalités ? Et natif sur Haiku ou d'autres plateformes ? Gajim ne fonctionne pas sur Haiku ?
Triste de voir ce genre de chose se passer sur un des piliers historiques du logiciel libre (entre autres choses)
Après quel que soit les protocoles et logiciels de votre choix, c'est une fois de plus un événement qui montre l'importance de la décentralisation (et malgré cela, on voit encore, y compris chez les libristes et autres publics qui se voudraient avertis, les mêmes erreurs se répéter).
j'avoue (honteusement) que le XMPP est un protocole dont je ne sais presque rien
Oui ben c'est normal, honnêtement se farcir les protocole c'est pas la chose la plus excitante du monde dans le développement.
Le rôle des bibliothèques c'est justement de rendre ça plus facile d'accès sans avoir à trop s’inquiéter des détails internes. Si t'as besoin d'aide, tu peux me contacter ou aller sur un salon dédié. Avec JavaScript, je vois par exemple que ça a l'air assez facile d'utiliser Pubsub via stanzaJS.
En gros dans ton cas, l'avantage c'est que tu peux utiliser un serveur XMPP existant (https://jabberfr.org/ par exemple) et implémenter la synchro via Pubsub par dessus, et tu as ainsi une implémentation prête à l'emploi pour les notifications, permissions, et abonnements (et dans quelques mois le chiffrement de bout en bout), ça ne devrait pas être si compliqué à greffer sur une archi existante, même centralisée.
Enfin bref, c'est juste une suggestion tu en fais ce que t'en veux. C'est surtout que j'aimerais bien voir une compatibilité entre les différentes options libres :)
Pour info, j'ai aussi travaillé sur une liste de courses avec Libervia, basée sur XMPP. Elle est donc décentralisée avec un système de permissions (dans la capture ci-dessous il suffit de cliquer sur manage invitations et de choisir les personnes à inviter).
Ton projet est bien avancé mais vu que tu n'as pas encore fait le système de permission/synchronisation, peut être que tu peux envisager d'utiliser XMPP pour ça (avec une des bibliothèques disponibles ça devrait être relativement facile) ? Ça serait chouette que ça soit compatible, et ça t'éviterait d'avoir à réinventer la roue.
Depuis quelque temps, il y a Poetry qui a le vent en poupe, il gère tout ce qu'il faut pour le packaging, la publication, et l'exécution (y compris les environnements virtuels dont on parle ici). Je n'y suis pas encore passé moi même donc je n'ai pas de retour d'expérience, mais ça semble être vraiment bien.
J'avais aussi vu passer un outil qui utilisait __pypackages__ (cf. PEP 582) et qui n'avait donc pas besoin d’environnement virtuel. J'ai oublié le nom, mais après une recherche je suis tombé sur PDM, c'était peut-être celui-là.
Petit retour d'expérience sur Latex, que j'utilise avec un mélange de Kile et Vim :
ça demande un apprentissage, et il y a parfois voire souvent besoin de chercher sur le net, donc ça peut être exclus d'après tes critères
il y a des erreurs de compilations, ça peut taper sur les nerfs quand on ne sait pas d'où ça vient, mais si tu sauvegardes/compile régulièrement, tu devrais les voir suffisamment tôt pour trouver le problème.
il accuse son age, et n'est pas toujours très intuitif (les erreurs peuvent être cryptiques, il faut activer Unicode et les paquets qui correspondent à ce que tu veux avant que ça soit agréable à utiliser),
Ça c'est pour les mauvais côtés maintenant les bons :
le résultat est souvent très (très très) bien, et correspond aux normes typographiques
c'est du texte, ça se sauvegarde facilement et tu peux versionner sans problème
c'est du texte, tu peux utiliser tous les outils standards pour faire des modifications, tu peux faire un script qui t'importe automatiquement toutes les images d'un répertoire si ça t'arrange pas exemple.
ça s'exporte dans n'importe quoi (PDF, ePub, HTML, etc.). Avec Pandoc tu peux très certainement en faire du RST voire du ODT, donc possibilité de changer de train si tu changes d'idée.
une fois que t'as compris le truc, ça te fait une grosse partie du boulot (tout ce qui est références, figures, table des matières, numérotation, etc. est fait automatiquement et dans les règles de l'art, et ça s'adapte relativement facilement à tes besoins)
une fois que t'as compris le truc, tu te concentres sur le contenu, la mise en page est gérée en grande partie automatiquement, et tu ajustes comme tu l'entends vraiment à la fin
il y a une grosse communauté et beaucoup de ressources/paquets/thèmes
c'est utile à connaître, ça peut servir pour faire des présentations, pour écrire des formules mathématiques, d'autres livres à l'avenir
Sphinx est super pour de la doc (je l'utilise) mais ça ne serait pas mon outil de choix pour un livre. Scribus j'avais utilisé à ses début, c'était déjà bien et je pense que c'est super aujourd'hui, mais je l'utiliserais plutôt pour un dépliant ou un magazine.
Bref, pour un livre je choisirais très probablement Latex, mais c'est un choix qui demande un certain investissement (qui vaut le coup sur le long terme à mon avis), il n'est pas forcément le bon pour tout le monde (et puis je suis développeur).
J'ai une tablette Nexus 7 (flo) de 2013 achetée il a plusieurs années d'occasion. Elle est officiellement supportée (après repartitionnement) et tourne sous Lineage OS 18.1 avec mises à jour régulières : c'est fluide, stable, et fait parfaitement tourner ce dont on a besoin (sans gapps, ni même microG, mais ça pourrait s'installer facilement).
Il y aurait sans doute beaucoup moins de gaspillage électronique si ce genre de projets, et le libre en général étaient plus répandus.
[^] # Re: dates et adresses
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 10. Dernière modification le 30 novembre 2021 à 14:03.
Ç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.
[^] # Re: Deux questions
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Superdesk : la salle de rédaction virtuelle libre. Évalué à 3. Dernière modification le 27 novembre 2021 à 14:26.
oui AngularJS, désolé (en plus je connaissais la subtilité).
edit: on utilise aussi typescript depuis un bon moment dans le frontend.
[^] # Re: Deux questions
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Superdesk : la salle de rédaction virtuelle libre. Évalué à 5.
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.
[^] # Re: Félicitations
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Superdesk : la salle de rédaction virtuelle libre. Évalué à 10.
Ç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.
[^] # Re: Félicitations
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Superdesk : la salle de rédaction virtuelle libre. Évalué à 2.
Il me semble que le moteur actuel fonctionne bien, pourquoi changer ?
[^] # Re: Deux questions
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Superdesk : la salle de rédaction virtuelle libre. Évalué à 10.
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.
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).
[^] # Re: Félicitations
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Superdesk : la salle de rédaction virtuelle libre. Évalué à 8.
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.
# mais je ne disparais pas !
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal De la sédimentation dans l'espace de rédaction. Évalué à 8.
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).
[^] # Re: Pas trop étonnant
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Comme une impression de déjà vu…. Évalué à 10.
Le nom
draft, hérité de l'IETF, portait à confusion et a récemment été renommé enstablejustement pour éviter ce genre de mauvaise compréhension.Jitsi qui est une des solutions les plus populaires pour la visioconférence de nos jours est basée sur XMPP/Jingle, et c'est ce qui est actuellement utilisé dans Matrix aussi pour les visioconférences (à plus de 2).
La bibliothèque libwebrtc de Google qui est utilisé par la grande majorité des implémentations de webrtc et de tout ce qui fait de la visioconférence hérite en partie de libjingle (Jingle est originairement une contribution de Google à XMPP).
Bref je n'ai pas franchement l'impression que Jingle soit un raté.
XMPP gère des appareils multiples (via les ressources) depuis le début, et pendant très, très longtemps ça n'était pas possible sur les autres messageries (Skype te déconnectait par exemple).
L'historique quand tu n'es pas là (ou "backlog") c'est sur XMPP que je l'ai vu en premier. Après sa s'est modernisé avec MAM et Carbon pour suivre l'évolution des usages (et c'est ce qui fait la force de XMPP et que c'est toujours aujourd'hui le protocole le plus adapté à mon avis: il est extensible et s'adapte aux évolutions).
Mais oui il y a eu des erreurs, comme des clients pas très facile à aborder (Psi notamment qui est je pense le premier client que j'ai utilisé n'est pas très ergonomique, et la découverte de services était présenté de manière trop brute aux utilisateurs).
D'un autre côté, il faut aussi garder en tête qu'il y a eu des tâtonnements partout et que les interfaces clonés qu'on a aujourd'hui sont le fruit de ces essais (et des gros budgets de recherche en UI/UX dans les grosses boîtes).
XMPP a mis du temps à s'adapter aux téléphones (un peu), mais ça reste raisonnable quand on pense au peu de ressources par rapport aux gros acteurs (beaucoup de clients sont développés par une poignet de développeur·se·s, voir un·e seul·e).
Côté serveurs il y a un peu plus de moyens chez certains (EjabberD par exemple), et c'est pas pour rien que c'est à la base de gros acteurs comme Whatsapp, de nombreux jeux, ou les notifications push d'Apple.
En tout cas, si toutes les critiques à faire c'est sur des problèmes réglés depuis des années, c'est que ça ne va pas si mal.
[^] # Re: Retour sur le bépo
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Retour d'expérience sur les dispositions de claviers ?. Évalué à 2.
C'est exactement ce qui me pose problème. Au final je pense opter pour un clavier EurKey, ce qui ne m'empêchera pas de taper en azerty à l'aveugle si besoin, ou d’apprendre le bépo/béop toujours à l'aveugle (certain·e·s recommandes d'ailleurs d'apprendre le bépo à l'aveugle).
[^] # Re: La disposition la plus courante dans ton pays
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Retour d'expérience sur les dispositions de claviers ?. Évalué à 2.
Merci pour les réponses.
Oui ce n'est pas tant une question de vitesse de frappe que de confort pour le développement. Pour les détails je travaille de la maison et je peux utiliser mon ordi perso, le changement de clavier n'est donc pas nécessaire. Je peux taper à l'aveugle, en fait je me pose la question actuellement parce que j'envisage de faire graver une disposition sur un clavier d'ordinateur portable. Si je me déplace j'ai généralement ma machine, et de toute façon ce n'est pas parce que je tape dans telle disposition que je vais oublier les autres.
Pour le moment j'hésite principalement entre l'AZERTY AFNOR et le EurKey, je suis en train de tester ce dernier. A priori je m'en sort pas trop mal avec (je connais déjà à peu près le qwerty), la transition devrait se faire facilement.
Le béop programmeur m'intéresse beaucoup aussi, mais je n'ai pas le temps de m'y investir actuellement, et je veux éviter d'avoir à passer des heures à reconfigurer mes logiciels pour qu'ils soient utilisables.
# Cobra, week-end à Zuydcoot
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Belmondo bronsonisé. Évalué à 4.
Pour celles et ceux qui ont connu ce dessin animé/manga, Bébel a servi de modèle au personnage.
Outre les classiques qu'on lit partout en ce moment, il est aussi à revoir dans Week-end à Zuydcoot qui raconte la débâcle de 1940 et l'opération Dynamo, avec une scène impressionnante de mitraillage par avion sur une plage entre Dunkerque et Bray-Dunes, suivie de l'éjection du pilote allemand au milieu de ceux qu'il vient de viser.
[^] # Re: chouette entretien
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Interview d’Aryeom dessinatrice de marmottes (mais pas que). Évalué à 4. Dernière modification le 26 juillet 2021 à 15:11.
OK, c'est que j'avais soupçonné avec le nom, merci.
Une note serait bienvenue oui.
# chouette entretien
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Interview d’Aryeom dessinatrice de marmottes (mais pas que). Évalué à 10.
Coucou,
merci pour ce chouette entretien, c'est très agréable de lire le travail d'artistes, ça change du développement logiciel.
Petite question pour un non initié, qu'est-ce que le « in-between » ?
Bravo pour réussir à continuer sur la durée, c'est vraiment pas évident de porter un gros projet à bouts de bras quand on est une petite équipe avec peu de moyens.
[^] # Re: Triste
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 7.
XMPP est très utilisé, mais ça n'est pas toujours visible ou fédéré. Quelques chiffres sont dispos sur https://xmpp.org/uses/instant-messaging.html (mais j’exclurais Whatsapp qui a utilisé une variante maison de XMPP au début). C'est aussi utilisé dans le domaine du jeu, médical ou militaire, ou comme base pour des services (de mémoire les plateformes de notification — push — d'Apple et de Google utilisent XMPP, enfin si c'est encore le cas). C'est peu utilisé (très peu en comparaison à IRC) pour les projets libres, ça c'est vrai. Avec les évolutions énormes en cours (Snikket, vidéoconférence sur plusieurs projets, interface de Gajim, chiffrement de bout en bout sur Movim, passerelle ActivityPub sur laquelle je travaille), je m'attends à une sérieuse montée en puissance dans les 1 ou 2 années à venir.
Qu'est-ce que tu appelles un bon client natif ? Quelles fonctionnalités ? Et natif sur Haiku ou d'autres plateformes ? Gajim ne fonctionne pas sur Haiku ?
[^] # Re: Triste
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 7.
Sauf erreur ou évolution, cela ne compte que des serveurs Prosody qui ont installé un plugin particulier, ça limite beaucoup.
# Triste
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 6.
Triste de voir ce genre de chose se passer sur un des piliers historiques du logiciel libre (entre autres choses)
Après quel que soit les protocoles et logiciels de votre choix, c'est une fois de plus un événement qui montre l'importance de la décentralisation (et malgré cela, on voit encore, y compris chez les libristes et autres publics qui se voudraient avertis, les mêmes erreurs se répéter).
[^] # Re: Merci pour ton travail de traduction
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Lettre d'information XMPP d'avril 2021. Évalué à 3.
idem, travail utile et apprécié, mais c'est compréhensible de vouloir passer à autre chose. Merci !
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Our Shopping List : liste de courses partagée et libre. Évalué à 3.
Oui ben c'est normal, honnêtement se farcir les protocole c'est pas la chose la plus excitante du monde dans le développement.
Le rôle des bibliothèques c'est justement de rendre ça plus facile d'accès sans avoir à trop s’inquiéter des détails internes. Si t'as besoin d'aide, tu peux me contacter ou aller sur un salon dédié. Avec JavaScript, je vois par exemple que ça a l'air assez facile d'utiliser Pubsub via stanzaJS.
En gros dans ton cas, l'avantage c'est que tu peux utiliser un serveur XMPP existant (https://jabberfr.org/ par exemple) et implémenter la synchro via Pubsub par dessus, et tu as ainsi une implémentation prête à l'emploi pour les notifications, permissions, et abonnements (et dans quelques mois le chiffrement de bout en bout), ça ne devrait pas être si compliqué à greffer sur une archi existante, même centralisée.
Si tu veux une idée du fonctionnement, j'avais écris un article de vulgarisation ici même : Parlons XMPP - épisode 8 - PubSub et PEP.
Enfin bref, c'est juste une suggestion tu en fais ce que t'en veux. C'est surtout que j'aimerais bien voir une compatibilité entre les différentes options libres :)
# XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Our Shopping List : liste de courses partagée et libre. Évalué à 6.
Salut et bravo pour ton projet.
Pour info, j'ai aussi travaillé sur une liste de courses avec Libervia, basée sur XMPP. Elle est donc décentralisée avec un système de permissions (dans la capture ci-dessous il suffit de cliquer sur
manage invitationset de choisir les personnes à inviter).Ton projet est bien avancé mais vu que tu n'as pas encore fait le système de permission/synchronisation, peut être que tu peux envisager d'utiliser XMPP pour ça (avec une des bibliothèques disponibles ça devrait être relativement facile) ? Ça serait chouette que ça soit compatible, et ça t'éviterait d'avoir à réinventer la roue.
[^] # Re: tout bêtement
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Our Shopping List : liste de courses partagée et libre. Évalué à 2. Dernière modification le 08 mai 2021 à 10:19.
Par curiosité, c'est un message texte simple que vous supprimez ensuite (ou barrez ?), ou Telegram gère une forme de liste dynamique ?
# Poetry et PEP 582
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Python — partie 7 — Environnements virtuels. Évalué à 9.
Depuis quelque temps, il y a Poetry qui a le vent en poupe, il gère tout ce qu'il faut pour le packaging, la publication, et l'exécution (y compris les environnements virtuels dont on parle ici). Je n'y suis pas encore passé moi même donc je n'ai pas de retour d'expérience, mais ça semble être vraiment bien.
J'avais aussi vu passer un outil qui utilisait
__pypackages__(cf. PEP 582) et qui n'avait donc pas besoin d’environnement virtuel. J'ai oublié le nom, mais après une recherche je suis tombé sur PDM, c'était peut-être celui-là.# Latex
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Outils pour écrire un livre. Évalué à 8. Dernière modification le 05 mai 2021 à 10:41.
Petit retour d'expérience sur Latex, que j'utilise avec un mélange de Kile et Vim :
Ça c'est pour les mauvais côtés maintenant les bons :
Sphinx est super pour de la doc (je l'utilise) mais ça ne serait pas mon outil de choix pour un livre. Scribus j'avais utilisé à ses début, c'était déjà bien et je pense que c'est super aujourd'hui, mais je l'utiliserais plutôt pour un dépliant ou un magazine.
Bref, pour un livre je choisirais très probablement Latex, mais c'est un choix qui demande un certain investissement (qui vaut le coup sur le long terme à mon avis), il n'est pas forcément le bon pour tout le monde (et puis je suis développeur).
[^] # Re: Et les téléphones basiques (aka dumb phones) ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 2.
Il y a le ZeroPhone, mais je ne sais pas s'il est encore en développement.
[^] # Re: LineageOS
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 6.
J'ai une tablette Nexus 7 (flo) de 2013 achetée il a plusieurs années d'occasion. Elle est officiellement supportée (après repartitionnement) et tourne sous Lineage OS 18.1 avec mises à jour régulières : c'est fluide, stable, et fait parfaitement tourner ce dont on a besoin (sans gapps, ni même microG, mais ça pourrait s'installer facilement).
Il y aurait sans doute beaucoup moins de gaspillage électronique si ce genre de projets, et le libre en général étaient plus répandus.