LeBouquetin a écrit 1919 commentaires

Merci pour le retour en tout cas.

Travailler ensemble n'est pas naturel pour beaucoup de personnes. Souvent c'est vu comme je fais ma partie et je la livre, processus dans lequel il est exclu d'intervenir. Cela peut d'ailleurs se comprendre pour des raisons d'efficacité. Mais il y a également la notion de transparence qui est souvent rejetée, type : "non je te montre pas c'est pas terminé. Je te montrerai une fois que j'ai résolu les derniers points ".

On retrouve ça très souvent aussi dans le domaine du développement.

La collaboration encapsule la production d'information, mais également sa diffusion, la recherche, les sollicitations.

La valeur ajoutée de Tracim devient évidente lorsqu'on exploite ces différents aspects :

• un évènement n'est pas mis dans son agenda perso puis dans l'agenda partagé mais directement dans l'agenda partagé (que chacun intègre avec son agenda perso)
• on documente les nouvelles révisions de document
• on considère le travail comme appartenant à l'équipe et non à l'individu
• on veut affecter des tâches à des personnes (y compris associées à des documents précis) et en suivre l'exécution
• on communique avec l'équipe
• on veut garder trace de l'histoire pour permettre aux nouveaux venus d'entrer dans le sujet le plus rapidement possible avec toutes les informations en main

D'ailleurs au sujet de l'édition en ligne, je serais très curieux de connaître le nombre de personnes qui l'utilise vraiment pour de la collaboration. Mon ressenti est surtout que c'est utilisé comme un confort d'utilisation : mon document est toujours disponible et la dernière version, quel que soit l'appareil à partir duquel j'y accède.

Les développeurs qui n'ont pas de PC pour télétravailler ou qui télétravaillent avec un ordinateur personnel ont forcément été confrontés à un moment ou à un autre à une version de leur code qui est malheureusement sur l'autre machine.

C'est un sujet super intéressant sur lequel on a passé du temps sur Tracim :

1. les gestionnaires de version pourraient s'appuyer sur le souce XML, mais le contenu est fortement structuré et faire des diff d'arbres est complexe et pas de résolution unique
2. En conséquence du point ci-dessus, les diff de documents bureautique c'est compliqué, ça marchotte quand ça existe mais rien de très abouti
3. Je n'ai jamais regardé les outils de fusion existant, mais logiquement vu 1 et 2, ça ne peut pas se résoudre simplement

Je rajouterai aussi :

1. les utilisateurs d'outils bureautique veulent des solutions simples à utiliser plus que des solutions rigoureuses et puissantes
2. La complexité du concept de branches et révisions, etc sont au delà de ce qu'on recherche dans un outil collaboratif bureautique.

Pour des gens dont le quotidien est fait de rédaction collaborative, ça serait sûrement le pied - mais ceux-là utilisent souvent déjà des outils à base de fichiers source textuels.

Par exemple les documents embarquent des solutions de commentaires, de révision, etc, mais qui les utilise ? Peu de personnes (y compris les gens au fait tels que les développeurs).

Dans ce contexte, l'édition collaborative en ligne est la seule solution qui réponde. C'est pas l'idéal mais ça marche - en tout cas sur des documents modestes.

La rédaction de longs documents reste dans tous les cas plus confortable sur son ordinateur, avec une suite bureautique native.

Merci pour tous ces retours.

Le retour "dans Tracim on ne passe pas facilement d'une application à une autre alors que les autres solutions le permettent" me semble inapproprié : le paradigme de Tracim, c'est basé sur les espaces de collaboration, pas sur les applications.

Je ne connais pas odoo, je connais un peu nextcloud. Dans Nextcloud, par exemple, il me semble pas que tu retrouves en un clic les notes du projet courant : tu bascules d'une application à une autre, toutes données comprises.

Le paradigme Tracim est plutôt une forge de collaboration. Dans gitlab par exemple, tu ne bascules pas de "tous les codes sources à tous les tickets" : tu es dans un contexte projet.

Ça ne veut pas dire qu'il n'y a pas des choses à améliorer ; mais prendre Tracim comme une somme d'applications c'est voué à la déception car ce n'est pas ça qui le définit.

Tracim s'installe facilement avec l'image docker ; il faut un serveur dédié ceci dit.

Nextcloud, si je ne me trompe pas, c'est du PHP donc + classique comme Starck technique.

Par contre, aujourd'hui souvent on s'attend à avoir de l'édition collaborative type collabora online, et la la complexité technique de Tracim n'est plus un sujet : c'est pas plus compliqué que Collabora Online.

j'aurais préféré Tracim, mais je n'ai pas réussi à convaincre :-(

Ah c'est intéressant ça. Quelles ont été les objections ?

Ça fait probablement 5 ans qu'on voulait faire un client de synchronisation et qu'on a creusé et abandonné des pistes. Et qu'on avait fini par laisser tomber, faute de priorité et de financement (on n'a pas d'investisseurs à Algoo, on développe ce que nos clients demandent et financent).

Quand bux m'a montré son projet, j'ai été emballé et d'autant plus que le projet trsync s'est développé sans nécessité de faire évoluer le cœur de Tracim : trsync s'appuie sur les APIs et sur le websocket pour établir la communication bidirectionnelle. Comme l'interface utilisateur en fait - mais du coup l'API est largement suffisante pour traiter le sujet.

En finançant une partie du travail sur trsync, j'ai voulu rendre l'outil utilisable par le grand public - installeur Windows, icône visible dans le bureau, etc.

Trsync est composé de plusieurs briques et est donc + facilement accessible à un contributeur. Trsync est un projet indépendant de Algoo et de Tracim.

Je suis content que Algoo ait contribué à un projet indépendant, et ce d'autant plus qu'on utilise trsync en production en interne chez Algoo, notamment pour les personnes administratives qui s'affranchissent naturellement de la problématique fichier local vs fichier distant.

Prochaine contribution financière ? Probablement qqchose autour des notifications, mentions ou tâches pour interagir avec Tracim directement depuis son bureau. J'imagine bien trsync devenir le client officiel natif (et contrairement à beaucoup de solutions, ce n'est pas un navigateur internet embarqué mais bien une application native)

Oui on est bien d'accord :-)

C'est un sujet de réflexion assez vaste. Ne serait-ce que dans les bugs : il y a les bugs en cours de documentation (on a constaté une anomalie, on souhaiterait la corriger mais il faut encore clarifier le problème) et un bug "prêt" qui est auto-suffisant pour être pris en charge par un développeur. Le fait d'avoir tout au même endroit simplifie la recherche d'information et le suivi mais génère du "bruit" lorsqu'on veut une vue d'ensemble.

Sur Tracim on s'est posé la question et aujourd'hui on a 3 "inputs" :

1. les demandes utilisateur / client qui arrivent par tout un tas de chemins (email, discussion, ticket, chat, espace communautaire, etc). Ces demandes sont "regroupées en vrac" dans un espace Tracim interne
2. une fois suffisamment claires, ces demandes sont introduites dans un doc de suivi (tableur) qui va permettre de prioriser ces demandes clients. on a environ 100 demandes aujourd'huis, bug et fonctionnalités confondues.
3. le travail de priorisation abouti à l'écriture de tickets (github) qui vont être pris en charge en terme de développement

Ce mode de fonctionnement permet notamment de conserver une base de travail publique (les ticket github, accessibles à tout un chacun) tout en travaillant en priorité sur les demandes faites par les clients (ceux qui paient nos salaires).

On est très loin du 0 bug (actuellement, c'est plus de 1700 tickets ouverts) ; mais c'est aussi un moyen de tracer le problèmes et de ne pas ignorer des problèmes remontés par le passé mais qu'on n'a pas (encore) eu le temps de traiter.

Cette description succinte ne prend pas en compte les bugs identifiés durant les phase de test et livraison de fin de sprint, qui sont dans un sas type "on le garde là pour le moment car si on peut le corriger dans la foulée, ça ne passera même pas par un ticket"

En écrivant ça, je me dis qu'on pourrait prévoir une conf sur le sujet du process de développement si ça intéresse des gens …

:-D

Dit autrement : comment se fait-il que le projet Flask est aussi dynamique là où la majorité des projets libres ou professionnels ne sont jamais à ce niveau d'avancement entre demandes et réponses / corrections.

C'est une vraie interrogation !

Ce n'est pas ironique, c'est mal exprimé. Ce que je veux dire c'est que là, on voit le projet complètement à jour de toutes les demandes, de toutes les remontées de bugs, sans aucune merge request ouverte. Je trouve ça super étrange :

• d'un côté c'est bien et ça montre une hyper réactivité de l'équipe de dév
• d'un autre côté, ça fait plus de 20 ans que je fais du développement et je n'ai jamais vu un projet aussi "à jour sur les demandes" et "sans aucuns travaux en cours" (genre tous les soirs les MR sont terminées).

Je sais pas si c'est plus clair …

Dans un certain nombre de projets, le "bug" est la particule élémentaire pour les travaux de développement. Là ce n'est pas le cas. Il n'y a pas non plus de merge requête ouverte, ni de tableau de suivi.

C'est assez étrange, je trouve. Quelqu'un en sait un peu plus ? C'est le projet de développement ultime ?

À Algoo on utilise Thunderbird pour la messagerie email et on a découvert comme certains d'entre vous la nouvelle version de Thunderbird qui est très prometteuse.

On a prévu de faire une présentation de l'outil en interne et du coup on s'est dit qu'un webinaire public serait aussi bien.

L'événement est gratuit et se déroulera sur une plateforme Big Blue Button (donc sans nécessité d'installation de logiciel)

Notepad++ est le troisième environnement de développement ? Je suis vraiment dubitatif. Certes j'ai vu quasiment tous les développeurs en environnement Windows l'utiliser … mais comme éditeur de ressources texte, pas pour éditer et coder au quotidien.

Les sociétés Algoo (éditrice du logiciel libre Tracim) et Aukfood (services, infogérance et formation autour des logiciels libres) organisent ce webinaire mardi 21/06 de 11h30 à 12h30 à destination (en particulier) des collectivités.

L'événement se déroulera +/- sous forme de table ronde avec 2 invités de marque :

• Jean-Christophe ELINEAU, Responsable du cluster NAOS, le cluster Open Source de Nouvelle-Aquitaine,- Emmanuel CHOPOT DSI de la Roche-sur-Yon

La participation à l'événement est gratuite.

Je pense que mesurer CPU, RAM et temps de réponse permettront effectivement d'identifier à quel moment ton service se dégrade trop.

Commentaire en double -> supprimé

J'ai vu passer l'information par ailleurs ; je ne connaissais pas l'association et je n'arrive pas à comprendre le sujet.

Pourquoi l'association se dissout-elle ? Objectif atteint ? Plus de raison d'être ? Plus de motivation ?

Pourquoi ? 🤔 (le lien ne m'a pas aidé)

Je t'invite à chercher les termes "design pattern" (ou patrons de conception en Français).

Par exemple :

• https://refactoring.guru/fr/design-patterns/python (en français)
• https://python-patterns.guide/
• https://www.toptal.com/python/python-design-patterns

Attention au français car la littérature est massivement en anglais sur le sujet, du coup si tu veux trouver de l'aide, je t'invite vivement à utiliser la terminologie anglophone. Par exemple utilise Bridge plutôt que Pont, ou encore Abstract Factory plutôt que Fabrique Abstraite. Ça marche aussi en Français, hein, mais c'est juste que tu trouveras beaucoup plus d'aide en Anglais - et tu pourras échanger et discuter avec beaucoup plus de monde.

Du coup, les claviers orthogonaux c'est bien ou pas bien ?

Par rapport à ce qui est dit au dessus, ce qui est important aussi, pour la pérennité de tes projets, c'est de respecter l'architecture des projets que tu reprends, et d'appliquer la philosophie de structuration proposée par les framework sur lesquels tu t'appuies.

Développer une app web Django avec une autre philosophie que celle de Django va t'amener à des difficultés de compréhension, d'organisation du code et casser les "paradigmes" que tes contributeurs s'attendent à retrouver.

L'architecture MVC est une manière d'implémenter une application mais dès que tu travailles sur des projets complexes, ça ne suffit plus.

À partir de la, il y a plusieurs approches possibles selon les cas … Et pas de solution clé en main à mon sens.

Plus tu découpes et découples, plus ton logiciel est résilient et maintenance… Mais plus il sera coûteux à maintenir.

Veux tu mettre construire une architecture évolutive ? Dans ce cas une structure à base d'interfaces de programmation et de plugins sera la meilleure solution, mais alors c'est du boulot.

Ou alors tu as une architecture monolithique, moins évolutive mais nettement plus simple à maintenir.

Tu peux aussi t'orienter vers une architecture micro services mais là on s'éloigne de l'architecture logicielle pure…

Ce qui me semble important :

1. Regarder ce qui se fait
2. Connaître les pattern classiques (Factory, stratégie, etc, etc)
3. Écrire des tests car si tu veux changer l'architecture de ton code, les tests t'aideront à réécrire à iso-perimetre
4. Documenter et faire le + simple possible

La démarche d'évolution assez classique d'un développeur est :

1. Novice -> pas d'architecture
2. Intermédiaire -> trop d'architecture
3. Expérimenté -> architecture réfléchie là où c'est important

Mais même en étant expérimenté on n'est pas forcément d'accord avec ses pairs …

Bon courage :)