Entradas

Cambio de requerimientos: Es conveniente renombrar todo?

Imagen
Este es un problema ficticio, pero similar a muchos de los que nos enfrentamos cuando desarrollamos aplicaciones.

El usuario me plantea hacer una determinada funcionalidad, supongamos que se relaciona con el manejo de SOBRES y defino algo como

Tabla de Sobres
*SobreID
SobreRemitente
SobreDireccion
SobreFechaHora

Defino dos o tres tablas relacionadas y también hago programas del tipo

Trabajar con Sobres
Recibir un Sobre
Modificar Sobre

Se instala la funcionalidad en ambiente de pruebas y el cliente lo prueba y lo acepta.
Pocos dias antes de poner en producción, el cliente decide que quiere generalizar el uso de lo desarrollado para el manejo de sobres, para el manejo de paquetes (son sobres + cajas + bolsas)

Lo que pide es "un cambio chiquitito" que en todas las pantallas, donde dice SOBRE, se cambie por PAQUETE.

Si accedemos solo a lo que nos dice el cliente, nos va a quedar una tabla llamada Sobres, con contenido de paquetes y atributo con nombre SobreID, que en realidad v…

Usabilizando GXServer: Etiquetas en los commits

Imagen
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 estado que tiene el commit, en el caso qu…

Porque jodes tanto con modulos?

Imagen
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 casi todos los prob…

GeneXus Modularity Maturity Model

Imagen
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 que pertenecen. 
Nivel 4 - Minimizo acoplamiento, maximizo cohesion y evito ciclos - Se traba…

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…