Leve embora: O anfitrião Eric Kavanagh discutiu a depuração e criação de perfil de banco de dados com o Dr. Robin Bloor, Dez Blanchfield e IDERAs Bert Scalzo.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Certo, senhoras e senhores, são quatro da manhã, horário do leste da quarta-feira, e é claro que isso significa.
Robin Bloor: Não posso ouvir você, 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ê deseja 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 estávamos falando sobre 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, falaríamos 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 dê uma olhada, @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, isso vai acontecer, a questão é: qual será a sua solução para lidar com isso e resolver esses problemas?
Bem, ouça 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, levá-las embora. O chão é seu.
Robin Bloor: ESTÁ BEM. 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, assim é como se fosse, e fiquei quase tentado com esta apresentação a começar a falar sobre a idéia de código aberto, mas pensei que deixaria isso para outra pessoa.
Aqui está uma lista de bugs famosos, e a maioria deles entra na lista principal 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 circulava por todos - aparentemente causou danos no valor de US $ 100 milhões; 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 Apples Maps é 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 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 de codificadores 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, no 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, os funcionários do banco de dados criaram 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 era apenas integridade referencial e exclusões em cascata e coisas assim, o banco de dados estava cuidando de todo o repentino momento em que você colocava a funcionalidade em um banco de dados, o que significava obviamente que a funcionalidade para um O aplicativo pode ser dividido 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 do banco de dados, porque significa que você entrou em muitas implementações, por exemplo, que eu estive envolvido em bancos de dados relacionais; na verdade, existe uma quantidade enorme de código que fica nos procedimentos armazenados, tratados separadamente do código que fica nas aplicações. E parece uma coisa muito estranha, é suposto ser bastante inteligente em fazer várias coisas.
Eu pensei que eu também falaria sobre desempenho de banco de dados porque 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 por causa do 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, você obtém um design incorreto do banco de dados, um design incorreto do programa, 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, isso é uma visão geral.
A única coisa que 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á como todas as situações na depuração que já experimentei. é, é 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, frequentemente, quando você está olhando para um problema no banco de dados, tudo o que você está olhando é dados corrompidos e está pensando: "Como diabos isso aconteceu?"
De qualquer forma, vou passar para Dez, que provavelmente dirá mais palavras de sabedoria do que saí. Não sei como passar a bola para você, dez.
Eric Kavanagh: Vou passar, aguarde, aguente firme.
Voz automatizada: As linhas dos participantes foram 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 me ajudar nisso. 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 muitas vezes é 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 ligeiramente diferente do que era um problema de hardware e supostamente de software surgiu.
Então, o mito urbano é que ronda o dia 9 de setembroº1945, uma equipe da Universidade de Harvard estava desmontando uma máquina, eles encontraram algo que eles chamavam de "relé setenta" - naqueles dias a programação era feita no sentido físico, você enrolava o código em uma placa e foi assim que você efetivamente programou o máquina - e descobriram que este relé número setenta havia algo errado com ele, e o termo "bug" surgiu porque era literalmente uma mariposa - supostamente havia uma mariposa presa entre um pedaço de fio de cobre 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.E desde então, usamos essa terminologia para tentar lidar com problemas, não tanto como codificar problemas em um programa que não compila, mas como um programa que não funciona bem. E, especificamente, não foi elaborado 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 eu pensei em colocar alguns slides engraçados antes de entrar em detalhes. Aqui está o desenho animado clássico, chamado XKCD na Web, e o cartunista tem algumas visões bem engraçadas do mundo. E este sobre um garoto chamado "Little Bobby Tables" e supostamente seus pais nomearam esse garoto Robert); DROP TABLE Alunos; - e é chamado e meio que “Olá, esta é a escola dos seus filhos que 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 anos de registros dos alunos, 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 muitas vezes o código não olha para 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 uma falha no 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 da opinião de que esse tempo passou e, em minha experiência, o meu primeiro - e isso me envelhece terrivelmente, tenho certeza; Robin, você é bem-vindo a zombar de mim por isso - mas historicamente eu venho de um passado aos 14 anos de idade, vagando pelo fim da cidade e batendo na porta de um data center chamado “Data Com” na Nova 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 papéis em papel, 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 físico 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 a depuração de código era uma questão muito trivial, então você tendia a escrever todo o código manualmente e a agir como datilógrafo, fazendo o possível para não erros, porque é extremamente frustrante contar o editor de uma linha para ir para uma determinada linha e depois 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 passou - e todos estavam 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 que fez na fita de papel meio que o formato ed apenas em um CRT, mas você foi capaz de excluir mais facilmente e não tinha o som "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ê se safar 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 de design e processos para garantir que eu não introduzisse buggy código.
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 encontrar e introduzir 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 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, todos esses dias corriam 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 funcionários com salários mais baixos. E não quero dizer isso de uma maneira dissimulada, mas não estava 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 estão entrando 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 me lembro 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ê precisa limpe-o. ”E, portanto, o SQL tem esse problema e é muito, muito fácil de aprender, muito fácil de usar. Mas não é, na minha opinião, 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, para manipular 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 através 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 dar um ponto nesse ponto, aqui está um exemplo que eu carrego muito. Sou um grande fã de matemática, adoro a teoria do caos, adoro os conjuntos de Mandelbrot. No lado direito, há uma versão do conjunto de Mandelbrot, com o qual tenho certeza que todos estão familiarizados. E, à esquerda, há um pedaço de SQL que realmente 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. Então, agora temos construções muito complexas e procedimentos armazenados, 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 uma equipe bem remunerada, 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 isso é meio fofo e você pensa: “Uau, que gráfico maravilhoso, eu adoraria fazer 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 realmente ilustrar isso - e desculpe, as cores estão invertidas, é suposto ser um fundo preto e verde 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. Esta é 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 acessando um sistema a cada dia, hora ou minuto, muito em breve você acaba com uma experiência em Chernobyl, onde 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 realmente bonito, mas vamos conseguir um DBA para ajudá-lo a criar essa consulta estruturada corretamente, porque, francamente, isso é simplesmente desagradável". E os URLs lá podem ser vistos - é chamado de consulta SQL mais complexa que você já escreveu. Porque acredite em mim, que na verdade é compilado, é executado. 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.
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, 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 concluir 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 disse anteriormente. , era uma vez, você poderia 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 estava prestes a receber. Eric, vou passar de volta.
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 do 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, uma espécie de pré-história, idade avançada, idade média, tipo de dizer onde estávamos 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, tínhamos depuradores disponíveis para nós e, por assim dizer, "Ei, 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 é a única maneira de obter afastado com essa alegação.
Agora, a outra coisa engraçada nesse gráfico é que Dez acabou de comentar sobre Grace Hopper, eu realmente conhecia Grace, então é meio engraçado. E então a outra coisa de que eu ri é que ele falou sobre teletipos e eu estou 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". , 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, eu 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 rastreio ou algo assim, e assim você instrumenta seu código. Eu consideraria isso como depuração, é um pouco mais difícil, uma maneira de fazê-lo, mas conta. Mas também recebemos a famosa declaração: você assiste e as pessoas realmente colocam declarações e eu realmente vi uma ferramenta em que - e é uma ferramenta de banco de dados - onde, se você não sabe usar um depurador, pressiona um botão e ele fica preso instruções em todo o código para você e, quando terminar, aperta outro botão e ele as retira. Porque é assim que muita gente depura.
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 que perdemos um requisito de negócios, mas o que é é que o código não é eficaz; Ele não faz o que esperávamos. A outra vez que fazemos 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, eu afirmo isso porque os criadores de perfil provavelmente são melhores para o segundo cenário e iam 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 às pessoas na tela em um momento.
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 tem sido mais melhor se for feita uma 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 demoram demais . 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 sentir 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, as linguagens de banco de dados, como mencionamos anteriormente, você tem SQL - e meio que forçamos o pino redondo no buraco quadrado aqui e o forçamos a se tornar uma linguagem de programação - e Oracle.Isso é PL / SQL - essa é a linguagem processual SQL - e o SQL Server, o Transact-SQL, o SQL-99, o SQL / PSM - para, eu acho, o Procedure Stored Module. 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?" 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ódigos de depuração para colocar em todas essas instruções do que o código. Portanto, embora isso possa funcionar e seja melhor que nada, é uma maneira muito difícil de depurar, especialmente porque, e se levarmos 10 horas para essa coisa funcionar 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, 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 ele tem várias instruções 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 o Visual Studio para escrever programas, ou o 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, é só procurar 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, tenho meu código-fonte no meio, tenho o que é chamado de variáveis de relógio e bandejas de pilha de chamadas e, na parte inferior, tenho algumas saídas. E o que é 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 estou percorrendo 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 meu cursor está no momento - então, em outras palavras, eu pisei e é onde estou no momento. Então, se eu disser "passo de novo", vou para a próxima linha. Agora, logo abaixo, você verá o ponto vermelho. Bem, isso é um ponto de interrupção, que diz: "Ei, eu não quero pular 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 para o final, 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 veja meu rastreamento de pilha de chamadas e todas essas informações são exibidas lá enquanto estou percorrendo o código, para que eu possa ver, sentir e entender o que está acontecendo e como o código realmente está funcionando no 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, este é 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 podem ficar juntos? Nesse caso, e novamente, eu 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 de uma tabela. E assim, o que está acontecendo dentro desse loop FOR provavelmente é algo que eu preciso examinar e, se eu puder melhorar, pagará dividendos. Não vou conseguir 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 que é legal é 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 eu tenho uma instrução que parece estar ocupando a maior parte do bolo e, se eu olhar, vejo nessa grade na parte inferior, linha 23, o loop FOR novamente: ele está ocupando mais tempo, ele é realmente vermelho escuro mastigando todo o gráfico de pizza. 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 melhor código do mundo e obter um aumento salarial - esse pode ser o nosso motivo, mas esse não é realmente o motivo - você prometeu ao negócio 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 antes mesmo de pressionar a tecla. Eles deveriam ler sua mente e fazer tudo instantaneamente. Em outras palavras, tem que ser eficiente. E assim, é para isso que usaríamos 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á vendado. 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, só vou fazer uma demonstração rápida aqui. Não é minha intenção empurrar o produto, eu só 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 o que parece 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 DBAs, o Rapid SQL é mais para 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, vou extrair 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 no topo, pela linha um, é onde estou no código. E se eu pressionar o terceiro ícone, que é um passo em frente, você verá que a seta acabou de se mover e, se eu continuar pressionando, verá que ela continua se movendo. Agora, se eu quisesse ir até esse loop FOR, porque sei que é esse 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 ponto 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 seleta 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 ele corra até o fim, porque o que eu quero que você veja é que um depurador não altera o comportamento do programa: quando terminar, eu deveria obter exatamente os mesmos resultados se o tivesse executado dentro de um depurador.
E com isso, vou suspender a demonstração 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 algumas 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? Como é que 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: Você sabe, isso é uma pergunta fantástica. Vamos dizer que estou trabalhando no Visual Basic e eu, dentro do meu Visual Basic, vou chamar um Transact-SQL ou um PL / SQL. Deixe-me fazer o PL / SQL, já que 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 possa ser altamente eficiente, você pode procurar e dizer: “Ooh, estávamos 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 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, aliás, novamente, eu não fiz ... Eu nunca estive envolvido na criação de aplicativos onde tínhamos procedimentos armazenados, então acho que nunca 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 sim, faça tudo - presumo que as respostas sejam sim, mas isso faz parte de uma atividade da equipe de desenvolvimento, quando você está tentando, de uma maneira ou de outra, consertar algo que está quebrado ou talvez tentando reunir um novo aplicativo. 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 da 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 deles 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? Na verdade, 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 poderiam ter uma união cartesiana e não saber 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 apenas devolve o primeiro registro, então sei que obtive algo e preciso apenas do primeiro. E assim, eles não percebem que apenas trouxeram de volta um bilhão de registros ou olham através de 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 habilitadas 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, de uma forma ou de outra, apenas seja independente do idioma em relação a isso, porque tudo isso se concentra 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 o pensamento de gravação 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 menos. E às vezes é muito difícil para uma pessoa que nunca pensou em termos de conjuntos, sair, deixar de lado o processamento recorde 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 isso é completamente uma questão 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", sabe? Enquanto nas linguagens de programação, muitas vezes você tem as mangas arregaçadas e você está minucioso em até gerenciar as contagens, enquanto faz um loop. Vou passar mal para ...
Bert Scalzo: Não. OK, continue.
Sim, eu diria 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. Portanto, ele está fazendo o mesmo efeito que uma associação, mas ele mesmo, e um perfil pode ser percebido, porque você provavelmente passaria mais tempo fazendo a associação manualmente do que permitir que o servidor de banco de dados fizesse isso por você.
Robin Bloor: Sim, isso seria um desastre. Quero dizer, você só estaria se debatendo. Thrashings sempre ruins.
Enfim, vou passar para Dez; Tenho certeza que ele tem algumas perguntas interessantes.
Dez Blanchfield: Obrigado sim, sim. Vou acompanhá-lo nos programadores que não jogam debaixo do ônibus. Quero dizer, eu 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, eu estava envolvido em um duas 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: um cartão de saída da cadeia para todos os programadores e roteiristas 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 o mesmo caminho. 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; nós 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 script de shell e encontrar alguns problemas, porque você sabe que hoje em dia a idade sempre trabalhava 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ê paga às pessoas US $ 400.000 por ano para escrever o 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 de código e procurar por 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? Isso agora, estava ficando menos, como Robin disse, uma abordagem acadêmica, e agora seu código autodidata, ou recortar e colar, ou apenas criar as 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; ele procura uma resposta que seja boa o suficiente em um período de tempo razoável, então é assim que programamos. Mas o que eu estou descobrindo agora é que a maioria das pessoas, em vez de dizer que quer um profiler como parte de seus testes de unidade - que é como eu faria isso, porque eu não vejo isso como uma perda de tempo - o que está acontecendo agora é que está sendo feito mais tarde, às vezes, durante testes de integração ou testes de estresse, se tiverem sorte. Mas, na maioria das vezes, faz parte de uma escalada, onde algumas coisas entram em produção, ela funciona por um tempo, talvez até por anos, e agora não funciona bem, e agora perfila bem. 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 em todo o grupo Bloor. E sempre que estávamos 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, versus posso simplesmente colocar na lata e coloque-o lá fora, e então observe e veja se isso vai quebrar. E herdar essa dívida técnica que sei que precisarei voltar mais tarde e consertar.
Quero dizer, eu fiz isso nos últimos sete dias: escrevi algumas ferramentas e scripts, escrevi algumas partes da linguagem Python e a implantei no back-end do Mongo, certificando-se de que seja agradável, limpo e seguro, mas apenas obtém a consulta que preciso fazer, sabendo que preciso que essa função funcione, para chegar ao quebra-cabeça maior; é onde 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 isso é 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 revisar seu próprio código , você é 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. Porque, se alguma vez estou ensinando um depurador e uma classe ou sessão de criação de perfis, perguntarei às pessoas: "OK, quantas pessoas aqui entram no Microsoft Word e propositalmente nunca usam o corretor 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 em seu IDE como o Visual Basic, você 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 em tempo real, em vez de voltar e olhar para ela mais tarde, o que é bem legal de ver com antecedência. Mas sim, isso é uma ótima analogia de apenas colocar em um processador de texto, causar 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, acho que é a última pergunta minha, antes de iniciar nossa sessão de perguntas e respostas, talvez, para os participantes. Se você iria dar algum tipo de recomendação em torno da abordagem para fazer isso - suponho que isso seja retórico - é o caso de você entrar cedo e implementá-lo à medida que se desenvolve, antes de se desenvolver? Ou é o caso de você estar predominantemente construindo, movendo-se, construindo algo e depois entrando no perfil e depois? Suspeito que é o caso de você chegar cedo e garantir que seus códigos sejam limpos com antecedência. Ou será que eles deveriam considerar essa parte de sua pós-implantação?
Bert Scalzo: Idealmente, eles fariam isso com antecedência, 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 conseguem resolver adicionando mais CPUs e memória para 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 tenha passado a hora.
Eric Kavanagh: Sim, existem algumas pessoas por aí, apenas farei um comentário rápido: Bert, acho que essa metáfora, a analogia que você dá ao uso do corretor ortográfico é francamente brilhante. Isso é digno de um blog ou dois, francamente, porque é uma boa maneira de enquadrar o que é que você está fazendo, e quão valioso é, e como realmente deve ser uma prática recomendada usar um depurador em um base regular, certo? Aposto que você faz que sim com a cabeça quando joga isso fora, certo?
Bert Scalzo: Absolutamente, porque o que eu digo é: “Por que eu executo uma verificação ortográfica nos meus documentos? 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: Direito. Sim, de fato. Bem, pessoal, queimávamos 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, então adicione isso a esta lista aqui.
E com isso, você iria se despedir, pessoal. Mais uma vez, ótimo trabalho, Bert, graças aos nossos amigos da IDERA. Bem, falo com você na próxima vez, bem, na semana que vem, na verdade. Cuidar! Tchau tchau.