Por el personal de Techopedia, 15 de marzo de 2017
Para llevar: El presentador Eric Kavanagh discutió la depuración y el perfil de la base de datos con el Dr. Robin Bloor, Dez Blanchfield y Bert Scalzo de IDERA.
Actualmente no has iniciado sesión. Inicia sesión o regístrate para ver el video.
Eric Kavanagh: Bien, damas y caballeros, son las 4:00 hora del este de un miércoles, y por supuesto eso significa.
Robin Bloor: No puedo escucharte, Eric.
Eric Kavanagh: Estuve allí hace días, así que no estás solo. Pero el tema de hoy es algo realmente interesante. Es el tipo de cosas que desea asegurarse de que sucedan en segundo plano en su empresa, a menos que sea la persona que lo hace, en cuyo caso desea asegurarse de que lo está haciendo correctamente. Porque estamos hablando de depuración. A nadie le gustan los errores, a nadie le gusta cuando el software deja de funcionar: la gente se molesta, los usuarios se vuelven hostiles. Eso no es bueno. Entonces, vamos a hablar sobre "Respuesta rápida: depuración de bases de datos y perfiles al rescate".
Hay un lugar sobre el tuyo, contáctame en Twitter, @eric_kavanagh, por supuesto.
Este año es caluroso. Y la depuración va a estar caliente, pase lo que pase. Realmente va a ser uno de estos problemas que nunca va a desaparecer, no importa lo bueno que lleguemos a esto, siempre habrá problemas, por lo que la clave es cómo llegar a donde puede resolver esos problemas rápidamente. Idealmente, usted tiene excelentes programadores, excelentes entornos, donde no sale demasiado mal, pero como dice el viejo dicho: "Los accidentes ocurren en la mejor de las familias". Y lo mismo es cierto para las organizaciones. Entonces, esto sucede, va a suceder, la pregunta es ¿cuál será su solución para lidiar con eso y resolver esos problemas?
Escucharemos al Dr. Robin Bloor, luego a nuestro propio Dez Blanchfield desde abajo y, por supuesto, a nuestro buen amigo, Bert Scalzo, de IDERA. Y, de hecho, voy a entregar las llaves de Robin Bloor, quítamelas. El piso es tuyo.
Robin Bloor: OK. Este es un tema interesante. Pensé que debido a que Dez probablemente continuará con las técnicas reales y las historias de guerra sobre la depuración, pensé que solo haría una discusión de fondo para que pudiéramos tener una idea completa de lo que está sucediendo. Hice esto durante mucho tiempo, y solía ser un programador, así que es como, y casi me sentí tentado con esta presentación a comenzar a escribir líricamente sobre la idea del código abierto, pero pensé que se lo dejaría a otra persona.
Aquí hay una lista de errores famosos, y la mayoría de estos entran en la lista principal de cualquiera, básicamente, todos excepto los dos últimos cuestan al menos $ 100 millones. El primero fue el Mars Climate Orbiter, se perdió en el espacio y fue debido a un problema de codificación, donde la gente confundía las unidades métricas con (risas) pies y pulgadas. En el Ariane Five Flight 501 hubo una falta de coincidencia entre un motor que se encendió y las computadoras que supuestamente estaban ejecutando el cohete cuando se lanzó. Múltiples fallas informáticas, explosión de cohetes, titulares de noticias. Gasoducto soviético en 1982, que se dice que es la mayor explosión en la historia del planeta; No estoy seguro de si es así. Los rusos robaron un software de control automatizado, y la CIA se dio cuenta de que iban a hacer eso y le colocaron errores, y los soviéticos lo implementaron sin probarlo. Entonces, explotó una tubería, pensó que era divertido.
El gusano Morris fue un experimento de codificación, que de repente se convirtió en un gusano rapaz que dio la vuelta a todos, aparentemente causó daños por valor de $ 100 millones; Esa es una estimación, por supuesto. Intel cometió un error famoso con un chip matemático, una instrucción matemática sobre el chip Pentium en 1993, que supuestamente costaba más de $ 100 millones. El programa Maps de Apple es posiblemente el peor y más desastroso lanzamiento de cualquier cosa que Apple haya hecho. Las personas que intentaron usarlo fueron, quiero decir, alguien conducía por la 101 y descubrieron que el Mapa de Apple decía que estaban en el medio de la Bahía de San Francisco. Entonces, la gente comenzó a referirse a la aplicación Apple Maps como iLost. La, nuestra interrupción más larga en 1990, es interesante desde el punto de vista del costo de algo así: AT&T estuvo fuera durante aproximadamente nueve horas y costó alrededor de $ 60 millones en llamadas de larga distancia.
Y estaba en una compañía de seguros del Reino Unido, y la base de datos, implementaron una nueva versión de la base de datos y comenzó a borrar datos. Y lo recuerdo muy bien, porque después me llamaron para participar en algún tipo de selección de base de datos debido a eso. Y fue muy interesante que habían tomado una nueva versión de la base de datos, y que tenían una batería de pruebas que hicieron para las nuevas versiones de la base de datos que pasó todas las pruebas. Encontró una forma muy oscura de borrar datos.
Entonces, de todos modos, eso es todo. Pensé que hablaría sobre la falta de coincidencia de impedancia y el SQL emitido. Es interesante que las bases de datos relacionales almacenen datos en tablas y los codificadores tienden a manipular datos en estructuras de objetos que realmente no se asignan muy bien a las tablas. Y debido a eso, obtienes lo que se llama el desajuste de impedancia, y alguien tiene que lidiar con eso de una manera u otra. Pero lo que realmente sucede, porque un modelo, el modelo del codificador y la base de datos de otro modelo, no están particularmente alineados. Obtienes errores que simplemente no sucederían si la industria hubiera construido cosas que funcionen juntas, lo que creo que es gracioso. Entonces, básicamente, del lado de los codificadores, cuando se obtienen jerarquías, pueden ser tipos, pueden resultar conjuntos, puede ser una pobre capacidad de API, pueden ser muchas cosas que simplemente arrojan cosas en términos de interacción con la base de datos. Pero lo que es más para mí, realmente interesante; Siempre me sorprendió que tuvieras esta barrera SQL que también es una especie de impedancia en la forma en que los codificadores y la base de datos trabajan entre sí. Entonces, SQL tiene reconocimiento de datos, lo cual está bien y tiene DML para seleccionar, proyectar y unir, lo cual está bien. Con eso, puede arrojar mucha capacidad en términos de obtener datos de la base de datos. Pero tiene muy poco lenguaje matemático para hacer cosas. Tiene un poco de esto y aquello, y tiene muy poco material basado en el tiempo. Y debido a eso, SQL es un medio imperfecto, si lo desea, para obtener los datos. Por lo tanto, los chicos de la base de datos crearon procedimientos almacenados para vivir en la base de datos y la razón de los procedimientos almacenados que viven allí fue que realmente no deseaba enviar datos de un programa a otro.
Debido a que parte de la funcionalidad era extremadamente específica de los datos, por lo que no era solo integridad referencial y eliminaciones en cascada y cosas así, la base de datos se ocupaba de repente de que estuvieras poniendo funcionalidad en una base de datos, lo que significaba, por supuesto, que La funcionalidad de una aplicación podría dividirse entre el codificador y la base de datos. Y eso hizo que el trabajo de implementar algunos tipos de funciones fuera realmente difícil y, por lo tanto, más propenso a errores. Entonces, ese es un lado del juego de la base de datos, porque significa que tienes muchas implementaciones, por ejemplo, que he estado involucrado en bases de datos relacionales, realmente hay una gran cantidad de código que se encuentra en los procedimientos almacenados que se manejan por separado del código que se encuentra en las aplicaciones. Y parece que es algo muy extraño, se supone que es bastante inteligente para hacer varias cosas.
Pensé que también hablaría sobre el rendimiento de la base de datos porque los errores de rendimiento a menudo se consideran errores, pero básicamente puede tener un cuello de botella en la CPU, en la memoria, en el disco, en la red y puede tener problemas de rendimiento debido al bloqueo . La idea sería que el codificador realmente no necesitara preocuparse por el rendimiento y la base de datos en realidad funcionaría razonablemente bien. Se supone que está diseñado para que el codificador no necesite saberlo. Sin embargo, se obtiene un diseño de base de datos incorrecto, se obtiene un diseño de programa incorrecto, se obtiene concurrencia en la mezcla de carga de trabajo, lo que también puede generar problemas de rendimiento. Obtiene equilibrio de carga, planificación de capacidad, crecimiento de datos, lo que puede hacer que una base de datos simplemente se detenga o se ralentice. Es algo interesante, cuando las bases de datos se llenan casi, se ralentizan. Y puede tener problemas de capas de datos en términos de replicación y la necesidad de replicar y la necesidad de hacer copias de seguridad y recuperación. De todos modos, esa es una descripción general.
Lo único que me gustaría decir es que la depuración de la base de datos puede ser tan onerosa y no trivial, y lo digo porque he hecho mucho, y a menudo descubrirás que es como todas las situaciones de depuración que yo alguna vez experimentado es, es lo primero que ves es un desastre. Y tienes que intentar pasar del desorden a averiguar cómo surgió el desorden. Y a menudo, cuando observa un problema de la base de datos, lo único que observa son datos corruptos y piensa: "¿Cómo demonios sucedió eso?"
De todos modos, pasaré a Dez, quien probablemente dirá más palabras de sabiduría de las que salí. No sé cómo pasarte la pelota, Dez.
Eric Kavanagh: Lo pasaré, espera, espera.
Voz automatizada: líneas de participantes silenciadas.
Eric Kavanagh: Muy bien, espera un segundo, déjame darle la pelota a Dez.
Dez Blanchfield: Gracias Eric. Sí, Dr. Robin Bloor, de hecho tiene toda la razón: este es un tema, un error de por vida si perdona el juego de palabras, lo siento, no pude evitarlo. Espero que puedan ver mi primera pantalla allí, mis disculpas por el problema del tamaño de fuente en la parte superior. El tema de los errores es una conferencia de un día, en muchos casos en mi experiencia. Es un tema tan amplio y amplio, por lo que voy a centrarme en dos áreas clave, específicamente el concepto de lo que consideramos un error, pero un problema de programación. Creo que en estos días, la introducción de un error per se generalmente es detectada por los entornos de desarrollo integrados, aunque pueden ser errores de larga duración. Pero a menudo es más un caso de código de perfil y es posible escribir código que funcione, eso debería ser un error. Entonces, mi título de diapositiva aquí, en realidad tenía una copia de esto en A3 de muy alta resolución, pero desafortunadamente se destruyó en una mudanza de casa. Pero esta es una nota escrita a mano en una hoja de programación de alrededor de 1945, donde supuestamente algunas personas de la Universidad de Harvard en los Estados Unidos, su segunda construcción de una máquina llamada Mark II. Estaban depurando algún problema, en un lenguaje común, pero estaban tratando de encontrar una falla, y resultó que surgió algo ligeramente diferente de lo que era un hardware y supuestamente un problema de software.
Entonces, el mito urbano es que alrededor del 9 de septiembre de 1945, un equipo de la Universidad de Harvard estaba desarmando una máquina, se encontraron con algo que llamaron "retransmisión de setenta", en esos días la programación se hacía en sentido físico, hería el código alrededor de una placa, y así fue como efectivamente programó la máquina, y descubrieron que este relé número setenta tenía algo de malo, y resulta que el término real "error" surgió porque literalmente era una polilla, supuestamente allí Era una polilla encajada entre un trozo de alambre de cobre que iba de un lugar a otro. Y la historia cuenta que la legendaria Grace Hopper como este subtítulo, para mi diapositiva del título, "cita el primer caso real de un error" no se cita.
Pero como Robin destacó anteriormente en su primera diapositiva, el concepto de error se remonta tan lejos como podemos imaginar a los humanos haciendo computación, conceptos como un parche. El término "parche" proviene de un trozo de cinta real que se pega sobre un agujero en una tarjeta perforada. Pero el objetivo de todo esto es que el término "depuración" surgió de este concepto de encontrar un error en una máquina física. Y desde entonces, hemos utilizado esa terminología para tratar de lidiar con problemas, no tanto como la codificación de problemas en un programa que no se compila, sino como un programa que no funciona bien. Y específicamente no se ha perfilado solo encuentra cosas como bucles interminables que simplemente no van a ninguna parte.
Pero también tenemos un escenario, y pensé en poner un par de diapositivas divertidas antes de entrar en un poco más de detalle. Aquí está la caricatura clásica, llamada XKCD en la web, y el dibujante tiene algunas opiniones bastante divertidas sobre el mundo. Y este es sobre un niño llamado "Little Bobby Tables" y supuestamente sus padres llamaron a este niño Robert '); TABLA DE GOTA Estudiantes; - y se llama, y algo así como "Hola, esta es la escuela de su hijo que tiene problemas con la computadora", y el padre responde: "Oh, querido, ¿rompió algo?" Y el maestro dice: "Bueno, en cierto modo ", y la maestra pregunta, " ¿realmente nombraste a tu hijo Robert '); DROP TABLE Students; -? "Y el padre dice:" Oh, sí, pequeñas Bobby Tables, lo llamamos ". De todos modos, continúan diciendo que ahora han perdido los registros estudiantiles del año, espero que estén contentos. Y la respuesta es: "Bueno, deberías limpiar y desinfectar las entradas de tu base de datos". Y lo uso muchas veces para hablar sobre algunos de los problemas que tenemos al encontrar cosas en el código, que a menudo el código no mira los datos también.
Otra divertida, no sé si esto es real o no, sospecho que es una parodia, pero nuevamente, también toca mi hueso divertido. Alguien que cambia la placa de matrícula en la parte delantera de su automóvil, a una declaración similar que hace que las bases de datos caigan en las cámaras de velocidad, etc. Y siempre me refiero a eso porque dudo que algún programador haya anticipado un golpe y ejecución de su código por parte de un vehículo de motor real, pero nunca subestime eso: el poder de un geek enojado.
(La risa)
Pero supongo que esto me lleva a mi punto clave, y es que alguna vez pudimos depurar y perfilar el código como simples mortales. Pero soy de la opinión de que ese tiempo ha pasado, y anecdóticamente en mi experiencia, el primero, y esto me envejecerá terriblemente, estoy seguro; Robin, puedes burlarte de mí por esto, pero históricamente he venido de un entorno a la edad de 14 años deambulando por el extremo de la ciudad y tocando la puerta de un centro de datos llamado "Data Com" en Nueva Zelanda y preguntándome si podía ganar dinero de bolsillo en la escuela tomando el autobús a casa tarde, unos 25 km de viaje todos los días, poniendo papel en impresoras y cintas en unidades de cinta, y simplemente siendo un administrador general. Y curiosamente me dieron un trabajo. Pero con el tiempo, logré ingresar al personal y encontrar a los programadores y me di cuenta de que me encantaba la codificación y pasé por el proceso de ejecutar scripts y trabajos por lotes, que al final del día sigue siendo código. Debe escribir scripts y trabajos por lotes que parecen mini programas y luego pasar por todo el proceso de sentarse a mano en un código de escritura de terminal 3270.
De hecho, mi primera experiencia fue en un terminal de teletipo, que en realidad era una impresora física de 132 columnas. Esencialmente, piense en una máquina de escribir muy antigua con papel que se desplaza por ella, porque no tenían un tubo CRT. Y la depuración del código en ese asunto no era muy trivial, por lo que tendías a escribir todo tu código a mano y luego actuabas como un mecanógrafo, haciendo todo lo posible para que no se introdujeran errores, porque es extremadamente frustrante tener que decirlo el editor de una línea para ir a una determinada línea y luego imprimir la línea y luego volver a escribirla. Pero érase una vez, así fue como escribimos el código y así es como lo depuramos, y nos hicimos muy, muy buenos en eso. Y, de hecho, nos obligó a tener muy buenas técnicas de programación, porque fue una verdadera molestia solucionarlo. Pero el viaje continuó, y todos estamos familiarizados con esto, pasó de la experiencia del terminal 3270 en mi mundo, a Digital Equipment VT220, donde se podían ver cosas en la pantalla, pero nuevamente, simplemente estaban haciendo lo mismo. lo hizo en la cinta de papel en formato impreso solo en un CRT, pero pudo eliminarlo más fácilmente y no tenía ese sonido "dit dit dit dit".
Y luego, ya sabes, los terminales Wyse, como el Wyse 150, probablemente mi interfaz favorita para una computadora, y luego la PC y luego la Mac, y ahora estas GUI e ID modernas que están basadas en la web. Y una gama de programas a través de eso, programación en uno y ensamblador y PILOTO y Logo y Lisp y Fortran y Pascal y lenguajes que pueden hacer que la gente se avergüence. Pero estos son lenguajes que te obligaron a escribir un buen código; no te dejaron escapar con malas prácticas. C, C ++, Java, Ruby, Python: y avanzamos más en esa etapa de programación, nos volvemos más parecidos a los scripts, nos acercamos cada vez más al lenguaje de consulta estructurado y a lenguajes como PHP que realmente se utilizan para invocar SQL. El punto de decirle que, desde mi experiencia, fui autodidacta de muchas maneras y las que me ayudaron a aprender, me enseñaron muy buenas prácticas de programación y muy buenas prácticas sobre diseño y procesos para asegurarme de que no Introducir código con errores.
En la actualidad, los métodos de programación, como por ejemplo, el lenguaje de consulta estructurado, SQL, es un lenguaje de consulta simple muy potente. Pero lo hemos convertido en un lenguaje de programación y realmente no creo que SQL haya sido diseñado para ser un lenguaje de programación moderno, pero lo hemos sesgado para que se convierta en eso. Y eso introduce un montón de problemas, porque cuando pensamos en dos puntos de vista: desde el punto de vista de la codificación y desde el punto de vista del DBA. Es muy fácil presentarse e introducir errores para cosas como técnicas de programación deficientes, esfuerzos flojos para escribir código, falta de experiencia, el clásico motivo favorito que tengo, por ejemplo, con personas SQL que saltan a Google y buscan algo y encuentran un sitio web que sea obtuve un ejemplo y copiando y pegando el código existente. Y luego replicar una mala codificación, mala práctica y ponerla en producción, porque simplemente les da los resultados que desean. Tienes otros desafíos, por ejemplo, en estos días todos nos apresuramos hacia esto, lo que llamamos la carrera a cero: tratar de hacer todo tan barato y tan rápido, que tenemos un escenario en el que no estamos empleando menos personal pagado. Y no lo digo de manera falsa, pero no estamos contratando expertos para cada trabajo posible. Érase una vez que todo lo que tenía que ver con las computadoras era ciencia espacial; estuvo involucrado en cosas que se volvieron explosivas y muy ruidosas, o fueron al espacio o los ingenieros eran hombres y mujeres altamente calificados que habían obtenido títulos y tenían una educación rigurosa que les impedía hacer locuras.
En estos días, hay mucha gente entrando en el desarrollo, el diseño y la base de datos que no han tenido años de experiencia, no han tenido necesariamente la misma capacitación o apoyo. Y así termina con un escenario de solo el aficionado tradicional versus el experto. Y hay una línea famosa, en realidad no recuerdo quién creó la cita, la línea dice: “Si crees que es costoso contratar a un experto para hacer un trabajo, espera hasta que contrates a un par de aficionados que crean un problema y tú tiene que limpiarlo ”. Y entonces SQL tiene ese problema, y es muy, muy fácil de aprender, es muy fácil de usar. Pero no es, en mi opinión, un lenguaje de programación perfecto. Es muy fácil hacer cosas como hacer una estrella selecta desde cualquier lugar y poner todo eso en un lenguaje de programación con el que se sienta más cómodo, como PHP y Ruby o Python, y usar el lenguaje de programación con el que está nativamente familiarizado. la manipulación de datos, en lugar de hacer una consulta más compleja en SQL. Y vemos esto mucho, y luego la gente se pregunta por qué la base de datos se está ejecutando lentamente; es porque un millón de personas están tratando de comprar un boleto desde un sistema de venta de boletos en línea, donde hace una estrella selecta desde cualquier lugar.
Ahora, ese es un ejemplo realmente extremo, pero obtienes el punto de todo eso. Por lo tanto, para resaltar realmente ese punto, este es un ejemplo que llevo mucho. Soy un gran fanático de las matemáticas, me encanta la teoría del caos, me encantan los sets de Mandelbrot. En el lado derecho hay una versión del conjunto de Mandelbrot, que estoy seguro de que todos estamos familiarizados. Y a la izquierda hay una pieza de SQL que realmente lo representa. Ahora, cada vez que pongo esto en una pantalla en algún lugar, escucho este "Oh, Dios mío, alguien hizo la serie Mandelbrot con SQL, ¿lo dices en serio? ¡Eso es una locura! ”Bueno, el objetivo es ilustrar lo que estaba describiendo allí, y eso es sí, de hecho ahora puedes programar casi cualquier cosa en SQL; Es un lenguaje de programación muy desarrollado, potente y moderno. Cuando originalmente era un lenguaje de consulta, fue diseñado para obtener datos. Entonces, ahora tenemos construcciones muy complejas y tenemos procedimientos almacenados, tenemos una metodología de programación que se aplica a un lenguaje y, por lo tanto, es muy fácil para una mala práctica de programación, falta de experiencia, código de cortar y pegar, personal mal pagado tratando de ser un personal mal pagado, personas que fingen saberlo, pero que tienen que aprender en el trabajo.
Toda una gama de cosas donde la creación de perfiles de código y lo que llamamos depuración, no es tanto encontrar errores que impiden que los programas funcionen, sino errores que solo están dañando el sistema y el código mal estructurado. Cuando miras esta pantalla ahora, y piensas, es simplemente lindo, y piensas: "Vaya, qué gran gráfico, me encantaría ejecutar eso". Pero imagina que se ejecuta en alguna lógica empresarial. . Parece bastante ordenado, pero habla de una teoría matemática del caos representada gráficamente, pero cuando piensas para qué podría usarse en alguna lógica comercial, obtienes una idea muy rápida. Y para ilustrarlo realmente, y lamento que los colores se inviertan, se supone que debe ser un fondo negro y un texto verde para ser una pantalla verde, pero aún puede leer eso.
Fui y eché un vistazo rápido a un ejemplo de lo que potencialmente podrías hacer si estuvieras realmente loco y no tuvieras experiencia en absoluto y vinieras de un entorno diferente de programación y aplicara los gustos de C ++ a SQL, para ilustrar realmente mi punto, antes Le entrego a nuestro sabio invitado de IDERA. Esta es una consulta estructurada que está escrita como C ++, pero está codificada en SQL. Y en realidad se ejecuta, pero se ejecuta durante un período de tres a cinco minutos. Y retira aparentemente una línea de datos de múltiples bases de datos, múltiples uniones.
Una vez más, el punto principal de esto es que si no tiene las herramientas correctas, si no tiene las plataformas y entornos correctos para poder atrapar estas cosas, y entran en producción, y entonces tiene 100, 000 personas golpeando un sistema todos los días, u horas, o minutos, muy pronto terminas con una experiencia de Chernobyl donde el gran hierro comienza a derretirse y enterrarse en el núcleo del planeta, porque ese código nunca debería entrar en producción. Sus sistemas y sus herramientas, discúlpeme, deberían recogerlo antes de que se acerque a él, incluso a través del proceso de prueba, incluso a través de UAT y la integración de sistemas, ese fragmento de código debe seleccionarse y resaltarse y alguien debe ser apartado y diciendo: "Mira, ese es un código realmente bonito, pero obtengamos un DBA para ayudarte a construir esa consulta estructurada correctamente, porque francamente, eso es desagradable". Y la URL está ahí, puedes ir y echar un vistazo, se conoce como La consulta SQL más compleja que hayas escrito. Porque créeme, eso realmente se compila, se ejecuta. Y si corta y pega eso y simplemente se burla de la base de datos, es bastante algo para ver; Si tiene las herramientas para mirar la base de datos, simplemente intente fundirse durante un período de tres a cinco minutos, para devolver la llamada a una línea de texto.
Entonces, para resumir, con eso en mente, toda mi experiencia en codificación me ha enseñado que puedes dar un arma a la gente y que si no tienen cuidado se dispararán en el pie; El truco es mostrarles dónde está el mecanismo de seguridad. Con las herramientas adecuadas y el software adecuado a su alcance, después de haber realizado la codificación, puede revisar su código, puede encontrar problemas al crear un perfil del código, puede encontrar errores no intencionados que son problemas de rendimiento, y como dije anteriormente, una vez, podías hacerlo mirando una pantalla verde. Ya no puedes; Hay cientos de miles de líneas de código, hay decenas de miles de aplicaciones implementadas, hay millones de bases de datos en algunos casos, e incluso los súper humanos ya no pueden hacer esto a mano. Literalmente, necesita el software adecuado y las herramientas adecuadas a su alcance y necesita que el equipo use esas herramientas, para que pueda encontrar estos problemas y abordarlos muy, muy rápidamente, antes de llegar al punto, mientras que el Dr. Robin Bloor destacó, las cosas se vuelven desastrosas y las cosas explotan, o más comúnmente, simplemente comienzan a costarle muchos dólares y mucho tiempo y esfuerzo y destruyen la moral y esas cosas, cuando no pueden entender por qué las cosas toman mucho tiempo para correr.
Y con eso en mente, voy a entregar a nuestros invitados y espero escuchar cómo han resuelto este problema. Y particularmente la demostración que creo que estamos a punto de recibir. Eric, volveré a pasar.
Eric Kavanagh: OK, Bert, quítatelo.
Bert Scalzo: OK, gracias. Bert Scalzo aquí de IDERA, soy el gerente de producto de nuestras herramientas de base de datos. Y voy a hablar sobre depuración. Creo que una de las cosas más importantes que Robin dijo anteriormente, y es muy cierto, es que la depuración es onerosa y no trivial, y cuando va a la depuración de la base de datos es un orden de magnitud aún más oneroso y no trivial, por lo que Fue una cita importante.
OKAY. Quería comenzar con el historial de programación, porque muchas veces veo personas que no están depurando, no usan un depurador, solo programan con el lenguaje que estén usando, y muchas veces me dicen, "Bueno, esas cosas del depurador son nuevas, y todavía no hemos comenzado a usarlas". Entonces, lo que hago es mostrarles esta tabla de tiempo, una especie de prehistoria, la vejez, la edad media, es amable de decir dónde estábamos en términos de lenguajes de programación. Y teníamos idiomas muy antiguos a partir de 1951 con código de ensamblaje, y Lisp y FACT y COBOL. Luego nos metemos en el siguiente grupo, Pascals y Cs y luego en el siguiente grupo, los C ++ s, y miramos dónde está ese signo de interrogación: ese signo de interrogación está aproximadamente a la vuelta de 1978 a quizás 1980. En algún lugar de ese rango tuvimos depuradores disponibles para nosotros, y por así decir, "Oye, no estoy usando un depurador, porque esa es una de esas cosas nuevas", entonces debes haber comenzado a programar, ya sabes, en la década de 1950, porque esa es la la única forma en que te saldrías con esa afirmación.
Ahora, la otra cosa que es divertida de esta tabla es que Dez acaba de hacer un comentario sobre Grace Hopper, en realidad conocía a Grace, así que es un poco divertido. Y luego, la otra cosa de la que me reí es que habló sobre los teletipos y estoy sentado allí diciendo: "Hombre, ese fue el mayor salto que hemos tenido en productividad, cuando pasamos de las tarjetas a los teletipos, ese fue el salto más grande de la historia". "Entonces, y he programado en todos los idiomas aquí, incluido SNOBOL, del que nadie había oído hablar antes, era un CDC, Control Data Corporation, así que supongo que me estoy haciendo un poco viejo para esta industria .
Dez Blanchfield: Iba a decir que nos has envejecido terriblemente allí.
Bert Scalzo: Sí, te digo que me siento como el abuelo Simpson. Así que miro la depuración y hay diferentes formas de hacer la depuración. Podrías estar hablando de lo que todos pensamos que es tradicional entrar en un depurador y recorrer el código. Pero también, la gente instrumentará su código; ahí es donde pega las declaraciones en su código y tal vez produce un archivo de salida, un archivo de rastreo o algo así, y así instrumenta su código. Contaría eso como depuración, es un poco más difícil, una forma de hacerlo, pero cuenta. Pero también, tenemos la famosa declaración impresa: ves y la gente realmente pone declaraciones impresas y he visto una herramienta donde, y es una herramienta de base de datos, donde si no sabes cómo usar un depurador, presiona un botón y pegará las declaraciones de impresión en todo el código para usted y luego, cuando haya terminado, presione otro botón y los eliminará. Porque así es como mucha gente depura.
Y la razón por la que depuramos es doble: en primer lugar, tenemos que encontrar cosas que hagan que nuestro código sea ineficaz. En otras palabras, normalmente eso significa que hay un error lógico o hemos perdido un requisito comercial, pero lo que es es que el código no es efectivo; no hace lo que esperábamos que hiciera. La otra vez que vamos y hacemos depuración, es por eficiencia y eso podría ser un error lógico, pero lo que es es que hice lo correcto, simplemente no regresa lo suficientemente rápido. Ahora, hago ese punto porque un perfilador probablemente sea mejor para ese segundo escenario y vamos a hablar sobre depuradores y perfiladores. Además, existe este concepto de depuración remota; Esto es importante porque muchas veces, si está sentado en su computadora personal y está utilizando un depurador, que golpea una base de datos donde el código se ejecuta realmente en la base de datos, en realidad está haciendo lo que se llama depuración remota. Puede que no te des cuenta, pero eso es lo que está sucediendo. Y luego, es muy común con estos depuradores tener puntos de interrupción, puntos de observación, entrar y pasar y algunas otras cosas comunes, que voy a mostrar en una instantánea de la pantalla en un momento.
Ahora, creación de perfiles: puede hacer perfiles de un par de formas diferentes. Algunas personas dirán que la carga de trabajo captura y reproduce donde captura todo, eso cuenta como perfilado. Mi experiencia ha sido más, es mejor si se hace un muestreo. No hay ninguna razón para captar cada declaración, porque algunas declaraciones pueden ejecutarse tan rápido que no te importa, lo que realmente estás tratando de ver es, bueno, cuáles son las que siguen apareciendo una y otra vez, porque corren demasiado tiempo Por lo tanto, la creación de perfiles a veces puede significar un muestreo en lugar de ejecutar todo. Y, por lo general, obtendrá algún tipo de salida que puede usar, ahora que podría ser visual dentro de un entorno de desarrollo IDE, donde puede proporcionarle un histograma del rendimiento de las diversas líneas de código, pero también podría sea que produce un archivo de seguimiento.
Los perfiladores aparecieron por primera vez en 1979. Por lo tanto, también han existido durante mucho tiempo. Excelente para encontrar el consumo de recursos o problemas de rendimiento, en otras palabras, esa cuestión de eficiencia. En términos generales, es independiente y distinto del depurador, aunque he trabajado con depuradores que hacen ambas cosas al mismo tiempo. Y aunque los creadores de perfiles creo que son las más interesantes de las dos herramientas, si siento que no hay suficientes personas que depuran, entonces definitivamente no hay suficientes perfiles de personas, porque parece que uno de cada diez depuradores creará un perfil. Y eso es una pena, porque la elaboración de perfiles realmente puede hacer una gran diferencia. Ahora, los lenguajes de bases de datos, como hemos mencionado anteriormente, tienes SQL, y hemos forzado la clavija redonda en el agujero cuadrado aquí y forzado a convertirse en un lenguaje de programación, y Oracle. Eso es PL / SQL, ese es el lenguaje de procedimiento SQL, y SQL Server, es Transact-SQL, es SQL-99, es SQL / PSM, porque creo que es el Módulo de procedimiento almacenado. Postgres le da otro nombre, DB2 otro nombre más, Informix, pero el punto es que todos han forzado construcciones de tipo 3GL; en otras palabras, los bucles FOR, en declaraciones de variables y todas las demás cosas que son ajenas a SQL ahora son parte de SQL en esos lenguajes. Por lo tanto, debe poder depurar un PL / SQL o un Transact-SQL como lo haría con un programa de Visual Basic.
Ahora, los objetos de la base de datos, esto es importante porque la gente dirá: "Bueno, ¿qué cosas tengo que depurar en una base de datos?" Y la respuesta es, bueno, lo que pueda almacenar en la base de datos como código, si lo estoy haciendo T-SQL o PL / SQL, y estoy almacenando objetos en la base de datos, probablemente sea un procedimiento almacenado o una función almacenada. Pero también hay desencadenantes: un desencadenante es algo así como un procedimiento almacenado, pero se dispara en algún tipo de evento. Ahora, algunas personas en sus desencadenantes pondrán una línea de código y llamarán a un procedimiento almacenado para que conserven todo su código y procedimientos almacenados, pero es el mismo concepto: sigue siendo el desencadenante lo que inicia todo el proceso. Y luego, como Oracle, tienen algo llamado paquete, que es como una biblioteca, por así decirlo. Pones 50 o 100 procedimientos almacenados en una agrupación, llamada paquete, por lo que es como una biblioteca. Entonces, aquí está el depurador a la antigua usanza; esta es en realidad una herramienta que realmente entrará y pegará todas estas declaraciones de depuración en su código para usted. Entonces, donde sea que vea el bloque de depuración, no elimine, el depurador automático se inicia y rastrea, todos fueron atrapados por alguna herramienta. Y las líneas fuera de eso, que es la minoría del código, bueno, ese es el método de depuración no manual.
Y la razón por la que menciono esto es que, si está tratando de hacer esto a mano, en realidad va a escribir más código de depuración para incluir todas estas declaraciones de impresión que con el código. Entonces, si bien esto puede funcionar, y aunque es mejor que nada, esta es una forma muy difícil de depurar, especialmente porque, ¿qué pasa si se tarda 10 horas en ejecutar esto y dónde tiene un problema está en la línea tres? Si estuviera haciendo una sesión de depuración interactiva, lo habría sabido en la línea tres, cinco minutos después, oye, hay un problema aquí, puedo dejarlo. Pero con esto, tengo que esperar a que se ejecute, hasta completarlo y luego tengo que mirar algún archivo de rastreo que probablemente tenga todas estas declaraciones de impresión, e intentar encontrar la aguja en el alpaca. De nuevo, esto es mejor que nada, pero no sería la mejor manera de trabajar. Ahora, así es como se vería ese archivo que vino de la diapositiva anterior; en otras palabras, ejecuté el programa, y solo tengo un montón de declaraciones impresas en este archivo de rastreo y puedo o no ser capaz de extraerlo y encontrar lo que necesito encontrar. Entonces, de nuevo, no estoy tan seguro de que esta sea la forma en que desearía trabajar.
Ahora, los depuradores interactivos, y si ha usado algo como Visual Studio para escribir programas, o Eclipse, ha tenido depuradores y los usó con sus otros idiomas, simplemente no pensó en usarlos aquí con su base de datos. Y hay herramientas por ahí, como nuestro DB Artisan y nuestro Rapid SQL, este es Rapid SQL aquí, que tiene un depurador, y puede ver en el lado izquierdo, tengo un procedimiento almacenado llamado "verificar duplicados". Básicamente, solo va a ir a ver y ver si tengo varias filas en la tabla con el mismo título de película. Entonces, la base de datos es para películas. Y se podía ver en el lado derecho, en el tercio superior, tengo mi código fuente en el medio, tengo lo que se llama mis variables de vigilancia y mis bandejas de pila de llamadas, y luego en la parte inferior I ' Tengo algunos mensajes de salida. Y lo importante aquí es que si miras por encima de esa primera flecha roja, si pasas el mouse sobre una variable, en realidad puedo ver qué valor hay en esa variable en ese momento, mientras paso por el código. Y eso es realmente útil, y luego puedo pasar una línea a la vez a través del código, no tengo que decir ejecutar, podría decir paso a línea, déjame ver lo que pasó, paso a otra línea, déjame ver qué pasó, y estoy haciendo esto en la base de datos. Y aunque estoy sentado en Rapid SQL en mi PC y mi base de datos está en la nube, aún puedo hacer esa depuración remota y verla y controlarla desde aquí, y hacer la depuración como lo haría con cualquier otro idioma.
Ahora, la siguiente flecha allí: puede ver la pequeña flecha que apunta hacia la derecha, hacia esa salida DBMS, ahí es donde está mi cursor en este momento, por lo que en otras palabras, he pisado y ahí es donde estoy el momento. Entonces, si digo: "Paso de nuevo", voy a ir a la siguiente línea. Ahora, justo debajo de eso, verás el punto rojo. Bueno, ese es un punto de quiebre, que dice "Oye, no quiero pasar por encima de estas líneas". Si solo quiero saltar sobre todo y llegar a ese punto rojo, puedo presionar el botón de ejecutar y se ejecutará desde aquí hasta el final, o hasta un punto de interrupción, si hay algún punto de interrupción establecido, y luego se detendrá y me permitirá dar el paso nuevamente. Y la razón por la que todo esto es importante y poderoso es porque cuando estoy haciendo todo esto, lo que sucede en el medio e incluso en la parte inferior, pero lo más importante, en el medio, cambiará y puedo ver los valores de mis variables, Puedo ver mi rastro de la pila de llamadas, ya sabes, y toda esa información se muestra allí mientras paso por el código, de modo que realmente puedo ver y sentir y comprender lo que está sucediendo y cómo es realmente el código trabajando en tiempo de ejecución. Y típicamente puedo encontrar un problema, si hay uno, o si soy lo suficientemente bueno como para atraparlo.
Bien, ahora voy a hablar sobre un perfilador, y en este caso, este es un perfilador que puedo ver a través de un depurador. ¿Recuerdas que dije que a veces están separados y a veces pueden estar juntos? En este caso, y nuevamente, estoy en Rapid SQL, y puedo ver que hay un margen, en el lado izquierdo, al lado de los números de línea. Y lo que es eso es la cantidad de segundos o microsegundos que se tardó en ejecutar cada línea de código, y puedo ver claramente que todo mi tiempo lo paso en este bucle FOR donde selecciono todo de una tabla . Y entonces, lo que sea que esté sucediendo dentro de ese ciclo FOR probablemente sea algo que necesito mirar, y si puedo mejorarlo, pagará dividendos. No voy a obtener ninguna mejora trabajando en esas líneas que tienen 0.90 o 0.86; No hay mucho tiempo allí. Ahora, en este caso, y nuevamente, estoy en Rapid SQL, está viendo cómo puedo hacer perfiles entremezclados con mi depuración. Ahora, lo bueno es que Rapid SQL también te permite hacerlo de otra manera. El SQL rápido le permite decir: “¿Sabes qué? No quiero estar en el depurador, solo quiero ejecutar esto y luego quiero ver gráfica o visualmente el mismo tipo de información ".
Y puede ver que ya no estoy en el depurador y ejecuta el programa y después de que se realiza la ejecución, me da gráficos para decirme cosas, así puedo ver que tengo una declaración que parece que está ocupando la mayor parte del gráfico circular y si miro, veo en esa cuadrícula hacia abajo, línea 23, está el bucle FOR nuevamente: está ocupando la mayor parte del tiempo, de hecho es rojo oscuro masticando todo el gráfico circular. Y así, esta es otra forma de hacer perfiles. Llamamos a ese "Analista de Código" en nuestra herramienta. Pero es básicamente un perfilador separado de un depurador. A algunas personas les gusta hacerlo de la primera manera, a algunas personas les gusta hacerlo de la segunda.
¿Por qué hacemos depuración y creación de perfiles? No es porque queramos escribir el mejor código del mundo y obtener un aumento de sueldo, esa podría ser nuestra razón, pero esa no es realmente la razón por la que lo hace, le prometió al negocio que haría algo correctamente, que su programa será efectivo. Para eso usarás el depurador. Además, usuarios finales comerciales; no son muy pacientes: quieren resultados incluso antes de presionar la tecla. Se supone que debemos leer su mente y hacer todo instantáneamente. En otras palabras, tiene que ser eficiente. Y entonces, para eso usaríamos el generador de perfiles. Ahora, sin estas herramientas, realmente creo que eres este tipo en el traje de negocios con el arco y la flecha y estás disparando al objetivo y tienes los ojos vendados. Porque, ¿cómo va a encontrar cómo se ejecuta un programa simplemente mirando el código estático y cómo va a averiguar qué línea es donde realmente pasaría más tiempo en la ejecución, de nuevo, simplemente mirando el código estático? Una revisión de código puede o no mostrar algunas de estas cosas, pero no hay garantía de que una revisión de código las encuentre a todas. Con un depurador y un generador de perfiles, debería poder encontrar todos esos errores.
OK, solo voy a hacer una demostración rápida aquí. No es mi intención impulsar el producto, solo quiero mostrarles cómo se ve un depurador porque muchas veces la gente dice: "Nunca he visto uno de estos antes". Y se ve bonito en las diapositivas de la pantalla, pero ¿cómo se ve cuando está en movimiento? Entonces, aquí en mi pantalla estoy ejecutando nuestro producto DB Artisan; Tenemos un depurador allí también. El DB Artisan está más destinado a los DBA, el Rapid SQL es más para los desarrolladores, pero he visto desarrolladores que usan DB Artisan, y he visto a los DBA que usan Rapid. Por lo tanto, no se deje atrapar por el producto. Y aquí, tengo la opción de hacer una depuración, pero antes de iniciar la depuración, voy a extraer este código para que pueda ver cómo se ve el código antes de comenzar a ejecutarlo. Entonces, aquí está exactamente el mismo código que estaba en la captura de pantalla, esta es mi verificación de duplicados. Y quiero depurar esto, así que presiono debug. Y ahora, lleva un momento y usted dice: "Bueno, ¿por qué está tomando un momento?". Recuerde la depuración remota: la depuración está ocurriendo en mi servidor de base de datos, no en mi PC. Entonces, tenía que ir y crear una sesión allí, crear una cosa de depuración remota, conectar mi sesión a esa sesión de depuración remota y configurar un canal de comunicación.
Entonces, ahora, aquí está mi flecha, está arriba en la parte superior, en la línea uno, ahí es donde estoy en el código. Y si presiono el tercer ícono allí, que es un paso, verás que esa flecha se acaba de mover, y si sigo presionándola, verás que sigue moviéndose. Ahora, si quisiera llegar hasta este bucle FOR, porque sé que ahí es donde está el problema, puedo establecer un punto de interrupción. Pensé que había establecido eso. Oh, dispara, tenía una de mis teclas de captura de pantalla asignadas a la misma tecla que el depurador, eso es lo que está causando la confusión. OK, así que establecí manualmente un punto de interrupción allí, así que ahora, en lugar de hacer un paso, paso, paso, paso hasta llegar allí, en realidad solo puedo decir: "Adelante y ejecuta esta cosa", y se detendrá. Observe que me movió hasta el punto de ruptura, así que ahora estoy en el contexto de ejecutar este ciclo, puedo ver a qué están configuradas todas mis variables, lo cual no es una sorpresa, porque las inicialicé todas a cero. Y ahora, puedo entrar en este bucle y comenzar a mirar lo que sucede dentro de este bucle.
Entonces, ahora va a hacer un recuento selecto de mis alquileres y puedo pasar el mouse sobre ese tipo y mirar, él es dos, dos es mayor que uno, por lo que probablemente va a hacer la siguiente pieza de este código. En otras palabras, encontró algo. Solo voy a seguir adelante y dejar que eso se ejecute. No quiero pasar por todo aquí; lo que quiero mostrarte es que cuando se hace un depurador, termina como un programa normal. Tengo el punto de interrupción establecido, así que cuando dije correr, simplemente volví al siguiente punto de interrupción. Estoy dejando que se ejecute hasta el final, porque lo que quiero que veas es que un depurador no cambia el comportamiento del programa: cuando termine de ejecutarse, debería obtener exactamente los mismos resultados si no lo hubiera ejecutado dentro de un depurador.
Y con eso, suspenderé la demostración y regresaré porque queremos asegurarnos de tener tiempo para preguntas y respuestas. Y así, lo abriré para preguntas y respuestas.
Eric Kavanagh: Muy bien, Robin, ¿tal vez una pregunta tuya y luego una pareja de Dez?
Robin Bloor: Sí, claro, me parece fascinante, por supuesto. He trabajado con cosas como esta, pero nunca he trabajado con algo así en la base de datos. ¿Puedes darme una idea de para qué usa la gente el generador de perfiles? Porque es como si estuvieran mirando, porque supongo que lo están haciendo, están viendo problemas de rendimiento, ¿te ayudará a distinguir cuándo una base de datos toma tiempo y cuándo un código toma tiempo?
Bert Scalzo: Sabes, esa es una pregunta fantástica. Digamos que estoy trabajando en Visual Basic y, dentro de mi Visual Basic, voy a llamar a Transact-SQL o PL / SQL. Déjame hacer el PL / SQL, ya que Oracle no siempre juega bien con las herramientas de Microsoft. Podría estar perfilando mi código de Visual Basic, y el perfil allí podría decir: "Oye, llamé a este procedimiento almacenado y me tomó demasiado tiempo". Pero luego puedo ingresar al procedimiento almacenado y puedo hacer un perfil de base de datos en el procedimiento y diga, "OK, de las 100 declaraciones que están aquí, aquí están las cinco que estaban causando el problema". Entonces, puede que tenga que hacer un equipo de etiquetas, donde debe usar múltiples perfiladores.
La idea es que si alguna vez le dicen que el problema de rendimiento está en su base de datos, un perfil de base de datos puede ayudarlo a encontrar la aguja en el pajar en el que las declaraciones son realmente las que tiene un problema. Te digo otra cosa que apareció con la creación de perfiles: si tienes un código que se llama un millón de veces, pero solo toma un microsegundo cada uno de los millones de veces, pero se llama un millón de veces, lo que el perfilador mostrará, esa cosa funcionó durante tantas unidades de tiempo. Y, si bien el código puede ser muy eficiente, puede mirar y decir: “Ooh, estamos haciendo esta llamada a este fragmento de código con demasiada frecuencia. Tal vez solo deberíamos llamarlo de vez en cuando, en lugar de cada vez que procesamos un registro ", o algo así. Y así puede encontrar dónde hay un código eficiente que se llama con demasiada frecuencia, y que en realidad es un problema de rendimiento.
Robin Bloor: Sí, eso es maravilloso. Nunca he hecho esto. Verá, por supuesto, cuando tuve problemas con la base de datos fue como si de una forma u otra estuviese tratando con una base de datos o con un código; Nunca podría lidiar con ambos al mismo tiempo. Pero allí, de nuevo, no hice un … Nunca he estado involucrado en la creación de aplicaciones donde teníamos procedimientos almacenados, así que supongo que nunca he tenido problemas que solían volverme loco, la idea de que tú dividiría el código entre una base de datos y un programa. Pero así que, hazlo todo: supongo que la respuesta será afirmativa, pero esto es parte de una actividad del equipo de desarrollo, cuando estás de una manera u otra tratando de arreglar algo que está roto, o tal vez tratando de traer una nueva Aplicación juntos. ¿Pero todo esto se adapta a todos los demás componentes que esperaría en el entorno? ¿Puedo esperar que pueda recortar esto junto con todos mis paquetes de prueba y todas esas otras cosas que estaría haciendo y con mis cosas de gestión de proyectos, es así como todos estos clips se juntan?
Bert Scalzo: Sí, puede formar parte de cualquier proceso estructurado para hacer sus esfuerzos de programación o desarrollo. Y es curioso, la semana pasada tuve un cliente que estaba creando una aplicación web, y su base de datos había sido pequeña, históricamente, por lo que el hecho de que no fueran muy buenos programadores nunca los perjudicó. Bueno, su base de datos ha crecido a lo largo de los años, y ahora lleva 20 segundos en una página web, entre cuando dices: "Iniciar sesión y darme algunos datos para ver" y cuando aparece la pantalla, y ahora es Un problema de rendimiento. Y sabían que el problema no estaba en ninguno de sus Java ni en ninguno de esos otros lugares. Pero tenían miles de procedimientos almacenados, por lo que tuvieron que comenzar a perfilar los procedimientos almacenados para descubrir por qué esta página web tarda 20 segundos en aparecer. Y en realidad descubrimos que tenían una unión cartesiana en una de sus declaraciones selectas y no lo sabían.
Robin Bloor: Wow.
Bert Scalzo: Pero alguien me dijo una vez: "Bueno, ¿cómo podrían tener una unión cartesiana y no saberlo?" Y esto sonará realmente horrible; a veces un programador que no se siente muy cómodo con SQL hará algo como darme una combinación cartesiana, pero luego solo me devolverá el primer registro, así que sé que obtuve algo y solo necesito el primero. Por lo tanto, no se dan cuenta de que solo trajeron un billón de registros o que miran a través de un billón de registros, porque obtuvieron el que les interesaba.
Robin Bloor: Wow, lo sé, eso es lo que se llama, bueno, de eso se trataba Dez, en términos de personas que no son tan hábiles como quizás deberían ser, ya sabes. Si eres un programador, debes saber cuáles son las implicaciones de emitir cualquier comando. Quiero decir, realmente, no hay excusa para ese nivel de estupidez. También supongo que usted es, de una forma u otra, solo agnóstico del lenguaje con respecto a esto, porque todo esto se centra en el lado de la base de datos. ¿Estoy en lo cierto? ¿Es lo mismo, lo que sea que esté usando en el lado de la codificación?
Bert Scalzo: Absolutamente, puedes hacer esto en Fortran o C o C ++. De hecho, en algunos Unixes incluso puedes hacerlo por sus lenguajes de script; en realidad proporcionan las mismas herramientas. Y luego quiero retroceder un segundo por lo que dijiste sin excusa. Voy a darles un descanso a los programadores, porque no me gusta tirar a los programadores debajo del autobús. Pero el problema es realmente el entorno académico porque cuando vas a aprender cómo ser un programador, te enseñan a pensar de forma récord. No se le enseña el pensamiento de conjunto, y eso es lo que Structured Query Language o SQL funciona con conjuntos; Es por eso que tenemos la unión, la intersección y el operador menos. Y a veces es muy difícil para una persona que nunca ha pensado en términos de conjuntos, renunciar, dejar de lado el procesamiento de grabación a la vez y trabajar con conjuntos.
Robin Bloor: Sí, estoy contigo en eso. Quiero decir, entiendo, ese es un problema de educación; Creo que es completamente un problema educativo, creo que es natural que los programadores piensen de manera procesal. Y SQL no es de procedimiento, es declarativo. En realidad solo estás diciendo: "Esto es lo que quiero y no me importa cómo lo haces", ¿sabes? Mientras que con los lenguajes de programación, a menudo te arremangas y tienes las minucias de incluso administrar los recuentos, mientras haces un ciclo. Voy a pasar a …
Bert Scalzo: No. Bien, continúa.
Sí, iba a decir que mencionaste otro ejemplo de que un perfilador sería bueno para atrapar el tipo de procesamiento de grabación a la vez. A veces, un programador que es bueno en una lógica de registro a la vez, no puede descubrir cómo hacer un programa SQL. Bueno, digamos que hace dos bucles FOR y básicamente hace una unión, pero lo hace del lado del cliente. Entonces, está haciendo el mismo efecto que una unión, pero lo está haciendo él mismo, y un perfil lo captaría, porque probablemente terminarías pasando más tiempo haciendo la unión manualmente que dejando que el servidor de la base de datos lo haga por ti.
Robin Bloor: Sí, eso sería un desastre. Quiero decir, estarías dando vueltas. Golpear siempre es malo.
De todos modos, pasaré a Dez; Estoy seguro de que tiene algunas preguntas interesantes.
Dez Blanchfield: Gracias, sí, lo hago. Voy a unirme a ustedes para no tirar a los programadores debajo del autobús. Quiero decir, he pasado demasiados años en mi vida siendo un codificador, en todos los niveles, ya sabes, ya sea como dijiste, sentado en la línea de comando de la máquina Unix, y en algunos casos, incluso estuve involucrado en un par de puertos diferentes de Unix de una plataforma de hardware a otra. Y puedes imaginar los desafíos que tuvimos allí. Pero la realidad es que aquí está esa tarjeta de salida de la cárcel para cada programador y programador del mundo. Es una ciencia de cohetes, literalmente, escribir realmente apretado cada vez, todo el tiempo, es una ciencia de cohetes. Y famosas historias de personas como Dennis Ritchie y Brian Kernahan trabajando en algún código de forma independiente y luego acudiendo a un chat de revisión de código mientras toman un café y descubren que escribieron exactamente el mismo código, exactamente en el mismo programa, exactamente de la misma manera. Y lo hicieron en C. Pero ese nivel purista de programación existe muy raramente.
El hecho es que a diario, solo hay 24 horas en un día, siete días en una semana, y solo tenemos que hacer las cosas. Y así, cuando se trata no solo de programadores tradicionales, los DBA y codificadores, y scripters, y sysadmin, y administradores de red, y personal de seguridad, y todo hasta el lado de los datos ciudadanos en estos días; escuchamos, todos están tratando de hacer su trabajo. Así que creo que lo mejor de todo esto es que me encantó tu demo y me encantó la comida para llevar que nos dejaste allí, hace un momento, hablando con Robin sobre el hecho de que esto tiene un particular, tal vez no tanto un nicho, pero un amplio espacio al que se aplica, en cuanto a la fijación de código y SQL y bases de datos. Pero estaba realmente emocionado de escucharlo decir que podría meterlo en un script de shell y encontrar algunos problemas, porque ya sabe, en la actualidad siempre estamos trabajando al menor costo en todo.
La razón por la que puede comprar una camisa de $ 6 en algún lugar es porque alguien construyó un sistema lo suficientemente barato como para fabricar y enviar y entregar logísticamente y vender y vender y tomar pagos en línea para obtener esa camisa de $ 6. Y eso no sucede si se le paga a la gente $ 400, 000 al año para escribir el código de la manera perfecta; Es solo un desarrollo completo. Entonces, ese punto, supongo que una de las preguntas que realmente me encantaría que nos brinde más información es cuál es la amplitud y el alcance del tipo de personas que está viendo actualmente que están implementando este tipo de herramientas para perfilar un código y buscar problemas de rendimiento? Inicialmente, históricamente, ¿de dónde vienen? ¿Han sido las grandes casas de ingeniería? Y luego, en el futuro, es el caso, ¿estoy en lo cierto al pensar que cada vez más empresas están implementando esta herramienta, o estas herramientas, para intentar ayudar a los codificadores, quienes saben quién está haciendo las cosas para terminar el trabajo? y sacarlo por la puerta? ¿Y a veces necesitamos una tarjeta para salir de la cárcel? ¿Estoy en lo cierto al pensar que históricamente tuvimos un enfoque y desarrollo más de ingeniería? ¿Ahora, estamos obteniendo un enfoque académico menos, como Robin dijo, y ahora es autodidacta, o código de cortar y pegar, o simplemente construir cosas? ¿Y eso coincide con el tipo de personas que están tomando el producto ahora?
Bert Scalzo: Sí, exactamente. Y le daré un ejemplo muy específico, solo queremos hacer el trabajo, porque la gente de negocios no quiere la perfección. Es algo así como un juego de ajedrez computarizado: el juego de ajedrez no busca la respuesta perfecta; busca una respuesta que sea lo suficientemente buena en un tiempo razonable, así que así es como programamos. Pero lo que encuentro ahora es que la mayoría de las personas en lugar de decir que quieren un perfilador como parte de sus pruebas unitarias, que es cómo lo haría, porque no lo veo como una pérdida de tiempo, lo que está sucediendo es ahora que eso se hace más tarde, a veces, durante las pruebas de integración o las pruebas de estrés, si tenemos suerte. Pero la mayoría de las veces es parte de una escalada, donde algo entró en producción, funcionó durante un tiempo, tal vez incluso funcionó durante años, y ahora no funciona bien, y ahora lo perfilaremos. Y ese parece ser el escenario más común ahora.
Dez Blanchfield: Sí, y creo que el término "deuda técnica" es probablemente uno con el que estás más que familiarizado; Sé que Robin y yo ciertamente lo somos. Creo que en estos días, particularmente en los enfoques ágiles para el desarrollo y la construcción de sistemas, para mí, el concepto de deuda técnica ahora es algo muy real, y en realidad lo tenemos en cuenta en los proyectos. Lo sé, quiero decir, tenemos nuestros propios proyectos, como Media Lens y otros, en los que tenemos que programar a diario, y varias cosas en el Grupo Bloor. Y cada vez que estamos construyendo algo, lo miramos, lo miro, y siempre miro desde el punto de vista de lo que me va a costar arreglar esto en este momento, en comparación, ¿puedo obtenerlo en el puede y sacarlo, y luego mirar y ver si esto se va a romper. Y herede esta deuda técnica que sé que tendré que volver más tarde y arreglar.
Y quiero decir, lo he hecho en los últimos siete días: he escrito un par de herramientas y scripts, he escrito un par de piezas de lenguaje Python, y lo he implementado en Mongo back end, haciendo seguro que es agradable, limpio y seguro, pero solo obtiene la consulta que necesito hacer, sabiendo que necesito esa función para funcionar, para llegar al rompecabezas más grande; ahí es donde está mi verdadero dolor. Y entonces incurres en esta deuda técnica, y creo que esto no es solo algo ocasional, creo que esto es parte del ADN del desarrollo ahora. Las personas simplemente, no falsamente, simplemente aceptan que la deuda técnica es un tipo de problema de modus operandi normal, y solo tienen que incurrir en ella. Es donde incurres en la deuda técnica. Y creo que lo mejor de lo que nos mostró en la demostración fue que literalmente puede perfilar y ver cuánto tiempo lleva ejecutar algo. Y esa es probablemente una de mis cosas favoritas. Quiero decir, en realidad he creado herramientas de creación de perfiles: solíamos construir herramientas en Sed, Lex y Orc para ejecutar nuestro código y ver dónde estaban los bucles, antes de que herramientas como esta estuvieran disponibles, y cuando has creado código para ir y revise su propio código, se vuelve muy bueno al no tener que revisar su propio código. Pero ese no es el caso ahora. Con eso en mente, ¿hay un segmento de mercado en particular que tome esto más que ningún otro? Ver como una masa
Bert Scalzo: Oh, sí, tengo que … Voy a dibujar una analogía para ti y mostrarte que los no programadores lo hacen todo el tiempo. Porque si alguna vez enseño un depurador y una clase o sesión de creación de perfiles, le preguntaré a la gente: "OK, ¿cuántas personas entran aquí a Microsoft Word y nunca usan el corrector ortográfico a propósito? Y nadie levanta la mano, porque para escribir documentos, todos sabemos que podemos cometer errores en inglés, por lo que todos usan el corrector ortográfico. Y le dije: "Bueno, ¿cómo es que cuando estás escribiendo texto en tu IDE como Visual Basic, no estás usando el depurador? Es lo mismo, es como un corrector ortográfico ".
Dez Blanchfield: Sí, en realidad, esa es una gran analogía. Realmente no había pensado, tengo que admitir que realmente hago algo similar con un par de herramientas que uso. De hecho, uno, ODF, mi favorito con Eclipse es simplemente cortar y pegar el código allí y buscar cosas que solo resalten de inmediato y me doy cuenta de que hice un error tipográfico en alguna llamada de clase. Y, pero ahora es interesante con una herramienta como esta, puedes hacerlo en tiempo real en lugar de volver y mirarlo más tarde, lo cual es algo agradable de ver por adelantado. Pero sí, esa es una gran analogía de simplemente poner texto en un procesador de textos, porque es una llamada de atención interesante que, solo date cuenta de que has cometido algunos errores tipográficos o incluso un error gramatical, ¿verdad?
Bert Scalzo: Exactamente.
Dez Blanchfield: Entonces, ¿estás viendo más de un aumento ahora de, supongo, quiero decir, la última pregunta de mí, antes de lanzar a nuestras preguntas y respuestas tal vez, para nuestros asistentes. Si iba a dar algún tipo de recomendación sobre el enfoque para hacer esto, supongo que esto es retórico, ¿es el caso de que llegue temprano y lo implemente a medida que se desarrolla, antes de desarrollar? ¿O es el caso de que predominantemente construyes, te mueves, construyes algo y luego entras y lo perfilas más tarde? Sospecho que es el caso de llegar temprano y asegurarse de que su código esté limpio por adelantado. ¿O es un caso que deberían estar considerando esta parte de su despliegue posterior?
Bert Scalzo: Idealmente, lo harían por adelantado, pero como todo el mundo está en el ajetreado mundo donde solo tienen que hacer cosas, tienden a no hacerlo hasta que se encuentran con un problema de rendimiento que no pueden resolver. agregando más CPU y memoria a una máquina virtual.
Dez Blanchfield: Sí. Entonces, ¿en realidad mencionaste algo interesante, si puedo rápidamente? Usted mencionó anteriormente que esto puede ejecutarse desde cualquier lugar y puede comunicarse con la base de datos en el back-end. Así que esto es cómodo con el tipo de concepto bimodal del que hablamos ahora, de nube en las instalaciones / fuera de las instalaciones, por el aspecto de las cosas también, al final del día, si puede hablar con el back-end y ver el código, realmente no le importa, ¿verdad?
Bert Scalzo: Exactamente, sí, puedes ejecutar esto en la nube.
Dez Blanchfield: Excelente, porque creo que es a donde va nuestro nuevo mundo valiente. Entonces Eric. Voy a responderle ahora y veré que tenemos algunas preguntas aquí y quiero que nuestros asistentes aún se queden con nosotros, a pesar de que hemos pasado la hora.
Eric Kavanagh: Sí, hay algunas personas por ahí, solo haré un comentario rápido: Bert, creo que esa metáfora, la analogía que das al usar el corrector ortográfico es francamente brillante. Eso es digno de un blog o dos, francamente, porque es una buena manera de enmarcar el contexto de lo que estás haciendo, y lo valioso que es, y cómo realmente debería ser una mejor práctica usar un depurador de forma regular, ¿verdad? Apuesto a que tienes algunas cabezas asintiendo cuando tiras esa, ¿verdad?
Bert Scalzo: Absolutamente, porque lo que les digo es: “¿Por qué hago un corrector ortográfico en mis documentos? No quiero sentirme avergonzado por los estúpidos errores de ortografía ”. Bueno, ¡no quieren avergonzarse por los estúpidos errores de codificación!
Eric Kavanagh: Correcto. Si, de hecho. Bueno, amigos, hemos quemado una hora y cinco minutos aquí, muchas gracias a todos por su tiempo y atención. Archivamos todos estos chats web, no dude en volver en cualquier momento y verlos. El mejor lugar para encontrar esos enlaces es probablemente techopedia.com, así que agregaremos esto a esta lista aquí.
Y con eso, nos despediremos, amigos. Una vez más, buen trabajo, Bert, gracias a nuestros amigos de IDERA. Hablaremos con usted la próxima vez, hablaremos con usted la próxima semana, de hecho. ¡Cuídate! Adiós.
