De vuelta en el Mashup Camp

En Julio del año pasado asistí por primera vez a un Mashup Camp. Fui más de observador que de otra cosa, al igual que mis compañeros Wei y Juan.

Sin embargo, este año las cosas han cambiado. Hemos cogido el toro por los cuernos, y hemos ido a por todas.

Un Mashup Camp es una "unconference" y una competición. En cuanto a la "unconference", se llama así porque no hay una agenda previamente fijada. En la primera sesión del primer día uno se puede levantar, coger el micrófono, decir lo que quiere comentar, discutir, etc., y plasmarlo en la agenda. Así de simple. Y os aseguro que el nivel general de las presentaciones y discusiones no tiene nada que envidiar a las de las conferencias más estándar.

En cuanto al concurso, también es abierto, y permite que cualquiera pueda competir mediante la elaboración de un "mashup" (una combinación de datos procedentes de otros sitios web o fuentes de datos, de manera que el resultado aporte mayor valor al usuario). Los jueces son los propios participantes: cada uno de ellos tiene un "níquel de madera" que puede ofrecer al mashup que más le guste. El que más níqueles acumule, pues ese gana.


Los dos primeros días, lunes y martes, son más parecidos a una conferencia clásica. Es lo que se denomina "Mashup University" (Universidad Mashup), y hay charlas de los patrocinadores y, en este caso, de un profesor de Berkeley, Raymond Yee, que impartió dos de introducción a este nuevo concepto.






==========================================================

La "chicha" está el miércoles y el jueves. La primera sesión del miércoles es donde los propios participantes se levantan de sus asientos y proponen las sesiones.

En este enlace podéis ver las charlas de este año. Debido a que nos presentábamos al concurso y propuse una charla, no tuve mucho tiempo para asistir a otras discusiones. Pero sí a alguna.













Primero, a la que impartía Stefan Andreasen, fundador y CTO de Kapow, sobre la utilidad de la utilización de programas de acceso a la web para la obtención de la información. En un mundo en el que cada vez se ofrecen más APIs de acceso, ¿qué sentido tiene el seguir utilizando "web scrapers"? En este caso tenía que estar de acuerdo con Andreasen (aunque esté en una empresa que podemos considerar competidora en algunos casos). Hay cientos de miles, o millones de páginas web con información útil que no ofrece ningún tipo de API de acceso. Por otra parte, hay intranets que ofrecen acceso a repositorios de información que pertenecen a departamentos que no van a permitir el acceso directo a esas bases de datos. En otros casos, va a ser más fácil acceder a través de la web que utilizando complejas APIs, ya que la web modela los procesos más típicos que realizan los usuarios. En definitiva, el único punto a considerar es para qué se quiere utilizar esa información, e incluso en este caso muchos proveedores de datos ya se están dando cuenta de que su información tiene mucho más valor si se permite extraer. Por supuesto, todo de manera muy genérica, ya que hay que tener mucho cuidado en este aspecto.


La otra charla a la que asistí fue el jueves por la mañana, sobre Open Social, el API liderado por Google para la estandarización de las redes sociales. No pude estar todo el rato, pero me pareció interesante que en pleno Mountain View, cuna de Google, Chris Radcliff expusiese los problemas principales que le ve a Open Social (básicamente: no es demasiado social, ya que no permite fácilmente la utilización de perfiles por parte de diferentes aplicaciones). Me queda mucho por leer sobre este API, y esta charla me ha "dado sed" :)

¿Y la nuestra? Pues la llamé "Crossing the Mashup Chasm: Requirements for Enterprise Mashups".




En breve subiré un resumen a la página del mashup camp, pero se puede decir que veo tres puntos de vista con respecto a lo que es un Enterprise Mashup y hacia dónde ha de ir:
  1. Un mashup es el mismo nombre para tecnologías previas. Así de claro lo dijo un tío de BEA. Claro que luego empezó a decir que ETL, Data warehouse, EII, ... es todo lo mismo. Ese fue el momento en que perdió todo punto de credibilidad... tanto, ¡¡¡que se fue de la charla!!!
  2. Un enterprise mashup permite a los usuarios de negocio el poder obtener soluciones a más corto plazo. Son soluciones intermedias, más baratas y más flexibles.
  3. Un enterprise mashup permite, además de soluciones más baratas y flexibles, participar en la infraestructura de datos core de la empresa en aquellos casos en los que la integración de información ha de ser en tiempo real.
Mi postura era, claramente, la del punto (3), entendiendo también la necesidad del (2). En general, los asistentes creían más en el segundo punto, aunque espero que tras nuestra charla, hayan cambiado un poquito de opinión :)

Por otra parte, estaba el concurso. Los últimos días fueron un poco infierno, sacando tiempo de las piedras para tener lista una aplicación que integrase información de diferentes fuentes. Esta conferencia no era la más adecuada a nuestros "intereses", pues ya antes de empezar sabíamos que el público tendería a votar a aplicaciones de usuario, no a aplicaciones de negocio. Aún así, nuestra intención no era tanto la de ganar (que si se podía, pues bien :) ), sino que de una vez por todas se conociese nuestra tecnología en este mundillo de "geeks" del Silicon Valley. Creo que lo hemos conseguido, incluso la aplicación llamó la atención a algunas personas :)

¿Que qué hicimos? Pues un mashup que combinaba datos de LinkedIn, Salesforce, bases de datos internas, el servicio Google de coordenadas geo y GoogleMaps, para mostrar una lista ordenada de contactos obtenidos de LinkedIn, teniendo en cuenta si esos contactos ya existen en nuestra cuenta de Salesforce, y, si no es así, cómo de fácil es contactar con ellos. Por ejemplo, si yo quiero contactar con Pepe, LinkedIn me dice si tengo algún acceso directo a él (p.e. a través de María y de Juan). Si tengo a Juan en mi lista de contactos de Salesforce, puedo saber si es un buen contacto y, por tanto, si puedo llamarle para "pedirle el favor" de que me ponga en contacto con Pepe. Por otra parte, si me llevo mal con María, el mashup me avisará de ello para que no cometa el error de llamarla (¡para que ella no llame a Pepe diciéndole que no me coja el teléfono! :) ). La información la mostrábamos como una lista ordenada, y como datos en un mapa de Google.

Por cierto, que LinkedIn me ha bloqueado durante unos días por, según comenta, incumplimiento de sus condiciones de servicio. Es una señal inequívoca de que, una de tres:
  1. Están a punto de sacar su API, y no quieren que herramientas de acceso a su web le quiten el protagonismo.
  2. Todavía están temblando por su reacción cuando Plaxo accedió a su web para promocionar su nueva versión.
  3. No se han enterado todavía de que los mashups pueden hacer su producto aún más interesante.
Espero que sea el primer caso. Si no, LinkedIn va a tener problemas, y usuarios descontentos.

En definitiva, una semana que me ha dejado exhausto (de ahí el tiempo que hacía que no escribía en el blog), pero que ha merecido claramente la pena.

Comments

Anonymous said…
Joder, Justo, me ha parecido la mar de interesante.
Algún día que te pases por aquí (o nosotros por ahí) podías contarnos lo que haces por si vemos enlaces entre monitorización y datos externos en servicios web. Quizás pueda ser interesante monitorizar y recibir avisos si alguien de una empresa cuya web utiliza mashups de ACME ha añadido como contacto en Xing a otro que se dedica a las bases de datos y además son contactos míos de como mucho tercer orden... no sé.
Justo Hidalgo said…
Je je, le damos una vuelta a esa idea y nos volvemos a presentar el año que viene :) Pero, ahora en serio, el rango de posibilidades que ofrece la integración de información pública y privada, en diferentes niveles de abstracción, es impresionante. Piensa, en tu caso, en qué información añadida podrías ofrecer al usuario cuando se produce una notificación o una alarma... ¿podrías acceder a la base de conocimiento del router que ha provocado el fallo para devolver las razones más típicas de ese error? ¿Podrías ligar eso con información sobre el cliente que está sufriendo ese problema para priorizar su alarma si es algo que sufre constantemente? A partir de ahí, la imaginación es el límite...

Popular Posts