Cher journal,
Je voudrais te raconter une histoire, qui n'est peut-être pas encore finie d'ailleurs, qu'on pourrait résumer en 1 mot : OPTIMISATION !
Tout commence en tout début d'année : je suis embauché chez Chacun cherche son Film, une toute petite (5, moi inclus) boite qui développe un site Web faisant la promotion du cinéma indépendant. Cette boite a fait le (très mauvais, comme on va le voir) choix de faire développer son site par une boite de prestation parisienne, qui a mis des mois à livrer son travail et qui, en plus, était bâclé !
Ils devaient notamment gérer l'import hebdomadaire des horaires de séances : tous les mardis soirs, nous recevons un fichier XML (35Mo, 400.000 lignes) contenant les 3.300 cinémas de France métropolitaine, les centaines de films projetés dans la semaine (du blockbuster au vieux film projeté 1 fois par un petit cinéma Art & Essai, dans le cadre d'une rétrospective d'un réalisateur), les 15.000 événements (1 événement = toutes les infos concernant la projection de 1 film dans 1 cinéma : VF/VO, 3D ou pas, projection 35mm/numérique/…) et les 100.000-150.000 horaires de séances.
Leur import reposait sur le système de Queue de Drupal (avec lequel ils avaient développé le site Web). Mais il était tellement mal optimisé que cela prenait jusqu'à 18 heures (!) pour tout traiter ! De plus, leur script plantait souvent en cours de traitement, nécessitant de le relancer manuellement (et quand il plante dans la nuit de mardi à mercredi, il faut donc attendre que quelqu'un s'en rende compte le matin, et relance).
Bref, les horaires de cinéma pour la semaine, qui commence le mercredi, n'étaient parfois pas totalement disponibles avant… le jeudi dans la journée !
Une de mes premières missions fut donc de corriger et d'optimiser tout ça.
Première optimisation : ne pas traiter les cinémas ou les films dont la date de dernière modification (incluses dans les attributs XML de chacun) est plus ancienne que le flux hebdomadaire précédent. Si rien n'a changé, y a rien à traiter !
Deuxième, et principale, optimisation : réécrire les 2 requêtes XPath (servant à chercher des infos sur les cinémas et films auxquels se rattache chaque horaire). Leurs requêtes XPath cherchaient dans TOUT le fichier XML, au ;lieu de ne chercher que dans les blocs des cinémas/des films.
Résultat : de 18h, on arrive à 3h.
Quelques :ois plus tard, le choix fut fait de recoder totalement le site. Les bugs étaient trop nombreux, et la boite de presta n'avait pas l'air de s'en sortir pour déboguer tout ça. Je recode donc tout en PHP (framework Laravel, mais ça n'a pas d'importance ici). Il me faut donc aussi réécrire le script d'import. Je décide alors de le faire en Python.
Résultat : de 3h, on passe à 1h30.
On a donc les horaires de séances de la nouvelle semaine disponibles dès le mardi vers 19h. Parfait ! Je décide alors d'en rester là, et de me concentrer sur d'autres priorités.
Le temps passe, les autres priorités sont traitées, et me revoilà à repenser à ce script. Ne pourrait-on pas l'améliorer encore ? Après tout, ces 15.000 événements et ces 100.000-150.000 horaires qu'on insère en autant de requêtes, c'est vraiment pas top, quand même. Ça donnerait quoi, si je faisais des INSERT multi-lignes ? Disons… 2 INSERT par cinéma, 1 pour tous les événements, l'autre pour tous les horaires.
Résultat : de 1h30, on passe à… 10 minutes !
Bref, on ne le dira jamais assez : OPTIMISEZ VOTRE CODE ! Ce n'est pas parce que ça tourne sur un serveur avec 8 cœurs que ça dépotera. Surtout quand votre script n'est absolument pas parallélisé !
Et même si je suis très fier de ce gain (d'un rapport de plus de 100 pour 1, au final), je ne peux que me désespérer de voir des codes absolument pas optimisés parce que "bof, de toute façon, le processeur en a sous la pédale !".
PS : ma modification du script n'ayant consisté qu'à stocker dans un tableau les données à insérer, et à passer ce tableau d'un coup à la requête d'insertion, la seule autre cause possible de gains de temps que je vois est l'écriture des logs (à raison d'une ligne par INSERT), qui a diminué dans les mêmes proportions que le nombre de requêtes SQL.
# Chacun cherche son film
Posté par dovik (site web personnel) . Évalué à 4.
Bon exemple d'optimisation simple et efficace.
Dans le même genre : juste ajouter un "LIMIT 1" à la fin de toutes les requêtes ne concernant qu'une seule ligne. Ou 2 si c'est 2, etc…
Quelques questions sur ton site :
- Quel est le modèle économique ?
- Le fichier XML des séances, c'est de l'Open Data ?
[^] # Re: Chacun cherche son film
Posté par windu.2b . Évalué à 5.
_ Modèle économique : aucune publicité sur le site, c'est la règle !
Notre financement vient donc (une fois passée les subventions obtenues auprès de plusieurs organismes, au départ) uniquement des distributeurs de films. Ils nous payent pour mettre plus en avant leurs films (même si tous sont visibles, vu qu'on a tous les films qui sortent en salle).
_ Fichier XML des séances : je doute qu'il soit en Open Data, étant donné que le fournisseur de ce fichier (Plurimedia) le fait payer (20.000€/an, de mémoire). Mis à part nous, leurs autres clients sont au moins Première et Télérama, mais pas Allociné.
[^] # Re: Chacun cherche son film
Posté par j_m . Évalué à 2.
Si ce sont les fichiers SMPTE, j'ai un peu travaille sur un script qui les recupere sur des milliers de cinema en Europe pour Ymagis :-)
Je n'avais pas remarque qu'il y avait foule sur les projecteurs pour les recuperer. Ces donnees pourraient donc assez bien venir d'Ymagis.
[^] # Re: Chacun cherche son film
Posté par kna . Évalué à 3.
Dans le fond, tu as raison, mais comme ça me rappelle un mauvais souvenir, je précise : en ayant mis des contraintes d'unicité là où il faut !
[^] # Re: Chacun cherche son film
Posté par Obsidian . Évalué à 5.
… et en rappelant également que LIMIT ne fait pas partie de la norme ! ;)
[^] # Re: Chacun cherche son film
Posté par Dring . Évalué à 6.
Se restreindre à la norme quand on code du SQL, c'est garantir que le code ne sera pas optimisé.
C'est pour ces raisons que les ORMs implémentent la notion de dialecte, permettant un certain niveau de généricité avec des performances honorables. Et encore, l'ajustement des paramètres du serveur est parfois plus efficace que la réécriture du code…
[^] # Re: Chacun cherche son film
Posté par Obsidian . Évalué à 7.
Il ne s'agit pas de se « restreindre », mais bien d'agir en connaissance de cause, surtout que LIMIT est aussi utile que répandu, mais que si l'on en croit ce tableau, cette fonctionnalité serait prise en charge sur un grand nombre de SGBD mais à l'exception notable de poids lourds comme Oracle ou MS SQL.
Du coup, si ça nous a toujours paru naturel de l'utiliser et qu'on a appris le SQL avec, on va vers certaines déconvenues.
À l'inverse, on n'est plus obligé non plus de s'en tenir à SQL92. On peut aujourd'hui choisir de reconnaître SQL 2003 (même s'il y a eu 2008, 2011 et 2016 depuis) et profiter des fenêtres WINDOW, et même des requêtes récursives qui sont définies depuis 1999 et avec lesquelles j'ai implémenté le forum du site de mon quartier.
[^] # Re: Chacun cherche son film
Posté par Dring . Évalué à 4.
D'une part, et comme indiqué par wismerhill, ce n'est pas le standard, (je rajoute que Sybase ne le prend pas en compte non plus et il est encore très répandu le bougre, surtout dans la finance).
D'autre part, dans la plupart des cas, un LIMIT 1 ne va pas être très efficace ; un index unique avec des statistiques à jour sera déjà suffisant pour ne pas continuer à lire la table "pour rien".
[^] # Re: Chacun cherche son film
Posté par wismerhill . Évalué à 2.
En effet, mais si j'en crois PostgreSQL (https://www.postgresql.org/docs/current/static/sql-select.html, j'ai la flemme d'aller vérifier dans le standard même) SQL 2008 a introduit la clause OFFSET pour remplir la même fonction.
# Optimisez la clarté de votre code !
Posté par damaki . Évalué à 10.
L'optimisation de la vitesse du traitement, c'est bien, mais la base de l'optimisation, c'est de ne jamais commencer par l'optimisation. Déjà, faire du code clair et modulaire, ça permet en moyenne de s'assurer que l'optimisation sera moins complexe car plus localisée.
Ensuite, on ne doit optimiser que ce dont on peut mesurer la performance. Si vous n'arrivez pas à prouver quel bout de code, SQL ou quoi que ce soit est lent, faut pas se lancer dans l'optimisation. D'abord il faut ajouter des mesures de performance, puis si on se rend compte que la granularité des mesures est insuffisante, en mettre encore plus et enfin seulement optimiser.
Enfin, l'optimisation, ça n'est pas juste un travail de développeur, c'est aussi un travail d'administrateur système, d'administrateur réseau et de DBA. Le code n'est pas la seule source de lenteur ou de performances non déterministes.
[^] # Re: Optimisez la clarté de votre code !
Posté par Nicoco (site web personnel) . Évalué à 5.
Oh que je suis d'accord.
Je ne suis pas un vrai dev (mais un académique qui pond des scripts horribles) mais combien de temps ai-je perdu à optimiser des trucs inutiles. Rendre la maintenance plus difficile et introduire des bugs pour gagner quelques millisecondes, ça ne vaut pas le coup.
Bon en vrai j'ai du mal à m'en empêcher parce qu'on est toujours content quand son code va super vite… Mais c'est con !
[^] # Re: Optimisez la clarté de votre code !
Posté par Christie Poutrelle (site web personnel) . Évalué à 8.
C'est absolument vrai, il faut toujours éviter les "premature optimization" - cependant, la performance commence toujours par une architecture logicielle claire et pensée en premier lieu pour les performances. Quand on importe toutes les semaines de centaines de milliers de lignes de gros fichiers XML, la mécanique a sérieusement intérêt à avoir été pensée pour dès le départ.
Par exemple, l'auteur parle de Drupal, et je sais de quoi je parle j'en fais depuis presque 10 ans, et je suis certain que les gens ayant commencé le site ont utilisé les API de Drupal pour injecter le contenu. Cependant, ça devient très vite très compliqué (ça aurait été pareil avec une application Symfony ou Django basée sur un ORM) - où est la barrière que je peux franchir ou pas pour respecter les performances ? Est-ce que j'accepte de contourner les API du logiciel et potentiellement avoir des données obsolète dès leur import (évènements non lancés, listeners non reveillés) où est-ce que j'accepte que ce soit juste lent mais m'assure que tout le monde ai bien sa chance d'intervenir logiciellement au moment de l'injection des donnée ?
La réponse que j'aurais apporté à ce genre de problématique c'est que bien souvent l'outil de base est mal choisi, et dès ce moment, avant même qu'une seule ligne du logiciel existe, ce choix aurait pu permettre d'éviter d'avoir se poser ces questions là.
Puis, pour revenir au XML, utiliser du XPath, sérieusement ? Pour des très gros imports, si tu sais ce que tu fais et que tu connais le schéma, il faut mieux utiliser un lecteur séquentiel, comme l'API XMLReader, qui va juste être incroyablement plus rapide et ne pas consommer de mémoire, là où les implémentations basées sur la libxml2 (c'est à dire toutes en PHP, sauf l'API XML(Reader|Writer)) nécessitent de charger le fichier XML intégralement en mémoire, et en profitent pour passer une phase d'autocorrection du contenu (si si, ça le fait, et même plutôt bien).
Bref, les performances ça se prépare en amont:
[^] # Re: Optimisez la clarté de votre code !
Posté par pralines . Évalué à 2.
quand je lis (rapidement) la doc de PHP, je trouve du XML Reader|Writer, mais dans les pré-requis, je vois : libxml >= 2.6.0
peux tu donner un lien vers l'API XML Reader/Writer dont tu parles, celle qui fait de la lecture séquentielle et évite de charger le fichier complet en mémoire ?
Merci
Envoyé depuis mon Archlinux
[^] # Re: Optimisez la clarté de votre code !
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
En effet (cf https://secure.php.net/manual/en/xmlreader.requirements.php ) tu as raison - peut-être qu'il utilise l'API plus bas niveau que les autres. Je sais que l'API DOMDocument ainsi que SimpleXML sont basée sur la libxml elle aussi - mais eux parsent les fichiers en entier pour les charger. Je me suis donc trompé :)
Cependant le reste reste vrai, à savoir que XMLReader est basée sur un curseur sur le fichier, et ne le parse pas au complet, de mémoire (à moins que ça ait changé mais ça m'étonnerais) tu peux parser du XML invalide (en théorie je dis bien) avec jusqu'au moment ou tu tombes sur la partie cassée.
[^] # Re: Optimisez la clarté de votre code !
Posté par Christie Poutrelle (site web personnel) . Évalué à 1. Dernière modification le 07 décembre 2017 à 17:04.
Par exemple https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/dom/document.c#L1473 (ext-dom) va lire le fichier en entier via https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/dom/document.c#L1352 qui utilise http://xmlsoft.org/html/libxml-parser.html#xmlParseDocument - et là je perds mes petits parce qu'apparemment en interne ça utilise un SAX parser, qui n'est pas donc pas supposer charger le fichier en entier.
Alors que XMLReader ici https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/xmlreader/php_xmlreader.c#L884 (ext-xml) utilise http://xmlsoft.org/html/libxml-xmlreader.html#xmlReaderForFile et ce n'est pas précisé dans la documentation si il charge le fichier en entier ou non.
A noter, ça fait longtemps que je ne l'ai pas utilisé, mais à l'époque, utilise XMLReader et XMLWriter m'avait sauvé d'un bon nombre de memory limit exceeded en PHP.
[^] # Re: Optimisez la clarté de votre code !
Posté par pralines . Évalué à 1.
ok, je note d'utiliser de préférence ces fonctions, faut que je me trouve un bon gros fichier xml pour faire un test avec memory_get_usage
merci
ps : sur un sujet parallèle, faut aussi que je me trouve une bibliothèque php qui permet de générer/lire des gros fichiers XLSX (ou ODS) qui ne souffre pas de fuites mémoire comme PHPExcel (bon outil pour des fichiers pas trop volumineux)
Envoyé depuis mon Archlinux
[^] # Re: Optimisez la clarté de votre code !
Posté par Christie Poutrelle (site web personnel) . Évalué à 2. Dernière modification le 07 décembre 2017 à 17:25.
Utilise https://github.com/box/spout http://opensource.box.com/spout/ c'est très exactement fait pour ça.
[^] # Re: Optimisez la clarté de votre code !
Posté par pralines . Évalué à 2. Dernière modification le 07 décembre 2017 à 17:29.
je repéré SPOUT, mais pas encore eu le temps de tester…
merci pour le second lien, beaucoup plus motivant que le github :-)
Envoyé depuis mon Archlinux
[^] # Re: Optimisez la clarté de votre code !
Posté par Rozé Étienne . Évalué à 1.
Bonjour,
Merci pour le lien vers spout…
J'utilise PHPExcel pour effectivement des fichiers assez petits voir tout petit… L'avantage est qu'il permets l'utilisation des formules…
Et pour créer des fichiers odt ou doc (sans ou avec template), vous auriez aussi des recommandations ?
[^] # Re: Optimisez la clarté de votre code !
Posté par pralines . Évalué à 2.
PHPWord pour les doc et docx
Envoyé depuis mon Archlinux
[^] # Re: Optimisez la clarté de votre code !
Posté par Rozé Étienne . Évalué à 1.
Merci ! cela me semble pas mal du tout…
[^] # Re: Optimisez la clarté de votre code !
Posté par Tit . Évalué à 1.
Pour odt j'ai déjà utilisé odtphp (il me semble qu'il faut un template)
[^] # Re: Optimisez la clarté de votre code !
Posté par windu.2b . Évalué à 3.
Je ne comprends pas ce qui te perturbe : les parsers DOM reposent (tous ?) sur un parser SAX. Ce n'est donc pas le fichier XML qui est chargé complètement en mémoire (SAX étant là pour éviter cela) : c'est sa représentation sous forme d'arbre DOM.
[^] # Re: Optimisez la clarté de votre code !
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Ouais en effet, ça paraît logique.
# Problème
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 07 décembre 2017 à 13:39.
Pas trop de rapport avec l'optimisation de ton script mais quand je vais sur http://chacuncherchesonfilm.fr et que je cherche la chaîne "La défense" ça me retourne 4 films et un cinéma.
Si je clique sur le cinéma j'ai une erreur de type : "Whoops, looks like something went wrong."
Edit : Ah en fait ça le fait sur tous les cinémas :-(
[^] # Re: Problème
Posté par windu.2b . Évalué à 10.
Oupsss !
C'est corrigé.
(note à moi-même pour plus tard : ne pas faire de nouvelle mise en prod' avant de parler de son site)
[^] # Re: Problème
Posté par gnumdk (site web personnel) . Évalué à 10. Dernière modification le 07 décembre 2017 à 16:41.
C'est la blague effectivement.
Le nombre de fois ou je veux faire une démo d'une nouvelle fonctionnalité dans Lollypop ou Eolie en postant une vidéo sur Google+ et que je découvre 1 ou 2 ou 3 bugs pendant l'enregistrement, que je corrige les bugs, et qu'au final cette vidéo m'a pris 3 heures de mon temps. Alors que j'utilise la fonctionnalité en question depuis une semaine sans rien voir.
Moralité, faisez des vidéos!
[^] # Re: Problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Quand je recherche un cinéma avec des homonymes (strada), la liste propose bien des solutions,mais si on choisit avec les flèches du clavier, le nom de la ville n'apparait pas, et on ne sait pas quel cinéma est sélectionné.
Le bouton de recherche de séance est lent, mais la recherche ensuite est ultra rapide : super.
Par contre, je ne vois pas d'indication sur la 3D. Par exemple, si je ne veux pas voir star wars 8 en 3D, je fais comment ? (image moins belle et plus sombre)
Le bouton "nouvelle recherche" revoit sur le whoops.
Il manque une forme de notation aussi. Pour moi, malgré tout ses énormes défaut, c'est l'avantage de allociné. Peut être qu'un résumé des critiques cinéma, pourrait être plus facilement intégré que les critiques de spectateur ? (ou alors, il faudrait reprendre des critiques de totten tomato ou metacritic ou autre)
"La première sécurité est la liberté"
[^] # Re: Problème
Posté par windu.2b . Évalué à 3.
Merci pour ces remontées, je vais regarder tout ça :-)
# Yet another movie database?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Même si tu résous les problèmes techniques, ce site risque d'avoir du mal à vivre s'il ne se différencie pas des allocine/imdb/…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Yet another movie database?
Posté par windu.2b . Évalué à 10.
On ne se contente pas d'être une base de données : notre créneau, c'est la promotion du cinéma indépendant.
Critiques de films (on assistes à quasiment toutes les projections presse des films indépendants qui vont sortir en France), interviews de réalisateurs/acteurs, débats filmés lors de projections dans des cinémas Art & Essai, …
Les horaires, c'est le truc qui nous met à égalité, si je puis dire, avec d'autre sites.
[^] # Re: Yet another movie database?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
La "monocritique" bof-bof les scores "presse" d'allociné montre bien que pour n'importe quel film, il y a toujours un critique pour lui coller 1 étoiles, et un autre pour en coller 3 ou 4. Par contre, qu'importe le film, avec une moyenne de 3 étoiles, c'est forcément un bon film.
"La première sécurité est la liberté"
[^] # Re: Yet another movie database?
Posté par steph1978 . Évalué à 3.
En tout cas le site est agréable.
Il est plus rapide de allociné.
Et je partage l'adage de google : speed is a feature.
# INSERT et transaction
Posté par Blount (site web personnel) . Évalué à 7.
Pour le multi INSERT, l'autre solution est, si ce n'est pas déjà fait, d'utiliser des transactions. Je l'ai fait sur un Prestashop et c'est magique ;)
[^] # Re: INSERT et transaction
Posté par windu.2b . Évalué à 10. Dernière modification le 07 décembre 2017 à 15:14.
En effet, la suppression d'un grand nombre de COMMIT (à chaque requête SQL), au profit d'un seul COMMIT pour chaque cinéma (avec ses événements et horaires) traité a là encore permis de gagner de précieuses minutes (de 10 minutes, je viens de tomber à moins de 3).
[^] # Re: INSERT et transaction
Posté par Anonyme . Évalué à 4.
Diviser le temps d'exécution par 360 au minimum c'est classe.
La boite de presta a filé ça à des lycéens stagiaires, c'est pas possible d'accumuler autant de lacunes sur la base de la programmation.
Après cette lecture fort intéressante, je pense qu'une entreprise devrait avoir au moins une personne capable de vérifier la production externalisée quand elle est aussi critique.
[^] # Re: INSERT et transaction
Posté par Cheuteumi . Évalué à 4.
Que le travail ai pu être confié à des stagiaires c’est pas tellement le problème, c’est qu’il n’y a eu aucun contrôle derrière et que, si c’est le cas, nos pauvres stagiaires sont ressortis sans aucune connaissance supplémentaire… enfin bon c’est un tout autre sujet.
[^] # Re: INSERT et transaction
Posté par j_m . Évalué à 7. Dernière modification le 08 décembre 2017 à 20:45.
Tout a fait. Si tu fais de la relecture de code pour le stagiaire pour chaque pull request, le resultat ne devrait pas etre trop mauvais.
[^] # Re: INSERT et transaction
Posté par Anonyme . Évalué à 6.
Je suis complètement d'accord avec ces remarques. Je me suis mal exprimé. Je ne blâme pas l’exécutant mais bien le manque d'encadrement.
Je pense simplement que c'est le genre d'entreprise qui confond stage et CDD voire qui ne tourne qu'avec ce genre de contrats à bas coûts et qui ne fait qu'empocher sans superviser, parce que dès les premiers choix, avant même de coder, le projet était très mal pensé, tellement mal que j'en viens à croire que la ou les personnes qui ont travaillé dessus soient de jeunes néophytes livrés à eux-mêmes.
Je suis totalement un amateur autodidacte en informatique pourtant j'ai constaté que dans tous les corps de métier (et même par extension dans le travail domestique non rémunéré) il y a toujours une part d'organisation préalable qui correspond à une bonne partie du travail et qui détermine l'exécution et l'efficacité (qualité, temps, énergie, coûts, etc). Une formation pro commence souvent par le savoir théorique, l'apprentissage d'une méthodologie et la description des outils manipulés.
[^] # Re: INSERT et transaction
Posté par ckyl . Évalué à 9.
Pourquoi supposer que ce sont des stagiaires ou CDD qui ont fait ça ? Il y a une masse significative de gens parfaitement incompétents parmi les gens en CDI, qu'ils aient 1 mois ou 10 ans d'expérience d'ailleurs. Après il y en a moins, ils ont été déplacé middle manager / product owner, ou jouent au consultant mais ne produisent plus rien.
Le fait qu'on parle d'optimisation pour ce genre d'évolution montre où on en est !
[^] # Re: INSERT et transaction
Posté par Anonyme . Évalué à 2. Dernière modification le 09 décembre 2017 à 12:35.
Je n'ai pas supposé que c'était des gens en CDD, tu as mal lu cette phrase qui évoque une pratique détournée du stage en entreprise.
Je doute fortement que les bases méthodologiques se désapprennent. À ce niveau de méconnaissance c'est pour moi de l'amateursime d'où l'emploi du terme "lycéens stagiaires" (au pluriel car dans le détournement de stage c'est commun qu'on refile un projet en cours de stagiaires en stagiaires). Dans tous les cas c'est bien un problème de supervision et de vérification, surtout quand tu sais que l'employé assigné n'est pas à la hauteur de la tâche ou qu'il doit faire ses preuves (la période d'essai sert à ça).
La problématique sur l'emploi du terme "optimisation" est déjà discutée plus haut dans les commentaires, ce n'était pas mon propos.
[^] # Re: INSERT et transaction
Posté par ff9097 . Évalué à 1.
C'est aussi le problème de la prestation. Comment veux-tu motiver tes développeurs à se donner à fond et à faire de la qualité pour quelque chose qu'ils te toucheront plus une fois livré ? Surtout s'ils n'ont pas à gérer les problèmes d'exploitation derrière
[^] # Re: INSERT et transaction
Posté par j_m . Évalué à 2. Dernière modification le 11 décembre 2017 à 10:05.
Parce que la recherche du travail bien fait est la seule motivation qui leur reste puisque comme tu le dis ils ne peuvent pas suivre la vie du projet et son impact. Mais ca peut etre une motivation puissante. C'est un peu la motivation de l'artiste et de la recherche du chef d'oeuvre. C'est ce type de motivation que je privilegie personnellement.
Je pense que cet extrait de Simone Weil peut aider a comprendre cet etat d'esprit:
Sachant que Simone Weil a suivis les debuts du collectif de mathematiciens Bourbaki avec son frere Andre Weil, je me demande si cet etat d'esprit n'a pas un peu participe au succes du projet.
[^] # Re: INSERT et transaction
Posté par Cheuteumi . Évalué à 6.
Faut-il encore avoir le temps de faire les choses bien en prestation. J’ai quitté ce mode pour cette raison… je n’ai pas eu l’occasion d’avoir des clients désireux de travail bien fait jusqu’au bout. Il fallait que ça soit fait pour rentrer dans le budget quitte à avoir des bouts de scotch pourris à certains endroits.
Ce n’est que mon expérience, j’espère que ce n’est pas le cas pour tout le monde.
[^] # Re: INSERT et transaction
Posté par Anonyme . Évalué à 3.
J'en ai aussi posé du scotch cache-misère plutôt que de reboucher proprement des trous.
Ce qui m'a fait quitté l’événementiel c'est à la fois le manque d'intéressement proposé et de considération des employeurs, et à la fois le manque de peaufinement et le rush permanent parce qu'on veut pas dépenser dans le budget alloué à la construction et au montage.
Quant en plus certains exposants ne sont pas joignables et se permettent de demander de gros changements lorsqu'ils débarquent les derniers jours avant l'ouverture au public, t'as vraiment ni le temps ni la motivation de faire du bon travail et tu n'en retires aucune satisfaction, uniquement le soulagement d'en avoir terminé.
[^] # Re: INSERT et transaction
Posté par dinomasque . Évalué à 6.
Comment veux-tu motiver
tes développeursles fleuristes à se donner à fond et à faire de la qualité pour quelque chose qu'ils te toucheront plus une fois livré ? Surtout s'ils n'ont pas à gérer les problèmes d'exploitation derrièreSi les fleuristes (et ça marche avec plein de métiers) y arrivent, pourquoi pas les développeurs ?
D'ailleurs, plein de développeurs se sont déchirés pour faire du super code qu'ils n'ont plus jamais touché ensuite (par exemple des légions de développeurs de jeux vidéo qui ont fait cracher leurs tripes aux micros et consoles des années 80 et 90).
BeOS le faisait il y a 20 ans !
[^] # Re: INSERT et transaction
Posté par Fabimaru (site web personnel) . Évalué à 4.
Parce que c'est plus peut-être beaucoup plus facile d'évaluer la qualité du travail d'un fleuriste que celle d'un développeur?
# Bémol
Posté par Zenitram (site web personnel) . Évalué à -3.
Zut, je retrouve plus l'histoire, alors vite fait :
C'est l'histoire d'un responsable d'équipe qui présente à sa hiérarchie le travail depuis 6 mois de son équipe pour optimiser la RAM, car ça touchait les limites des machines (et il y en avait, "quand même".
Le mec était fier, ça évitait d'acheter de nouvelles machines ou d'upgrader.
Et la intervient le stagiaire : "je ne connais pas tous les prix, mais de ce que vous donnez comme info, ajouter de la RAM aux machines me semble moins cher, pouvez-vous m'en dire plus?"
La fin ne s'est pas bien passé pour le responsable d'équipe.
Bref, attention aux généralités, ici tu as oublié de comparer le prix que ça a coûté à faire ces modifs (ton temps passé dessus) et le prix d'achat d'une machine plus puissante : peu information à ce sujet, donc impossible de savoir si ce que tu as fait a été intelligent (ça va dépendre du nombre d'heures passées et de ton salaire, par rapport au prix d'une machine 10x plus puissante disons, 2 heures ou 10 minutes pour le traitement, faut voir si ça a une rentabilité pour vous entre l'un et l'autre). La, il semble que tu as pensé geek (1h30, tu aimes pas, mais combien ça te rapporte de passer à 10 minutes? aucune info) et pas "gestionnaire d'entreprise" (est-ce que ça vaut le coût de dépenser de l'argent à passer en dessous de 1h30? tu ne le dis pas, mais il semble bien que tu l'as fait sur le temps de l'entreprise et non pas sur ton temps perso, donc c'est important)
Alors certes un gain de 100 sur plusieurs heures ça semble plié, mais de manière générale on dit aussi le contraire : arrêtez de vouloir optimiser quand le coût de développement est supérieur au gain prévu.
Moralité : penser à optimisez ou surtout arrêtez de vouloir optimiser, ça dépend des cas, en faire une généralité dans un sens ou dans l'autre en conclusion, sans avertissement, est un mauvais conseil.
[^] # Re: Bémol
Posté par claudex . Évalué à 10.
Sauf que d'après ce qu'il décrit, il y a ait peu de chance qu'une machine plus puissante fasse beaucoup mieux. Typiquement, le genre d'opération qu'il décrit, ça demande du tuning db pour tirer correctement parti d'une machine plus puissante (augmenter les valeurs de consommation mémoire, déplacer certaines opération en mémoire…).
Pour la partie utilisation RAM, il faut faire aussi attention, un processeur Intel Xeon ne peut avoir que 750Gb de RAM (1,5To pour certaines version). Passer cette limite, tu vas avoir ta mémoire déplacer sur plusieurs processeurs, ce qui va ralentir les traitement vu qu'il faudra lire la mémoire en passant par un autre CPU. Et je parle du cas limite. Si tu as 500 Gb de RAM dans un machine, tu as (dans les configurations classiques) 250Gb par CPU, si tu rajoute 500Gb, tu n'auras que 250Gb en plus par CPU.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bémol
Posté par windu.2b . Évalué à 10.
Comme je l'explique dans le journal, je me suis "contenté" d'un traitement durant 1h30 pendant des mois (de mars à cette semaine), parce que, comme tu le soulignes, le gain de temps que j'aurais pu avoir n'aurait pas apporté grand chose, si ce n'est une fierté personnelle.
C'est quand j'ai eu du temps "libre" (pris sur mon temps de travail, toutefois) que je me suis remis à optimiser ce script. Tout compris (donc en incluant le temps mis ce matin pour écrire ce journal), j'estime mon temps passé dessus à 1 journée, max.
[^] # Re: Bémol
Posté par pralines . Évalué à 10.
et la prochaine fois que tu travailleras sur un problème similaire, tu n'y passeras que quelques minutes
Envoyé depuis mon Archlinux
[^] # Re: Bémol
Posté par Cheuteumi . Évalué à 10. Dernière modification le 08 décembre 2017 à 15:04.
Une journée pour optimiser vs. le temps passé à être en retard je crois que ça en vaut le coup.
Et puis bon, c’est bien aussi d’arrêter de faire flamber les centrales nucléaires
^^'[^] # Re: Bémol
Posté par groumly . Évalué à 10.
Ouais faut arrêter un peu la. c'est pas de l'optimization ce qu'il a fait, c'est corriger des bugs monstrueux.
Ya aucune raison pour qu'un import hebdomadaire de petite taille (on parle de 200k insert la quand meme, on est loin du big data…) prenne 18 heures.
Si ca veut dire que les horaires du mercredi ne sont pas dispo avant jeudi matin, ben c'est un peu ballot quand meme, non?
ya aucune raison que ca prenne plus de 5 minutes. L'équipe qui a écrit ca avait pas la moindre idée de ce qu'ils faisaient (ou en avaient rien a carrer).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bémol
Posté par Fabimaru (site web personnel) . Évalué à 4.
Ou alors quelqu'un a estimé un budget/une durée ridicule, et il a fallu arrêter dès que ça remplissait les obligations contractuelles. Ou alors un supérieur hiérarchique s'est dit que ça serait plus rentable de bosser sur un autre contrat une fois que les risques avec ce client étaient minimisés. Y a plein de tristes scénarios ayant pu mener à ce fiasco.
[^] # Re: Bémol
Posté par Kerro . Évalué à 3.
Les exemples que tu donnes correspondent à « en avaient rien a carrer ».
[^] # Re: Bémol
Posté par Guillaum (site web personnel) . Évalué à 9.
Dans mon industrie, on cours après les % de performance qui peuvent impacter le coût d'un projet d'une manière non significative (le coût du calcul est souvent supérieure à la masse salariale de nos projets). Ceci impact directement notre façon de programmer. On passe du temps à optimiser pour 5%, on est pret a transformer un code générique de 3 lignes en 2000 lignes d'une soupe infâme pleine de cas particuliers.
Après de nombreuses années dans cette industrie, je ne sais toujours pas quel est la stratégie gagnante. Si on est 10% plus lent que la concurrence, on perd des clients, mais si on prend 6 mois a mettre en place un nouvel algorithme parce que le code est trop complexe, on perd des clients aussi.
Et sinon, pour la blague sur la RAM, on s'amuse à quantifier des float sur moins de bits (en fonction du contexte), parce que 1 ou 2 bits à droite ou à gauche, au final cela fait quelques Giga de RAM en plus ;)
[^] # Re: Bémol
Posté par Anthony Jaguenaud . Évalué à 6.
Dans mon industrie, c’est l’inverse on court après les certitudes…
On a besoin d’être sûr que la boucle principale s’exécute bien en moins de 10ms (proc pas véloce) tout le temps.
Pour moi, l’optimisation doit être mesurable : gain, temps de dev et de maintenance… car la soupe infâme, quand il y a un bug, c’est encore plus infâme.
Au niveau de l’approche que j’adopte :
- Quelles sont mes contraintes temporelles ?
- Quels sont les traitements qui risque de déborder ?
En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.
Ma question pour l’auteur, c’est : entre le moment d’obtention des données et la limite de mise en ligne acceptable, tu as combien de temps pour combien de donnée ?
À partir de là, tu peux voir si tu tiens ou non. S’il faut optimiser ou pas. Parce que souvent, c’est rigolo d’optimiser, mais on oublie souvent que ça a un coût non négligeable. Dans certains métier comme le tien c’est vital, dans d’autre non. Par contre, si la maintenance à long terme est vitale, il vaut mieux pas faire trop d’optimisation (micro optimisation locale), et privilégier les bons algo structure de donnée.
[^] # Re: Bémol
Posté par flagos . Évalué à 2.
Parcourir une liste, c'est pas franchement O(1)..
[^] # Re: Bémol
Posté par foobarbazz . Évalué à 3.
Si les tailles des listes sont bornées, si :-)
C'est comme ça que je l'ai compris.
[^] # Re: Bémol
Posté par Anonyme . Évalué à 5.
pendant un stage chez THALES, un formateur a expliqué :
il faut mesurer pour décider.
J'ai bien aimé, après c'est pas une excuse pour pondre des fichiers excel degeulasse pour mesurer des latences sous MS SQL
[^] # Re: Bémol
Posté par gasche . Évalué à 5.
Il doit y avoir une incompréhension entre toi et nous, parce qu'arrêter de chercher une liste quand on a trouvé, ça reste en O(1). O(1) veut dire "plus petit qu'une constante", donc faire moins de calculs préserve toujours la propriété d'être O(1).
Il y a des domaines où on veut non seulement faire du O(1), mais en plus que le calcul consomme toujours les mêmes ressources (temps, mémoire, énergie) : c'est quand on veut éviter les attaques par canaux auxiliaires dans un protocole cryptographique. Mais tu parlais plutôt de systèmes temps-réel dur dans ton message.
[^] # Re: Bémol
Posté par groumly . Évalué à 2.
A moins que je me méprenne, les deux sont du o(n), à moins que tous ses tableaux aient une taille fixe (ce qui est certes pas courant, mais pas forcément jamais vu), mais même dans ce cas, c’est une utilisation douteuse de la notation O.
La différence entre les 2 approches c’est que la sienne va donner des temps d’executions plus constant sur des données différentes, à savoir que les cas pathologiques (valeur à la fin du tableau) s’exécutent aussi lentement que les meilleurs cas. C’est assez particulier comme approche, j’avoue, mais il a potentiellement des contraintes qui justifient ça.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bémol
Posté par Sufflope (site web personnel) . Évalué à -5.
Oui c'est précisément le commentaire de gasche, c'est gentil de lui expliquer qu'il a raison sur l'air d'il a tort.
[^] # Re: Bémol
Posté par Sufflope (site web personnel) . Évalué à -7.
Visiblement les lecteurs de DLFP sont toujours aussi cons et illettrés.
[^] # Re: Bémol
Posté par groumly . Évalué à 5.
Et les commentateurs aussi pedants et attaches a leur sacro saint karma.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bémol
Posté par Xinul . Évalué à 10. Dernière modification le 08 décembre 2017 à 14:43.
Tu n'as pas totalement tord, mais dans la cas présenté tu oublies aussi les faits suivants :
- sur les 18h il y avait des erreurs, et il fallait parfois relancer manuellement (donc on a aléatoirement des pertes et un gros problème de fiabilité),
- le script doit tourner au moins 1 fois par semaine, ce qui à 18h d'exécution est ENORME à l'année,
- la machine consomme sans doute bien plus d'électricité, ce n'est ni économique ni écologique,
- difficile à quantifier financièrement, mais avoir cherché à optimiser lui a fait gagner en compétence ce qui sera toujours bénéfique,
- si le fichier reçu est de plus en plus volumineux, ça devrait avoir très peu d'impact.
Le gain n'est pas que financier. Et de manière générale, ne penser qu'en terme financier est un mauvais calcul, il y a tellement d'autres paramètres…(ah mais oui, ce n'est pas aussi facile à quantifier, donc les gens du dessus n'aiment pas…).
Edit : j'oubliais, le partage d'expérience derrière tout ça (qui n'aurait au eu lieu en gonflant la machine) ! Gain qui sort du simple cadre de ton entreprise, et rapporte à tous.
[^] # Re: Bémol
Posté par Zenitram (site web personnel) . Évalué à 3.
En fait, l'idée de mon bémol était moins sur cet exemple précis (qui forcément est assez "évident"), mais sur le fait de passer d'une exemple "pour moi, sur ce cas, ça a été utile d'optimiser" à une conclusion "optimisez" très générale, qui est le meilleur moyen pour se planter à terme.
Après, si on a envie de me moinsser pour faire une remarque sur une erreur des plus classiques de passer d'un exemple à une généralité, que les moinsseurs s'amusent à se complaire dans cette façon de faire… (mais je parie qu'ils ne mettent pas la conclusion en application, car les jours ne faisant que 24 heures et les finances étant non infinies il faut bien faire des choix de ce qu'on cherche à optimiser et non pas suivre la généralité à laquelle on "refuse" le bémol)
PS : et zut, je m'étais dit de ne faire qu'un commentaire, bon essayons de se limiter à 2 vu que de toute façons c'est "inutile"…
[^] # Re: Bémol
Posté par steph1978 . Évalué à 8.
Passer de 18h à 10m en groupant des inserts.
Faut que tu expliques comment tu fais ça en ajoutant de la RAM et sans code…
# -fomgoptimization !
Posté par Lutin . Évalué à 7.
-O5 et ça roule !
# Et au final ?
Posté par pasBill pasGates . Évalué à 8.
Vous leur avez fait quoi à ces consultants incompétents ? Vous avez demandé un retour de votre argent ? Un procès pour violation du contrat ? …
[^] # Re: Et au final ?
Posté par xcomcmdr . Évalué à 7.
Ils leur ont offert Windows 10.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et au final ?
Posté par Michaël (site web personnel) . Évalué à 6.
C'est une bonne question, et moi qui n'ai pas une grande expérience de ce type de contrats, je me demande quelles genre de clauses on trouve pour se protéger de consultants complètements incompétents. (Le plus simple est peut-être d'essayer de parler à leurs anciens clients?)
[^] # Re: Et au final ?
Posté par steph1978 . Évalué à 5.
De manière générale, le mode forfait et le développement agile te permet de limiter les dégâts.
En ajoutant de partir d'un COTS, si possible opensource (pour la pérennité, et la gestion simplifie des licences) pour un premier proto fonctionnel.
Tu paies deux trois sprints. Si les résultats sont pas là, tu changes de presta.
Sans vouloir être méchant, quand un client s’aperçoit un an après le lancement de projet, que le logiciel qu'on lui livre n'est pas de la qualité attendue, c'est plus le client qui est à blâmer que le presta.
[^] # Re: Et au final ?
Posté par Michaël (site web personnel) . Évalué à 2.
Top, merci!
[^] # Re: Et au final ?
Posté par windu.2b . Évalué à 9.
Une procédure est en cours…
# Vécu
Posté par Obsidian . Évalué à 9. Dernière modification le 16 septembre 2024 à 20:03.
Malheureusement, la prestation de code, ça ne marche que très rarement surtout qu'à moins d'être vraiment une toute petite structure, il y a toujours un geek quelque part qui est capable d'écrire ce genre de script dans le cadre de ses heures et qui est beaucoup plus au fait des nécessités de sa boîte (surtout que ce sont généralement les siennes aussi).
J'ai connu l'affaire aussi au début des années 2000. Je travaillais dans un centre de recherche semi-indépendant et qui avait besoin d'un LIMS depuis longtemps (une vraie arlésienne) et le patron avait confié la chose à une boîte canadienne pour le développer.
Moralité, un soft toujours pas sorti des années plus tard et une facture tenue confidentielle mais qu'un collègue avait réussi à estimer en millions de dollars. Au point ou on en était, on ne disposait que d'une interface (client Windows natif) qui permettait de nourrir une base de données… sans pouvoir la lire en retour. Celle-ci était formée d'une boîte de dialogue de taille fixe truffée de champs de saisie et de boîtes déroulantes. Entre autres tares, j'ai suggéré à un collège de faire [TAB]… [TAB]… [TAB]… pour voir comment on passait d'un champ à l'autre au clavier, sachant que cette interface devait être utilisée intensivement dans les laboratoires pour entrer les résultats de recherche. Et sans surprise, on voyait le focus partir dans tous les sens. L'interface proprement dite avait là encore dû être confiée à un
stagiairedébutant (j'ai connu plusieurs stagiaires qui étaient plus compétents que les titulaires qu'ils épaulaient), qui avait dû utiliser l'interface de composition de Visual Basic et décorer bien gentiment son panneau avec ses contrôles, sans même être conscient de l'existence de la propriété « index ».Toujours au même endroit, quelques années plus tard, un type qui faisait de la bioinfo devait reverse-complémenter une séquence de paires de bases génétiques (remplacer un A par T, un C par un G, et vice-versa, puis retourner la séquence en la lisant de droite à gauche) enregistrée en ASCII dans un fichier de 3Mo.
Le gars avait fini par me demander de l'aide parce que son programme n'avait toujours pas fini après… 2 heures de calcul ! Il avait écrit un script en Perl (encore à la mode à l'époque), il chargeait son fichier dans une grande chaîne de caractères et utilisait
chomppour grignoter le dernier caractère, le complémenter et l'ajouter à la chaîne de sortie.Pour le fun, étant donné que la tâche à réaliser était excessivement simple, je me suis amusé à l'optimiser à outrance également, en y consacrant une petite heure. J'avais utilisé mmap() pour projeter son fichier en mémoire en laissant toute latitude au système pour charger tout cela de la façon la plus efficace possible et j'avais écrit le cœur de la boucle en utilisant xlat sur x86 (c'était surtout un prétexte pour le faire. En plus, je n'avais pas envie de me faire suer à savoir si et dans quelles conditions le compilateur aurait pu faire mieux).
On est passé de plus de 2 heures à… 2 dixièmes de secondes ! :-)
Certes, ce n'était pas très difficile, mais je pense que c'est le plus grand gain que j'obtiendrai jamais.
[^] # Re: Vécu
Posté par gasche . Évalué à 6.
Le contrat à l'extérieur ne marche pas forcément, mais tout internaliser a aussi ses propres problèmes, au moins quand la taille du projet est trop petite (ou ses finances) pour avoir plus d'un seul développeur. Avec un prestataire extérieur, si tu as la chance de trouver des gens compétents (oui, ça existe), tu peux espérer avoir plusieurs personnes qui travaillent sur le projet à temps partiel, ou au moins un seul développeur qui a beaucoup d'expérience de travail en équipe.
(Bien) travailler à plusieurs et (bien) travailler tout seul c'est très différent, le premier est un peu moins efficace sur le court terme (coûts de communication, conventions à adopter, mécompréhensions etc.), mais il incite beaucoup plus à avoir de la documentation écrite, des processus de développement/bugfix/release/etc. explicités, et se prête donc plus naturellement à un passage de bâton (partiel ou total) à d'autres développeurs ensuite.
Quand on travaille tout seul (même quand on est compétent et qu'on fait attention), c'est facile de s'enfermer sans s'en rendre compte dans un projet où on a tout en tête mais peu de choses écrites pour d'autres, dans des choix d'architectures non-standards qui rendent le projet plus difficile à comprendre pour d'autres, et au final avec quelque chose qui, si on doit se faire remplacer pour une raison quelconque, est beaucoup plus difficile à prendre en main pour les suivants.
Idéalement je pense que si j'étais demandeur d'une prestation informatique, j'essaierais de trouver un compromis entre "la boîte de prestation opaque" et "le développeur tout seul en interne". Soit une petite boîte avec un petit nombre de personnes en local avec qui j'ai de bons rapports, soit essayer de gérer les responsabilités en interne pour avoir plus d'une personne sur le backend (par exemple, au lieu d'avoir un développeur et un webmaster, chercher deux personnes polyvalentes qui se partagent les tâches sur les deux fronts).
# Beaucoup de dev ne savent pas faire du SQL
Posté par ComputingFroggy (site web personnel) . Évalué à 6.
Salut,
En plus des problèmes XML, ceci démontre bien ce à quoi j'ai déjà été confronté, il y a … 20 ans (putaing, je suis vieux) : la plupart des développeurs ne sont pas intéressés par le SQL et la base de données.
Gérer les problématiques d'insertion (INSERT multi-ligne, et transactions pour diminuer les logs) : cela fait partie de ce que doit savoir un développeur qui travaille avec une base de données mais qui est très souvent ignorée. De plus dans le cas d'insertion de plusieurs parties corrélées, la gestion de transaction permet de s'assurer que la base de données reste dans un état stable en cas d'arrêt du chargement (suite à une erreur) et donc de pouvoir recommencer simplement.
J'ai déjà constaté très souvent, que beaucoup de développeurs ne voient la base de données que comme "le truc dans lequel on enregistre et lit les données" sans se préoccuper de comment ça marche et surtout comment l'utiliser efficacement. Par exemple, faire des requêtes efficaces, lire les query plan, ajouter des index si besoin, en supprimer s'ils sont inutiles, utilier BCP (ou équivalent selon le moteur) pour charger des données etc.
Bravo pour les modifications apportées.
Et bonne continuation pour Chacun cherche son Film, que j'ai découvert grâce à ce journal.
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par j_m . Évalué à 3.
Qu'est-ce que tu conclus avec cette remarque de ce que dois savoir ou ne pas savoir un developpeur sur les DB? Si c'est d'aider avec bienveillance le developpeur en question a s'approprier ces techniques des que tu te rend compte de ce type de lacune, ca me va. Mais c'est valable pour tout truc necessaire a un moment donne, que ca soit plus ou moins pointu. Donc pourquoi ca en particulier?
En plus je sens bien le truc venir de la liste des choses indispensables a connaitre, et que c'est une humilitation d'un ignorer une. Eviter la honte est plutot une mauvaise motivation d'apprentissage.
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par Obsidian . Évalué à 3.
Rien de tout cela, à mon avis.
Je suis assez d'accord avec lui quand il dit qu'au départ, les bases de données sont un sujet qui a l'air rébarbatif aux jeunes programmeurs. C'est même un problème quand ça dure dans le temps, au point d'avoir un chef qui se sent obligé d'expliquer leur métier à tous les développeurs mais qui met un point d'honneur à dire que les bases de données ne sont pas dans son périmètre, justifiant ainsi ses soi-disant domaines d'expertise (en fait, ses centres d'intérêts, qui sont bien souvent les mêmes que tout le monde. Et, oui, tout le monde aura compris que c'est là encore un exemple vécu.)
L'ennui avec les DB, c'est qu'on les enseigne bien souvent avec le traditionnel annuaire ou la base de données clients (nom, prénom, adresse, numéro de client, liste des produits achetés, etc.). Déjà rien de folichon en soi mais, en général, on doit aussi construire et surtout remplir la base soi-même. Donc, des heures de insert à recommencer sans arrêt pour se retrouver au final avec une base de cinq clients et trois commandes. :-\ Il est beaucoup plus intéressant, à mon avis, de se faire les dents sur une base déjà faite et bien remplie, avec un schéma visuel et bien explicite, surtout que cela ne pose aucune difficulté technique : il est tout-à-fait possible d'accorder des droits en lecture seule sur la base à un profil donné et de lui conférer en plus la possibilité de créer les siennes dans un tablespace bien défini, avec bien sûr les contraintes d'intégrité qui s'imposent. Personnellement, j'ai totalement pris goût au SQL lorsque j'ai commencé à travailler sur la base de gènes qui m'a occupé pendant six ans. Donc en faisant des requêtes dans une base avec beaucoup de tables, énormément de données (des millions d'enregistrements par table sur une base Sybase de l'époque).
Non plus. C'est plutôt que ces notions sont intimement liées aux SGBDR et en fait, c'est même pour elles qu'ils ont été conçus ! Sinon, ils n'apportent pas grand chose de plus que de simples fichiers. Au passage, on rappelle qu'initialement, un « fichier », c'est une boîte à fiches. Et c'est bien pour faire ce genre de traitement qu'ils ont été inventés sur les ordinateurs. Comme depuis le départ, un fichier est implémenté comme une suite continue de données, on les utilise majoritairement cette fin : sauvegarder une séquence d'octets continue quelle qu'elle soit, et c'est très bien comme ça. Mais ça explique pourquoi les appels comme fread() permettent de préciser la longueur d'un enregistrement ET le nombre d'enregistrements à lire, et pourquoi un certain nombre de langages définissent les champs destinés aux fichiers comme étant de taille fixe et comblés par des espaces.
En plus, ce n'est pas forcément difficile. C'est plutôt une bonne habitude à prendre depuis le départ. Et très vite, dresser un schéma bien léché devient un plaisir de fin gourmet.
Alors naturellement, il ne s'agit pas de faire de tout un chacun un expert base de données mais en revanche, la façon dont tu poses la question laisse penser qu'en effet, pour un certain nombre de personnes, une base MySQL serait un peu l'équivalent d'une base de registre Windows. Si c'est le cas, et qu'en plus c'est en toute bonne foi, alors c'est peut-être, en effet, quelque chose à surveiller puisque l'on tenait cela pour acquis depuis longtemps.
En plus, c'est réellement important qu'il est extrêmement difficile de gérer « à la main » les contraintes d'intégrité dès lors qu'on dépasse deux ou trois tables. Il n'y a qu'à comptabiliser le nombre de fois que l'on s'est vu opposer une erreur par le SGBD au départ pour se rendre compte que chacune d'elle était en fait une catastrophe potentielle évitée. C'est un peu comme les segfaults quand on fait du langage C ou autre langage compilé en langage machine. Il faut se souvenir que même sur PC, on a attendu le 286 et surtout le 386 pour avoir un mode protégé et que même avec eux, le DOS n'a réellement pris sa retraite qu'avec les années 2000. Cela veut aussi dire qu'en fin de compte, ça ne fait qu'une petite quinzaine d'années que l'informatique grand public est proprement sécurisée de ce côté. :)
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par j_m . Évalué à 4.
Je suis d'accord que les base de donnees peuvent etre un probleme interessant. Mais je ne repondais pas sur ce point mais plutot sur declarer ce que les autres doivent savoir. Ce genre de preoccupation est le premier pas pour developper des relations pourries tout autour de soit.
Apres si on est enseignant ou qu'on doit payer un salaire c'est sans doute une question a se poser.
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par Sufflope (site web personnel) . Évalué à 7.
Bah disons que quand c'est le point (la méconnaissance des SGBDR) qui fait passer de 10s à 18h d'exécution, non ce n'est plus "un savoir parmi d'autres" mais "le problème n°1".
Je ne peux qu'abonder dans le sens de l'auteur du journal et du commentaire initial. Venant d'un monde JEE, j'ai vu mon lot de développeurs d'applis de gestion qui ne comprennent rien aux SGBDR / à SQL (voire refusent de) et les horreurs que ça provoque. Alors que dans le même temps, dans chaque test de recrutement on leur demandera la différence entre une TreeMap et une LinkedHashMap (donc ils la connaissent, éventuellement par cœur sans la comprendre). Différence dont on se bat les gonades dans le contexte de la majorité des applis JEE car elles contiendront maximum 100 éléments et auront la durée de vie d'une requête HTTP, alors qu'un pauvre index sur la table utilisée ferait passer le temps de chargement de cet écran de 10s à 10ms (et je parle même pas de mieux modéliser les données).
Je ne sais pas pourquoi mais c'est comme ça. Enfin si j'ai une vague idée, liée au fantasme des abstractions comme Hibernate et équivalents ailleurs (quand j'ai fait de très modestes contribs à des projets non-Java, même des avec pignon sur rue, j'ai vu de ces trucs qui m'ont bien décomplexé de mon passé Javaiste, comme quoi c'est pas une question de langage utilisé…), qui promettent d'abstraire totalement le stockage concret des données. Note que j'aime bien Hibernate pour ce qu'il apporte réellement, mais je reste lucide. Mais malheureusement on a formé des générations de développeurs qui pensent que "le stockage des données ça juste marche et c'est pas un problème".
Donc je n'ai pas de preuve parfaitement scientifique, mais j'ai l'impression que oui, le problème des développeurs qui font des horreurs avec leur modélisation / stockage des données, est bien plus grave que "là tu aurais pu dérouler ta boucle et gagner 10 cycles de processeur".
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par j_m . Évalué à 7.
Ce que j'essaie de dire c'est que ca ne me derangerait pas forcement de travailler avec quelqu'un qui ferait ce genre d'erreur. Il se pourrait meme que je m'en fout totalement.
Un processus qui fait des insertion dans une table, qui prend 18 heures a tourner, une des premieres choses que je demanderais a la personne qui a fait ca, c'est est-ce que tu fais des bulk insert. Si il ne sait pas ce que c'est on va un peu parler, je lui montre peut-etre un exemple en SQL et voila. C'est gere sans aucune consideration de ce que les autres doivent savoir ou pas.
Et j'essaie surtout de pas lui faire sentir qu'il aurait du le savoir! Meme si c'est difficile de se sortir ce genre de betise de la tete quand on est immerge dans cette societe pourrie qui est la notre.
# SI je puis me permettre de suggérer?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3.
Ton script est parfaitement optimisé.
Néanmoins, chez nous on parse le XML (fichier de parfois plusieurs Go) en AWK compilé (PERL est censé faire mieux) avec ">" comme séparateur de champ et "<" comme fin de ligne. C'est bateau et cela ne vérifie pas la conformité XML mais quand on connait le format, avec un tel traitement on peux parser même un fichier XML mal formaté et c'est très rapide. Pour le charger en base on écrit des fichiers CSV car le LOAD DATA est ce qui ce fait de mieux pour MySQL. Il faut savoir que l'on peut écrire une ligne CSV très rapidement sans avoir tout en mémoire juste en sachant ce que l'on traite.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.