Réponse rapide: débogage et profilage de base de données à la rescousse

Par Techopedia Staff, 15 mars 2017

À retenir: l' hôte Eric Kavanagh a discuté du débogage et du profilage de la base de données avec le Dr Robin Bloor, Dez Blanchfield et Bert Scalzo d'IDERA.

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, un mercredi, et bien sûr, cela signifie.

Robin Bloor: Je ne vous entends pas, Eric.

Eric Kavanagh: J'y étais il y a quelques jours, donc vous n'êtes pas seul. Mais le sujet d'aujourd'hui est donc vraiment intéressant. C'est le genre de chose dont vous voulez vous assurer qu'il se passe en arrière-plan dans votre entreprise, sauf si vous êtes la personne qui le fait, auquel cas vous voulez vous assurer que vous le faites correctement. Parce que nous parlons 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. Nous allons donc parler de "Réponse rapide: débogage de la base de données et profilage à la rescousse".

Il y a vraiment une place dans la vôtre, contactez-moi sur Twitter, @eric_kavanagh bien sûr.

Cette année est chaude. Et le débogage va être chaud, quoi qu'il arrive. Ce sera vraiment l'un de ces problèmes qui ne disparaîtra jamais, peu importe à quel point nous réussissons dans ce domaine, il y aura toujours des problèmes, alors la clé est de savoir comment arriver à résoudre ces problèmes rapidement? Idéalement, vous avez d'excellents programmeurs, de superbes environnements, où tout ne va pas trop mal, mais comme le dit le vieil adage, «les accidents se produisent dans le meilleur des familles». Et il en va de même pour les organisations. Donc, ce genre de choses arrive, ça va arriver, la question est quelle sera votre solution pour y faire face et résoudre ces problèmes?

Nous entendrons le Dr Robin Bloor, puis notre propre Dez Blanchfield d'en bas, et bien sûr, notre bon ami, Bert Scalzo, de l'IDERA. Et en fait, je vais remettre les clés de Robin Bloor, les emporter. La parole est à vous.

Robin Bloor: D' accord. C'est un sujet intéressant. J'ai pensé que parce que Dez allait probablement continuer sur les techniques et les histoires de guerre sur le débogage, je pensais que je ferais juste une discussion de fond afin que nous ayons une image complète de ce qui se passe. Je l'ai fait longtemps, et j'étais codeur, donc c'est comme, et j'ai été presque tenté avec cette présentation de commencer à devenir lyrique sur l'idée de l'open source, mais je pensais laisser cela à quelqu'un d'autre.

Voici une liste de bogues célèbres, et la plupart d'entre eux arrivent en tête de liste, en gros, tous sauf les deux derniers coûtent au moins 100 millions de dollars. Le premier était le Mars Climate Orbiter, s'est perdu dans l'espace et c'était à cause d'un problème de codage, où les gens ont confondu les unités métriques avec (rires) les pieds et les pouces. Sur le Ariane Five Flight 501, il y avait un décalage entre un moteur qui était allumé et les ordinateurs qui étaient censés faire fonctionner la fusée lors de son lancement. Plusieurs pannes informatiques, explosion d'une fusée, manchettes. Gazoduc soviétique en 1982, dit être la plus grande explosion de l'histoire de la planète; Je ne sais pas si c'est le cas. Les Russes ont volé un logiciel de contrôle automatisé, et la CIA a réalisé qu'ils allaient le faire et y mettre des bugs, et les Soviétiques l'ont implémenté sans test. Alors, a fait exploser un pipeline, a pensé que c'était amusant.

Le ver Morris était une expérience de codage, qui est soudainement devenu un ver rapace qui a fait le tour de tout le monde - il a apparemment causé 100 millions de dollars de dégâts; 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 Maps d'Apple est probablement le pire et le plus désastreux lancement de tout ce qu'Apple a jamais fait. Les gens qui ont essayé de l'utiliser, je veux dire, quelqu'un conduisait sur la 101, et ont découvert que la carte Apple indiquait qu'ils étaient au milieu de la baie de San Francisco. Ainsi, les gens ont commencé à se référer à l'application Apple Maps comme iLost. La - notre plus longue panne en 1990 - c'est juste intéressant du point de vue du coût de quelque chose comme ça - AT&T a été absent pendant environ neuf heures et cela a coûté quelque 60 millions de dollars en appels interurbains.

Et j'étais dans une compagnie d'assurance britannique, et la base de données, ils ont mis en œuvre une nouvelle version de la base de données et il a commencé à effacer les données. Et je m'en souviens très bien, car j'ai été appelé par la suite pour participer à une sorte de sélection de base de données à cause de cela. Et c'était très intéressant qu'ils aient pris une nouvelle version de la base de données, et ils ont eu une batterie de tests qu'ils ont fait pour les nouvelles versions de la base de données et qui ont passé tous les tests. Il a trouvé un moyen vraiment obscur d'effacer les données.

Donc, de toute façon, c'est ça. Je pensais parler du décalage d'impédance et du SQL émis. Il est intéressant de noter que les bases de données relationnelles stockent les données dans des tables et que les codeurs ont tendance à manipuler les données dans des structures d'objets qui ne correspondent vraiment pas très bien aux tables. Et à cause de cela, vous obtenez ce que l'on appelle le décalage d'impédance, et quelqu'un doit y faire face d'une manière ou d'une autre. Mais ce qui se passe réellement, car un modèle, le modèle du codeur 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, je pense, est hilarant. Donc, fondamentalement, du côté des codeurs, lorsque vous obtenez des hiérarchies, il peut s'agir de types, il peut en résulter des ensembles, cela peut être une faible capacité API, il peut y avoir beaucoup de choses qui jettent simplement les choses en termes d'interaction avec la base de données. Mais ce qui m'intéresse le plus, c'est vraiment intéressant; m'a toujours étonné que vous ayez cette barrière SQL qui est aussi une sorte d'impédance d'une manière que les codeurs et la base de données fonctionnent ensemble. Ainsi, SQL a la reconnaissance de données, ce qui est bien et il a DML pour sélectionner, projeter et joindre, ce qui est bien. Vous pouvez jeter beaucoup de capacités en termes d'extraction de 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 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, d'obtenir les données. Donc, 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ésidaient était que vous ne vouliez pas vraiment envoyer des données dans un programme.

Pour certaines fonctionnalités, les données étaient extrêmement spécifiques, donc ce n'était pas seulement l'intégrité référentielle et les suppressions en cascade et des choses comme ça, la base de données s'occupait de tout à coup que vous mettiez des fonctionnalités dans une base de données, ce qui signifiait bien sûr que la fonctionnalité d'une application peut être partagée entre le codeur et la base de données elle-même. Et cela a rendu le travail d'implémentation de certains types de fonctions très difficile et donc plus sujet aux erreurs. Donc, c'est un côté du jeu de base de données, car cela signifie que vous avez beaucoup d'implémentations par exemple, que j'ai été impliqué dans des bases de données relationnelles, il y a vraiment beaucoup de code qui se trouve dans les procédures stockées qui sont gérées séparément du code qui se trouve dans les applications. Et cela semble être une chose très étrange, il est censé être assez intelligent pour faire diverses choses.

Je pensais que je parlerais également des performances de la base de données parce que les erreurs de performances sont souvent considérées comme des bogues, mais en gros, vous pouvez avoir un goulot d'étranglement au niveau du processeur, de la mémoire, du disque, du réseau et vous pouvez avoir des problèmes de performances en raison du verrouillage . L'idée serait que le codeur n'avait pas vraiment besoin de se soucier des performances et que la base de données fonctionnerait en fait raisonnablement bien. Il est censé être conçu pour que le codeur n'ait pas besoin de savoir. Cependant, vous obtenez une mauvaise conception de base de données, vous obtenez une mauvaise conception de programme, vous obtenez la concurrence dans le mélange de charge de travail, ce qui peut également entraîner des problèmes de performances. Vous bénéficiez de l'équilibrage de charge, de la planification de la capacité, de la 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éplication et de nécessité 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 la base de données ne peut être que très onéreux et non trivial - et je le dis parce que j'en ai fait beaucoup - et vous découvrirez souvent que c'est comme toutes les situations de débogage que je jamais connu est, est la première chose que vous voyez jamais est un gâchis. Et vous devez essayer de passer du désordre à trouver comment le désordre s'est produit. Et souvent, lorsque vous regardez un problème de base de données, tout ce que vous regardez, ce sont des données corrompues et vous vous demandez: "Comment diable est-ce arrivé?"

Quoi qu'il en soit, je vais passer à Dez, qui va probablement dire plus de mots de sagesse que je n'en ai sorti. Je ne sais pas comment te passer le ballon, Dez.

Eric Kavanagh: Je vais le laisser passer, attendez, attendez.

Voix automatisée: les lignes des participants sont coupées.

Eric Kavanagh: Très bien, attendez une seconde, laissez-moi donner le ballon à Dez.

Dez Blanchfield: Merci, Eric. Oui, Dr Robin Bloor, vous avez en effet tout à fait raison: c'est un sujet, un ours de bogue à 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 bogues est une conférence d'une journée, dans de nombreux cas d'après mon expérience. C'est un sujet tellement large et large, donc je vais 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 soi est généralement détectée par les environnements de développement intégrés, bien qu'il puisse s'agir de bogues de longue durée. Mais souvent c'est plus un cas de profilage de code et il est possible d'écrire du code qui fonctionne, cela devrait être un bug. Donc, ma diapositive de titre ici, j'avais en fait une copie en très haute résolution A3, mais malheureusement elle a été détruite lors d'un déménagement. Mais ceci est une note manuscrite sur une feuille de programmation de vers 1945, où soi-disant des gens de l'Université de Harvard aux États-Unis, leur deuxième construction d'une machine appelée Mark II. Ils déboguaient un problème, dans un langage courant, mais ils essayaient de trouver un défaut, et il s'est avéré que quelque chose de légèrement différent de ce qui était un matériel et un problème soi-disant logiciel s'est produit.

Donc, le mythe urbain est que, vers le 9 septembre 1945, une équipe de l'Université de Harvard démontait une machine, ils sont tombés sur quelque chose qu'ils appelaient «relais soixante-dix» - à cette époque, la programmation se faisait dans un sens physique, vous blessiez le code autour d'une planche, et c'est ainsi que vous avez efficacement programmé la 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 "bug" était apparu parce qu'il s'agissait littéralement d'un papillon de nuit - soi-disant là était un papillon de nuit coincé entre un morceau de fil de cuivre allant d'un endroit à un autre. Et l'histoire raconte que la légendaire Grace Hopper comme cette légende, pour ma diapositive de titre, "premier cas réel d'un bug détecté" cite sans citation.

Mais comme Robin l'a souligné plus tôt dans sa première diapositive, le concept d'un bug remonte aussi loin que nous pouvons imaginer que les humains font du calcul, des concepts comme un patch. Le terme «patch» vient d'un véritable morceau de ruban adhésif collé sur un trou d'une carte perforée. Mais tout l'intérêt, c'est que le terme «débogage» est né de ce concept de trouver un bogue dans une machine physique. Et depuis, nous avons utilisé cette terminologie pour essayer de traiter les problèmes, non pas tant que les problèmes de codage dans un programme qui ne compile pas, mais comme un programme qui ne fonctionne pas bien. Et spécifiquement n'a pas été profilé, il suffit de trouver des choses comme des boucles sans fin qui ne vont nulle part.

Mais nous avons aussi un scénario, et je pensais que je mettrais quelques diapositives amusantes avant d'entrer dans un peu plus de détails. Voici le dessin animé classique, appelé XKCD sur le Web, et le dessinateur a des vues assez drôles sur le monde. Et celui-ci concerne un enfant appelé "Little Bobby Tables" et soi-disant ses parents ont nommé ce jeune garçon Robert '); DROP TABLE Élèves; - et ça s'appelle, et en quelque sorte «Salut, c'est l'école de ton fils qui a des problèmes avec l'ordinateur», et le parent répond: «Oh mon dieu, a-t-il cassé quelque chose?» Et l'enseignant dit: «Eh bien, d'une certaine manière », et l'enseignant demande, « avez-vous vraiment nommé votre fils Robert »); DROP TABLE Students; -? »Et le parent dit:« Oh oui, petites tables Bobby que nous l'appelons. »Quoi qu'il en soit, ils continuent en disant qu'ils ont maintenant perdu le dossier scolaire de l'année, j'espère que vous êtes heureux. Et la réponse est: "Eh bien, vous devez nettoyer et désinfecter vos entrées de base de données." Et j'utilise cela plusieurs fois pour parler de certains des problèmes que nous avons pour trouver des choses dans le code, que souvent le code ne regarde pas les données ainsi que.

Un autre drôle, je ne sais pas si c'est réel ou pas - je soupçonne que c'est une parodie - mais encore une fois, cela touche aussi mon os drôle. Quelqu'un change la plaque d'immatriculation à l'avant de sa voiture, pour une déclaration similaire qui provoque la chute des bases de données des radars et ainsi de suite qui capturent les plaques d'immatriculation des voitures. Et je me réfère toujours à cela comme si je doute qu'un programmeur ait anticipé une fuite de son code par un véritable véhicule à moteur, mais jamais sous-estimer cela - la puissance d'un geek en colère.

(Rire)

Mais cela m'amène à mon point clé, je suppose, et c'est qu'il était une fois, nous pourrions déboguer et profiler le code comme de simples mortels. Mais je suis très convaincu que ce temps est passé, et de façon anecdotique dans mon expérience, ma première - et cela va me vieillir terriblement, j'en suis sûr; Robin, vous êtes le bienvenu pour me moquer de cela - mais historiquement, je viens d'un milieu à l'âge de 14 ans errant au bout de la ville et frappant à la porte d'un centre de données appelé «Data Com» dans New Zélande et demander si je pouvais gagner de l'argent de poche à l'école en rentrant tard dans le bus, à environ 25 km de trajet tous les jours, en mettant du papier dans les imprimantes et des bandes dans les lecteurs de bande, et en étant simplement administrateur général. Et curieusement, ils m'ont donné un emploi. Mais au fil du temps, j'ai réussi à me lancer dans la dotation en personnel et à trouver les programmeurs.J'ai réalisé que j'aimais le codage et j'ai suivi 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 passer par tout le processus de s'asseoir sur un terminal 3270 en écrivant du code à la main.

En fait, ma toute première expérience a été sur un terminal téléscripteur, qui était en fait une imprimante physique à 132 colonnes. Essentiellement, pensez à une très vieille machine à écrire avec du papier qui la faisait défiler, car ils n'avaient pas de tube CRT. Et le débogage du code était un problème très simple, donc vous aviez tendance à écrire tout votre code à la main, puis à agir comme une dactylo, en faisant de votre mieux pour ne pas avoir d'erreurs à se faufiler, car il est extrêmement frustrant d'avoir à le dire l'éditeur d'une ligne pour aller à une certaine ligne, puis imprimer la ligne et la taper à nouveau. Mais il était une fois, c'est ainsi que nous écrivions du code et c'est ainsi que nous déboguions, et nous sommes devenus très, très bons. Et en fait, cela nous a forcés à avoir de très bonnes techniques de programmation, car c'était un vrai tracas de le réparer. Mais le voyage a ensuite traversé - et nous le savons tous - il est passé de l'expérience du terminal 3270 dans mon monde, à l'équipement numérique VT220 où vous pouviez voir les choses à l'écran, mais encore une fois, vous faisiez simplement la même chose vous l'avez fait sur le type de bande papier au format imprimé uniquement sur un tube cathodique, mais vous avez pu 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, probablement mon interface préférée avec un ordinateur - et puis le PC et ensuite le Mac, et de nos jours des GUI et ID modernes basés sur le Web. Et une gamme de programmes à travers cela, la programmation en un et assembleur et PILOT et Logo et Lisp et et Fortran et Pascal et des langages qui pourraient faire grincer des dents. Mais ce sont des langages qui vous ont obligé à écrire du bon code; ils ne vous ont pas laissé échapper à de mauvaises pratiques. C, C ++, Java, Ruby, Python - et nous progressons dans cette étape de programmation, nous nous rapprochons davantage du script, nous nous rapprochons de plus en plus du Structured Query Language et des langages comme PHP qui sont en fait utilisés pour appeler SQL. Le point de vous dire que, venant de mes antécédents, j'étais autodidacte à bien des égards et ceux qui m'ont aidé à apprendre, m'ont enseigné de très bonnes pratiques de programmation et de très bonnes pratiques autour de la conception et des processus pour m'assurer que je ne l'ai pas introduire du code buggy.

Les méthodes de programmation de nos jours, des choses comme, par exemple, Structured Query Language, SQL, c'est un langage de requête simple et très puissant. Mais nous l'avons transformé en 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 tout un tas de problèmes, car lorsque nous pensons à deux points de vue: du point de vue du codage et du point de vue du DBA. Il est très facile de se présenter et d'introduire des bogues pour des choses telles que de mauvaises techniques de programmation, des efforts paresseux pour écrire du code, un manque d'expérience, la bête noire classique que j'ai par exemple avec des gens SQL sautant sur Google et cherchant quelque chose et trouvant un site Web qui est a obtenu un exemple et fait un copier-coller du code existant. Et puis répliquer un mauvais codage, une faute professionnelle et le mettre en production, car il se trouve que cela leur donne les résultats qu'ils souhaitent. Vous avez d'autres défis, par exemple, ces jours-ci, nous nous précipitons tous vers ce que nous appelons la course à zéro: essayer de tout faire si bon marché et si vite, que nous avons un scénario où nous n'employons pas moins -le personnel rémunéré. Et je ne veux pas dire cela de manière fallacieuse, mais nous n'engageons pas d'experts pour tous les emplois possibles. Il était une fois quelque chose à voir avec les ordinateurs était sorcier; il a été impliqué dans des choses qui ont explosé et ont été très bruyantes, ou sont allés dans l'espace ou des ingénieurs étaient des hommes et des femmes hautement qualifiés qui avaient obtenu des diplômes et une formation rigoureuse qui les empêchaient de faire des choses folles.

De nos jours, beaucoup de gens se lancent dans le développement et la conception et la base de données qui n'ont pas eu des années d'expérience, n'ont pas nécessairement reçu la même formation ou le même soutien. Et vous vous retrouvez donc avec un scénario de l'amateur traditionnel versus l'expert traditionnel. Et il y a une ligne célèbre, je ne me souviens pas vraiment qui a créé la citation, la ligne dit: «Si vous pensez que cela coûte cher d'embaucher un expert pour faire un travail, attendez jusqu'à ce que vous embauchiez quelques amateurs qui créent un problème et vous doivent le nettoyer. »Et donc SQL a ce problème, et il est très, très facile à apprendre, il est 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 sélectionnée de n'importe où et tirer tout cela dans un langage de programmation avec lequel vous êtes plus à l'aise comme PHP et Ruby ou Python, et utiliser le langage de programmation que vous connaissez nativement, pour le faire la manipulation des données, plutôt que de faire une requête plus complexe en SQL. Et nous le voyons beaucoup, puis les gens se demandent pourquoi la base de données fonctionne lentement; c'est parce qu'un million de personnes essaient d'acheter un billet depuis un système de billetterie en ligne, où il fait une sélection d'étoiles de n'importe où.

Maintenant, c'est un exemple vraiment extrême, mais vous obtenez le point de tout cela. Donc, pour vraiment marquer ce point, voici un exemple que je porte beaucoup. Je suis un grand fan des mathématiques, j'adore la théorie du chaos, j'adore les sets Mandelbrot. Sur le côté droit, il y a une interprétation de l'ensemble de Mandelbrot, que je suis sûr que nous connaissons tous. Et à gauche, il y a un morceau de SQL qui rend cela. Maintenant, chaque fois que je mets ça sur un écran quelque part, j'entends ça «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 ici, et c'est oui, en fait, vous pouvez maintenant programmer presque n'importe quoi en SQL; c'est un langage de programmation très développé, puissant et moderne. À l'origine, il s'agissait d'un langage de requête, il était conçu pour simplement récupérer des données. Donc, maintenant nous avons des constructions très complexes et nous avons des procédures stockées, nous avons une méthodologie de programmation appliquée à un langage et c'est donc très facile pour les mauvaises pratiques de programmation, le manque d'expérience, le code couper-coller, du personnel peu rémunéré qui essaie d'être un personnel bien rémunéré, des gens qui prétendent savoir, mais ils doivent apprendre sur le tas.

Toute une gamme de choses où le profilage de code et ce que nous appelons le débogage, ce n'est pas tant de trouver des bogues qui empêchent les programmes de fonctionner, mais des bogues qui nuisent au système et un code mal structuré. Lorsque vous regardez cet écran maintenant, et que vous pensez, c'est juste, c'est plutôt mignon et vous vous dites: "Wow, quel super graphique, j'adorerais faire ça." Mais imaginez que courir sur une certaine logique métier . Il a l'air assez soigné, mais il parle d'une théorie mathématique du chaos rendue graphiquement, mais quand vous pensez à quoi il pourrait potentiellement être utilisé dans une logique métier, vous obtenez l'image très rapidement. Et pour vraiment illustrer cela - et je suis désolé que les couleurs soient inversées, c'est censé être un fond noir et un texte vert être un écran vert, mais vous pouvez toujours le lire.

Je suis allé jeter un coup d'œil à un exemple de ce que vous pourriez potentiellement faire si vous étiez vraiment fou et que vous n'aviez aucune expérience et que vous veniez d'un arrière-plan différent de la programmation et que j'appliquais le C ++ à SQL, pour illustrer vraiment mon point, avant Je passe la main à notre éminent invité d'IDERA. Il s'agit d'une requête structurée écrite comme C ++, mais codée en SQL. Et il s'exécute en fait, mais il s'exécute sur une période d'environ trois à cinq minutes. Et il tire ostensiblement une ligne de données de plusieurs bases de données, de plusieurs jointures.

Encore une fois, le but de tout cela est que si vous n'avez pas les bons outils, si vous n'avez pas les bonnes plates-formes et les bons environnements pour pouvoir attraper ces choses, et ils entrent en production, et alors vous avez 100 000 personnes frapper un système tous les jours, heures ou minutes, vous vous retrouvez très vite avec une expérience à 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, je vous prie de m'excuser, devraient les prendre en compte avant qu'ils ne se rapprochent de - même pendant le processus de test, même via l'UAT et l'intégration des systèmes, ce morceau de code devrait être ramassé et mis en évidence et quelqu'un devrait être mis de côté en disant: "Regardez, c'est vraiment du code, mais obtenons un DBA pour vous aider à construire correctement cette requête structurée, car franchement, c'est juste désagréable." Et l'URL est là, vous pouvez aller y jeter un coup d'œil - on l'appelle le la requête SQL la plus complexe que vous ayez écrite. Parce que croyez-moi, ça compile, ça tourne. Et si vous copiez et collez cela et que vous simulez simplement la base de données, c'est quelque chose à surveiller; si vous avez les outils pour regarder la base de données, essayez de fondre sur une période de trois à cinq minutes, pour rappeler ce qu'est une ligne de texte.

Donc, pour résumer, dans cet esprit, toute mon expérience en codage m'a appris que vous pouvez donner une arme aux gens et 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, après avoir effectué le codage, vous pouvez revoir votre code, vous pouvez trouver des problèmes en profilant le code, vous pouvez trouver des bogues involontaires qui sont des problèmes de performances et, comme je l'ai dit plus tôt, il était une fois, vous pourriez le faire en regardant un écran vert. Vous ne pouvez plus; il y a des centaines de milliers de lignes de code, des dizaines de milliers d'applications déployées, il y a 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, afin que vous puissiez trouver ces problèmes et les résoudre très, très rapidement, avant d'arriver au point, alors que le Dr Robin Bloor a souligné que les choses deviennent désastreuses et que les choses explosent, ou plus souvent, elles commencent juste à vous coûter beaucoup d'argent et beaucoup de temps et d'efforts et à détruire le moral et tout ça, quand ils ne peuvent pas comprendre pourquoi les choses prennent longtemps à courir.

Et dans cet esprit, je vais céder la parole à notre invité et j'ai hâte d'entendre comment ils ont résolu ce problème. Et en particulier la démo, je pense que nous sommes sur le point de recevoir. Eric, je repasse.

Eric Kavanagh: OK, Bert, emportez-le.

Bert Scalzo: D' accord, merci. Bert Scalzo ici d'IDERA, je suis le chef de produit pour 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 a dites plus tôt - et il est très vrai que le débogage est onéreux et non trivial, et quand vous allez au débogage de base de données, c'est un ordre de grandeur encore plus onéreux et non trivial - donc, que était une citation importante.

D'ACCORD. Je voulais commencer par l'historique de programmation, parce que souvent je vois des gens qui ne déboguent pas, ils n'utilisent pas de débogueur, ils programment juste avec le langage qu'ils utilisent, et souvent ils me disent, "Eh bien, ces choses de débogueur sont nouvelles, et nous n'avons pas encore commencé à les utiliser." Et donc ce que je fais est de leur montrer ce tableau chronologique, une sorte de pré-histoire, la vieillesse, le moyen âge, c'est gentil de dire où en étions-nous en termes de langages de programmation. Et nous avions des langues très anciennes à partir de 1951 avec le code d'assemblage, et Lisp et FACT et COBOL. Ensuite, nous entrons dans le groupe suivant, Pascals et Cs, puis dans le groupe suivant, les C ++, et regardons où se trouve ce point d'interrogation - ce point d'interrogation est approximativement à droite vers 1978 à peut-être 1980. Quelque part dans cette plage, nous avions débogueurs à notre disposition, et pour ainsi dire, "Hé, 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 50, parce que c'est le seule façon de vous en sortir avec cette affirmation.

Maintenant, l'autre chose qui est drôle à propos de ce graphique est que Dez vient de faire un commentaire sur Grace Hopper, je connaissais en fait Grace, donc c'est assez drôle. Et puis l'autre chose dont j'ai ri, c'est qu'il a parlé de télétypes et je suis assis là à dire: «Mec, c'était le plus grand saut que nous ayons jamais eu dans la productivité, quand nous sommes passés des cartes aux télétypes, c'était le plus grand saut jamais. "Donc, et j'ai programmé dans toutes les langues ici, y compris SNOBOL, dont personne n'a jamais entendu parler auparavant, c'était un CDC, Control Data Corporation, donc je suppose que je deviens un peu trop vieux pour cette industrie .

Dez Blanchfield: J'allais dire que vous nous avez terriblement vieillis là-bas.

Bert Scalzo: Oui, je vous le dis, je me sens comme grand-père Simpson. Je regarde donc le débogage et il existe différentes façons de déboguer. Vous pourriez parler de ce que nous considérons tous comme traditionnel d'entrer dans un débogueur et de parcourir le code. Mais aussi, les gens instrumenteront leur code; c'est là que vous collez des instructions dans votre code et que vous produisez peut-être un fichier de sortie, un fichier de trace ou quelque chose, et donc 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 fameuse déclaration print: vous regardez et les gens mettent des déclarations print dedans et j'ai vu un outil où - et c'est un outil de base de données - où si vous ne savez pas comment utiliser un débogueur, vous appuyez sur un bouton et il collera des instructions d'impression dans tout votre code pour vous, puis lorsque vous avez terminé, vous appuyez sur un autre bouton et il les supprime. Parce que c'est ainsi que beaucoup de gens déboguent.

Et la raison pour laquelle nous déboguons est double: tout d'abord, nous devons trouver des choses qui rendent notre code inefficace. En d'autres termes, cela signifie généralement qu'il y a une erreur de logique ou que nous avons manqué une exigence métier, mais ce que c'est, c'est que le code n'est pas efficace; il ne fait pas ce que nous attendions de lui. L'autre fois que nous allons et que nous faisons le débogage, c'est pour l'efficacité et cela pourrait être une erreur logique, mais ce que c'est, c'est que j'ai fait la bonne chose, ça ne revient tout simplement pas assez rapidement. Maintenant, je le dis parce qu'un profileur est probablement meilleur pour ce deuxième scénario et nous allons parler à la fois des débogueurs et des profileurs. De plus, il y a ce concept de débogage à distance; c'est important parce que la plupart du temps, si vous êtes assis sur votre ordinateur personnel et que vous utilisez un débogueur, qui frappe une base de données où le code est réellement exécuté sur la base de données, vous faites ce que l'on appelle le débogage à distance. Vous ne vous en rendez peut-être pas compte, mais c'est ce qui se passe. Et puis, il est très courant avec ces débogueurs d'avoir des points d'arrêt, des points de surveillance, d'intervenir et de passer par-dessus et d'autres choses courantes, que je vais montrer à ceux-ci sur un instantané d'écran dans un instant.

Maintenant, le profilage: vous pouvez effectuer le profilage de deux manières différentes. Certaines personnes diront que la capture de la charge de travail et la relecture là où elle capture tout, que cela compte comme un profilage. Mon expérience a été plus c'est mieux si c'est fait d'échantillonnage. Il n'y a aucune raison d'attraper chaque instruction, car certaines instructions peuvent simplement s'exécuter si rapidement que vous vous en fichez, ce que vous essayez vraiment de voir, eh bien, ce sont celles qui continuent de s'afficher maintes et maintes fois, car ils courent trop longtemps. Ainsi, le profilage peut parfois signifier l'échantillonnage plutôt que d'exécuter le tout. Et généralement, 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 peut vous donner comme un histogramme des performances des différentes lignes de code, mais elle pourrait aussi toujours c'est qu'il produit un fichier de trace.

Les profileurs sont apparus pour la première fois en 1979. Donc, ils existent depuis longtemps aussi. Idéal pour trouver la consommation de ressources ou les problèmes de performance, en d'autres termes, cette efficacité. De manière générale, il est séparé et distinct du débogueur, bien que j'aie travaillé avec des débogueurs qui font les deux en même temps. Et même si les profileurs sont, je pense, les plus intéressants des deux outils, si je pense que pas assez de personnes déboguent, alors certainement pas assez 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 en avons parlé plus tôt, vous avez SQL - et nous avons en quelque sorte forcé la cheville ronde dans le trou carré ici et l'avons forcée à devenir un langage de programmation - et Oracle. C'est PL / SQL - c'est le langage procédural SQL - et SQL Server, c'est Transact-SQL, c'est SQL-99, c'est SQL / PSM - car, je pense, c'est le module stocké de procédures. Postgres lui donne un autre nom, DB2 encore un autre nom, Informix, mais le fait est que tout le monde a forcé des constructions de type 3GL; en d'autres termes, les boucles FOR, les déclarations de variables et toutes les autres choses étrangères à SQL font désormais partie de SQL dans ces langages. Et donc, vous devez pouvoir déboguer un PL / SQL ou un Transact-SQL comme vous le feriez pour un programme Visual Basic.

Maintenant, les objets de base de données, c'est important parce que les gens diront: "Eh bien, qu'est-ce que je dois 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 je stocke des objets dans la base de données, c'est probablement une procédure stockée ou 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 se déclenche sur une sorte d'é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 leurs procédures stockées, mais c'est le même concept: c'est toujours le déclencheur qui pourrait être à l'origine de tout cela. Et puis, en tant qu'Oracle, ils ont quelque chose appelé un package, qui est un peu comme une bibliothèque si vous voulez. Vous mettez 50 ou 100 procédures stockées dans un seul groupe, appelé package, c'est donc un peu comme une bibliothèque. Voici donc le débogueur à l'ancienne; c'est en fait un outil qui va réellement coller et coller toutes ces instructions de débogage dans votre code pour vous. Donc, partout où vous voyez le bloc de débogage, ne le supprimez pas, le débogueur automatique démarre et trace, ceux-ci étaient tous coincés par un outil. Et les lignes en dehors de cela, qui est la minorité du code, eh bien, c'est la méthode de débogage non manuelle.

Et la raison pour laquelle je soulève cela, c'est que si vous essayez de le faire à la main, vous allez en fait taper plus de code de débogage pour insérer toutes ces instructions d'impression 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 à déboguer, d'autant plus que, que se passe-t-il si cela prend 10 heures pour que cette chose s'exécute, et où elle a un problème se trouve à la ligne trois? Si je faisais une session de débogage interactive, j'aurais su à la ligne trois - cinq minutes après - hey, il y a un problème ici, je peux arrêter. Mais avec cela, je dois attendre qu'il s'exécute, jusqu'à la fin, puis je dois regarder un fichier de trace qui contient probablement toutes ces instructions d'impression, et essayer de trouver l'aiguille dans le meule de foin. Encore une fois, c'est mieux que rien, mais ce ne serait pas la meilleure façon de travailler. Maintenant, voici à quoi ressemblerait ce fichier provenant de la diapositive précédente; en d'autres termes, j'ai exécuté le programme, et il y a juste un tas d'instructions d'impression dans ce fichier de trace et je peux ou non être capable de siphonner à travers cela et trouver ce que je dois 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 avez utilisé quelque chose comme Visual Studio pour écrire des programmes ou Eclipse, vous avez eu des débogueurs et vous les avez utilisés avec vos autres langages - ne pensiez tout simplement pas à les utiliser ici avec votre base de données. Et il y a des outils là-bas, comme notre DB Artisan et notre Rapid SQL, c'est 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". Fondamentalement, il va juste aller chercher et voir si j'ai plusieurs lignes dans le tableau 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, dans le tiers supérieur, j'ai mon code source au milieu, j'ai ce qu'on appelle mes variables de montre et mes plateaux de pile d'appels, puis en bas, je ' ai reçu quelques messages de sortie. Et ce qui est important ici, c'est que si vous regardez par-dessus cette 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 précis, alors que je 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 une ligne, laissez-moi regarder ce qui s'est passé, passez une autre ligne, laissez-moi voir ce qui s'est passé, 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 dans le cloud, je peux toujours faire ce débogage à distance et le voir et le contrôler à partir d'ici, et faire le débogage comme je le ferais avec n'importe quelle autre langue.

Maintenant, la flèche suivante là-bas - vous pouvez voir la petite flèche comme pointant vers la droite, vers cette sortie du SGBD, c'est là que se trouve mon curseur en ce moment - donc en d'autres termes, j'ai fait un pas et c'est là que je suis le moment. Donc, si je dis: «Encore une fois», je vais passer à 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 enjamber ces lignes." Si je veux juste sauter par-dessus tout et arriver là où ce point rouge, je peux appuyer sur le bouton Exécuter et il fonctionnera d'ici à 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 quand je fais tout cela, ce qui se passe au milieu et même en bas - mais surtout au milieu - va changer et je peux voir les valeurs de mes variables, Je peux voir ma trace de pile d'appels, vous savez, et donc toutes ces informations sont affichées là lorsque je parcours le code, donc je peux réellement voir et ressentir et comprendre ce qui se passe et comment le code est réellement travailler au moment de l'exécution. Et généralement, 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 que j'ai dit que parfois ils sont séparés et parfois ils peuvent être ensemble? Dans ce cas, et encore une fois, je suis en Rapid SQL, et je peux voir qu'il y a 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 voir clairement que tout mon temps est passé dans cette boucle FOR où je sélectionne tout dans une table . Et donc, tout ce qui se passe à l'intérieur de cette boucle FOR est probablement quelque chose que je dois examiner, et si je peux l'améliorer, cela rapportera des dividendes. Je ne vais pas obtenir d'améliorations en travaillant sur ces lignes qui ont comme 0, 90 ou 0, 86; il n'y a pas beaucoup de temps passé là-bas. Maintenant, dans ce cas, et encore une fois, je suis en Rapid SQL, vous voyez comment je peux faire du profilage mélangé avec mon débogage. Maintenant, ce qui est bien, c'est que SQL rapide 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 et ensuite 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 semble prendre la plupart du graphique à secteurs et si je regarde, je vois sur cette grille vers le bas, ligne 23, il y a à nouveau la boucle FOR: il prend le plus de temps, il est en fait ce rouge foncé mâchant tout le graphique à secteurs. Et donc, c'est une autre façon de faire du profilage. Il se trouve que nous appelons cet «analyste de code» dans notre outil. Mais il s'agit essentiellement d'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 façon.

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 - c'est peut-ê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 pour cela que vous utiliserez le débogueur. En outre, les utilisateurs finaux des entreprises; ils ne sont pas très patients: ils veulent des résultats avant même d'appuyer sur la touche. Nous sommes censés lire dans leurs pensées et tout faire instantanément. En d'autres termes, il faut que ce soit efficace. Et donc, c'est pour cela que nous utiliserions le profileur. Maintenant, sans ces outils, je crois vraiment que vous êtes ce type 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 en regardant simplement du code statique et comment allez-vous déterminer quelle ligne est l'endroit où il passerait le plus de temps à exécuter, encore une fois, simplement en regardant du code statique? Un examen du code peut ou non révéler certaines de ces choses, mais rien ne garantit qu'un examen du code les trouverait toutes. À l'aide d'un débogueur et d'un profileur, vous devriez pouvoir trouver tous ces bogues.

OK, je vais juste faire une démo très rapide ici. Ce n'est pas mon intention de pousser le produit, je veux juste vous montrer à quoi ressemble un débogueur, car la plupart du temps, les gens diront: "Je n'en ai jamais vu auparavant." Et c'est joli dans les diapositives de capture d'écran, mais à quoi ça ressemble quand il est en mouvement? Donc, ici sur mon écran, je lance notre produit DB Artisan; nous avons également un débogueur. Le DB Artisan est plus destiné aux DBA, le Rapid SQL est plus pour les développeurs, mais j'ai vu des développeurs qui utilisent DB Artisan, et j'ai vu des DBA qui utilisent Rapid. Alors, ne vous laissez pas prendre par le 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 exactement le même code qui était dans l'instantané d'écran, c'est ma vérification des doublons. Et je veux déboguer ceci, donc j'appuie sur debug. 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 en fait sur mon serveur de base de données, pas sur mon PC. Il a donc fallu passer par là et créer une session là-bas, créer un débogage à distance, raccorder ma session à cette session de débogage à distance et configurer un canal de communication.

Donc, maintenant, voici ma flèche, c'est là-haut en haut, à la ligne un, c'est là que je suis dans le code. Et si j'appuie sur la troisième icône là-bas, qui est une étape, vous verrez que la flèche vient de se déplacer, et si je continue à appuyer dessus, vous la verrez continuer à bouger. Maintenant, si je voulais descendre jusqu'à cette boucle FOR, parce que je sais que c'est là que réside le problème, je peux définir un point d'arrêt. Je pensais avoir réglé cela. 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, je viens de définir manuellement un point d'arrêt là-bas, alors maintenant, au lieu de faire une étape, étape, étape, étape jusqu'à ce que j'arrive, en fait, je peux simplement dire: «Allez-y et exécutez cette chose», et cela s'arrêtera. Remarquez que cela m'a déplacé jusqu'à l'endroit où se trouve le point d'arrêt, donc je suis maintenant dans le contexte de l'exécution de 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 certain nombre de mes locations et je peux passer la souris sur ce gars et regarder, il est deux, deux est supérieur à un, donc il va probablement faire la prochaine pièce de ce code. En d'autres termes, il a trouvé quelque chose. Je vais juste aller de l'avant et laisser courir. Je ne veux pas passer par tout ici; ce que je veux vous montrer, c'est quand un débogueur est terminé, il se termine comme un programme normal. J'ai le point d'arrêt défini, donc quand j'ai dit courir, il est juste revenu au point d'arrêt suivant. Je le laisse fonctionner jusqu'à la fin, 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 les mêmes résultats exacts si je ne l'avais pas exécuté à l'intérieur d'un débogueur.

Et avec cela, je vais suspendre la démo et revenir en arrière parce que nous voulons nous assurer d'avoir du temps pour les questions et les réponses. Et donc, je vais l'ouvrir pour des questions et réponses.

Eric Kavanagh: Très bien, Robin, peut-être une question de votre part, puis un couple de Dez?

Robin Bloor: Oui, bien sûr, je trouve cela fascinant, bien sûr. J'ai travaillé avec des trucs 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 que fait le profileur? Parce que c'est comme s'ils regardent - parce que je suppose qu'ils le sont - qu'ils examinent des problèmes de performances, cela vous aidera-t-il à faire la distinction entre le moment où une base de données prend du temps et le moment où un code prend du temps?

Bert Scalzo: Vous savez, c'est une question fantastique. Disons que je travaille en Visual Basic, et moi, à l'intérieur de mon Visual Basic, je vais appeler un Transact-SQL ou un PL / SQL. Permettez-moi de faire le PL / SQL, car Oracle ne joue pas toujours bien avec les outils Microsoft. Je peux profiler mon code Visual Basic, et le profil peut dire: «Hé, j'ai appelé cette procédure stockée et cela a pris trop de temps.» Mais ensuite je peux aller dans la procédure stockée et je peux faire un profil de base de données sur le stocké procédure et dites: «OK, sur les 100 déclarations qui sont ici, voici les cinq qui ont causé le problème.» Et donc, vous devrez peut-être faire une équipe de tag, où vous devrez utiliser plusieurs profileurs.

L'idée est que si jamais on vous dit que le problème de performances est 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 instructions sont en fait celles où vous avez un 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 chacun des millions de fois, mais il est appelé un million de fois, ce que le profileur montrerait, cette chose a fonctionné pendant autant d'unités de temps. Et donc, même si le code peut être très efficace, vous pourriez regarder et dire: «Ooh, nous appelons trop souvent ce morceau de code. Peut-être que nous ne devrions l'appeler que de temps en temps, plutôt que chaque fois que nous traitons un enregistrement », ou quelque chose. Et donc vous pouvez réellement trouver où il y a du code efficace qui est simplement appelé trop souvent, et c'est en fait un problème de performances.

Robin Bloor: Oui, c'est merveilleux. Je n'ai jamais fait ça. Vous voyez, bien sûr, quand j'avais des problèmes de base de données, c'était comme si, d'une manière ou d'une autre, je traitais avec une base de données ou avec 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 été impliqué dans la création d'applications où nous avions des procédures stockées, donc je suppose que je n'ai jamais rencontré de problèmes qui me rendaient fou, l'idée que vous aurait divisé le code entre une base de données et un programme. Mais alors, faites tout … Je suppose que la réponse sera oui, mais cela fait partie d'une activité d'équipe de développement, lorsque vous essayez d'une manière ou d'une autre de réparer quelque chose qui est cassé, ou peut-être d'essayer d'apporter un nouveau application ensemble. Mais tout cela correspond-il à tous les autres composants auxquels je m'attendrais dans l'environnement? Puis-je m'attendre à ce que je puisse clipser cela avec tous mes packs de test et tous les autres trucs que je ferais et avec mes trucs de gestion de projet, est-ce ainsi que tout cela se clipse?

Bert Scalzo: Oui, 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, j'avais un client qui construisait une application Web, et leur base de données avait été petite, historiquement, et le fait qu'ils n'étaient 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 lorsque l'écran apparaît, et maintenant c'est un problème de performances. Et ils savaient que le problème n'était pas dans leur Java ou dans ces autres endroits. Mais ils avaient des milliers de procédures stockées et ils ont donc dû commencer à profiler les procédures stockées pour savoir pourquoi cette page Web mettait 20 secondes à apparaître? Et nous avons en fait découvert qu'ils avaient une jointure cartésienne dans l'une de leurs déclarations sélectionnées et ne le savaient pas.

Robin Bloor: Wow.

Bert Scalzo: Mais quelqu'un m'a dit une fois: «Eh bien, comment pourraient-ils avoir une jointure cartésienne sans le savoir?» Et cela semblera 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 ne me restituera que le premier enregistrement, donc je sais que j'ai quelque chose, et je n'ai besoin que du premier. Et donc, ils ne réalisent pas qu'ils ont juste ramené un milliard de disques ou qu'ils parcourent un milliard de disques, car ils ont obtenu celui qui les intéressait.

Robin Bloor: Wow, je sais, c'est ce qu'on appelle … eh bien, c'est ce que Dez faisait, en termes de personnes qui ne sont pas aussi qualifiées qu'elles devraient l'être, vous savez. Si vous êtes un programmeur, vous devez savoir quelles sont les implications de l'émission d'une commande. Je veux dire, vraiment, il n'y a aucune excuse pour ce niveau de stupidité. Je présume également que vous êtes, d'une manière ou d'une autre, juste agnostique vis-à-vis de la langue à cet égard, car tout cela se concentre sur le côté de la base de données. Ai-je raison? Est-ce la même chose, quoi que vous utilisiez du côté du codage?

Bert Scalzo: Absolument, vous pouvez le faire en Fortran ou en 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 en arrière une seconde pour ce que vous avez dit sans excuse. Je vais donner une pause aux programmeurs, parce que je n'aime pas jeter des programmeurs sous le bus. Mais le problème est vraiment l'environnement académique parce que lorsque vous allez apprendre à être programmeur, vous apprenez la pensée d'enregistrement à la fois. On ne vous apprend pas la réflexion sur les ensembles, et c'est ce que Structured Query Language, ou SQL, fonctionne 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, d'arrêter, d'abandonner le traitement d'enregistrement à la fois et de travailler avec des ensembles.

Robin Bloor: Oui, je suis avec vous là-dessus. Je veux dire, je comprends maintenant, c'est une question d'éducation; Je pense que c'est complètement une question d'éducation, je pense qu'il est naturel pour les programmeurs de penser de manière procédurale. Et SQL n'est pas procédural, il est déclaratif. En fait, vous dites simplement: «C'est ce que je veux et je me fiche de comment vous le faites», vous savez? Alors qu'avec les langages de programmation, vous avez souvent vos manches retroussées et vous êtes dans la minutie de même gérer les comptes, pendant que vous faites une boucle. Je passe à …

Bert Scalzo: Non. OK, continuez.

Ouais, j'allais dire que vous avez cité un autre exemple qu'un profileur serait bien de saisir le genre de processus avec ce traitement à la fois. Parfois, un programmeur qui est bon dans une logique d'enregistrement à la fois, ne peut pas comprendre comment faire un programme SQL. Eh bien, disons qu'il fait 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 l'attraperait, car vous finiriez probablement par passer plus de temps à faire la jointure manuellement qu'à laisser le serveur de base de données le faire pour vous.

Robin Bloor: Ouais, ce serait un désastre. Je veux dire, vous seriez juste en train de vous battre. La raclée est toujours mauvaise.

Quoi qu'il en soit, je vais passer à Dez; Je suis sûr qu'il a des questions intéressantes.

Dez Blanchfield: Merci, oui, je le fais. Je vais vous rejoindre dans les programmeurs ne jetant pas sous le bus. Je veux dire, j'ai passé trop d'années dans ma vie à être codeur moi-même, à tous les niveaux, vous savez, que ce soit comme vous l'avez dit, assis sur la ligne de commande de la machine Unix, et dans certains cas, j'étais même impliqué dans quelques ports différents d'Unix d'une plate-forme matérielle à une autre. Et vous pouvez imaginer les défis que nous avons rencontrés là-bas. Mais la réalité est que voici cette carte de sortie de prison pour chaque codeur et scripteur dans le monde. C'est une science de fusée, littéralement, écrire vraiment serré à chaque fois, tout le temps, est une science de fusée. Et des histoires célèbres de gens comme Dennis Ritchie et Brian Kernahan travaillant indépendamment sur un morceau de code, puis se tournant vers une discussion de révision de code autour d'un café et découvrant qu'ils avaient écrit exactement le même morceau de code, exactement dans le même programme, exactement de la même manière. Et ils l'ont fait en C. Mais ce niveau de programmation puriste existe très rarement.

Le fait est que sur une base quotidienne, il n'y a que 24 heures par jour, sept jours par semaine, et nous devons simplement faire avancer les choses. Et donc, en ce qui concerne non seulement les programmeurs traditionnels, les administrateurs de base de données, les codeurs et les scripteurs, les administrateurs système, les administrateurs réseau, le personnel de sécurité, et tout le reste du côté des données citoyennes ces jours-ci; nous entendons, tout le monde essaie juste de faire son travail. Et donc je pense que le grand point à retenir de tout cela est que j'ai adoré votre démo et j'ai adoré le plat à emporter que vous nous avez laissé là-bas, il y a un instant, en parlant à Robin du fait que cela a une particularité - peut-être pas tellement une niche - mais un large espace auquel elle s'applique, en ce qui concerne la correction du code et du SQL et des bases de données. Mais j'étais vraiment excité de vous entendre dire que vous pouviez le piquer sur un script shell et trouver des problèmes, car vous savez, de nos jours, nous travaillons toujours au moindre coût sur tout.

La raison pour laquelle vous pouvez acheter une chemise à 6 $ quelque part, c'est parce que quelqu'un a construit un système suffisamment bon marché pour fabriquer, expédier et livrer, vendre et vendre au détail et accepter les paiements en ligne pour obtenir cette chemise à 6 $. Et cela ne se produit pas si vous avez payé 400 000 $ par an pour écrire du code de la manière parfaite; c'est juste un développement complet. Donc, ce point, je suppose que l'une des questions que j'aimerais vraiment que vous nous donniez un peu plus d'informations, c'est 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 et rechercher des problèmes de performances? D'abord, historiquement, d'où viennent-ils? S'agit-il des 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, qu'ils connaissent, qui font simplement avancer les choses pour terminer le travail et le sortir par la porte? Et avons-nous parfois besoin d'une carte de sortie de prison? Ai-je raison de penser qu'historiquement, nous avions une orientation et un développement plus techniques? Que maintenant, nous obtenons moins, comme l'a dit Robin, une approche académique, et maintenant c'est du code autodidacte, ou du copier-coller, ou tout simplement faire construire les choses? Et cela correspond-il au type de personnes qui prennent le produit en ce moment?

Bert Scalzo: Oui, exactement. Et je vais vous donner un exemple très précis, nous voulons juste faire le travail, parce que 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 recherche une réponse qui est assez bonne dans un délai raisonnable, c'est donc 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 ainsi que je le ferais, parce que je ne le vois pas comme une perte de temps - ce qui se passe est maintenant que cela se fait plus tard, parfois, pendant les tests d'intégration ou les tests de résistance, si nous sommes chanceux. Mais la plupart du temps, cela fait partie d'une escalade, où quelque chose est entré en production, il a fonctionné pendant un certain temps, peut-être même pendant des années, et maintenant il ne fonctionne pas bien, et maintenant nous allons le profiler. Et cela semble être le scénario le plus courant maintenant.

Dez Blanchfield: Oui, et je pense que le terme «dette technique» est probablement celui que vous connaissez bien; Je connais Robin et je le suis certainement. Je pense que de nos jours, en particulier dans les approches agiles de développement et de construction de systèmes, pour moi, le concept de dette technique est maintenant une chose très réelle, et nous en tenons compte dans les projets. Je sais, je veux dire, nous avons nos propres projets comme Media Lens et d'autres, où nous avons du codage au quotidien, et diverses choses à travers le groupe Bloor. Et chaque fois que nous construisons quelque chose, nous regardons en quelque sorte, je le regarde, et je regarde toujours du point de vue de ce que cela va me coûter pour résoudre ce problème maintenant, par rapport à ce que je peux simplement le faire dans le peut et le faire sortir, puis regardez et voyez si cette chose va se casser. Et hériter de cette dette technique que je sais que je devrai revenir en arrière plus tard et réparer.

Et je veux dire, je l'ai fait 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é sur le serveur Mongo, ce qui fait bien sûr, c'est agréable et propre et sécurisé, mais il obtient simplement la requête dont j'ai besoin, sachant que j'ai besoin de cette fonction pour fonctionner, pour accéder au plus grand puzzle; c'est là que ma vraie douleur est. Et donc vous contractez cette dette technique, et je pense que ce n'est pas seulement une chose occasionnelle, je pense que cela fait partie de l'ADN du développement maintenant. Les gens acceptent simplement - et non de manière fallacieuse - que la dette technique est un type normal de problème de mode opératoire, et ils n'ont qu'à l'endurer. C'est là que vous contractez la dette technique. Et je pense que la grande chose à propos de ce que vous nous avez montré dans la démo était que vous pouvez littéralement profiler et regarder combien de temps quelque chose prend pour fonctionner. Et c'est probablement l'une de mes choses préférées. Je veux dire, j'ai en fait construit des outils de profilage - nous avions l'habitude de construire des outils dans Sed et Lex et Orc pour exécuter notre code et voir où étaient les boucles, avant que des outils comme celui-ci ne soient disponibles - et quand vous avez construit du code pour aller révisez 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 en occupe plus que tout autre? Voir comme une masse …

Bert Scalzo: Oh oui, j'ai … Je vais faire une analogie pour vous et vous montrer que les non-programmeurs le font tout le temps. Parce que si j'enseigne un débogueur et un cours ou une session de profilage, je demanderai aux gens: «OK, combien de personnes ici vont dans Microsoft Word et n'utilisent jamais délibérément le correcteur orthographique?» Et personne ne lève la main, parce que pour la rédaction de documents, nous savons tous que nous pouvons faire des erreurs en anglais, et donc tout le monde utilise le correcteur orthographique. Et j'ai dit: «Eh bien, comment se fait-il que lorsque vous écrivez du texte dans votre IDE comme Visual Basic, vous n'utilisez 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, l'un, ODF, mon préféré avec Eclipse est juste de copier-coller du code là-bas et d'aller chercher des choses qui viennent juste de surligner immédiatement et de réaliser que j'ai fait une faute de frappe dans 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 et de le regarder plus tard, ce qui est plutôt agréable de le voir d'avance. Mais oui, c'est une excellente analogie de simplement mettre du texte dans un traitement de texte, car c'est un réveil intéressant qui, réalisez juste que vous avez fait quelques fautes de frappe ou même une erreur de grammaire, non?

Bert Scalzo: Exactement.

Dez Blanchfield: Donc, voyez-vous plus de hausse maintenant, je suppose, je veux dire, la dernière question de moi, avant de passer à notre Q&R peut-être, pour nos participants. Si vous deviez faire une sorte de recommandation concernant l'approche à suivre - je suppose que c'est rhétorique - est-ce le cas que vous interveniez tôt et que vous mettiez cela en œuvre pendant votre développement, avant de développer? Ou est-ce le cas où vous commencez principalement à construire, à bouger, à construire quelque chose, puis à le profiler plus tard? Je soupçonne que c'est le cas d'entrer tôt et de vous assurer que votre code est propre à l'avance. Ou est-ce un cas où ils devraient envisager cette partie de leur post-déploiement?

Bert Scalzo: Idéalement, ils le feraient d'avance, mais parce que tout le monde est dans le monde bruyant où ils doivent juste faire avancer les choses, ils ont tendance à ne pas le faire jusqu'à ce qu'ils rencontrent un problème de performance qu'ils ne peuvent pas résoudre par ajouter plus de CPU 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é auparavant que cela peut être exécuté de n'importe où et que vous pouvez parler à la base de données à l'arrière. Donc, cela est à l'aise avec le genre de concept bimodal dont nous parlons maintenant, de cloud sur site / hors site, par l'apparence des choses également, à la fin de la journée, s'il peut parler au back-end et voir le code, il s'en fiche vraiment, n'est-ce pas?

Bert Scalzo: Exactement, oui, vous pouvez exécuter cela dans le cloud.

Dez Blanchfield: Excellent, car je pense que c'est un peu là où va notre nouveau monde courageux. Alors, Eric. Je vais vous renvoyer maintenant et voir que nous avons quelques questions ici et je veux que nos participants restent avec nous, même si nous avons dépassé l'heure.

Eric Kavanagh: Oui, il y a quelques personnes là-bas, je vais juste faire un petit commentaire: Bert, je pense que la métaphore, l'analogie que vous donnez à l'utilisation de la vérification orthographique est franchement brillante. Franchement, cela mérite un ou deux blogs, car c'est un bon moyen de définir le contexte de ce que vous faites, de sa valeur et de la manière dont il devrait être recommandé d'utiliser un débogueur. sur une base régulière, non? Je parie que vous faites hocher la tête lorsque vous la jetez, non?

Bert Scalzo: Absolument, car ce que je leur dis, c'est: «Pourquoi dois-je effectuer une vérification orthographique de mes documents? Je ne veux pas être gêné par des erreurs d'orthographe stupides. »Eh bien, ils ne veulent pas être gênés par des erreurs de codage stupides!

Eric Kavanagh: D' accord. Oui en effet. Eh bien, les amis, nous avons brûlé une heure et cinq minutes ici, merci beaucoup à vous tous pour votre temps et votre attention. Nous archivons tous ces chats Web, n'hésitez pas à revenir à tout moment et à les vérifier. Le meilleur endroit pour trouver ces liens est probablement techopedia.com, nous allons donc l'ajouter à cette liste ici.

Et avec cela, nous allons vous dire adieu, les amis. Encore une fois, beau travail, Bert, grâce à nos amis de l'IDERA. Nous vous parlerons la prochaine fois, nous vous parlerons la semaine prochaine, en fait. Prends soin de toi! Bye Bye.