Entradas

Uniendo los puntos - Charla del Adizes con los problemas en las KB Grandes

Imagen
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 referencias circ…

Modularizacion de KB - Lecciones aprendidas - GX27

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 binarios con tablas, va…

Renovado interés en GXUnit

Imagen
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 testeo unitario, es la de poder aislar correctame…

KBDoctor - Nuevas consultas para modulos e integridad transaccional

Imagen
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 esta informacion, es ba…

Módulo de Análisis de Riesgo en Aduana de Colombia

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


COMMIT ON EXIT considered harmful

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

Creo que alg…

Métricas sobre modularización de KB

Imagen
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 ejecutable (…