Entradas

Mejorar la calidad de nuestro software ayudando a otros

Imagen
En Concepto desde hace un tiempo estamos haciendo cosas para colaborar con la incorporación de jóvenes al mercado de tecnologías de la información. Es un área que permite crecer a las empresas y a las personas, hay trabajo y todos salen beneficiados.

Fuimos con una borrador de una idea a hablar con los amigos de Abstracta y ellos elaboraron (supongo que ya lo tenían medio elaborado) un plan para armar centros de pruebas de software (o Centros de Excelencia?) en el interior del pais, para probar aplicaciones y detectar oportunidades de mejora.

La idea es crear la infraestructura  y capacitar a personas, para que las empresas del medio (y podria ser en el futuro del exterior) puedan contratar personal para realizar pruebas (de performance, funcionales, exploratorias, revision de codigo, de documentación, etc) con supervision de ellos, trabajando en forma remota desde dicho centro.

La idea es tratar de capacitar y contratar a gente joven con poca experiencia laboral , de forma de introd…

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…