Seis APIs de Google para Don Isidro Parodi

El 15 de mayo de 2007 la consultora Globant realizó un evento denominado Globant Tech Upate, promocionado como una jornada donde se presentaría lo último en metodologías de desarrollo.
Banner de Globant Tech Update
Luego de la introducción y bienvenida a los asistentes que realizó Guibert Englebienne, CTO de Globant, hubo una presentación llamada “Agile methodologies and lean software development at Globant” donde el PM Ricardo Moral contó como se trabaja en los proyectos de la compañía.

Luego el evento contó con la exclusiva participación de Patrick Chanezon, Google API Evangelist, que realizó una presentación llamada: “Six Google APIs for Don Isidro Parodi. Let’s help Don Isidro build a better web site using 6 Google APIs”. La charla trató sobre Ajax Search, Maps, Google Data, KML, Google Checkout, Google Web Toolkit, un temario muy interesante…

Lo positivo:

Lo negativo:

Está disponible en el sitio de Globant una home page del evento. Allí pueden encontrar una descripción, la agenda y repasar el contenido descargando los slides.

Publicado el 23/08/2010 dentro de la categoría eventos, tecnología | Realice un comentario 

Update 08: Web 2.0 Cadena de favores

Continúo mi serie de comentarios sobre el Update 08 con el resumen de la charla Web 2.0: Cadena de favores.

En esta charla Gustavo Guaragna, CEO y socio fundador de Snoop Consulting, básicamente realizó una presentación sobre el estado del arte de las aplicaciones denominadas web 2.0 y cuáles son los caminos que tomará la evolución de las mismas en la opinión de la compañía que él preside. Fue acerca de una visión principalmente estratégica de la web como plataforma de desarrollo y de negocios. La charla la dio en conjunto con Martín Salvadori, uno de los arquitectos de Snoop Consulting.

Al comienzo hizo una breve introducción de cómo Snoop se involucró con el desarrollo y uso de aplicaciones web 2.0 ya que no era lo más característico de la compañía en el mercado local, donde se caracteriza por la experiencia en implementaciones SOA. Cuando comenzaron a expandirse tuvieron que ver que oferta llevaban como compañía a otros mercados. En Argentina tratan de mantener el liderazgo tecnológico. En Europa vieron que la demanda y lo que mueve en gran medida la economía son las PyMEs, y que la oportunidad de negocio era ofrecerles calidad e innovación usando las tecnologías emergentes de la web 2.0.

Las aplicaciones web 2.0 se diferencian de los sitios tradicionales en varios aspectos: hay aplicaciones web 2.0 orientadas a redes sociales, a contenidos, a servicios/transacciones, sitios que proveen valor agregado sobre la información, sobre los datos… Hay nubes de tags dando vuelta que quieren explicar qué es la web 2.0:
Nube de tag que enumera conceptos de la web 2.0

Por ello al pensar en qué es la web 2.0 el orador citó la conocida parábola budista de los ciegos y el elefante, dando cuenta de que tiene múltiples aspectos y que se pueden dar múltiples definiciones.

Ante la consulta del orador, aproximadamente la mitad del auditorio recordaba los tiempos en los que no había web. Es decir, la mitad de los asistentes habían crecido en un mundo donde la web es algo más que forma parte de la vida cotidiana tanto como la electricidad o las heladeras… En su opinión la web experimentó un ciclo de aparición, ascenso, caída (la época de la burbuja de las .com) y ahora resurge con fuerza con esta encarnación a la que se llama web 2.0.

Los oradores plantearon que tenemos que hacer un cambio mental al pensar en las tecnologías de la web 2.0 (análogamente al cambio que se ha hecho en el desarrollo más tradicional, antes uno se hacia su propio ORM o la herramienta de soporte que fuera, y hoy se piensa en soluciones existentes ya probadas). Hay que empezar a percibir en la web 2.0 oportunidades, no sólo de negocio, sino desde el punto de vista del desarrollo. En la industria se va a continuar haciendo desarrollos tradicionales, sistemas transaccionales, pero hay que pensar en dónde hacer la diferencia aprovechando las nuevas tecnologías.

Los oradores se preguntaron: “¿Y cuál es el conflicto, cuál es la pregunta, el ser o no ser de la charla ésta? ¿Todo esto de la web 2.0 es un gran verso o en verdad hay algo sustancioso para los desarrolladores alrededor de esta tecnología?”

Aclararon que aunque mayormente esa charla se realizaba en otros contextos dirigida a gerentes, consideran que es importante para los desarrolladores conocer y pensar en estas cuestiones por lo que nos habilita a hacer la web 2.0. Para muchos usuarios el advenimiento de la web fue un retroceso en su experiencia de usuario de aplicación, pero ahora la web 2.0 es un habilitador para que construyamos aplicaciones mas sofisticadas.

Si se piensa en los orígenes de la web 2.0, hay que recordar que el tema de la colaboración está desde los inicios mismos de la web: nació como una herramienta de colaboración entre laboratorios de física, era una forma de escribir documentos y compartir información entre científicos. Luego apareció la idea de usar la web como plataforma para hacer aplicaciones, a mediados de la década pasada aparecen las wikis (confianza en que el usuario tambien puede escribir y generar contenido), aparecen los web services y otras tecnologías, evolución en protocolos… que deviene todo en lo que llamamos web 2.0. Paralelamente surgen teorías económicas, como la teoría de la larga cola. Aparece la folksonomía, las comunidades se autorregulan. Aparecen tecnologías y modelos como AJAX, RIA, la web se vuelve tan poderosa como diez años atrás…

En este modelo los usuarios tiene el control de los datos. En los desarrollos aparecen seis competencias clave:
• servicios (opuesto a software)
• arquitectura de participación
• tener modelos de escalabilidad rentable (teoría de la larga cola)
• fuentes de datos re-mezclables
• el software presente en dispositivos heterogéneos
• aprovechar la capacidad colectiva

Como conclusión se plantea que el eje central de la web 2.0 es el posicionamiento estratégico: usar la web como plataforma (de negocios y de desarrollo).

Evaluación:

Esta exposición fue un poco desprolija. Aunque seguramente tuvo algún ensayo previo faltó mayor coordinación de la presentación, había una falta de timming en las intervenciones de ambos oradores que hacía que el ritmo de exposición fuese discontinuo y por momentos hubiera una innecesaria reiteración de los conceptos.
   Algunos de los problemas de coordinación estaban derivados del hecho de que al momento de tener que comenzar la charla la notebook de uno de los oradores tuvo problemas y los trataron de solucionar mientras comenzaban a exponer. Esto también causó algunas demoras para comenzar. Además Guaragna usó bastante más tiempo del previsto para la exposición, lo que motivó un desajuste para asistir a las charlas siguientes.
   A pesar de estos inconvenientes la presentación me resultó muy interesante como overview general de las tecnologías denominadas web 2.0 y las posibilidades que brinda para pensar soluciones innovadoras.

Entradas relacionadas:

Publicado el 16/03/2009 dentro de la categoría eventos, tecnología | 2 Comentarios 

Update 08: Aplicaciones web online/offline

Una de las charlas del Update 08 fue la que dio Fernando Das Neves, Gerente de I+D en Snoop Consulting, denominada Aplicaciones web online/offline: Google Gears y Adobe AIR.

Fernando Das Neves (Gerente de I+D de Snoop Consulting)Esta exposición fue la que me resultó más útil. Unos días antes del evento estaba buscando software que manejara listas de tareas y encontré referencias de que uno de los productos más interesantes para ello es un sistema basado en la web que se llama Remember the milk. Al ver las múltiples formas de uso que tenía vi un servicio offline basado en Google Gears pero no sabía bien qué era esa tecnología o cómo funcionaría. Ésta presentación me brindó con mucha claridad todo el background conceptual para entender este tipo de mecanismos y sus posibilidades.

Ya que la exposición de Das Neves sobre el tema fue muy clara y precisa, la mejor forma de dar cuenta de su contenido es transcribirla:


Bueno, muchas gracias por quedarse… Se que la mayoría de ustedes ya para esta altura ya tienen hambre, así que voy a tratar de distraerles el hambre lo más posible en estos 40 minutos.

El título de esta charla es un título contradictorio, porque el título de esta charla dice aplicaciones web online/offline y uno se pregunta de qué diablos estamos hablando. Dejenmé definir primero entonces de qué estamos hablando. Una aplicación web online/offline es una aplicación que está dividida en front-end y back-end generalmente separados, donde el front-end (cuando hablamos de front-end hablamos de la interface) está desarrollado con tecnologías usadas normalmente en la web, dicho de otra manera, cosas que anden adentro de un browser. Adentro de un browser puede ser la combinación familiar de Javascript más CSS más HTML o puede ser algo que ande arriba de la máquina virtual de Flash.

Lo que hace estas aplicaciones diferentes a una aplicación web común es que pueden funcionar de dos maneras. Puede funcionar en el modo cliente servidor común, típico de cualquier aplicación web, o bien puede funcionar desconectada también, en el escritorio, como una aplicación de escritorio. Y acá es la parte que uno pregunta: ¿estamos todos locos?, que es lo que me dijo una amiga cuando le conté de qué iba a hablar: “¿estamos todos locos?”.

(…) ¿Vieron que la informática es un círculo infinito?. Lo que parece de lo que estoy hablando es que cuando era 1980 Dios hizo la Commodore 64 y vio que era bueno y que por un tiempo le alcanzó, pero no le alcanzó tanto tiempo, entonces después aparecieron las aplicaciones web que durante bastante tiempo no eran muy diferentes a ésto: es básicamente un formulario donde cada cosa que cambiaba iba al server y venía la respuesta y el server tenía el estado completo de la aplicación todo el tiempo, en realidad la interface no era más que una vista sobre el estado del server, y en realidad la aplicación no hacia demasiado porque los browsers tampoco eran capaces de hacer demasiado. Estabamos felices con que hubiera formularios y entonces Dios vio que esto tampoco era bueno y decidió hacerlo más complicado e inventó las aplicaciones web con interfaces ricas, que tratan de emular la funcionalidad de las aplicaciones de escritorio con las ventajas de una aplicación web: que está disponible en todos lados, que lo único que necesito para que esté disponible es un browser, pero por otro lado tratan de darle la ventaja de una aplicación de escritorio, que es la interactividad, era imposible la interactividad antes con el ciclo pedido/respuesta, pedido/respuesta, pedido/respuesta, pedido/respuesta de aplicación web, simplemente el tiempo de respuesta era lo que hacía que la interactividad no fuera pràctica… el famoso efecto de “pagina en blanco, estoy esperando”. Y entonces las aplicaciones web ricas trataron de agregar algo de las aplicaciones de escritorio y empiezan a tener entonces en principio los graficos de negocio y todas esas cosas que se usan para los ejemplos y empiezan a tener algo más simple como ventanas de diálogo, que uno dice que hacen dentro de una aplicación web,y entonces ahora estoy adentro de algo que emula una aplicación de escritorio adentro del web… Entonces si esto es lo que pasa en el 2005, ésto es lo que pasa en el 2009: que tenemos la Commodore 64 adentro del browser. ¡Y este es el futuro de la informatica!

Acá es cuando mi amiga me dijo: “¡Estamos todos locos! ¡Volvemos para atrás! ¿Que pasó? No era que las aplicaciones web estaban buenísimas? ¿Qué pasó?”

Entonces voy a tratar de convencer a ustedes y a mi amiga que eso no es así. Entonces voy a contestarles porque haría semejante locura, por qué yo querría tener una aplicación web offline/online.

Hay una serie de causas. La primera es que las aplicaciones web están en todos lados, la gente está acostumbrada al modo de interacción (uno podría decir que es el mismo de las aplicaciones de escritorio pero hay muchas aplicaciones hoy en día ,sobre todo en las empresas, que no tienen equivalente en escritorio). De esa gente hay mucha gente que trabaja no en una posición fija, que es la ventaja de aplicación web, pero tampoco trabaja conectada todo el tiempo, no porque le gusta estar aislada sino porque no tiene una conexión, y eso es una razón bastante importante. El personal de ventas es un ejemplo clásico de gente que está bastante tiempo desconectada (…) y un argumento extra es que el modelo de HTML más CSS más Javascript (aún cuando parezca ser hacer pasar un pedazo de tronco redondo en un agujero cuadrado) tiene algunas ventajas (…): el HTML se puede usar muy rápidamente para combinar funcionalidad y estructura y el CSS para darle después la apariencia visual y combinar el funcionamiento con Javascript. Sean honestos con ustedes mismos, diganmé cuanto tardan en prototipar una interface (la que se les ocurra) de escritorio y cuánto tiempo tardan en prototipar la interface en HTML, CSS y Javascript, todo junto. Y en general si uno puede termina usando HTML.

De hecho a lo que va Microsoft ahora con el XAML o Sun con JavaFX o el gusto de la semana en realidad es derivación de esto: es tener una interface que declare estructura separada del código y el código lee la estructura porque eso hace el diseño de la estructura de la interface mucho más fácil de cambiar. Entonces no estábamos totalmente mal. Hay algunos problemas con Javascript más HTML más CSS que no fueron diseñados para hacer lo que les hacen hacer, pero no estaba totalmente errado.

Y juntando todo ésto y poniéndolo en el contexto adecuado lo que tengo es una aplicación que tiene las ventajas de aplicación web para el usuario, o sea que el usuario sabe como se usa y que además sigue siendo multiplataforma porque los runtime de ésto son multiplataforma. Entonces tengo una tecnología que conozco para hacer aplicaciones que corran en más de una plataforma.

(…) La revista Technology Review lo considera una de las tecnologías emergentes, una de las tecnologías que va a empezar a tener impacto desde el 2008. Entonces, como desarrollador, ¿cómo se mira ésto?

Bueno, si yo estoy metiendo la aplicación adentro del escritorio y estoy diciendo que es una aplicación que puede funcionar desconectada, ¿que tipo de aplicación web se puede pasar? ¿Cualquier aplicación web? La respuesta es que no…

Cualquier aplicación se puede volver a escribir para que funcione pero no cualquier aplicación se puede pasar, básicamente estamos hablando de aplicaciones donde el servidor no sea el estado completo y la interface una cara boba del servidor, y donde podamos de alguna manera en esa aplicación o capturar los momentos de envío de información al server para almacenarlos cuando está desconectado o bien interceptar los puntos de comunicación si es una aplicación AJAX que hace comunicación asíncrona. Para los que son de Java una aplicación Struts no es un buen candidato para este tipo de aplicaciones, sino en realidad para hacerla de vuelta (pero por otra serie de razones que van más alla de esto).

¿Qué hace falta para hacer una aplicación de este tipo? Hacen falta 3 partes: hace falta un runtime, un shell que me envuelva la interface de la aplicación que antes era de aplicación web para transformarla en aplicación de escritorio, que me provea ciertos servicios que la aplicación ahora por funcionar desconectada puede usar y que están relacionados con la máquina en donde corra, necesito un toolkit para construir las interfaces, (…) y necesito algún medio para sincronizar cuando esta aplicación desconectada pasa a conectada. Esto no es (…) agarrar la aplicación web y ponerla dentro del escritorio sino que el el propósito es tener una herramienta que funcione en los dos casos: cuando hay una conexión disponible, que se comporte como una aplicación común, que ande como aplicación web o que funcione también cuando está desconectada y que sea exactamente la misma aplicación…

Y éste es el esquema de la arquitectura de una aplicación web, o de los componentes, para no usar una palabra tan grande como arquitectura… Hay una interfaz de usuario que tiene unas ciertas limitaciones sobre lo que puede hacer, esas limitaciones también afectan al back-end, hay que hacer un back-end mínimo, cuando digo back-end no estoy hablando de un server de aplicación y 10 MB de bibliotecas, sino sólo es un back-end mínimo. Ese back-end mínimo además hace de intermediario y de almacenamiento, porque con un monitor de conexión es como la aplicación se da cuenta de que está online/offline, y o bien funciona como una capa la conexión al servidor como si fuera una aplicación web o bien debe almacenar el resultado de las operaciones que el usuario hace en un almacenamiento local para poder, cuando la aplicación pasa a modo conectado nuevamente, pasárselas al servidor porque al fin y al cabo si se está hablando de una aplicación que funciona en modo conectado o desconectado siempre hay un servidor y el servidor sigue funcionando de la misma manera que siempre, concentrando la información.

(…) La mayoría de las aplicaciones que van a ver con esta tecnología hoy en día en mi opinión son bastante pobres demostrando la tecnología porque básicamente evitan la parte de la sincronización enteramente haciendo que sólo se pueda leer, Google Reader por ejemplo. Google Reader es sólo de ida, o sea se pueden bajar cosas y leerlas desconectado… ¡Wow! Es lo mismo que bajarse una página web pero con otro nombre eso!

Las aplicaciones serias de este tipo necesitan un componente de sincronización porque necesitan comunicarse con el server para los dos lados, no solo bajando información para leerla cuando no hay una conexión web. Y las dos plataformas que existen hoy en día para esto, que son Google Gears y Adobe AIR, tienen APIs para todos los componentes del runtime, queda de parte de nosotros todavía la parte del servidor a la que la idea siempre es en una aplicación existente tocarla lo mínimo posible y en una aplicación nueva diseñarla para que sea compatible.

¿Qué provee el runtime? Hoy en día los runtimes proveen todas estas cosas: Como es una aplicación de escritorio puede acceder al disco que tiene un almacenamiento local (que es en realidad SQL Lite en estas dos implementaciones), puede decirle a la aplicación cuando hay una conexión de red disponible, tiene una manera de instalarse, tiene servicios de impresión hasta cierto punto (eso es bastante primitivo hoy en día) y pueden correr procesos en background, que para los que saben Javascript saben que Javascript es single threaded por lo tanto no existe background (hay maneras de hacerlo pero no hacen orgulloso a nadie…).

Éstos, fijensé, son servicios típicos de una aplicación de escritorio y no es casualidad porque lo que quiere uno hacer cuando uno diseña una aplicación de este tipo no es simplemente envolver una aplicación web y transformala en escritorio sino tener una aplicación que se pueda transformar como aplicación web y aplicación de escritorio, ambas cosas..

Como les decía, ambas tienen una base de datos y ese es el corazón de cómo hacen cuando están desconectados. En realidad el runtime provee una base de datos local entonces cuando uno está desconectado almacena las cosas localmente en un esquema que no tiene por què tener nada que ver con el esquema que usa el server, solo tiene que ser un esquema mínimo necesario para almacenar la información para poder volversela a mandar al server, dado que el server es el que sigue haciendo el trabajo de mantener la base de datos unificada. Y lo que provee entonces es una API (…) que no se diferencia demasiado de ODBC o JDBC: abro la conexión, puedo darle el SQL, recibo los resultados, muchas gracias. Lo que pasa es que lo estoy haciendo contra la base de datos local. Esa es la parte interesante. Hay algunas cosas que aparecen arriba de esto como que si se usa una base de datos local y encima es SQL Lite hay un montón de herramientas que pueden mirar SQL Lite, entonces a uno le interesa que la información esté encriptada en la base de datos local para que si la laptop cae en manos erróneas no sea fácilmente leíble, pero el esquema es éste, la API no es terriblemente sofisticada , esto es Javascript puro lo que están viendo…

Hay intentos de hacer un ORM en Javascript etc etc… para mí es gente que se va de mambo, porque el punto de esto es “mantengamosló simple, no hagamos el trabajo dos veces” Que bueno! Tengo dos ORMs ahora, uno en el server y uno en el cliente, soy feliz… ¡NO!

¿Qué puedo usar para implementar ésto? Como les dije hay dos runtimes disponibles, los son gratis, Google Gears y Adobe AIR. Son muy parecidos, tal vez Adobe AIR tiene una mejor integración en el escritorio que Google Gears. Google Gears trata de meter algunas cosas más que Adobe AIR no tiene, pero los runtimes son bastante similares, las APIS no son tan diferentes tampoco. A este punto la elección entre uno u otro es a dónde se juega uno que parece que la tecnología va a ir.

Y las combinaciones que se pueden hacer entre runtime e interfaz son todas éstas: uno puede usar GWT (Google Web Toolkit) para hacer la interface y después envolverla con Google Gears -eso está explícitamente soportado-, puede usar Adobe AIR y Google Gears, tiene que usar JSON en ese caso, tiene que cambiar el protocolo en el que se hablan cliente/servidor pero no es un gran problema. Adobe AIR además, por ser de Adobe tiene el soporte explícito para meter Flex adentro de la ventana, uno no necesita programar en Javascript sino que la idea es que el mismo front-end que uno desarrolló en Flex para una aplicación web lo puede transformar en una aplicación de escritorio. En ese caso como Flex es nuevo y por funcionar en una máquina virtual separada (al fin y al cabo Flash no es más que una máquina virtual) es más probable que sea más fácil de pasar que una aplicación existente porque lo forzó a diseñar la aplicación en el back-end y en el front-end con interfaces específicas, mientras que en el otro caso la interface puede ser mucho más sucia, depende del tipo de aplicación. Lo que no se puede usar -para los que conocen un poco la historia con Flash- es Open Laszlo (…).

Nosotros tenemos una aplicación web que hemos desarrollado donde juntamos los antecedentes de los proyectos (cuánta gente intervino, cuántas horas, quién fue el cliente, cuánto salió finalmente el proyecto, cuánto le cobramos al cliente… la información de antecedentes de proyectos) y con eso creamos una versión online/offline de la aplicación. La interface estaba escrita en Yahoo User Interface Library lo que hizo que no fuera tremendamente complicado envolverla. La parte complicada en estas cosas es pensar que no están trabajando en una aplicación de escritorio ni en una aplicación web… están trabajando en una aplicación web que quieren que sea extensible a escritorio. Entonces lo que hicimos nosotros es tener una manera a conciencia de cómo se extiende la aplicación web, el front-end de la aplicación web es Javascript, cómo interceptamos estos puntos de comunicación para que nuevas versiones de la aplicación web se transformaran en nuevas versiones de la aplicación de escritorio más o menos automáticamente. Y eso no tiene nada que ver con tecnología, tiene que ver mas con diseñar una arquitectura de como uno produce la aplicación. Ninguna de estas cosas en realidad hoy en día es problema de tecnología, es mas problema de cómo hacer que tenga sentido y donde le encuentro el valor. A la propuesta evidente “ahora puedo usar la tecnología web para escritorio” la respuesta es “y a mí ¿que me importa?” y “por que tendría que hacer eso yo?” La propuesta de valor es tomar aplicaciones web existentes que tengan la definición lo más desacoplada posible entre cliente y servidor (interface y back-end) para poder envolverla como aplicación web. O bien desarrollarla desde un principio como aplicación que va a nacer online/offline, entonces el desacople entre interface y back-end puede ser explícito, básicamente lo que hace uno en estos casos es transformar las URLs en una serie de servicios para la interface, puntos de comunicación, sea REST, sea web services, si les gusta hacer parsing de XML sientansé libres de usar SOAP, pero básicamente lo que hace el back-end es una oferta de servicios y la interface es un consumidor de la oferta de servicios.

Les iba a mostrar la aplicación y resulta que el cambio de laptop hizo que la aplicación quedara en la otra sala. Básicamente es la misma aplicación que tenemos en la web, exactamente la misma interface, con una capa encima que está escrita en Javascript.

El punto más peludo cuando uno quiere convencer a alguien de ésto es que le dicen “¿Y la sincronización? ” Está bien que lo pregunte porque esta aplicación web en algun momento si la está usando diferente gente tiene que coordinar la información, como dije antes el server mantiene la informacion unificada … no es una cosa tan tremenda. Ponganse las manos en el corazón y piensen cuantos de los que hacen aplicaciones web acá piensan en la sincronización explícitamente. (…) Porque el término de sesión del usuario es bastante corto…

Una aplicación cuando está en modo offline la pueden considerar como una aplicación web que está en modo online pero donde la sesión es tremendamente larga (o puede ser que uno le ponga una duración determinada, digamos tus datos tienen duración de una semana, luego de una semana tus datos no pueden ser refrescados, es una deficion así… “stalinista” de cuánto puede durar tu sesión) o bien la sesión está abierta siempre. Básicamente si la aplicación offline pasa a modo online la sesión está viva nuevamente, y en ese caso sí hay que hacer sincronización.

Hay dos grandes estrategias para sincronizar: si uno empieza desde cero básicamente uno puede tener un storage de acciones -acciones son datos a pasar al servidor-, y hay frameworks que ayudan despues a reproducir todas esas acciones, pasarselas al servidor para que las ejecute, hacer como el replay de las acciones, no estoy hablando de apretar botones y cosas por el estilo, sino el agregado de un nuevo cliente, el borrado de un cliente…

El problema es que entonces tengo un modelo dual para almacenar porque tengo por un lado el almacenamiento de acciones y del otro el almacenamiento que necesito para el back-end mínimo para que funcione, porque si hay que hacer una consulta o bien tengo un almacenamiento separado para hacer consultas también offline o bien tengo que interpretar estas acciones que han quedado guardadas. Y el otro modo de sincronizar si hay una aplicación existente es básicamente guardar todo a tablas y usar las URLs existentes para comunicarse con el servidor, en este caso el servidor ni se entera de que la aplicación es una aplicación web online/offline , para el cliente es exactamente lo mismo que una aplicación web, en cuyo caso si existe un login el usuario se va a tener que volver a loguear, esa es la parte fácil, entonces hay que volver a tener la sesión. Lo que hacen todas estas cosas en realidad para que funcionen es que tienen básicamente una ventana con un browser adentro que no se nota, no es un browser, es un motor de HTML, es un web kit lo que tienen los dos, Google Gears y Adobe AIR. Por lo tanto la mayoría de la interaccion web que pasa automáticamente, como pedido de autenticación, si pasa en el browser pasa adentro de la aplicación web de por sí. La desventaja es que hay que hacer la sincronización a mano, hay que sacar de la tabla y hablarle a las URLs, la parte buena es que el servidor no se entera, por lo tanto el impacto en el servidor es nulo, que es lo que nosotros hemos hecho. Lo que hicimos es ponerle adelante una capa finita, la aplicación cuando pasa a modo online se convierte en otro cliente web igual que el cliente web que ya existía.

¿Qué son éstas bibliotecas? Una de las bibliotecas que existen es DOJO offline. Para los que no conocen, DOJO es uno de esos proyectos que trata de curar el sarampión, la caspa, todo… el problema es que el mismo remedio se usa para el sarampión, la caspa y el cáncer, con lo que es un poco complicado de aprender. Por suerte el pedazo offline en la última versión de DOJO está separado, entonces se puede usar separado, éste es el que hace esto de almacenar acciones y después mandárselas al servidor, la otra es simular los POSTs, el tipico POST de web, que es lo que hicimos nosotros, porque queriamos reusar la aplicación que ya estaba , no hicimos una aplicación desde cero. Una alternativa interesante es utilizar otro framework (…) que hay que usarlo del lado del servidor y hay que hacer una capa que se comunique con la aplicación web online/offline pero lo que tiene de interesante es que se encarga del problema de sincronización y unificación de datos ya existentes. Es un framework para el que no existe equivalente en Java, al menos no equivalente que se pueda bajar sin pagar mucha plata, hay algunos intentos con SyncML de los teléfonos que es el típico protocolo diseñado por comité, totalmente enorme, super-requete-diseñado para sincronizar cualquier cosa y que los clientes están hechos por la mitad…

Esto es así de sencillo lo de aplicaciones web online/offline.

¿Cuándo tiene sentido económicamente ésto? Tiene sentido cuando quiero crear una aplicación que funciona para un usuario que tiene que funcionar desconectado sin duplicar el costo de tener que hacer una aplicación de escritorio. ¿Se puede hacer? Sí. Nosotros lo hicimos y probamos que se puede hacer. De hecho se usa… La tecnología funciona, ahora ya Adobe AIR salió de beta, Google Gears está en un estado similar, se puede hacer… el truco está en la arquitectura de la aplicación, no en la implementación, la implementación es un problema transitorio para hacer esto. Haganló mal, hagan la arquitectura mal y esto les sale el doble; hagan la arquitectura bien y esto les sale mucho menos que hacer la aplicación de vuelta. A nosotros de hecho la mayor parte del tiempo que nos consumió fue aprender a hacer esta arquitectura por primera vez, y no escribir el codigo en sí mismo.

Yo creo que esto no es la solución al cáncer y la caspa, pero tiene su lugar en las aplicaciones, hay muchos usuarios que ya conocen aplicaciones web en las empresas y no tiene sentido económico hacerles un cliente desconectado que tengan que aprender de vuelta, no tiene sentido reproducir la interface, estas personas tienen un aumento de productividad si pueden trabajar desconectados cuando están de viaje, no sólo cuando tienen acceso a internet y en esos casos es en las empresas donde va a tener la aceptación mas grande, después existen otras compañías que ya tienen aplicaciones web y lo que tratan entonces es de penetrar en el escritorio, que es lo que hace Google con el perpetuamente inminente Google Writer y también con Google Docs que va a funcionar offline también. La idea de Google en este caso es penetrar en la dirección contraria a la que penetra Microsoft que va del escritorio hacia la web, la idea de Google es penetrar de la web hacia el escritorio…

Esto es sencillamente mi presentación, no les vengo a proponer ninguna tecnología revolucionaria sino algo que nosotros encontramos práctico y creemos que va a tener un impacto concreto. De vuelta: el punto está en la arquitectura, la parte tecnológica no es un problema, cuesta tiempo aprenderlo y una vez que uno lo aprende ya no…

Esta es mi presentación, rápida, cortita y eficiente. Esa es mi dirección de web, si tienen alguna pregunta por favor no duden en preguntarme, no soy de los que se encanutan los secretos, si es algo que yo sé se los voy a contar, sino lo peor que pueden recibir es un “no tengo ni idea”. Esa fue toda mi presentacion…

Publicado el 02/12/2008 dentro de la categoría eventos, tecnología | 3 Comentarios