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 - 2552 commentaires -
Les derniers commentaires de Virtual_Spirit :


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

Pas de problème de sécurité tant que l'appareil reste dans le monde des bisounours mais que ce passe-t-il en cas de panne ou d'action malveillante ? Même pour des systèmes très surveillés (fusée, avion, train) il y a des problèmes.


Je doute qu'ils envoient des drones fait par des amateurs...

Pour qu'ils aient les autorisations il faudra certainement une redondance des systèmes plus un dispositif d'urgence type parachute si jamais tout l'électronique foire.

Pour moi c'est pas quelque choses qu'ils doivent intégrer à leur cahier des charges, mais c'est absolument pas un frein techniquement.
Je pense pas qu'il y'aura tant de problème de livraison que ça pour plusieurs raisons :

- La plupart du temps les drones voleront assez haut (pour éviter les obstacles d'une ville (les gens, les animaux, mais aussi les haut immeubles). Donc pas de problème de sécurité pour les personne et il seront assez difficile à intercepté par les voleurs, même pour un bon tireur. Et si celui-ci arrive à toucher seulement le drone sans détruire le paquet, peu de chance de récupérer le colis intacte à l'arriver (faut déjà le retrouver et pas qu'il soit tomber sur un toit, dans une rivière, écrasé par un camion... )

- ça reste un service annexe, peu de chance de voir 10 drones au dessus de la tête en permanence, donc si on veut en intercepté un ça sera par quelques chose de prévue, mais à faire au moment où on a la chance d'en croiser un, donc toujours se trimbaler avec sa carabine sur soit.

- J'imagine qu'Amazon envoi un SMS / email quelques minutes avant l'arrivé du drône, le destinataire peut donc sortir de sa maison et surveiller la phase d'approche (la seule qui présente des risques (minimes). Il pourra rentrer le chat, éloigner les enfants et faire fuir les vilains voleurs.

Bref, au final très peu de risque de vol et surtout aucun intérêt, autant chopper le sac d'une vielle, c'est plus discret, moins difficile, y'en à plein les rue et au moins on récupère de l'argent et pas un colis qui nous intéressera surement pas. Le vol directement dans les boites au lettre me semble également plus simple et lucratif.
Bah je vois qu'on est tous d'accord, Presse-Citron, c'est un peu de la m***e

Edité par virtual_spirit le vendredi 4 octobre 2013 à 11:59
Pour une début d'optimisation ne suffirait il pas de regarder le code du résultat de leur optimisation puis de modifier en conséquence ? Je sais ça parait simpliste comme ça, il faut que je teste ça


C'est très probable qu'ils rajoutent une petite couche offuscation dans le résultat.