À emporter: L’animateur Eric Kavanagh a discuté du débogage et du profilage des bases de données avec les docteurs Robin Bloor, Dez Blanchfield et IDERAs Bert Scalzo.
Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.
Eric Kavanagh: D'accord, mesdames et messieurs, il est 16 h 00, heure de l'Est, et bien sûr, cela signifie.
Robin Bloor: Je ne peux pas vous entendre, Eric.
Eric Kavanagh: J'y étais il y a quelques jours, alors tu n'es pas seul. Mais le sujet d’aujourd’hui est vraiment intéressant. C’est le genre de chose que vous voulez faire en sorte qu’il se passe en arrière-plan dans votre entreprise, à moins que vous ne le fassiez, mais dans ce cas, vous voulez vous assurer de le faire correctement. Parce que parlaient de débogage. Personne n'aime les bugs, personne n'aime quand le logiciel cesse de fonctionner - les gens se fâchent, les utilisateurs deviennent hostiles. Ce n'est pas bon. Alors, allions parler de "Réponse rapide: Débogage de base de données et profilage à la rescousse".
Il y a un endroit sur le tien, frappe-moi bien sûr, @eric_kavanagh.
Cette année est chaude. Et le débogage va être chaud, quoi qu'il arrive. C’est vraiment l’un de ces problèmes qui ne disparaîtra jamais, quelle que soit la qualité de notre travail, il y aura toujours des problèmes, donc la clé est de savoir comment arriver à résoudre ces problèmes rapidement. Idéalement, vous avez de grands programmeurs, de très bons environnements, où tout se passe bien, mais comme le dit le vieil adage: «Les accidents se produisent dans les meilleures familles». Et il en va de même pour les organisations. Donc, cela arrive, ça va arriver, la question est quelle sera votre solution pour y faire face et résoudre ces problèmes?
Nous entendrons bien le Dr Robin Bloor, puis notre propre Dez Blanchfield d’en bas, et bien entendu notre bon ami, Bert Scalzo, de l’IDERA. Et en fait, je vais remettre les clés à Robin Bloor, prenez-les. La parole est à vous.
Robin Bloor: D'ACCORD. C'est un sujet intéressant. Parce que Dez va probablement parler des techniques actuelles et des récits de guerre sur le débogage, j’ai pensé que je ferais une discussion de fond pour que nous puissions avoir une image complète de ce qui se passe. Je faisais cela longtemps, et j’étais codeur, c’est comme si, et cette présentation me tentait presque de faire naître des paroles lyriques sur l’idée de l’open source, mais j’ai pensé que Ill laisserais ça à quelqu'un d’autre.
Voici une liste de bugs célèbres, et la plupart d’entre eux figurent en tête de liste des anybodys, tous sauf les deux derniers coûtant au moins 100 millions de dollars. Le premier était l’orbiteur climatique Mars, perdu dans l’espace, à cause d’un problème de codage, où les gens confondaient les unités métriques avec (rires) pieds et pouces. Le vol 501 d’Ariane Five présentait un déséquilibre entre un moteur mis en marche et les ordinateurs censés faire fonctionner la fusée lors de son lancement. Plusieurs pannes d’ordinateur, fusée explosive, gros titres. Gazoduc soviétique en 1982, qui serait la plus grande explosion de l’histoire de la planète; Je ne suis pas sûr que ce soit le cas. Les Russes ont volé un logiciel de contrôle automatisé, et la CIA s'est rendu compte qu'ils allaient le faire et y mettre des bogues, et les Soviétiques l'ont mis en œuvre sans aucun test. Alors, fait sauter un pipeline, trouvé cela amusant.
Le ver Morris était une expérience de codage, qui devint soudainement un ver rapace qui parcourut tous les corps: il causa apparemment des dégâts de 100 millions de dollars; c'est une estimation bien sûr. Intel a fait une erreur célèbre avec une puce mathématique - une instruction mathématique sur la puce Pentium en 1993 - qui devait coûter plus de 100 millions de dollars. Le programme Apple Maps est probablement le pire et le plus désastreux de tous les lancements d’Apple. Les personnes qui ont essayé de l'utiliser étaient, je veux dire, quelqu'un qui conduisait le 101, et ont découvert que la carte Apple Map indiquait qu'elles se trouvaient au milieu de la baie de San Francisco. Les gens ont donc commencé à se référer à l'application Apple Maps comme étant iLost. Notre - la plus longue panne de 1990 -, ce qui est tout à fait intéressant du point de vue du coût de ce genre de choses, est de neuf heures environ et les appels longue distance coûtent environ 60 millions de dollars.
Et j'étais dans une compagnie d’assurance britannique, et la base de données a implémenté une nouvelle version de la base de données qui a commencé à effacer les données. Et je m'en souviens extrêmement bien, car on m'a ensuite appelé à participer à une sélection de bases de données pour cette raison. Et il était très intéressant qu'ils aient pris une nouvelle version de la base de données et qu'ils aient effectué une batterie de tests pour les nouvelles versions de la base de données et qu'ils aient passé tous les tests. Il a trouvé un moyen très obscur pour effacer les données.
Donc, de toute façon, c'est ça. Je pensais que je parlerais de l'inadéquation de l'impédance et du code SQL fourni. Il est intéressant de noter que les bases de données relationnelles stockent des données dans des tables et que les codeurs ont tendance à manipuler des données dans des structures d'objet qui ne correspondent pas vraiment aux tables. Et à cause de cela, vous obtenez ce qu'on appelle le déséquilibre impédance, et quelqu'un doit s'en occuper d'une manière ou d'une autre. Mais que se passe-t-il réellement, car un modèle, le modèle des codeurs et la base de données, un autre modèle, ne sont pas particulièrement alignés. Vous obtenez des bugs qui ne se produiraient tout simplement pas si l'industrie avait construit des choses qui fonctionnent ensemble, ce qui, à mon avis, est hilarant. Ainsi, du point de vue des codeurs, lorsque vous obtenez des hiérarchies, il peut s'agir de types, de résultats, d'aptitudes d'API médiocres, de nombreuses choses qui ne font que jeter des objets en termes d'interaction avec la base de données. Mais la chose qui me tient le plus à cœur est vraiment intéressante. Je suis toujours étonné que vous ayez cette barrière SQL qui soit aussi une sorte d’impédance qui permette aux codeurs et à la base de données de fonctionner ensemble. Donc, SQL a la reconnaissance de données, ce qui est très bien, et DML pour sélectionner, projeter et rejoindre, ce qui est correct. Vous pouvez utiliser beaucoup de possibilités pour extraire des données de la base de données avec cela. Mais il a très peu de langage mathématique pour faire les choses. Il y a un peu de ceci et de cela, et il y a très peu de choses basées sur le temps. Et à cause de cela, SQL est un moyen imparfait, si vous voulez, pour obtenir les données. Ainsi, les gars de la base de données ont construit des procédures stockées pour vivre dans la base de données et la raison pour laquelle les procédures stockées y résidant était que vous ne vouliez pas vraiment envoyer des données à un programme.
Certaines fonctionnalités étant extrêmement spécifiques aux données, il ne s’agissait donc pas que de l’intégrité référentielle, des suppressions en cascade, etc., la base de données s’occupait tout à coup de mettre des fonctionnalités dans une base de données. l'application pourrait être partagée entre le codeur et la base de données elle-même. Et cela rendait la tâche de mettre en œuvre certains types de fonctions vraiment difficile et donc plus sujette aux erreurs. Donc, c’est un côté du jeu de base de données, car cela signifie que vous avez eu beaucoup d’implémentations, par exemple, que j’ai été impliqué dans des bases de données relationnelles, il ya vraiment énormément de code qui se trouve dans des procédures stockées qui est gérée séparément du code se trouve dans les applications. Et cela semble être une chose très étrange, elle est supposée être assez intelligente pour faire diverses choses.
Je pensais qu'Id parlait aussi de performance de base de données car les erreurs de performance sont souvent considérées comme des bugs, mais vous pouvez avoir un goulot d'étranglement au niveau du processeur, de la mémoire, du disque, du réseau et des problèmes de performances à cause du verrouillage. L'idée serait que le codeur n'ait pas vraiment besoin de se préoccuper de la performance et que la base de données fonctionne assez bien. Son supposé être conçu pour que le codeur n'ait pas besoin de savoir. Cependant, vous obtenez une mauvaise conception de base de données, de conception de programme, de concomitance dans le mélange de charge de travail, ce qui peut également entraîner des problèmes de performances. Vous obtenez un équilibrage de charge, une planification de la capacité et une croissance des données, ce qui peut entraîner l’arrêt ou le ralentissement d’une base de données. C'est une chose intéressante, lorsque les bases de données sont presque pleines, elles ralentissent. Et vous pouvez avoir des problèmes de couches de données en termes de réplication et de nécessité de répliquer et de sauvegarde et de récupération. Quoi qu'il en soit, c'est un aperçu général.
La seule chose que je voudrais dire, c'est que le débogage de base de données peut être aussi lourd et non trivial - et je le dis parce que j'en ai fait beaucoup - et vous le découvrirez souvent comme toutes les situations de débogage que j'ai connues est, est la première chose que vous voyez est un désordre. Et vous devez essayer de passer de la pagaille à la recherche de la cause de la pagaille. Et souvent, lorsque vous examinez un problème de base de données, vous examinez uniquement des données corrompues et vous vous dites: "Comment diable est-ce arrivé?"
Quoi qu'il en soit, je vais laisser la parole à Dez, qui va probablement dire plus de paroles de sagesse que ce dont je suis sorti. Je ne sais pas comment te passer le ballon, Dez
Eric Kavanagh: Je vais le passer, restez là, attendez.
Voix automatisée: Les lignes des participants ont été mises en sourdine.
Eric Kavanagh: Très bien, attendez une seconde, laissez-moi donner la balle à Dez.
Dez Blanchfield: Merci Eric. Oui, Docteur Robin Bloor, vous avez tout à fait raison: c’est un sujet, un ennemi de toute une vie si vous pardonnez le jeu de mots, désolé je n’ai pas pu m'en empêcher. J'espère que vous pourrez voir mon premier écran là-bas, mes excuses pour le problème de taille de police en haut. Le sujet des insectes est une leçon d'une journée, souvent dans mon expérience. Son sujet est tellement vaste et vaste, je vais donc mettre l’accent sur deux domaines clés, en particulier le concept de ce que nous considérons comme un bug, mais un problème de programmation. Je pense que ces jours-ci, l’introduction d’un bogue en tant que telle est généralement détectée par les environnements de développement intégrés, même s’il s’agit peut-être de bogues de longue durée. Mais souvent, il s’agit plutôt d’un cas de code de profilage et de son possible d’écrire du code qui fonctionne, ce qui devrait être un bogue. Donc, ma diapositive de titre ici, j’en avais une copie en très haute résolution A3, mais malheureusement, elle a été détruite lors d’un déménagement. Mais il s’agit d’une note manuscrite sur une feuille de programmation datant de 1945 environ, dans laquelle on suppose que des gens de l’Université de Harvard, aux États-Unis, construisent pour la deuxième fois une machine appelée Mark II. Ils étaient en train de résoudre un problème, dans un langage commun, mais ils essayaient de trouver une erreur et il s'est avéré que quelque chose de légèrement différent de ce qui était un matériel et un soi-disant problème de logiciel est apparu.
Donc, le mythe urbain est que vers le 9 septembrethEn 1945, une équipe de l’Université de Harvard était en train de démonter une machine, elle tomba sur quelque chose qu’ils appelaient «relais soixante-dix»: à l’époque, la programmation était faite physiquement, vous enrobiez du code autour d’un tableau, et c’est ainsi que vous programmiez efficacement machine - et ils ont trouvé ce relais numéro soixante-dix, il y avait quelque chose qui n'allait pas, et il s'est avéré que le terme "bogue" est apparu parce que c'était littéralement un papillon de nuit - soi-disant, il y avait un papillon de nuit coincé entre un fil de cuivre d'un endroit à un autre. Et l’histoire raconte que la légendaire Grace Hopper a pour légende, pour ma diapositive de titre, le «premier cas réel de découverte d’un bogue», citation non citée.
Mais comme Robin l'a souligné plus tôt dans sa première diapositive, le concept de bogue remonte aussi loin que l'on puisse imaginer des humains en train de calculer, des concepts comme des correctifs. Le terme «patch» vient d'un morceau de ruban adhésif collé sur un trou d'une carte perforée. Mais l’essentiel, c’est que le terme «débogage» est né de ce concept de recherche d’un bogue dans une machine physique.Et depuis, nous avons utilisé cette terminologie pour tenter de traiter les problèmes, non pas tant comme problèmes de codage dans un programme qui ne compile pas, mais comme programme qui ne fonctionne pas bien. Et spécifiquement, n’a pas été profilé, mais trouvez des choses comme des boucles sans fin qui ne vont nulle part.
Mais nous avons aussi un scénario, et je pensais que Id aurait ajouté quelques diapositives amusantes avant d’entrer un peu plus dans les détails. Voici le dessin classique, appelé XKCD sur le Web, et le dessinateur a des points de vue assez amusants sur le monde. Et celle-ci à propos d'un enfant appelé "Little Bobby Tables" et soi-disant que ses parents l'ont appelé Robert); DROP TABLE Etudiants, - et on l'appelle, et en quelque sorte "Salut, c'est l'école de ton fils qui a des problèmes informatiques", et le parent répond: "Oh, mon Dieu, a-t-il cassé quelque chose?" Et l'enseignant a répondu: "Eh bien, d’une certaine manière », demande l’enseignant,« as-tu vraiment appelé ton fils Robert); DROP TABLE Etudiants, -? »Et le parent dit:« Oh oui, nous l'appelons comme ça, les petites tables de Bobby. »Quoi qu'il en soit, ils continuent en disant qu'ils ont maintenant perdu les années de leur dossier étudiant, j'espère que vous êtes heureux. Et la réponse est: «Eh bien, vous devriez nettoyer et désinfecter les entrées de votre base de données.» Et je l’utilise souvent pour parler de certains problèmes que nous rencontrons pour trouver des éléments dans le code, qui souvent ne se penche pas sur les données. .
Un autre drôle, je ne sais pas si c'est vrai ou pas - je soupçonne que c'est une parodie - mais encore une fois, ça touche aussi mon drôle d'os. Quelqu'un remplace la plaque d'immatriculation à l'avant de son véhicule par une déclaration similaire provoquant la chute de bases de données dans des radars automatiques, etc. capturant les plaques d'immatriculation des voitures. Et je me réfère toujours à cela comme à un doute que tout programmeur ait anticipé le succès de son code par un véritable véhicule automobile, mais je ne sous-estime jamais cela - le pouvoir d'un geek en colère.
(Rire)
Mais cela m'amène à mon point essentiel, je suppose, c'est qu'il était une fois, nous pourrions déboguer et profiler le code en tant que simples mortels. Mais je suis tout à fait convaincu que ce temps a passé et, de façon anecdotique, le premier - et cela m’a terriblement vieilli, j'en suis sûr; Robin, tu es le bienvenu pour me moquer de ça - mais historiquement, je viens d'un milieu à 14 ans errant au bout de la ville, et frappant à la porte d'un centre de données appelé "Data Com" en Nouvelle-Zélande et demandant si Je pouvais gagner de l’argent de poche à l’école en ramenant le bus tard dans la maison, environ 25 km de trajet tous les jours, en mettant du papier, des cassettes dans des lecteurs de cassettes et en étant simplement un administrateur général. Et curieusement, ils m'ont donné un travail. Mais au fil du temps, j'ai réussi à me trouver dans la dotation en personnel et à trouver les programmeurs et me suis rendu compte que j'aimais le codage et que je passais par le processus d'exécution de scripts et de travaux par lots, qui en fin de compte est toujours du code. Vous devez écrire des scripts et des travaux par lots qui ressemblent à des mini-programmes, puis suivre tout le processus d’assise manuelle sur un terminal 3270.
En fait, ma toute première expérience a été réalisée avec un terminal de télétype, qui était en réalité un physique de 132 colonnes. Essentiellement, pensez à une très vieille machine à écrire avec du papier qui défilait, car ils n’avaient pas de tube cathodique. Et le débogage de code là-dessus n’était pas une mince affaire, alors vous aviez tendance à écrire tout votre code à la main, puis à agir comme un dactylographe, en faisant de votre mieux pour éviter les erreurs, car c’est extrêmement frustrant de devoir le dire. l’éditeur d’une ligne pour aller à une ligne donnée, puis la ligne et la taper ensuite. Mais jadis, c’était comme ça que nous écrivions du code et c’est ainsi que nous déboguions, et nous avons vraiment très bien réussi. Et en fait, cela nous a obligé à avoir de très bonnes techniques de programmation, car ce fut un vrai problème de le réparer. Mais le voyage a ensuite pris fin - et connaissait tous cela - il est passé de l'expérience du terminal 3270 dans mon monde à Digital Equipment VT220 où vous pouviez voir des choses à l'écran, mais encore une fois, vous faisiez la même chose que vous avez fait sur la bande de papier, un format éd juste sur un tube cathodique, mais vous pouviez supprimer plus facilement et vous n’aviez pas ce son "dit dit dit dit".
Et puis, vous savez, les terminaux Wyse - comme le Wyse 150, sont probablement mon interface préférée pour un ordinateur de tous les temps -, puis le PC, puis le Mac, et maintenant ces GUI et ID modernes basés sur le Web. Et une gamme de programmes à travers cela, la programmation en un seul et assembleur et PILOT et Logo et Lisp et Fortran et Pascal et les langages qui pourraient faire cracher les gens. Mais ce sont des langues qui vous ont obligé à écrire du bon code; ils ne vous ont pas laissé sortir avec de mauvaises pratiques. C, C ++, Java, Ruby, Python - et nous avançons dans l’étape de la programmation, nous nous rapprochons davantage du type script, nous nous rapprochons de plus en plus du langage de requête structuré et de langages tels que PHP, qui sont en fait utilisés pour appeler SQL. En me fondant sur mon expérience, je suis un autodidacte à bien des égards. Ceux qui m’ont aidé à apprendre, m’ont appris de très bonnes pratiques de programmation et de très bonnes pratiques en matière de conception et de processus pour ne pas avoir introduit le buggy. code.
Les méthodes de programmation actuelles, telles que, par exemple, Structured Query Language, SQL, sont des langages de requête très puissants et simples. Mais nous l’avons transformé en un langage de programmation et je ne crois pas vraiment que SQL ait jamais été conçu pour être un langage de programmation moderne, mais nous l’avons biaisé pour le devenir. Et cela introduit toute une série de problèmes, ce qui pose problème lorsque nous réfléchissons à deux points de vue: du point de vue du codage et du point de vue du DBA. Il est très facile de venir et de présenter des bogues pour des choses comme des techniques de programmation médiocres, des efforts paresseux pour écrire du code, un manque d'expérience, la bête noire que j'ai, par exemple, avec des personnes SQL qui sautent sur Google et cherchent quelque chose et trouvent un site Web. obtenu un exemple et faire un copier / coller du code existant. Et ensuite, reproduire un mauvais code, une mauvaise pratique et le mettre en production, car il se trouve que cela leur donne les résultats souhaités. Vous avez eu d’autres défis, par exemple, ces jours-ci se précipitaient tous vers ce que nous appelons la «course à zéro»: essayer de faire tout ce qui est si bon marché et si vite, que nous avons un scénario dans lequel nous n’employons pas d’employés moins bien payés. Et je ne le dis pas de manière malhonnête, mais n’engageais pas d’experts pour chaque travail possible. Il était une fois tout ce qui concernait les ordinateurs: la science de la fusée. il s'agissait de choses qui allaient très fort, ou allaient dans l'espace ou les ingénieurs étaient des hommes et des femmes hautement qualifiés qui avaient fait des diplômes et avaient suivi une formation rigoureuse qui les empêchait de faire des choses folles.
De nos jours, beaucoup de gens qui se lancent dans le développement, la conception et la base de données sans avoir des années d’expérience, n’ont pas nécessairement suivi la même formation ou le même soutien. Et si vous terminez avec un scénario de l'amateur traditionnel versus expert. Et il y a une phrase célèbre, je ne me souviens pas vraiment qui a créé la citation, elle dit: «Si vous pensez que le fait d'embaucher un expert pour faire un travail coûte cher, attendez que vous engagiez un couple d'amateurs qui créent un problème et vous devez nettoyez-le. ”Et SQL a donc ce problème, et il est très très facile à apprendre, très facile à utiliser. Mais ce n'est pas, à mon avis, un langage de programmation parfait. Il est très facile de faire des choses comme faire une étoile de choix où que vous soyez et insérer tout cela dans un langage de programmation avec lequel vous êtes plus à l'aise que PHP, Ruby ou Python, et utiliser le langage de programmation avec lequel vous êtes naturellement familiarisé pour la manipulation des données. plutôt que de faire une requête plus complexe en SQL. Et nous voyons cela souvent, puis les gens se demandent pourquoi la base de données est lente; c’est parce qu’un million de personnes essaient d’acheter un billet via un système de billetterie en ligne, dans lequel une star sélectionnée de n'importe où.
C’est un exemple vraiment extrême, mais vous comprenez tout cela. Donc, pour vraiment marquer ce point à la maison, voici un exemple que je porte beaucoup. Je suis un grand fan de maths, j'adore la théorie du chaos, j'aime les décors de Mandelbrot. A droite, une interprétation de l'ensemble de Mandelbrot, avec laquelle je connaissais tous. Et à gauche, il y a un morceau de SQL qui rend cela. Maintenant, chaque fois que je mets cela quelque part sur un écran, j'entends ceci: «Oh mon dieu, quelqu'un a rendu la série Mandelbrot avec SQL, êtes-vous sérieux? C'est fou! »Eh bien, le but de tout cela est d'illustrer ce que je viens de décrire, et c'est oui, en fait, vous pouvez maintenant programmer presque tout en SQL; c'est un langage de programmation moderne très puissant, puissant et très développé. Lorsqu'il était à l'origine un langage de requête, il était conçu pour obtenir uniquement des données. Donc, maintenant, nous avons des constructions très complexes et des procédures stockées, nous appliquons la méthodologie de programmation à un langage et il est donc très facile en cas de pratique de programmation médiocre, de manque d’expérience, de code copier-coller, d’employés mal payés être des employés bien payés, des gens qui font semblant de savoir, mais qui doivent apprendre sur le tas.
Toute une série de choses où le profilage de code et ce que nous appelons le débogage, ce n'est pas tant la recherche de bogues qui empêchent les programmes de fonctionner, mais des bugs qui ne font que nuire au système et à un code mal structuré. Quand vous regardez cet écran maintenant, et que vous pensez que c'est juste, c'est un peu mignon et que vous vous dites: «Waouh, quel graphisme génial, j'adorerais le faire.» Mais imaginons que ce soit basé sur une logique de gestion. Cela a l'air sympa, mais cela parle d'une théorie du chaos mathématiquement rendue graphiquement, mais quand vous réfléchissez à ce à quoi elle pourrait potentiellement être utilisée dans une logique métier, vous obtenez l'image très rapidement. Et pour bien illustrer cela - et je suis désolé, les couleurs sont inversées, il est supposé être un fond noir et le vert doit être un écran vert, mais vous pouvez toujours le lire.
J’ai jeté un rapide coup d’œil à un exemple de ce que vous pourriez faire si vous étiez vraiment fou et n’aviez aucune expérience de la sorte et que vous veniez d’un contexte de programmation différent et que j’appliquais C ++ en SQL, pour bien illustrer mon propos, avant de commencer. Je passe la parole à notre éminent invité d'IDEA. Ceci est une requête structurée écrite comme C ++, mais codée en SQL. Et il s’exécute en réalité, mais sur une période de trois à cinq minutes environ. Et il extrait ostensiblement une ligne de données de plusieurs bases de données, plusieurs jointures.
Encore une fois, l’essentiel est que si vous n’avez pas les outils adéquats, si vous n’avez pas les plates-formes et les environnements adéquats pour capturer ces choses, et qu’ils entrent en production, vous avez alors 100 000 personnes qui utilisent un système tous les jours. jour, heure ou minute, très vite, vous vous retrouvez avec une expérience de Tchernobyl où le gros fer commence à fondre et à s’enfouir au cœur de la planète, car ce morceau de code ne devrait jamais entrer en production. Vos systèmes et vos outils, excusez-moi, devraient en prendre connaissance avant qu’ils ne se rapprochent du processus de test, et même de l’UAT et de l’intégration des systèmes, ce morceau de code doit être récupéré et mis en évidence, et quelqu'un doit être mis de côté et en disant: «Regardez, c'est du code vraiment joli, mais demandons à un DBA de vous aider à construire correctement cette requête structurée, parce que franchement, c'est tout simplement désagréable." Et les URL ici, vous pouvez y jeter un coup d'œil - c'est ce qu'on appelle le la requête SQL la plus complexe que vous ayez écrite. Parce que crois-moi, ça compile, ça marche. Et si vous coupez et collez cela et que vous ne faites que simuler la base de données, c'est tout à fait à surveiller; Si vous disposez des outils nécessaires pour regarder la base de données, essayez de le faire fondre sur une période de trois à cinq minutes pour rappeler une ligne de.
Donc, pour résumer, dans cet esprit, tout mon expérience en codage m'a appris que vous pouvez donner une arme à feu aux gens et que s'ils ne font pas attention, ils se tireront une balle dans le pied; L'astuce consiste à leur montrer où se trouve le mécanisme de sécurité. Avec les bons outils et le bon logiciel à portée de main, une fois le codage effectué, vous pouvez réviser votre code, vous pouvez détecter les problèmes en profilant le code, vous pouvez rechercher efficacement des bogues non intentionnels qui constituent des problèmes de performances, et comme je l'ai dit précédemment Il était une fois, vous pouviez le faire en regardant un écran vert. Vous ne pouvez plus; il existe des centaines de milliers de lignes de code, des dizaines de milliers d'applications déployées, des millions de bases de données dans certains cas, et même les super-humains ne peuvent plus le faire à la main. Vous avez littéralement besoin du bon logiciel et des bons outils à portée de main et vous avez besoin que l'équipe utilise ces outils pour pouvoir trouver ces problèmes et les résoudre très, très rapidement, avant que le point Robin Bloor a souligné que les choses devenaient désastreuses et que les choses explosaient, ou plus généralement, elles commençaient à vous coûter beaucoup d’argent, beaucoup de temps et d’efforts, et à détruire le moral et autres, quand elles ne peuvent pas comprendre pourquoi cela prend beaucoup de temps à courir.
Et, gardant cela à l’esprit, je vais laisser la parole à notre invité et j’ai hâte d’entendre comment ils ont résolu ce problème. Et particulièrement la démo que je pense qui était sur le point de recevoir. Eric, je reviens.
Eric Kavanagh: OK, Bert, emporte-le.
Bert Scalzo: D'accord, merci. Bert Scalzo, de IDERA, est le chef de produit de nos outils de base de données. Et je vais parler de débogage. Je pense que l’une des choses les plus importantes que Robin ait dites plus tôt - et c’est vrai, que le débogage est onéreux et non trivial, et lorsque vous passez à la base de données, le débogage est un ordre de grandeur encore plus lourd et non trivial - était une citation importante.
D'ACCORD. Je voulais commencer par l’historique de la programmation, car souvent, je vois des personnes qui ne font pas de débogage, elles n’utilisent pas de débogueur, elles programment simplement avec la langue qu’elles utilisent et, très souvent, elles me disent: ces outils de débogage sont nouveaux et nous n’avons pas encore commencé à les utiliser. »C’est pourquoi je leur montre ce tableau chronologique, une sorte de préhistoire, la vieillesse, le moyen âge, son genre de dire où nous étions. termes de langages de programmation. Et nous avons eu de très vieilles langues à partir de 1951 avec le code assembleur, ainsi que Lisp et FACT et COBOL. Nous passons ensuite au groupe suivant, Pascals and Cs, puis au groupe suivant, les C ++, et cherchons où se trouve ce point d'interrogation - ce point d'interrogation se situe approximativement de 1978 à peut-être 1980. Quelque part dans cette gamme nous avions les débogueurs disponibles pour nous, et pour ainsi dire, "Hey, je n'utilise pas de débogueur, parce que c'est une de ces nouvelles choses", alors vous devez avoir commencé à programmer, vous savez, dans les années 1950, parce que c'est le seul moyen de vous obtenir loin avec cette revendication.
Dez vient de faire un commentaire à propos de Grace Hopper. Je connaissais bien Grace, donc c’est assez drôle. Et puis l’autre chose qui m’a fait rire, c’est qu’il a parlé de télétypes et que je restais assis là: «Mec, c’est le plus grand saut que nous ayons jamais fait en termes de productivité, lorsque nous sommes passés des cartes aux télétypes, c’était le plus grand saut de tous les temps." , et j’ai programmé dans toutes les langues ici, y compris SNOBOL, dont personne n’avait jamais entendu parler auparavant, c’était une CDC, Control Data Corporation, donc je suppose que je deviens un peu trop vieux pour cette industrie.
Dez Blanchfield: J'allais dire, vous nous avez terriblement vieillis là.
Bert Scalzo: Oui, je te le dis, je me sens comme mon grand-père Simpson. Donc, je regarde le débogage et il y a différentes façons de le déboguer. Vous pourriez parler de ce que nous pensons tous comme étant traditionnel, entrer dans un débogueur et parcourir le code. Mais aussi, les gens vont instrumentaliser leur code; C’est là que vous collez des instructions dans votre code et peut-être que vous produisez un fichier de sortie, un fichier de trace ou quelque chose de ce genre, et que vous instrumentez votre code. Je considérerais cela comme un débogage, c’est un peu plus difficile, une façon de le faire, mais ça compte. Mais aussi, nous avons la déclaration célèbre: vous regardez et les gens insèrent des déclarations et j’ai effectivement vu un outil dans lequel - et c’est un outil de base de données - dans lequel, si vous ne savez pas utiliser un débogueur, vous appuyez sur un bouton qui reste enfoncé déclarations tout au long de votre code pour vous et puis lorsque vous avez terminé, vous appuyez sur un autre bouton et il les supprime. Parce que beaucoup de gens déboguent.
Et la raison pour laquelle nous avons débogué est double: premièrement, nous devons trouver des éléments qui rendent notre code inefficace. En d’autres termes, cela signifie généralement qu’il s’agit d’une erreur de logique ou que nous avons manqué une exigence professionnelle, mais c’est que le code n’est pas efficace; il ne fait pas ce que nous nous attendions à faire. L'autre fois, nous procédons au débogage, pour des raisons d'efficacité et cela pourrait être une erreur de logique, mais ce que c'est, c'est que j'ai fait ce qu'il fallait, cela ne revient tout simplement pas assez vite. Maintenant, je fais valoir ce point, car les profileurs seraient probablement meilleurs pour ce deuxième scénario et allaient parler à la fois des débogueurs et des profileurs. En outre, theres ce concept de débogage à distance; c’est important parce que souvent, si vous êtes assis sur votre ordinateur personnel et utilisez un débogueur, cela frappe une base de données où le code est réellement exécuté sur la base de données, vous effectuez ce que l’on appelle le débogage distant. Vous ne le réaliserez peut-être pas, mais c'est ce qui se passe. Et puis, il est très commun avec ces débogueurs d’avoir des points de rupture, des points de vue, d’intervenir et d’autres choses courantes, que je vais montrer à ceux-ci sur un instantané.
Profilage: vous pouvez le faire de différentes manières. Certaines personnes diront que la charge de travail capture et rejoue où elle capture tout, que cela compte comme profilage. Mon expérience a été meilleure si son échantillonnage est fait. Il n’ya aucune raison de saisir chaque déclaration, car certaines déclarations risquent de courir si vite que vous ne vous en souciez pas. Ce que vous essayez vraiment de voir, c’est bien ce sont celles qui reviennent sans cesse, car elles durent trop longtemps. . Ainsi, parfois, profiler peut signifier échantillonnage plutôt que de tout exécuter. Et en général, vous obtiendrez une sorte de sortie que vous pouvez utiliser, qui pourrait maintenant être visuelle à l'intérieur d'un environnement de développement IDE, où elle pourrait vous donner l'aspect d'un histogramme des performances des différentes lignes de code, mais cela pourrait également soyez qu'il produit un fichier de trace.
Les profilers sont apparus pour la première fois en 1979. Ils existent donc aussi depuis longtemps. Idéal pour résoudre les problèmes de consommation de ressources ou de performances, autrement dit, cette efficacité. De manière générale, il est distinct et distinct du débogueur, même si j’ai travaillé avec des débogueurs effectuant les deux à la fois. Et bien que les profileurs soient, à mon avis, les plus intéressants des deux outils, si j’ai le sentiment que trop peu de personnes déboguent, il est clair qu’il n’ya pas assez de profil de personnes, car un débogueur sur dix profilera, semble-t-il. Et c'est dommage, car le profilage peut vraiment faire une énorme différence. Maintenant, les langages de base de données, comme nous l’avons mentionné plus tôt, vous avez le SQL - et nous avons en quelque sorte forcé la cheville ronde dans le trou carré et l’obligé à devenir un langage de programmation - et Oracle.Thats PL / SQL - thats langage procédural SQL - et SQL Server, son Transact-SQL, son SQL-99, son SQL / PSM - pour, je pense, son module stocké de procédure. Postgres lui donne un autre nom, DB2 et un autre, Informix, mais tout le monde a forcé les constructions de type 3GL; autrement dit, les boucles FOR, les déclarations de variable et tous les autres éléments étrangers à SQL font maintenant partie de SQL dans ces langages. Ainsi, vous devez être en mesure de déboguer un fichier PL / SQL ou Transact-SQL comme vous le feriez avec un programme Visual Basic.
Maintenant, objets de base de données, c'est important parce que les gens vont dire: «Qu'est-ce qu'il me faut pour déboguer dans une base de données?» Et la réponse est, eh bien, tout ce que vous pouvez stocker dans la base de données sous forme de code - si je fais T- SQL, ou PL / SQL - et Im stockant des objets dans la base de données, il s’agit probablement d’une procédure stockée ou d’une fonction stockée. Mais il y a aussi des déclencheurs: un déclencheur est un peu comme une procédure stockée, mais il déclenche un événement. Maintenant, certaines personnes dans leurs déclencheurs mettront une ligne de code et appelleront une procédure stockée afin de conserver tout leur code et toutes leurs procédures stockées, mais c'est le même concept: son déclencheur pourrait être ce qui déclenche tout. Et puis comme Oracle, ils ont ce qu’on appelle un paquet, qui est un peu comme une bibliothèque si vous voulez. Vous mettez 50 ou 100 procédures stockées dans un même groupe, appelé package, ce qui en fait une sorte de bibliothèque. Alors, voici le débogueur à l'ancienne; c'est en fait un outil qui va réellement coller toutes ces instructions de débogage dans votre code pour vous. Ainsi, partout où vous voyez un bloc de débogage, ne supprimez pas, le démarrage et la trace automatiques du débogueur, ceux-ci étaient tous bloqués par un outil. Et les lignes en dehors de cela, qui sont la minorité du code, eh bien, c’est la méthode de débogage non manuelle.
Et la raison pour laquelle j’en parle est que, si vous essayez de le faire à la main, vous allez réellement taper plus de code de débogage pour mettre toutes ces déclarations que vous ne l’êtes avec le code. Donc, bien que cela puisse fonctionner, et bien que ce soit mieux que rien, c’est un moyen très difficile de déboguer, d’autant plus que se passe-t-il si cela prend 10 heures pour que cette chose soit exécutée, et où il ya un problème en troisième ligne? Si je faisais une session de débogage interactive, j'aurais su à la ligne trois ou cinq minutes - hé, il y a un problème ici, je peux arrêter. Mais avec cela, je dois attendre son exécution complète, puis j’ai besoin d’examiner un fichier de trace contenant probablement toutes ces déclarations et d’essayer de trouver l’aiguille dans la botte de foin. Encore une fois, cela vaut mieux que rien, mais ce ne serait pas la meilleure façon de travailler. Maintenant, voici à quoi ce fichier ressemblerait qui provenait de la diapositive précédente; En d’autres termes, j’ai exécuté le programme et il vient de recevoir un grand nombre d’énoncés dans ce fichier de trace et je peux ou non être en mesure de siphonner et de trouver ce que j’ai besoin de trouver. Donc, encore une fois, je ne suis pas sûr que ce soit la façon dont vous voudriez travailler.
Maintenant, les débogueurs interactifs - et si vous utilisiez quelque chose comme Visual Studio pour écrire des programmes, ou Eclipse, vous aviez des débogueurs et que vous les utilisiez avec vos autres langues - ne pensiez pas simplement les utiliser ici avec votre base de données. Et il existe des outils, tels que notre base de données Artisan et notre base de données SQL, il s'agit de Rapid SQL ici, qui ont un débogueur, et vous pouvez voir sur le côté gauche, j'ai une procédure stockée appelée "vérifier les doublons". En gros, ça va juste aller voir et voir si j'ai plusieurs lignes dans la table avec le même titre de film. Donc, la base de données est pour les films. Et vous pouvez voir sur le côté droit, sur le tiers supérieur, que j'ai mon code source au milieu, sur ce que l’on appelle mes variables de surveillance et sur mes plateaux d’appel, puis sur le bas, sur quelques sorties. Et ce qui est important ici, si vous regardez par-dessus la première flèche rouge, si je passe la souris sur une variable, je peux réellement voir quelle est la valeur de cette variable à ce moment-là, lorsque Im parcourt le code. Et c’est vraiment utile, et ensuite je peux parcourir une ligne à la fois dans le code, je n’ai pas à dire exécuter, je pourrais dire étape par ligne, laissez-moi regarder ce qui s’est passé, avancez d’une autre ligne, laissez-moi voir ce qui est arrivé, et Je fais cela dans la base de données. Et même si je suis assis sur Rapid SQL sur mon PC et que ma base de données est stockée dans le cloud, je peux toujours effectuer ce débogage à distance, le visualiser et le contrôler à partir d’ici, ainsi que le débogage comme je le ferais avec n’importe quel autre langage.
Maintenant, la prochaine flèche là-bas - vous pouvez voir la petite flèche semblable à celle-ci pointant vers la droite, vers cette sortie de SGBD, c’est là où se trouve mon curseur - c’est-à-dire que j’ai marché et que c’est là où j’en suis. Donc, si je dis, "Pas encore", je vais aller à la ligne suivante. Maintenant, juste en dessous, vous verrez le point rouge. Eh bien, c’est un point d’arrêt qui dit: "Hé, je ne veux pas franchir ces lignes." Si je veux juste sauter par-dessus tout et arriver à où ce point rouge, je peux appuyer sur le bouton Exécuter et tout ira de là à la fin, ou à un point d'arrêt, s'il y a des points d'arrêt définis, puis il s'arrêtera et me laissera faire le pas à nouveau. Et la raison pour laquelle tout cela est important et puissant, c’est parce que lorsque je fais tout cela, ce qui se passe au milieu et même au bas - mais surtout au milieu - va changer et je peux voir les valeurs de mes variables, je peux voyez ma trace d'appel, vous savez, et ainsi toute cette information y est affichée lorsque je suis en train de parcourir le code pour que je puisse réellement voir, ressentir et comprendre le fonctionnement du code et son fonctionnement au moment de l'exécution . Et typiquement je peux trouver un problème, s’il y en a un, ou si je suis assez bon pour l’attraper.
OK, maintenant je vais parler d'un profileur, et dans ce cas, c'est un profileur que je peux voir à travers un débogueur. Rappelez-vous, j'ai dit que parfois ils sont séparés et parfois ils peuvent être ensemble? Dans ce cas, et encore, je suis en Rapid SQL, et je peux voir une marge, sur le côté gauche, à côté des numéros de ligne. Et ce que c'est, c'est le nombre de secondes ou de microsecondes qu'il a fallu pour exécuter chaque ligne de code, et je peux le voir clairement, tout mon temps est passé dans cette boucle FOR où Im sélectionne tout dans une table. Et donc, ce qui se passe à l'intérieur de cette boucle FOR est probablement quelque chose que je dois regarder, et si je peux l'améliorer, cela rapportera des dividendes. Je ne vais pas obtenir d'amélioration en travaillant sur ces lignes qui ont 0.90 ou 0.86; il n'y a pas beaucoup de temps passé là-bas. Maintenant, dans ce cas, et encore, dans Rapid SQL, vous voyez comment je peux faire du profilage en étant mélangé à mon débogage. Maintenant, ce qui est bien, c'est que Rapid SQL vous permet également de le faire dans l'autre sens. Rapid SQL vous permet de dire: «Vous savez quoi? Je ne veux pas être dans le débogueur, je veux juste l'exécuter, puis je veux regarder graphiquement ou visuellement le même type d'informations. ”
Et vous pouvez voir que je ne suis plus dans le débogueur et qu'il exécute le programme et une fois l'exécution terminée, il me donne des graphiques pour me dire des choses afin que je puisse voir que j'ai une déclaration qui ressemble à celle-ci qui prend presque toute la place. et si je regarde, je vois sur cette grille vers le bas, ligne 23, la boucle FOR à nouveau: c'est lui qui prend le plus de temps, il est en fait que le rouge sombre grignote tout le camembert. Et donc, c'est une autre façon de faire du profilage. Nous appelons cela «analyste de code» dans notre outil. Mais c'est fondamentalement juste un profileur séparé d'un débogueur. Certaines personnes aiment le faire de la première façon, d'autres aiment le faire de la deuxième manière.
Pourquoi faisons-nous le débogage et le profilage? Ce n'est pas parce que nous voulons écrire le meilleur code du monde et obtenir une augmentation de salaire - cela pourrait être notre raison, mais ce n'est pas vraiment la raison pour laquelle vous le faites - vous avez promis à l'entreprise que vous feriez quelque chose correctement, que votre programme serait efficace. C’est ce pour quoi vous utiliserez le débogueur. En outre, les utilisateurs finaux de l'entreprise; ils ne sont pas très patients: ils veulent des résultats avant même d'appuyer sur la touche. Étaient censés lire dans leurs pensées et tout faire instantanément. En d'autres termes, il faut que ce soit efficace. Et c’est pour cela que nous utiliserions le profileur. Maintenant, sans ces outils, je crois vraiment que vous êtes ce gars en costume d'affaires avec l'arc et la flèche et que vous tirez sur la cible et que vous avez les yeux bandés. Parce que comment allez-vous trouver comment un programme s'exécute simplement en regardant du code statique et comment allez-vous déterminer quelle ligne est l'endroit où il passerait le plus de temps, encore une fois, en regardant simplement du code statique? Une révision de code peut ou non révéler certaines de ces choses, mais rien ne garantit qu’une révision de code les trouverait toutes. En utilisant un débogueur et un profileur, vous devriez pouvoir trouver tous ces bogues.
OK, je vais juste faire une vraie démo ici. Ce n’est pas mon intention de promouvoir un produit, je veux simplement vous montrer à quoi ressemble un débogueur car souvent, les gens diront: «Je n’en ai jamais vu un auparavant.» Et cela semble joli dans les diapositives, les diapositives, ça ressemble quand il est en mouvement? Donc, ici sur mon écran, je lance notre produit DB Artisan; nous avons aussi un débogueur. La base de données Artisan est davantage destinée aux administrateurs de base de données, la base de données Rapid SQL est davantage destinée aux développeurs, mais j'ai déjà vu des développeurs qui utilisent DB Artisan et j'ai déjà vu des administrateurs de base de données utiliser Rapid. Alors, ne vous laissez pas prendre au produit. Et ici, j'ai le choix de faire un débogage, mais avant de lancer le débogage, je vais extraire ce code afin que vous puissiez voir à quoi ressemble le code avant de commencer à l'exécuter. Donc, voici le même code qui était dans la capture d'écran, ceci est mon chèque pour les doublons. Et je veux déboguer ceci, donc je presse déboguer. Et maintenant, cela prend un moment et vous dites: «Eh bien, pourquoi cela prend-il un moment?» Rappelez-vous le débogage à distance: le débogage se produit réellement sur mon serveur de base de données, pas sur mon PC. Donc, il devait passer par là et créer une session là-bas, créer un truc de débogage distant, raccorder ma session à cette session de débogage distant et configurer un canal de communication.
Donc, maintenant, voici ma flèche, elle est en haut, par la première ligne, c'est où je suis dans le code. Et si j'appuie sur la troisième icône, qui constitue une étape dans, vous verrez que la flèche vient de bouger, et si je continue à l'appuyer, vous la verrez continuer à avancer. Maintenant, si je voulais aller jusqu'au bout de cette boucle FOR, parce que je sais que le problème est là, je peux définir un point d'arrêt. Je pensais avoir réglé ça. Oh shoot, j'avais une de mes clés de capture d'écran mappée sur la même clé que le débogueur, c'est ce qui cause la confusion. OK, donc je viens de définir manuellement un point d'arrêt là-bas, donc maintenant, au lieu de faire une étape, étape par étape, jusqu'à ce que j'y arrive, je peux simplement dire: «Vas-y, lance cette chose», et ça s'arrêtera. Notez que cela m’a déplacé jusqu’au point de rupture. Je suis maintenant prêt à exécuter cette boucle. Je peux voir à quoi toutes mes variables sont définies, ce qui n’est pas une surprise, car je les ai toutes initialisées à zéro. Et maintenant, je peux entrer dans cette boucle et commencer à regarder ce qui se passe à l'intérieur de cette boucle.
Donc, maintenant, il va faire un compte choisi parmi mes locations et je peux passer la souris sur ce gars-là et regarder, hs deux, deux est supérieur à un, donc il va probablement faire la prochaine partie de ce code. En d'autres termes, il a trouvé quelque chose. Je vais juste aller de l'avant et laisser ça courir. Je ne veux pas passer par tout ici; Ce que je veux vous montrer, c’est qu’un débogueur terminé, il se termine comme un programme normal. Le point d'arrêt est défini, alors lorsque j'ai dit courir, il est simplement retourné au point d'arrêt suivant. Je le laisse courir jusqu'au bout, car ce que je veux que vous voyiez, c'est qu'un débogueur ne change pas le comportement du programme: quand il est terminé, je devrais obtenir exactement le même résultat si je ne l'avais pas exécuté dans un débogueur.
Et avec cela, je vais suspendre la démo et revenir en arrière parce que nous voulons nous assurer que nous avons le temps pour les questions et réponses. Et donc, je vais l'ouvrir pour des questions et des réponses.
Eric Kavanagh: Ok, Robin, peut-être une question de votre part et ensuite un couple de Dez?
Robin Bloor: Oui, bien sûr, je trouve cela fascinant, bien sûr. J'ai travaillé avec des choses comme ça, mais je n'ai jamais travaillé avec quelque chose comme ça dans la base de données. Pouvez-vous me donner une idée de l'utilisation du profileur par les utilisateurs? Parce que c'est comme s'ils regardaient - parce que je suppose qu'ils le font - ils se penchent sur des problèmes de performances, est-ce que cela va vous aider à faire la différence entre une base de données et un code?
Bert Scalzo: Vous savez, c'est une question fantastique. Disons que je travaille dans Visual Basic et que, dans mon Visual Basic, je vais appeler un Transact-SQL ou un PL / SQL. Laissez-moi faire le PL / SQL, car Oracle ne joue pas toujours bien avec les outils Microsoft. Je suis peut-être en train de profiler mon code Visual Basic, et celui-ci peut indiquer: «Hé, j’ai appelé cette procédure stockée et cela a pris trop de temps.» Mais je peux ensuite accéder à la procédure stockée et créer un profil de base de données sur la base de données stockée. procédez comme suit et dites: «OK, sur les 100 déclarations qui sont ici, voici les cinq causes du problème.» Vous devrez donc peut-être créer une équipe de balises, où vous devrez utiliser plusieurs profileurs.
L'idée est que si jamais on vous dit que le problème de performances se trouve dans votre base de données, un profil de base de données peut vous aider à trouver l'aiguille dans la botte de foin sur laquelle les déclarations sont réellement celles qui posent problème. Je vous dis une autre chose qui est apparue avec le profilage: si vous avez un morceau de code qui est appelé un million de fois, mais cela ne prend qu'une microseconde chaque million, mais il est appelé un million de fois, ce que le profileur montrerait , cette chose a fonctionné pendant autant d’unités de temps. Ainsi, bien que le code puisse être très efficace, vous pouvez regarder et dire: «Ooh, appelions trop souvent ce code. Peut-être devrions-nous ne l'appeler que de temps en temps, plutôt que chaque fois que nous traitons un enregistrement »ou quelque chose du genre. Et vous pouvez donc réellement trouver un code efficace appelé trop souvent et qui pose un problème de performances.
Robin Bloor: Ouais, c'est merveilleux. Je n'ai jamais fait ça. Vous voyez, bien sûr, lorsque j’avais des problèmes de base de données, c’était comme si j’avais affaire à une base de données ou à du code; Je ne pourrais jamais traiter avec les deux en même temps. Mais là encore, je n’ai pas fait de - Je n’ai jamais participé à la création d’applications contenant des procédures stockées, je suppose donc que je n’ai jamais rencontré de problèmes qui me rendaient folle, l’idée de scinder le code entre une base de données et un programme. Mais alors, faites tout ... je suppose que les réponses seront oui, mais cela fait partie d'une activité de l'équipe de développement, lorsque vous essayez, d'une manière ou d'une autre, de réparer quelque chose qui ne fonctionne pas, ou peut-être d'essayer de créer une nouvelle application. Mais tout cela est-il adapté à tous les autres composants que j'attendrais de l'environnement? Puis-je m'attendre à pouvoir l'associer à tous mes packs de test et à tous les autres éléments que je ferais et à ceux liés à la gestion de projet, est-ce ainsi que tous ces éléments sont réunis?
Bert Scalzo: Ouais, cela peut faire partie de tout processus structuré pour faire vos efforts de programmation ou de développement. Et c’est drôle, la semaine dernière, un client était en train de créer une application Web. Leur base de données était historiquement petite et le fait qu’ils ne soient pas de très bons programmeurs ne leur a jamais fait de mal. Eh bien, leur base de données a grandi au fil des ans, et maintenant cela prend 20 secondes dans une page Web, entre le moment où vous dites «Connectez-vous et donnez-moi des données à voir» et le moment où l'écran s'affiche réellement. un problème de performance. Et ils savaient que le problème ne se posait pas dans leurs Java ou autres. Mais ils avaient des milliers de procédures stockées et ils ont donc dû commencer à les profiler pour savoir pourquoi cette page Web prend 20 secondes à s'afficher. Et nous avons effectivement constaté qu’ils avaient un joint cartésien dans l’une de leurs déclarations sélectionnées et ne le savaient pas.
Robin Bloor: Sensationnel.
Bert Scalzo: Mais quelqu'un m'a dit une fois: «Eh bien, comment ont-ils pu faire venir un cartésien sans le savoir?» Et tout cela a l'air vraiment horrible; Parfois, un programmeur qui n'est pas très à l'aise avec SQL fera quelque chose comme me donner une jointure cartésienne, mais seulement me rendre le premier enregistrement, donc je sais que j'ai quelque chose et que je n'ai besoin que du premier. Et donc, ils ne réalisent pas qu’ils ont ramené un milliard de disques ou parcouru un milliard de disques, car ils ont eu celui qui les intéressait.
Robin Bloor: Wow, je sais, c'est ce qui s'appelle - eh bien, c'est ce dont parlait Dez, en ce qui concerne les personnes qui ne sont pas aussi qualifiées qu'elles le devraient peut-être, vous savez. Si vous êtes programmeur, vous devez savoir quelles sont les implications de l’émission d’une commande. Je veux dire, vraiment, il n'y a aucune excuse à ce niveau de stupidité. Je présume également que vous êtes, d’une manière ou d’une autre, juste agnostique quant à la langue, parce que tout est centré sur la base de données. Ai-je raison en cela? Est-ce la même chose, peu importe ce que vous utilisez du côté du codage?
Bert Scalzo: Absolument, vous pouvez le faire en Fortran, C ou C ++. En fait, sur certains Unix, vous pouvez même le faire pour leurs langages de script; ils fournissent en fait les mêmes outils. Et puis je veux revenir une seconde en arrière pour ce que vous avez dit sans excuse. Je vais donner une pause aux programmeurs, parce que je n'aime pas les lancer sous le bus. Mais le problème, c’est vraiment l’environnement académique, car lorsque vous apprenez à devenir programmeur, vous apprenez à penser de manière record. On ne vous enseigne pas la pensée d'ensemble, et c'est ce que le langage de requête structuré, ou SQL, utilise avec les ensembles; c'est pourquoi nous avons l'union, l'intersection et l'opérateur moins. Et il est parfois très difficile pour une personne qui n’a jamais pensé en termes d’ensembles, de cesser de fumer, de laisser tomber le traitement des enregistrements et de travailler avec des ensembles.
Robin Bloor: Oui, je suis avec vous à ce sujet. Je veux dire, je comprends maintenant, c’est un problème d’éducation; Je pense que c’est une question d’éducation, c’est naturel pour les programmeurs de penser de manière procédurale. Et SQL n'est pas procédural, c'est déclaratif. En fait, vous dites simplement: «C'est ce que je veux et je ne me soucie pas de la façon dont vous le faites», vous savez? Alors qu'avec les langages de programmation, vous avez souvent les manches retroussées et que vous êtes dans les moindres détails de la gestion même des comptes, pendant que vous faites une boucle. Malade à -
Bert Scalzo: Non, continuez.
Ouais, j'allais dire que vous avez évoqué un autre exemple selon lequel un profileur serait bien à même de saisir la situation, continue en quelque sorte avec ce traitement record à la fois. Parfois, un programmeur qui est doué pour une logique d'enregistrement après enregistrement ne peut pas comprendre comment exécuter un programme SQL. Disons qu'il crée deux boucles FOR et fait essentiellement une jointure, mais il le fait côté client. Donc, il fait le même effet qu'une jointure, mais il le fait lui-même, et un profil le comprendrait, car vous perdriez probablement plus de temps à faire la jointure manuellement qu'à laisser le serveur de base de données le faire pour vous.
Robin Bloor: Oui, ce serait un désastre. Je veux dire, vous seriez juste en train de se débattre. Thrashings toujours mauvais.
Quoi qu'il en soit, je passe à Dez; Je suis sûr qu'il a des questions intéressantes.
Dez Blanchfield: Merci, oui, je le fais. Je vais vous rejoindre pour ne pas jeter les programmeurs sous le bus. Je veux dire, j’ai passé trop d’années dans ma vie à être codeur moi-même, à tous les niveaux, que ce soit comme vous le dites, assis sur la ligne de commande de la machine Unix, et dans certains cas, j’ai même été impliqué dans une couple de ports Unix différents d’une plate-forme matérielle à une autre. Et vous pouvez imaginer les défis que nous avons eus. Mais la réalité est que voici la carte de sortie de prison pour chaque codeur et scripteur du monde. C'est littéralement une science de fusée, écrire très serré à chaque fois, tout le temps, est une science de fusée. Et des histoires célèbres de personnes comme Dennis Ritchie et Brian Kernahan, travaillant indépendamment sur un code, puis discutant autour d'un code autour d'un café et découvrant qu'elles écrivaient exactement le même code, exactement dans le même programme, exactement de la même façon. Et ils l'ont fait en C. Mais ce niveau de programmation puriste existe très rarement.
Le fait est que, tous les jours, il n’ya que 24 heures par jour, sept jours par semaine, et nous devons tout faire. Et ainsi, en ce qui concerne non seulement les programmeurs traditionnels, les administrateurs de base de données, les codeurs, les scripteurs, les administrateurs système, les administrateurs réseau, le personnel de sécurité, et tout ce qui concerne les citoyens, ces jours-ci; nous entendons, chacun essaie juste de faire son travail. Et donc je pense que le meilleur atout de tout cela, c’est que j’ai adoré votre démo et celle que vous nous avez laissée là-bas, tout à l’heure, parler à Robin du fait que cela a un aspect particulier - peut-être pas tellement une niche - mais un vaste espace auquel elle s'applique, dans la mesure où elle corrige le code, SQL et les bases de données. Mais j'étais vraiment ravi de vous entendre dire que vous pouviez vous attaquer à un script shell et trouver quelques problèmes, car vous savez, de nos jours, nous travaillions toujours au moindre coût.
La raison pour laquelle vous pouvez acheter une chemise de 6 $ quelque part, c'est parce que quelqu'un a construit un système suffisamment bon marché pour réellement fabriquer, expédier et livrer de façon logistique, vendre et vendre au détail et prendre des paiements en ligne pour obtenir cette chemise de 6 $. Et cela ne se produit pas si vous payez 400 000 $ par an à des personnes pour écrire du code de manière parfaite; c'est juste le développement entier. Donc, je pense que l’une des questions que je voudrais vraiment vous donner nous donne un peu plus de perspicacité: quelle est l’ampleur et la portée du type de personnes que vous voyez actuellement qui déploient ce type d’outils pour profiler un code pour des problèmes de performance? Au départ, historiquement, d'où viennent-ils? Ont-ils été les grandes maisons d'ingénierie? Et puis, à l'avenir, est-ce le cas? Ai-je raison de penser que de plus en plus d'entreprises mettent en œuvre cet outil, ou ces outils, pour essayer d'aider les codeurs, ceux qu'ils savent qui font juste quelque chose pour terminer leur travail? et le sortir par la porte? Et parfois avons-nous besoin d'une carte de sortie de prison? Ai-je raison de penser qu'historiquement, nous nous sommes davantage concentrés sur le développement et l'ingénierie? Comme le disait Robin, l’approche académique a été réduite et son code autodidacte, ou copier-coller, ou tout simplement être construit? Et cela correspond-il au genre de personnes qui utilisent le produit maintenant?
Bert Scalzo: Oui exactement. Et je vais vous donner un exemple très spécifique, nous voulons simplement que le travail soit effectué, car les gens d’affaires ne veulent pas de la perfection. C'est un peu comme un jeu d'échecs informatisé: le jeu d'échecs ne cherche pas la réponse parfaite; il cherche une réponse suffisamment bonne dans un laps de temps raisonnable, et c'est ainsi que nous programmons. Mais ce que je trouve maintenant, c’est que la plupart des gens au lieu de dire qu’ils veulent un profileur dans le cadre de leurs tests unitaires - c’est comment je le ferais, parce que je ne le vois pas comme une perte de temps - ce qui se passe, c’est maintenant que c’est ce qui est fait plus tard, parfois, lors de tests d'intégration ou de tests de résistance, si vous avez de la chance. Mais la plupart du temps, cela faisait partie d'une escalade, où certaines choses sont entrées en production, cela a duré pendant un certain temps, peut-être même pendant des années, et maintenant, cela ne fonctionne pas bien, et maintenant, il est bien présenté. Et cela semble être le scénario le plus courant maintenant.
Dez Blanchfield: Oui, et je pense que le terme «dette technique» est probablement un terme que vous connaissez mieux que d’habitude; Je sais que Robin et moi sommes certainement. Je pense que ces jours-ci, en particulier dans les approches agiles de développement et de construction de systèmes, le concept de dette technique est pour moi une chose très réelle, et nous en tenons réellement compte dans les projets. Je sais, je veux dire, nous avons nos propres projets, comme le Media Lens et d’autres, dans lesquels nous effectuons le codage quotidiennement, et diverses choses au sein du groupe Bloor. Et chaque fois que nous construisions quelque chose, nous regardions en quelque sorte, je le regardais, et regardais toujours du point de vue de ce que ça va me coûter de régler ça maintenant, par opposition à ce que je peux juste le mettre dans la boîte faites-le sortir, puis regardez et voyez si cela va casser. Et hériter de cette dette technique que je sais, je vais devoir revenir plus tard et réparer.
Et je veux dire, j’ai fait cela au cours des sept derniers jours: j’ai écrit quelques outils et scripts, j’ai écrit quelques morceaux de langage Python et je l’ai déployé dans le dos de Mongo, pour s’assurer qu’il est agréable, propre et sécurisé, mais il obtient juste la requête dont j'ai besoin, sachant que j'ai besoin de cette fonction pour fonctionner, pour arriver au plus gros casse-tête; C'est là que se trouve ma vraie douleur. Et donc vous contractez cette dette technique, et je pense que ce n’est pas maintenant une chose occasionnelle, je pense que cela fait partie de l’ADN du développement. Les gens acceptent simplement - pas de manière naïve - qu'ils acceptent simplement la dette technique est un problème normal de type modus operandi, et il leur suffit de la supporter. C'est là que vous contractez la dette technique. Et je pense que le point fort de ce que vous nous avez montré dans la démo est que vous pouvez littéralement profiler et voir combien de temps il faut pour courir. Et c'est probablement l'une de mes choses préférées. Je veux dire, j’ai en fait créé des outils de profilage - nous utilisions des outils dans Sed, Lex et Orc pour exécuter notre code et voir où se trouvaient les boucles, avant que des outils comme celui-ci ne soient disponibles - et lorsque vous avez créé du code pour passer en revue votre propre code , vous obtenez très bien de ne pas avoir à réviser votre propre code. Mais ce n'est pas le cas maintenant. Dans cet esprit, y a-t-il un segment de marché particulier qui aborde cette question plus que tout autre? Voir comme une masse
Bert Scalzo: Oh oui, j'ai… je vais vous faire une analogie et vous montrer que les non-programmeurs le font tout le temps. Parce que, si j'enseigne un cours ou une session de débogage et de profilage, Ill demandera aux gens: «Bon, combien de personnes ici vont dans Microsoft Word et n'utilisent jamais à dessein le correcteur orthographique?» Et personne ne lève la main, car pour écrire des documents, nous savons tous que nous pouvons faire des erreurs en anglais et que tout le monde utilise le correcteur orthographique. Et j'ai dit: «Eh bien, comment se fait-il que lorsque vous écrivez dans votre IDE comme Visual Basic, vous n'utilisiez pas le débogueur? C'est la même chose, c'est comme un correcteur orthographique.
Dez Blanchfield: Oui, en fait, c'est une excellente analogie. Je n'y avais pas vraiment pensé, je dois admettre que je fais quelque chose de similaire avec quelques outils que j'utilise. En fait, ODF, mon préféré avec Eclipse, consiste simplement à copier / coller du code et à rechercher des éléments à mettre immédiatement en surbrillance tout en réalisant que j'ai fait une faute de frappe lors d'un appel de classe. Et, mais c’est intéressant maintenant, avec l’outil comme celui-ci, vous pouvez le faire en temps réel au lieu de revenir le regarder plus tard, ce qui est plutôt agréable à comprendre. Mais oui, c’est une excellente analogie que de simplement mettre dans un traitement de texte, parce que c’est un réveil intéressant, réalisez simplement que vous avez fait des fautes de frappe ou même une erreur de grammaire, non?
Bert Scalzo: Exactement.
Dez Blanchfield: Alors, voyez-vous maintenant une légère hausse de la part de ma dernière question avant de passer à notre Q & R, peut-être, pour nos participants. Si vous aviez l'intention de faire une sorte de recommandation sur l'approche à adopter - je suppose que c'est rhétorique - est-il vrai que vous arrivez tôt et que cela soit mis en œuvre au fur et à mesure de votre développement, avant votre développement? Ou bien vous êtes principalement en train de construire, de bouger, de construire quelque chose, puis d’entrer et de le profiler plus tard? Je soupçonne que c'est le cas d'entrer tôt et assurez-vous que vos codes nettoient dès le départ. Ou est-ce un cas où ils devraient envisager cette partie de leur post-déploiement?
Bert Scalzo: Idéalement, ils le feraient au départ, mais comme tout le monde est dans le monde agité où ils doivent faire leur travail, ils ont tendance à ne pas le faire tant qu'ils ne rencontrent pas un problème de performances qu'ils ne peuvent pas résoudre en ajoutant davantage de processeurs et de mémoire. à une machine virtuelle.
Dez Blanchfield: Ouais. Donc, en fait, vous avez mentionné quelque chose d'intéressant, si je peux rapidement? Vous avez mentionné précédemment que cela peut être exécuté de n'importe où et que vous pouvez parler à la base de données à l'arrière-plan. Nous sommes donc à l'aise avec le type de concept bimodal dont nous parlons à présent, de nuage sur site / hors site, à en juger par la suite, à la fin de la journée, s'il peut parler au client et voir le code, il ne se soucie pas vraiment, n'est-ce pas?
Bert Scalzo: Exactement, oui, vous pouvez l'exécuter dans le cloud.
Dez Blanchfield: Excellent, car je pense que notre genre de monde est en train de se diriger vers un nouveau monde. Alors, Eric. Je vais maintenant vous dire que nous avons quelques questions et que je veux que nos participants restent avec nous, même si nous avons passé l'heure.
Eric Kavanagh: Oui, il y a quelques personnes là-bas, je vais juste faire un commentaire rapide: Bert, je pense que cette métaphore, l'analogie que vous donnez à l'aide du correcteur orthographique est franchement brillante. Franchement, c’est digne d’un blog ou deux, car c’est un bon moyen de dire ce que vous faites et ce que vous faites, et à quel point cela est précieux et comment il devrait être préférable de se servir d’un débogueur sur un ordinateur. base régulière, non? Je parie que vous avez la tête qui hoche la tête quand vous jetez celui-là, non?
Bert Scalzo: Absolument, car ce que je leur dis est: «Pourquoi est-ce que je vérifie l'orthographe de mes documents? Je ne veux pas être embarrassé par des fautes d'orthographe stupides. »Eh bien, ils ne veulent pas être embarrassés par des erreurs de codage stupides!
Eric Kavanagh: Droite. Oui en effet. Eh bien, chers amis, nous avons passé une heure et cinq minutes ici, un grand merci à vous tous pour votre temps et votre attention. Nous archivons toutes ces discussions en ligne, n'hésitez pas à revenir à tout moment pour les consulter. Le meilleur endroit pour trouver ces liens est probablement techopedia.com, alors ajoutez-le à cette liste ici.
Et avec cela, allions vous dire au revoir, les gens. Encore une fois, excellent travail, Bert, merci à nos amis d’IDERA. Eh bien, à la prochaine fois, à la semaine prochaine. Prends soin de toi! Bye Bye.