Desarrollando desde la trinchera.

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 un CALL lo cual

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 errores. El p

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.  Es rea

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 usuario. Prueba Unitari