Énormément de gens sensés se faire comprendre par l'écriture ne se relisent pas, au hasard, les journalistes. Ils accumulent fautes d'orthographe ou de grammaire, néologismes, acronymes, etc.
ben pourqoui se relire, il y a les correcteures dortaugraffe. D'ailleur il en fodré un ossi sur linuxfr ...
seconde explication : remplace "livrée" dans mon commentaire auquel t as répondu par un autre terme (que tu pourras choisir) qui n'a pas de connotation contractuelle. Autrement dit, je m'attends à ce que la version X.Y.Z considérée comme n'étant plus en développement sorte avec une documentation à jour ......
C'est bien ce que je dis, tu raisonne en livraison unique à un client garantie par contrat avec une seule documentation fixe et finale
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.
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.
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.
Tu prends mes commentaires un peu trop au pied de la lettre .....
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.
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. Après si quelqu'un veut vendre ses bibliothèques, il a intéret à bien écrire sa doc .... Après je t'accorde que payer n'est pas en soi une garantie d'avoir une documentation de qualité, mais souvent ça aide (tout dépend aussi à qui tu t'adresses, mais c'est un autre pb).
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord. La réponse que tu as apporté ne le laissait pas paraitre ....
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.
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).
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.
C'est ce que j'ai fait .... et ça s'est plutot bien passé (je ne reviendrai plus au PHP).
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.
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...).
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.
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).
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é ....
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).
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 .... Et tu remarqueras que pour ma part je ne parlais pas de Rails mais que j'étais dans une optique plus globale.
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 C'était un exemple ..... ne prends pas mes propos au pied de la lettre. Que ce soit UML ou autre chose, ce n'est pas le plus important. JE parle d'UML parce que ç'est un ensemble d'outils normalisés et qui restent assez clair et "universel". Cela dit si chacun utilise sa propre convension, comment veux-tu ensuite regrouper tout ça dans un ensemble cohérent (ce qui était l'objet du fil initial) ...
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.
2/ Sinon, encore de la dispersion :
- Readme
- code source
- wiki projet
- les forums
- les FAQ
- un bouquin qui fait la glue avec ça ...
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.
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 ....
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.
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 ....
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 :
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 ....
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.
On est pas obliger d'expliciter tous les cas possible. Cependant ce qui pour moi constitue un bon exemple de documentation bien faite (mais pas parfaite) c'est par exemple la documentation de VBA dans Excel.
Tu as une aide et une explication sur les fonctions, les paramètres qu'elles prennent ainsi qu'un exemple d'utilisation. Tu n'as pas un exemple sur tous les cas d'utilisation, mais suffisamment pour comprendre comment ça marche.
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
C'est vrai mais ce n'est pas la seule raison : voir plus haut.
Je vais prendre un autre exemple Ruby : Rails. La doc de base est extrêmement bien faite
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.
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.
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 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) ...
En même temps, c'est pas forcément facile / agréable / gratifiant de maintenir de la documentation à jour, et certains développeurs y épuisent leur goût de faire du LL s'ils s'y ennuient.
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 ....
Tout rejeter sur le dos des développeurs, c'est facile mais contre-productif
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.
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.
L'idée de faire de la documentation partagée me semble beaucoup plus efficace, et encourage, si tu ne trouve pas ce que tu cherches sur la doc partagée officielle, à l'ajouter quand tu le trouves ailleurs pour que tout le monde en profite.
D'accord avec toi, cependant les développeurs doivent en faire un minimum. Et la il s'agit plus d'adopter des conventions et des normes communes dans un développement, qui pourront être utilisés par des outils tiers pour centraliser cette doc. Il faut aussi en cas de besoin avoir un chemin inverse : reporter les modifications de la doc "en ligne" par exemple vers le code source .... un peu ambitieux mais pourquoi pas ?
Juste une queston : as-tu déjà essayé de documenter un projet que tu ne connais pas, rien qu'à partir du code source ? Moi, oui, et le temps de documenter ce que tu as compris, c'est obsolète car une ou deux autres versions du projet sont sorties et tout est à refaire.
Sachant que le vrai contenu HD (ie reellement filme en haute def) coute plus cher a produire (achat de camera + nouvelle chaine de montage etc.), ca se tient.
Ca ne tient pas pour les anciens films ....
Maintenant je ne pense pas que la caméra ait un impact aussi important, rapporté au budget global et au nombre de films vendu ...
Enfin je pense que les caméras n'ont pas attendu que le HD soit disponible pour le grand public pour s'équiper en matériel HD. ...
Parce que , et je le déplore, la grande majorité des développeurs du libre s'imaginent que le code source suffit et est amplement suffisant.
Parce que la majorité des développeurs du libre en ont rien à faire des gens qui ne veulent ou ne peuvent passer des heures à lire des lignes de code source pour récupérer une info sur une ou deux classes.
Parce que beaucoup de développeurs, même dans le libre, développent "à l'arrache", codent "à la volée" sans avoir écrt une analyse préalable ..... ou alors ne partagent pas cette analyse.
Je déplore cette attitude. Pour moi la documentation devrait être faite avant de coder.
avec des procédures de déploiements correcte, la différence est minime. La où je bosse, ce qui prend du temps ce n'est pas l'installation physique (rackage + cablage) ni celle de l'OS, c'est la configuration (même chose qu'avec des VMs). Le clonage ça marche aussi avec des machines physiques très rapidement.
T'as de la chance .... Je bosse en ce moment dans une grosse structure ou c'est la croix et la bannière pour installer des serveurs ( a juste titre : les datacenters sont full, tant au niveau consommation électrique que l'emplacement au sol).
tu peux faire tourner plusieurs applis sur 1 seul serveur et tu n'es pas obligé d'acheter que des bêtes de courses.
Tu n'a pas la même isolation, ni même la même finesse de répartition de ressources que sur des VM.
La virtualisation n'a rien à voir la dedans, les serveurs ont tous une console d'administration à distance.
Bien sur que si ....
1 serveur physique = 1 connection d'administration/serveur = 1 cable = 1 port de switch, etc ....
N serveurs virtuels = 1 ip d'administration = 1 cable, = 1 port de switch ...
Hors VM je ne connais pas de système capable d'effectuer des migrations à chaud. Les clusters type HACMP, Service Guard ou autre on tous un temps de bascule et une interruption de service, le temps de la bascule.
'avoue que je n'avais pas pensé à la souplesse, mais dans ce cas, le précédent exemple était un peu de mauvaise foi : totof supposait que les blades et les machines virtuelle n'était que pour les frontaux et que les machines d'appli étaient sur des machines physiques différentes ;)
Dans ma philosophie je ferais des tests de charge avant de mettre en prod, et comme ça je connaitrais le bon (enfin une approximation) dimensionnement pour mon objectif ;)
Moua ha ha ha ha ha !!!!
Excuse-moi, ce n'est pas pour toi mais .... Si tu savais commment se passent les tests de perfs dans la majorité des boites .... quad ils sont faits.
Tu vends un film en VOD, appliques des tarifs agressifs en fonction de la diagonale de l'écran sur lequel le gentil acquéreur va regarder ce film (avec un petit supplément pour les 16:9)...
tiens curieux, en lisant ça je n'ai pu m'empêcher de faire une analogie avec le mode de facturation de certains logiciels (tarif au CPU, au type de serveur, à la quantité de RAM présente, txc ...).
Sinon ce principe existe déjà : un film sur support HD est facturé plus cher que sur DVD ..... parce que potentiellement tu peux le regarder sur un matériel quui te donne une meilleur qualité. Mais ça n'a rien couté de plus (ou si peu) à produire: ce n'est que de la copie.
. Et vu les progrès réalisé en matière d'automatisation
C'est là que ton raisonnement cloche : une émotion n'est pas un automatisme ....
Sinon je suis d'accord avec toi que les synthèses vocales ont fortement progressé, mais dans le contexte de la dépèche, il sera impossible - et ça j'en suis convaincu - de créer une synthèse vocalae capable de restituer une oeuvre écrite avec les émotions adaptées, sans qu'un travail d'adaptation humain ne passe derrière ...
"* Les méthodes actuellement utilisés accusent des adresse ip d'imprimante "
C'est qu'il y a des gens qui pirate via leur imprimante.
Ouais, génial !!! Je sus pas sur des supports DVD donc j'ai décidé de télécharger l'intégrale de Lorie et de l'imprimer, et pour l'écouter, je scanne les feuilles une à une pour entendre le morceau (mais faut que j'aille vite sinon le morceau est un peu saccadé).
Pareil pour les films, l'intégrale de StarWars me prend par contre 3 pièces de mon appartement, et la faut qu'on s'y mette à plusieurs pour scanner les feulles ...
[^] # Re: *LE* dictionnaire ?
Posté par totof2000 . En réponse au journal Les vierges effarouchées du langage. Évalué à 1.
ben pourqoui se relire, il y a les correcteures dortaugraffe. D'ailleur il en fodré un ossi sur linuxfr ...
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
Je m'exprime mal : disons que je ne leur demande pas d'écrire un roman .....
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
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.
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.
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.
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
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.
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. Après si quelqu'un veut vendre ses bibliothèques, il a intéret à bien écrire sa doc .... Après je t'accorde que payer n'est pas en soi une garantie d'avoir une documentation de qualité, mais souvent ça aide (tout dépend aussi à qui tu t'adresses, mais c'est un autre pb).
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord. La réponse que tu as apporté ne le laissait pas paraitre ....
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.
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).
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.
C'est ce que j'ai fait .... et ça s'est plutot bien passé (je ne reviendrai plus au PHP).
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.
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...).
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.
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).
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é ....
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).
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 .... Et tu remarqueras que pour ma part je ne parlais pas de Rails mais que j'étais dans une optique plus globale.
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 C'était un exemple ..... ne prends pas mes propos au pied de la lettre. Que ce soit UML ou autre chose, ce n'est pas le plus important. JE parle d'UML parce que ç'est un ensemble d'outils normalisés et qui restent assez clair et "universel". Cela dit si chacun utilise sa propre convension, comment veux-tu ensuite regrouper tout ça dans un ensemble cohérent (ce qui était l'objet du fil initial) ...
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.
2/ Sinon, encore de la dispersion :
- Readme
- code source
- wiki projet
- les forums
- les FAQ
- un bouquin qui fait la glue avec ça ...
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.
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 ....
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.
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 ....
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
Non, je raisonne en terme de doc à jour et utilisable par quelqu'un qui ne connait pas forcément le projet, par rapport à la version livrée.
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
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 ....
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.
On est pas obliger d'expliciter tous les cas possible. Cependant ce qui pour moi constitue un bon exemple de documentation bien faite (mais pas parfaite) c'est par exemple la documentation de VBA dans Excel.
Tu as une aide et une explication sur les fonctions, les paramètres qu'elles prennent ainsi qu'un exemple d'utilisation. Tu n'as pas un exemple sur tous les cas d'utilisation, mais suffisamment pour comprendre comment ça marche.
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
C'est vrai mais ce n'est pas la seule raison : voir plus haut.
Je vais prendre un autre exemple Ruby : Rails. La doc de base est extrêmement bien faite
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.
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.
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 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) ...
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 4.
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
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 ....
Tout rejeter sur le dos des développeurs, c'est facile mais contre-productif
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.
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.
L'idée de faire de la documentation partagée me semble beaucoup plus efficace, et encourage, si tu ne trouve pas ce que tu cherches sur la doc partagée officielle, à l'ajouter quand tu le trouves ailleurs pour que tout le monde en profite.
D'accord avec toi, cependant les développeurs doivent en faire un minimum. Et la il s'agit plus d'adopter des conventions et des normes communes dans un développement, qui pourront être utilisés par des outils tiers pour centraliser cette doc. Il faut aussi en cas de besoin avoir un chemin inverse : reporter les modifications de la doc "en ligne" par exemple vers le code source .... un peu ambitieux mais pourquoi pas ?
Juste une queston : as-tu déjà essayé de documenter un projet que tu ne connais pas, rien qu'à partir du code source ? Moi, oui, et le temps de documenter ce que tu as compris, c'est obsolète car une ou deux autres versions du projet sont sorties et tout est à refaire.
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
Regarde un peu la vitesse à laquelle tout bouge dans le LL ....
Il faut que la doc soit faite en même temps par les développeurs ou elle aura 3 versions de retard.
[^] # Re: et ..
Posté par totof2000 . En réponse à la dépêche Un synthétiseur de voix enfreint-il les droits liés au texte lu ?. Évalué à 2.
Ca ne tient pas pour les anciens films ....
Maintenant je ne pense pas que la caméra ait un impact aussi important, rapporté au budget global et au nombre de films vendu ...
Enfin je pense que les caméras n'ont pas attendu que le HD soit disponible pour le grand public pour s'équiper en matériel HD. ...
# Si tu précisais ce que tu veux mesurer ......
Posté par totof2000 . En réponse au message Monitorer les ressource systèmes. Évalué à 2.
Parce que la j'ai l'impression qu'on sort la grosse artillerie pour pas grand chose.
Un outil ressemblant au Glance d'HP-UX ca n'existe pas sous linux ?
[^] # Re: NAT
Posté par totof2000 . En réponse au message Bricolage d'adresses. Évalué à 3.
nat on $ext_if from 192.168.1.0/24 to any -> 192.168.50.0/24 bitmask
Je me disais aussi, une syntaxe aussi claire ça peut pas être un firewall Linux ....
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
Parce que , et je le déplore, la grande majorité des développeurs du libre s'imaginent que le code source suffit et est amplement suffisant.
Parce que la majorité des développeurs du libre en ont rien à faire des gens qui ne veulent ou ne peuvent passer des heures à lire des lignes de code source pour récupérer une info sur une ou deux classes.
Parce que beaucoup de développeurs, même dans le libre, développent "à l'arrache", codent "à la volée" sans avoir écrt une analyse préalable ..... ou alors ne partagent pas cette analyse.
Je déplore cette attitude. Pour moi la documentation devrait être faite avant de coder.
# je n'aurai pas de mal ....
Posté par totof2000 . En réponse au journal boycotter les industries de la musique et du cinéma ?. Évalué à 2.
En près de 10 ans je ne pense pas avoir acheté 1 album par an ..... Pas seulement à cause des DRM mais surtout parce que rien ne me plait ....
Côté cinéma c'est pareil, quoi que c'est un peu plus compliqué (fille de 6 ans qui aime regarder certains films).
[^] # Re: Une réponse à ta question
Posté par totof2000 . En réponse au journal Franck Riester : "L’interopérabilité n’est pas nécessaire pour les consommateurs". Évalué à 2.
[^] # Re: Explications?
Posté par totof2000 . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
T'as de la chance .... Je bosse en ce moment dans une grosse structure ou c'est la croix et la bannière pour installer des serveurs ( a juste titre : les datacenters sont full, tant au niveau consommation électrique que l'emplacement au sol).
tu peux faire tourner plusieurs applis sur 1 seul serveur et tu n'es pas obligé d'acheter que des bêtes de courses.
Tu n'a pas la même isolation, ni même la même finesse de répartition de ressources que sur des VM.
La virtualisation n'a rien à voir la dedans, les serveurs ont tous une console d'administration à distance.
Bien sur que si ....
1 serveur physique = 1 connection d'administration/serveur = 1 cable = 1 port de switch, etc ....
N serveurs virtuels = 1 ip d'administration = 1 cable, = 1 port de switch ...
[^] # Re: Explications?
Posté par totof2000 . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Si ca existe je serais curieux de les connaitre.
[^] # Re: Explications?
Posté par totof2000 . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
s/mauvaise foi/mauvaise explication/
voir mon message plus haut.
[^] # Re: Explications?
Posté par totof2000 . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Moua ha ha ha ha ha !!!!
Excuse-moi, ce n'est pas pour toi mais .... Si tu savais commment se passent les tests de perfs dans la majorité des boites .... quad ils sont faits.
[^] # Re: Explications?
Posté par totof2000 . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Je me suis mal exprimé, parce que je suis en ce moment dans une boite qui a non pas une application mais des tas d'applis qui marchent de cette façon.
En gros tu as 4 ou 5 blades qui peuvent héberger les frontaux web de plusieurs applis différentes, .... mais effectivement je me suis mal exprimé.
[^] # Re: et ..
Posté par totof2000 . En réponse à la dépêche Un synthétiseur de voix enfreint-il les droits liés au texte lu ?. Évalué à 2.
tiens curieux, en lisant ça je n'ai pu m'empêcher de faire une analogie avec le mode de facturation de certains logiciels (tarif au CPU, au type de serveur, à la quantité de RAM présente, txc ...).
Sinon ce principe existe déjà : un film sur support HD est facturé plus cher que sur DVD ..... parce que potentiellement tu peux le regarder sur un matériel quui te donne une meilleur qualité. Mais ça n'a rien couté de plus (ou si peu) à produire: ce n'est que de la copie.
[^] # Re: C'est un poil exagéré
Posté par totof2000 . En réponse à la dépêche Un synthétiseur de voix enfreint-il les droits liés au texte lu ?. Évalué à 2.
[^] # Re: Ils n'ont pas compris ?
Posté par totof2000 . En réponse à la dépêche Un synthétiseur de voix enfreint-il les droits liés au texte lu ?. Évalué à 1.
C'est là que ton raisonnement cloche : une émotion n'est pas un automatisme ....
Sinon je suis d'accord avec toi que les synthèses vocales ont fortement progressé, mais dans le contexte de la dépèche, il sera impossible - et ça j'en suis convaincu - de créer une synthèse vocalae capable de restituer une oeuvre écrite avec les émotions adaptées, sans qu'un travail d'adaptation humain ne passe derrière ...
[^] # Re: Mouais..
Posté par totof2000 . En réponse au journal Pour l'ouverture d'une enquête parlementaire contre Christine Albanel !. Évalué à 6.
"* Les méthodes actuellement utilisés accusent des adresse ip d'imprimante "
C'est qu'il y a des gens qui pirate via leur imprimante.
Ouais, génial !!! Je sus pas sur des supports DVD donc j'ai décidé de télécharger l'intégrale de Lorie et de l'imprimer, et pour l'écouter, je scanne les feuilles une à une pour entendre le morceau (mais faut que j'aille vite sinon le morceau est un peu saccadé).
Pareil pour les films, l'intégrale de StarWars me prend par contre 3 pièces de mon appartement, et la faut qu'on s'y mette à plusieurs pour scanner les feulles ...
Merci de m'avoir fait autant rigoler ....