miércoles, 29 de junio de 2011

Twitter – La Integración Obligada

Para nadie es una sopresa las miles de herramientas y mecanismos de publicación que hay para Twitter. Aún así, intenté armar un proyecto para entender cómo es que funciona la API de integración de Twitter y, además, poder hacer una aplicación a la medida para las pocas publicaciones que realizo. En mi caso, la idea es construir una mini-aplicación que permita la publicación de un Tweet con un solo click y que me permita evitar el proceso (engorroso a veces) de abrir el browser, ingresar a Twitter, autenticarse, publicar, salir, etc.

La API está perfectamente documentada y es simple entender. En términos simples, el proceso para poder construir una aplicación es el siguiente:

  1. Registrar la aplicación.
  2. Construir la aplicación.
  3. Autorizar la aplicación para que pueda publicar a nombre de un usuario.
  4. Publicar un Tweet de prueba.

A continuación se describen los pasos anteriores.

1. Registrar la Aplicación.
El proceso de registro de la aplicación está destinado a, como su nombre lo indica, registrar la aplicación para hacer uso de la API. Esto es similar al AppStore de Apple en términos que las aplicaciones deben estar registradas, sin embargo, Twitter no provee un mecanismo para buscar y/o recorrer las aplicaciones ya existentes. Como yo no encontré la aplicación que quería, la tuve que hacer así que comencé con el proceso de registro. Para registrar una aplicación hay que acceder a la página de Registro de Aplicaciones. Realizado la autenticación, esta página despliega todas las aplicaciones ya registradas y permite agregar nuevas. La pantalla de registro es como la siguiente:

Twitter.RegisterApp.02

Lo más complejo es la elección del nombre de la aplicación (marcado en Azul) ya que, al igual que los nombres de dominios, están casi todos ocupados.

  • El Tipo de Aplicación (Application Type) indica si la aplicación es de escritorio o web. En el segundo caso, se debe indicar la URL a la que Twitter traspasará el control (Callback) una vez que termine el proceso de autenticación y autorización.
  • El Tipo de Acceso (Default Access Type) indica el tipo de acceso por defecto que se le solicitará al usuario al momento de la autorización.

Terminado el proceso de registro de la aplicación, Twitter entregará un token de acceso (Access Token) que contiene dos llaves únicas que identifican a la aplicación. Estas llaves son el Access Token (oauth_token) y el Access Token Secret (oauth_token_secret). El token de acceso identifica a la aplicación y, por lo tanto, debe ser protegido por el autor para mantenerla bajo su control. El protocolo utilizado por Twitter para hacer la autenticación es el estándar de autenticación OAuth.

2. Construir la Aplicación.
Registrada la aplicación, es necesario construirla. Para esto, obviamente, hay mil alternativas de lenguajes y de bibliotecas. Para este ejemplo, la aplicación será construída en VB.net y será una aplicación de escritorio (Desktop). Las bibliotecas disponibles para cada lenguaje se pueden revisar en la página de bibliotecas, Twitter Libraries.

Para la aplicación, utilizaré la biblioteca TwitterVB. Esta biblioteca tiene todos los métodos de integración con Twitter ya implementados, por lo tanto, se hace muy fácil integrarla a un proyecto existente.

La pantalla principal de la aplicación es como muestra la imágen siguiente. En términos simples, es una ventana que debiera omitir todos los detalles de autenticación y permitir elegir la cuenta de Twitter con la que se desea publicar. Para lograr esto, como revisaremos en el punto siguiente, es fundamental que el proceso de autorización de un usuario a una aplicación persiste en el tiempo.

Twitter.MainForm

3. Autorizar la Aplicación para Publicar a nombre de un Usuario.
El proceso de autorización de una aplicación consiste básicamente en realizar la secuencia para obtener las llaves secretas de autorización del usuario para la aplicación. El código siguiente muestra la secuencia anterior:

Twitter.Source.Link

Los pasos conceptualmente son:

a) Solicitar la página (URL) de autorización del usuario para la aplicación. La URL de autorización es como la siguiente:
http://twitter.com/oauth/authorize?oauth_token=RwcHZJHKshgdkahskwer7khkaasdfHKH

b) Abrir el browser en la página anterior para que el usuario realice el proceso de autorización. Como resultado de este proceso, el usuario deberá identificarse y obtendrá un PIN (Número de Identificación). El PIN es un número como el que se muestra a continuación:

Twitter.Auth.02

c) Recuperar el PIN desde el usuario.

d) Validar el PIN del usuario y recuperar las llaves de la autorización. Las llaves que se obtienen del proceso anterior son dos llaves que se llaman TokenKey y TokenSecret que se ven como sigue:

TokenKey = 177061323-9iPOqWwp9IhFEHN3bTvehjkHGJKJHGhjghghgjHGHGJk3qBtSWI
TokenSecret = 3neRlNafAPgKQBR5sv05Eq6MMhjyHGGTYUHysig

Con la autorización realizada, la aplicación está en condiciones de enviar Tweets a nombre del usuario. Una de las gracias de este mecanismo es que las llaves anteriores son únicas (obviamente) y no cambian en el tiempo. Esto implica que, una vez realizada la autorización y obtenidas las llaves, la aplicación podrá realizar la publicación de Tweets sin necesidad de repetir el proceso de autorización, a menos que el usuario cambie sus preferencias.

4. Publicar un Tweet
La publicación de un Tweet comprende la autenticación en Twitter de la aplicación a nombre del usuario (por medio de las respectivas llaves) y luego enviando el Tweet. El código siguiente muestra la secuencia anterior:

Twitter.Source.Post

Los pasos conceptualmente son:

a) Autenticar en Twitter la aplicación a nombre del usuario utilizando las llaves respectivas, es decir, las llaves de la aplicación y las llaves de la autorización del usuario para la aplicación.

b) Enviar el Tweet!.

c) Al enviar el Tweet! se obtiene un número que identifica la publicación y que puede ser utilizado para eliminar (deshacer) la publicación desde la aplicación.

Lo anterior es sólo un ejemplo de cómo utilizar la API en donde, lo fundamental, es tener claridad sobre el proceso de registro y posterior autorización de una aplicación para permitir realizar los Tweets.

Adicionalmente, Twitter provee otros métodos en la API que permiten recuperar el Timeline, los Seguidores, etc.

jueves, 23 de junio de 2011

Un Viaje en el Tiempo

Ayer tuve la oportunidad de asistir a la cena anual de la ACTI. Similar a otras ocasiones, la agenda es más o menos la siguiente: bienvenida, discursos varios, premiaciones a empresas y regalos a asistentes. Uno de los regalos, esta vez, fue un celular LG Optimus 2X de última generación. Lamentablemente, no me lo gané.

Hubo tres discursos. El primero del Sr. Jeffrey Cole invitado de USA y representante del Center for the Digital Future. El segundo del presidente de la ACTI, Sr. Raúl Ciudad y, el último, del Ministro de Economía, Sr. Juan Andrés Fontaine.

En términos generales, los discursos fueron bastante planos sin muchos elementos nuevos o que no hayan sido mencionados muchas veces antes. Algunas de las ideas fuerza que se mencionaron en los últimos dos discursos fueron:

  • Chile país desarrollado en el 2018
  • Computadores para todos los colegios de Chile
  • Banda Ancha debe ser un derecho... todos los ciudadanos debieran tener acceso a velocidades y precios adecuados
  • Es necesario fomentar el emprendimiento
  • Es necesario apoyar el I+D nacional

¿Parece familiar alguna de estas frases?
¿No parece un Déjà vu, un viaje en el tiempo y lo mismo que se viene discutiendo hace 10 años?

Desde que yo hacía clases en la universidad que vengo escuchando este tipo de declaraciones mientras hacíamos esfuerzos para vincular al DCC con la empresa por medio del curso CC61A – Proyecto de Software.

El miércoles fui a otro seminario llamado emprendeTIC destinado a promover el espíritu emprendedor. Uno de los oradores de InnovaChile, Adrian Magendzo, hizo una presentación espectacular (yo no lo había visto antes) y, al final, uno de los asistentes le dijo:

- "Adrián... he asistido a todas tus charlas en los últimos dos años y, aparte de felicitarte por lo bien que lo haces, debo decirte que es lo mismo ¿Me puedes realmente decir qué cosas nuevas está haciendo Corfo para apoyar al emprendimiento?”

Al margen que no comparto la manera, el mensaje era claro. Adrián respondió la pregunta bien y agregó algunas cosas nuevas.

Pero el tema de fondo yo creo que es que falta marketear (y mucho) las cosas buenas que se están haciendo. Creo que ya hay suficientes ejemplos de personas que están haciendo cosas importantes e interesantes en Chile, a menor escala, y que son ejemplos a seguir y no continuar, permanentemente, con el discurso de lo que tal vez habría que hacer. Creo que es necesario creerse el cuento, un pasito a la vez, y no esperar que de un día para otro aparezca algo como los ya clásicos ejemplos: Facebook, Google, etc.

Esto es muy parecido a la discusión de las "competencias" de hace 10 años... aún siguen apareciendo gurús que dicen "hay que hacer un modelo de competencias" y, bueno, se echa a andar la bolita nuevamente.

Otra cosa que me pareció sorprendente fue el premio entregado a Enlaces. No tengo nada encontra del proyecto, al contrario, conozco a varias personas que han estado muy involucradas en ese proyecto, pero, me parece que no se puede premiar en el contexto de un discurso sobre la innovación y el emprendimiento, un proyecto que ya lleva más de veinte años en ejecución. Lo que correspondía, en caso de haber sido necesario, era un premio al reconocimiento o similar, pero no un premio a la innovación.

viernes, 17 de junio de 2011

Mundo Touch

Mi primer contacto con computadores y/o dispositivos de juegos fue por el año ochenta. En ese momento, los ejemplos más cercanos eran el Atari 2600, Intellivision, ColecoVision y Sega. En el ámbito de los computadores eran el Commodore 64, Sinclair y Texas Instruments y, en mi colegio usaban computadores BBC Micro para enseñar Basic. Siendo un niño, para mí era sencillamente incomprensible y a la vez fantástico, la posibilidad de controlar con un joystick algo en pantalla y hacer que se moviera, saltara, disparara, etc. Los juegos que recuerdo más importantes eran el Q*Bert, PacMan (y toda su parentela), PitFall y PitStop, todos ellos provistos por mi mejor amigo ya que yo no tenía uno.

En ese momento, estar frente a la televisión jugando horas era algo impensado. Yo, y muchos de mis amigos, no teníamos incorporada esa variable, por lo tanto, era un juego más. Jugábamos un rato y luego volvíamos a nuestros juegos típicos. Aún así, a veces, la frustración nos atacaba y lo más perjudicado era el hardware asociado, es decir, la consola, los otros cartridges, los joystick, etc. Recuerdo especialmente que los joystick de Atari aguantaban todo, nunca me tocó ver uno destruído.

Han pasado algunos años desde ese momento y mis intereses y mi relación con la tecnología ha cambiado. Hoy trabajo con computadores todos los días por lo que, mirando hacia atrás, creo entender qué es lo que sucedia cuando movíamos el joystick y el monito pixelado saltaba o corría y, no dejo de sorprenderme, cómo eso sucedia con las infinitas restricciones de recursos y lenguajes que había en esas máquinitas. Pero, obviamente, el hardware de hoy no tiene nada que ver con el hardware de ese entonces. Hoy los computadores tienen discos duros, pantallas LCD (ya no se usa el televisor), son ultradelgados, etc., y, la tendencia más importante desde la incorporación de las cámaras a los celulares, es hacer todos los dispositivos touch copiando la tendencia establecida por Apple con el iPod, iPhone e iPad.

Dado esto, el otro día estaba intentando hacer una llamada con mi iPhone. Para los que tienen iPhone (o tienen plan con la compañia *********), deben haber experimentado la pérdida de señal habitual y, la mucho peor, latencia (demora) en la recuperación de la misma. Yo no tengo claro si es un problema del hardware o de la señal o de los dos, pero, es realmente irritante cuando sucede. Tanto así que el otro día necesitaba hacer una llamada urgente y no pude hacer que el teléfono recuperara la señal durante un buen rato. Surgió dentro de mi, como una explosión, el recuerdo de mi infancia y estuve a punto de golpear el teléfono con mi puño, tirarlo al suelo, etc., para lograr canalizar de alguna manera mi rabia. Lamentablemente, mi racionalidad me lo impidió por las consecuencias obvias que eso tendría sobre el teléfono.

Hay una frase que refleja esta situación a la perfección pero que, en este mundo cada vez más touch, no aplica lamentablemente:

Hardware = Lo que golpeas. Software = La causa”

Símplemente, habrá que buscar otros mecanismos para canalizar la rabia en estas situaciones.

martes, 14 de junio de 2011

WebServices… ¿La solución a todos los problemas?

Como es habitual, me toca asistir a muchas reuniones para revisar, evaluar y proponer soluciones para la integración entre los sistemas del cliente y los productos de Paperless. Una reunión de este tenor, casi siempre gira en torno a buscar la mejor manera (más barata, de menor impacto) de lograr que los dos sistemas conversen y/o intercambien información. Adicionalmente, típicamente el sistema del cliente es un sistema antiguo y/o en operación (la manera elegante de decir que ya está estable), por lo que cualquier intención de tocarlo o modificarlo es liquidada rápidamente. Claramente, la opción más natural es adaptarse a cualquier tipo de salida y/o esquema de integración ya existente.

En mi experiencia, cada cliente tiene una realidad particular que impide enfrentar este tipo de problemas con una oferta de interfaces estándar. Por tal razón, mi visión, es la de ofrecer diversos esquemas más o menos conocidos y comenzar a evaluarlos con él. Según el perfil con el que se realice la reunión, ésta puede ser una reunión exitosa (desde el punto de vista de encontrar la mejor solución) o un fracaso (en caso de no encontrar una salida). En general, el desafío es encontrar la alternativa más concreta y eficiente para la integración, es decir, aquella para la cual el cliente tiene algún tipo de conocimiento y/o expertise, tiene la tecnología, los recursos, etc. Muchas veces he visto proyectos de integración en los que se deciden estrategias entre cuatro paredes y, al intentar implementarlas, los problemas son infinitos.

En este contexto, los WebServices han pasado a convertirse en un salvavidas de dominio público, desde mi punto de vista, nunca antes visto. En muchas reuniones en las que me ha tocado participar y después de estar un buen rato buscando la alternativa correcta, aparece un iluminado (A) que, sin tener la más mínima idea de lo que significa, hace su gran aporte:

- ¿Y si hacemos un WebServices? – nótese la ‘s’ al final, fundamental para identificar este perfil.

Lo más simpático de esta situación es lo siguiente:

  • Posicionamiento. Casi inmediatamente A sube de rango entre sus pares. Pasa a ser un referente, el experto en integración. La persona que sabe y que va a resolver todos los problemas.
  • Optimismo. Los problemas de integración se terminan. Mágicamente, la palabra WebService se convierte en un salvavida, algo así como un WD40 que permitirá desentrabar la integración y avanzar y, en los casos más extremos, se concluye que este es el mecanismo de integración y la reunión avanza hacia otras problemáticas.

Desde el punto de vista de la integración vía WebService, ésta requiere dos componentes:

  • WebService. El WebService propiamente tal. Es un punto de entrada expuesto, típicamente, desde un servidor web hacia el resto del mundo. La
  • Consumidor. El cliente que consume (usa) el WebService. Esta, probablemente, es una de las ventajas más grandes de esta tecnología y es que, actualmente, existen diversas bibliotecas integrables a nivel cliente que permiten hacer uso cualquier WebService fácilmente. Visual Studio provee herramientas visuales para incorporar referencias a un WebService. Java posee la herramienta wsdl2java que permite hacer lo mismo y, para los otros lenguajes, hay muchas alternativas para lograr lo mismo.

Considerando lo anterior, es fundamental tener presente que la integración vía WebService no es bidireccional por naturaleza. Esto implica, básicamente, que si se desea que dos sistemas, S1 y S2, puedan intercambiar información, se requiere que S1 implemente un WebService y S2 también y, a su vez, S1 consuma el WebService de S2 y vice versa. Lo importante de esto es tener claro cuál es el objetivo de la integración. Por ejemplo, si se tiene un sistema legacy que no posee una implementación para publicar un WebService, sería absurdo proponer esta tecnología como esquema de integración bidireccional.

Mi experiencia personal es que los WebServices son una alternativa más de integración, no son necesariamente la única ni la mejor, como muchas personas hoy en día sienten. Esta es una situación similar a lo que pasa con el XML en que cualquier cosa, en formato XML, pasa a ser “estándar” y cumplir con las buenas prácticas de uso de esta tecnología. En este contexto, ejemplos me sobran.

lunes, 6 de junio de 2011

Los Piropos

El otro día encontré estos piropos absolutamente nerds, que creo pueden ser útiles para aquellos que andan en plan de conquistar a alguien:

- ¿Tu nombre es Google? Porque tienes todo lo que ando buscando.

- ¿Crees en el Orígen? Porque estás en mis sueños.

- Si yo pudiera ser una enzima, sería el DNA – Helicasa de manera de abrir tus genes.

- ¿Eres un ángulo de 90 grados? Porque estás perfecta.

- Me gustaría fueras Banda Ancha para tener acceso ilimitado.

- ¿Tienes un fantasma en tus pantalones? porque estás de miedo.

- Yo soy el estudiante y tú eres mi libro de matemáticas… me resuelves todos mis problemas.