S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité
Avatar de Virtual_Spirit INpactien
Virtual_Spirit Inscrit le mercredi 5 avril 06 - 96 commentaires -
Les derniers commentaires de Virtual_Spirit :
Son lancement sera donc beaucoup plus rapide car le code ne sera pas recompilé à chaque exécution. Du moins en théorie.


Dans la pratique, y'a quand même peu de chance qu'il n'y ai pas d'amélioration si ? (Même si elles ne sont pas perceptible)
Chez Free, le VDSL2 ne tient parfois qu'à un fil Le mercredi 30 avril 2014 à 11:35

Il faut se rendre dans le menu de la Freebox Server, puis dans ADSL > DSLAM et enfin regarder l'information correspondant à BDCM


Merci
Chez Free, le VDSL2 ne tient parfois qu'à un fil Le mercredi 30 avril 2014 à 11:12
Et comment on fait pour connaitre la version du DSLAM ?
Je suis pas sûr d'avoir bien compris. En gros si un visiteur tombe sur le site après une recherche google il est compté comme une source du moteur de recherche. Jusque là, c'est normal.

Mais si il revient sur le site dans les 30 jours (ou avant l'expiration du cookie) sans passé par le moteur de recherche mais en accès direct, il sera quand même compté comme provenant d'un moteur de recherche ?


Oulà.... je viens de retourner voir le site pris d'un gros doute. Il me semblait que le paramètre passé était une ressource et non une string (j'avais pas vu le mysql_query).

Ok, je raconte que de la merde. Désolé


Ahah pas grave ;)


Ca l'est ! Le count ça peut être utile avant, pas après.

La correction aurait du être "sinon on peut écrire $nbResultats = mysql_num_rows($query)"


mysql_num_rows() a besoin d'une ressource, retourné par mysql_query(), mais la fonction prend en paramètre une requête et pas une ressource.

Donc même problème que de refaire un count() il peut y avoir une différence si il y'a eu des résultats modifiés entre le moment où la première requête est faite et le moment ou celle avec count() est exécuté.

Si on ne cherche qu'à modifier la fonction sans toucher au reste du code, faire une regex qui remplace

SELECT * FROM ...

Par

SELECT COUNT(*) FROM ...

Est celle qui semble le moins gourmande.


Si c'est du code de garage le gars fait ce qu'il veut, du moment que ça marche (et son code, pour être très crade) fonctionne.



Dans l'absolue, même du code réalisé dans une grosse boite, peut importe si c'est crade, du moment que ça marche...


Pour le reste, rien. Mais rien n'interdit les bonnes pratiques, surtout dans le cas d'une "correction".


Un count() c'est forcement une mauvaise pratique ? Je ne pense pas.

Parfois un code dégueulasse peut se corriger en modifiant uniquement la fonction, parfois c'est tout l'architecture qui est en cause. Donc encore une fois, difficile de juger sans voir tous le code.


Bah, pour moi c'est quand même très axé "Ouh le vilain code ! Riez ! Voilà comment il faudrait faire".


Oui, riez du mauvais code, parce qu'on en fait tous à un moment où à un autre.


Et y a pas besoin de connaitre le contexte pour savoir que la solution proposée est presque aussi crade que le code exposé dans ce cas précis.


Si, mais bon, c'est pas grave, t'as l'air bien seul à soutenir le fait qu'utiliser un count est aussi dégueulasse que de faire une boucle en php pour compter les résultats renvoyés.


Bon, petit court de programmation pour les nuls.

Pourquoi la solution critiquée est mauvaise ? the_frogkiller a déjà répondu, rien à redire dessus.

Pourquoi faire une deuxième requête en count est une (très) mauvaise idée ? Trois raisons :



1) Ca peut être assez lourd de regénérer une requête count avec les mêmes paramètres que la première. Encore une fois, en milieu pro, la grande, que dis-je ?, l'immense majorité des requêtes sont générées ce qui peut nécessiter un traitement assez lourd (pour peu que ça soit possible - ce qui est loin d'être toujours le cas).


Qu'est-ce qui te fait pensé que le code est issue du milieux pro ? Que l'application où tourne le code nécessite des requêtes générées ? Que les traitements sont assez lourds ? Si t'es capable de dire tout ça en regardant 10 lignes de codes félicitation, je pense que tu peux lancer une nouvelle activité : La voyance pour le code.


2) Une deuxième requête en count sera très rapide dans le cas d'une requête simple, dans celui d'une requête complexe avec jointures multiples c'est pas gagné.


Même remarque que plus haut. Rien ne te permet d'affirmer que l'application ne se contente pas uniquement de petit SELECT sans jointures.

Et la solution préconise d'utiliser count, pas forcement en l'utilisant dans la fonction donnée, mais peut être directement dans la requête d'origine. Encore une fois, t'extrapole dans le sens qui t'arrange, mais ce n'est peut être pas le bon sens.


3) Absolument rien ne dit qu'entre les deux requêtes (le select simple et le count) il n'y ait pas eu de nouveaux enregistrements.... donc qui donneraient deux réponses différentes (ah, oui, la requête a déjà été exécuté dans le cas donné en critique).


Comme tu le dis si bien, la fonction "de porc" exécute déjà la requête, donc refaire un count n'est pas pire.


Bref, je ne vais pas ergoter, le code est cradingue au possible, mais la solution n'est pas mieux, d'où mon histoire de poutre et de paille. Quand on rapporte un code pour que le monde entier puisse rire de son auteur, la moindre des choses est d'être irréprochable (d'ailleurs j'ai lu 2-3 autres exemples assez drôles du même genre).


Ah, je pense que t'as pas bien compris l'esprit du blog : montrer des bouts de code un peu dégueulasses pour se marrer, mais pas pour "rire de l'auteur".

Tous les développeurs écrivent un jour ou l'autre du code dégueulasse, pour des milliers de raisons : manque de temps, manque de formation sur une techno, obligation d'utiliser une librairie pourrie, refactoring (trop) rapide qui laisse du code mort ou des aberrations dans le code, reprise de vieux code horrible et pas le temps de tout réécrire, ...

Bref, l'idée c'est de rire de tout ça, parce que tous les développeurs connaissent ça pas de montrer du doigts les auteurs en les traitants de sous-merde.

Les "corrections" ne sont peut être pas toujours les plus optimisés / propre tout ce que tu veux, mais sans connaitre le contexte et le reste du code c'est impossible de juger si la "solution" est la meilleur ou pas à moins de faire comme toi, pleins d'hypothèses qui sont peut être totalement fausses...


Il n'y a aucun système ayant 0 failles, les fusées qu'on envoie dans l'espace aussi sont fait par des mecs bardés de diplômes ça n'empêche qu'il y a des ratés.

Et dans le cas de drone comme ceux qui nous intéresse il y a plus d'un facteur de risque.




Les domaines que j'ai cités ne sont pas fait par des amateurs non plus, les mesures de sécurités sont nombreuses et il y a tout de même des pannes et des accidents. Je ne sais pas si fournir le dernier sextoy à la mode à M. Michu en moins de 30 minutes justifie de mettre des gens en danger.


Ah bah oui, y'a des pannes partout. C'est dingue ça, je le savais même pas. Faut tout interdire alors ?

Le seul risque c'est que le drone tombe de 500m de haut. (Les pales peuvent être protégé pour sécuriser la phase atterrissage).

Et avec un dispositif de parachute à ouverture automatique redondant, on limite quand même énormement les risques.

Et si la livraison se fait par drone, la personne ne sort pas avec sa voiture, qui je le rappel peut elle aussi tuer des gens et petits chats...

Alors oui, y'a des risques tout les systèmes de sécurités peuvent foiré et peut -être qu'une livraison sur 1 million se terminera par une chute du drone et une vitre de voiture cassé. Mais y'aurais peut être eu plus de dégâts si toutes les achats avaient été faits en voiture
Chez moi, www.healthcare.gov me renvoi vers la page de mon serveur local