Forum CMS Made Simple FR

J'en suis pas peu fier de celle là, je tiens donc à vous présenter la prochaine version de mon module DownCnt 2.3.0 avec la génération des statistiques



encore en cours de développement, je suis preneur de tous les retours

http://www.furie.be/news/20/15/Preview-d...2-3-0.html

Et avec des graphiques
Je vais le tester sur les plugins que j'ai sur mon site.

Il n'est pas encore disponible pour test ?

nop, c'est une préview :]

Attend fin de semaine prochaine

là je suis en train de m'exciter tout seul devant mes graphs ^^ bon faut que j'arrête un peu et que je rentre chez moi ...

C'est le pied le développement, hein :p
Qu'est-ce que tu te dis en regardant ton oeuvre ? Ouais, je suis une bête

avec plus de modestie .. ouais c'est un truc du genre

Je prévois également la possibilité dans les versions supérieurs de générer un code HTML à copier/coller pour avoir le graphique à l'exterieur du panel admin si besoin : pratique pour montrer aux collègues ou aux visiteurs les stats de téléchargement de vos logiciels sur votre site.

plutôt que de faire un copier/coller, si tu faisais une option pour voir la vue sur le front-end?

je ne sais pas trop, ca signifie faire un {DownCnt} avec 36 options au fesses, illisible.

L'autre solution est de faire un bouton enregistrer, une sorte de favoris en somme, qui puisse être appelé simplement depuis le front sous la forme {DownCnt stat='35'} mais là encore se pose des questions, par exemple le shéma (35) sera forcement figé dans les dates, il n'évoluera pas au fil des jours...

tu vas me dire, l'export HTML c'est pareil ^^

donc comme je le disais sur mon site, je n'ai pas d'avis arrêté sur le sujet, si on me persuade de l'utilité d'une fonctionnalité je le ferrais (dans la mesure du possible hein, ..)

Par email jce me proposais une purge des stats mois par mois. Ca signifie l'impossibilité de refaire des stats graphique évidement mais si besoin je peux prévoir cela.

J'attends avec impatience la version à venir. Comme j'ai eu l'occasion de te le dire par mail, pour moi les versions antérieures du module ( que tu as repris) étaient difficiles à mettre en place sauf admin expérimenté. Du coup, je trouve que la solution que tu étudies me semble bonne, à savoir pouvoir créer le lien en back-end et pouvoir le copier en front ensuite. Ce module me semble particulièrement intéressant pour étudier les interactions entre le cms et les actions des visiteurs. Bon courage pour la suite, je suis prêt à tester et faire des retours.

Citation :Par email jce me proposais une purge des stats mois par mois. Ca signifie l'impossibilité de refaire des stats graphique évidement mais si besoin je peux prévoir cela.

peut être me suis-je mal exprimé mais ma demande est de pourvoir supprimer un ou plusieurs mois sur le paquet d'enregistrements
par exemple j'ai actuellement : 6 mois d'enregistrements, au 31 aout je fais mon graphique, je le stocke ou copie ou ..., et je supprime les 5ou6 mois précédents.
cela permet d'avoir les stats pour 6 mois
puis de repartir sur une autre base de six mois et de ne avoir une BD obèse
Autre exemple je fais les stats tous les mois et les stocke ou..., j'efface le mois précdement

D'accord avec jce, sinon la base de données va pas tenir le choc.

C'est techniquement plus complexe en réalité.

Les graphes vont reposer à terme sur plusieurs axes

nombre de clic par user-agent ou par name de compteur ?
sur un cycle de 24H ? sur un cycle de 7 jours ? sur x jours ? semaines ? mois ? année ?

Soit 2 * 6 = 12 possibilités de compilation de donnée complètement différente.

Alors la solution rapide serait de pré-macher ces douzes versions, de le mettre en cache d'une manière ou d'une autre et ensuite de vider à la demande la bdd mais comment gérer le fait potentiel que dans 3 semaines après la purge on me demande un nouveau type de graphe ? c'est con de perdre nos sources non ?

edit : je viens de penser à pire : on peut regrouper ses compteurs par tag, et faire des graphes par tag. Or, faire un graphe pour un tag donné alors que dans le même temps on peut changer la liste des compteurs de ce tag, ca fausse complètement le jeu... la précompilation NE PEUT PAS fonctionner

edit 2 : en fait si, ça pourrait fonctionner mais tant que je ne pré-compile que les données au niveaux des name de compteur, laissant php faire le recalcul par Tag à chaque chargement de page et ne pas précompiler cette partie.

Vous me parlez de taille de bdd. Sur ce site, de nombreux liens sont cliqués comme vous pouvez l'imaginer, à commencer par les liens de téléchargement. Ainsi, depuis Avril (début des stats) j'ai un total de 17.450 clics enregistrés pour un poids de 1,9 Mio, c'est très très peu je trouve mais bon, je peux comprendre que la taille des bdd peut être gênant pour d'autre.

Alors que fait on ?

* Perdre les données sources me semble trop risqué
* Scinder les données dans deux tables (avec une nouvelle table stat_archives par exemple) ne règle pas le pb de poids, et on n'est pas face à un ralentissement de données causé par la taille de la bdd donc mauvaise piste.
* Archiver les données sous format fichier. Je penses que c'est la moins pire des solutions.

Peu de personnes de nos jours sont limités en terme de taille de disque (<100Mo) et cela libèrerait la base de donnée.

Par contre ce n'est pas sans effet de bord puisque la génération des graphes vont prendre un coup dans l'aile niveau performance si vous continuez à générer les graphes sur une période comprenant les fichiers archives ...

Donc seconde question : gère t on le cache ? De quelle manière ?


J'ai déjà réfléchit pas mal à la question et je penses déjà avoir un début de réponse.

La génération des graphes se fait par appel Ajax / Get sur une page spécialisée.

mapage.php?param1=...&param2=...&param3=...

De manière très simpliste il me suffit de faire un md5 sur l'array des paramètres afin d'être capable de stocker le résultat de smarty dans un fichier de cache et/ou le charger à la prochaine demande.

Cela sera extrêmement performant sur des graphes demandés répétitivement
Cela sera complètement inutile si vous jonglez sur les dates début/fin pour le fun car je serais incapable de réutiliser le cache précédemment généré.

Si vous avez d'autres idées, des réactions ou que vous pensez que je me suis planté dans le raisonnement prévenez

salut,
qu'est-ce que tu utilises comme lib pour les graphes?
J'ai utilisé jpgraph plusieurs fois et il a une bonne gestion interne de cache. Si le graphe existe déjà, il ne le refait pas. Ensuite, mettre en place une purge peut-être une option intéressante pour la bdd, sachant que les graphes sont toujours dans le cache.
On ne perd pas d'infos et on allège la bdd. Mais bon, c'est vrai qu'aujourd'hui, l'espace disque est de moins en moins un frein.

j'avais vu jpgraph mais je l'ai trouvé trop simpliste dans les résultats.

Là j'utilise Google Charts qui est une librairie JS . C'est totalement intégrée dans des templates smarty et ça permettrait à une Tiers personne de pondre ses propres graphes avec une autre librairie

Le fait d'être dans smarty permet également de profiter du cache smarty (non négligeable)

Pour la partie génération de la matrice, c'est du php classique évidement, ça me laisse toute la liberté pour manipuler les données, la bdd et dans le futur gérer plusieurs sources pour les données : bdd + fichier plats par exemple.

Qu'on soit d'accord : la gestion d'un cache interne à DownCnt doit elle être liée au cache cmsms ? Imaginez si un gus vide le cache cmsmadesimple, vos graphes doivent ils être perdus/à regénérer ? ou doivent ils être conservés ?

Un autre point évoqué en début de topic par toi justement :

Citation :plutôt que de faire un copier/coller, si tu faisais une option pour voir la vue sur le front-end?

Je vais faire comme dans Shootbox : un graphe aura une signature JS + une signature Smarty (via un alias) qui permette de l'afficher ET dans cmsmadesimple ET en dehors : sur votre blog, sur un forum, ...

Pour voir comment fonctionne le JS de Shootbox en dehors de son habitat normal qu'est cmsmadesimple : http://www.alpha-team.fr/bb

le code source à placer dans la page est :


mastoc je vous l'accord, mais terriblement efficace . Ce sera de toute façon moins conséquent pour afficher un diagramme.

bess a écrit :mastoc je vous l'accord, mais terriblement efficace

c'est une excellente solution et on pourra toujours faire un UDT pour l'afficher dans le front-end

ça avance plutôt bien. Pas de screen aujourd'hui mais l'essentiel des boutons utilisables pour générer les graphs sont prêts, y compris ceux pour les graphs par User-agent

Sont donc proposés : par roulement de 24H, roulement de 7 jours, Jour à Jour, par semaine, par mois, par an. Très instructif pour la plupart

Les users-agent qui me font chier. Je ne sais pas trop par quel bout les prendre. Notamment les innombrables bots qui devraient être laissé séparés ou regroupé sous l’appellation bot pour plus de lisibilité (question ouverte, besoin de réponse ?) ainsi que les innombrable variation de navigateur. Je les regroupe par quoi ? marque / version / plateforme / ... il y a tellement de variante que les graphes sont illisibles ...

J'ai du limiter à 20 éléments simultanés dans les graphes pour conserver un semblant de cohérence

Autre difficulté : on affiche quoi ? les 19 premiers par ordre alphabétique ou les 19 premiers par ordre d'importance sur la durée sélectionnée (j'opterais logiquement pour la seconde option) Sachant que l'on peut tenter d'insérer dans la vingtième position "TOUS LES AUTRES" ou un truc de ce genre pour ne pas perdre les statistiques.

Autre difficulté : dois-je prévois une blacklist/option lambda pour exclure des graphs tous les clics ayant pour provenance un user-agent non-identifiable, null, ou = à un bot ? ça me semble TRÈS conséquent en terme de volumétrie (80% ?)

c'est un module de stats ou un compteur de téléchargement?
Perso, je ne le connais pas, mais j'étais justement en train de réfléchir à ça pour un de mes sites, et le user-agent et tout le reste n'est pas intéressant. La chose à laquelle je n'avais pas pensé, c'est juste viré les bots dans les compteurs.
Alors, je pense que tu ne devrais pas t'em....er avec ça!

donc en substance toi tu préconises de virer les stats par user-agent et de laisser uniquement la possibilité d'exclure des stats certains user-agent ? (whitelist, regex ou toute autre solution)

Je suis d'accord sur ton raisonnement.

D'autres avis ?

C'est un compteur de téléchargement
donc pour moi voir les informations nb téléchargement (par tag) avec des stats par semaine et mois voir par x mois me suffit

ok second avis dans le sens de jissey donc.

Je prendrais bien celui de siohan s'il passe dans le coin :]

Bien avancé ce midi sur de nouvelles options.



Tout d'abord le menu gauche atteint son état quasi-définitif. Toutes les options de la 2.3.0 sont présentes


Des nouvelles options permettent par exemple d'avoir un cumul sur les jours de la semaine pour constater quels jours les clics se font le plus (moi j'ai trouvé ça très instructif concernant les éditions des news sur cmsms par exemple)

Une option , ici "Not End Date" permet de ne pas envoyer de date de fin au moteur, ainsi il prendra toujours la date système pour la génération. L'avantage est qu'avec un tel paramètre (no_end) dans l'url appelé depuis Ajax à l'extérieur de cmsmadesimple, votre graph restera toujours à jour et évoluera au fur et à mesure des clics (pratique pour l'incorporer dans un module Tiers avec FEU

Le bon vieux Camembert est effectif, tout comme le chart classique "Line" qui n'est ni plus ni moins le Area sans le cumul de valeur?

Tout le code relatif à des graphes sur les user-agent sont en commentaires pour l'instant, prêt à être retiré.

Ce que je compte terminer avant de livrer une version béta :

* coder "Exclude bot" qui tentera de virer des résultats tout ce qui provient pas d'un navigateur digne de ce nom
* limiter proprement le nombre de comparatif simultané à 19 + 1 qui s’appellera "Autre" ou "Divers" et cumulera les données des plus petits segments d'un graph.
* proposer un inputtext contenant le code Ajax prêt à l'emploi dans n'importe quelle page internet, que ce soit sous cmsmadesimple ou ailleurs (problème d'ajax crossover mis à part )

Et nous voici donc avec la sortie de la béta privée

Seul l'exclusion des bots n'est pas encore codé et reste sur ma todo-list. Toutes les autres fonctionnalités prévu pour la 2.3.0 sont réalisées.

J'envoie par email le module à ceux qui seront intéressés

Je vous souhaite bon test et bon plaisir devant les graphs

la prochaine version 2.4.0 devrait donc embarquer

* exclusion des bots
* gestion du cache

Je te réclamerai la prochaine version.là,j ai peur de mettr du sable sur mon clavier

tu rentres de plage ?

Oui, la 3g n est pas terrible!
Je rentre en fin de mois