Salut, est-ce que faire la doc de l'API des stats est envisageable si je n'ai pas participé ? Ou c'est trop complexe ?
Je ne dis pas que je vais le faire, mais si j'ai le temps, ça fait partie des seules tâches que je peux faire pour l'instant 
Si tu n'as pas participé tu peux quand même faire la doc sans problème. Ceci dit il faudra peut-être que tu installe une instance de zds chez toi pour pouvoir documenter ça en bonne et du forme.
Je ferais un coucou ici quand j'aurai poussé la branche sur mon dépôt. Tu pourras donc la forker pour documenter si tu veux.
Ça serait vraiment cool que tu nous envois une branche. Si on a des remarques, qu'on puisse te les faire avant la fin du dev. OSEF de la qualité du code pour l'instant. Pour moi, l'important c'est l'architecture, on sait tous, combien c'est chiant de modifier, l'archi quand le projet est presque finis.
De plus, c'est toujours plus motivant de bosser à plusieurs et puis il t'arrive quelque chose (rencontre avec un Grosminet ^^), pour une raison X ou Y, qu'on puisse au moins repartir de ce que tu as fait.
En effet, j'ai oublié de signaler ici quand je l'ai poussé sur github. Le code actuel de la zep se trouve sur cette branche.
Je profite donc pour faire un état des lieux.
Pour l'instant, ce n'est pas encore documenté et l'essentiel des apports se trouve dans le module stats.
Actuellement il est possible, après avoir crée du contenu (tutoriel, article, … voir la doc de création de fixtures auto) de générer un fichier de logs automatique (très utile pour les tests) à coup de :
python manage.py generate_logs lines=1000 path==/chemin/vers/mon-fichier.log
Et ensuite de parser et stocker le contenu de la log avec :
python manage.py parse_logs /chemin/vers/mon-fichier.log.
Après le résultat on le retrouve dans les urls de l'API. Actuellement les urls suivantes sont quasi-fonctionnelles.
api/stats/contenus/chapitre/visitesapi/stats/contenus/partie/visitesapi/stats/contenus/tutoriel/visitesapi/stats/contenus/article/visitesapi/stats/contenus/chapitre/<id_chapitre>/visitesapi/stats/contenus/partie/<id_partie>/visitesapi/stats/contenus/tutoriel/<id_tutoriel>/visitesapi/stats/contenus/article/<id_article>/visitesça avance peu à peu (très lentement ces dernieres semaines) et tout le monde est invité à filer un coup de patte à tout moment. Que ce soit pour la doc, pour le code, pour tester, etc.
Ok, je suis désolé, j'avais pas vu la branche, c'est déja bien avancé. Je peux personnellement pas te filer un coup de main en ce moment mais si j'ai cinq minutes avec plaisir !
J'ai rien vu qui me choque, personnellement. Tu nous dit quand tu pense avoir suffisamment avancé pour qu'on puisse évaluer la volumétrie de façon concrète ?
Ok, je suis désolé, j'avais pas vu la branche
J'avoue elle était cachée au milieu de mes 127 branches (oui j'en avais pas mal). J'ai fais un nettoyage pour y voir plus clair.
Tu nous dit quand tu pense avoir suffisamment avancé pour qu'on puisse évaluer la volumétrie de façon concrète ?
Normalement avec mes deux commandes, je pourrais facilement boucler dessus pour simuler 1 an de logs, puis en lançant le parsing des 365 fichiers de logs, j'aurai tout simplement une estimation de la volumétrie par an. Donc ouaip, ce genre de résultat arrivera. On peut même déjà les faire aujourd'hui.
Il est un peu tard mais j'ai une question/suggestion. Etant tombé par hasard sur ce module python, qui n'a fondamentalement rien de particulier, je me suis demandé si effectivement l'évaluation des stats en lignes ne serait pas une bonne idée.
On sait qu'on ne peut pas stocker toutes les valeurs fournit par google pour faire des moyennes et variances précises. Cela ferait trop de données. Pour autant il existe de nombreuses méthodes (certaines implémentés dans ce module) qui permettent d'évaluer des estimation relativement précise des données statistique sans avoir besoin de mémoriser des valeurs.
Typiquement ne pourrait t'on pas gagner en stockage en ne stockant que l’historique d'évolution de moyennes glissantes ?
Si vous suivez ce topic, vous avez certainement remarqué que toutes les jauges du premier post sont passées au vert.
Ce qui signifie que la PR de la ZEP est officiellement ouverte sur le dépôt. Si on est suffisament nombreux à croiser nos doigts de pied, il y a moyen que ça arrive en prod pour la v21, sinon ça sera en v22.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte