Projet "documentation des tables"
Bonjour,

N'ayant rien à me mettre sous la dent depuis quelques temps, je me suis réveillé ce matin avec une idée qui va nécessiter la participation de chacun, un vrai travail collaboratif pour l'ensemble de la communauté de l'émulation française !

Sur un précédent sujet, je m'étais plain du fait que la structure des tables de Trinity n'était pas suffisamment documentée, se qui freinait considérablement mon apprentissage. Il y a bien le wiki officiel de Trinity que je trouve sympa mais il n'est pas à jour !

L'idée est de créer un genre de documentation (pour le moment j'ai pensé au format pdf, a voir selon vos idées). Mais comme je sais qu'il y a beaucoup beaucoup de tables à documenter, je pense qu'il serait bien que je réalise une interface web simple d'accès afin que chacun puisse contribuer à la documentation.

Je compléterai le document PDF au fur et à mesure des ajouts sur le site afin d'en publier des "release". Le projet sera plus ou moins long selon le nombre de personnes participantes !

Je pense m'attaquer à la dernière release de trinity : "TDB.335.53".

Voici mes questions :

- Selon vous, est ce un bon projet?
- Quels formats proposés? (pdf, web, ...)
- Pensez vous y participer? Pourquoi?
- Des idées supplémentaires?


Ce topic risque d'être édité en fonction des messages publiés en dessous, repassez souvent !
- Selon vous, est ce un bon projet?
Oui, il avait été brièvement abordé ici http://wow-emu.fr/showthread.php?tid=123. Ca peut à la fois apporter un outil essentiel aux membres et en même temps agrandir notre communauté. Si en plus le wiki de trinitycore.org est incomplet et pas à jour alors ce serait encore plus utile.

- Quels formats proposés? (pdf, web, ...)
Le web me semble le plus adéquat si il s'agit d'un projet collaboratif.

- Pensez vous y participer? Pourquoi?
Pourquoi pas ! Après je ne connais pas Trinity dans les détails donc ma contribution sera limitée Wink
Je pense qu'il s'agit d'un bon projet, mais qui risque d'être très long ! Pour le format, je pense qu'un simple Wiki suffirait et serait plus simple à la gestion. Est-ce que je pense y participer ? Eh bien, pourquoi pas. Wink Il faut également se prendre un mutualisé, certes cela ne coûte pas chère, mais sachant que certains gère un serveur, tout le monde ne peut pas aider financièrement.
Très bon projet dont je participerai volontiers, par contre j'aurai préféré que tu choisisses une DB 4.3.4 qu'une 3.3.5 car elle date un peu :/
Pour un projet collaboratif comme celui-ci, je penche aussi pour le support web Smile

C'est un projet auquel j'ai souvent pensé mais que je n'ai jamais commencé (faute de temps).
Mais si tu es motivé pour te lancer là dedans je peux y contribuer de plusieurs manières :
- Développement de l'interface web
- Hébergement (je dispose d'un serveur dédié chez OVH)
- Contributions au contenu

Pourquoi ? J'ai beaucoup travaillé sur la structure des bases de données de Trinity et MaNGOS par le passé (nWorldEditor) et je continue aujourd'hui (WoW Studio). Cependant je n'ai nulle part où partager les résultats de mes expériences, et je perdrai également moins de temps à ne pas rechercher ce qui a déjà été fait.

Si les membres du forum y participent, vu les compétences rassemblées, ça pourrait former une très bonne base de connaissance !
A propos de l'hébergement, WoW-Emu devrait aussi pouvoir vous fournir un espace web Wink
Je pense aussi que le wiki est un bon support et facile à mettre en place. Un truc similaire avait été mis en place sur Zone-Emu mais les thèmes abordés étaient surement trop importants.
Il y avait un projet similaire sir Mc-revolution sur les DBC (il me semble) je ne sais pas si il est toujours d'actu, mais si s'est le cas, réunir les deux projets pourrait être une bonne chose. Smile
Je suis d'accord avec Slowy, si le même projet à été fait pour les dbc par MC Révolution, rassembler les deux formerait un projet plus complet.
Personnellement, je suis pour l'idée, mais contre l'application. Il y a déjà un wiki de Trinity qui contient un tas d'informations, et les champs qui ne sont pas référencés sont compréhensibles en quoi ... 2 minutes ? Avec leur nom, le contexte dans lequel ils se trouvent (nom de table, nom des colonnes adjacentes etc) leur identification devient presque "bateau" (pour les tables SQL).

Et puis, je ne pense pas que ce soit servir les gens que de leur mâcher ce travail qui me permet par exemple de voir la motivation et le niveau d'un dev SQL qui veut dév avec moi (en gros, si le mec a pas la logique pour comprendre l'utilité de tel ou tel champ, c'est qu'il y a un souci pour la suite). Après, ça c'est purement personnel et évidemment ce n'est pas à généraliser.

Pour les DBCs, c'est un peu pareil. Les champs connus sont identifiés dans le client (structures). Les champs inconnus sont assez facilement identifiables une fois qu'on a l'habitude (mais ça prend du temps), et une fois de plus c'est le genre de travail que peu de monde souhaite rendre public tellement il est sensible (par exemple, les travaux de recherche sur les BattlePets).

Et enfin, dernier argument à ce sujet : la pérennité des données. Le gros problème là dedans, c'est que DBCs tout comme tables SQL changent d'une version à une autre (encore, les tables SQL ça reste similaire malgré quelques modifications) mais les DBC sont juste une horreur à ce sujet. Et je vous vois mal mettre à jour vos données à chaque update du client Wink (de la même façon que Trinity ne met pas à jour ses données à chaque update du serveur).
Je suis d'accord que le wiki de Trinity contient déjà beaucoup d'informations. Mais il y a parfois des interactions complexes entre différents champs, par exemple si tel flag est activé ici, tel autre flag là, et que la valeur dans ce champ est négative alors ça signifie cela MAIS si tel autre flag est activé alors la valeur doit être positive et elle signifie ceci ...

Les structures des tables sont en grande partie assez "sales" (j'ai fait des cours sur les Modèles Conceptuels de Données donc je sais de quoi je parle ^^)
Donc chaque éclaircissement est le bienvenu selon moi Smile

Après je comprends très bien la réticence à mettre à disposition du premier venu les résultats de recherches et d'expérimentations. Mais c'est selon moi la voie du progrès, les scientifiques qui ont marqué l'histoire sont ceux qui ont partagé leurs travaux, et c'est grâce à eux que d'autres scientifiques ont pu aboutir à d'autres résultats, etc, etc.

Si l'objectif du forum est d'éduquer les gens à apprendre par eux-mêmes alors je suis d'accord, ce n'est pas un projet approprié.
En revanche si l'objectif du forum est le progrès des connaissances et des outils de l'émulation, alors ça me semble être un projet qui va tout à fait dans cette voie ! Smile
Je suis tout à fait d'accord avec toi Nico. Une telle doc ne mâchera pas le travail, elle donnera seulement les outils nécessaires aux lecteurs pour travailler plus en profondeur.
Pour toi Nobodie ça ne te parait pas utile puisque tu travailles sur Trinity depuis pas mal de temps mais ce n'est pas le cas de tous le monde. S'il y avait que des Nobodie ici le forum ne servirait plus à rien Tongue
Pour ma part, je trouve que Nobodie a souligné les problèmes d'un tel projet et je rejoins complètement son avis. J'ajouterai également que mettre à jour un tel wiki sera quelque chose de particulièrement laborieux et surtout, pour ma part, ne l’enverrai jamais à un développeur en test pour la simple et bonne raison qu'il pourra fermer du jour au lendemain car il ne serai attaché à aucun autre projet. Je pense qu'il vaut mieux créer un tutoriel pour les champs légèrement complexes plutôt que de refaire ce qui existe, une grande habitude dans le monde de l'émulation française.
Citation :Les structures des tables sont en grande partie assez "sales" (j'ai fait des cours sur les Modèles Conceptuels de Données donc je sais de quoi je parle ^^)

Attention, la DB est effectivement très sale si tu pars d'une approche complétement relationnelle avec pour principe de respecter les formes normales (au moins les trois premières). Mais n'oublie pas que cette DB a pour objectif premier d'être utilisée dans un cadre bien précis et qu'il s'agit *normalement* d'un base de données statique donc pas modifiée "souvent". Et elle est tout à fait (bon, sauf quelques exceptions) bien exploitée pour le serveur. Si cette DB devait être faite de façon relationnelle, il faudrait multiplier par 15 le nombre de tables, au bas mot.

Citation :Après je comprends très bien la réticence à mettre à disposition du premier venu les résultats de recherches et d'expérimentations. Mais c'est selon moi la voie du progrès, les scientifiques qui ont marqué l'histoire sont ceux qui ont partagé leurs travaux, et c'est grâce à eux que d'autres scientifiques ont pu aboutir à d'autres résultats, etc, etc.

Je suis d'accord, mais nous sommes dans un monde un peu différent. Personnellement, je ne me donne pas pour objectif de rendre tout le monde ultra compétent. Certains ne le seront jamais, d'autres voudront mais ne le pourront pas, d'autres encore vont se prendre pour des génies en copiant et leechant le travail des autres. Moi, j'essaie d'abord de faire comprendre au gens ce que ça signifie que de monter et développer un projet de serveur, d'inviter les gens à être curieux et se poser des questions pour aller plus loin et comprendre un tas de choses, et acquérir ainsi une logique qu'ils utiliseront toute leur vie (en tout cas, moi elle me sert).

Citation :Si l'objectif du forum est d'éduquer les gens à apprendre par eux-mêmes alors je suis d'accord, ce n'est pas un projet approprié.
En revanche si l'objectif du forum est le progrès des connaissances et des outils de l'émulation, alors ça me semble être un projet qui va tout à fait dans cette voie !

Je pense que justement, l'objectif du forum n'est pas forcément le progrès des connaissances et des outils de l'émulation. Si c'était le cas, alors il y aurait un serveur opensource publique type Trinity, avec un serveur relié etc. L'objectif de ce forum est, selon moi, de partager ses connaissances, avoir un regroupement de développeurs en tous genres capables éventuellement de s'entraider sur certains points, de trouver peut être de futurs collaborateurs, et également, pour mon propre cas, de voir un peu comment cela évolue au sein de l'émulation française, de voir aussi la concurrence qui fait son apparition, etc (un peu de veille n'a jamais fait de mal à personne Wink).

Citation :Pour toi Nobodie ça ne te parait pas utile puisque tu travailles sur Trinity depuis pas mal de temps mais ce n'est pas le cas de tous le monde. S'il y avait que des Nobodie ici le forum ne servirait plus à rien

Attention, je n'ai jamais dit que ça ne me serait pas utile. Je dis que quand tu jettes du pain aux canards, ceux-ci doivent encore se déplacer pour aller le trouver et le manger. Pour comprendre un champ en DB, ça me parait extraordinairement plus simple que chacun aille voir ce qu'il en est et se casse un peu le trognon pour trouver comment ça fonctionne, plutôt que de galérer à tenter de maintenir un sujet qui est, selon moi, impossible à maintenir (trop de versions, trop de mises à jour, etc).
Même sans une approche "complétement relationnelle" y a un certain nombre de choses que je trouve pas propre mais dans l'ensemble je suis d'accord avec tes arguments Smile

Ce qui m'intéresse en particulier ce n'est pas de traduire le wiki déjà existant mais d'ajouter des compléments d'information. Mais bon, pour ça il y a déjà le forum, inutile de créer un projet parallèle ^^
Je trouve que c'est une bonne idée, mais il va falloir ce décider, un sujet à été ouvert il y a plus de 2 mois mais a part ça, on est toujours en train de donner notre avis, il serait temps de ce décider? Oui ou non?

Retourner en haut WoW-Emu