Desarrollando desde la trinchera.

Dentro de las funcionalidades nuevas de KBDoctor esta la de poder hacer revisión de código automatizado, y poder ejecutar dicha tarea como una tarea MSBUILD. Nosotros lo usamos para poder revisar los cambios subidos al GXServer, en la KB que arma los build, para revisar los objetos subidos. Todas las noches se pueden revisar todos los objetos  que tenga un timestamp (modificados o subidos) del dia anterior o el actual. set KBPath=C:\Models\GX16\KBPrueba MSBuild.exe KBDoctorCmd.msbuild   /t:ReviewObjects  Si se quiere revisar desde una fecha determinada, se puede agregar el parametro /p:DateFrom=01-01-2018  En el proyecto KBDoctorCmd.msbuild (que se instala con KBdoctor) se tiene   <Target  Name="ReviewObjects">     <Message Text="Using GeneXus DIR = $(GX_PROGRAM_DIR)" />      <Message Text="KB DIR = $(KBPath)" />      <OpenKnowledgeBase Directory="$(KBPath)" />  ...

En el post anterior, comentaba la importancia de usar dominios con significado, para facilitar la propagación de cambios desde el modelo de datos a los programas. Otra ventaja de tener bien definidos los dominios, es el de poder agrupar todas las cosas que son de la misma categoría, facilitando la identificación de los objetos que tengo que cambiar. Por otro lado, al tener tanto variables como atributos con dominios, podemos hacer validaciones mas estrictas de lo que hoy permite Genexus. Supongamos que tenemos los atributos (*) MovimientoPeso - Domino PesoKG N(10,2) CamionPeso - Dominio PesoToneladas N(10,2) Si en un programa tenemos una operacion que haga una asignacion de MovimientoPeso = CamionPeso + &Carga muy posiblemente estemos introduciendo un error, al sumar pesos en diferentes unidades, aunque los ambos sean numéricos. Lo mismo sucede si pasamos de variables que tienen mas decimales a otra que tenga menos decimales, podemos estar perdiendo precisión c...

Hace unos dias, me preguntaron el motivo por el cual KBDoctor chequeaba que los todos los atributos estuvieran basados en dominios y también sugiere que todas las variables estén basadas en atributos (o dominios) El motivo es bastante sencillo, para hacer que la KB sea mas fácil de mantener en el futuro.  Pongo un ejemplo bien sencillo, con el cual, puede quedar un poco mas claro. Tengo tres atributos, que son N(8) y guardo en ellos números telefónicos.  Ninguno de estos atributos tiene dominio. Luego tengo 4 programas que usan estos atributos y tienen variables que tambien contienen numeros telefonicos, tambien definidas como N(8). Por el aumento de la cantidad de teléfonos, las compañías telefónicas se ponen de acuerdo y deciden pasar sus números de 8 a 10 dígitos.  Para adaptar mi aplicacion, tengo que cambiar, 3 atributos, mas 4 programas los cuales tengo que detectar  y cambiar manualmente. Estas tareas (sobre todo la de encontrar donde s...

Estamos programando una opción en KBDoctor, que va a hacer un Object Review, de forma de hacer una analisis y revision del objeto y detectar posibles errores, antes de subir dicho objeto a GXServer. La idea es que aparezca en el dialogo del Commit, permitiendo revisar todos los objetos que van a ser subidos al server. Es una herramienta que ayuda a realizar una revision del objeto, para liberar al revisor de los controles rutinarios y que pueden automatizarse. Ademas unifica algunos criterios en todo el grupo de desarrollo, de forma de hacer mas predecible como seran los objetos. Que hace el Object Review? Hace algo mas que un review, pues por ejemplo, borra todas las variables no usadas y si el objeto es una transaccion y no esta siendo referenciada por nadie, le borra las reglas, los eventos, le saca la masterpage y vuelve los forms a default. Tambien avisa cuando: Hay parametros tenga IN/OUT/INOUT Tiene mas de N1 parametros Tiene mas de un parametro de salida Tiene...

Agregué algunas opciones al KBDoctor para poder manejar la modularización de KB. List Modules Errors.  Cuando hacemos cambios en la visibility de los objetos y/o cambiamos los objetos de modulos, no detecta automáticamente los cambios.  Al menos en Evo3, hay que hacer un rebuild para poder detectar los errores y eso demora muchisimo. Este reporte lo que lista son los objetos (tablas y programas) privados que estan siendo accedido desde afuera del modulo. Tambien las tablas publicas que son actualizadas fuera del modulo. Esto no es un error para Genexus, pero es algo que es bueno evitar. Por ultimo, tiene una lista de los objetos que seria bueno mover para el modulo, pues solo usa tablas y objetos de este modulo. List Tables in modules.  Permite lista un conjunto de tablas, y muestra si son privadas o publicas, en modulo esta y cuales son las transacciones que la generan. Tambien muestra la transaccion que GeneXus eligio para definir el modulo de la tabla. Toda ...

Soy promotor de la modularización de KB Genexus, pues ayuda en muchos aspectos mejorar  la salud de la KB y de la aplicación. Al tener la KB modularizada, se puede entender mas rapido, y por lo tanto, se pueden hacer cambios mas agiles y con menos riesgos. Algunos de los patrones de problemas comunes que aparecen en KB que he estado modularizando son: Tengo un objeto que recorre una tabla privada de otro modulo y ejecuta código utilizando objetos del modulo B, por ejemplo actualizando o haciendo inserts. En este caso, conviene sacar la logia del Object1 y crear un nuevo objeto en el ModuleB De esta forma el ModuloB pasa a tener un nuevo servicio que puede ser usado por otros modulos y la tabla queda como privada. Caso 2: Se intenta recorrer una tabla privada de otro modulo, y luego se ejecuta logica propia del modulo en el que estoy.  Una posible solución es hacer un Data Provider que devuelva los datos de la tabla privada y utilizar los elementos d...

Subi al Marketplace una versión nueva del KBDoctor con varios cambios y arreglos. Algunas de las novedades son : Generar SQL scripts para validar la estructura de la base de datos con lo esperado en la KB, validar datos de integridad referencial, cambiar valores nulos, etc.  Sustituir un dominio por otro Listar dominios Listar atributos Listar modulos y tablas por modulos  Utilitario para acortar el nombre de atributos y objetos a su largo significativo de nombre Mejorado de codigo (cambia codigo, saca calls, udp.   varios etc.  Los compilé para Evolution 3 Upgrade 9 y GeneXus 15.   Dejo este link por si alguien quiere bajarla, antes que se soluciones unos inconvenientes que hay con el marketplace. 

Estamos realizando una migración de version de GeneXus, a la última liberada. Algunas de las tareas involucradas fueron las siguientes Comparación de Navegaciones.  Use el KBDoctor para comparar las navegaciones de la Evolution 2 con la Evolution 3. Unos cuantos objetos cambiaron su navegación, pues ahora cambia el ORDER de algunas sentencias. En general, el criterio que vi es que toma en cuenta las condiciones del WHERE para considerar el orden. Parece mejor en casi todos los casos, pero igual hay que chequear contra la base de datos para ver si alguna sentencia que estaba optimizada no tiene problemas de performance. Comparación de WSDL de servicios publicados.  Tuvimos diferencias en algunos pocos WSDL publicado, pero era por habíamos dejado el Namespace de la KB en su valor por default y como la KB toma el nombre de la KB como Namespace, al cambiar de KB cambiaba la definición del WSDL. Detectamos el problema y lo solucionamos rapido. Objetos con  c...

Hace unas semanas, estaba con gripe en casa. Estaba aburrido y me puse a ver que podía mejorar una KB Genexus. Para esto, me puse a probar una opción de KBDoctor que permite identificar cuales son los objetos que tienen problemas y arreglar los mas comunes. Los tipos de problemas que soluciona son: variables que no están basadas en dominios / atributos parámetros que no tienen indicador de in/out atributos que no tienen dominios  Estos arreglos son semiautomáticos, donde KBDoctor cambia el fuente en forma automática, pero  luego tiene que verificarse en forma manual, pues el cambio no siempre es el correcto, porque se usan heuristicas que no siempre hacen lo correcto.  Primero probé estos  con una KB chica y bien conocida y todo funcionó bien.  Con el viento en la camiseta y pensando que nada podía salir mal, hice una corrida en una KB grande que están en desarrollo desde el año 1998, que tiene código viejo.  Tal vez por la gripe y la f...

Una empresa amiga me mando una KB, para que diagnosticara algunos problemas de performance bastante serios que estaban teniendo, en el proceso de build de la misma. Es una KB recién migrada desde GeneXus 9.0 a GeneXus Evolution 3 U8. Me mandaron el MDF (archivo de la base de datos SQL Server) de la KB ya convertida por ellos y con eso me puse a trabajar. Esta KB me dio la oportunidad de practicar una limpieza a fondo de la misma, en código escrito por otros, que me permite probar el KBDoctor en un entorno diferente al que tenemos en Concepto. Al empezar la KB tenia: 13.872 objetos. 10.662 atributos y 674 tablas. Con esos datos iniciales, me puse a trabajar. Revisar propiedades. Lo primero que hago cuando trabajo con KB grandes, es revisar algunas propiedades de las mismas. En este caso lo que hice fue: Deshabilitar el Indexado dentro de la KB (esto enlentence mucho cada vez que se salva un objeto) Poner el Generate Developer Menu en *NO No generar prompts.  ...

En el post Codigo GeneXus mas entendible , contaba algunas técnicas muy sencillas para hacer que los programas GeneXus sean mas fáciles de entender y por lo tanto de modificar y mantener. También había comentado en otro post que cada vez mas usamos mas programas para generar programas o para hacer tareas propias del desarrollo de sistemas. Para seguir con esta tendencia, hice algunos programas para cambiar programas para que los mismos sean mas entendibles. Los cambios que por ahora esta haciendo son: cambio de palabras clave ( for each , where , do , case , endif , if , etc) para pasarlas a minúsculas pasar Call(Objeto) a sintaxis objeto.call() o objeto() detectar variables no basadas en atributos y dominios Las dos primeras se pueden hacer sin pedir ayuda al desarrollador, pero la tercera, no es fácil de automatizar. Lo que si se puede hacer, es aprender de las decisiones del usuario, o sea, si en un objeto tengo una variable que se llama FilePath y es Char(100...

Agregué al KBDoctor un reporte que mide la complejidad de los objetos GeneXus de una KB. No es fácil definir que objeto es complejo y cual es simple, por lo que definí un KBDoctor Complexity Index , que mide algunas de las cosas que me interesa simplificar. El mismo esta definido de la forma KBDoctor Complexity Index = +100 por tener algún parametro sin IN: OUT: INOUT +(MaximoNivelAnidacion * MaximoNivelAnidacion) + NumeroCiclomatico * 10 // Cuenta IF, Do While, For, Do Case + MaximoBloqueCodigo * 2 El indice intenta, que todos los objetos tengan reglas parm con IN y OUT, tener un nivel de anidacion bajo, bloques de codigo chico y un numero ciclomatico tambien chico. En nuestros sistemas, si un objeto tiene un índice mayor que 500 es considerado muy complejo y debe cambiarse. Estuve evaluando otros criterios para medir la complejidad como  Cantidad de Rules Cantidad de tablas accedidas Cantidad de atributos accedidos pero preferí una primer versión ...

Estaba buscando una forma fácil de poder ejecutar en producción una validación de la estructura de la base de datos, para asegurarme que las tablas existen y que tienen todos los atributos de la versión que voy a instalar. Parece un problema menor o de fácil solución, pero en algunas instalaciones, las reorganización de las tablas no dependen de nosotros o hay mas personas que pueden cambiar la estructura de la base de datos, por lo que tener una forma de chequear que el programa se va a encontrar la base de datos esperada viene muy bien. Le agregué una opción al KBDoctor que genera varios scripts SQL para hacer algunas validaciones. La mas simple, recorre todas las tablas de la aplicación y todos los atributos de dicha tabla y genera un script del tipo: select attClave1, attClave2, attSec1, attSec2, attSec3 from Tabla where 1=0 No se tienen en cuenta los atributos formulas no redundantes e inferidos. De esta forma, si dicho script corre sin errores, existen grandes po...

Por la forma en que desarrollamos GeneXus, basados en conocimiento y no en la tecnología de moda, es común que tengamos algunas KB que fueron desarrolladas años atras, que aun sigan funcionando sin problemas. Esto es una ventaja enorme, pero también nos trae el problema de como hacer para que dicho codigo utilice las nuevas funcionalidades, para facilitar su mantenimiento.  Pongo un ejemplo concreto: Parametros con IN:, OUT: e INOUT:  En versiones viejas de GeneXus, todos los parámetros eran de entrada/salida. En versiones mas recientes, se puede especificar si los parámetros son de entrada o de salida, por lo que se evitan problemas de modificar un parámetro sin querer y queda mas claro que es lo que hace el objeto al tener especificado cuales parámetros son de entrada y cuales de salida.  Ademas el código generado, es mas compacto, se usa menos memoria, etc.  Teniendo tantas ventajas, es deseable poder cambiar todo el código viejo y obligar que ...

Una de las funcionalidades mas promisorias de GeneXus X Evo3, es la posibilidad modularizar la KB. Las ventajas son muchas, pero tener una KB bien modularizada, ayuda a entenderla, facilita mucho el mantenimiento y ayuda a instalar la aplicación. Que es modularizar? Dividir la KB en módulos (o grupos de objetos) de tal forma que sea mas fácil de entender, cambiar y manejar. Porque modularizar? Partiendo el problema y permitiendo resolverlo incrementalmente.  Permite distribuir las tareas de desarrollo entre diferentes personas/equipos. Definir interfaces claras entre dominios, facilita también la reutilización de un módulo en otro contexto del original.  Dependencias.  Decimos que un módulo depende de otro, o usa otro módulo, cuando llama o utiliza un objeto publico de otro módulo.  Por ejemplo, si tengo un módulo A que tiene los objetos que hacen el manejo de parámetros de la aplicación y otro módulo B necesita recuperar el valor de un pará...

En varias oportunidades me encontré con las  necesidad de generar transacción 'limpias' con las misma estructura que las tablas. Por ejemplo, hace unos días, me dieron una KB que estaba en GX 7.5 que tenia una transccion con 8 NIVELES!! y al intentar migrarla a Evo3 daba errores. Para estos casos, lo que hago es generar transacciones con la misma estructura que la tabla, sin ninguna regla y con la propiedad de GenerateObject=NO, para que no molesten y luego me dedico a cambiar la transacción en cuestión o a borrarla si se puede. Otro escenario de uso, es cuando se tiene una KB desarrollada con versiones anterior a la cual le quiero aplicar el pattern WorkWith y me sirve empezar con transacciones sencillas Para eso, agregue una opción en KBDoctor , que permite seleccionar un conjunto de tablas, y genera una transacción por cada una de ellas, respetando los atributos, la descripción, la clave, etc de las mismas. Otro caso, es cuando se tiene una transacción que tiene ...

En la versión 10.10 del KBDoctor (para Evo3 U3 ** o superior y para Evo2 U4 o superior) hay algunos arreglos de errores o cosas que funcionaban mal y algunos reportes nuevos. Lo dejé documentados en la pagina del Wiki de la comunidad : KBDoctor 10.10 (Nuevas Funcionalidades) ** No funciona para la Evo3 Upgrade 1 y 2, porque hay cambios en el GeneXus Platform SDK y tengo que recompilarlo con esas versiones viejas y aun no lo hice.

Entre las evaluaciones de KBDoctor, me llegó una de  Marco Tigselema   (gracias por las cinco estrellas!!!) que pedía poder ver los objetos no referenciados antes de borrarlos. Como el marketplace no permite responder a las evaluaciones, lo hago por el blog. Saqué hace un tiempo la posibilidad de ver cuales son los objetos no referenciados, porque esa funcionalidad ya fue agregada por Artech en GeneXus hace un tiempo. Si se hace View / Knowledge Base Information / Not Referenced Objects También se pueden ver los objetos menos referenciados y los mas referenciados.

GeneXus provee varias funcionalidades de comparación entre objetos. Se puede comparar diferentes revisiones del mismo objeto, el mismo objeto en dos versiones dentro de la misma KB y también se puede comparar un objeto que voy a importar con el objeto que tengo en la KB. Sin embargo, hay varios casos de uso que no se pueden resolver aun con estas herramientas, por ejemplo: * Un modulo común, instalado en dos KB diferentes y quiero comparar las diferencias entre los módulos.  * KB en dos versiones de GeneXus diferentes (por ej, Evo2 y Evo3) * Comparar versiones, en KB grande, donde el comparador entre versiones de GeneXus demora tanto que se hace muy poco practico.  Para esto, programé una nueva opción en el KBDoctor (version 11, que aun no publiqué) que permite seleccionar un conjunto de objetos y generar un archivo de texto con el contenido de cada uno de dichos objetos. Luego utilizo un comparador de archivos, para ver cuales son las diferencias. Traté de ...

Subí al marketplace de GeneXus una versión del KBDoctor (10.9.1) compatible con Evolution 3 (también con Evolution 2).  El marketplace tiene un proceso de aprobación que se demora algunos días.. Empece hace poco a trabajar un poco mas en serio con Evolution 3 y por me hice de un tiempito para hacer los cambios necesarios para que compile y funcione mas o menos bien. Esta version tiene lo mismo que la version anterior, y le agregue un par de reportes nuevos * Objetos que se generan WIN y WEB (cuando se tiene mas de un generador) * Procedures que llaman a Transacciones y Webpanels (para detectar posibles problems de diseño) * Objetos Complejos (que tienen archivos de especificacion grandes) * Un link al help en el wiki Ya estoy necesitando algunos reportes nuevos para poder solucionar problemas con los Modulos y se lo voy a estar agregando en las próximas semanas. Lo que ya tengo medio hecho es el fijar todos los objetos de un modulo como privado a menos que sea llamado ...