jueves, 18 de diciembre de 2014

Una KB grande vs Varias KB mas chicas. Manejando fuerzas opuestas

A medida que pasa el tiempo es normal que las empresas automaticen cada vez mas sus procesos, desarrollando  (o integrando) aplicaciones en cada vez mas secciones de las mismas.

Con este crecimiento, aparecen fuerzas opuestas en la forma de modelar la realidad.

Por un lado, se quieren tener base de conocimientos lo mas chicas posibles, para poder entender y tener un desarrollo mas rapido y ágil. Esto implica que se van a tener varias KB para cada uno de los sistemas necesarios.

La otra opción es tener una KB que tenga todos los sistema de la empresa, siempre que sea posible. Esto hace que se tengan KB grandes, lo cual es buenísimo para el manejo del modelo de datos, el mantenimiento de las instalaciones, etc.

Comparación de ventajas y desventajas


VENTAJAS
DESVENTAJAS
Muchas
KB chicas
  • Fácil de entender cada KB
  • Desarrollo Agil
  • Diferentes versiones de GeneXus en cada KB
  • Fácil de instalar cada KB
  • Migraciones mas fáciles
  • No se mantiene la integridad referencial en forma automática
  • Programación rápida
  • Difícil de enteder el modelo global
  • Interfaces entre sistemas mas complejos
  • Proceso de instalación para cada KB (mucho trabajo)
  • Si hay objetos compartidos entre KB (por ejemplo transacciones) es difícil mantener sincronizados entre las KB
  • Dificil mantener propiedades sincronizadas
Una
KB grande
  • Modelo de datos unificado
  • Integridad referencial
  • Interfaces entre sistemas muy fáciles
  • Fácil instalar
  • Build all lento
  • Difícil de probar
  • Difícil de migraciones
  • Difícil de entender la relación entre los objetos de la KB.
  • Programación mas lenta

Parte de estas ventajas y desventajas pueden mitigarse utilizando módulos, dividiendo una KB grande en módulos mas pequeños. Aun faltan algunos ajustes para que esto sea práctico, pero son pasos en la dirección correcta. Por ejemplo, seria bueno poder ver una KB "filtrada" por un modulo, de forma de solo ver los objetos de dicho modulo y los objetos públicos de los demás módulos y nada mas. Esto ayudaría a los desarrolladores a entender una KB grande. 

Un caso que no se puede resolver correctamente usando módulos, es cuando se necesita una versión nueva de GeneXus para una parte del sistema. Por ejemplo, tengo una KB corporativa en GeneXus Evolution 2 y necesito desarrollar un sistema para dispositivos móviles que pueda funcionar sin conexión, por lo que tengo que usar GeneXus Evolution 3. 

Las opciones que tengo, son hacer una migración de toda la KB de Ev2 a Ev3 (lo cual es todo un proyecto en si mismo  y puede llevar recursos que en el momento no se tienen) o desarrollar el sistema en una KB separada en Evolution 3, e integrarla a la KB grande, cuando se realice la migración definitiva. 

Me viene dando vueltas en la cabeza este problema de mantener varias KB en diferentes versiones de GeneXus, pero que comparten un mismo modelo de datos. Tengo algunas ideas (no demasiado maduras) para poder resolver este problema, las cuales son bastante difíciles de implementar. 

Me parece importante conocer y manejar las fuerzas opuestas de muchas KB vs KB centralizada, pues muchas veces el éxito de mantenimiento de sistemas, dependen de como se organicen las bases de conocimiento de las instalaciones. 

lunes, 15 de diciembre de 2014

Don Eduardo

Hace unas semanas, falleció Romualdo Eduardo Gard Figoli, mas conocido como Don Eduardo.
Tenía cerca de 100 años, muy bien vividos. Fue uno de los verdaderos emprendedores de Uruguay, que conocí bastante, por haber trabajado para varias de las empresas de la que era dueño o accionista. 

Partiendo de un origen muy humilde, llegó a ser dueño y comandar importantes empresas de producción de aceite comestibles, cosméticos, molinos harineros,  empresas de trasporte, de alquiler de autos, producción agropecuaria y muchas mas. En los últimos años también  en biocombustibles. 

Una anécdota que lo pinta de cuerpo entero, es que junto con Gustavo y Raúl, teníamos que ir una vez por semana  a Molino San José (a 100 km de Montevideo), pues eramos responsable del centro de cómputos * de todo un grupo de empresas. 
Salíamos temprano, para llegar antes de las 7:00 AM pues teníamos que hacer algunos ajustes en las maquinas antes que entraran la mayoría de los usuarios a los sistemas. 
Casi siempre llegábamos al Molino, y Don Eduardo ya estaba trabajando. Había salido de Montevideo y llegado antes que nosotros!!. 

Recuerdo que al principio de los 90 cuando tenían un proyecto de producción de biocombustibles a partir de oleaginosos, que en aquella época lo veia como algo imposible y se termino de implementar mas de 20 años después. 

Siempre vivió tratando de no llamar la atención, con un perfil muy bajo, siendo un hombre hábil en la negociación y trabajador como pocos. Ejemplos como el de él son necesarios para Uruguay, pues lo considero un verdadero emprendedor.



viernes, 12 de diciembre de 2014

Rebuild All en GeneXus

Me llego una consulta de un colega y dejo la respuesta tambien aca, por si a alguien mas le sive.

Antes de hacer un REBUILD ALL, con GeneXus, es bueno aprovechar y borrar algunos archivos que pueden haber quedado desactualizados.

Lo que yo hago antes de ejecutar un rebuild es ejecutar el BAT

echo ----------------------------------
set dirGX=C:\GeneXus\GeneXusEv2U7
set dirKB=C:\models\ev2\KBdir
echo --- Borrado previo REBUILD ALL ---
del %dirKB%\*.ari /s/q 
del %dirKB%\*.0?? /s/q 
for /f %%i in ('dir /a:d /s /b %dirKB%\*') do rd /s /q %%i
MSBuild /nologo Rebuild.msbuild /p:KBDir=%dirKB%;GXDir=%DirGx%  /t:Rebuild
echo --- TERMINO EN BUILD ALL       ---


Que hace este archivo de comandos? 

Borra todos los archivos *.ARI de la KB (de la version actual y de todas la versiones de la KB). 
Borra todos los archivos donde se guardan referencias entre objetos que tienen extensiones 001, 005, etc). Estos archivos muchas veces quedan mal, cuando se tiene mas de un generador en la KB y son causante de muchos de los errores de compilacion cuando hay objetos que se generan WIN y pasan a generarse WEB y cosas asi. 
Borra todos los directorios que estan en bajo la KB (el directorio de la propiedad TargetPath, mas todos los directorios de usuarios, donde se guardan las especificaciones, el GXLock, etc, etc). 

Es bastante peligroso, por lo que conviene correrlo con cuidado y backups, pero es sano para tener un rebuild limpito. 

Para poder ejecutar el rebuild desde linea de comandos, tengo un proyecto MSBUILD que tiene

<Project DefaultTargets="Rebuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(GXDir)\Genexus.Tasks.targets" />
<Target Name="OpenKnowledgeBase">
   <OpenKnowledgeBase Directory="$(KBDir)"/>
</Target>
<Target Name="Rebuild" DependsOnTargets="OpenKnowledgeBase">
       <BuildAll ForceRebuild="true" CompileMains="true" DetailedNavigation="false" />    
</Target>
</Project>

miércoles, 29 de octubre de 2014

GeneXus y modelo fisico - Herramientas necesarias

Comentando el post anterior, un colega me preguntó que tipo de herramientas podrían desarrollarse para el manejo de modelo físico, dentro de KB GeneXus.

Lo que me gustaría es poder ver el modelo físico que hoy GeneXus intenta ocultar a los desarrolladores, pero que tiene mucha de la información necesaria.

Una vista interesante, seria poder ver las tablas por Data Store

DataStore1
    Tables/DataViews
         TABLA1
              * atributo1
                atributo2
                atributo3
             INDICES
                 Indice1
                     atributo2 (desc)
                 Indice2

                     atributo3
          Referential Integrity
                     Referenced by 
                                TABLA3
                     Referenced from
                                TABLA4 
  
          DataView1  (Asociated table TABLA3)
                  attexterno1
                  attexterno4
     
De las tablas, me gustaría poder especificar si es una tabla con alta cardinalidad y que % de crecimiento puede tener, lo cual puede servir para prever el funcionamiento del sistema.

También podría servir para que GeneXus sea algo mas inteligente en la definción de indices.
Por ejemplo, hoy tengo una tabla de parámetros, que tiene solo un registro. Si a la misma le defino atributos con subtipos (por ejemplo, países, monedas, etc) para que solo se puedan ingresar parámetros validos, hoy GeneXus define indices para cada uno de ellos.
Si especifico que una tabla solo va a tener un registro, GeneXus no debería definirle ningún índice.

Desde esta vista de las diferentes bases de datos de la aplicación, se podrían cambiar las propiedades de conexion y regenerar los archivos de configuracion (web.config, client.exe.config, client.cfg, etc).

Para el manejo de servicios web, estaria bueno tener una forma de verlos en forma global.

Web Services
      Servicio1   (SOAP)
               Parameters
                          IN: Parametro1, Parametro2, Parametro2

                          OUT: Parametro4
      Servicio2   (REST)
                 Parameters
                           IN: Parametro5
                           OUT: Parametro6

 [GENERATE location.xml]    [EDIT location.xml]   [Test WS]

Desde aqui se podria generar el archivo location.xml y también editarlo.
Seria bueno poder probar los web services en forma interactiva..

Otras cosas que podria tenerse en el modelo fisico, es poder modelar los diferentes ambientes de ejecucion de un mismo juego de ejecutables (desarrollo, pruebas, produccion, etc) y poder almacenar ahi las reglas de transformacion para adaptar los archivos generados por GeneXus.

El ambiente de desarrollo y el de pruebas, tendrian los mismos ejecutables, pero diferentes archivos para los Themes, diferentes location.xml, diferentes web.config, etc.

Se pueden almacenar los archivos directamente en cada ambiente o se puede poner las reglas de transformacion que permita cambiar el web.config que genera GeneXus y cambiarlo por el web.config que se necesita en el nuevo ambiente (por ejemplo, cambiando usuario / contraseña por otros.  Lo mismo se puede hacer con los temas.

Hay muchas herramientas posibles  que pueden y deben hacerse, para facilitarnos la vida.

domingo, 19 de octubre de 2014

Modelando realidades

Un esquema que me ayuda a entender las aplicaciones que desarrollamos con GeneXus es el siguiente:


No es nada original, pero me sirve para clasificar los objetos que utilizamos en el desarrollo de nuestra aplicaciones.
Tenemos tres modelos o vistas de la misma realidad, cada uno con un nivel de abstraccion diferente:


Modelo Físico

Aquí se encuentran las tablas y sus estadísticas de uso y  de distribución de datos, los indices, los diferentes tablespaces. También pongo ahí, todos los servicios que mi aplicación deba utilizar para funcionar.
Este modelo es fundamental para el correcto funcionamiento y performance de la aplicación, pero su complejidad es la que Genexus nos ha escondido (para bien) por años.
La aplicación va a seguir funcionando correctamente si tengo o no tengo un indice, aunque puede tener mejor o peor performance.
En este nivel, es donde trabajan principalmente los administradores de base de datos (DBAs) y administradores de sistemas (servidores de aplicaciones, servidores web, proxys, servicios web consumidos, etc).
Los desarrolladores GeneXus se tiene que preocupar poco por este nivel, a no ser que tengan problema de performance. A este nivel funcionan la auditoria con triggers, la reorg, las herramientas de ingenieria reversa, data view.


Modelo Lógico.

Es donde se modela lógicamente la aplicación, sin preocuparme de como va a ser implementado,  con las transacciones, data providers, data selectors y demás.
Por deformación profesional, es lo que mas me gusta hacer.
Aquí nos preocupamos por subtipos, claves, relaciones de integridad y se logra modelar lo que ve el usuario.
La particularidad que tiene Genexus es que teniendo el modelo lógico definido, logra deducir y generar el diseño del modelo físico, ahorrando muchísimo trabajo. Esto trae como consecuencia que muchos desarrolladores GeneXus no tengan claros conceptos básicos de modelo físico, por lo que pueden cometer errores que hagan que sus aplicaciones funcionen lento.


Modelo Conceptual

Es donde desarrolla la aplicación, es lo que el usuario final ve.
A este nivel hay que preocuparse de la estética, la usabilidad, el diseño gráfico de la aplicación.
Es donde los desarrolladores GeneXus deberíamos pasar la mayor parte de nuestro tiempo para ser mas productivos.


Utilidad. 

Para que sirve todo esto?
En realidad, ayuda a entender un poco mas como desarrollamos y los diferentes roles que se necesitan para lograr aplicaciones que sean usables. Todos los niveles deben estar mínimamente bien resueltos para lograr que la aplicación funcione correctamente. Los conocimiento que se necesitan para lograr un buen funcionamiento en el modelo conceptual, son totalmente diferentes a los que se necesitan para el modelo físico.
Cuando un desarrollador GeneXus  utilizando patterns, necesita hacer usar el comando NEW (que trabaja al nivel casi físico) al cambiar de nivel, baja su productividad.
Por eso es bueno que se tengan la mayoría del grupo de desarrollo trabajando a nivel mas alto de abstracción y que las tareas de modelado (lógico) y de optimización (físico) sean realizado por especialistas siempre que sea posible y no sean cuello de botella en el desarrollo.

Supongo que en el futuro cercando la especialización hará que tengamos herramientas especializadas para cada uno de los modelados.

Por ejemplo, ya existen herramientas especializadas para la edición de temas, editor de patterns, para el nivel conceptual.

A nivel de modelo lógico, hay diagramas de módulos, diagramas de relación entre transacciones y demás que ayuda a visualizarlo, aunque aun son muy mejorables.

A nivel físico, es donde puede mejorar bastante mas. Se puede hacer modelos de instalación de las aplicaciones para ayudar a los administradores para hacer el deploy de las mismas y tambien herramientas especializadas para el DBA, para que puedan manejar el modelo fisico desde GeneXus y no teniendo que usar herramientas especificas de las plataformas. Por ejemplo, si se conociera la cardinalidad de las tablas y su crecimiento, se podrian planificar los recursos necesarios a lo largo del tiempo o estudiar los programas que accede a tablas muy grandes, etc.

Cosas que se me ocurren que podríamos tener es tener registro de los diferentes ambientes donde se instala la aplicación (desarrollo, test, pre-producción, producción), en que servidores se instala en producción. tener un registro de todos los servicios consumidos y publicados por mi aplicación, que directorio necesita o utiliza mi aplicación, etc.


Conclusión. 

La división en diferentes modelos (conceptual, lógico, físico) es bastante arbitraria, pero ayuda a entender problemas algo mas chicos y limitados, que son mas fáciles de entender y resolver los problemas que se producen en ellos.
El hecho que Genexus nos aísle de algunas complejidades técnicas de bajo nivel, no quiere decir que las mismas no existan y posiblemente sea momento de  brindarle herramientas a los profesionales de cada uno de los niveles herramientas adecuadas para que puedan cumplir con su tarea de forma productiva.