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 fiebre, cuando quise acordar h

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

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 caso de las Mayúscula