Enigma LABS

Como programador, he aprehendido la importancia de los test unitarios por la vía del dolor. Por la vía de los mantenimientos de software que se van volviendo más y más inmantenibles día tras día, por la vía de corregir un error con urgencia, subirlo a un entorno de producción habiendo hecho las pruebas funcionales justas, y totalmente orientadas a probar la parte que se ha modificado, para darme cuenta -también dolorosamente- que la corrección del error produce otro error en algún otro punto de la solución, que obliga a revertir el cambio, corregir de nuevo con la presión del negocio en aumento, y subir la corrección de la corrección con los dedos cruzados y las rodillas temblorosas, a sabiendas de que ningún mecanismo me garantiza que no vuelva a pasar lo mismo. Sencillamente no se pueden repetir manualmente todas las pruebas, todas las casuísticas que pudieran haberse visto afectadas por el cambio. Cuesta un poco entender el test unitario como una inversión, pero cuando por fin ...

En el anterior post ( Proyecto GEOW. Implementando el patrón CQRS ) nos adentramos en el funcionamiento del proyecto GEOW que nos va a servir de base para implementar un patrón arquitectónico, CQRS , pensado para dar respuesta a sistemas con alta exigencia de lecturas y escrituras simultáneas. Para ello hemos creado una interfaz gráfica con una serie de figuras geométricas en movimiento. Ahora vamos a ir a la parte de EL DATO. Cada vez que uno de estos cuadrados cambia de posición envía una trama con sus propias características, y sus nuevas coordenadas. Cada uno de los cuadrados realiza un movimiento cada 300 milisegundos, y he llegado a probar con hasta unas 700 figuras. En estos niveles el software empieza a sufrir, pero más la parte gráfica. Aparentemente el sistema de grabación de coordenadas se mantiene en buena forma. Vamos a ver, precisamente, este sistema de grabación: Grabando lotes de coordenadas en BBDD En el objeto PointObj que representa cada una de las figuras, en el ...

En esta nueva entrega de la publicación  Trazabilidad y control de errores vamos a centrarnos en el que es quizá el más interesante aspecto de la trazabilidad.  Structured Logging es la técnica que nos permitirá realizar análisis automatizados de nuestra trazabilidad, mediante software de detección de eventos. En la primera parte de la publicación incorporamos a nuestra plataforma de test Open Source la librería NLog , y configuramos la generación de dos ficheros de texto plano para trazas, uno para dejar la información de los posibles errores no controlados, y otro para los avisos, o warnings . Además asociamos la consola para crear trazas de información para la depuración. Hoy vamos a configurar la creación de un tercer fichero, que almacenará igualmente información de los errores, pero en este caso guardará la información no en texto plano, sino estructurada, con notación JSON que después podría ser procesada. Para este fin NLOG nos proporciona el JSON Layout . Vamos a ...

" Cada vez que cometo un error me parece descubrir una verdad que no conocía " Maurice Maeterlinck Hoy abordamos un aspecto crucial en todo buen desarrollo. El control de errores. Y es que, amigos, aunque se encuentren Uds. en el TOP 5 de los mejores programadores de su barrio, una cosa es segura, y es que no hay nada seguro, y que todo lo que pueda fallar, fallará. Más importante que no cometer errores -al menos respecto al desarrollar software-, es controlarlos adecuadamente. Hay que convivir con el error como un elemento más de nuestros desarrollos, tratándolo con mimo y cautela, vigilándolo, corrigiéndolo, monitorizándolo... Amigos, no oculten sus errores. ¡Expóngalos! ¡Enfréntense a ellos! Aquí el desarrollo de software y la vida vislumbran algunos paralelismos. Pero centrémonos en el desarrollo. ¿Creen que si dejan su código bajo un try {} catch {} sin más, su código aparentará no fallar nunca? Ciertamente no habrá excepciones no controladas, pero s...