Silicon Valley

Le problème c'est pas le temps mais les nombreuses fois où ça a été repoussé. Volontairement ou pas t'as fait le même coup que jv.com avec les MP

Je comprends shumzy, pas simple, j'ai moi même créé un programme de scan des forums + stats y a quelques années, mais occupé par d'autres projets j'ai peu à peu abandonné le travail sur ce programme
Mais effectivement c'était un énorme taff. Rappatrier les messages était la partie la plus facile, calculer la première fois aussi, mais les mises à jour de stats, c'était une plaie.

Shumz >> je ne te dis pas etre un excellent codeur, je dis juste que ca se fait en un rien de temps ...

hop on scann un forum, on recupere chaque message de chaque page, si le pseudo deja present on l'incremente, on verifie son message on recupere ce qui nous interesse ( smiley, lien ect ... ) ainsi de suite et on se constitue sa bdd, ca va vite a coder stout, je vois sincerement pas ce qui peut te faire mettre des mois pour ca ( je vais du principe que tu sais coder [vue que ta fais jvflux]), meme si tu n'a pas de temps a cause d'autre chose, genre 2/3h dessus pendant une semaine grand max et c'est regler et encore tu code en PHP le PHP facile grandement tout ce qui est traitement de message par rapport au c++ donc bon ...

Autre exemple de problème pouvant survenir :
Tu scannes la première page d'un forum, mais le temps que tu l'aies scanné, il y a déjà eu cinq topics uppés, du coup tu passes à la page suivante mais tu rates cinq topics.
Et ainsi de suite de page en page sur de gros forums.

Bref ça c'est un "bête" problème durant une récupération.
Ensuite, y a le problème des threads, impensable en effet de s'amuser à récupérer topic par topic, c'est trop d'E/S donc trop lent, on fera du parrallèle, là encore si un thread se retrouve face à une exception, il faut pas que les autres threads en patissent, surtout s'il y a un résultat final qui dépend du travail de chacun.

Pourtant il s'agit de tâches simples, très simples, qui entrainent des problèmes complexes, qu'on peut corriger bien sûr mais après un certain temps. je ne parle même pas alors du calcul des stats à venir après, des cas particuliers de jv.com (des messages plus longs que la limite, des pseudos buggés, des pages avec plus que 20 messages, les topics de split à gérer, qui ont différents numéros pour un même topic malgré qu'il s'agisse du même pour jv.com )

Bref, pas mal de cas particuliers qui peuvent être emmerdants pour les stats, le calcul des mises à jour, etc.
Le moindre bug découvert remet en cause l'intégrité des stats précédentes et donc pousse la conscience du développeur à tout scanner et recalculer de nouveau, vérifier si les corrections n'entrainent pas d'autres bugs, sur de gros gros volumes de données. tout celà prend du temps.

Et ce n'est que la partie visible de l'iceberg.

Bonjour, all.

Je passe juste pour encourager les programmeurs qui travaillent sur ce projet car c'est quelque chose qui intéresse réellement les forumeurs.

Je me posais au passage quelques questions.
Y-a-t-il une quelconque collaboration avec Fremen, ou bien faites vous cela de façon séparée ? (Votre union vous apporterez quelque chose ?)
Comme Fremen, les MàJ seront régulières et faites par le site, ou bien y aura-t-il une participation des membres, un peu comme dans l'AJV ?

Merci de votre future réponse.

Silvermo a tout dit il me semble.

Kalikun => On fait ça de façon séparée, les mises à jour seront régulières et y aura à priori aucune participation des membres.

QUote=
Tu scannes la première page d'un forum, mais le temps que tu l'aies scanné, il y a déjà eu cinq topics uppés, du coup tu passes à la page suivante mais tu rates cinq topics.
Et ainsi de suite de page en page sur de gros forums.

ca c'est si tu veux faire des stats mise en temps reel, ce qui n'est pas le cas ici, juste obtenir un etat des lieux a une date fixe, et pour regler ce "probleme" il suffit de liste 2 fois la liste des topics alors, moi personnellement dans le porgramme que j'ai fais je liste d'abbord la liste des topics avant de commencer a les scanners ( obliger aussi si je veux avoir un % et une estimation du temps restant )

QUote =
Ensuite, y a le problème des threads, impensable en effet de s'amuser à récupérer topic par topic, c'est trop d'E/S donc trop lent, on fera du parrallèle, là encore si un thread se retrouve face à une exception, il faut pas que les autres threads en patissent, surtout s'il y a un résultat final qui dépend du travail de chacun.

je ne sais pas si il existe des execeptions en Php ni comment le multi thread est gerer dans ce langage mais en C++ (avec l'aide de QT en tout cas ) c'est assez aisee de lancer plusieurs processeur en meme temps sur des topics differents et gerer de facon tout a fait correctes les exceptions dont ils peuvent souffrir, pour ma part je scanne en parallele 10 topics et a chaque fois que l'un finis il lance le prochain de la liste ( a condition qu'il ne soit pas deja en cours ).

Quote=
Pourtant il s'agit de tâches simples, très simples, qui entrainent des problèmes complexes, qu'on peut corriger bien sûr mais après un certain temps. je ne parle même pas alors du calcul des stats à venir après, des cas particuliers de jv.com (des messages plus longs que la limite, des pseudos buggés, des pages avec plus que 20 messages, les topics de split à gérer, qui ont différents numéros pour un même topic malgré qu'il s'agisse du même pour jv.com )

pour le cas de jvc, suffit de partir du principe qu'il n'y a pas de limite pour la taille du message et du pseudo ( en effet pour les pseudos des annees 99/20 ), on recupere juste ce qu'il y a entre les balises correspondant au pseudo et au messages et on recherche les differentes occurences de ses balises dans la page jusqu'a la fin et c'est pas forcement le temps de calcul qui est long mais plutot le temps de recuperation des pages ( dependant donc de la connexion ) en outre pour faire les stats de ce forum ( la premiere fois ) la recuperation du forum en lui meme a mis quelques heures mais le calcul de ses stats une fois finis que quelques secondes.

donc oui je ne dis pas que c'est une tache "super" facile, mais franchement je dis que prendre autant de mois pour un projet pas si gros que ca, c'est trop ( meme en prenant compte des contraintes irl ),
lorsque j'ai finis mon jv_stats, c'est par respect pour le faite qu'un projet "communautaire" etait deja en cours que je me suis dis pas la peine d'en faire un enieme topic sur le sujet, les forumeurs attendent deja un qui ne devrait plus tarder et justement ca tardent ... ^^

Je crois que tu n'as pas compris le message.

Secundo, tes solutions sont valables mais ne couvrent pas tous les cas. Et sont sous performantes.

Rien que pour le parsing, si tu traites un petit message comme un gros, tu vas avoir des soucis de perf.
Si tu traites dix topics à la fois sur un gros forum, ça prendra plus de temps que sur un petit.
Et dix est bien trop peu performant, la limite doit dépendre du contexte.
Faire deux fois la liste des topics ne règle pas le problème, rien ne te garantit qu'au bout de deux passes, tout est récupéré.
De plus, il n'y a pas qu'une page de topics mais de nombreuses, la seule manière d'être sûr de récupérer est de se baser sur la date de dernier message d'un topic, ce qui nécessite souvent d'y entrer pour les plus récents.

Etc etc.
Pour un programme performante, il faut s'adapter au contexte.

Les langages de nos jours fournis des class suffisamment puissante pour s'adapter, considerer un message de 5000 char comme un message de 20 char n'a pas vraiment de difference au niveau de ton code, pour exemple la class string ( C++ ), un message d'un topic se trouve entre 2 base <li> </li> il suffit de recuperer ligne par ligne le contenu qu'il y a present dans ses 2 balises, tu as ton message, tu recupere les informations qui t'interesse dedans et tu libere la memoire, au final la vitesse d'execution ne changera quasiment pas (0,001...) donc y a vraiment aucune modification particuliere dans le code a faire lorsque tu traite un gros ou un petit message,

la je te parle de class suffisamment bonne pour gerer le probleme, maintenant si tu veux utiliser des buffeur classic louer sur la stack avec des valeurs par defaut il faudra simplement parcourir la chaine une premiere fois pour connaitre sa taille exacte et ensuite le recuperer et coter optimisation ca ne changera pratiquement rien avec le premier.

et comme je l'ai dis les stats ce n'est pas quelque chose fait en TEMPS REEL , c'est des stats a un moment T donc c'est normale que si pendant que tu fais les stats x nombres nouveaux topics sont creer il ne soit pas present, mais seront present a la prochaine maj ( qui ne prendra normalement pas plus de quelques minutes pour un gros forum [etant donner la bdd de la premiere] )

et pour recuperer tous les messages d'un topic, je ne vois pas en quoi il faut se baser sur le dernier message ( qui aussi peut changer ... , genre le topic fait 3000 pages, tu scann de 1 avant d'arriver a 3000, yaura certainement de new message donc si tu te base sur une date pour stopper net la recuperation ca va pas le faire ... ) il suffit de verifier qu'on est sur la derniere page ou non pour cela il suffit de simplement de verifier si dans le code source de la page recuperer on est :
<a class="p_suiv"
href="http://www.jeuxvideo.com/forums/1-numero...

ou
<a class="p_fin" href="http://www.jeuxvideo.com/forums/1-...

et tant que ce n'est pas le cas on peut incrementer de 1 le nombre de page et parcours la page suivante et recuperer les messages ainsi de suite.

et la on ne parle pas d'un projet en global mais bien d'un programme de stats de jvc, donc le contexte est deja fixer ici.

Tu n'as toujours pas compris ce que je disais, résultat tu t'y perds en blabla.

Tu me parles de capacités de language, je te parle de logique du code, de performances. Tu utilises des Regex non ? Tu crois sincèrement qu'une regex où tu ne spécifies pas le maxlength de certains champs sera plus peformante qu'une regex qui sait deviner plus rapidement ce qui ne matchera pas à l'avance ?
D'où l'importance de s'adapter au contexte. Moins tu en sais sur ce que tu parses, et plus ça peut prendre de temps en tests.

"et comme je l'ai dis les stats ce n'est pas quelque chose fait en TEMPS REEL"
Non mais au moment où tu lis une page de topics ou de messages d'un forum ou topic actif, rien n'est prédestiné à être figé, le temps que ton parseur lise, le contenu peut avoir changé.

Enfin, si tu acceptes que ton programme loupe des milliers de messages et présente donc de fausses stats, libre à toi. Pour ma part, un programme devrait récupérer tous les messages jusqu'à un moment T et faire les stats jusqu'à ce moment T, ce qui peut nécessiter de relire plusieurs fois les liste de topics. Pas seulement deux.

Bref arrête de vouloir faire bien en défendant ton implémentation, car tu sembles visiblement ne pas comprendre de quoi je parle.

Tu t'enfonces dans des exemples précis pour démontrer que tu n'as rien compris du tout à ce que j'ai dit. Bravo.

Et pour les stats des forums ?

Et dire que le 4 septembre je pensais que ça prendrais une semaine maximum...

Ca fait deux mois, c'est loin des 2 semaines...

J'ai aucune date non, maintenant j'en donne plus.

" De toutes manières, à quelques messages près, les stats seront correctes hein. "

faut compter en centaines de milliers de messages, voire plus hein

Autant garder les autres stats.

Où voir les stat's sérieux sa m'échappe

Effectivement, se mettre au C c'est pas évident, j'avais fait le programme en Java pour ma part, car bien que je connaisse le C et C++ , Java était mon langage de prédilection :p