Por Techopedia Staff, 15 de março de 2017
Takeaway: O anfitrião Eric Kavanagh discutiu a depuração e criação de perfis de banco de dados com o Dr. Robin Bloor, Dez Blanchfield e Bert Scalzo do IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Ok, senhoras e senhores, são 4:00 da manhã no leste de uma quarta-feira, e é claro que isso significa.
Robin Bloor: Não consigo ouvi-lo, Eric.
Eric Kavanagh: Eu estive lá dias atrás, então você não está sozinho. Mas o tópico hoje é realmente interessante. É o tipo de coisa que você quer ter certeza de que está acontecendo em segundo plano na sua empresa, a menos que você seja a pessoa que faz isso; nesse caso, você quer ter certeza de que está fazendo isso corretamente. Porque estamos falando de depuração. Ninguém gosta de bugs, ninguém gosta quando o software para de funcionar - as pessoas ficam chateadas, os usuários não são amigáveis. Isso não é bom. Então, falaremos sobre "Resposta rápida: depuração e criação de perfil do banco de dados para o Rescue".
Há um ponto sobre o seu verdadeiramente, me encontre no Twitter, @eric_kavanagh, é claro.
Este ano é quente. E a depuração será quente, não importa o quê. Será realmente um desses problemas que nunca desaparecerá, não importa quão bom seja esse tipo de coisa, sempre haverá problemas; portanto, a chave é como chegar aonde você pode resolver esses problemas rapidamente? Idealmente, você tem ótimos programadores, ótimos ambientes, onde não há muita coisa errada, mas como diz o velho ditado, “Acidentes acontecem nas melhores famílias”. E o mesmo vale para as organizações. Então, essas coisas acontecem, vai acontecer, a pergunta é qual será a sua solução para lidar com isso e resolver esses problemas?
Ouviremos o Dr. Robin Bloor, então nosso próprio Dez Blanchfield de baixo e, é claro, nosso bom amigo, Bert Scalzo, da IDERA. E, na verdade, vou entregar as chaves para Robin Bloor e levá-las embora. O chão é seu.
Robin Bloor: OK. Este é um tópico interessante. Eu pensei que, como Dez provavelmente continuará falando sobre as técnicas reais e as histórias de guerra sobre depuração, pensei em fazer uma discussão em segundo plano para que possamos ter uma imagem completa do que está acontecendo. Eu fiz isso por um longo tempo e costumava ser um codificador, então é como se eu estivesse quase tentado com esta apresentação a começar a falar sobre a idéia de código aberto, mas achei que deixaria isso para outra pessoa.
Aqui está uma lista de bugs famosos, e a maioria deles chega à lista de ninguém, basicamente, todos, exceto os dois últimos, que custam pelo menos US $ 100 milhões. O primeiro foi o Mars Climate Orbiter, se perdeu no espaço e foi por causa de um problema de codificação, onde as pessoas confundiam unidades métricas com (risos) pés e polegadas. No Ariane Five Flight 501, havia uma incompatibilidade entre um motor que foi ligado e os computadores que deveriam estar rodando o foguete quando foi lançado. Várias falhas de computador, foguetes explosivos, manchetes. Gasoduto soviético em 1982, considerado a maior explosão da história do planeta; Não tenho certeza se é. Os russos roubaram algum software de controle automatizado, e a CIA percebeu que eles fariam isso e colocaram bugs nele, e os soviéticos o implementaram sem testar. Então, explodiu um oleoduto, achou divertido.
O worm Morris foi um experimento de codificação, que de repente se tornou um worm voraz que percorreu todo mundo - aparentemente causou US $ 100 milhões em danos; isso é uma estimativa, é claro. A Intel cometeu um erro famoso com um chip de matemática - uma instrução matemática sobre o chip Pentium em 1993 - que deveria custar mais de US $ 100 milhões. O programa Maps da Apple é possivelmente o pior e mais desastroso lançamento de tudo o que a Apple já fez. As pessoas que tentaram usá-lo foram, quero dizer, alguém dirigindo pela 101, e descobriram que o Apple Map dizia que elas estavam no meio da baía de São Francisco. Então, as pessoas começaram a se referir ao aplicativo Apple Maps como iLost. A - nossa maior interrupção em 1990 - é apenas interessante do ponto de vista do custo de algo assim - a AT&T ficou fora por cerca de nove horas e custou cerca de US $ 60 milhões em chamadas de longa distância.
E eu estava em uma companhia de seguros do Reino Unido, e o banco de dados implementou uma nova versão do banco de dados e ele começou a limpar os dados. E lembro-me disso muito bem, porque fui chamado depois para participar de algum tipo de seleção de banco de dados por causa disso. E foi muito interessante que eles tivessem feito uma nova versão do banco de dados e tivessem uma bateria de testes que fizeram para novas versões do banco de dados e que foram aprovados em todos os testes. Ele encontrou uma maneira realmente obscura de limpar dados.
Então, enfim, é isso. Eu pensei em falar sobre a incompatibilidade de impedância e o SQL emitido. É interessante que os bancos de dados relacionais armazenem dados em tabelas e codificadores tendem a manipular dados em estruturas de objetos que realmente não mapeiam muito bem as tabelas. E por causa disso, você recebe o que chamamos de incompatibilidade de impedância e alguém precisa lidar com isso de uma maneira ou de outra. Mas o que realmente acontece, porque um modelo, o modelo do codificador e o banco de dados outro modelo, não estão particularmente alinhados. Você recebe bugs que simplesmente não aconteceriam se a indústria tivesse construído coisas que funcionam juntas, o que eu acho hilário. Então, basicamente, do lado dos codificadores, quando você obtém hierarquias, podem ser tipos, conjuntos de resultados, pode ter uma fraca capacidade de API, pode haver muitas coisas que simplesmente descartam as coisas em termos de interação com o banco de dados. Mas a coisa mais importante para mim é realmente interessante; sempre me surpreendeu que você tivesse essa barreira SQL, que também é um tipo de impedância, de forma que os codificadores e o banco de dados trabalham uns com os outros. Portanto, o SQL possui reconhecimento de dados, o que é bom e DML para seleção, projeto e associação, o que é bom. Você pode oferecer muita capacidade em termos de obter dados do banco de dados com isso. Mas tem muito pouca linguagem matemática para fazer as coisas. Tem um pouco disso e daquilo, e tem muito pouco material baseado em tempo. E por isso, o SQL é um meio imperfeito, se você preferir, de obter os dados. Portanto, o pessoal do banco de dados construiu procedimentos armazenados para residir no banco de dados e o motivo dos procedimentos armazenados que estavam lá era que você realmente não queria lançar dados para um programa.
Como parte da funcionalidade era extremamente específica dos dados, não se tratava apenas de integridade referencial e exclusões em cascata e coisas assim, o banco de dados estava cuidando de repente, você colocava a funcionalidade em um banco de dados, o que significava obviamente que a funcionalidade de um aplicativo pode ser dividida entre o codificador e o próprio banco de dados. E isso tornou o trabalho de implementar alguns tipos de funções realmente bastante difícil e, portanto, mais propenso a erros. Então, esse é um lado do jogo de banco de dados, porque significa que você teve muitas implementações, por exemplo, que eu estive envolvido em bancos de dados relacionais, há realmente uma enorme quantidade de código que fica nos procedimentos armazenados que são manipulados separadamente do código que fica nos aplicativos. E parece uma coisa muito estranha, é suposto ser bastante inteligente em fazer várias coisas.
Pensei em falar também sobre o desempenho do banco de dados porque os erros de desempenho são frequentemente considerados bugs, mas basicamente você pode ter um gargalo na CPU, na memória, no disco, na rede e pode ter problemas de desempenho devido ao bloqueio . A idéia seria que o codificador não precisasse realmente se preocupar com o desempenho e que o banco de dados tivesse um desempenho razoavelmente bom. Ele deveria ser projetado para que o codificador não precise saber. No entanto, o design do banco de dados é ruim, o design do programa é ruim, a simultaneidade na mistura de carga de trabalho, o que também pode levar a problemas de desempenho. Você obtém balanceamento de carga, planejamento de capacidade, aumento de dados - que podem fazer com que um banco de dados pare ou diminua a velocidade. É interessante, quando os bancos de dados ficam quase cheios, diminuem a velocidade. E você pode ter problemas com as camadas de dados em termos de replicação e a necessidade de replicar e a necessidade de fazer backup e recuperação. Enfim, essa é uma visão geral.
A única coisa que eu gostaria de dizer é que a depuração do banco de dados pode ser tão onerosa e não trivial - e digo isso porque já fiz muito disso - e você frequentemente descobrirá que é como todas as situações na depuração que eu já experiente é, é a primeira coisa que você vê é uma bagunça. E você tem que tentar ir da bagunça para descobrir como a bagunça surgiu. E, muitas vezes, quando você olha para um problema no banco de dados, tudo o que você vê são dados corrompidos e pensa: "Como diabos isso aconteceu?"
Enfim, vou passar para Dez, que provavelmente vai dizer mais palavras de sabedoria do que eu saí. Não sei como passar a bola para você, dez.
Eric Kavanagh: Eu vou passar, aguarde, aguarde.
Voz automatizada: as linhas dos participantes silenciadas.
Eric Kavanagh: Tudo bem, espere um segundo, deixe-me dar a bola a Dez.
Dez Blanchfield: Obrigado, Eric. Sim, Dr. Robin Bloor, você está realmente mais correto: este é um tópico, um urso de insetos ao longo da vida se você perdoar o trocadilho, desculpe, eu não pude evitar isso. Espero que você possa ver minha primeira tela lá, minhas desculpas pelo problema de tamanho da fonte na parte superior. O tópico dos bugs é uma palestra de um dia inteiro, em muitos casos na minha experiência. É um tópico tão amplo e amplo, por isso vou focar em duas áreas principais, especificamente o conceito do que consideramos um bug, mas uma questão de programação. Acho que hoje em dia a introdução de um bug em si geralmente é detectada pelos ambientes de desenvolvimento integrados, embora possam ser erros de longa duração. Mas geralmente é mais um caso de código de criação de perfil e é possível escrever código que funcione, que deve ser um bug. Então, no slide do meu título aqui, eu realmente tinha uma cópia disso em uma resolução muito alta A3, mas infelizmente ela foi destruída em uma mudança de casa. Mas esta é uma nota manuscrita em uma planilha de programação de cerca de 1945, onde supostamente algumas pessoas da Universidade de Harvard nos EUA, sua segunda construção de uma máquina chamada Mark II. Eles estavam depurando algum problema, em linguagem comum, mas estavam tentando encontrar uma falha, e acontece que algo um pouco diferente do que era um hardware e supostamente um problema de software apareceu.
Então, o mito urbano é que, por volta de 9 de setembro de 1945, uma equipe da Universidade de Harvard estava desmontando uma máquina, eles encontraram algo que chamavam de "relé setenta" - naqueles dias a programação era feita no sentido físico, você codifica ao redor de uma placa, e foi assim que você efetivamente programou a máquina - e eles descobriram que esse relé número setenta havia algo errado com ela, e o termo "bug" surgiu porque era literalmente uma mariposa - supostamente havia uma mariposa presa entre um pedaço de fio de cobre que ia de um lugar para outro. E a história diz que a lendária Grace Hopper como esta legenda, para o meu slide-título, “primeiro caso real de um bug encontrado” cita entre aspas.
Mas, como Robin destacou no início de seu primeiro slide, o conceito de bug remonta à medida que podemos imaginar humanos fazendo computação, conceitos como um patch. O termo "patch" veio de um pedaço de fita real sendo gravado em um buraco em um cartão perfurado. Mas o ponto principal disso é que o termo "depuração" surgiu desse conceito de encontrar um bug em uma máquina física. Desde então, usamos essa terminologia para tentar lidar com problemas, não tanto como codificar problemas em um programa que não é compilado, mas como um programa que não funciona bem. E, especificamente, não foi criado o perfil, basta encontrar coisas como loops intermináveis que simplesmente não levam a lugar algum.
Mas também temos um cenário, e pensei em colocar alguns slides engraçados antes de entrar em mais detalhes. Aqui está o desenho animado clássico, chamado XKCD na Web, e o cartunista tem algumas visões muito engraçadas do mundo. E este é sobre um garoto chamado "Little Bobby Tables" e supostamente seus pais chamaram esse garoto de Robert); DROP TABLE Alunos; - e é chamado, e meio que “Olá, esta escola do seu filho está com problemas no computador”, e os pais respondem: “Oh, querido, ele quebrou alguma coisa?” E o professor diz: “Bem, de certa forma ”, e o professor pergunta, “ você realmente nomeou seu filho Robert '); DROP TABLE Alunos; -? ”E os pais dizem:“ Ah, sim, pequenas mesas de Bobby, nós o chamamos. ”De qualquer forma, eles continuam dizendo que agora perderam os registros dos alunos do ano, espero que você esteja feliz. E a resposta é: "Bem, você deve limpar e higienizar as entradas do banco de dados". E eu uso isso muitas vezes para falar sobre alguns dos problemas que temos ao encontrar coisas no código, que geralmente o código não analisa os dados também.
Outro engraçado, eu não sei se isso é real ou não - eu suspeito que seja uma paródia - mas, novamente, também toca meu osso engraçado. Alguém trocando a placa na frente do carro, para uma afirmação semelhante que faz com que os bancos de dados caiam nos radares de velocidade e assim por diante que capturam as placas dos carros. E sempre me refiro a isso como duvido que qualquer programador tenha antecipado o sucesso de seu código por um veículo a motor real, mas nunca subestime isso - o poder de um nerd zangado.
(Riso)
Mas isso me leva ao meu ponto-chave, eu acho, e é que, uma vez, poderíamos depurar e criar um perfil de código como meros mortais. Mas sou muito convencido de que esse tempo passou e, em minha experiência, o primeiro - e isso me envelhece terrivelmente, tenho certeza; Robin, você é bem-vindo a zombar de mim por isso - mas historicamente eu venho de uma formação aos 14 anos, vagando pelo fim da cidade e batendo na porta de um data center chamado "Data Com" em Nova York. Zelândia e perguntando se eu poderia ganhar dinheiro na escola, levando o ônibus atrasado para casa, cerca de 25 km de viagem todos os dias, colocando papel em impressoras e fitas em unidades de fita, e apenas sendo um administrador geral. E, curiosamente, eles me deram um emprego. Mas, com o tempo, consegui entrar na equipe, localizei os programadores e percebi que adorava codificar e passei pelo processo de execução de scripts e tarefas em lote, que no final do dia ainda é código. Você precisa escrever scripts e tarefas em lotes que se pareçam com mini programas e, em seguida, passar por todo o processo de ficar sentado em um terminal 3270, escrevendo o código manualmente.
De fato, minha primeira experiência foi em um terminal de teletipo, que na verdade era uma impressora física de 132 colunas. Essencialmente, pense como uma máquina de escrever muito antiga, com papel que a rolava, porque eles não tinham um tubo CRT. E o código de depuração foi um problema não trivial, então você tendeu a escrever todo o código manualmente e a agir como um datilógrafo, fazendo o possível para não erros, pois é extremamente frustrante ter que dizer o editor de uma linha para ir para uma determinada linha e depois imprimir a linha e digitar novamente. Mas uma vez, foi assim que escrevemos o código e foi assim que depuramos, e ficamos muito, muito bons nisso. E, de fato, nos forçou a ter ótimas técnicas de programação, porque era um verdadeiro aborrecimento corrigi-lo. Mas a jornada prosseguiu - e todos estamos familiarizados com isso - passou da experiência do terminal 3270 no meu mundo, até o Digital Equipment VT220, onde você podia ver as coisas na tela, mas, novamente, você estava fazendo a mesma coisa você gravou na fita de papel o formato impresso apenas em um CRT, mas conseguiu excluir mais facilmente e não teve o som de "dit dit dit dit".
E então você sabe, os terminais Wyse - como o Wyse 150, provavelmente a minha interface favorita para um computador de todos os tempos - e depois o PC e depois o Mac, e hoje em dia GUIs e IDs modernos baseados na Web. E uma variedade de programas por meio disso, programação em um e assembler e PILOT e Logo e Lisp e Fortran e Pascal e linguagens que podem fazer as pessoas se encolherem. Mas essas são linguagens que o forçaram a escrever um bom código; eles não deixaram você escapar de más práticas. C, C ++, Java, Ruby, Python - e nós avançamos mais nessa etapa de programação, nos tornamos mais parecidos com scripts, nos aproximamos cada vez mais da Linguagem de Consulta Estruturada e de linguagens como PHP, que realmente são usadas para invocar o SQL. O ponto de dizer que, vindo da minha formação, fui autodidata de várias maneiras e aquelas que me ajudaram a aprender, ensinaram-me muito boas práticas de programação e muito boas práticas em torno de design e processos para garantir que não aprendi. introduzir código de buggy.
Atualmente, métodos de programação, coisas como, por exemplo, Structured Query Language, SQL, são uma linguagem de consulta simples e muito poderosa. Mas nós o transformamos em uma linguagem de programação e eu realmente não acredito que o SQL tenha sido projetado para ser uma linguagem de programação moderna, mas nós a inclinamos para se tornar isso. E isso introduz um monte de problemas, porque quando pensamos em dois pontos de vista: do ponto de vista da codificação e do ponto de vista do DBA. É muito fácil aparecer e apresentar bugs para coisas como apenas técnicas de programação ruins, esforços preguiçosos para escrever código, falta de experiência, a irritação clássica que eu tenho, por exemplo, com pessoas do SQL pulando no Google e procurando por algo e encontrando um site que seja obteve um exemplo e copiou e colou o código existente. E, em seguida, replicar uma má codificação, prática incorreta e colocá-la em produção, porque isso lhes dá os resultados desejados. Você tem outros desafios, por exemplo, hoje em dia estamos todos correndo para isso, o que chamamos de corrida zero: tentando fazer tudo tão barato e tão rápido, que temos um cenário em que não empregamos menos pessoal remunerado. E não quero dizer isso de uma maneira dissimulada, mas não estamos contratando especialistas para todos os trabalhos possíveis. Era uma vez algo a ver com computadores era ciência de foguetes; estava envolvido em coisas que eram estrondosas e muito barulhentas, ou que entravam no espaço ou os engenheiros eram homens e mulheres altamente qualificados, formados e com educação rigorosa que os impedia de fazer coisas malucas.
Hoje em dia, muitas pessoas entram no desenvolvimento, no design e no banco de dados que não tiveram anos de experiência, não tiveram necessariamente o mesmo treinamento ou suporte. E assim você termina com um cenário apenas do amador tradicional versus especialista. E há uma frase famosa, na verdade não consigo lembrar quem criou a cotação, a frase diz: “Se você acha caro contratar um especialista para fazer um trabalho, espere até contratar um casal de amadores que criam um problema e você precisamos limpá-lo. ”E, portanto, o SQL tem esse problema, e é muito, muito fácil de aprender, é muito fácil de usar. Mas não é, a meu ver, uma linguagem de programação perfeita. É muito fácil fazer coisas como selecionar uma estrela de qualquer lugar e colocar tudo isso em uma linguagem de programação com a qual você se sinta mais confortável, como PHP e Ruby ou Python, e usar a linguagem de programação com a qual você está familiarizado nativamente. a manipulação de dados, em vez de fazer uma consulta mais complexa no SQL. E vemos muito isso, e as pessoas se perguntam por que o banco de dados está lento; é porque um milhão de pessoas está tentando comprar um ingresso de um sistema de venda on-line, onde faz uma estrela selecionada de qualquer lugar.
Agora, esse é um exemplo realmente extremo, mas você entende tudo isso. Então, para realmente enfatizar esse ponto, aqui está um exemplo que eu carrego muito. Sou um grande fã de matemática, amo a teoria do caos, amo os cenários de Mandelbrot. No lado direito, há uma versão do conjunto de Mandelbrot, com a qual tenho certeza de que todos estamos familiarizados. E, à esquerda, há um pedaço de SQL que processa isso. Agora, toda vez que coloco isso em uma tela em algum lugar, ouço o seguinte: “Oh meu Deus, alguém processou a série Mandelbrot com SQL, está falando sério? Isso é loucura! ”Bem, o ponto principal disso é ilustrar o que eu estava descrevendo lá, e isso é sim, na verdade, agora você pode programar quase tudo em SQL; é uma linguagem de programação moderna muito desenvolvida, poderosa e moderna. Quando originalmente era uma linguagem de consulta, foi projetada apenas para obter dados. Portanto, agora temos construções muito complexas e procedimentos armazenados, temos a metodologia de programação aplicada a uma linguagem e, portanto, é muito fácil para práticas de programação ruins, falta de experiência, código de copiar e colar, funcionários mal pagos tentando ser funcionários bem pagos, pessoas fingindo que sabem, mas precisam aprender no trabalho.
Todo um conjunto de coisas em que o perfil de código e o que chamamos de depuração, que não é tanto encontrar bugs que impedem o funcionamento dos programas, mas bugs que estão prejudicando o sistema e o código mal estruturado. Quando você olha para esta tela agora e pensa que é fofo, você pensa: “Uau, que gráfico maravilhoso, eu adoraria rodar isso.” Mas imagine isso rodando em alguma lógica de negócios . Parece bem legal, mas fala uma teoria matemática do caos renderizada graficamente, mas quando você pensa sobre o que poderia ser usado em alguma lógica de negócios, você obtém a imagem rapidamente. E para ilustrar isso - e sinto muito, as cores estão invertidas, deveria ser um plano de fundo preto e texto verde para ser uma tela verde, mas você ainda pode ler isso.
Analisei rapidamente um exemplo do que você poderia fazer se fosse realmente louco e não tivesse nenhuma experiência e viesse de um background diferente de programação e aplicasse C ++ ao SQL, para ilustrar meu ponto antes. Entrego ao IDERA nosso convidado instruído. Essa é uma consulta estruturada escrita como C ++, mas codificada em SQL. E ele realmente é executado, mas é executado por um período de três a cinco minutos. E retira ostensivamente uma linha de dados de vários bancos de dados, várias junções.
Novamente, o ponto principal disso é que, se você não possui as ferramentas corretas, se não possui plataformas e ambientes corretos para capturar essas coisas, elas entram em produção e você tem 100.000 pessoas atingindo um sistema todos os dias, horas ou minutos, muito em breve você acaba com uma experiência em Chernobyl, na qual o grande ferro começa a derreter e a enterrar-se no centro do planeta, porque esse código nunca deve entrar em produção. Seus sistemas e suas ferramentas, desculpe-me, devem entender isso antes que chegue perto - mesmo através do processo de teste, mesmo através do UAT e da integração de sistemas, esse trecho de código deve ser escolhido e destacado e alguém deve ser deixado de lado e dizendo: “Olha, esse é um código muito bonito, mas vamos obter um DBA para ajudá-lo a criar essa consulta estruturada corretamente, porque, francamente, isso é desagradável.” E a URL está lá, você pode ir dar uma olhada - é conhecido como consulta SQL mais complexa que você já escreveu. Porque acredite, isso realmente compila, ele corre. E se você recortar e colar isso e apenas zombar do banco de dados, é algo a se observar; se você tiver as ferramentas para assistir ao banco de dados, tente derreter por um período de três a cinco minutos, para retornar o que é uma linha de texto.
Então, para resumir, com isso em mente, toda a minha experiência em codificação me ensinou que você pode dar uma arma às pessoas e, se elas não tomarem cuidado, elas vão dar um tiro no próprio pé; o truque é mostrar a eles onde está o mecanismo de segurança. Com as ferramentas certas e o software certo ao seu alcance, depois de fazer a codificação, você pode revisar seu código, encontrar problemas criando um perfil do código, encontrar bugs efetivamente não intencionais que são problemas de desempenho e, como eu disse anteriormente, era uma vez, você podia fazer isso olhando para uma tela verde. Você não pode mais; existem centenas de milhares de linhas de código, dezenas de milhares de aplicativos implantados, milhões de bancos de dados em alguns casos e até super-humanos não conseguem mais fazer isso manualmente. Você literalmente precisa do software certo e das ferramentas certas na ponta dos dedos e da equipe para usá-las, para poder encontrar esses problemas e resolvê-los muito, muito rapidamente, antes de chegar ao ponto, enquanto o Dr. Robin Bloor destacou: as coisas se tornam desastrosas e as coisas explodem, ou mais comumente, elas começam a custar-lhe muito dinheiro e muito tempo e esforço, destruindo o moral e outras coisas, quando não conseguem entender por que as coisas acontecem. muito tempo para correr.
E com isso em mente, vou passar para o nosso convidado e estou ansioso para saber como eles resolveram esse problema. E particularmente a demo que acho que estamos prestes a receber. Eric, eu vou voltar.
Eric Kavanagh: OK, Bert, leve embora.
Bert Scalzo: OK, obrigado. Bert Scalzo, da IDERA, sou o gerente de produto de nossas ferramentas de banco de dados. E eu vou falar sobre depuração. Eu acho que uma das coisas mais importantes que Robin disse anteriormente - e é verdade que a depuração é onerosa e não trivial, e quando você vai para a depuração de banco de dados, é uma ordem de magnitude ainda mais onerosa e não trivial - então, isso foi uma citação importante.
ESTÁ BEM. Eu queria começar com o histórico de programação, porque muitas vezes vejo pessoas que não estão depurando, elas não usam um depurador, apenas programam com o idioma que estão usando e muitas vezes me dizem, “Bem, essas coisas de depurador são novas e ainda não começamos a usá-las.” E então o que faço é mostrar a eles esse gráfico da linha do tempo, tipo de pré-história, idade avançada, idade média, é gentil digamos onde estávamos em termos de linguagens de programação. E nós tínhamos idiomas muito antigos a partir de 1951 com código assembly, Lisp, FACT e COBOL. Em seguida, entramos no próximo grupo, Pascals e Cs, e depois no próximo grupo, os C ++ s, e observamos onde está esse ponto de interrogação - esse ponto de interrogação está aproximadamente entre 1978 e talvez 1980. Em algum lugar desse intervalo depuradores disponíveis para nós e, por assim dizer, "Ei, eu não estou usando um depurador, porque isso é uma daquelas coisas novas", então você deve ter começado a programar, sabe, nos anos 50, porque esse é o única maneira de se safar dessa alegação.
Agora, a outra coisa engraçada neste gráfico é que Dez acabou de comentar sobre Grace Hopper, eu realmente conhecia Grace, então é meio engraçado. E a outra coisa de que eu ri é que ele falou sobre teletipos e eu fico sentado dizendo: “Cara, esse foi o maior salto que já tivemos em produtividade, quando passamos de cartões para teletipos, esse foi o maior salto de todos os tempos. ”Então, e eu programei em todos os idiomas aqui, incluindo o SNOBOL, que ninguém nunca ouviu falar antes, era um CDC, Control Data Corporation, então acho que estou ficando um pouco velho demais para esse setor .
Dez Blanchfield: Eu ia dizer que você nos envelheceu terrivelmente lá.
Bert Scalzo: Sim, estou lhe dizendo, me sinto como o vovô Simpson. Então, eu olho para a depuração e há diferentes maneiras de fazer a depuração. Você pode estar falando sobre o que todos pensamos ser tradicional: entrar em um depurador e percorrer o código. Mas também, as pessoas instrumentarão seu código; é aí que você coloca instruções no seu código e, talvez, produza um arquivo de saída, um arquivo de rastreamento ou algo assim, e assim instrumenta seu código. Eu consideraria isso como depuração, é um pouco mais difícil, uma maneira de fazer isso, mas conta. Mas também temos a famosa declaração de impressão: você assiste e as pessoas realmente colocam declarações de impressão e eu realmente vi uma ferramenta em que - e é uma ferramenta de banco de dados - em que se você não sabe como usar um depurador, você aperta um botão e ele colará instruções de impressão em todo o código para você; quando terminar, aperta outro botão e as retira. Porque é assim que muitas pessoas depuram.
E a razão pela qual depuramos é dupla: primeiro, precisamos encontrar coisas que tornem nosso código ineficaz. Em outras palavras, normalmente isso significa que há um erro de lógica ou perdemos um requisito de negócios, mas o que é é que o código não é eficaz; não faz o que esperávamos que fizesse. Na outra vez em que fazemos a depuração, é por eficiência e isso pode ser um erro lógico, mas o que é é que fiz a coisa certa, mas não volta rápido o suficiente. Agora, afirmo isso porque um perfilador provavelmente é melhor para esse segundo cenário e vamos falar sobre depuradores e criadores de perfil. Além disso, existe esse conceito de depuração remota; isso é importante porque muitas vezes, se você está sentado no seu computador pessoal e está usando um depurador, que atinge um banco de dados em que o código é realmente executado no banco de dados, você está realmente fazendo o que é chamado de depuração remota. Você pode não perceber, mas é isso que está acontecendo. E então, é muito comum com esses depuradores ter pontos de interrupção, pontos de observação, entrar e passar por cima e algumas outras coisas comuns, que vou mostrar em um momento na tela.
Agora, criação de perfil: você pode criar perfis de várias maneiras diferentes. Algumas pessoas dirão que a carga de trabalho captura e reproduz onde captura tudo, o que conta como perfil. Minha experiência foi mais, melhor se for feita a amostragem. Não há razão para capturar todas as declarações, porque algumas podem ser executadas tão rapidamente que você não se importa, o que você realmente está tentando ver é: bem, quais são as que continuam aparecendo repetidamente, porque eles correm muito tempo. Portanto, algumas vezes o perfil pode significar amostragem, em vez de executar a coisa toda. E, normalmente, você obtém algum tipo de saída que pode usar, agora que pode ser visual dentro de um ambiente de desenvolvimento IDE, onde pode fornecer um histograma do desempenho das várias linhas de código, mas também pode ainda seja que ele produz um arquivo de rastreamento.
Os criadores de perfil apareceram pela primeira vez em 1979. Então, eles existem há muito tempo também. Ótimo para encontrar consumo de recursos ou problemas de desempenho, em outras palavras, o que é eficiência. De um modo geral, é separado e distinto do depurador, embora eu tenha trabalhado com depuradores que fazem as duas coisas ao mesmo tempo. E enquanto os criadores de perfil eu acho que são as mais interessantes das duas ferramentas, se eu sinto que poucas pessoas depuram, então definitivamente não há perfil suficiente, porque parece que um em cada dez depuradores fará o perfil. E isso é uma pena, porque o perfil pode realmente fazer uma enorme diferença. Agora, linguagens de banco de dados, como falamos anteriormente, você tem SQL - e meio que forçamos o pino redondo no buraco quadrado aqui e forçamos a se tornar uma linguagem de programação - e Oracle. Isso é PL / SQL - linguagem processual SQL - e SQL Server, é Transact-SQL, é SQL-99, é SQL / PSM - pois acho que é o Módulo Procedimento Armazenado. O Postgres fornece outro nome, DB2, outro nome, Informix, mas o ponto é que todo mundo forçou construções do tipo 3GL; em outras palavras, os loops FOR, nas declarações de variáveis e todas as outras coisas estranhas ao SQL agora fazem parte do SQL nessas linguagens. E assim, você precisa ser capaz de depurar um PL / SQL ou um Transact-SQL da mesma forma que faria com um programa do Visual Basic.
Agora, objetos de banco de dados, isso é importante porque as pessoas dirão: "Bem, que coisas eu tenho para depurar em um banco de dados?" E a resposta é: bem, tudo o que você pode armazenar no banco de dados como código - se eu estiver fazendo T-SQL ou PL / SQL - e estou armazenando objetos no banco de dados, provavelmente é um procedimento armazenado ou uma função armazenada. Mas também há gatilhos: um gatilho é como um procedimento armazenado, mas é acionado em algum tipo de evento. Agora, algumas pessoas em seus gatilhos colocam uma linha de código e chamam um procedimento armazenado para manter todos os seus códigos e procedimentos armazenados, mas é o mesmo conceito: ainda é o gatilho que pode iniciar tudo. E então, como Oracle, eles têm algo chamado pacote, que é como uma biblioteca, se você preferir. Você coloca 50 ou 100 procedimentos armazenados em um agrupamento, chamado de pacote, então é como uma biblioteca. Então, aqui está o depurador da maneira antiga; na verdade, é uma ferramenta que realmente entra e cola todas essas instruções de depuração no seu código para você. Portanto, em todos os lugares que você vê o bloco de depuração, não remova, o depurador automático inicia e rastreia, todos foram presos por alguma ferramenta. E as linhas fora disso, que são a minoria do código, bem, esse é o método de depuração não manual.
E a razão pela qual eu trouxe isso à tona é que, se você está tentando fazer isso manualmente, na verdade você digitará mais código de depuração para inserir todas essas instruções de impressão do que com o código. Portanto, embora isso possa funcionar e seja melhor do que nada, essa é uma maneira muito difícil de depurar, especialmente porque, e se levar 10 horas para que essa coisa funcione e onde houver um problema na linha três? Se eu estivesse fazendo uma sessão de depuração interativa, saberia na linha três - cinco minutos depois - ei, há um problema aqui, posso sair. Mas com isso, tenho que esperar a execução, até a conclusão e, em seguida, tenho que olhar para algum arquivo de rastreio que provavelmente tenha todas essas instruções de impressão e tentar encontrar a agulha no palheiro. Novamente, isso é melhor que nada, mas não seria a melhor maneira de trabalhar. Agora, é assim que esse arquivo se parece com o que veio do slide anterior; em outras palavras, eu executei o programa e há várias instruções de impressão nesse arquivo de rastreamento e posso ou não ser capaz de desviar isso e encontrar o que preciso encontrar. Então, novamente, não tenho tanta certeza de que é assim que você gostaria de trabalhar.
Agora, depuradores interativos - e se você usou algo como Visual Studio para escrever programas, ou Eclipse, teve depuradores e os usou com outros idiomas - simplesmente não pensou em usá-los aqui com seu banco de dados. E existem ferramentas por aí, como nosso DB Artisan e nosso Rapid SQL, aqui é o Rapid SQL, que possui um depurador, e você pode ver no lado esquerdo, eu tenho um procedimento armazenado chamado "check for duplicates". Basicamente, ele vai ver e ver se tenho várias linhas na tabela com o mesmo título de filme. Então, o banco de dados é para filmes. E você pode ver no lado direito, no terço superior, eu tenho o meu código-fonte no meio, o que é chamado de variáveis de relógio e minhas bandejas de pilha de chamadas e, em seguida, na parte inferior ' recebi algumas mensagens de saída. E o importante aqui é que, se você olhar por cima da primeira seta vermelha, se eu passar o mouse sobre uma variável, na verdade, posso ver qual valor está nessa variável naquele momento, enquanto passo o código. E isso é realmente útil, e então eu posso passar uma linha de cada vez através do código, não preciso dizer executar, eu poderia dizer uma linha, deixe-me ver o que aconteceu, outra linha, deixe-me ver o que aconteceu, e estou fazendo isso no banco de dados. E mesmo estando no Rapid SQL no meu PC e meu banco de dados esteja na nuvem, ainda posso fazer essa depuração remota e vê-la e controlá-la daqui, além de fazer a depuração como faria com qualquer outro idioma.
Agora, a próxima seta lá - você pode ver a pequena seta apontando para a direita, em direção à saída do DBMS, é onde está o meu cursor no momento - então, em outras palavras, eu pisei e é onde estou o momento. Então, se eu disser "passo de novo", vou para a próxima linha. Agora, logo abaixo, você verá o ponto vermelho. Bem, esse é um ponto de interrupção, que diz: "Ei, eu não quero ultrapassar essas linhas". Se eu quiser pular tudo e chegar onde esse ponto vermelho, eu posso apertar o botão de correr e ele vai correr daqui até o fim ou para um ponto de interrupção, se houver algum ponto de interrupção definido, e então ele será interrompido e deixe-me fazer o passo novamente. E a razão de tudo isso ser importante e poderoso é que, quando estou fazendo tudo isso, o que está acontecendo no meio e até no fundo - mas o mais importante é o meio - mudará e eu posso ver os valores das minhas variáveis, Posso ver o rastreamento da pilha de chamadas e todas essas informações são exibidas lá enquanto passo o código, para que eu possa ver e sentir e entender o que está acontecendo e como o código realmente está trabalhando em tempo de execução. E normalmente posso encontrar um problema, se houver, ou se sou bom o suficiente para detectá-lo.
OK, agora vou falar sobre um criador de perfil e, neste caso, é um criador de perfil que posso ver através de um depurador. Lembra que eu disse que às vezes eles são separados e às vezes eles podem ficar juntos? Nesse caso, e novamente, estou no Rapid SQL e posso ver que há uma margem, no lado esquerdo, ao lado dos números das linhas. E o que é isso, é o número de segundos ou microssegundos necessários para executar cada linha de código, e posso ver claramente que todo o meu tempo é gasto nesse loop FOR, onde estou selecionando tudo em uma tabela . E assim, o que quer que esteja acontecendo dentro desse loop FOR provavelmente é algo que eu preciso analisar e, se eu puder melhorar, pagará dividendos. Não vou obter nenhuma melhoria trabalhando nas linhas que possuem 0, 90 ou 0, 86; não há muito tempo gasto lá. Agora, neste caso, e novamente, eu estou no Rapid SQL, você está vendo como eu posso criar perfis misturados à minha depuração. Agora, o legal é que o Rapid SQL também permite que você faça o contrário. O Rapid SQL permite que você diga: “Você sabe o que? Não quero estar no depurador, só quero executar isso e depois quero olhar gráfica ou visualmente o mesmo tipo de informação. ”
E você pode ver que eu não estou mais no depurador e ele executa o programa e, após a execução, me fornece gráficos para me dizer as coisas, para que eu possa ver que tenho uma declaração que parece estar ocupando a maior parte do gráfico de setores circulares e, se eu olhar, vejo nessa grade na parte inferior da linha 23, há o loop FOR novamente: ele está ocupando mais tempo, na verdade está vermelho escuro mastigando todo o gráfico de setores circulares. E assim, essa é outra maneira de criar perfis. Por acaso chamamos isso de "analista de código" em nossa ferramenta. Mas é basicamente apenas um criador de perfil separado de um depurador. Algumas pessoas gostam de fazê-lo da primeira maneira, outras pessoas gostam de fazê-lo da segunda maneira.
Por que fazemos depuração e criação de perfil? Não é porque queremos escrever o maior código do mundo e obter um aumento de salário - esse pode ser o nosso motivo, mas não é esse o motivo - você prometeu aos negócios que faria algo corretamente, que seu programa será eficaz. É para isso que você usará o depurador. Além disso, usuários finais de negócios; eles não são muito pacientes: desejam resultados mesmo antes de pressionar a tecla. Nós devemos ler a mente deles e fazer tudo instantaneamente. Em outras palavras, tem que ser eficiente. E é para isso que usamos o criador de perfil. Agora, sem essas ferramentas, eu realmente acredito que você é esse cara de terno com arco e flecha e está atirando no alvo e está com os olhos vendados. Porque como você vai descobrir como um programa é executado apenas olhando para o código estático e como você vai descobrir qual linha é onde ele realmente gastaria mais tempo na execução, novamente, apenas olhando para o código estático? Uma revisão de código pode ou não exibir algumas dessas coisas, mas não há garantia de que uma revisão de código encontre todas elas. Usando um depurador e um criador de perfil, você poderá encontrar todos esses erros.
OK, vou fazer uma demonstração rápida aqui. Não é minha intenção empurrar o produto, apenas quero mostrar a você como é um depurador, porque muitas vezes as pessoas dizem: "Eu nunca vi um desses antes." E fica bonito nos slides da tela, mas como fica quando está em movimento? Então, aqui na minha tela, estou executando nosso produto DB Artisan; nós temos um depurador lá também. O DB Artisan é mais voltado para os DBAs, o Rapid SQL é mais para os desenvolvedores, mas vi desenvolvedores que usam DB Artisan e vi DBAs que usam Rapid. Portanto, não seja pego no produto. E aqui, eu tenho a opção de fazer uma depuração, mas antes de iniciar a depuração, extrairei esse código para que você possa ver como é o código antes de começar a executá-lo. Então, aqui está exatamente o mesmo código que estava no instantâneo da tela, esta é minha verificação de duplicatas. E eu quero depurar isso, então eu pressiono debug. E agora, leva um momento e você diz: “Bem, por que está demorando um pouco?” Lembre-se da depuração remota: a depuração está realmente acontecendo no meu servidor de banco de dados, não no meu PC. Então, foi preciso revisar e criar uma sessão por lá, criar uma coisa de depuração remota, conectar minha sessão a essa sessão de depuração remota e configurar um canal de comunicação.
Então, agora, aqui está minha flecha, está lá em cima, na linha um, é onde estou no código. E se eu pressionar o terceiro ícone, que é um passo em frente, você verá a seta se movendo e, se eu continuar pressionando, verá que ela se move. Agora, se eu quisesse ir até esse loop FOR, porque sei que é onde está o problema, posso definir um ponto de interrupção. Eu pensei em definir isso. Oh, dispara, eu tinha uma das minhas teclas de captura de tela mapeada para a mesma tecla do depurador, é isso que está causando a confusão. OK, então eu apenas defino manualmente um ponto de interrupção lá, então agora, em vez de dar um passo, passo, passo, passo até chegar lá, na verdade, posso apenas dizer: "Vá em frente e execute essa coisa", e ele irá parar. Observe que ele me moveu até o ponto de interrupção, então agora estou no contexto de executar esse loop, posso ver como todas as minhas variáveis estão definidas, o que não é uma surpresa, porque eu as inicializei todas para zero. E agora, posso entrar nesse loop e começar a ver o que está acontecendo dentro desse loop.
Então, agora ele fará uma contagem selecionada dos meus aluguéis e eu posso passar o mouse sobre esse cara e olhar, ele é dois, dois é maior que um, então provavelmente fará o próximo trecho deste código. Em outras palavras, encontrou algo. Eu só vou em frente e deixar isso correr. Eu não quero passar por tudo aqui; o que eu quero mostrar é que, quando um depurador é concluído, ele termina como um programa normal. Eu tenho o ponto de interrupção definido, então quando eu disse executar, ele voltou ao próximo ponto de interrupção. Estou deixando que funcione até o fim, porque o que eu quero que você veja é que um depurador não altera o comportamento do programa: quando terminar de executar, eu deveria obter exatamente os mesmos resultados se não o executasse dentro de um depurador.
E com isso, vou suspender a demo e voltar porque queremos ter tempo para perguntas e respostas. E assim, vou abri-lo para perguntas e respostas.
Eric Kavanagh: Tudo bem, Robin, talvez uma pergunta sua e depois um par de Dez?
Robin Bloor: Sim, claro, acho isso fascinante, é claro. Eu trabalhei com coisas assim, mas nunca trabalhei com algo assim no banco de dados. Você pode me dar uma idéia de para que as pessoas usam o criador de perfil? Porque é como eles estão olhando - porque eu presumo que eles estão - eles estão olhando para problemas de desempenho, isso ajudará você a distinguir entre quando um banco de dados leva tempo e quando um código leva tempo?
Bert Scalzo: Sabe, essa é uma pergunta fantástica. Digamos que estou trabalhando no Visual Basic e, dentro do meu Visual Basic, vou chamar um Transact-SQL ou um PL / SQL. Deixe-me fazer o PL / SQL, pois o Oracle nem sempre funciona bem com as ferramentas da Microsoft. Talvez eu esteja criando um perfil do meu código do Visual Basic e o perfil possa dizer: "Ei, chamei esse procedimento armazenado e demorou muito tempo". Mas, então, posso entrar no procedimento armazenado e fazer um perfil de banco de dados no armazenado. procedimento e diga: “OK, das 100 instruções que estão aqui, aqui estão as cinco que estavam causando o problema.” E assim, talvez você precise criar uma equipe de tags, na qual é necessário usar vários criadores de perfil.
A idéia é que, se alguma vez você for informado de que o problema de desempenho está no seu banco de dados, um perfil de banco de dados poderá ajudá-lo a encontrar a agulha no palheiro, na qual as instruções são realmente aquelas em que você tem um problema. Digo a você outra coisa que surgiu com o perfil: se você tiver um pedaço de código que é chamado um milhão de vezes, mas leva apenas um microssegundo cada um dos milhões de vezes, mas é chamado um milhão de vezes, o que o criador de perfil mostraria, essa coisa funcionou por tantas unidades de tempo. E, embora o código seja altamente eficiente, você pode olhar e dizer: “Ooh, estamos fazendo essa chamada para esse pedaço de código com muita frequência. Talvez devêssemos chamá-lo de vez em quando, e não toda vez que processamos um registro ”ou algo assim. E, assim, você pode descobrir onde existe um código eficiente que é chamado apenas com muita frequência e isso é realmente um problema de desempenho.
Robin Bloor: Sim, isso é maravilhoso. Eu nunca fiz isso. Obviamente, quando eu tive problemas com o banco de dados, era como se, de uma maneira ou de outra, estivesse lidando com banco de dados ou com código; Eu nunca poderia lidar com os dois ao mesmo tempo. Mas lá, novamente, eu não fiz uma … Eu nunca estive envolvido na criação de aplicativos onde tínhamos procedimentos armazenados, então acho que nunca realmente tive problemas que costumavam me deixar louco, a idéia de que você dividiria o código entre um banco de dados e um programa. Mas faça tudo - presumo que a resposta seja sim, mas isso faz parte de uma atividade da equipe de desenvolvimento, quando você está tentando, de uma forma ou de outra, consertar algo que está quebrado ou talvez tentando trazer uma nova aplicação em conjunto. Mas isso tudo se adapta a todos os outros componentes que eu esperaria no ambiente? Posso esperar que eu possa juntar isso em conjunto com todos os meus pacotes de teste e todas as outras coisas que eu faria e com o meu gerenciamento de projetos, é assim que todos esses clipes são agregados?
Bert Scalzo: Sim, pode se tornar parte de qualquer processo estruturado para realizar seus esforços de programação ou desenvolvimento. E é engraçado, na semana passada eu tive um cliente que estava construindo um aplicativo Web, e o banco de dados deles era pequeno, historicamente, e o fato de não serem bons programadores nunca os prejudicou. Bem, o banco de dados cresceu ao longo dos anos e agora leva 20 segundos em uma página da Web, entre quando você diz: "Entre e me dê alguns dados para ver" e quando a tela realmente aparece, e agora é um problema de desempenho. E eles sabiam que o problema não estava em nenhum de seus Java ou em qualquer outro lugar. Mas eles tinham milhares de procedimentos armazenados e, portanto, tiveram que começar a criar um perfil dos procedimentos armazenados para descobrir por que essa página da web está demorando 20 segundos para aparecer? E descobrimos que eles tinham uma junção cartesiana em uma de suas declarações selecionadas e não sabiam disso.
Robin Bloor: Uau.
Bert Scalzo: Mas alguém me disse uma vez: “Bem, como eles podem ter uma união cartesiana e não sabem disso?” E isso parecerá realmente horrível; Às vezes, um programador que não se sente muito à vontade com o SQL faz algo como me fornecer uma junção cartesiana, mas depois me devolve o primeiro registro, então eu sei que consegui algo e preciso apenas do primeiro. E assim, eles não percebem que trouxeram de volta um bilhão de registros ou examinam um bilhão de registros, porque eles conseguiram aquele em que estavam interessados.
Robin Bloor: Uau, eu sei, é assim que se chama - bem, é disso que Dez estava falando, em termos de pessoas não exatamente tão qualificadas quanto talvez devessem ser, você sabe. Se você é um programador, deve saber quais são as implicações de emitir qualquer comando. Quero dizer, realmente, não há desculpa para esse nível de estupidez. Também estou presumindo que você, de uma forma ou de outra, seja apenas independente da linguagem em relação a isso, porque tudo isso está focado no lado do banco de dados. Estou certo nisso? É a mesma coisa, o que você estiver usando no lado da codificação?
Bert Scalzo: Absolutamente, você pode fazer isso no Fortran ou C ou C ++. De fato, em alguns Unixes, você pode até fazê-lo nas linguagens de script; eles realmente fornecem as mesmas ferramentas. E então eu quero voltar um segundo para o que você disse sem desculpa. Vou dar uma folga aos programadores, porque não gosto de jogar programadores embaixo do ônibus. Mas o problema é realmente o ambiente acadêmico, porque quando você aprende a ser um programador, é ensinado a pensar em um registro de cada vez. Você não é ensinado a pensar em conjuntos, e é isso que a Structured Query Language, ou SQL, trabalha com conjuntos; é por isso que temos a união, a interseção e o operador negativo. E, às vezes, é muito difícil para uma pessoa que nunca pensou em conjuntos, desistir, deixar de lado o processamento de gravação por vez e trabalhar com conjuntos.
Robin Bloor: Sim, estou com você nisso. Quero dizer, entendi agora, isso é uma questão de educação; Eu acho que é uma questão completamente educacional, acho natural que os programadores pensem proceduralmente. E o SQL não é processual, é declarativo. Na verdade, você está apenas dizendo: "É isso que eu quero e não me importo como você faz isso", sabia? Considerando que, nas linguagens de programação, muitas vezes você tem as mangas arregaçadas e você fica atento às minúcias de até mesmo gerenciar as contagens enquanto faz um loop. Vou passar para-
Bert Scalzo: Não. OK, continue.
Sim, eu ia dizer que você mencionou outro exemplo de que seria bom capturar um perfilador, meio que continua com esse processamento de gravação por vez. Às vezes, um programador que é bom em uma lógica de registro por vez, não consegue descobrir como executar o programa SQL. Bem, digamos que ele faça dois loops FOR e basicamente faça uma junção, mas ele faz isso no lado do cliente. Então, ele está fazendo o mesmo efeito que uma associação, mas ele mesmo, e um perfil pode ser percebido, porque você provavelmente acabaria gastando mais tempo fazendo a associação manualmente do que permitir que o servidor de banco de dados faça isso por você.
Robin Bloor: Sim, isso seria um desastre. Quero dizer, você só estaria se debatendo. Bater sempre é ruim.
Enfim, vou passar para Dez; Tenho certeza que ele tem algumas perguntas interessantes.
Dez Blanchfield: Obrigado, sim, eu aceito . Vou me juntar a você nos programadores que não jogam debaixo do ônibus. Quero dizer, passei muitos anos na minha vida sendo um codificador, em todos os níveis, você sabe, seja como você disse, sentado na linha de comando da máquina Unix e, em alguns casos, até me envolvi em algumas portas diferentes do Unix de uma plataforma de hardware para outra. E você pode imaginar os desafios que tivemos lá. Mas a realidade é a seguinte: o cartão de saída da cadeia para todos os codificadores e scripts do mundo. É uma ciência do foguete, literalmente, escrever muito bem sempre, o tempo todo, é uma ciência do foguete. E histórias famosas de pessoas como Dennis Ritchie e Brian Kernahan trabalhando em algum trecho de código de forma independente e depois acessando um bate-papo de revisão de código durante um café e descobrindo que haviam escrito exatamente o mesmo trecho de código, exatamente no mesmo programa, exatamente da mesma maneira. E eles fizeram isso em C. Mas esse nível purista de programação existe muito raramente.
O fato é que diariamente, existem apenas 24 horas por dia, sete dias por semana, e precisamos apenas fazer as coisas. E assim, quando se trata de não apenas programadores tradicionais, os DBAs, e codificadores, e scripts, e sysadmin, e administradores de rede, equipe de segurança e todo o caminho até o lado dos dados dos cidadãos atualmente; ouvimos, todo mundo está apenas tentando fazer o seu trabalho. E então eu acho que a melhor ideia de tudo isso é que eu amei sua demo e adorei a comida que você nos deixou lá, apenas um momento atrás, conversando com Robin sobre o fato de que isso tem um particular - talvez não tanto um nicho - mas um amplo espaço ao qual ele se aplica, na medida em que fixa código, SQL e bancos de dados. Mas fiquei realmente empolgado ao ouvi-lo dizer que você poderia cutucá-lo em um shell script e encontrar alguns problemas, porque você sabe, nos dias de hoje, sempre estamos trabalhando com o menor custo em tudo.
A razão pela qual você pode comprar uma camisa de US $ 6 em algum lugar é porque alguém construiu um sistema com preço baixo o suficiente para realmente fabricar e enviar e entregar, vender e vender logisticamente e receber pagamentos on-line para obter essa camisa de US $ 6. E isso não acontece se você receber US $ 400.000 por ano para escrever código da maneira perfeita; é apenas desenvolvimento inteiro. Então, nesse ponto, acho que uma das perguntas que eu realmente adoraria que você nos desse mais informações é qual é a amplitude e o alcance do tipo de pessoa que você está vendo atualmente e que está implantando esses tipos de ferramentas para criar um perfil um código e procurar problemas de desempenho? Inicialmente, historicamente, de onde eles vêm? Eles foram as grandes casas de engenharia? E então, daqui para frente, é o caso, estou correto ao pensar que mais e mais empresas estão implementando essa ferramenta, ou essas ferramentas, para tentar ajudar os codificadores, que eles sabem que estão apenas fazendo as coisas para concluir o trabalho e tirá-lo da porta? E às vezes precisamos de um cartão de saída da cadeia? Estou certo ao pensar que historicamente tínhamos mais foco e desenvolvimento em engenharia? Que agora estamos adotando uma abordagem acadêmica menos, como Robin disse, e agora é um código autodidata, ou recortar e colar, ou apenas criar coisas? E isso corresponde ao tipo de pessoa que está usando o produto agora?
Bert Scalzo: Sim, exatamente. E vou dar um exemplo muito específico: queremos apenas fazer o trabalho, porque as pessoas de negócios não querem perfeição. É como um jogo de xadrez computadorizado: o jogo de xadrez não procura a resposta perfeita; procura uma resposta que seja boa o suficiente em um período de tempo razoável, e é assim que programamos. Mas o que estou descobrindo agora é que a maioria das pessoas, em vez de dizer que quer um profiler como parte de seus testes de unidade - é como eu faria isso, porque não vejo isso como uma perda de tempo - o que está acontecendo é agora que isso está sendo feito mais tarde, às vezes, durante testes de integração ou testes de estresse, se tivermos sorte. Mas, na maioria das vezes, faz parte de uma escalação, onde algo entra em produção, ele fica por um tempo, talvez até anos, e agora não corre bem, e agora vamos dar um perfil. E esse parece ser o cenário mais comum agora.
Dez Blanchfield: Sim, e acho que o termo "dívida técnica" é provavelmente aquele com o qual você está mais familiarizado; Eu sei que Robin e eu certamente somos. Hoje em dia, particularmente em abordagens ágeis para o desenvolvimento e a construção de sistemas, para mim, o conceito de dívida técnica agora é uma coisa muito real e, na verdade, a consideramos em projetos. Eu sei, quero dizer, nós temos nossos próprios projetos, como o Media Lens e outros, onde a codificação acontece diariamente e várias coisas no Bloor Group. E sempre que estamos construindo algo, nós meio que olhamos, eu olho para ele, e sempre olhamos do ponto de vista do que vai me custar consertar isso agora, em vez de simplesmente conseguir pode e coloca lá fora, e então assiste e vê se isso vai quebrar. E herdar essa dívida técnica que sei que vou ter que voltar mais tarde e corrigir.
Quero dizer, eu fiz isso nos últimos sete dias: escrevi algumas ferramentas e scripts, escrevi algumas partes da linguagem Python e implantei no Mongo back-end, criando claro que é agradável, limpo e seguro, mas apenas recebe a consulta que preciso fazer, sabendo que preciso que essa função funcione, para chegar ao quebra-cabeça maior; é aí que está minha verdadeira dor. E assim você incorre nessa dívida técnica, e acho que agora isso não é apenas uma coisa ocasional, acho que isso faz parte do DNA do desenvolvimento agora. As pessoas simplesmente - não de maneira dissimulada - apenas aceitam a dívida técnica como um tipo de problema normal do modus operandi e precisam incorrer nela. É onde você incorre na dívida técnica. E acho que o melhor do que você nos mostrou na demonstração foi que você pode literalmente criar um perfil e observar quanto tempo leva para ser executado. E essa é provavelmente uma das minhas coisas favoritas. Quero dizer, eu realmente construí ferramentas de criação de perfil - costumávamos criar ferramentas no Sed e Lex e Orc para executar nosso código e ver onde estavam os loops, antes que ferramentas como essa estivessem disponíveis - e quando você construiu o código para ir e revise seu próprio código, você será muito bom em não precisar revisar seu próprio código. Mas esse não é o caso agora. Com isso em mente, existe um segmento de mercado específico que ocupa isso mais do que qualquer outro? Vendo como uma massa-
Bert Scalzo: Ah sim, eu tenho - vou fazer uma analogia para você e mostrar que os não programadores fazem isso o tempo todo. Como se eu estiver ensinando uma aula ou sessão de depurador e criação de perfil, perguntarei às pessoas: "OK, quantas pessoas aqui entram no Microsoft Word e propositalmente nunca usam o verificador ortográfico?" E ninguém levanta a mão, porque, para escrever documentos, todos sabemos que podemos cometer erros de inglês e, portanto, todo mundo usa o corretor ortográfico. E eu disse: “Bem, como é que, quando você está escrevendo um texto no seu IDE como o Visual Basic, não está usando o depurador? É a mesma coisa, é como um corretor ortográfico.
Dez Blanchfield: Sim, na verdade, é uma ótima analogia. Eu realmente não tinha pensado, tenho que admitir que realmente faço algo semelhante com algumas ferramentas que uso. De fato, um, ODF, o meu favorito no Eclipse é apenas recortar e colar código e procurar coisas que se destacam imediatamente e percebendo que cometi um erro de digitação em alguma chamada de classe. E, mas agora é interessante com a ferramenta como essa, você pode fazer isso em tempo real, em vez de voltar e olhar para ela mais tarde, o que é bem legal de se ver com antecedência. Mas sim, é uma ótima analogia de apenas colocar texto em um processador de texto, porque é uma chamada interessante para despertar que, basta perceber que você cometeu erros de digitação ou até mesmo um erro gramatical, certo?
Bert Scalzo: Exatamente.
Dez Blanchfield: Então, você está vendo mais um aumento agora, eu acho, quero dizer, a pergunta final de mim, antes de iniciar nossa sessão de perguntas e respostas, talvez, para nossos participantes. Se você iria dar algum tipo de recomendação em torno da abordagem para fazer isso - presumo que isso seja retórico - é o caso de você entrar cedo e implementá-lo à medida que desenvolve, antes de desenvolver? Ou é o caso de você estar predominantemente construindo, movendo-se, construindo algo e entrando no perfil depois? Eu suspeito que seja o caso de entrar cedo e verifique se o seu código está limpo. Ou será que eles deveriam considerar essa parte de sua pós-implantação?
Bert Scalzo: Idealmente, eles fariam isso antecipadamente, mas, como todos estão no mundo da agitação, onde apenas precisam fazer as coisas, eles tendem a não fazê-lo até encontrar um problema de desempenho que não podem resolver. adicionando mais CPUs e memória a uma máquina virtual.
Dez Blanchfield: Sim. Então, na verdade você mencionou algo interessante, se eu puder rapidamente? Você mencionou anteriormente que isso pode ser executado em qualquer lugar e pode conversar com o banco de dados no back-end. Portanto, isso é confortável com o tipo de conceito bimodal de que falamos agora, de nuvem no local / fora do local, pela aparência das coisas também, no final do dia, se puder falar com o back-end e ver o código, realmente não se importa, não é?
Bert Scalzo: Exatamente, sim, você pode executar isso na nuvem.
Dez Blanchfield: Excelente, porque acho que é para onde nosso novo mundo corajoso está indo. Então, Eric. Vou voltar para você agora e ver que temos algumas perguntas aqui e quero que nossos participantes ainda fiquem conosco, mesmo que tenhamos passado a hora.
Eric Kavanagh: Sim, existem algumas pessoas por aí, vou fazer um comentário rápido: Bert, acho que essa metáfora, a analogia que você dá ao uso da verificação ortográfica é francamente brilhante. Isso é digno de um ou dois blogs, francamente, porque é uma boa maneira de enquadrar o contexto do que você está fazendo, e quão valioso é, e como realmente deve ser uma prática recomendada usar um depurador regularmente, certo? Aposto que você faz que sim com a cabeça quando joga isso fora, certo?
Bert Scalzo: Absolutamente, porque o que digo é: “Por que faço uma verificação ortográfica nos meus documentos? Eu não quero ter vergonha de erros estúpidos de ortografia. ”Bem, eles não querem ter vergonha de erros estúpidos de codificação!
Eric Kavanagh: Certo. Sim, de fato. Bem, pessoal, passamos uma hora e cinco minutos aqui, muito obrigado a todos por seu tempo e atenção. Arquivamos todos esses bate-papos na web, sinta-se à vontade para voltar a qualquer momento e verificá-los. O melhor lugar para encontrar esses links é provavelmente o techopedia.com, portanto, adicionaremos a esta lista aqui.
E com isso, vamos dizer adeus, pessoal. Mais uma vez, ótimo trabalho, Bert, graças aos nossos amigos da IDERA. Falaremos com você na próxima vez, na verdade, semana que vem. Cuidar! Tchau tchau.
