Ir al contenido principal

Murió la 4x4

Aviso: Disfrute del camino porque no lleva a ningún lado.

Retrospectiva 1 

Hace muchos años, unos 15, lo que hoy conocemos por SAC era un cuaderno tipo "escolar" que recuerdo tenía una moto enduro en la tapa y donde uno iba anotando datos técnicos útiles (Internal Errors, piques de configuración de DBIII Plus, etc).

También lo usábamos para anotar cosas pendientes de resolver, datos de un cliente que nos había llamado. Entre esos datos esta el teléfono y obviamente el fax que era el único medio de mandar algo como un "print screen".

Si bien no había problemas de concurrencia porque el 90% del tiempo tenía yo el cuaderno y el otro 10% lo tenía Verónica Buitrón, el mismo no resistía el uso. Era un cuaderno para escolares y no para soportistas; les aseguro que lo peor que le puede tocar a un cuaderno no es ser comprado por un escolar. Luego de un tiempo el mismo era peor que el cuaderno de un carnicero.



Llegó el momento que había que "informatizarnos" un poco, desarrollar alguna aplicación sobre aquella Novell versión ¿3.x? no lo recuerdo, si me acuerdo de los NTLM (o algo así) que a Federico Wagner le divertían.

Bueno, cuestión que daba vergüenza (propia) el cuaderno así que había dos líneas: el CSD (customer support documents) y el SAC (Sistema de Atención a Clientes).

El CSD era un producto sofisticado, desarrollado por Alejandro Bia y básicamente hacia uso de la "Wordstar automation" por llamarlo de algún modo. Era la posibilidad de macros, palabras claves,  indexaciones & búsquedas que tenía el wordstar de esa época. Uno podía usar un workpanel (recién salidito del horno ese tipo de objetos) y mostrar en un subfile (hoy grilla) los resultados. Elegía uno y se abría el documento con wordstar ¡Maravilloso!. Priorizaba la potencia de edición, la estética y hacia alarde de toda clase de chiches. Era mostrar "integración con herramientas de escritorio antes de que existiera el escritorio" ;)  o el escritorio era el DOS nomás.

El SAC era otra rama, en lugar de redactar en Wordstar uno ponía algunos atributos obvios (titulo, fecha, etc) y luego llenaba el "campo memo" (hoy sería un LVChar). Aquellos que se guardaban "al costado" de la DBF en un DBT o algo así, luego evolucionaron en Foxpro 2.6 a archivos FPT. Este producto priorizaba la performance (en un mundo sin "ventanas ni mutitasking") y el contenido por sobre la forma.

Un punto interesante era como resolvían la búsqueda, en el caso del CSD uno tenía que incluir palabras clave en el documento de modo tal que luego se pudiera buscar por ellas. Tenia un muy coqueto workpanel con un edit arriba, del típico "trabajar con" y uno ponía palabras sueltas que luego eran buscadas (todas con AND) utilizando el propio buscador del Wordstar.

En el caso del SAC era diferente, no se requerían palabras claves y la búsqueda tenía una "matriz" de 4x4 (de ahí el nombre del post):

  Matriz 4×4 del SAC

Si se fijan en la imagen eran 4 edits horizontales x 4 edits verticales, las palabras en la misma línea se conectaban con "OR" (por eso la "o" que aparece entre edit y edit de la misma línea) y en diferentes líneas con "AND" (cualquier coincidencia con el WebSAC es casual ;))

Luego tenía un algoritmo "rudimentario" que consistía en buscar en los memos las palabras digitadas utilizando la función ATC y un enorme nido de IFs (no existían los CASE en GX en ese momento) que resolvía los conectores AND/OR (Para los fanáticos después veo si me hago un tiempito para poner más al respecto).

¿Que pasó? el CSD fue poco conocido y el SAC avanzó hasta lo que es hoy. El resto es historia.

Obvio que hubo varios cambios (de arquitectura por ejemplo), los memos no se usaron más y se pasó a una tabla de palabras (SacId*, SacPalabra) que dicho sea de paso ronda el millón de registros hoy, pero esencialmente es lo mismo y la 4x4 sobrevivió a todos esos cambios y ahí está evolucionada pero esencialmente la misma.

Retrospectiva 2 

No solo hay conocimiento en los SACs, hay otros fuentes como "white papers", los documentos (word) del help, materiales de capacitación (PPTs), etc. Por lo cual el SAC comenzó a ser mucho más limitado porque su alcance no cubría todo lo necesario.

Entonces en el 2000/2001 inventamos la GXDL basados en una idea bastante sencilla: cada uno edita en la fuente que quiere, luego tiene que proveer un HTML, ese HTML es indexado con el index server del IIS (para la versión "online") y con el HTML Help Workshop se genera un CHM para la versión "offline".

El amigo Ignacio Roqueta desarrolló en su momento la GX Quick Seach Bar que es un "add-ins" del Internet Explorer y envía la consulta a la GXDL terminando en una página de la misma: http://www.gxtechnical.com/gxdl/query.asp

A pesar de la GXDL y la GXQuickSearch la 4x4 siguió existiendo y a la vez se integró a la GXDL como una fuente más de la misma.

Retrospectiva 3, el presente y ¿el futuro?

Hace mucho tiempo uso Google como buscador y hace bastante me instalé el Google Desktop Search que, para los desordenados como yo, es una excelente solución. Buscar documentos, mails, etc es muchísimo más fácil. Solo he visto que Laura Passaro es mejor que Google Desktop Search en esta tarea.

Hace menos de un año, de la mano del amigo Cuiñas, nació la GXSearch, basada en Lucene. Mismo componente que los amigos de la GXOpen Task Force usan en el wiki de la comunidad.

¿Qué tiene de maravilloso?

Bueno, de algún modo esta solución indexa cualquier cosa de un modo eficiente y a la vez tiene una potencia expresiva en la búsqueda y una eficiencia en su ejecución que es pasmosa.

De algún modo resolvió todos los problemas que llevaron al CSD a morir rápidamente (obligatoriedad de una fuente->wordstar, definir palabras claves, etc),  los problemas que la 4x4 no supo resolver (flexibilidad en la consulta, indexación de múltiples fuentes, etc) y que la GXDL mejoró pero con mecanismos sofisticados y engorrosos (pasaje a HTML, parseo del mismo, compilación del HTML) y que en cualquier caso muestran una "foto" de la información (eventualmente des-actualizada y siempre read-only).

Como frutilla de la torta hace unos días se publicó la GX Search Toolbar 

Talvez no tiene ideas revolucionarias, talvez es simplemente una mejor implementación de una serie de ideas ya conocidas, basados en una tecnología moderna y de la mano de universalización de las mismas (me refiero a Google que universalizó las indexaciones/búsquedas).

Me resulta entonces interesante constatar como a veces los cambios revolucionarios son simplemente girar 2 grados una idea o simplemente juntar la idea con una tecnología diferente y arribar a un resultado muy superior.

¿Podrá la 4x4 soportar este nuevo embate?

Creo que no. Mis amigos, creo que la espada de Damócles pende sobre ella y solo es cuestión de tiempo. Lo digo con cierta pena pero a la vez con la alegría que me produce la constatación de algo en lo que siempre creí: las ideas superan ampliamente los soluciones, estas últimas son simples implementaciones limitadas y coyunturales de una idea.

También me alegra constatar otra "ley natural" en la que creo: el factor desencadenante de un cambio siempre es un ser humano apasionado por la idea y que es capaz de juntar la misma con la tecnología necesaria para llegar a una solución. Una idea que primero funciona en su mente y recién después de mucho trabajo y superar con optimismo y pragmatismo todos los errores (nunca fracasos) es un bien tangible para el resto de nosotros.

Lo del principio... avisé que disfrutara del camino porque no llegaba a ningún lado y acá se terminó el mismo ¿abruptamente? bueno, el que avisa no traiciona.

Comentarios

  1. Solo falto musica lenta de fondo !! que nostalgia che

    Para la proxima hacemos un post a duo y contamos como se paso el help de htmls sueltos en una unica carpeta a un chm !!

    Fue para largar la 7.5

    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