Desarrollando desde la trinchera

Desde hace un buen tiempo, estoy participando en un proyecto de migración de una KB grande desde GeneXus Evo3 a GeneXus 16 Upgrade4. En el proceso, hemos tenido que asegurarnos que la ejecución del sistema nuevo, es compatible con el sistema anterior. Como es un sistema bastante grande, hemos tratado de automatizar lo que podemos para hacer el chequeo mas eficiente y encontrar mas rapido las diferencias. Algunas de las cosas que comparamos son: * WSDL de los servicios SOAP del sistema * Respuesta de los servicios SOAP (cuando lo llamamos con parámetros) * Respuesta de los servicios REST * Salida de los procesos batch * Ejecución de pantallas WEB Para lograrlo, hemos estado utilizando algunas herramientas que pienso que pueden ser de utilidad a otros en proyectos parecidos. Estas herramientas son las que usamos para SoapUI.  Permite probar en forma fácil servicios SOAP (y también REST) pero en principio lo usamos mas para el SOAP. Como lo usamos?. Dado el WSDL...

Con el fin de practicar y encontrar la forma de como incorporar pruebas unitarias a un proyecto GeneXus, decidí hacer un proyecto colaborativo (conmigo mismo) en un proyecto público como GXwiki.  http://open.genexusserver.com/v16/knowledgebase.aspx?GXwiki6,GXWiki6 Elegi este proyecto porque es publico/abierto y tiene pocas tablas y a la vez es suficientemente sofisticado como para encontrar varios de los problemas que vamos a encontrar en casas proyectos reales. Lamentablemente no puedo crear versiones en el server, pues me gustaría poder dejarlo (en el server) asi: Por ahora, lo voy a dejar desconectado del server, y tal vez mas adelante lo suba a algun server para que otros puedan usarlo. Las tareas que voy realizando son: Aprontes y limpieza de la KB Crear KB from Server Build All Creo una versión congelada (para tener un lugar donde volver si meto la pata).  Corregir estos errores:  Processing enumerated domains... Database Creation Analysis S...

Luego de un pequeño parate (por motivos externos a nosotros) volvimos a poner en producción la aplicación generada. Ayer le tocó a los servicios web externos. No tuvimos mayores inconvenientes, tuvimos 2 cancelaciones, una fue un error 500 - Internal Server error pues teníamos: &ret= &XMLIn.ReadType(&XMLIn.ElementType, 'Imagenes_Documentos') y la variable &ret era N(1) y puede devolver hasta 128, dando un overflow. Es un error de programación que no tiene nada que ver con el cambio de versión. También nos reportaron que los WSDL tenian error, que decia This page contains the following errors: error on line 4 at column 7: Entity 'nbsp' not defined Below is a rendering of the page up to the first error. Esto se daba en la seccion:  <documentation> &nbsp; </documentation> El error no es demasiado grave, porque no afecta la operativa, pero si es bastante molesto porque nos llaman los programadores que usa...

Tiempo atrás, cuando queremos forzar que un for each leyera una tabla especifica, debíamos poner en la sentencia for each un Defined by de la forma for each    defined by <AtributoSecundario> //Está solo en la tabla que quiero recorrer. .. endfor Esto solo era necesario en algunas tablas, pero tiene varias consecuencias adversas, como que el atributo secundario figura como usado, que se agrega en la sentencia aunque no sea necesario, que si quiero borrarlo debo cambiar varios programas, etc. Creo que fue en la versión Evo3, se agregó la posibilidad de especificar la Tabla Base del for each, poniendo una lista de transacciones y en forma indirecta se especifica cual tabla debo recorrer. Para esto, la sintaxis es parecido a: for each <Transaccion.Nivel> //Nivel de transaccion que define la tabla que quiero recorrer   ... endfor Esta sintaxis tiene como contra que el objeto transacción queda referenciado y parece que lo estuviera llamando con u...

Seguimos con la instalación de servicios web. GXUi.  Esta es una biblioteca que soporta algunos user controls interesantes para el desarrollo WEB. Cuando ejecuta en GX16 algunas cosas funciona diferente (por ejemplo, no se puede hacer el Resize de columnas en grillas, no aparece el menu que permite seleccionar que columnas mostrar y cuales no). Es una biblioteca que ya esta mostrando sus años y no parece adaptarse correctamente a los nuevos desarrollos, pues por ejemplo, no es responsive. Cuando busque en el Marketplace vi que la ultima version es la que soporta GX15 U10 y no parece claro que vaya a tener soporte para la 16. Vamos a tener que buscar WA temporales para salir del paso y luego encarar una reprogramación de los programas que la usen buscando alternativas al Layout, Menu, Message, Panel , Grid, etc.  Agrandamos un poco y de forma un poco inesperada, nuestra deuda técnica. Web Services SOAP.  Algunos clientes que consumen web services SOAP reportaron e...

Supongamos que tengo un sistema ya desarrollado y encuentro que los desarrolladores que lo hicieron (siempre son otros que ya no están !!!) hace años. Por ejemplo, podemos decir que detectamos una oportunidad de mejora en una KB GeneXus desarrollada hace años, en una versión anterior de GeneXus, pues tiene algunos objetos que no especifican si los parámetros son IN, OUT o INOUT. Al no especificar nada, los parámetros quedan de entrada salida. En las versiones anteriores de GeneXus todos los parámetros eran de entrada salida, pues no se podía especificar si el parámetro era solo IN o OUT. Identificado el problema, es bueno ponerse un objetivo para corregirlo Definir Objetivo Todos los parámetros de los objetos de la KB deben especificar si son IN, OUT o InOut.  Metodologías  Una vez definido el objetivo, hay que definir cómo voy a realizar el cambio para lograr dicho objetivo. Generalmente evaluo un par de formas de conseguir los objetivos: Cambio Big bang....

Michael Feathers en su libro  “ Working Effectively with Legacy Code ” define codigo legado (legacy code) como todo  código que no tiene pruebas. Code without tests is a bad code. It doesn’t matter how well written it is; how well structured it is; how well encapsulated it is.Without tests there is no way to tell if our code is getting better or worse. Si nos guiamos por esa definición (que me gusta), puedo decir que la mayoria del codigo que tenemos es Legacy Code y que podemos mejorarlo de muchas formas. Luego de algunos años de práctica, puedo decir que en mi experiencia siempre es mejor tener las pruebas lo  mas cerca del código que sea posible. pues agregan mas valor a mi código.  Por lo tanto, creo que es válida decir que tener Pruebas Unitarias (que prueban solo un objetos procedure o data provider) agrega mas valor que una prueba de integración (que prueban módulos o integración entre módulos) y a su vez agrega mas valor que pruebas de interfaz de usuari...