Il n'y a que de mauvais outils
Par Mathieu le mardi 17 août 2010, 22:52 - Informatique - Lien permanent
Cet article aurait put venir compléter mon article sur l'incompétence, que j'avais écrit il y a plusieurs mois et que je n'ai jamais publié, pour des raisons de scrupules à juger un peu trop vite les gens, et j'ai au final bien fait.
Bref, cette petite parenthèse refermée, cet article est encore un article « raz le bol », où j'exposerais pourquoi je ne veux plus travailler avec certaines personnes sur certains projets, et c'est valable aussi pour le projets scolaires.
Ce n'est pourtant pas la pléthore de solutions disponible pour chaque utilisation qui aurait put créer un « vide technique » autour de la profession ; il existe énormément de logiciels plus ou moins bien conçus, libres et/ou gratuits, pour répondre aux problématiques quotidiennes d'un informaticien « généraliste » [1].
Le problème, c'est souvent que les gens ne savent pas qu'ils sont ignorants à propos des outils existants et des méthodes de développement. C'est quelque chose que je constate avec mes camarades à la fac, et que je retrouve dans les jeunes communautés OpenSource. Ils utilisent donc des outils qui ne sont pas vraiment adapté pour répondre à des problèmes qu'ils ne se seraient peur être pas posés en s'organisant autrement.
Le point le plus dramatique le plus souvent, c'est que ces derniers refusent également les nouveaux outils qu'on leur propose ou qu'on leur impose, ils ne veulent pas reconnaître non plus la qualité d'un des individus du groupe pour mettre en place et apprendre aux autre à se servir du nouvel outil. Il arrive même que ces derniers s'entêtent dans une solution alternative à la leur, mais qui est aussi alternative à la votre, alors qu'elle pose plus de problème que la votre sur de nombreux points. C'est prétentieux de prétendre détenir la vérité par rapport aux bons outils et aux bonnes méthodes, mais la valeur de l'expérience est trop souvent sous estimée, si elle n'est pas tout simplement ignorée.
Les jeunes communautés ont toujours deux attitudes antagonistes :
- Se démarquer des autres communautés en utilisant d'autres outils, en changeant de méthode, bref en essayant d'autres voies, ce n'est pas un mal en soi si ces voies sont praticables
- Ou alors coller à 100% aux autres communautés, plagiat leurs méthodes, leurs outils, mais sans l'expertise des autres, et bien souvent le résultat c'est que les outils n sont pas maîtrisés, et le travail s'embourbe dans des procédures qui ne sont pas adaptées à la taille de la communauté.
Je suis sans doute très critique, mais il y a des moments où vraiment je dis stop, je ne supporte plus par exemple :
- Que l'on refuse les outils de gestion de version avec code public (ou privé développeurs) pour travailler sur un projet de code, ou un projet où la valeur ajoutée est incrémentale (on améliore constamment, c'est pas « one shot »)
- Que l'on utilise un forum comme bug tracker
- Que l'on utilise un forum comme gestionnaire de tâches
- Que l'on utilise un forum pour de la revue de code (!)
- Que l'on utilise un forum pour de la documentation plutôt qu'un wiki (ouvert ou fermé d'ailleurs)
- Que la roadmap est inconnue, sauf du leader du projet
- Qu'il n'existe pas de portail privé pour les membres du projet, avec un accès direct à l'ensemble des outils
- Que l'on ne me fasse pas confiance (pourquoi je ferais confiance au responsable du projet s'il ne me fait pas confiance ?)
- Outils de gestion de versions : Subversion, Git, Mercurial
- Outils de report et de traitement des bugs : MantisBT, Bugzilla
- Outils de travail collaboratif : Dokuwiki (documentation), OpenCollab (Coordination)
- Outils « Tout-en-un » : Trac (wiki+bug tracker+gestionnaire de tâches+synchro svn, git, etc), Redmine (wiki+tracker+gestion de projet+synchro svn, git, etc+forums+diagrammes de GANTT+machine à café)
Notes :
- [1] Je parle ici de concept de généraliste, mais il est différent de celui des médecins généralistes, en effet on pourrait penser que pour moi l'informaticien généraliste est celui qui vient vous installer windows et vous réparer votre ordinateur quand vous en avez besoin, mais ce n'est pas ce que je considère comme un informaticien généraliste. Même s'il m'arrive d'envier les connaissances techniques de ces personnes avec les système d'exploitation grand public, et la connaissance qu'ils ont du matériel qu'ils installent, ce ne sont à mon sens que des techniciens, pour moi un informaticien généraliste est un informaticien qui a des connaissances larges, à la fois techniques mais aussi des connaissances sur les concepts abstraits et fondamentaux de l'informatique, bref une personne un peu « touche à tout », mais avec un seul domaine de prédilection, comme tout le monde. Je me considère comme un généraliste, à ma façon.
Commentaires
J'aime bien ta description des jeunes communautés, j'irai même plus loin en adaptant ça à un cadre plus général à savoir :
Maintenant, si j'ai bien compris ce que tu reproche, c'est comment doser tout ça de manière optimale… Partir dans des voies inexplorées faisant perdre de l'efficacité, le conformisme poussant à la conservation des erreurs sans perspective d'évolution.
Le plus intéressant étant probablement que ce problème est tellement général qu'il la question principale ressortant directement de la loi de l'évolution de Darwin. Et donc, s'applique aussi bien au mutant bien qu'inflexible ADN, qu'aux innovantes mais têtues groupes de populations.
Maintenant, si on regarde du côté pratique, on voit que le problème principal est ici : « ces derniers s'entêtent dans une solution alternative à la leur, mais qui est aussi alternative à la votre »
C'est un problème d'égalité, chacun croit qu'il a une solution meilleure que celle des autres, chacun peux (sans rancune) écrire un article comme celui-ci pour décompresser de cette pression constante. C'est le stress imposé par la concurrence dans un système égalitaire. Je vais donc me comporter comme un pur hérétique aux droits de l'homme en prônant le bienfait des inégalités. A mon avis, le problème viens du fait qu'il n'y a pas de relation d'ordre stricte (terme mathématique… ou pas) entre les individus du groupe. Il faut et il suffit que chaque personne ait un supérieur. Et pour éviter la monarchie, il faut que les inférieurs, s'ils parviennent à un accord, aient plus d'importance que leur supérieur dans la prise de choix. En d'autre terme, le patron doit écouter les autres. Bon, dans un groupe de 2 c'est assez difficile à appliquer, c'est pour ça que je prône les groupes de 4. Enfin, tout ce que j'ai dit ne sont que des idioties sur lesquelles je changerais probablement d'avis dans quelques temps, mais pour le moment j'en suis assez convaincu.
C'est pour ça que j'aime pas les binômes et que je préfères les groupes au nombre de membres impair (1, 3, 5, 7, 11, 13, 17...)
Qu'en est-il d'un cas de monôme ?
Car hier, j'en discutais avec Dakin sur IRC. Cela partait de quand j'avais mentionné que je m'apprêtais à aller envoyer un MP à un des modos de CB pour un bug que j'ai dans mon MOD (un Q&A Captcha simple), et lorsque je lui ai montré le bout de code où ça coinçait et qu'il n'aimait pas trop la façon d'écrire les conditions, je lui ai dit que c'est généralisé et que c'est au développeur qu'il doit s'adresser pour les suggestions. Je lui ai alors dit qu'il développe seul et que même si je lui avait proposé l'idée du SVN, il n'est pas prêt à passer au développement à plusieurs car c'est un projet pour lequel il a une certaine vision et il ne veut pas précipiter les choses, voir sujet : http://forum.connectix-boards.org/f... (ça date d'un an, la beta de la 1.0 a été dévoilée depuis)
Je lui ai aussi dit (à Dakin) que CB est hébergé en mutu et que si mes connaissances en serveur Linux avaient été plus solides, je me serais proposée pour prendre un dédié pour pouvoir mettre en place un bug tracker (pour remplacer la vieille méthode des signalements sur le forum). Dakin m'a parlé de l'idée d'un VPS et m'a suggéré Trac. Or, est-il possible d'utiliser Trac sans utiliser SVN, GIT ou autre système de versionnement, quitte à l'installer plus tard ?
Une fois que j'aurais les réponses, je pourrais regarder s'il y a d'autres habitués de Linux sur le forum (je sais que le développeur lui-même n'a comme expérience Linux que les tests avec un livecd d'Ubuntu, et il est déjà occupé par son emploi, sa fiancée et autres trucs non-geek), voire si je peux avoir la collaboration de Natim (un utilisateur de CB qui a déjà installé Trac sur un serveur), question de me sécuriser pour un éventuel projet de bug tracker pour CB. Autrement, coder un plugin "from scratch" utilisant les sessions de CB aurait été long.
Après, j'ai l'intention de montrer le lien de ton article au développeur en question, donc sache qu'il lira donc ta réponse.
MissGeek
ps : c'est ma deuxième tentative de commentaire, j'avais annulé ma première tentative avant de l'envoyer, ma phobie sociale a pris le dessus en me faisant anticiper tous les commentaires négatifs possibles (pas nécessairement vis à vis de moi, mais sur tout ce que j'ai à coeur).
Alors pour la question la réponse est oui, on peut installer Trac sans lui associer de gestionnaire de version, les outils qui restent sont : un wiki, un gestionnaire de bugs et un gestionnaire de tâches. On peut désactiver des fonctions en configurant les permissions de manière adéquate.
Trac est relativement facile à installer, mais il faut quand même être à l'aise avec la ligne de commande, il suffit de l'installer, de créer un utilisateur et/ou un dossier pour l'accueillir, d'initialiser l'environnement, de faire les chown www-data qu'il faut sur le dossier db/ (si on utilise sqlite, ce qui est le plus simple, mais on peut utiliser mysql ou postgresql), configurer le virtual host d'apache (j'ai des exemples), et enfin configurer Trac (ce qui peut se faire via le navigateur si un utilisateur a la permission TRAC_ADMIN).
Je pense que c'est "tellement" simple que ça peut faire l'objet d'un tuto sur le SDZ.
Dans ce cas, je ferai la proposition du serveur VPS avec Trac installé dessus plus tard en journée, j'avais gardé le contenu du message dans un .txt en attendant ta réponse.
Car en effet, ça fait plusieurs patchs que moi ou l'un des modérateurs de CB propose, que ce soit par MP ou via le forum, et vu qu'on accumule les sujets de rapports de bugs ou d'améliorations pour toutes les versions de CB et ce, pêle-mêle, en ordre de dernière réponse, je pensais justement à l'idée d'un bug tracker qui aiderait grandement à organiser le tout, par version (0.8.x, 1.0.x, 1.1.x, ...) et par composantes, etc.
Pour un tuto sur le SDZ, j'ai justement pensé que tu pourrais en faire un
Ouais pourquoi pas, mais j'en ai jamais fait, et je sais pas si j'ai vraiment le temps pour ça :s
Si tu veux quelqu'un pour rédiger le tuto à deux, je peux te proposer Natim. Il a déjà installé Trac (cf. un article sur le blog Simple IT), est à l'aise avec GNU/Linux (il est l'admin du forum de Zenwalk-Fr) et le langage Python. Il a aussi plusieurs tutos à son actif, et il a fait un stage chez Simple IT.
Son profil SDZ : http://www.siteduzero.com/membres-2...