[Résolu] Ajax limité ou bug ?

[Allwise]

En fait pour reprendre une expression, l'optimisation est un "problème de riche". En général, quand on optimise son code c'est parce qu'il y a un besoin réel derrière. Si tu connais la montée en charge que tu auras par avance pourquoi pas. Mais si tu anticipes une montée en charge dont tu ne sais rien parce qu'elle n'existe pas, ce qui est manifestement le cas car ton jeu n'est pas en ligne, je pense que tu pars dans la mauvaise direction. Tu vas t'imposer des contraintes, te compliquer la tâche, et perdre du temps pour un problème qui, au final, n'existe pas ou pas encore. Les optimisations sont souvent synonymes de concessions, de prises de tête... Mieux vaut utiliser son temps pour avancer le carrosse, que pour lui mettre un super méga turbo qui tue mais qui ne servira peut-être jamais.
Ce que je dis là se vérifie dans le monde professionnel car il y a toujours le facteur temps qui joue inlassablement contre nous. Peut-être que dans un projet perso où on est maître de son temps et de son projet c'est différent...

Faire un model quand on sait que dans quelques mois faudra passer a un autre est une perte de temps.

Là encore je suis pas trop d'accord... A chaque problème sa solution. Si on vise toujours le mieux on ne fait rien parce qu'il n'y a plus de limite. Quand tu vas lancer ton jeu, tu commenceras peut-être sur un mutualisé. Et peut-être qu'un jour, pour X raisons, tu prendras un dédié. Peut-être que si ton jeu marche bien tu étofferas le background, tu rajouteras des classes, des maps ou je ne sais pas trop quoi. Mais si tu vises un truc ultra complet et ultra bien tu repousseras sans cesse tes objectifs et ton jeu ne sortira jamais.
==> CF la sortie de Duke Nukem for Ever =)

[guile]

J'ai une expression pour résumer ça : chercher à construire une cathédrale.
Certains vont penser à installer une église dans le quartier. Ca prendra 6 mois, elle sera en bois, accueillera 10 fidèles, mais elle sera là.
D'autres vont vouloir construire une cathédrale. Ca va prendre 80 ans, on va faire des travaux de malade et, qui sait, peut être ne pourrons-nous pas la terminer (guerre? épidémie? approvisionnement KO?).
A chacun son point de vue évidemment, et je sais que Argorate n'est pas d'accord avec l'idée de sortir un truc rapidement.

En fait, je sais ça, car il m'avait demandé pourquoi MOI, j'avais sorti mon jeu si rapidement, alors qu'il n'a rien d'extraordinaire, il lui manque plein de choses, etc. Lui, de son côté, souhaite sortir quelque chose de grandiose, et il y a bosse bcp bcp...

Je n'ai vraiment pas envie de revenir sur ce débat, là où je sais que nous aurons tous les deux raisons, et où l'un des deux va vite s'emporter sur des propos incorrects (je pense à moi là).

Je vais citer un ami et une anecdote professionnelle : un développeur aux qualités certaines, avait mis à un endroit

Code :

if (valeur > MEGA_MAX_VALEUR)     // aucun risque qu'on arrive un jour à cette valeur!
    CATCH 'error xxx'

Je vais être idiot, et prendre le point de vue extrême d'Argorate : "mouai, un test qui sert à rien! Bouh l'optim! Caca! Un IF c'est deux instructions processeurs! MOCHE le code ! MOCHE! BOUUUH!". En plus, on était dans de l'embarqué pas super performant (les processeurs à l'époque n'était pas formidables). Roh lala qu'il a raison Argorate!
Ce pauvre testeur avait juste mis ce test pour éviter un dépassement critique pour la machine...

3 ans plus tard, ils sont tombés pour la première fois sur la fameuse 'error xxx', le développeur n'était plus là, et ils étaient tous bien content de tomber facilement sur le bout de code en question...

Autre exemple : à mon boulot, on ne m'a jamais dit quoique ce soit lorsque je mettais un IF quasi inutile car le test effectué était prérequis autre part, mais qui assurait derrière "Au cas où" ... oui, le fameux "au cas où... on se met à changer le bout de code qui faisait tous les prérequis, et que derrière on se retrouve avec une merde insondée".

Tout ça pour dire que si des professionnels disent que les tests et les contrôles SONT importants, c'est ptet qu'ils le sont?

Chercher de la performance au niveau du "flop" est vraiment naïf au début d'un projet. Ca démontre la maigre expérience du jeune étudiant pas encore dépucelé au boulot par un boss un peu rugueux, qui se rappelle d'une appli qui prenait des plombes à cause de IF mal foutus, sans qu'il ait pu comprendre que c'était son code qu'était foireux... Quand on commence à avoir une expérience sur les projets professionnel, on sait déjà éviter ces bêtises de débutant, et on sait surtout l'importance de certaines choses comme les tests.

Argorate? j'avais vu que tu galérais un max avec les div, les background-position, etc. Mais ce sont des problématiques CSS. Or CSS3 va arriver un jour où l'autre, ça sert à rien de faire tout ce que tu fais, tu perds ton temps, passe en CSS3!
Et puis, commence à bosser pour être compatible PHP6.
Ah oui, et puis ton jeu va démolir tout ce qu'il y a autour. Faudra penser à faire du load-balancing, c'est sûr! Faudra y passer! Tu devrais aussi le gérer... Et ton serveur de données, j'espère que c'est pas MySQL... car avec les millions de personnes qui viendront (celles qui t'ont poussé à supprimer 4 flops par page => 4 mégaflops / secondes de gagné!), bin faudra passer à Oracle 10g, avec proédure stockées, et tout ça.

Guile, de plus en plus navré

[Argorate]

La seul chose que je peux te dire, c'est que je suis content que tu m'ai dit ton avis.
Je suis plutot a l'opposé de ce mode de pensé.

On fait les choses bien ou on ne les fait pas.

Sur ce, je pense qu'on a fait le tour du sujet

Merci.

EDIT: dsl guile pas le temps pour des post non constructif.

[Sephi-Chan]

En fait on dérive beaucoup. Même si je ne suis pas souvent d'accord avec Argorate (du fait de solutions pas industryproof), je dois reconnaître que là, on cherche beaucoup à lui faire changer de technique côté serveur, alors que son problème ne vient pas de là mais d'un croise de 2 requêtes Ajax (dont on obtient donc 2 fois l'effet).

Du coup, la solution la plus simple pour ne rien avoir à toucher côté serveur, c'est d'utiliser un callback côté client : on effectue le déplacement une fois qu'on a reçu la réponse du serveur. Regarde du côté des librairies (je te conseille d'utiliser une librairie comme jQuery : tu n'auras pas à réinventer une roue moins ronde et ce sera beaucoup plus fiable que tout ce que tu pourras faire) et leur événement onsuccess.

• jQuery - Ajax
  
• Prototype - Ajax
  
• ...
  

Sephi-Chan

[naholyr]

Nan mais j'insiste, il suffit juste de faire une requête "synchrone", pas besoin de sortir des libs & cie, l'objet XmlHttpRequest prend un paramètre booléen pour ça, il suffit de le changer (passer true en false pour régler tes problèmes, question rapport gain/coût tu trouveras pas mieux ^^).

[Ter Rowan]

Nan mais j'insiste, il suffit juste de faire une requête "synchrone", pas besoin de sortir des libs & cie, l'objet XmlHttpRequest prend un paramètre booléen pour ça, il suffit de le changer (passer true en false pour régler tes problèmes, question rapport gain/coût tu trouveras pas mieux ^^).

pas d'accord avec toi naholyr

en effet si tu fais une requete synchrone, alors tu ne peux plus rien faire d'autres tant que la requete n'est pas terminée or l'intérêt d'ajax à mon sens c'est aussi de pouvoir demander d'autre chose pendant une requête

la le problème est : il ne faut pas lancer deux fois en // une requête de mouvement, mais si d'aventure ajax servait à autre chose (vérifier toutes les x sec la messagerie, afficher au joueur des infos diverses lors du passage de souris, etc...) ta synchronisation gèlerait toutes les fonctionnalités, pas seulement le mouvement (enfin si je me gourre pas)

[Anthor]

C'est pas comme si je vous avait filé la modif une page derrière, 2 lignes à changer, c'est dur

Au lieu de vous toucher l'an** sur vos optimisations de IF à deux balles vous avez pas des trucs à dev ?

L'optimisation ça ne se fait pas sur du IF, ça se fait sur l'OP Code, les caches SQL et autres...

[Sephi-Chan]

C'est pas comme si je vous avait filé la modif une page derrière, 2 lignes à changer, c'est dur

Au lieu de vous toucher l'an** sur vos optimisations de IF à deux balles vous avez pas des trucs à dev ?

L'optimisation ça ne se fait pas sur du IF, ça se fait sur l'OP Code, les caches SQL et autres...

Gros +1.

On s'en fout des simple quote, double quote. L'essentiel c'est d'aller au plus lisible en ce qui concerne la syntaxe et le style. L'optimisation, c'est pas ça. :p


Sephi-Chan

[Argorate]

C'est pour ça que j'arrete le pseudo débat là.

Comme je l'ai dit j'ai comprit le problème avant de poster suite au observation que j'avais faite du problème (pas assez rapide pour rafrech correctement) et je remercie qu'on m'ai donné la solution que je ne connaissais pas a savoir les callback...

Sur ce, sujet clos pour moi