DevelUY

Planeta de desarrolladores uruguayos

7 de octubre de 2017

Enrique Almeida

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 a ser posible hacer eso.

Esto es cierto, pero me parece que el escenario al  que apuntaba el usuario, era que quería tener UNA KB modularizada y poder darle a una empresa externa el desarrollo de un modulo y no pudieran acceder a otro modulo que ese, a través de módulos. Seria util también para restringir a los integrantes mas nuevos del grupo de desarrollo para que no puedan acceder a las partes mas criticas del sistema, para que no puedan introducir errores sin querer.



por noreply@blogger.com (Enrique Almeida), el 7 de octubre de 2017 a las 00:06

6 de octubre de 2017

Enrique Almeida

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

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 circulares, también logran empeorar esto mucho mas. Es solo un pensamiento que ayuda a entender la sensación que los problemas en las KB grandes no son lineales con la cantidad de objetos. Y también que hay que trabajar en forma activa, para bajar las dependencias circulares y minimizar las dependencias.


por noreply@blogger.com (Enrique Almeida), el 6 de octubre de 2017 a las 19:19

28 de septiembre de 2017

Enrique Almeida

Renovado interés en GXUnit

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 correctamente al objeto de su entorno, fundamentalmente de las tablas de la base de datos y de las llamadas a otros objetos.  Seria hacer el un "objeto simulado" (en ingles mock) de dichos objetos. 

Supongamos que tenemos que testear un procedure, que lo que hace es un for each que genera una sentencia "Select att1, att2 from table1 where att1 > 10".  Seria bueno contar con un mecanismo que me permita obtener siempre un conjunto de datos, sin tener que ir a la base de datos.

En los lenguajes orientados a objetos, es mas fácil hacer el mock del objeto que devuelve esos datos, para que devuelva algo conocido, sin tener que ir a la base de datos. 

En GeneXus, creo que se podría utilizar la propiedad Database access caching  para poder hacer que el objeto que estoy probando no  tenga que acceder a la base de datos y pueda ejecutar el test unitario en forma rápida. 

La idea primaria, seria poder ejecutar una vez la prueba con acceso a la base y capturar en el cache todas las sentencias ejecutadas y sus resultados. 

Luego seria bueno poder capturar el estado del cache y salvarlo (esto no se puede hacer hoy en día), de forma de poder volver a cargarlo en el futuro. 

Cada vez que voy a ejecutar un test unitario, podría restaurar el cache en el estado que lo necesita dicha prueba, y eso aceleraría muchísimo su ejecución, y aislaría el test de la base de datos, siempre y cuando la sentencia no cambie y se ejecute con los mismos parámetros. 

Es poco lo que falta para tener esto y creo que seria un paso muy bueno para los desarrolladores GeneXus, para ejecutar sin tener que modificar en nada el procedimiento a probar. 

Luego, si quiero ejecutar una prueba de integración, podría utilizar los mismos procedimientos de pruebas unitarias, pero con el cache deshabilitado, para que acceda a la base de datos como se hará en producción. 

Cada vez que pienso en el tema de TDD/CI/CD y encuentro alguien reticente a usarlo a pesar de todas las pruebas de su efectividad, me acuerdo de la anécdota   de los medicos que resistian a lavarse las manos antes de operar. 

por noreply@blogger.com (Enrique Almeida), el 28 de septiembre de 2017 a las 14:27

26 de septiembre de 2017

Enrique Almeida

KBDoctor - Nuevas consultas para modulos e integridad transaccional

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 bastante dificil de conseguir y espero que en las proximas versiones de Genexus sean mas faciles de ver.

Build Module Objects y References. 

Esta opcion permite hacer un build with this only de todos los objetos del modulo, mas todos los objetos que hacen referencia a algun objeto del modulo, mas todos los objetos que hacen referencia a alguna tabla que esta en el modulo.

List public URL/URI

Lista todos los webpanels / Transacciones / Procedimientos main.
Esto es util, para sacarla antes y despues de modularizar, de forma de detectar todos aquellos programas que cambian la URL de acceso o el nombre del exe/class a ejecutar para poder ajustar aquellas herramientas externas que usan nuestro sistema. Tambien sirve para ajustar la documentacion del sistema.

Module Dependencies

Lista todo lo externo que necesita un modulo para ejecutar.
Es util para cuando quiero llevar un modulo de una KB hacia otra, para saber todo lo que voy a necesitar llevar o adaptar en la otra KB.

Split main object. 

En el proceso de modularizacion, es comun tener que mantener el nombre de algunos objetos, que estan siendo usado desde otro sistema de terceros, por ejemplos procedures command line, web services Rest o SOAP.
Esta opcion, lo que hace es crear un objeto que mantiene el nombre anterior, y mueve el objeto viejo con otro nombre al modulo correspondiente y lo llama con los parametros originales..

List Module Statistics

Permite sacar algunas estadisticas basicas de los diferentes modulos, como cantidad de objetos, cantidad de objetos publicos, cantidad de tablas, cantidad de tablas publicas y en el futuro, tendra tambien medidas de la calidad de la modularizacion de toda la KB. Hoy tengo un indicador, pero estoy teniendo problemas cuando la KB tiene submodulos, pues algunos objetos se estan contando mas de una vez. Cuando tenga tiempo voy a arreglarlo.

Move Transaction to folders.
(esta opcion esta deprecada y va a desaparecer en el futuro)

Con estas opciones es bastante mas facil la tarea de modularizar una KB existente.

Estudiar Integridad Transaccional

Tambien agregue otra opcion, pero bajo Objects, para poder ver los arboles de llamadas y ver cuales son los objetos que hacen commits.



El estudio de que objeto hacen realmente commit y si hacen commit en otra UTL y demas, es un proceso bastante complejo.

Espero que le pueda servir a alguien mas.  Voy a espera para subirlo hasta despues del evento, pues en esto dias previos al Evento Genexus, todo el mundo esta bastante alborotado y con mucho trabajo.

por noreply@blogger.com (Enrique Almeida), el 26 de septiembre de 2017 a las 19:39