Antes de empezar la conferencia en si, quisiera empezar con un juego o una adivinanza.Soy alguien a quien le encantan los números, los acertijos y los trucos de ilusión óptica. El mundo en que vivimosVivimos en un mundo donde los números se tratan “alegremente” o “livianamente” y hablamos de millones, miles de millones, billones, 20.000 millones de dólares, 7.000 millones de dólares como si de un “vuelto”, un “cambio” se tratase, en ese marco es que traje esta adivinanza para uds. Recuerdo que en mis clases de matemáticas siempre hablamos de los ceros no significativos son los que van a la izquierda, hoy parece que los ceros son “no significativos” independientemente de donde estén.En ese mundo, mi pregunta aquí es: ¿Cuántos puntos ven en esta PPT? (miren que me costó mucho esfuerzo, como verán, el diseño no es lo mío y escribir todos esos puntos me llevó mucho “copy&paste”).Bien ¿cuantos hay?¿1.000? ¿10.000?, hagamos una aproximación… pongamos que son unas … 50 o 60 columnas por unas 40 filas, pongamos entonces 40x60=2.400. ¿Eso es una buena aproximación?Bueno, si, es una buena aproximación. Es más, la respuesta exacta es 3.437, hay 3.437 puntos ahí.Esa es la respuesta exacta: 3.437Es mucho o es pocoPero eso es ¿es mucho o es poco? Como dice Decaro: “ante una pregunta difícil ud. siempre conteste: depende, eso lo hará ver inteligente y nunca quedará mal”. Bien, depende.Depende de los que los puntos signifiquen, supongamos que son dólares… no es mucho dinero… en un mundo que habla de 700 billones de dólares, como si hablara de hojas que lleva el viento…alguien preguntará ¿700 billones americanos? Porque eso son 700 mil millones sino son 700 millones de millones… que es otra cosa… ¿a quien le importa? No hay modo de imaginarse siquiera esa cantidad de dinero. Digamos que 3.437 dólares es poco… no me miren, no los tengo pero en cualquier caso si hablamos de dinero no es mucho.Supongamos que es lo que cobra Cristiano Ronaldo por jugar al fútbol.. ¿Es poco no? Si para entender lo que cobra CR precisamos sacar la cuenta por minuto jugado para lograr llegar a un número que podamos “manejar”!!Supongamos que son los goles que metió Uruguay en la eliminatoria… bueno… busquemos otro ejemplo mejor…Supongamos que son objetos de una KB ¿nada mal no? 3.437 es un número interesante, una KB ¿mediana? En cualquier caso, 700 mil millones o 3.437 , es un número finito, grande, inmanejable, pero finito.)Supongamos que son personasAhora, supongamos que son personas, supongamos que son 3.437 personas, supongamos que cada punto de esos representa una persona, supongamos que es cada una de las personas que se participará de este evento en los próximos tres días.Es más, son las 3430 personas que anoche estaban registradas a este encuentro.¿Imaginan el nivel de sinergia que se puede producir entre 3.437 personas compartiendo 3 intensos días de interacción, de aportar y recibir? ¿el enorme brainstorming? ¿la cantidad de oportunidades que se pueden generar?Entonces, si bien la respuesta exacta es 3.437, la respuesta correcta es MUCHO… MUCHISIMO, porque esos 3.430 no son puntos, son personas y cuando se trata de 3.437 personas trabajando juntas… el número es infinito y solo el cielo es el limite.¡Bienvenidos entonces al XIX Encuentro GeneXus, muchas gracias por estar y como dice Chiquita Legrand “la mesa está servida”!----------------------------Opcion1 (corta)Ahora, la respuesta correcta es otra, porque cada uno de esos puntos no es un punto, sino que representa a una persona que estará acompañandonos en este encuentro, muchas de las cuales están presentes hoy.La respuesta correcta entonces es: MUCHO. Porque esos no son puntos, son personas y un grupo de 3.500 personas interactuando produce una sinergia enorme, es un enorme centro de brainstorming, es un sinfín de oportunidades de aportar y recibir.Bienvenidos entonces al XIX Encuentro GeneXus, muchas gracias por estar y como dice Chiquita Legrand “la mesa está servida”.
El año pasado hablaba de la X y la reingenieria que esta significaba respecto a las versiones precedentes. Lo comparaba con el cambio de auto que por esa época había tenido.Los principios detrás de manejar el auto seguían vigentes pero las prestaciones del nuevo modelo eran netamente superiores. Comentaba el desafío que significó para mi cambiarme de versión y el temor a no lograrlo.Luego el éxito de haberlo logrado y haber obtenido una experiencia de manejo superior.
Hoy vengo a contarles sobre la Evolution 1 y nuevamente, como los dos últimos años, utilizo como punto de comparación un auto. El 156 y el 159 son la misma máquina pero diferentes, son la misma plataforma y están basados en los mismos principios: brindar una experiencia de manejo superior. El 159 es un 156 mejorado sustancialmente.El 156 fue la revolución y el 159 es la evolution.En el caso de GeneXus pasa lo mismo, la X fue una versión innovadora, una re-ingeniería total del IDE para obtener una experiencia de desarrollo superior y la generación de aplicaciones Web 2.0 de altísima calidad.
Esta es una versión es el resultado de un intenso proceso de beta testing que duró casi un año (los primeros “bits” se liberaron en el evento pasado (22/Set/2009) y la versión final se liberó el 2/set de este año).En ese proceso de beta testing más de 500 betatesters aportaron sus ideas, experiencia de uso y esfuerzo, intercambiando más de 6.700 mails en el foro y aportando a las más de 1.700 pruebas automatizadas a las cuales se somete cada build de esta versión.Gracias a los BT y pueden conocer sus experienciaMuchos de estos “earlyadopters” tienen hoy aplicaciones en producción, a muchos de ellos podrán conocer e intercambiar experiencias en el transcurrir de este encuentro e incluso podrán asistir a conferencias de algunos de ellos comentando su experiencia en el uso de esta versión tanto para el desarrollo de nuevas aplicaciones como para conversión o re-ingeniería de las ya existentes.
Bueno pero ¿qué es la Evolution 1? ¿qué tiene de nuevo? ¿quéventajas me da? En esta versión pusimos foco en 4 pilares: Facilitar la conversiónLa experiencia de conversión a la X nos llevó a mejorar el pasaje a esta versión y a su vez todas esas mejoras fueron volcadas a la Evolution 1. Enterprise levelapplicationsEl desarrollo de aplicaciones de misión crítica con esta versión fue otro de los objetivos principales.ApplicationCustomizationResolver un problema importante que tienen las Software Houses que es ¿cómo manejar la personalización de las aplicaciones?.DeveloperExperienceMejorar la developerexperience aun más
Como deciamos, uno de los focos de la Evolution 1 ha sido el facilitar la conversión de aplicaciones a esta versión.De la X a la evolution 1Para aquellos que están en la versión X pasar a la Evolution 1 es tremedamente fácil, quien maneja un 156 maneja un 159 sin inconvenientes porque todo el entorno ya es conocido y todo el trabajo desarrollado en la X ha sido plasmado en la Evolution 1.De la 9.0 o anteriores a la Evolution 1En este sentido creo que hay dos aspectos resaltables.Madurez por la experienciaExisten muchas experiencias de conversiones a la X y a la X evolution 1 lo cual le dio madurez a la versión al proceso de conversión en si.La conversión de KBs de porte nos ha dado la oportunidad de mejorar el proceso.Algo importante en este sentido es que en el equipo de desarrollo y de test, toda experiencia y trabajo realizado en la X era volcado inmediatamente a la evolution 1, de modo que la evolution 1, durante el proceso de BT, se alimentó de esa experiencia para lograr una versión no solo mucho más potente, sino también con un alto grado de madurez inicial. Prueba de lo cual son las aplicaciones que se encuentran hoy en producción con esta versión.En este sentido creo que lo más importante es conocer las experiencias de sus colegas en este encuentro, conocer esas experiencias seguramente aportará mucho más valor que el que yo pueda aportar ahora. Soporte de GUI y TextPor otro lado creo que otro punto importante en este sentido es que hemos incluído en esta versión los generadores Java, NET y VFP para Windows, así como los generadores RPG y Cobol. De este modo la migración de las soluciones a un ambiente Web 2.0 se simplifica, evitando tener que mantener dos ambientes de desarrollo y KB diferentes. A su vez aprovechando toda la potencia que el IDE ofrece.La evolution 1 entonces es una versión sobre la cual construir sus nuevas aplicaciones, pero también una versión a la cual convertir las ya existentes.
Las aplicaciones de misión critica no solo requieren una interfaz rica sino escalabilidad, buena performance, etc.En este sentido aplicaciones generadas han sido mejoradas y hoy son más rápidas e interactivas.Más rápidas e interactivasHemos reducido el tamaño del HTML significativamente, mayor compresión de los JS, el tráfico se ha reducido. Además de eso ejecutamos más acciones en el cliente con lo cual en más casos, con respecto a la X y muchos más casos, con respecto a 9.0, no es siquiera necesario viajar al server y todo se resuelve en el cliente.Esto produce aplicaciones, por default, más rápidas e interactivas.
La interfaz RICA son un must de las aplicación de misión crítica, en este sentido la versión X incluyo el concepto de UC.Esta es la paleta de controles default de GeneXus X. En la misma se encuentran los controles estándar (edit, image, etc) y algo que conocemos como UC.(click)Los UC significan, basicamente, que cualquier desarrollador puede encapsular lógica de presentación implementada en un control en JS, SilverLigth o Flash en un “user control” el cual se puede agregar a la paleta que los desarrolladores Genexus tienen disponibles.Luego el desarrollador GeneXus lo utiliza como si de un control “estandar” (built-in) se tratase. Dependiendo de la funcionalidad que el control provea es la información a “cargarle”, por ejemplo, si quiero mostrar una gráfica seguramente usaré un control “chart” para eso, el cual cargaré con un DP que devuelve el conjunto de valores a graficar.Extensibilidad explosivaDejenme contarles una anécdota respecto a los UC. Un día, hace quizas un par de años o un poco menos, fue antes de la liberación de la X, estabamos discutiendo con Gastón sobre el tema de los UC y especificamente ¿cuántos llegarían a ser? Si sería necesario agruparlos de algun modo para tener una paleta de controles más usable.Pensamos: bueno nosotros tenemos este set inicial de 4 o 5 de controles y la comunidad desarrollará sus controles para, por ejemplo, resolver otros tipos de menus, capaz que algún player multimedia, otros tipos de treeviews… en fin.. ¿15? ¿20? bueno… no mucho másqueeso.(click) La realidad nos sorprendió. Esta es la paleta default de GeneXus X Evolution 1, esa paleta incluye “built-in” 20 “usercontrols”.Tantos controles se han desarrollado que tuvimos que crear el concepto de “categorias” de modo de agruparlos y que fuera más fácil su localización y uso. Hoy han decenas, tal vez cientos..Extensibilidad (gxui)A su vez, al ser extensible, otros desarrolladores han implementado controles, muchos de los cuales han disponibilizado a la comunidad a travez de gallery.genexus.com. Incluso se han desarrollado “bibliotecas de UC” como es el caso de la GXUI que es un set de controles basados en la ext.js que incluye controles desde un “layout” para definir precisamente el “layout” de un webpanel hasta una grilla propia que permite, por ejemplo, re-ordenar las columnas dentro de la misma. Dicho sea de paso, para utilizar esta grilla simplemente se establece una propiedad que dice que la grilla utilizar no es la “nativa” sino la gxui.grid, con esto se pueden utilizar el load, foreach line, etc como si de una grilla nativa se tratase.CollaborativeProjects 2.0Si ud quiere saber más sobre el tema puede ir a la charla de Armando al respecto, en cualquier caso está invitado a participar en los CollaborativeProjects 2.0 que se estará lanzando mañana de tarde.Gastón y yo estabamos equivocados y la comunidad nos sorprendió con el desarrollo explosivo de los UC.
Lo importante son los resultados no las herramientasPero lo más es el nivel de las aplicaciones que se llegaron a generar con esos UC, porque no se trata de cuantos controles tengo en la paleta sino de la utilidad, de la orquestación de los mismos en una aplicación, dejenme mostrarles algunos ejemplos…Quien es el cliente En este caso estamos viendo una aplicación de manejo de cabañas ganaderas desarrollada por Ganaderas Sofía, la 2da Ganadera en cantidad de animales de Paraguay, la cual podrán ver más en detalle en la 2da parte de esta mañana en la conferencia de Hugo Correa. Si se fijan en esta aplicación.(Click)La aplicaciónEn el centro se encuentra la actividad en la cual el usuario está enfocado en este momento que es ver rápidamente el stock de los animales con diferentes segmentaciones: por propietario, por categoría, etc.Para ello utiliza el UC de Google Chart, el cual está incluído en la biblioteca de GX Google Visualization Library.(click) El contexto es importantePero a su vez a la derecha brinda información al usuario del mundo que lo rodea, de su contexto. Para ello utiliza otro UC, en este caso es para consumir RSS internos (otros objetos GX) o externos. Como/ProductividadLo interesante de esto es que se basó en la potencia de los UC para brindar una solución mucho más rica en cuanto a la “userexperience” sin sacrificar la productividad (se trata de poblar esos controles con datos, no de técnicas sofisticadas de desarrollo) ni requerir conocimiento específico de JS, Silverligth o Flash.Además es una aplicación que mantiene al usuario enfocado en la acción especifica de ese momento pero en contacto con el mundo que lo rodea.
Esta aplicación es el Issue Tracking interno de Artech, nuevamente si se fijan está orientado a la tarea: (click) el inbox de issues, en este caso utilizando una grilla provista por la GXUI.A su vez en el contexto incluye un treeview con el resto de los proyectos en curso, la información sobre la ejecución de los test y la información sobre el flujo general de issues por tipo.
Esta es una aplicación de un cliente de Brasil que está en este momento revisando su agenda implementada con el UC GXscheduler.
Sitio del porte de wanermusic.com.br hacen un uso intensivo de los UC y requieren de una escalabilidad enorme para soportar el nivel de accesos. Está hecho con la Evolution 1.
Dejenme contarles otra historia.La empresa PEMEX tenía que desarrollar un proyecto en el área de “prospección y perforación”. Este proyecto tenía como particularidad que tenía que manejar información en bases de datos y a su vez toda la cartografía (topografía, performaciones, plataformas, oleoductos, etc) para lo cual PEMEX utiliza ESRI que es un potente GIS al cual se le pueden agregar capas con diferentes tipos de información, un lider en el segmento.El desafío era manejar ambos “dominios” de modo unificados, poder representar la información almacenada en la base de datos en los mapas y poder, interactuando con ese mapa, obtener y actualizar información en la base de datos.Se decidió entonces emprender un proyecto entre PEMEX, GeneXus consulting e ICA, Ingenieros Consultores Asociados, que es una firma empresa uruguaya especializada en ESRI.El resultado final del proyecto fue un éxito. (click) Y lograron integrar ambas tecnologías en una aplicación utilizando UC.
ESRI es un producto muy potente, pero a su vez especializado y de alto costo, no solo por el software en si sino por la infraestructura que requiere.Esto lo deja fuera del alcance de muchos posibles usuarios(click)Pero si ICA tenía el UC como conector para facilitar el acceso al ESRI ¿porque no proveer entonces los servicios de ESRI en un esquema de SaaS?De este modo los conceptos de Web 2.0, Mashupsapp, SaaS y Long Tail se acoplan basados en el uso de tecnología sofisticada de un modo sencillo.(Pueden ver una conferencia sobre lo que ofrece ICA en este mismo encuentro)Nuevos modelos de NegociosLos UC no solo solo mejoran sustancialmente la “userexperience” de las aplicaciones, además muchos de ellos, proveen la capacidad de integrarse facilmente con otras aplicaciones a nivel de interfaz, un tipo de “mashupsapplication”. De este modo se pueden generar nuevos soluciones o hasta modelos de negocios, por eso hablo de Web 2.0->Enterprise 2.0.
De modo similar SIE, una software house de Argentina, desarrolló una aplicación de carrito de compras y manejo de tarjetas de fidelización de clientes, la cual comercializa en un esquema SaaS.Podrán ver otros ejemplos en el resto del encuentro.
Otro de los aspectos de muchas de las aplicaciones de misión crítica es estar basadas o contener un workflow.El Gxflow ya estaba integrado al IDE GeneXus desde la versión X, la mejora más importante introducidaEn la evolution 1 pasamos a un esquema de notación BPMN.El punto más importante es la notación gráfica BPMN que además de dar una solución alineada con uno de los estándares de notación para el modelado de procesos con mayor adopción, también nos da más flexibilidad y expresividad para modelador los procesos de negocio.Por ejemplo hay una serie de patrones de workflow que antes no podíamos modelar o que era muy complicado. Hoy tenemos un símbolo Timer que te permite definir cuantos deadlines quieras en una tarea o te permite modelar una “waittask” entre un paso u otro. El evento signal que te permite dar una señal en un proceso y que otro proceso este “escuchando” esa señal para actuar a partir de ahí.
Otra necesidad de las aplicaciones de misión crítica es permitir acceder rápida, fácil y dinamicamente a la información de la base de datos (reporting).En la Evolution 1, además del objeto Query que ya existía en la X, se provee un UC que es el QueryViewer. (click)Este es un control control Flash que permite, por ejemplo, mostrar una grilla dinámica con información de la base de datos, en este caso los estudiantes de una universidad.(click)O mostrar los resultados de los exámenes de esos estudiantes en una “pivottable” permitiendo así el análisis de la información.(click)O mostrar los inscriptos por materia de modo gráfica.Lo importante de esto es que ese control viene “built-in” con Genexus y el mismo puede estar asociado a un objeto query (nuevo tipo de objeto incluído en GeneXus X) o puede estar asociado a un DP.De este modo se puede obtener rapidamente y de un modo muy sencillo un dashboard, en este caso, con información de los estudiantes.
Supongamos que existe una software house que provee una solución y que tiene un cliente (final o implantador) que precisa customizarlas para implantarla en una empresa. El problema que se plantea es el siguiente: El proveedor envía al cliente la V1 de la KB.El cliente la toma y comienza el proceso de personalización, además de la parametrización, debe modificar algunos objetos y agregar otros nuevos (extender el conocimiento).Por su parte el proveedor continúa trabajando en la KB, corrigiendo bugs, agregando funcionalidades, etc hasta lograr una V2.El problemaquetiene el equipo de cliente, esqueahoratienenqueintegrar los cambiosquehicieron los 2 equipos de trabajo de forma paralela.
A su vez ya en la X teniamos la trazabilidad de los objetos que nos permitía saber quién había hecho qué en qué objeto y cuando.Si a eso le sumabamos que teníamos las versiones en la propia KB, entonces parecía un problema que podía ser resuelto … y lo hicimos con lo conocemos como “change defender”.
¿Cómo funciona?Lo primero que se hace es propagar la versión 1 del proveedor al cliente.Luego el cliente modifica o agrega conocimiento en esa KB.Cuando el proveedor tiene una V2 para enviar lo que hace es propagar los cambios de esta V2.Al estar en la base de conocimientos que la información exacta de la Version que fue propagada originalmente (V1), entonces es bastante sencillo obtener el “delta” entre ambas versiones y eso es lo que se envía en el propagar.En esa propagación irán objetos nuevos u objetos que no fueron modificados por Mary. En este caso simplemente se tiene una nueva versión de ese objeto.Pero a su pueden haber objetos que hayan sido modificados por ambos equipos de desarrollo, en dicho caso la Evolution 1 incluye no solo la comparación de los objetos sino el merge automático de las modificaciones.Si este merge no puede ser automático, el desarrollador (Mary en este caso) es informado para que tome las acciones del caso y haga el “merge manual” que corresponda pues cuenta con todas las versiones del objeto para hacerlo.
La “developerexperience” ha sido mejorada en la Evolution 1 y tal vez uno de los aspectos más destacables sean las mejoras de performance en el IDEEn este sentido pusimos mucho foco en esta versión en optimizar los tiempos de desarrollo.Montamos un esquema de trabajo entre desarrollo y test que nos permitió innovar en los procesos de especificación y generación de un modo seguro.En este caso estamos viendo la historia de ejecución de una prueba del generador .NET y podemos ver, dada una mejora en la performance, en qué build sucedió así cual fue la causa de dicha mejora.
Este esquema nos permitió reducir significativamente los tiempos de “buildall” y “code & run”, es decir, modificar y ejecutar.
Dentro de la experiencia del desarrollador está el trabajo en equipo.En este sentido estamos liberando en este encuentro GeneXus server que es EL producto para trabajar en equipo con GeneXus.Dado que Breogán ya hizo una introducción y luego de esta conferencia viene una específica sobre el tema no profundizaré en sus características, si me parece importante resaltar que quienes utilicen la Evolution 1 podrán beneficiarse de las prestaciones de GeneXus Server.
Bueno pero ¿qué es la Evolution 1? ¿qué tiene de nuevo? ¿quéventajas me da? En esta versión pusimos foco en 4 pilares: Facilitar la conversiónLa experiencia de conversión a la X nos llevó a mejorar el pasaje a esta versión y a su vez todas esas mejoras fueron volcadas a la Evolution 1. Enterprise levelapplicationsEl desarrollo de aplicaciones de misión crítica con esta versión fue otro de los objetivos principales.ApplicationCustomizationResolver un problema importante que tienen las Software Houses que es ¿cómo manejar la personalización de las aplicaciones?.DeveloperExperienceMejorar la developerexperience aun más
La comunidad tiene hoy en la evolution 1 el 159, aprovechenlo.
