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.

viernes, 17 de octubre de 2014

PiensoPienso: Cual es la salida de este programa?

Un procedimiento GeneXus Evo3 main, tiene el siguiente código.

Cual es la salida del mismo?

a)
Venezuela AUN NO PERTENECE AL mercosur
>>> Venezuela pertenece al mercosur
Venezuela AUN NO PERTENECE AL mercosur

b)
Venezuela AUN NO PERTENECE AL mercosur
>>> Venezuela pertenece al mercosur
Venezuela pertenece al mercosur

c)
Venezuela pertenece al mercosur
>>> Venezuela pertenece al mercosur
Venezuela pertenece al mercosur

Justifique la respuesta


lunes, 6 de octubre de 2014

Modelando nuevas realidades

Hace unas semanas escribia sobre una dificultad que estamos teniendo con las aplicaciones actuales, donde el análisis de impacto que estamos haciendo se queda corto pues no mide lo que realmente cambio.

Esto me hizo pensar, sobre la evolución de las aplicaciones y como vienen cambiando la forma en que las desarrollamos.

En el GX24, se mostraron parte de las ramas de investigación que esta haciendo Artech para tratar de modelar las nuevas aplicaciones, donde los datos no están en bases de datos, sino que los orígenes de datos son diversos (bases de datos, sensores, archivos, servicios, etc) y donde se almacenan dichos datos también esta cambiando. Uno de los enfoques para tratar de modelar esto, son las Dynamic Transactions.  Con esto, se va a poder asociar a una transacción "cosas" diferentes que no son tablas, permitiendo usar la potencia del lenguaje Genexus para manejar dichos datos. No tengo detalles de la implementación, pero se me ocurre que en el futuro podremos:

  •  recorrer colecciones de datos estructurados (SDT collection) con for each
  •  leer y grabar en una tabla remota con los mismos for each
  •  hacer joins entre una tabla y un SDT
  •  manejar tablas en memoria  
  • leer de una balanza (puerto serial) sin tener que hacer programación especifica
  • levantar o bajar una barrera usando for each
Cualquiera de estas funcionalidades son de por si un aporte fundamental para poder programar aplicaciones mucho mas potentes, con lenguaje conocido y sencillo. 

Lo que me queda replicando en la cabeza, es que aun no tenemos la potencia de modelar las realidades de nuestras nuevas aplicaciones, que a medida que pasa el tiempo se vuelven mas interconectadas y complejas. 

Algunas de estas realidades son :

1) KB central en una version de GX y una aplicación satelite en otra version
Un ejemplo de esto, es cuando tengo una KB centralizada en Evolution 2 y necesito desarrollar de cobranzas con Smart Devices Offline, para lo cual tengo que desarrollar con Evolution 3 . Tengo varias opciones:
  • Migro toda la KB a la version Evo3 (es un proyecto en si mismo y puede ser imposible por diversos motivos). 
  • Mantengo la KB central en Evo2 y creo una KB en Evo 3 que tenga todo lo necesario, transacciones fundamentalmente. Desarrollo en dicha KB y agrego la tarea de sincronizacion de traerme todos los objetos que necesito de Ev2 a Ev3 cuando estos cambian. Tambien puede ser necesario pasar objetos de Ev3 a Ev2, con lo cual la cosa se complica un poco mas. 
  • Mantengo la KB central en Ev2 y creo la KB para cobranzas en Evo3 y agrego una capa de servicios o de Data View para poder interconectar dichos desarrollos. 

2) Varias KB. 
Por motivos de manejo y performance al desarrollar, se decidio hace tiempo dividir el modelo de la empresa en varias KB. Ahora se tienen varias aplicaciones, en diferentes data store sobre la misma base de datos. Se necesita al menos una persona para mantener la sincronizacion de los objetos comunes de la KB. 

Cualquier persona que haya que tenido que lidiar con varias KB que comparten objetos, tablas o servicios por varios años, sabe que no es facil lidiar con eso, pues la realidad cambia, cambian los objetos que la modelan y surgen problemas de sincronizacion. 

Como modelar esto? 

Algo en lo que estuve pensando, era como modelar estas realidades de forma de poder administrarlo  mejor. 

Una de las posibilidades es tener un MODELO DE DATOS, en el sentido amplio, que incluya los orígenes de datos diversos que mis aplicaciones consumen y por otro lado tener las diferentes aplicaciones que interactuan condicho modelo de datos. 

Dicho modelo de datos tendría:
  •  un conjunto de tablas de un modelo de datos relacional en una o mas bases de datos que mi aplicacion crea y maneja. Son todas las tablas reorganizadas por GeneXus. 
  • un conjunto de tablas que uso, pero no puedo cambiar su estructura, pues son manejadas por otros
  • un conjunto de servicios que la aplicacion crea y maneja (por ejemplo los servicios que se crean para ser consumidos por aplicaciones Smart Devices
  • un conjunto de servicios de terceros que la aplicación consume pero no puede cambiar
Un esquema rapido de esto, seria verlo como tiene Visual Studio, que tiene una SOLUCION (seria mi modelo de datos) y dentro de ellos los diferentes PROYECTOS (serian aplicaciones hechas con KB actuales).

Modelo de Datos y Servicios
     Aplicacion1
     Aplicacion2
     Aplicacion3

El modelo de datos, se encargaria de ver todas las transacciones, data store y servicios que publican las aplicaciones contenidas y realizaría la normalización y reorganización de cada una de ellas. 

Cada una de las aplicaciones, seria equivalente a una KB actual, podría estar en una versión diferentes de GeneXus y generaría la aplicación como hasta ahora. 

Llevándolo a un ejemplo de la vida real 

Solución LUCIA - Modelo de Datos
  •        Base LUCIA
  •        DB WikiProcedimientos
  •        DB WikiDocumentacion
  •        DB Data warehouse
       Aplicaciones
                KB LUCIA (Evolution 2)
                WikiProcedimientos (Evolution 3)
                WikiDocumentacion (Evolution 3)
                Análisis de Riesgo (Java nativo)

Podría trabajar con la KB como hasta ahora, haciendo build all solo de los objetos de dicha KB, o también hacer un build de toda la solución, con lo cual se harían un build de cada uno de las aplicaciones de la solución.

Me resulta bastante complejo de explicar en un post, lo que significa que aun no tengo el tema demasiado claro y tengo que madurarlo mas.
En resumen, quiero tener un modelo que abarque tome en cuenta todas las transacciones de diferentes KB de una solucion y sea compartido por todas las aplicaciones de dicha solucion.
                 
Varios cambios serian necesarios (o deseables) para que este esquema permita modelar mejor la realidad.

Data View modificables

Hoy definir un data view con una tabla asociada, implica que dicha tabla no es modificada por GeneXus. La limitante, es que las tablas solo se pueden definir dentro de un schema y la forma de definirlos en otro es a traves de data view. Seria deseable, poder marcar un dataview como reorganizable y que Genexus permita hacer los cambios, o en su defecto, permitir que las tablas tengan las propiedades que hoy se pueden definir en los data view, como otra base de datos, otro schema y que GeneXus las reorganice. 

Servicios como orígenes de datos

Es común importar un servicio y usarlo como fuente de datos. Hoy es sumamente engorroso mantener actualizado la definición de dichos servicios si los mismos cambian. Seria bueno tener una etapa en la reorganizacion que permita re-importar la definicion de dichos servicios si los mismos cambiaron, pero de forma facil. 




viernes, 3 de octubre de 2014

#GX24 - Mi resumen (un poco) técnico


Voy a tratar de hacer un resumen de los aspectos técnicos de GeneXus del 24 Encuentro Internacional GeneXus.


Solo puedo hablar de lo que vi y pude entender, que es menos de la mitad de lo que se mostró o se anunció.

GeneXus Evolution 3

Mucho fuerza y empuje para que los usuarios se pasen a esta versión, con mucho énfasis en aplicaciones WEB y de dispositivos móviles. 
Se comentaron las novedades en el desarrollo WEB de aplicaciones adaptables (responsivas es una palabra que no significa nada para mi) a diferentes tamaños de pantalla, con navegación mas fluida y pueden controlarse mucho mejor que parte de la pantalla renovar. Posibilita el desarrollo de aplicaciones de pagina única y también con notificaciones en el WEB. Las perspectivas son muy buenas, hay que trabajar bastante en el tema de como migrar las aplicaciones existentes para que aprovechen estas nuevas funcionalidades. Esto se puede hacer en forma paulatina. 
Un llamado de atención que haría, seria con respecto al tema de los objetos Módulos, pues me parece que no están siendo promocionados como se merecen. Desde mi punto de vista, los módulos van a cambiar muchas cosas:
  • la forma en que entendemos/estudiamos las KB
  • como se va a distribuir los trabajos dentro del grupo
  • como  probar la aplicación
  • como se va a instalar las aplicaciones
  • como administrar un proyecto GeneXus
  • como modelar la operativa de una empresa (en una KB o en varias KBs)
Es un objeto potente y que puede influir en mucho, que ha tenido una prensa limitada. Tenemos que trabajar en despulgar los errores que van quedando, para promocionarlos como se debe. 
También tenemos que ayudar a Artech a que entienda las diferentes escenarios de uso de estos objetos, para que puedan implementarse en forma paulatina en las próximas versiones. 

En el tema de dispositivos moviles, no tuve tiempo de ir a muchas charlas, por lo que puedo hablar solo en forma superficial.  Se hablo de la importancia de diseño, usabilidad y tener muy en cuenta la experiencia del usuario. Me encanta ver como temas importantes y complejos como la sincronización de datos entre bases de datos centrales y los dispositivos móviles, que hace poco mas de un año era un dolor para muchos, pasan a ser de uso corriente y aceptados. Una señal clara que estuvieron bien resueltos. 

GeneXus Server

Se anuncio una version nueva del server, con una interfaz web mas linda y la promesa de desacoplar el desarrollo. Voy a probarla en los proximos dias. 

GeneXus Cloud. 

La posibilidad de instalar nuestras aplicaciones en servidores de diferentes proveedores en la nube (IBM, Microsoft, Amazon, Montevideo Comm, rackspace, etc)
Algo que vamos a usar mucho en los proximos años. Si logran hacer facil este paso y esconder toda la complejidad subyacente, vamos por muy buen camino. 

AppsInFive

Una forma de distribuir aplicaciones y cobrar por su uso. Escribo sobre lo que entendí,.tomen esto con pinzas.  Creo que puede quedar mas claro con un ejemplo. 
Si tengo una KB que tiene una aplicación para Servicios de Comedores, para dispositivos móviles y esta funcionando para la concesión de la Aduana. La aplicación publica el menú semanal, notifica de promociones, cambios en el menú.  Ademas se puede pagar directamente con el celular.  

La aplicacion funciona bien, pero no tengo tiempo/ganas o conocimiento para venderla y  paso la KB a AppsInFive. Esta fabrica de aplicaciones, empaqueta la aplicación y la deja pronta para ser distribuida. Para ello, crea un nuevo dominio llamado "Servicios de Comedores", del cual se van a crear aplicaciones personalizadas para todos los comedores que quieran tener una aplicación propia. 
Al concesionario del LATU, le interesa tener una aplicación, pero no quiere complicarse la vida comprando una, sino que quiere alquilarla por el tiempo que dure la concesión. 
Entonces va al sito de AppsInFive y podes elegir un diseño, icono, titulo y me llega un link a una planilla electronica que tengo que llenar con datos. Esta planilla tendria una hoja para Platos, Postres, Menues, Promociones, etc y cargo el menu de la proxima semana. 
AppsInFive se encarga de subir esto a las tiendas para que los usuarios finales puedan bajarse dicha aplicacion al celular. 
Semanalmente se cambia la planilla electronica, y esto cambiará los datos que veran los usuarios en sus dispositivos moviles. 
El uso de la aplicacion lo pagará el concecionario en forma mensual, alquilandola por el tiempo que le sirva. 
Encontraron soluciones sencillas a problemas complejos. Creo que puede ayudar mucho a empresas desarrolladoras de software perezosas de comercializar soluciones. 

Live Editing

Es la posibilidad de cambiar la estética y el comportamiento de aplicaciones sin tener que generar/compilar. Cambio el tema y el cambio se ve inmediatamente en la aplicación funcionando. 
Que se puedan cambiar temas, ya es muy util, pero también se pueden cambiar el diagrama de distribución (layout) de la aplicación y también los eventos. Cuando lo mostraron en vivo, logro impresionar al publico que aplaudió en forma espontanea. 
Va a acelerar muchísimo el ciclo de prototipación en WEB y/o Smart Devices. 

Live Abstraction

Es un nombre que a mi no me dice nada, pero lo que esta atrás es una idea que puede ahorrar mucho trabajo. Hoy en dia es dificil y engorroso poder usar en GeneXus el diseño realizado por algún diseñador grafico que nos pase su trabajo con Photoshop o plantillas en HTML. 
Estan trabajando en poder importar el trabajo del diseñador con poco trabajo en GeneXus. Los que hemos pasado por este dilema, sabemos que es algo que lleva muchisimo rato hacerlo. Si artech logra implementarlo bien puede ser un golazo. La importacion va a tener que ser bastrante inteligente como para saber traducir varias controles nativos a su equivalente en GeneXus. 

Metodología de desarrollo

Hubieron charlas de testing, integrar el diseño temprano, big data (no encontré nada interesante, pero me falta ver mucho). 
En las charlas de Build y Deploy, me gusto mucho lo que mostró Sebastian Cardello (Cruise Control y desarrollo de ellos). Fue nombrado en varias charlas el tema, que estaba un poco abandonado, por lo que creo que ya valio la pena el esfuerzo. 

Bueno, puedo escribir un rato mas, pero nadie lee post tan largos. La sigo otro día.