Desarrollando desde la trinchera.

Necesitaba hacer una expresión regular que me permitiera cambiar de las sintaxis Call(Objeto,&ParametroIN, ......, &ParametroOUT) a &ParametroOUT = Objeto.udp(&ParametroIN,......) La expresión regular mas sencilla que encontré (con la invalorable ayuda de Nicolás) , que funciona bien en los casos que los probé es: (\s+)?(call\(({0})([\s\b]*)(,(.*)(,[\s\b]*)(&([a-z0-9\-]+))|,(.*)(&([a-z0-9\-]+)))[\s\b]*\)|(({0})(.call) ?\(((.*)(,[\s\b]*)(&([a-z0-9\-]+))|(.*)(&([a-z0-9\-] +)))[\s\b]*\))) donde debo remplazar {0} por el nombre del objeto. Luego debe remplazar en el código con la expresión super amigable: $1$8$11$19$22 = $3$14.udp($6$17) La potencia de las expresiones regulares es asombrosa, pero también es asombroso lo complejas que pueden quedar con casos bastantes sencillos. PD: La próxima version de KBDoctor, tendrá una opción que identifica los programas que tienen todos los parámetros IN, menos el ultimo OUT y cambia todas las inv...

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

Estuvimos haciendo charlas internas sobre como hacer mas fácil de entender el código GeneXus que escribimos. Algunas cosas básicas que vimos: Nomenclatura de objetos y variables Descripción, Column Title, Contextual title, etc en atributos.  Descripción de Tablas y Grupos de Subtipos (esto lo ven los usuarios) call(Objeto) vs Objeto.call() vs Objeto() Parámetros con IN y OUT Todos los atributos con Dominios (con significado semántico igual) Todas las variables basadas en  atributos o dominios Dominios Enumerados (para evitar constantes en el código) Bloques de código cortos (no mas de 200 lineas) Anidación de sentencias (no mas de 5 niveles de IF/Do/For Each, etc) Comentarios innecesarios (no dejar código viejo comentado).  Palabras claves en MAYUSCULA o minúsculas Indentación de for each / where Orden de los Eventos Si bien para algunos temas no hay demasiada discusión para algunos si hay varias posiciones diferenes.  Por ejemplo, en el ca...

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

En los últimos años, hemos visto el avance de varias herramientas para el desarrollo de software, donde se automatizan algunas de las tareas de la creación de sistemas y de software en particular.  Si pensamos dentro de la comunidad GeneXus tenemos GeneXus que escribe código C# o Java, desde especificaciones Patterns que escriben código GeneXus GXTest y GXUnit que prueban programas SecurityScan que detecta problemas de seguridad en KB GeneXus Herramientas de Build y Deploy para el armado y la instalación de aplicaciones KBDoctor ayuda a borrar objetos que no se usan mas LSIExtension ayudan desarrollar con GeneXus CleanVariables borra variables no usadas en objetos TotalValidator controla problemas de usabilidad de la aplicación generada GeneXus Server hace parte de la tarea de consolidación   Herramientas de integración contínua (CruiseControl), nos ayudan a tener una versión instalable en todo momento Pruebas de performance/carga se hacen con Jmeter y her...

Subí al marketplace una nueva versión de la extensión KBSaveReorganization Esta extensión permite almacenar un script de la reorg en al KB, como un objeto del tipo File. Esta versión, tiene ademas la nuevas funcionalidades: Se salvan los programas pare ejecutar la reorg GeneXus en .NET en un directorio Se crean scripts CMD para ejecutar la reorg forzada, otro en forma batch y otro para contar la cantidad de registros de las tablas a reorganizar. Es compatible con Evolution 3.  Ademas de funcionar en el IDE, funciona cuando se reorganiza con MSBUILD task.  Si alguien la baja y la prueba, me agradaría mucho conocer sus opiniones.

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