Quand on se permet de regarder ce que tu télécharge, on se permet non seulement de regarder les films que tu télécharge illégalement, mais aussi :
- les pages web que tu visite
- les emails non cryptés que tu lis (ou cryptés mais décryptés par un serveur pas par ton poste, comme sur un webmail)
- les conversations instantanées
- les commandes que tu passe sur des sites de vente en ligne
Donc oui, si Hadopi est tellement soutenu politiquement ce n'est pas que pour les beaux yeux des moines copistes de notre millénaire, c'est aussi pour introduire dans les esprits qu'internet devrait redevenir ce que selon eux il n'aurait jamais dû cesser d'être : un minitel un peu plus joli à regarder avec option big brother.
J'imagine bien les terminaux faire tout d'un coup un écran noir avec des caractères aléatoires, avec un enregistrement de parasites radio, tu laisse pendant 1 minute à peu près le temps qu'assez de monde remarque et commence à s'inquiéter, après tu affiche :
0:30
Clignotant, et tu décrémente toutes les minutes (surtout ne pas afficher les secondes), en augmentant le volume à chaque fois que tu décrémente.
Arrivé à 0:10 tu ajoute aux parasites radio un genre de prière islamique.
Arrivé à 0:5 tu fais clignoter une fois en rouge, une fois en blanc et tu ajoute un bip bien stressant.
A mon avis, à l'arrivée, si quelqu'un à le moindre doute que l'attaque vienne de toi, tu pars direct pour une prison secrète des services secrets de je ne sais quel pays qui assure la sécurité de la compagnie aérienne.
C'est bien ce qui se fait partout (JavaDoc, PHPdoc, Rdoc, etc.), mais ça n'oblige pas (et heureusement) à faire uniformément partout. Ca donne un outil pour faire automatiquement, mais personne n'empêche de faire un meilleur outil quand c'est utile / nécessaire, et surtout peronne n'oblige à documenter d'une façon parfaitement uniforme toutes les applications, l'outil laisse des marges de libertés très importantes, et c'est très bien comme ça. C'est ce que j'ai voulu dire.
Quand je parlais de documentation qui ne rentre pas dans des petites cases carrées, je voulais par exemple parler de celle de shoes, qui incite à se remettre la tête ronde quand elle commence à devenir trop bêtement carrée : http://shoooes.net/
Après, il y a des gens à qui ça fait peur, moi j'aime bien.
Un petit peu comme les fondamentalistes d'une religion qui contestent la validité de la science quand elle leur déplait, mais qui utilisent ses applications quand elle les arrange...
> Non, je raisonne en document _utilisable_ point barre. pour une version stable d'une bibliothèque ou d'un projet. En quoi le fait d'être libre/proptrio/contrat ou n'importe quoi change-t-il quelque chose ? On s'en fout, ce que je veux c'est pouvoir utiliser la doc sans me prendre trop la tête.
Il y a plein d'utilisateurs de Rails qui trouvent la doc de l'api très utilisable et pas prise de tête, moi en tête. Je m'en sers tous les jours, j'y trouve ce que je cherche rapidement et je trouve que c'est généralement assez clair et complet.
Sinon, ce que ça change d'être libre ou privateur, beaucoup de chose, j'ai développé dans un autre message plus haut. La question "comment faire pour obtenir des projets libres qu'ils soient des copies conformes mais gratuites des privateurs" est un non-sens. La bonne question est "est-ce que ce que j'attends est un projet libre, qui avance au fur et à mesure, qui évolue et change, ou est-ce que je veux travailler sur le marbre d'un produit privateur complètement fini avec une documentation parfaitement stable". Apparemment tes désirs te feront préférer la 2° catégorie. Si tu demandes à un léopard de porter des rayures, ou un zèbre de porter des taches, tu seras souvent déçu par la réalité....
> Et qu'est-ce qui empêche d'avoir une doc à jour par rapport aux évolutions de version ? Le temps que ca prend? Ca n'a pas de sens : soit tu documentes et on utilise ton code, quitte à prendre plus de temps, sit tu documentes pas et personne n'utilise ton code et la ça sert à rien d'aller vite. De plus en mettant la doc à jour au fur et à mesure ça prend moins de temps plutot que de générer une doc après que la version soit sortie (et cette doc ne sera jamais à jour car le temps d'écrire la doc, la version N+1 sort)..... Et je te répète que je ne cherche pas une doc à jour pour la derniere version non stable, mais pour une version stable.
L'API, rien n'empêche qu'elle soit à jour, et au risque de te surprendre à de rares exceptions près elle l'est. Par contre, les blogs de trucs et astuce et certaines pages de la wiki officielle ne sont pas toujours maintenues comme elles devraient. D'où une interrogation : en parlant de l'API, ne parlerais-tu pas en réalité de la wiki de Rails ? (l'api : http://api.rubyonrails.org/, la wiki : http://wiki.rubyonrails.org/)
L'API donc est générée à partir des commentaires du code, automatiquement, elle est donc généralement très à jour (sauf peut-être quelques jours de temps en temps quand une nouvelle version importante remplace la précédente edge, et encore) tout comme les commentaires du code donc. Celle du site concerne la dernière version edge, mais comme c'est celle générée automatiquement si tu n'utilise pas la dernière edge tu peux très bien générer la documentation de ta version à partir de ta version avec un " rake doc:rails ", ça te génère un répertoire avec une version HTML complète et navigable des commentaires correspondant à ta version en cours à toi au temps t sur ta machine m.
En fait, j'ai vraiment l'impression à te lire que tu as foncé dans le Rails tête baissée et que du coup tu es frustré parce que tu ne sais pas où trouver l'information et savoir par où commencer. C'est valable pour d'autres projets que Rails, privateurs ou libres. Si tu avais commencé par exemple par demander de l'aide sur un forum pour savoir par où commencer, et cherché de l'information de base (sur internet, dans un livre synthétique, etc.), à mon avis tu serais maintenant plus à l'aise et tu n'aurait peut-être pas un avis aussi orienté sur la question.
Rappelles-toi tes premiers pas dans les projets informatiques, rappelles-toi quand on t'a tenu la main pour prendre en main tel ou tel outil que maintenant tu aimes employer, rappelles-toi les heures à chercher une information sans la trouver parce que tu ne savais pas où chercher.
Bien sûr on voudrait que le savoir et l'expérience nous tombent tout cuit tout roti, mais le monde n'est pas comme ça, ce n'est pas plus la faute aux projets libres ou privateurs, il faut chercher pour trouver de l'info, et pour trouver il faut savoir parfois dans quelle botte de foin se cache l'aiguille.
De ce point de vue la l'avantage du libre c'est de pouvoir faire appel à l'aide de la communauté, et de laisser libre accès en lecture / écriture à ceux qui veulent améliorer la documentation. Le privateur a d'autres avantages (ne proposer de la documentation que pour ce qu'il veut bien te laisser voir par exemple, ça peut être un atout pour ne pas s'épuiser à commenter tout, c'est juste un exemple). A toi de faire ton choix en fonction de tes besoins.
Il faut se rendre à l'évidence, demander à la population d'un pays libre et démocratique d'arrêter de diffuser des copies illégales de leur plein gré alors qu'il n'y a pas de contrainte techniques et que les contraintes légales ne sont pas crédibles dans leur application, c'est comme demander aux chats et aux chiens d'arrêter de se lècher les couilles quand ils font leur toilettes, c'est bien brave, mais même en y mettant tout ton coeur ça n'aboutira pas, point, barre, allez à la ligne, nouveau paragraphe et on parle d'autre chose.
> Là n'est pas la question : tu sépares la doc du code et cette approche est bien plus rapide que de tout mettre dans le code.
On ne doit pas parler de la même chose alors. A volume égal, la doc des méthodes et des objets eux-mêmes, plus tu la détache et plus c'est pénible de la garder à jour, alors que la mettre proprement dans les commentaires prévus à cet effet permet de générer sous différents formats de façon automatisée sans perdre du temps à synchroniser à la main.
Par contre, si à fonctionnalité égale je dois commenter une seule méthode (Ruby) ou 3 méthodes (Java quand il y a plusieurs façons de fournir les paramètres), c'est clair je préfère Ruby.
> Je suis d'accord avec toi sur le fait qu'une version non stable n'a pas à être documenté, je parle de version stable. Et lorsque j'ai installé Rails 2, c'était une version considérée comme stable ( ou j'ai mal compris quelque chose).
Alors non on n'est pas d'accord. Je ne vois pas en quoi on ne devrait pas documenter une version non stable. Mais je crois que tu veux dire en fait "une version non stable n'a pas à sortir publiquement". Et là, vu que tu adopte un point de vue privateur, oui, c'est logique.
Dans un modèle de développement libre, on peut très bien rendre publiquement disponible même (surtout) les version non stables, en avertissant les visiteurs que la version non stable ne l'est pas encore. C'est comme ça que des utilisateurs peuvent soumettre des patchs pour stabiliser, indiquer les bugs qu'ils trouvent, et aider à évaluer la stabilité de l'ensemble. Aussi, à soumettre des patchs de commentaires pour améliorer la documentation.
Et que tu aies compris quand tu as installé Rails 2.0.0 que c'était une version stable... Comment te dire... Tu as mal compris quelque chose, oui.
>> Dans le cas d'un modèle privateur, puisque c'est un produit que l'on vend, on ne sort une nouvelle version qu'une fois que tout est lisse, arrondi, calé, ou du moins que les bugs sont cachés sous le tapis, et on lui met un gros numéro bien flamboyant pour dire "tadaaaaaa". Ici ça ne sert à rien d'être une version en dessous de la pointe, puisque la pointe n'est pas disponible avant d'être stabilisée.
> Tu caricatures ..... Je ne suis pas spécialiste Microsoft, ou Borland, mais je me rappelle que lorsque je faisais du développement Windows, l'API était sufisamment bien documentée pour pouvoir s'en sortir dans la plupart des cas .... Toi tu me parles de développements fait à l'arrache par une sSII pour un projet spécifique, et la je te l'accorde les SSII ne sont pas toujours des modèles dans le genre.
Non, je ne caricature pas, je constate. De plus je ne juge pas. C'est normal d'essayer de faire mousser un produit que l'on veut vendre, et c'est normal qu'on lisse les bords et qu'on arrondisse les coins, voir qu'on mette de la poussière sous le tapis quand il y en a qu'on n'a pas le temps de vider, tout le monde le fait, ce n'est pas l'apanage des SSII et Windows ou Borland ne sont pas en reste. De toute façon ce n'est pas un crime et ça peut être réparé discrètement ensuite à coups de patchs.
Et surtout, ce n'est pas une décision volontaire d'un dirigeant ou des développeurs, c'est un sous-produit du modèle en cascade "on livre pour quand c'est demandé / quand le marché est réceptif" comme le fait de soumettre des versions non stable est un sous-produit du modèle itératif "on livre petit à petit jusqu'à ce que ça fonctionne bien et quand ça fonctionne bien on appelle ça stable jusqu'à la prochaine stable".
> On en revient à ce que je disais plus haut : lire les commentaires parsemés dans le code, ca coute cer en temps à un développeur, bien plus qu'une aide en ligne à la "VBA" .... Apres entre le README qui indique comment installer, le README qui indique comment l'utiliser, etc .... c'est pas simple de s'uy retrouver.
Sinon tu as des outils pour prendre les commentaires et faire les jolies pages HTML lisibles / cherchables avec le code caché tant que tu ne veux pas le voir, avec Ruby ça s'appelle RDoc, avec Java JavaDoc, avec PHP, PHPDoc (c'est dingue, on dirait presque qu'ils se sont concertés). Ils peuvent par exemple prendre le README et en faire une jolie page de garde avec des titres et tout.
Avec ça, tu rajoutes un wiki sur ton site, où tu mets des schémas globaux, des explications sur les principes importants, des tutoriaux pour les tâches courantes, et n'importe qui peut s'y retrouver. Le point positif, c'est que c'est moins lourd et chiant à maintenir qu'une documentation complètement séparée du code, parce que quand on change la signature d'une méthode qui a un commentaire, on pense plus facilement à changer le commentaire et c'est moins pénible que de repasser sur toute la doc et tout le code pour voir les choses qui ont changé après coup.
> Je n'ai pas encore assez de recul sur Ruby et Rails pour répondre, mais ce n'est malhereusement le cas que d'une infime partie des projets libres. Pour beaucoup, la seule doc est le code ..... Et puis pour Ruby et rails en particulier il est difficile de s'y mettre sans un bon bouquin à côté ....
A mon avis oui, tu as assez peu de recul sur Ruby on Rails, probablement parce que tu as attaqué Rails sans avoir au préalable un peu creusé Ruby. C'est ce qui fait que oui, il faut généralement un bouquin pour attaquer parce que sinon c'est un trop grand pas à franchir.
C'est un peu comme vouloir apprendre le calcul intégral sans savoir faire d'additions, soustractions, multiplications, etc., c'est pas strictement impossible mais il va falloir beaucoup potasser et tu vas trouver ça beaucoup plus compliqué.
Ensuite, je pense que si je voulais attaquer le développement d'un jeu en 3D avec directX en C++, j'aurais quand même intérêt d'avoir des bases de C++ avant d'attaquer l'API directX par la face nord, API bien foutue ou pas.
Et puis franchement, commencer dans n'importe quelle API en plongeant direct dans l'API sans chercher des autres sources (tutos, blogs, forums de développeurs, etc.) c'est quand même un peu suicidaire non, à moins de déjà maîtriser à mort le sujet.
> Dans un contexte de travail collaboratif, c'est mieux : tu définis les interfaces avant de les implémenter :ceux qui se basent sur ton travail peuvent travailler sans avoir à t'attendre ....
En Java oui, puisque le Java est fortement typé, que d'écrire du code prends beaucoup de temps, qu'il y a beaucoup de répétitions inutiles (méthodes paravent, polymorphisme par clonage de signatures, répartition de responsabilités en multipliant le nombre de classes ...), ce qui oblige à faire des architectures de classes apriori pour faire en sorte que tout colle bien ensuite, ce qui plombe les projets parce que tout ne se passe jamais vraiment comme c'était prévu au départ (le client change d'avis, l'équipe avait mal compris / interprété, une contrainte technique force à considérer un cas imprévu...). C'est bureaucratique, lourd, et généralement ça tue l'esprit d'initiative chez les gens qui vont devoir développer derrière les architectes qui on fait les plans. Bof.
Maintenant, quand le langage n'est pas une carapace handicapante, comme en Ruby (typage dynamique "... alors pour moi c'est un canard", possibilité d'ajouter des comportements factorisés dans la définition de classe ou même à la volée grâce aux modules, etc.), on n'a pas besoin de tout penser avant de se mettre à coder, on peut commencer en itératif en définissant des lignes générales, prototyper jusqu'à obtenir un modèle convenable, casser le prototype et réaliser l'itération avec tests et factoriser ensuite. Et la collaboration se passe bien s'il y a communication, proximité, tests automatisés et confiance, ces 4 éléments sont nécessaires et c'est non-négociables par contre.
Il faut faire confiance apriori en sa capacité à trouver une solution pour chaque problèmes qui se présenteront en route, mais que l'on parte avec un plan rigide et sur-développé comme en Java ou une direction globale précise mais une ligne souple comme en Ruby, on arrive au même point au final et il y aura des embûches en cours de route de toute façon (le meilleur plan du monde n'est qu'un plan, la réalité a souvent tendance à le contredire).
et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
> 1/ D'abord combien de projets le font ? très peu. Et c'est ce que je déplore entre autres.
Plein de projets libres le font, au contraire, mais ils ne sont pas forcément toujours très connus / reconnus par les utilisateurs. Github par exemple propose de base un wiki pour chaque projet.
Au hasard dans ceux que j'utilise et que je lis beaucoup :
- Rails (beaucoup de tutos sont justement sur la Wiki)
- Shoes (toolkit graphique Ruby)
- Inkscape
- Ubuntu
> 2/ Sinon, encore de la dispersion :
> - Readme
> - code source
> - wiki projet
> - les forums
> - les FAQ
> - un bouquin qui fait la glue avec ça ...
Attends, tu mélanges tout là.
Le README ça va avec le code source, et ça peut être inclu dans la doc généré, généralement d'ailleurs ça fait la première page de doc générée automatiquement depuis les sources.
Un wiki projet c'est pour trouver les bases pour commencer, ça n'a rien à voir avec les sources et c'est normal, le but n'est pas d'aller au fond des choses mais de présenter une vue d'ensemble et des "portes d'entrées" dans les concepts principaux. C'est normal que ça ne soit pas intégré à la doc de l'API plus complète, moins didactique, plus directe, plus "sèche" (moins d'exemples pas à pas). Les FAQ ça s'intègre très bien aux wiki, c'est même limite la meilleur façon de les case.
Les forums officiels c'est là pour mettre en relation une question précise avec une réponse précise, quand une question - réponse revient souvent c'est une bonne idée de la faire remonter vers la wiki, ou dans la doc quand c'est un trou. C'est un autre média, ça n'a rien à voir, et rien n'empêche de le mettre sur un même nom de domaine que le site de l'API et du code par exemple.
Les forums officieux, les bouquins, c'est pas maîtrisable par les responsables du projet, chacun fait ce qu'il veut et encore heureux.
Bref, de tous ces différents médias, les "officiels" sont tous groupables sous un même nom de domaine commun, et les "officieux" font leur vie. En même temps c'est plutôt bien de disperser les médias officieux, ça diffuse l'information, ça donne des droits d'auteur à des auteurs de livres, quand ils sont bons, ça fait bloguer les blogueurs.
> Et tout ca sans que les développeurs s'impliquent dans la doc (je ne leur demande pas de rédiger de la doc hein) ... En plus chaque projet ou langage utilise ses propres convensions ou format ..... Pour un développeur windows par exemple c'est plus simple : un IDE qui contient l'aide dont il a besoin ....
> Si on pouvait arriver à ca je serais hereux .... mais j'y crois pas trop.
Ok, je ne sais pas toi, mais moi la dernière fois que j'ai consulté la MSDN je m'y suis perdu et je n'ai pas trouvé la réponse après une soirée, j'ai laissé tomber. Comme quoi c'est aussi subjectif, et qu'un outil demande un temps de prise en main de toute façon et quel qu'il soit.
> 3/ Qu'est-ce qui empêche de rédiger de la doc en même temps que les tests ? Pas grand chose puisque les tests sont censé, comme leur nom l'indique, testerles cas d'utilisation. Prendre certains bouts de code développés pour le test comme exemple serait bien pratique ....
Rien ne l'empêche, mais c'est pas forcément une bonne idée, tout comme celle qui voudrait que les tests sont fait au début et n'évoluent pas ensuite. On ne sait pas de quoi demain sera fait, il vaut mieux écrire les tests et les commentaires peu de temps avant le code, et les faire évoluer quand le code évolue pour mieux convenir aux besoins.
Considérer la programmation d'une façon verticale (on descend d'une vérité mathématique absolue jusqu'à lui donner corps) me semble être une erreur. Je préfère l'approche "biologique", on prend un problème, on le résout, on consolide, on livre, on prend de l'expérience, on réitère. C'est plus "darwinien" (le meilleurs finit pas survivre et transmet ses caractéristiques aux suivants), et moins "immanent" (la perfection existe au-delà de notre royaume, mais on doit s'en approcher quel que soit le prix).
> Juste un détail : ne prends pas mes commentaires comme si je crachais sur le LL et les développeurs : j'essaie d'être constructif et de mettre en avant les points qui me paraissent négatifs dans le LL, et je serai le premier hereux lorsque ces problèmes auront disparu.
Je ne le prend pas comme une insulte, mais plutôt comme un point de vue biaisé concernant le mode de fonctionnement de projets libres. C'est pourquoi je défend mon point de vue jusqu'à changement de celui-ci et / ou fin de la discussion.
Je ne suis pas un zélote d'un fonctionnement ou l'autre (même si je préfère moi me trouver dans un mode de fonctionnement itératif, c'est un choix personnel, que je défend mais que je n'impose pas), chacun peut mieux convenir selon la situation. Par contre, appliquer un modèle ou l'autre a des conséquences sur le format de la documentation officielle et de l'information en général, et attaquer l'api d'un projet libre avec les apriori d'un projet privateur n'a pas de sens, et ne peut que te mener à l'échec et à la frustration, l'inverse est vrai aussi.
> En fait de cette discussion me viennent des idées, mais je ne pense pas que les développeurs s'y plieraient ... Ya qu'a voir les tentatives d'uniformisations telles que LSB ou autres pour se faire une idée ....
Justement, pourquoi faire uniforme ? Est-ce que le monde sera plus beau et plus vivable quand on vivra dans des petites cases de béton de taille réglementaire, avec le choix de la couleur intérieure parmis les couleurs réglementaires, avec les meubles et la décoration à choisir dans les meubles et les décorations standards ?...
Le libre c'est la liberté d'expérimenter comme on le sent, c'est valable aussi pour la documentation. C'est un modèle vivant, presque organique, qui peut donner des bases stables (après tout, l'évolution naturelle a bien donné à l'essentiel des espèces vivantes une même base standard, l'ADN, il n'y a pas de raison que la liberté de création en informatique ne puisse pas reposer sur des standards quand ils sont plus adaptés) mais pas indépassables le jour où on trouve une meilleur idée. Vouloir mettre tout dans des cases bien propres c'est le mirage un peu schizo d'un Descartes qui pensait les animaux comme des machines biologiques déterminées en même temps que "Je pense donc je suis". La vie ne rentre pas dans des petites cases, ou alors avec un truc coupant bien aiguisé...
C'est bien ce que je dis, tu raisonne en livraison unique à un client garantie par contrat avec une seule documentation fixe et finale (même si on part ensuite sur des développements ultérieurs à partir du même modèle). Ce n'est pas le modèle de rails par exemple. Comparer les documentations générées par ces deux formes de développement sur le critère de la validité de la doc d'une seule version V à un moment arbitraire, c'est privilégier le premier modèle où il n'y a pas beaucoup de V, alors que dans le second modèle on fait en continu des versions V, V', V'', etc. sans forcément que la dernière soit la plus stable ou la mieux documentée.
Si tu veux comparer ce qui est comparable, commence par prendre une version stable (pas Rails 2.0.0 mais plutôt 2.2.2 par exemple) et ne prends pas la version "edge" puisque que c'est celle qui est encore en travaux, donc où la doc est la moins à jour et les bugs imprévus pas encore réparés.
> Je pense que tu n'as pas compris mon commentaire :
> On préfère acheter une bibliothèque payante, fermée mais bien documentée (pour l'utilisation) qu'une bibliothèque libre, code ouvert et peu documentée, parce qu'un développeur qui doit passer des jours à ausculter le code pour comprendre comment ça marche, ça coute cher ....
Payer ne te donne pas de garantie que ce soit propre et clair, juste une personne à blâmer si ça ne l'est pas et l'impression d'avoir un levier. Tu peux avoir du propre et du clair aussi bien en libre qu'en non-libre et le crade et pas clair n'est pas l'apanage du libre non plus.
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord.
> Non.
> Ruby on Rails est l'exemple typique de ce que je déplore : on sort une version (notamment la 2.0), et on ne sort pas de doc associée. Quelqu'un qui connait un peu ruby ou rails s'en sort mais je t'assure que quelqu'un qui a voulu se mettre à Ruby lorsque Ruby 2.0 est sorti aurait pu être totalement dégouté de ce langage. D'ailleurs, quand j'allais en cours, il y a plus de 10 ans, on m'a toujours encouragé à écrire un minimum de documentation _avant_ d'écrire mon code, d'écrire par exemple, pour une fonction, les paramètres qu'elle prend, le type et l'utilité de ces paramètres, ainsi que le code retour. On encourage également, dans certaines méthodes de développement, de décrire clairement les classes que l'on crée (notamment à l'aide d'UML), et ce _avant_ de commencer à coder. On encourage aussi à écrire les procédures de test unitaure _avant_ de coder les classes/fonctions (Methodes XP par exemple), et ce n'est pas pour rien.
Mais tu compares des choses non comparables, les n° de version ne veulent pas dire la même chose en libre et en privateur.
Dans le cas de Ruby ou de Rails, par exemple, les numéros de version se lisent :
x.y.z où x représente un très gros changement fondemental de l'API, y un apport de nouvelles fonctionalités majeurs ou des changements importants mais pas critiques, et x des changements mineurs ou des bugkills. Rien ne te garantis que la version 2.0.0 soit plus stable qu'une version 1.8.7 ou 0.1.23, je dirais même que la version 2.0.0 a beaucoup plus de chances d'être bugée, sa documentation incomplète ou à revoir par endroits. Dans ce cas, il vaut mieux rester une version en arrière de la pointe si tu veux de la stabilité et de la doc lisse.
Dans le cas d'un modèle privateur, puisque c'est un produit que l'on vend, on ne sort une nouvelle version qu'une fois que tout est lisse, arrondi, calé, ou du moins que les bugs sont cachés sous le tapis, et on lui met un gros numéro bien flamboyant pour dire "tadaaaaaa". Ici ça ne sert à rien d'être une version en dessous de la pointe, puisque la pointe n'est pas disponible avant d'être stabilisée.
Enfin, si tu veux de la méthodologie XP avec tests validés avant commit tu peux difficilement accuser Rails de ne pas être à la pointe de cette pratique. Pour écrire les tests avant codage, je ne suis pas dans le secret de l'équipe Rails core, mais moi-même en toute honnêteté je ne le fais pas toujours, et il m'arrive de me demander si c'est vraiment si meilleur que de les faire peu de temps après avoir fait une fonctionnalité (mais avant de factoriser bien entendu).
> Ce n'est pas non plus ce que je leur demande .... mais on peut leur en demander un minimum .... Et pour moi le minimum c'est d'expliquer comment utiliser le code qu'ils ont produit et ce que fait ce code.
En général les fichiers README sont là pour ça, et le commentaire aussi, en tout cas en Ruby (je n'ai pas fait beaucoup de C, VB, ou autres langages "chiants" en dehors du Java et du PHP...). Après il y a des gens qui ne lisent pas les readme ou les commentaires (en Ruby on génèrent les docs facilement à partir des commentaires, et comme contrairement à Java on ne fait pas plein de méthodes creuses qui appellent en fait une autre méthode qui fait vraiment le boulot, c'est moins fatiguant).
> En fait j'aimerais avoir pour certains projets libre, non seulement le code mais surtout les représentations (UML) de l'ensemble du projet. Mais la on s'éloigne du sujet initial (les bibliothèques) ...
Il n'y a pas que l'UML dans la vie...
Tu parlais d'XP, en XP on travaille beaucoup plus à partir de "stories", on fait des schémas beaucoup plus libres et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
Bien sûr que les brevets abusifs américains sont des "armes juridiques" utilisés essentiellement comme tel par les sociétés qui les possèdent (et ms n'est pas la seule, apple à bien récemment bloqué la possibilité de mettre deux doigts sur une surface tactile, tout ça pour essentiellement bloquer androïd juste un tout petit peu en dessous de l'os de l'iphone...).
Ce qui est amusant par contre, c'est que microsoft n'abatte toujours pas les cartes contre Linux lui-même...
...Mais attends, abattre les cartes contre Linux, ça voudrait dire faire le procès du siècle. Immaginez, Microsoft VS le reste du monde. Enfin, disons le reste des entreprises utilisant du LL aux USA. Je me demande qui gagnerait... Et les conséquences. Imaginons que redmond l'emporte. Imaginez la longueur d'avance que l'europe, l'Inde, et tous les pays informatisés ayant refusé la brevetabilité abusive prendraient si Linux devenait illégal aux USA... Et les universités qui se casseraient la gueule... A mon avis ça ferait du bruit...
Ok. Donc dire "Je tiens à être clair et à préciser dès maintenant qu'en aucun cas je ne vous invite à boycotter XXX qui viole mes droits de citoyen et les vôtres, mais que dans le cas où extrême hazard, vous preniez en même temps que moi la même décision alors ça ferait qu'on serait plusieurs et que le message passerait mieux." c'est cool ?
Non, la question n'est pas "est-ce que tout ce qu'ils téléchargent, ils l'achèteraient", mais "est-ce que s'ils ne pouvaient pas télécharger, ils achèteraient plus qu'en ce moment".
Et là, je répond oui, parce que c'est bien ce qui se passe. Là où Kevin 15 ans des boutons achetait un CD rempli de titres disparates qu'il allait écouter 3-4 fois d'une oreille de plus en plus distraite avant de l'oublier dans un placard, maintenant il télécharge disons 10 fois le même volume de musique, mais il ne paye plus rien. Bien sûr qu'il n'aurait pas acheté plus de compils qu'il en achetait avant, Kevin, s'il n'avait plus internet là tout d'un coup pouf, mais il se remettrait (peut-être) à acheter une fois de temps en temps une compile.
Le principe est aussi valable avec les autres types de disques à la con (genre une femme de président qui chuchotte des textes crétins, ou un ex de la nouvelle starac qui ne sait pas quoi faire de son absence de talent), et tu multiplies par le nombre de Kevins, tu ajoutes les mme Michu qui regardent TF1, et ça fait quand même encore des nouilles à l'industriel du disque.
Maintenant, la question intelligente que devraient quand même ce poser les lobbieurs, c'est est-ce qu'il leur es possible de faire régresser la planète à l'age pré-internet...
En gros, si je te comprend bien, ton argument là, c'est de dire qu'il faudrait arrêter de faire circuler des copies illégales pour montrer aux majors qu'on ne consommerait pas plus chez eux si on ne pouvait pas récupérer leurs bouses pour pas un rond ?
A ceci, quelques remarques :
- Il est évident qu'une (grande) partie de la raison pour laquelle les ventes de crottes des majors s'effondrent est quand même que personne ne voit l'intérêt direct d'acheter un support physique cher sur lequel il y a un caca que tu ne va visionner / écouter qu'une seule fois alors que c'est si facile de le récupérer pour pas un rond sur internet. Je veux dire, en admettant que ce soit légal ou que tu ne te fasse jamais prendre, tu préfèrerais quoi, télécharger un bronze sans payer quoi que ce soit ou acheter un disque sur lequel il y a la même matière fécale, dans le cas où de toute façon tu vas la voir une fois et c'est tout ?
- Il est également évident que ce sont souvent les pires excréments que produisent les majors qui sont les plus téléchargées, or ces mêmes immondices se vendaient très bien avant l'avènement de l'internet (rappelez-vous les compil's disco, rap, techno, etc. des années 90...). Eh oui, il n'y a pas que des pirateurs élitistes qui récupèrent illégalement des bon gros beaufs qui aiment les étrons audiovisuels quand ils sont bien gras.
- Même en admettant que les arguments plus haut ne sont pas valables, comment tu comptes faire pour convaincre les Kevins de ne pas télécharger des torrents de purin pour prouver que tu as raison ? (je suis curieux)
Je crois que les seules restrictions à la liberté d'expression, en france, c'est la diffamation et l'appel à la haine / discrimination / violence / trouble à l'ordre publique (mais je peux me tromper). Donc sauf erreur de ma part l'appel à faire comprendre à une entreprise privée que l'on est pas content en arrêtant d'acheter ses produits ne me semble pas illégal.
> Il est clair que mettre en place une documentation est assez fastidieux, cependant si celle-ci est faite en même temps que le développement c'est beaucoup moins contraignant. Un peu de rigueur dans la mise à jour et on s'y retrouve. Certes, les projets avancent un peu moins vite mais parfois ce n'est pas plus mal .... entre avoir une bibliothèque inutilisable parce que non documentée ou doc pas à jour, et une bibliothèque qui évolue moins vite mais qui est bien documentée, je choisis la deuxième ....
C'est aussi une question de volume. Pour un projet qui démarre en mono-développeur, ou qui est ambitieux avec trop peu de personnes, ou qui ne bénéficie pas d'une personne qui aime / sait organiser une doc, c'est inutilement handicapant. Dans ce genre de configuration, il vaut mieux (à mon avis, que je partage) partir à l'aventure, faire quelque chose de fonctionnel et imparfait, en retirer des leçons pour le futur, et faire un tant soit peu de commentaires dans le code et de doc intégrée.
Je prends un exemple (que j'aime vraiment pratiquer) : Ruby. La clarté du langage aide à commenter peu en conservant une bonne lisibilité (du moment qu'on évite de coder à la perl ou à la C). Dans ce cas, cependant, l'ouverture et la lecture du code rebutant toujours le débutant, il est positif de temps en temps de faire une explication pour débutants sur un site du projet, mais overkill et épuisant de faire une documentation exhaustive de tous les cas possibles.
> Loin de moi l'idée de trouver un coupable, simplement je déplore un état de fait. Et surtout, il y a encore des développeurs qui s'imaginent que le code source suffit, et qu'il n'y a pas besoin de documentation. Et c'est entre autre pour ça qu'en entreprise les LL se trainent une maivaise image.
>
> C'est une vision utopique du dev de LL.
Oui, enfin, en même temps, prendre les entreprises en exemple, c'est plutôt utopique aussi. Ce que j'ai beaucoup vu en SSII c'est :
- on ne factorise pas, ça ne sert à rien parce qu'on repars à 0 à chaque projet (nouvelles équipes constituées de bric et de broc, pas de phase d'analyse reposant sur des projets précédents, pas d'auto-formation digne de ce nom en interne, ...)
- c'est bien de faire des commentaires, mais avec les deadlines et tout ils sautent (et on récompense surtout le gars qui "pond de la ligne" et pas vraiment le gars qui réfléchit et propose des idées élégantes pour gagner du temps et de l'efficacité)
- la conception est un bon gros bloc de marbre gravé par un architecte, architecte qui est va sur un autre projet pendant la phase de réalisation
- la documentation livrée au client n'est pas à jour, pleine de répétitions de points e détails et de trous sur des choses essentielles pour comprendre le fonctionnement général, etc.
Non, la raison principale pour laquelle le LL a mauvaise presse devant une entreprise, c'est surtout parce que :
- on ne le paye pas (en licences) et que tout ce qui n'est pas cher est suspect de ne pas fonctionner
- c'est un royaume de bidouilleurs et tout ce qui se bidouille c'est pas fiable
- on n'a personne à attaquer en justice ou sur lequel faire pression quand on n'est pas content sinon soi-même
Ceci étant dit, il y a énormément d'entreprises qui commencent ou continuent à faire confiance aux les LL, en tête les hébergeurs (les serveurs qui coûtent pas cher, c'est bien quand on cause à des clients qui n'ont pas de très gros budgets mais qui sont nombreux), les SSII (houlà, crise financière tout ça, maintenant ça coûte cher une licence WebSphere, pfouuuu), et les startups (qui étaient déjà convaincues de toute façon, puisque pour bien démarrer une start-up, coût de licence zéro c'est mieux).
>> Il est impossible pour une tierce personne de déveopper une doc à jour pour du LL, sans mettre les développeurs dans la boucle, car le développement des LL va bien trop vite.
C'est peut-être parce que tu raisonnes trop en doc au forfait (une seule livraison finale, une seule grosse doc finale).
Je vais prendre un autre exemple Ruby : Rails. La doc de base est extrêmement bien faite (au point que je pioche dedans avant de chercher des tutoriaux), et n'a pas besoin de changer radicalement fréquement, mais la collaboration est encouragée (entre autres par l'utilisation d'un dépôt git publique et la possibilité d'envoyer des patchs de documentation).
Bien sûr, tôt ou tard les développeurs doivent être dans la boucle, mais il ne faut pas leur demander d'assurer tout le travail de documentation quel que soit le projet, sinon le développeur, il s'étiolle.
[^] # Re: Ne pas feindre la surprise
Posté par Bastes . En réponse au journal Après HADOPI... Piratage à l'Élysée !. Évalué à 10.
- les pages web que tu visite
- les emails non cryptés que tu lis (ou cryptés mais décryptés par un serveur pas par ton poste, comme sur un webmail)
- les conversations instantanées
- les commandes que tu passe sur des sites de vente en ligne
Donc oui, si Hadopi est tellement soutenu politiquement ce n'est pas que pour les beaux yeux des moines copistes de notre millénaire, c'est aussi pour introduire dans les esprits qu'internet devrait redevenir ce que selon eux il n'aurait jamais dû cesser d'être : un minitel un peu plus joli à regarder avec option big brother.
[^] # Re: Indie games
Posté par Bastes . En réponse au journal Indie game surpris par les ventes de la version Linux de son jeu. Évalué à 4.
[^] # Re: Tiens, on est déjà vendredi ?
Posté par Bastes . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 1.
...Ironie non plus apparemment.
# Tiens, on est déjà vendredi ?
Posté par Bastes . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 3.
[^] # Re: j'imagine
Posté par Bastes . En réponse au journal Le linux embarqué de l'A380 a planté en plein vol. Évalué à 10.
0:30
Clignotant, et tu décrémente toutes les minutes (surtout ne pas afficher les secondes), en augmentant le volume à chaque fois que tu décrémente.
Arrivé à 0:10 tu ajoute aux parasites radio un genre de prière islamique.
Arrivé à 0:5 tu fais clignoter une fois en rouge, une fois en blanc et tu ajoute un bip bien stressant.
A mon avis, à l'arrivée, si quelqu'un à le moindre doute que l'attaque vienne de toi, tu pars direct pour une prison secrète des services secrets de je ne sais quel pays qui assure la sécurité de la compagnie aérienne.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 2.
Quand je parlais de documentation qui ne rentre pas dans des petites cases carrées, je voulais par exemple parler de celle de shoes, qui incite à se remettre la tête ronde quand elle commence à devenir trop bêtement carrée :
http://shoooes.net/
Après, il y a des gens à qui ça fait peur, moi j'aime bien.
[^] # Re: L'homme qui a inventé le fil à couper le beurre
Posté par Bastes . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 3.
Un petit peu comme les fondamentalistes d'une religion qui contestent la validité de la science quand elle leur déplait, mais qui utilisent ses applications quand elle les arrange...
[^] # Re: Les brevets
Posté par Bastes . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 9.
Non ?
[^] # Re: Les brevets
Posté par Bastes . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 3.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 2.
Il y a plein d'utilisateurs de Rails qui trouvent la doc de l'api très utilisable et pas prise de tête, moi en tête. Je m'en sers tous les jours, j'y trouve ce que je cherche rapidement et je trouve que c'est généralement assez clair et complet.
Sinon, ce que ça change d'être libre ou privateur, beaucoup de chose, j'ai développé dans un autre message plus haut. La question "comment faire pour obtenir des projets libres qu'ils soient des copies conformes mais gratuites des privateurs" est un non-sens. La bonne question est "est-ce que ce que j'attends est un projet libre, qui avance au fur et à mesure, qui évolue et change, ou est-ce que je veux travailler sur le marbre d'un produit privateur complètement fini avec une documentation parfaitement stable". Apparemment tes désirs te feront préférer la 2° catégorie. Si tu demandes à un léopard de porter des rayures, ou un zèbre de porter des taches, tu seras souvent déçu par la réalité....
> Et qu'est-ce qui empêche d'avoir une doc à jour par rapport aux évolutions de version ? Le temps que ca prend? Ca n'a pas de sens : soit tu documentes et on utilise ton code, quitte à prendre plus de temps, sit tu documentes pas et personne n'utilise ton code et la ça sert à rien d'aller vite. De plus en mettant la doc à jour au fur et à mesure ça prend moins de temps plutot que de générer une doc après que la version soit sortie (et cette doc ne sera jamais à jour car le temps d'écrire la doc, la version N+1 sort)..... Et je te répète que je ne cherche pas une doc à jour pour la derniere version non stable, mais pour une version stable.
L'API, rien n'empêche qu'elle soit à jour, et au risque de te surprendre à de rares exceptions près elle l'est. Par contre, les blogs de trucs et astuce et certaines pages de la wiki officielle ne sont pas toujours maintenues comme elles devraient. D'où une interrogation : en parlant de l'API, ne parlerais-tu pas en réalité de la wiki de Rails ? (l'api : http://api.rubyonrails.org/, la wiki : http://wiki.rubyonrails.org/)
L'API donc est générée à partir des commentaires du code, automatiquement, elle est donc généralement très à jour (sauf peut-être quelques jours de temps en temps quand une nouvelle version importante remplace la précédente edge, et encore) tout comme les commentaires du code donc. Celle du site concerne la dernière version edge, mais comme c'est celle générée automatiquement si tu n'utilise pas la dernière edge tu peux très bien générer la documentation de ta version à partir de ta version avec un " rake doc:rails ", ça te génère un répertoire avec une version HTML complète et navigable des commentaires correspondant à ta version en cours à toi au temps t sur ta machine m.
En fait, j'ai vraiment l'impression à te lire que tu as foncé dans le Rails tête baissée et que du coup tu es frustré parce que tu ne sais pas où trouver l'information et savoir par où commencer. C'est valable pour d'autres projets que Rails, privateurs ou libres. Si tu avais commencé par exemple par demander de l'aide sur un forum pour savoir par où commencer, et cherché de l'information de base (sur internet, dans un livre synthétique, etc.), à mon avis tu serais maintenant plus à l'aise et tu n'aurait peut-être pas un avis aussi orienté sur la question.
Rappelles-toi tes premiers pas dans les projets informatiques, rappelles-toi quand on t'a tenu la main pour prendre en main tel ou tel outil que maintenant tu aimes employer, rappelles-toi les heures à chercher une information sans la trouver parce que tu ne savais pas où chercher.
Bien sûr on voudrait que le savoir et l'expérience nous tombent tout cuit tout roti, mais le monde n'est pas comme ça, ce n'est pas plus la faute aux projets libres ou privateurs, il faut chercher pour trouver de l'info, et pour trouver il faut savoir parfois dans quelle botte de foin se cache l'aiguille.
De ce point de vue la l'avantage du libre c'est de pouvoir faire appel à l'aide de la communauté, et de laisser libre accès en lecture / écriture à ceux qui veulent améliorer la documentation. Le privateur a d'autres avantages (ne proposer de la documentation que pour ce qu'il veut bien te laisser voir par exemple, ça peut être un atout pour ne pas s'épuiser à commenter tout, c'est juste un exemple). A toi de faire ton choix en fonction de tes besoins.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 2.
Ah oui, quand il n'est pas libre, pas itératif et pas vivant.
[^] # Re: Faire quelque chose de faisable et utile
Posté par Bastes . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 3.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 3.
On ne doit pas parler de la même chose alors. A volume égal, la doc des méthodes et des objets eux-mêmes, plus tu la détache et plus c'est pénible de la garder à jour, alors que la mettre proprement dans les commentaires prévus à cet effet permet de générer sous différents formats de façon automatisée sans perdre du temps à synchroniser à la main.
Par contre, si à fonctionnalité égale je dois commenter une seule méthode (Ruby) ou 3 méthodes (Java quand il y a plusieurs façons de fournir les paramètres), c'est clair je préfère Ruby.
> Je suis d'accord avec toi sur le fait qu'une version non stable n'a pas à être documenté, je parle de version stable. Et lorsque j'ai installé Rails 2, c'était une version considérée comme stable ( ou j'ai mal compris quelque chose).
Alors non on n'est pas d'accord. Je ne vois pas en quoi on ne devrait pas documenter une version non stable. Mais je crois que tu veux dire en fait "une version non stable n'a pas à sortir publiquement". Et là, vu que tu adopte un point de vue privateur, oui, c'est logique.
Dans un modèle de développement libre, on peut très bien rendre publiquement disponible même (surtout) les version non stables, en avertissant les visiteurs que la version non stable ne l'est pas encore. C'est comme ça que des utilisateurs peuvent soumettre des patchs pour stabiliser, indiquer les bugs qu'ils trouvent, et aider à évaluer la stabilité de l'ensemble. Aussi, à soumettre des patchs de commentaires pour améliorer la documentation.
Et que tu aies compris quand tu as installé Rails 2.0.0 que c'était une version stable... Comment te dire... Tu as mal compris quelque chose, oui.
>> Dans le cas d'un modèle privateur, puisque c'est un produit que l'on vend, on ne sort une nouvelle version qu'une fois que tout est lisse, arrondi, calé, ou du moins que les bugs sont cachés sous le tapis, et on lui met un gros numéro bien flamboyant pour dire "tadaaaaaa". Ici ça ne sert à rien d'être une version en dessous de la pointe, puisque la pointe n'est pas disponible avant d'être stabilisée.
> Tu caricatures ..... Je ne suis pas spécialiste Microsoft, ou Borland, mais je me rappelle que lorsque je faisais du développement Windows, l'API était sufisamment bien documentée pour pouvoir s'en sortir dans la plupart des cas .... Toi tu me parles de développements fait à l'arrache par une sSII pour un projet spécifique, et la je te l'accorde les SSII ne sont pas toujours des modèles dans le genre.
Non, je ne caricature pas, je constate. De plus je ne juge pas. C'est normal d'essayer de faire mousser un produit que l'on veut vendre, et c'est normal qu'on lisse les bords et qu'on arrondisse les coins, voir qu'on mette de la poussière sous le tapis quand il y en a qu'on n'a pas le temps de vider, tout le monde le fait, ce n'est pas l'apanage des SSII et Windows ou Borland ne sont pas en reste. De toute façon ce n'est pas un crime et ça peut être réparé discrètement ensuite à coups de patchs.
Et surtout, ce n'est pas une décision volontaire d'un dirigeant ou des développeurs, c'est un sous-produit du modèle en cascade "on livre pour quand c'est demandé / quand le marché est réceptif" comme le fait de soumettre des versions non stable est un sous-produit du modèle itératif "on livre petit à petit jusqu'à ce que ça fonctionne bien et quand ça fonctionne bien on appelle ça stable jusqu'à la prochaine stable".
> On en revient à ce que je disais plus haut : lire les commentaires parsemés dans le code, ca coute cer en temps à un développeur, bien plus qu'une aide en ligne à la "VBA" .... Apres entre le README qui indique comment installer, le README qui indique comment l'utiliser, etc .... c'est pas simple de s'uy retrouver.
Sinon tu as des outils pour prendre les commentaires et faire les jolies pages HTML lisibles / cherchables avec le code caché tant que tu ne veux pas le voir, avec Ruby ça s'appelle RDoc, avec Java JavaDoc, avec PHP, PHPDoc (c'est dingue, on dirait presque qu'ils se sont concertés). Ils peuvent par exemple prendre le README et en faire une jolie page de garde avec des titres et tout.
Avec ça, tu rajoutes un wiki sur ton site, où tu mets des schémas globaux, des explications sur les principes importants, des tutoriaux pour les tâches courantes, et n'importe qui peut s'y retrouver. Le point positif, c'est que c'est moins lourd et chiant à maintenir qu'une documentation complètement séparée du code, parce que quand on change la signature d'une méthode qui a un commentaire, on pense plus facilement à changer le commentaire et c'est moins pénible que de repasser sur toute la doc et tout le code pour voir les choses qui ont changé après coup.
> Je n'ai pas encore assez de recul sur Ruby et Rails pour répondre, mais ce n'est malhereusement le cas que d'une infime partie des projets libres. Pour beaucoup, la seule doc est le code ..... Et puis pour Ruby et rails en particulier il est difficile de s'y mettre sans un bon bouquin à côté ....
A mon avis oui, tu as assez peu de recul sur Ruby on Rails, probablement parce que tu as attaqué Rails sans avoir au préalable un peu creusé Ruby. C'est ce qui fait que oui, il faut généralement un bouquin pour attaquer parce que sinon c'est un trop grand pas à franchir.
C'est un peu comme vouloir apprendre le calcul intégral sans savoir faire d'additions, soustractions, multiplications, etc., c'est pas strictement impossible mais il va falloir beaucoup potasser et tu vas trouver ça beaucoup plus compliqué.
Ensuite, je pense que si je voulais attaquer le développement d'un jeu en 3D avec directX en C++, j'aurais quand même intérêt d'avoir des bases de C++ avant d'attaquer l'API directX par la face nord, API bien foutue ou pas.
Et puis franchement, commencer dans n'importe quelle API en plongeant direct dans l'API sans chercher des autres sources (tutos, blogs, forums de développeurs, etc.) c'est quand même un peu suicidaire non, à moins de déjà maîtriser à mort le sujet.
> Dans un contexte de travail collaboratif, c'est mieux : tu définis les interfaces avant de les implémenter :ceux qui se basent sur ton travail peuvent travailler sans avoir à t'attendre ....
En Java oui, puisque le Java est fortement typé, que d'écrire du code prends beaucoup de temps, qu'il y a beaucoup de répétitions inutiles (méthodes paravent, polymorphisme par clonage de signatures, répartition de responsabilités en multipliant le nombre de classes ...), ce qui oblige à faire des architectures de classes apriori pour faire en sorte que tout colle bien ensuite, ce qui plombe les projets parce que tout ne se passe jamais vraiment comme c'était prévu au départ (le client change d'avis, l'équipe avait mal compris / interprété, une contrainte technique force à considérer un cas imprévu...). C'est bureaucratique, lourd, et généralement ça tue l'esprit d'initiative chez les gens qui vont devoir développer derrière les architectes qui on fait les plans. Bof.
Maintenant, quand le langage n'est pas une carapace handicapante, comme en Ruby (typage dynamique "... alors pour moi c'est un canard", possibilité d'ajouter des comportements factorisés dans la définition de classe ou même à la volée grâce aux modules, etc.), on n'a pas besoin de tout penser avant de se mettre à coder, on peut commencer en itératif en définissant des lignes générales, prototyper jusqu'à obtenir un modèle convenable, casser le prototype et réaliser l'itération avec tests et factoriser ensuite. Et la collaboration se passe bien s'il y a communication, proximité, tests automatisés et confiance, ces 4 éléments sont nécessaires et c'est non-négociables par contre.
Il faut faire confiance apriori en sa capacité à trouver une solution pour chaque problèmes qui se présenteront en route, mais que l'on parte avec un plan rigide et sur-développé comme en Java ou une direction globale précise mais une ligne souple comme en Ruby, on arrive au même point au final et il y aura des embûches en cours de route de toute façon (le meilleur plan du monde n'est qu'un plan, la réalité a souvent tendance à le contredire).
et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
> 1/ D'abord combien de projets le font ? très peu. Et c'est ce que je déplore entre autres.
Plein de projets libres le font, au contraire, mais ils ne sont pas forcément toujours très connus / reconnus par les utilisateurs. Github par exemple propose de base un wiki pour chaque projet.
Au hasard dans ceux que j'utilise et que je lis beaucoup :
- Rails (beaucoup de tutos sont justement sur la Wiki)
- Shoes (toolkit graphique Ruby)
- Inkscape
- Ubuntu
> 2/ Sinon, encore de la dispersion :
> - Readme
> - code source
> - wiki projet
> - les forums
> - les FAQ
> - un bouquin qui fait la glue avec ça ...
Attends, tu mélanges tout là.
Le README ça va avec le code source, et ça peut être inclu dans la doc généré, généralement d'ailleurs ça fait la première page de doc générée automatiquement depuis les sources.
Un wiki projet c'est pour trouver les bases pour commencer, ça n'a rien à voir avec les sources et c'est normal, le but n'est pas d'aller au fond des choses mais de présenter une vue d'ensemble et des "portes d'entrées" dans les concepts principaux. C'est normal que ça ne soit pas intégré à la doc de l'API plus complète, moins didactique, plus directe, plus "sèche" (moins d'exemples pas à pas). Les FAQ ça s'intègre très bien aux wiki, c'est même limite la meilleur façon de les case.
Les forums officiels c'est là pour mettre en relation une question précise avec une réponse précise, quand une question - réponse revient souvent c'est une bonne idée de la faire remonter vers la wiki, ou dans la doc quand c'est un trou. C'est un autre média, ça n'a rien à voir, et rien n'empêche de le mettre sur un même nom de domaine que le site de l'API et du code par exemple.
Les forums officieux, les bouquins, c'est pas maîtrisable par les responsables du projet, chacun fait ce qu'il veut et encore heureux.
Bref, de tous ces différents médias, les "officiels" sont tous groupables sous un même nom de domaine commun, et les "officieux" font leur vie. En même temps c'est plutôt bien de disperser les médias officieux, ça diffuse l'information, ça donne des droits d'auteur à des auteurs de livres, quand ils sont bons, ça fait bloguer les blogueurs.
> Et tout ca sans que les développeurs s'impliquent dans la doc (je ne leur demande pas de rédiger de la doc hein) ... En plus chaque projet ou langage utilise ses propres convensions ou format ..... Pour un développeur windows par exemple c'est plus simple : un IDE qui contient l'aide dont il a besoin ....
> Si on pouvait arriver à ca je serais hereux .... mais j'y crois pas trop.
Ok, je ne sais pas toi, mais moi la dernière fois que j'ai consulté la MSDN je m'y suis perdu et je n'ai pas trouvé la réponse après une soirée, j'ai laissé tomber. Comme quoi c'est aussi subjectif, et qu'un outil demande un temps de prise en main de toute façon et quel qu'il soit.
> 3/ Qu'est-ce qui empêche de rédiger de la doc en même temps que les tests ? Pas grand chose puisque les tests sont censé, comme leur nom l'indique, testerles cas d'utilisation. Prendre certains bouts de code développés pour le test comme exemple serait bien pratique ....
Rien ne l'empêche, mais c'est pas forcément une bonne idée, tout comme celle qui voudrait que les tests sont fait au début et n'évoluent pas ensuite. On ne sait pas de quoi demain sera fait, il vaut mieux écrire les tests et les commentaires peu de temps avant le code, et les faire évoluer quand le code évolue pour mieux convenir aux besoins.
Considérer la programmation d'une façon verticale (on descend d'une vérité mathématique absolue jusqu'à lui donner corps) me semble être une erreur. Je préfère l'approche "biologique", on prend un problème, on le résout, on consolide, on livre, on prend de l'expérience, on réitère. C'est plus "darwinien" (le meilleurs finit pas survivre et transmet ses caractéristiques aux suivants), et moins "immanent" (la perfection existe au-delà de notre royaume, mais on doit s'en approcher quel que soit le prix).
> Juste un détail : ne prends pas mes commentaires comme si je crachais sur le LL et les développeurs : j'essaie d'être constructif et de mettre en avant les points qui me paraissent négatifs dans le LL, et je serai le premier hereux lorsque ces problèmes auront disparu.
Je ne le prend pas comme une insulte, mais plutôt comme un point de vue biaisé concernant le mode de fonctionnement de projets libres. C'est pourquoi je défend mon point de vue jusqu'à changement de celui-ci et / ou fin de la discussion.
Je ne suis pas un zélote d'un fonctionnement ou l'autre (même si je préfère moi me trouver dans un mode de fonctionnement itératif, c'est un choix personnel, que je défend mais que je n'impose pas), chacun peut mieux convenir selon la situation. Par contre, appliquer un modèle ou l'autre a des conséquences sur le format de la documentation officielle et de l'information en général, et attaquer l'api d'un projet libre avec les apriori d'un projet privateur n'a pas de sens, et ne peut que te mener à l'échec et à la frustration, l'inverse est vrai aussi.
> En fait de cette discussion me viennent des idées, mais je ne pense pas que les développeurs s'y plieraient ... Ya qu'a voir les tentatives d'uniformisations telles que LSB ou autres pour se faire une idée ....
Justement, pourquoi faire uniforme ? Est-ce que le monde sera plus beau et plus vivable quand on vivra dans des petites cases de béton de taille réglementaire, avec le choix de la couleur intérieure parmis les couleurs réglementaires, avec les meubles et la décoration à choisir dans les meubles et les décorations standards ?...
Le libre c'est la liberté d'expérimenter comme on le sent, c'est valable aussi pour la documentation. C'est un modèle vivant, presque organique, qui peut donner des bases stables (après tout, l'évolution naturelle a bien donné à l'essentiel des espèces vivantes une même base standard, l'ADN, il n'y a pas de raison que la liberté de création en informatique ne puisse pas reposer sur des standards quand ils sont plus adaptés) mais pas indépassables le jour où on trouve une meilleur idée. Vouloir mettre tout dans des cases bien propres c'est le mirage un peu schizo d'un Descartes qui pensait les animaux comme des machines biologiques déterminées en même temps que "Je pense donc je suis". La vie ne rentre pas dans des petites cases, ou alors avec un truc coupant bien aiguisé...
[^] # Re: Viendez faire du Ruby...
Posté par Bastes . En réponse au journal Il faut sauver le soldat %. Évalué à 2.
Bon, moi je suis immunisé, je m'est déjà méta-programmé. Comme quoi Ruby ça aide.
# Viendez faire du Ruby...
Posté par Bastes . En réponse au journal Il faut sauver le soldat %. Évalué à 4.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 2.
Si tu veux comparer ce qui est comparable, commence par prendre une version stable (pas Rails 2.0.0 mais plutôt 2.2.2 par exemple) et ne prends pas la version "edge" puisque que c'est celle qui est encore en travaux, donc où la doc est la moins à jour et les bugs imprévus pas encore réparés.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 2.
> On préfère acheter une bibliothèque payante, fermée mais bien documentée (pour l'utilisation) qu'une bibliothèque libre, code ouvert et peu documentée, parce qu'un développeur qui doit passer des jours à ausculter le code pour comprendre comment ça marche, ça coute cher ....
Payer ne te donne pas de garantie que ce soit propre et clair, juste une personne à blâmer si ça ne l'est pas et l'impression d'avoir un levier. Tu peux avoir du propre et du clair aussi bien en libre qu'en non-libre et le crade et pas clair n'est pas l'apanage du libre non plus.
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord.
> Non.
> Ruby on Rails est l'exemple typique de ce que je déplore : on sort une version (notamment la 2.0), et on ne sort pas de doc associée. Quelqu'un qui connait un peu ruby ou rails s'en sort mais je t'assure que quelqu'un qui a voulu se mettre à Ruby lorsque Ruby 2.0 est sorti aurait pu être totalement dégouté de ce langage. D'ailleurs, quand j'allais en cours, il y a plus de 10 ans, on m'a toujours encouragé à écrire un minimum de documentation _avant_ d'écrire mon code, d'écrire par exemple, pour une fonction, les paramètres qu'elle prend, le type et l'utilité de ces paramètres, ainsi que le code retour. On encourage également, dans certaines méthodes de développement, de décrire clairement les classes que l'on crée (notamment à l'aide d'UML), et ce _avant_ de commencer à coder. On encourage aussi à écrire les procédures de test unitaure _avant_ de coder les classes/fonctions (Methodes XP par exemple), et ce n'est pas pour rien.
Mais tu compares des choses non comparables, les n° de version ne veulent pas dire la même chose en libre et en privateur.
Dans le cas de Ruby ou de Rails, par exemple, les numéros de version se lisent :
x.y.z où x représente un très gros changement fondemental de l'API, y un apport de nouvelles fonctionalités majeurs ou des changements importants mais pas critiques, et x des changements mineurs ou des bugkills. Rien ne te garantis que la version 2.0.0 soit plus stable qu'une version 1.8.7 ou 0.1.23, je dirais même que la version 2.0.0 a beaucoup plus de chances d'être bugée, sa documentation incomplète ou à revoir par endroits. Dans ce cas, il vaut mieux rester une version en arrière de la pointe si tu veux de la stabilité et de la doc lisse.
Dans le cas d'un modèle privateur, puisque c'est un produit que l'on vend, on ne sort une nouvelle version qu'une fois que tout est lisse, arrondi, calé, ou du moins que les bugs sont cachés sous le tapis, et on lui met un gros numéro bien flamboyant pour dire "tadaaaaaa". Ici ça ne sert à rien d'être une version en dessous de la pointe, puisque la pointe n'est pas disponible avant d'être stabilisée.
Enfin, si tu veux de la méthodologie XP avec tests validés avant commit tu peux difficilement accuser Rails de ne pas être à la pointe de cette pratique. Pour écrire les tests avant codage, je ne suis pas dans le secret de l'équipe Rails core, mais moi-même en toute honnêteté je ne le fais pas toujours, et il m'arrive de me demander si c'est vraiment si meilleur que de les faire peu de temps après avoir fait une fonctionnalité (mais avant de factoriser bien entendu).
> Ce n'est pas non plus ce que je leur demande .... mais on peut leur en demander un minimum .... Et pour moi le minimum c'est d'expliquer comment utiliser le code qu'ils ont produit et ce que fait ce code.
En général les fichiers README sont là pour ça, et le commentaire aussi, en tout cas en Ruby (je n'ai pas fait beaucoup de C, VB, ou autres langages "chiants" en dehors du Java et du PHP...). Après il y a des gens qui ne lisent pas les readme ou les commentaires (en Ruby on génèrent les docs facilement à partir des commentaires, et comme contrairement à Java on ne fait pas plein de méthodes creuses qui appellent en fait une autre méthode qui fait vraiment le boulot, c'est moins fatiguant).
> En fait j'aimerais avoir pour certains projets libre, non seulement le code mais surtout les représentations (UML) de l'ensemble du projet. Mais la on s'éloigne du sujet initial (les bibliothèques) ...
Il n'y a pas que l'UML dans la vie...
Tu parlais d'XP, en XP on travaille beaucoup plus à partir de "stories", on fait des schémas beaucoup plus libres et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
[^] # Re: Changement de stratégie
Posté par Bastes . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 2.
[^] # Re: Les brevets
Posté par Bastes . En réponse au journal MS attaque TomTom et Linux (putain de brevets). Évalué à 10.
Ce qui est amusant par contre, c'est que microsoft n'abatte toujours pas les cartes contre Linux lui-même...
...Mais attends, abattre les cartes contre Linux, ça voudrait dire faire le procès du siècle. Immaginez, Microsoft VS le reste du monde. Enfin, disons le reste des entreprises utilisant du LL aux USA. Je me demande qui gagnerait... Et les conséquences. Imaginons que redmond l'emporte. Imaginez la longueur d'avance que l'europe, l'Inde, et tous les pays informatisés ayant refusé la brevetabilité abusive prendraient si Linux devenait illégal aux USA... Et les universités qui se casseraient la gueule... A mon avis ça ferait du bruit...
[^] # Re: Comment interdire un boycott ?
Posté par Bastes . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 2.
[^] # Re: Mauvaise cible!
Posté par Bastes . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 3.
Et là, je répond oui, parce que c'est bien ce qui se passe. Là où Kevin 15 ans des boutons achetait un CD rempli de titres disparates qu'il allait écouter 3-4 fois d'une oreille de plus en plus distraite avant de l'oublier dans un placard, maintenant il télécharge disons 10 fois le même volume de musique, mais il ne paye plus rien. Bien sûr qu'il n'aurait pas acheté plus de compils qu'il en achetait avant, Kevin, s'il n'avait plus internet là tout d'un coup pouf, mais il se remettrait (peut-être) à acheter une fois de temps en temps une compile.
Le principe est aussi valable avec les autres types de disques à la con (genre une femme de président qui chuchotte des textes crétins, ou un ex de la nouvelle starac qui ne sait pas quoi faire de son absence de talent), et tu multiplies par le nombre de Kevins, tu ajoutes les mme Michu qui regardent TF1, et ça fait quand même encore des nouilles à l'industriel du disque.
Maintenant, la question intelligente que devraient quand même ce poser les lobbieurs, c'est est-ce qu'il leur es possible de faire régresser la planète à l'age pré-internet...
[^] # Re: Mauvaise cible!
Posté par Bastes . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 1.
A ceci, quelques remarques :
- Il est évident qu'une (grande) partie de la raison pour laquelle les ventes de crottes des majors s'effondrent est quand même que personne ne voit l'intérêt direct d'acheter un support physique cher sur lequel il y a un caca que tu ne va visionner / écouter qu'une seule fois alors que c'est si facile de le récupérer pour pas un rond sur internet. Je veux dire, en admettant que ce soit légal ou que tu ne te fasse jamais prendre, tu préfèrerais quoi, télécharger un bronze sans payer quoi que ce soit ou acheter un disque sur lequel il y a la même matière fécale, dans le cas où de toute façon tu vas la voir une fois et c'est tout ?
- Il est également évident que ce sont souvent les pires excréments que produisent les majors qui sont les plus téléchargées, or ces mêmes immondices se vendaient très bien avant l'avènement de l'internet (rappelez-vous les compil's disco, rap, techno, etc. des années 90...). Eh oui, il n'y a pas que des pirateurs élitistes qui récupèrent illégalement des bon gros beaufs qui aiment les étrons audiovisuels quand ils sont bien gras.
- Même en admettant que les arguments plus haut ne sont pas valables, comment tu comptes faire pour convaincre les Kevins de ne pas télécharger des torrents de purin pour prouver que tu as raison ? (je suis curieux)
[^] # Re: Comment interdire un boycott ?
Posté par Bastes . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 2.
Je crois que les seules restrictions à la liberté d'expression, en france, c'est la diffamation et l'appel à la haine / discrimination / violence / trouble à l'ordre publique (mais je peux me tromper). Donc sauf erreur de ma part l'appel à faire comprendre à une entreprise privée que l'on est pas content en arrêtant d'acheter ses produits ne me semble pas illégal.
Avis aux juristes mieux informés.
[^] # Re: La faute aux députés et ceux qui les élisent
Posté par Bastes . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 2.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 4.
C'est aussi une question de volume. Pour un projet qui démarre en mono-développeur, ou qui est ambitieux avec trop peu de personnes, ou qui ne bénéficie pas d'une personne qui aime / sait organiser une doc, c'est inutilement handicapant. Dans ce genre de configuration, il vaut mieux (à mon avis, que je partage) partir à l'aventure, faire quelque chose de fonctionnel et imparfait, en retirer des leçons pour le futur, et faire un tant soit peu de commentaires dans le code et de doc intégrée.
Je prends un exemple (que j'aime vraiment pratiquer) : Ruby. La clarté du langage aide à commenter peu en conservant une bonne lisibilité (du moment qu'on évite de coder à la perl ou à la C). Dans ce cas, cependant, l'ouverture et la lecture du code rebutant toujours le débutant, il est positif de temps en temps de faire une explication pour débutants sur un site du projet, mais overkill et épuisant de faire une documentation exhaustive de tous les cas possibles.
> Loin de moi l'idée de trouver un coupable, simplement je déplore un état de fait. Et surtout, il y a encore des développeurs qui s'imaginent que le code source suffit, et qu'il n'y a pas besoin de documentation. Et c'est entre autre pour ça qu'en entreprise les LL se trainent une maivaise image.
>
> C'est une vision utopique du dev de LL.
Oui, enfin, en même temps, prendre les entreprises en exemple, c'est plutôt utopique aussi. Ce que j'ai beaucoup vu en SSII c'est :
- on ne factorise pas, ça ne sert à rien parce qu'on repars à 0 à chaque projet (nouvelles équipes constituées de bric et de broc, pas de phase d'analyse reposant sur des projets précédents, pas d'auto-formation digne de ce nom en interne, ...)
- c'est bien de faire des commentaires, mais avec les deadlines et tout ils sautent (et on récompense surtout le gars qui "pond de la ligne" et pas vraiment le gars qui réfléchit et propose des idées élégantes pour gagner du temps et de l'efficacité)
- la conception est un bon gros bloc de marbre gravé par un architecte, architecte qui est va sur un autre projet pendant la phase de réalisation
- la documentation livrée au client n'est pas à jour, pleine de répétitions de points e détails et de trous sur des choses essentielles pour comprendre le fonctionnement général, etc.
Non, la raison principale pour laquelle le LL a mauvaise presse devant une entreprise, c'est surtout parce que :
- on ne le paye pas (en licences) et que tout ce qui n'est pas cher est suspect de ne pas fonctionner
- c'est un royaume de bidouilleurs et tout ce qui se bidouille c'est pas fiable
- on n'a personne à attaquer en justice ou sur lequel faire pression quand on n'est pas content sinon soi-même
Ceci étant dit, il y a énormément d'entreprises qui commencent ou continuent à faire confiance aux les LL, en tête les hébergeurs (les serveurs qui coûtent pas cher, c'est bien quand on cause à des clients qui n'ont pas de très gros budgets mais qui sont nombreux), les SSII (houlà, crise financière tout ça, maintenant ça coûte cher une licence WebSphere, pfouuuu), et les startups (qui étaient déjà convaincues de toute façon, puisque pour bien démarrer une start-up, coût de licence zéro c'est mieux).
>> Il est impossible pour une tierce personne de déveopper une doc à jour pour du LL, sans mettre les développeurs dans la boucle, car le développement des LL va bien trop vite.
C'est peut-être parce que tu raisonnes trop en doc au forfait (une seule livraison finale, une seule grosse doc finale).
Je vais prendre un autre exemple Ruby : Rails. La doc de base est extrêmement bien faite (au point que je pioche dedans avant de chercher des tutoriaux), et n'a pas besoin de changer radicalement fréquement, mais la collaboration est encouragée (entre autres par l'utilisation d'un dépôt git publique et la possibilité d'envoyer des patchs de documentation).
Bien sûr, tôt ou tard les développeurs doivent être dans la boucle, mais il ne faut pas leur demander d'assurer tout le travail de documentation quel que soit le projet, sinon le développeur, il s'étiolle.