Ir al contenido principal

It's about collaboration, it's about web 2.0, it's about wiki..

GeneXus X es una versión totalmente renovada de GeneXus e incluye una cantidad de innovaciones con respecto a los conceptos ya conocidos en versiones anteriores (desarrollo declarativo, productividad, etc) y otros nuevos (extensibilidad, integración, etc).

En esta versión también hubo una innovación importante en cuanto a la documentación de la misma, trabajo nada sencillo que ha requerido un esfuerzo importante de muchos "documentadores", toda la documentación ha sido escrita desde el primer momento en el Community Wiki esto nos ha permitido que la misma sea facil y constantemente actualizada y a su vez el recibir colaboración no solo de otros miembros de Artech sino de cualquier miembro de la comunidad que quisiera colaborar.



De este modo creo que se ha logrado una documentación inicial muy rica, incluso considerando los grandes cambios que en muchos aspectos trae la versión, pero sobre todo una documentación en permanente evolución y enriquecida por la experiencia y conocimiento que todos han aportado y puedan aportar.

Esta documentación es la primera vez que la basamos en el gxwiki, wiki implementado en GX, que dicho sea de paso proximamente se estará liberando la versión 2.0 implementada en GeneXus X.

Fue un proceso interno bastante interesante que nos permitió conjugar perfiles bien diferentes como desarrolladores, documentadores, usuarios, soportistas, etc, perfiles que en muchos sentidos tuvieron que "romper moldes" y en definitiva fueron enriqueciendo dicha documentación en un proceso de evolución permanente.

Algo que a mi me resulta particularmente interesante es que toda esa información incluída en el wiki también ha sido publicada offline (HTML), de modo que quien se instale GeneXus X o simplemente quien la baje del download center puede accederla sin estar conectado.

gxxdoc.png

A su vez dicha información tiene un orden especifico lo cual facilita su lectura en muchos casos:

gxxdoc3.png

Pero más interesante me resulta lo siguiente: cada documento estático y local tiene un link para ver la versión "online":
gxxdoc2.png

de modo que uno puede consultar la información local que es una "foto" a un momento dado o puede ir a ver la última versión de dicha información.

Pero no solo puede ver dicha información sino que puede actualizarla, corregirla, mejorarla ¡directamente editando esa página wiki!.

De este modo se logra lo mejor de los dos mundos: la permanente y fácil actualización, así como la comodidad de la información local y con determinado "orden".

It's about collaboration, it's about web 2.0, it's about wiki...

Comentarios

  1. El otro dia te comentaba que la ultima documentacion que me atrapo fue la de la 7.5; ahora esta me gusta como se genero, como se usa etc etc, son todo loas, tanto la version off que es la que mas uso como la del wiki que hoy me entretuvo 2 horitas.

    Se nota el cambio a favor !!!

    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