Ir al contenido principal

X Evolution 1 Beta 1

Luego de  algunos CTP se liberó la Beta 1 de la Evolution 1. ¿qué tiene la Evolution 1? bueno, de todo un poco, acá hice una pequeña selección de los temas que me parecen más interesantes.

Yo cambio, tu cambias ¿¡quién nos integra!?
El problema de la "integración de conocimiento" es algo interesante, si se utiliza GeneXus se tiene una gran ventaja pues integrar nuevo conocimiento a una KB impacta automaticamente el conocimiento ya existente y permite el desarrollo incremental, un tema no menor que, para quienes estamos acostumbrados a él, nos suena obvio pero no es tan así fuera de Genexus. En fin, creo que la mayoría de los lectores de este blog saben a que me refiero.

Ahora, el problema se puede llegar a dar cuando más de un desarrollador modifica el mismo conjunto de objetos, especialmente si trabajan en equipos de trabajo (¿empresas?) diferentes.

Hasta ahora la solución era que una de las versiones de ese conocimiento pasaba por encima de la otra, incluso sin tener muy claro cuales eran las diferencias, los cambios que se estarían perdiendo, etc.

El "change defender" creo que está muy bueno para ayudar a resolver el problema de desarrollo en varias ramas desconectadas que en algún momento se tienen que integrar. El ejemplo canónico es la software house que hace customizaciones en un cliente y de algún modo se "desengancha" con la versión "principal" que tiene su linea de desarrollo.

El "change defender" tiene un "analizador de cambios" que permite  ver qué se modificó de cada lado e integrar esas modificaciones en un único objeto de modo automático (en la medida de lo posible) o manual (lo hace el developer) pero asistido por un "comparador" que lo ayuda en dicha tarea.

Con esta característica se puede manejar más facilmente la integración de ambas lineas de desarrollo (la linea principal y las customizaciones en cada cliente).

En equipo se llega más lejos.

Un capítulo especial merece el  GXserver, con el mismo se simplifica muchisimo el trabajo en grupo sobre la misma KB manteniendo cada uno la independencia, practicidad, etc de tener la KB local, pero a su vez conectado con una KB central desde donde recibir los cambios de los otros y adonde subir los propios.

Como corolario, con  GXServer es tremendamente fácil compartir una KB, simplemente es un "send to server" y eso queda en un servidor que es (si se quiere) accesible vía HTTP y desde donde otros pueden obtener esa KB, realizar las modificaciones que quieran y subirlas nuevamente. Todos desconectados pero sincronizados.

Se pueden ver algunos ejemplos de KBs compartidas en el GXServer publico hosteado en Artech, por ejemplo el GXwiki 3.0 o una KB de ejemplo de uso del Google Feed Control.

Las polillas existen


No soy perfecto (¡vaya descubrimiento!) por lo cual cometo errores, tener una herramienta de debug  que me ayuda a localizarlos y corregirlos es una muy buena noticia.

Sobre todo si habla mi propio idioma de desarrollador Genexus (reglas, transacciones, for each, etc). No se necesitan incluir más "msg" en los objetos y se tiene una herramienta muy más sencilla y poderosa para encontrar (90% del trabajo) el origen de los problemas y luego corregirlos (10% del trabajo).

En la misma linea el profiler puede resultar interesante para "afinar" una aplicación manejandose siempre con los conceptos conocidos por el desarrollador GX.

Esta naranja tiene más jugo

La X introdujo un cambio sustancial: es posible editar objetos mientras se está haciendo un "build" de la aplicación (especificando/generando). Con lo cual se reducen los "tiempos muertos" que ese proceso de build podía significar.

Ahora en la Evolution 1 ese proceso de build es más ágil aun porque no se espera que finalice la especificación para comenzar a generar los objetos. Sacarle el jugo al "dual core" con procesos de especificación/generación en paralelo realmente hace diferencia.

Con esto el tiempo total de build se reduce sustancialmente en máquinas con suficiente polenta (dual-core) y aprovechamos la ley de Moore :).

...y justo yo arranco unos días de licencia... pero bueno, por suerte este 2009 me dio un "día sanguche" así que por lo menos un poco me puedo divertir con estos nuevos chiches...

Comentarios

  1. estimado para la version evolution 1 es necesario actualizar licencias, pues estas ya me funcionan para el genexus x, gracias por tu respuesta

    ResponderBorrar
  2. Fabian: si, precisas pedir claves nuevas.

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en