Monday, March 14, 2016

Webcast Sinfonier Hackathon ETSIIT Granada

Los días 17 y 18 de febrero tuvo lugar el Hackathon de Sinfonier en la ETSIIT de Granada, y como no podía ser de otra forma antes de comenzar con los desarrollos se hizo una formación de la plataforma de Sinfonier y se presentó el reto.

Ahora se encuentra disponible el webcast de dicha presentación, para que sea más fácil iniciarse en el mundo de Sinfonier, así que os animo a verlo para empezar a trabajar con Sinfonier, o simplemente para recordar la participación en el Hackathon. Se puede visualizar el vídeo en el siguiente enlace.

De nuevo muchas gracias a todos los participantes por el trabajo realizado y por la actitud mostrada a lo largo del Hackathon.

Thursday, February 25, 2016

Compartiendo sesión entre módulos de Sinfonier

Cuando usamos algunos servicios o APIs necesitamos autenticarnos, para acceder a información privada, para contabilizar el número de llamadas en el caso de existir un rate limit por usuario, para que el proveedor del servicio se asegure que no se abusa del mismo por bots, etc.

Autenticación mediante Token

El proceso de autenticación puede ser simplemente mediante un token, el cual se incluye en cada petición y el servidor, tras comprobar que es un token válido y que tiene permiso al recurso solicitado, devuelve la información. En Sinfonier tenemos muchos módulos que utilizan este tipo de autenticación, por ejemplo los módulos que interactúan con Twitter o el drain de Telegram.

El Drain de Telegram tiene un parámetro token para autenticarnos

Autenticación con sesión en un módulo

Pero hay otros servicios que utilizan un proceso de autenticación más "sofisticado", y requieren del uso de sesiones . Las sesiones son persistentes en el tiempo. Nos autenticamos una vez, normalmente con con un usuario y contraseña, almacenando la información de la sesión en una variable. Posteriormente, usando esa variable podemos realizar llamadas al servicio o API sin tener que enviar un token ni nada parecido cada vez.

En Sinfonier tenemos algunos módulos que gestionan su propia sesión y las usan para realizar llamadas dentro del propio módulo. Por ejemplo el módulo de Google Alert. Si vemos su código fuente (en Java), vemos como recibe una cookie del servidor y usa esta cookie para realizar las llamadas posteriores, manteniendo con ella la sesión.

Fragmento de código donde recibe la cookie y hace uso de ella (módulo Google Alert)

Autenticación con sesión compartida entre módulos de la misma topología

En el caso del Spout de Google Alert la sesión se inicializa y se usa dentro del módulo. Se nos han dado otros casos donde necesitamos compartir una sesión entre varios módulos. Esto puede ser porque tengamos un acceso mediante usuario contraseña, el proveedor no nos permita tener más de una sesión activa a la vez y nosotros necesitemos hacer llamadas al servicio desde varios módulos, en la misma topología. 

La forma de solucionarlo es crear la sesión una vez y compartirla entre los módulos. Esto lo haremos serializando la sesión e insertándola en forma de String en un campo de la tupla (JSON) que se envía de módulo a módulo.

Vamos a ver un ejemplo, en Python, usando las sessions de la librería requests y serializando con cPickle (más rápido que pickle). La serialización nos permite almacenar como un String una variable completa y usarla en otro proceso diferente.

Primero necesitamos en la que autenticarnos y posteriormente hacer una petición que nos devuelva datos solo si estamos autenticados. Usaremos https://httpbin.org/, un genial recurso para probar peticiones web. En nuestro caso vamos a usar la llamada siguiente para la autenticación (el User Name es user y la Password es passwd):

http://httpbin.org/basic-auth/user/passwd

Si abrimos la URL con el navegador, vemos que nos pide autenticación

El esquema de la topología de prueba será el siguiente:

- Bolt BasicSession que utiliza los parémetros user y password para crear una session y almacenarla en el campo session.
- Bolt GetWithSession que realiza una petición GET al recurso especificado por parámetro, usando la sesión almacenada en la variable especificada también por parámetro.

Podéis ver el código de ambos módulos, para comprender el proceso, en su gist correspondiente. Es bastante sencillo.

Aparte, usamos el Spout Dummy para iniciar el flujo de tuplas en la topología, el Bolt JavaMultiTrim para solo mostrar de campo de salida el responsejson que devuelve GetWithSession, para evitar mostrar la session completa en el log (ver apartado de abajo Seguridad).

Y por último el Drain LogIt, para ver el resultado en el log.

Topología de prueba para compartir la sesión entre módulos

Si lanzamos la topología, vemos que la respuesta del servidor ha sido de autenticación correcta, por lo cual la sesión se ha compartido correctamente entre los dos módulos :)

Respuesta del servidor en el log:

2016-02-25 12:01:22.628 c.s.d.BaseSinfonierDrain [INFO] {"responsejson":{"authenticated":true,"user":"user"}}


Autenticación con sesión compartida entre módulos de distintas topologías

Este proceso sería un poco más complejo, pero en esencia es igual que en el punto anterior. Simplemente serializamos la variable de sesión y la almacenamos en un recurso externo, como puede ser una base de datos MongoDB externa. No detallaremos el ejemplo completo, así podéis intentarlo vosotros ;)

Seguridad

Tenemos que tener en cuenta que al compartir la sesión la estamos moviendo por sitios diferente a su ubicación original, en la memoria del proceso donde se haya inicializado, y por tanto abriendo puertas a que los malos nos la roben.

Hay que tener cuidado con los logs de la topología, donde debemos procurar no hacer un print del campo que almacena la variable de sesión, y con los accesos al MongoDB donde guardemos las sesiones, en el caso de compartirla entre distintas topologías.

Friday, February 19, 2016

Resultados Hackathon Sinfonier ETSIIT Granada



Ayer finalizó el Hackathon de Sinfonier que se celebró durante dos días en la ETSIIT de Granada, del cual salimos con muy buenas sensaciones.

El primer día como habéis podido ir viendo en las redes sociales estaba dedicado a explicar la herramienta de Sinfonier, presentar el reto y hacer que todos los asistentes saliesen con el entorno listo para poder desarrollar el grueso del reto al día siguiente.

Ayer fue el día duro de trabajo, en un sólo día los concursantes se enfrentaban a una nueva herramienta para ellos, teniendo que empaparse en la medida de lo posible de ella y conseguir desarrollar algunos de los módulos propuestos. Además también tendrían que desarrollar un posible caso de uso que se pudiese materializar en una topología, aunque ésta no estuviese del todo terminada.

Al finalizar el día varios equipos entregaron sus desarrollos y tras un complicado proceso de evaluación por parte de los organizadores, los premiados fueron:

1º Israel Blancas Álvarez
2º Ignacio Cordón Castillo

Además, por sorpresa se decidió entregar un tercer premio por las fotografías aportadas en las redes sociales que fue para uno de los grupos participantes, formado por Juan Antonio Velasco Gómez, Antonio Solís Izquierdo y Javier Pérez García.

Desde la organización solo nos queda dar las gracias a todos los asistentes y en especial a todos los que os quedasteis hasta el final entregando vuestras propuestas. Nos vamos con muy buenas sensaciones y con muchas ganas de volver a veros, así que como os hemos repetido en el trascurso del Hackathon, no os olvidéis de mandarnos vuestro CV si os ha gustado lo que os hemos contado.

¡Gracias chicos!

Wednesday, February 17, 2016

Reto Hackathon de Sinfonier en Granada

Como se ha explicado en la conferencia/presentación del reto que ha tenido lugar hace un ratito, en esta ocasión el título del reto es "Volatilidad, Persistencia y Representación".

El objetivo de este reto es poder realizar búsquedas dentro de redes sociales y de gestores de archivos, para así poder modelar una base de datos con los resultados obtenidos, permtiendo estudiar la evolución de los diferentes elementos recuperados. Además también se propone representar los datos obtenidos dentro de una base de datos de grafos para poner ver las relaciones entre ellos.

Pero sin más dilación las redes sociales sobre las que se va a trabajar son: Facebook, Linkedin y Archive.org. Para trabajar con ellas se han considerado una serie de aproximaciones.

Facebook

  • Facebook API
  • Simulación de login
  • Sin Login ni API
Linkedin
  • Peticiones web (sin login)
Archive.org
  • API
  • Peticiones web
Las puntuaciones detalladas se pueden consultar en el siguiente enlace.

En principio sólo se aceptan a concurso las soluciones que estén contempladas dentro de las puntuaciones, en caso de que algún participante tenga ideas de otros módulos lo ha de consultar previamente con la organización para que pueda determinar si ese módulo se podría aceptar.

También recordar que el desarrollo de módulos se ha de realizar utilizando la máquina virtual que se ha proporcionado y una vez los módulos sean funcionales se han de subir a la comunidad de Sinfonier para que puedan ser evaluados.

Para facilitar la entrega de resultados se ha elaborado una plantilla del excel que se debe entregar cumplimentado.

Monday, February 15, 2016

Cambio de ubicación Hackathon ETSIIT

Hoy estamos de enhorabuena! habéis conseguido desbordar nuestras previsiones de participación en el hackathon de la ETSIIT de Granada. Ya somos más de 90!

Por este motivo hemos cambiado el lugar de celebración del hackathon a un espacio más grande: el Salón de Actos de la propia ETSIIT. (UPDATED)

Aquí os dejamos el cartel definitivo.

Comparte esta  publicación y ayúdanos a llegar a 100!



Thursday, February 11, 2016

Bases Hackathon Sinfonier Project en la ETSIIT de Granada



Como hemos ido anunciando desde hace unas semanas los días 17 y 18 de febrero tendrá lugar un Hackathon de Sinfonier en la ETSIIT de Granada.

Recordar que para poder participar en el Hackathon es necesario inscribirse previamente, y es recomendable completar el registro en la plataforma de Sinfonier aceptando la invitación que recibiréis al hacer la inscripción, en caso de no recibir la invitación no dudéis en contactar con nosotros a través de info@sinfonier-project.net.

Las bases que regulan la participación en el de hackathon las podéis consultar aquí.

Tuesday, February 02, 2016

Development VM - Support Python exceptions

En anteriores entradas del blog (enlaces abajo) hemos explicado el funcionamiento de la máquina virtual de desarrollo de Sinfonier. Esta máquina virtual viene con un entorno Eclipse que nos permite desarrollar los módulos de forma más rápida que usando la Comunidad-Drawer. Una vez los tenemos listos, ya podemos subirlos y usarlos con nuestras topologías.

Sinfonier Development Virtual Machine
Sinfonier Development Virtual Machine, parte II

Uno de los problemas conocidos que teníamos en este entorno, es que cuando un módulo en Python, ya sea Spout, Bolt o Drain, daba un error (Exception), la ejecución se paraba sin mostrar nada en la consola, y por tanto no podríamos averiguar qué ocurría.

Esto ha sido solucionado. Ahora cuando hay una excepción en la ejecución se muestra la traza de Python en la consola de Eclipse.

Código de Bolt de prueba para generar una Excepción


Excepción en la consola de Eclipse

Para actualizar la máquina virtual con los nuevos cambios del código, hay que hacer un Pull del repositorio que viene configurado en Eclipse.

Pull del repositorio sinfonier-dev-tool