Desarrollando desde la trinchera.

Para hacer la primer prueba de CODA CLI, decidi ir por algo sencillo y conocido.  Queria un utilitario command line, que permita analizar un log de la ejecucion de una aplicacion GeneXus y me ayudara a detectar problemas (fundamentalmente para mejorar performance).  Lo que hice fue partir de cero, dandole ejemplos del archivo que queria procesar y luego ir agregando una a una las diferentes funcionalidades que queria.  ✅  Detección de demoras  - Identifica operaciones lentas ✅  Análisis de errores  - Separa y agrupa errores y warnings ✅  Totalización por programa  - Cuenta ejecuciones de cada programa ✅  Totalización por SQL  - Identifica queries más frecuentes ✅  Análisis de conexiones  - Detecta conexiones lentas o no cerradas ✅  Duración de logs  - Calcula el periodo cubierto por cada log Hasta ahi, todo fue muy bien.  Cuando le pedi algo un poco mas sofisticado, como armar un arbol de llamadas, partiendo...

Estoy haciendo algunas pruebas con Genexus Next, para aclimatarme y utilizar agentes de IA en codigo GeneXus.  Aun siento que le faltan algunos minutos de coccion como para que este pronto para ser usado en proyectos de verdad, pero esta bueno ver un poco como se avanza en el tema.  Una de las cosas que tenia que hacer es lograr conectarme a la base de datos generada, con SQL Server Management Studio y poder ver los datos y hacer algunos ajustes.  Como estoy usando Docker en windows para esta prueba, la base de datos queda dentro del contenedor que distribuyen con Genexus Next. El usuario y la password del administrador, tambien quedan no visibles.  Ya no tenemos mas el icono del ojo para ver el valor de la contraseña en el IDE.  Haciendo algo de ingenieria reversa en los docker-compose que levantan el IDE de GXNext, pude ver que dentro del archivo app.asar (es un formato de archivos indexados de atom que se puede abrir con VS Code y algunos otros ) se encuentra...

Una de las ideas más potentes de Specification by Example es simple: las reglas del negocio no deben quedar en documentos ambiguos, sino en ejemplos concretos que puedan ejecutarse. Si bien este libro se escribio antes que  la IA generativa tuviera la visibilidad que tiene hoy, sigue teniendo mucha vigencia.  Si combinamos esto con un enfoque model-driven , podemos ir un paso más allá: definir el modelo de datos, las reglas y los escenarios de aceptación en un único Markdown ejecutable . Ese archivo puede ser: Legible por negocio Procesable por una herramienta Generador de código Generador de tests automáticos Documentación viva Ejemplo: Sistema de Gestión de Pedidos 1️⃣ Modelo de Datos model: entities: - name: Cliente attributes: - { name: ClienteId, type: int, key: true } - { name: Nombre, type: string, required: true } - { name: Email, type: string } - name: Pedido attributes: - { name: P...