Desarrollando desde la trinchera.

Quienes usamos  GeneXus Server,   cada tanto nos planteamos algunas preguntas dificiles de contestar Cuales son los objetos cambiados para el requerimiento NNNNN? Todos los commits realizados por <persona nueva en el grupo> tuvieron revisión de código? Cuantos commits fueron por mejoras, cuales fueron por arreglo de errores? Cuales son los commits que están prontos para pasar de Stage a Produccion? Todas estas preguntas serian un poco mas faciles de contestar si se pudiera clasificar / agrupar los commits que se realizan. Una forma relativamente facil de hacer esto seria te tener etiquetas asociadas a los commits, que puedan ser agregadas en el momento de hacer el commit y modificadas luego del mismo. Para que puedo usar estas etiquetas? Por ejemplo podría poner etiqueta que fueran : ISSUE que va a tener los números de los incidentes. Es bueno para poder agrupar todos los Commits asociado a un mismo problema o requerimiento. STATUS , puede ser el estad...

Un amigo me preguntó porque me había dedicado desde hace algún tiempo, a trabajar en la modularización de KB, si hasta el momento nos habíamos arreglado sin módulos y podíamos hacer aplicaciones sin problemas. El conocía las dificultades del proceso de modularización y los cambios que implica introducir módulos al proceso de desarrollo, pero no veia las ventajas de tener todo bien modularizado. Mi razonamiento para tener una KB modularizada, es bastante sencillo: Es la única forma rentable que veo, con la que podremos resolver problemas mayores en el futuro, con GeneXus. Paso a explicar un poco. GeneXus es una herramienta que resuelve muy bien el desarrollo de pequeñas aplicaciones. Cuando uno trabaja con 10 tablas, es difícil encontrar algo que demore o funcione lento. Cuando trabajamos con 100 tablas, el proceso de normalizacion y reorganización puede ponerse un poco mas pesado, pero no hay nada que un build all (o en el peor de lo casos un rebuild all) soluciona ca...

El tema de modularización de bases de conocimiento me parecen uno de los mas importantes para los próximos años. El definir módulos en las KB (nuevas y existentes) es un trabajo interesante, con grandes ventajas para la evolución de los sistemas.  Para ordenar el proceso de modularizacion y poder saber cuanto me falta,  se me ocurre una escala de madurez, en el manejo de los módulos. Nivel 1 - La nada absoluta - Solo tengo el modulo Root  - Todos los objetos son públicos. Puede servir para KB de menos de 200 objetos.  Es como quedan todas las KB migradas desde versiones anteriores a Evolution 3.  Nivel 2 - Defino algunos  módulos . - Empiezo a definir algunos módulos - Algunos objetos son públicos sin necesidad.  Nivel 3 - Modularizo - Todo objeto esta en un modulo - Minimizo cantidad de objetos públicos - Hay tablas marcadas como publicas. No permito update/insert/delete a tablas fuera del modulo al...

En la charla " The future of Management" de Shoham Adizes (la recomiendo), en el GX27, explico con palabras sencillas porque se necesita el gerenciamiento (Management), para poder administrar el cambio y porque el cambio es cada vez será mas rápido. Una de las cosas que decia es que las cosas que son totalmente independientes, tienen poco cambio. Por el contrario, si se tienen muchas interdependencias, es mucho mas probable que tengamos cambios, pues cualquier cosa que cambie le va a afectar. Si estas dependencias son circulares, este ciclo se acelera aun mas. Mi mente retorcida hizo la asociación entre la percepción de cambio acelerado y los problemas que ocasiona el cambio, con  los problemas que tenemos en KB grandes. Muchas dependencias entre objetos logran que cualquier objeto que cambie, afecte a una cantidad enorme de otros objetos. En KB grandes, es común que al hacer un cambio que un piensa que es pequeño, termine afectando a muchísimos objetos. Las ...

Modularización de KB GeneXus - lecciones aprendidas de Enrique Almeida Esta es la presentación que di sobre modularizacion de KB. El tema módulos, aun no tiene la importancia que merece dentro de la comunidad GeneXus, pues solo aquellos que lidian con KB grandes valoran apropiadamente la importancia de estos objetos. Algunos integrantes de la comunidad, me preguntaron si podían ver la charla, pero me toco darla en una sala chica que  no se pudo ver online. Cuando quede subida aviso. Durante el "Cara a Cara con el grupo de desarrollo", varios participantes hicieron notar que se trató poco el tema módulos durante todo el evento, lo cual es cierto y es una pena. En particular una de los pedidos/preguntas era el de tener seguridad en la KB para poder desarrollar, para poder dividir el desarrollo en diferentes grupos de trabajo. Creo que la pregunta o el reclamo no se entendió mucho, pues fue contestada diciendo que cuando se puedan distribuir módulos como binario...

En el año 2003 (hace ya 14 años!!) empecé este blog con un artículo sobre una herramienta que llamé GXUnit.  Durante varios años hice un esfuerzo junto con otros compañeros de la comunidad de sacar el producto adelante, para que sirviera para lograr usar el testeo unitario dentro del ciclo de desarrollo con GeneXus.  Este año en el #GX27 , nace un interés renovado en GXUnit, pues poco a poco la comunidad GeneXus descubre que la metodología TDD o de Integración Continua (CI) o de Instalación Continua (CD) . Es muy bueno que podamos contar de una vez por todas con lo necesario para poder hacer testeo unitario de calidad y sin demasiado esfuerzo.  Hay varias charlas relativas a DevOps, integración continua y aledaños que recomiendo fervientemente.  Fundamentalmente Lali Aguiar , y Abstracta están haciendo un excelente trabajo para mantener y mejorar la herramienta.  Una de las cosas que le esta faltan al GXUnit para lograr ser realmente un te...

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

Desde hace unos meses, bajo el convenio de cooperación entre las aduanas uruguaya y colombiana,  esta funcionando en la Aduana de Colombia el modulo de análisis de riesgo en las operaciones aduaneras del aeropuerto El Dorado en Colombia. Como parte de la  segunda etapa de implantación, ayer paso a  funcionar para todas las operaciones de la Aduana de Bogotá. El sistema  permite a los funcionarios de la sección de análisis de riesgo, definir reglas complejas en un lenguaje sencillo, para elegir cuales son las operaciones a verificar (física o documentalmetne). Esta desarrollado en GeneXus , con interfaz web generando java y ejecuta sobre JBoss / Oracle.

Hace unos 7 años, publiqué un artículo donde proponía algunas mejoras para la propiedad Commit on Exit, pues es una de las cosas que resulta mas difícil de explicar a quienes recién comienzan a programar con GeneXus. Estamos en proceso de BetaTesting de la GeneXus Tero y seria bueno revisar el uso que le damos esta propiedad. Que cosas resultan confusas? Es difícil de explicar a un novato, que si un procedure que tiene Commit on exit = YES, no hace commit. Solo lo hace, cuando se hace un UPDATE/DELETE/INSERT en la base de datos y tiene la propiedad en YES. En cualquier otro caso, no hace commit. La documentacion del wiki si bien lo dice, es confusa. Es difícil de encontrar, cuales son los objetos que hace commit en un árbol de llamadas. La búsqueda por propiedades nunca funciono del todo bien, y de esta forma, es bien difícil encontrar donde se esta  rompiendo la integridad transaccional. En los BC, no se toma en cuenta la propiedad, lo cual hace mas confuso aun la c...

Cuando tengo un sistema desarrollado, tengo muchísimas formas de dividirlo en módulos. Segun la bibliografia, el problema mas general de particionar un grafo en diferentes agrupamientos de nodos (clusters) es considerado NP-Completo, por lo que no se ha encontrado aun una forma eficiente de resolverlo. Al tener tantas opciones, es bueno contar con alguna herramienta que me permita medir que tan buena o mal es dicha division, en el caso de una KB, seria medir que tan buena o mala es la modularizacion que he realizado. Algunas de las características perseguidas por la modularizacion, son la de tener un gran cohesion entre los nodos que están dentro de un modulo y tener poco acoplamiento con otros módulos. Esto se traduce, a que queremos maximizar las  aristas dentro de los módulos y minimizar las aristas entre los módulos. Resulta mas facil, verlo en imagenes. Supongamos que tenemos un grafo que representa la relaciones entre objetos. Los objetos pueden ser cualquier objeto e...

Una aplicación WEB C# en GeneXus 15 que usa el Abstract Editor (que viene migrada de versiones bastante anteriores de GeneXus), empezó a mostrar en algunos filtros, un fondo celeste. El motivo de esto, es porque la variable tenia la propiedad BackColor=Transparent, que en versiones anteriores de Chrome se tomaban como transparentes, pero en la version 62 que aun esta en Beta, la toma con ese color. Viendo el HTML, vimos que estaba generando donde el color (#00FFFF) tiene un FF al final que indica que es transparente. Por motivos que desconozco, esta version de Chrome no le da bolilla al alpha y pinta de celeste algunas variables. Esta propiedad, no esta alcanzable desde la interfaz de GeneXus con el editor abstracto (o al menos no lo encontramos), se ve que se guarda en forma interna, y debe venir de versiones anteriores de GeneXus. Para solucionarlo, lo que hicimos fue hacer un distribute de todas las transacciones y webpanels de la aplicacion y en el XML del export, b...

Problema:  Tengo una KB GeneXus, con una tabla con 2 millones de registros que tiene un campo AttSec N(3) y debe cambiarse a C(3) (si se quiere, puede tener otro nombre). Tabla ====== *Clave       N(10) AttSec       N(3) otros atributos El sistema esta funcionando 24x7, se instala en varios nodos (en un NLB). La aplicación deberá estar operativa siempre, no se puede bajar ni bloquear. Se pide: ¿Cuales son los pasos de desarrollo e instalación que debo seguir para lograr instalar en todos los nodos la aplicación operativa con el atributo C(3)? Solución: Si alguien se anima, la escribe en los comentarios. Yo publico la mia en unos dias. UPDATE = 04/07/2017=============================== MI SOLUCIÓN:  Lo primero que haría seria ver si la tabla es usada solo por mi aplicación o también es accedida por alguna aplicación externa. Para simplificar, supongamos que solo es accedida por la aplicación GeneXus. Estado Inicia...

En las últimas semanas, trabajé en la modularización de una KB grande, un proyecto que aun no finalizó. Esto me llevo a reflexionar un poco sobre el estado actual de los módulos en GeneXus. Mis reflexiones están basadas en la experiencia de trabajo de modularizacion algunas KB chicas en GeneXus 15 y una KB grande en Evolution 3. Faltarian varias mas para sacar conclusiones mas generales, pero creo que el intercambio de ideas de como se usan los módulos es necesario. Para que sirven los módulos?  Uno de los problemas que tienen los módulos, es que sirven para mucha cosas diferentes, lo cual ha hecho que se pierda un poco el foco hacia donde hay que seguir desarrollándolos. Pueden servir para * Entender mejor la KB * Ayudar en el mantenimiento de la KB * Distribuir el desarrollo entre varios integrantes o grupos * Hacer mas fácil el Deploy de la aplicación * Unir mas de una KB * Distribución de binarios e interfaces. * Hacer mas rapido el proceso de desarrollo y ...

Problema: Tengo una KB con mas de 10.000 objetos y se debe organizar en módulos mas pequeños. Se necesita: Metodología que permita realizar dicha modularización, de forma de mantener el funcionamiento del sistema generado a partir de la KB. Metodología propuesta.  Bajar una KB desde GXServer. Hacer un build all exitoso (es importante pues se agregan referencias a tablas) Mientras queden objetos de la aplicación sin módulo hacer: Elección que modulo se va a  crear  y cuales seran sus tablas.  Sacar una lista de URL de todos los objetos de la KB Crear Modulo y poner Visibility como Private.  Mover los Folders correspondientes al Modulo.  Identificar todas las transacciones que generan las tablas del modulo y moverlas al modulo.  Sacar del modulo los objetos que no correspondan  Marcar como públicos los objetos interfaz del modulo. (Todos los dames se mantendrán privados por default) Revisar los objetos externos al modulo que ...

Después de probar varias formas de modularizar, la que mas me convence es hacerla orientada a los datos o las tablas del modulo. Mi definición de modulo, seria: Conjunto de tablas, todos los objetos que hacen UPDATE/INSERT/DELETE sobre las mismas y casi-todos los objetos que hagan referencia a dichas tablas. Las excepciones, son objetos que hacen referencias a tablas de un modulo, sin pertenecer al mismo son: * Transacciones con integridad referencial sobre las tablas del modulo. * Join entre tablas de diferentes módulos En un diagrama: GeneXus ya controla que no se puedan acceder a objetos privados (tablas u otros objetos) y da errores al especificar. Estos son los que estan a la izquierda. Para todos los objetos publicos (no tablas) esto tambien esta bien manejado.  El problema para soportar nuestra forma de trabajo, viene con las tablas publicas.  Una tabla, no tiene modulo, ni es publica o privada en forma directa (lo cual creo que es una gran ...

El 15 y 16 de mayo en la Torre de Antel, se realiza el principal evento sobre pruebas de aplicaciones de la región. Hay charlas muy interesantes y refuerza la importancia que esta teniendo el Testing en el desarrollo de aplicaciones. Es gratuito y es muy recomendable. Mas informacion en  http://testinguy.org

En el año 2006, junto con Federico Dominioni implementamos el pattern SummarizedBy para GeneXus 9.0. Estuvo esperando todos estos años para ser implementado y parece que 11 años despues le llegó su momento. La idea es poder integrarlo con el WorkWith de forma fácil. El objetivo del mismo es mostrar los datos de eventos agrupados por diferentes dimensiones, mostrando indicadores. Por ejemplo, ver el total vendido (indicador), por producto,empresa,pais (dimensiones). Veremos como sigue la historia.

Me ha pasado muchas veces en diferentes proyectos, que necesito copiar datos entre bases de datos que tienen estructura de tablas parecidas. Por ejemplo, hago varias reorganizaciones en mi modelo de datos y quiero tener datos de producción para hacer pruebas, no es trivial hacerlo si se tienen diferentes estructuras. Le agregué una opción al generador de scripts en el KBDoctor, para que genere un script que tiene sentencias de la forma insert into <SourceDB>.<TargetSchema>.HrsCab (HrsFch,RspId,SeLiquida,CabezalPryId,EnExterior )      select HrsFch,RspId,SeLiquida,CabezalPryId,EnExterior from  <TargetDB>.<TargetSchema>.HrsCab; para todas las tablas del sistema. Para que quede un script operativo, hay que sustituir <SourceDB> por la base de datos origen,  <SourceSchema> por el Schema origen y lo mismo pora <TargetDB> y <TargetSchema> Entonces, para generarme una base de datos con los datos de produ...

En mi post sobre Paletas de colores en GeneXus , pedía que las KB de ejemplo tuvieran ya definidos varias paletas de forma que fuera fácil ver la aplicación en varios esquema de colores. En particular, pedía una versión de GXWiki con eso. Claudia Murialdo me hizo notar (gracias!) que la versión 6.0 ya tiene varias paletas de colores. Es una buena KB para sacar ejemplos de como hacer estas cosas.

Estoy buscando intersados que quieran participar en un proyecto colaborativo con GeneXus. El objetivo primario del proyecto, seria crear una versión de GXWiki que permitiera funcionar instalándolo en varios nodos sin tener que configurar la afinidad por servidores . El segundo objetivo es documentar que cosas impiden el tener aplicaciones GeneXus que funcionen sin afinidad, y para cada una de ellas proponer soluciones. Que es "Server Affinity" y por que no es bueno tenerlo? Tener una aplicación configurada con "Server affinity" significa que luego que un servidor atiende un pedido (request) de la aplicación, todos los pedidos sucesivos de dicho cliente, van a ser atendidos por el mismo servidor. Para aplicaciones de pocos usuarios y pocos nodos, esto generalmente no es un problema, pero si lo es para aplicaciones de muchos usuarios y/o proyectos que varios servidores en la nube. Que inconvenientes tiene configurar el "Server Affinity"? Como l...

En las últimas versiones de GeneXus tienen la posibilidad de tener diferentes paletas de colores para las aplicaciones. Lamentablemente me parece que los ejemplos que brinda GeneXus y otros proveedores de ejemplos (patrones y demás) no están aprovechando todo el potencial de estas herramientas. Muchas personas usan esos ejemplos con pocas modificaciones para generar sus aplicaciones, por lo que es importante que estos ejemplos brinden las "mejores practicas" desde el principio. Para personas como yo, con "capacidades estéticas diferentes" , seria bueno tener contar con algo que permita cambiar el esquema de colores en forma mas fácil. Que cosas no me gustan? Nombre de los temas Por ejemplo, el tema que viene con GeneXus 15 se llama Carmine (que es un color) lo cual indica que ese Theme seria para tener ese color. A mi me gustaría que el theme se llame algo asi como ModernResponsive y tener varias paletas de colores asociadas. Carmine es un buen nombre...

Llega la cita esperada El  Sábado 18 de marzo a las 11:30  en Puerto Madero  (Luis A. de Herrera 1172 casi 26 de marzo) Inscripciones  en:  Meetup.com Ticket $ 490 Formas de pago REDPAGOS:   Cta.   46855 “GUG Montevideo”  Depósito en BROU ,  ITAU, SANTANDER  (solicitar nros de cuenta a gugmontevideo@gmail.com) Presentaremos el  Plan de Trabajo del GUG   para el 2017  y algunas sorpresas! No te dejes estar, los cupos son limitados.