Desarrollando desde la trinchera.

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. 

Una de las cosas que ayuda mas a entender código escrito por otras personas, es que las variables, los objetos y las rutinas usadas en dicho código, tengan nombres coherentes y que permitan identificar rápidamente lo que se almacena en ellas. A medida que pasa el tiempo, el significado de los diferentes objetos/variables del sistema  puede cambiar y por lo tanto conviene renombrarlo. Si lo que renombro son tablas o atributos, le cambio el nombre, se genera un programa de reorganización para cambiar la base de datos y se regeneran todos los programas en forma que empiecen a usar dichos nombres. Es renombrar objetos ejecutables (por ejemplo, procedures, transactiones, webpanels, etc) dentro de la KB, es una tarea que esta bien implementada, pues le cambio el nombre al objeto, hago un build all y se regeneran y compilan todos los objetos que se necesitan. Las rutinas dentro de un objeto, se pueden renombrar y pero hay que cambiar en forma manual los lugares que hacen referencia

Un colega me pregutó como manejábamos los procesos de migración y fundamentalmente si le cobrábamos algo adicional a los clientes en los procesos de migraciones. Cuando hablo de migración, me refiero cuando quiero cambiar la version de mi herramienta de desarrollo (en mi caso GeneXus), para una mas nueva y con mejores prestaciones, pero sin agregar funcionalidad ninguna. Es muy dificil vender estos proyectos a los clientes, pues el valor de los mismos pasan bastante desapercibidos. Funcionalmente la aplicación luego de terminar el proyecto tiene que hacer exactamente los mismo que antes, pero al regenerar toda la aplicación se agrega el riesgo de que algo funcione diferente y peor que antes. Si bien no hay una receta única para esto, en general es bueno tratar de absorber el costo de los proyectos de migración. En el futuro, se le puede cobrar a los clientes, por las nuevas funcionalidades que se van a desarrollar con las nuevas tecnologías o mejoras al sistema. Por ejemplo al

Esta es una funcionalidad que me gustaría tener en GXServer.  Tengo una KB, con objetos, con  base de datos con datos y un build all terminado en mi version de trabajo y es la misma desde la que instalo y esta en producción.  Quiero hacer un cambio grande con reorganización que puede llevar un tiempo largo (mas de una semana)  y me gustaría poder trabajar tranquilo sin afectar mi capacidad de instalar desde la version original.  Me gustaría poder contar con una opción que haga estos pasos en uno solo Cree una version congelada Cree una version derivada de la congelada Copie la estructura de archivos de la version original a la nueva (TargetPath, subdirectorios y archivos de especificación) Deje todos los objetos como especificados (igual que la version original) (Paso opcional) Cree la estructura de la base de datos nueva con la misma estructura de la version original (Paso opcional) Copie los datos de la base de datos de la version original a la base de da