En el mes de marzo va a hacer un año que hice de Python  mi lenguaje de programación predeterminado y creo que tomé una buena decisión. Me encanta programar en este lenguaje, me cunde mucho el  trabajo y puedo resolver cualquier duda en su documentación o en las experiencias de sus entusiastas seguidores.

Todo empezó cuando Norberto, Fernández compañero de mi grupo de investigación, publicó este tweet

Google's Python Class: a free class for people with a bit of programming experience who want to learn Python http://tinyurl.com/yejg432

March 23, 2010 23:29 via webReplyRetweetFavorite

@nordez

nordez

Inicié el curso por la mañana y por la tarde ya había hecho los ejercicios. Al día siguiente empecé a programar las herramientas que usé en el experimento de Manifiesto. Nunca  había tenido una curva de aprendizaje tan rápida con un lenguaje de programación.

El curso de Google es muy básico pero te da ese mínimo que te permite empezar a programar. Las dudas que no me resolvía este curso las solventaba rápidamente consultando la documentación. Cuando ésta  no era suficiente bastaba buscar en Google “how to…. in python” y ¡voilà!, encontraba la respuesta.

Una de las páginas Web que me han ayudado en conocer más a fondo este lenguaje de programación es mundo geek, un blog escrito por Raul González Duque, ex-alumno de la Universidad Carlos III y autor también de un tutorial de Python.  En un post (Java vs. Python) de su blog encontré con esta cita, con la que estoy totalmente de acuerdo:

Tengo la impresión de que Java fue diseñado para hacer que fuera difícil escribir mal código, mientras que Python está diseñado para hacer que sea sencillo escribir buen código.

– Magnus Lycka

Otra de las características de Python es el humor, no en vano su nombre proviene de los míticos  Monty Python’s.

By the way, the language is named after the BBC show “Monty Python’s Flying Circus” and has nothing to do with reptiles. Making references to Monty Python skits in documentation is not only allowed, it is encouraged!

No voy a repetir por qué es tan bueno Python, en su página ya lo explican estupendamente. Pero si además se quiere hacer la prueba del nueve: solo hay que buscar información sobre él y  se aterrice donde se aterrice, siempre se encontrará el latido del entusiasmo.

Resumiendo: Python hace de la programación un placer. I ♥ Python y muchos más también

Actualización 20-10-20110:  La grabación de la primera jornada del Taller  disponible aquí

Ayer por la tarde nos reunimos en CAMON Madrid unos cuantos entusiastas de la visualización. Como era de esperar ha sido grupo heterogéneo que hemos llegado a la visualización desde distintas profesiones pero con similares necesidades: transmitir información, conocimiento o ideas mediante un impacto visual. El taller fue emitido en streaming por  Camon y La Información el primer medio español con una sección de visualización.

En mi caso la visualización me ayuda a analizar los datos que investigo, a validar los algoritmos y a presentar los resultados de una forma más divulgativa. Lo que he aprendido ha sido gracias a Internet y a bastantes horas de autoaprendizaje.

Este primer día de taller he presentado una visión global del estado del arte de la visualización, el data set que se va a utilizar en los talleres y he realizado algunas visualizaciones con el servicio ManyEyes.

Aquí está la presentación:

Aquí las primeras visualizaciones:

¿Quién fue más mencionado Navarro o Gasol? interactuen y vean..
¿Cuantas palabras españolas hay entre las más pronunciadas?

Agudeza visual: ¿qué dos paises se parecen más en sus menciones?
¿Cuantos twitean desde su iPhone?

¿En que lugar esta España en cuanto menciones en el Turkey2010?

Llevo unos meses sin actualizar el blog debido a mi dedicación con pico y pala a la extracción y análisis de datos en Twitter, labor nada trivial ni exenta de riesgos como se podrá constatar tras leer los obstáculos más importantes que me he encontrado en el ejercicio del data mining Twitter:

1. No hay conexión que tres días dure: El uso del streaming API requiere una conexión permanente. Pero esta conexión se puede romper (y se rompe) por unos de los dos extremos: el de Twitter y el del propio servidor. Dado que la captura de datos para un experimento puede durar meses, es evidente que hay un problema importante que resolver.
2. Agua que no has de beber, déjala correr: desde que el flujo de tweets es del orden de 700 TPS (Tweets Per Second) no hay conexión que los soporte ni servidor que lo almacene, aparte de que Twitter no permite la modalidad de statuses/firehose a cualquiera. Por tanto, hay que elegir lo que se quiere recibir y consecuentemente renunciar al resto.
3. ¿Qué fue antes la gallina o el huevo? Cuando se quiere monitorizar un evento anunciado no se sabe de antemano cuales serán los hashtag dominantes  ya que son los usuarios de Twitter los que mandan y marcan las tendencias. Cuando se quiere monitorizar un hashtag que es trendring es ya too late: con el Streaming API se habrán perdido todos los tweets que lo auparon a la cima y con el search API solo se obtendrá los 1.500 últimos tweets. Véase el caso de la huelga general del 29-O ¿Quién iba a saber de antemano cual serían los hashtags más usados?
4. Nunca están todos los tweets que son ni son todos los que están: Cuando se escogen los hashtags para monitorizar la información deseada es como jugar a las siete y media: que te pasas o que no llegas: Si se eligen hashtags que no son muy específicos se corre el riesgo de que haya tweets que no sean relevantes (problemas de ambiguación) y si se opta por otros más específicos se quedarán muchos tweets en el tintero, eso sin contar a la cantidad de tweets que no se etiquetan mediante hashtags.
5. El tamaño sí importa. Una captura de continua de tweets durante meses significa un volumen de información muy considerable, tanto para almacenar como para procesar. A 50 TPS, guardando la información en modo texto plano (200bytes) son 10K por segundo, 600K por minuto, 36 Megas por hora, 864 megas, casi un giga, al día.

El data mining en Twitter requiere paciencia, perseverancia e ingenio. Es necesario saber de antemano que se trabaja en un entorno difuso y que hay que adaptarse al medio para capturar la información de la manera más eficiente. Estos son unos consejos para obtener tweets y no morir en el intento:

1. Para mantener la conexión siempre viva es necesario realizar una aplicación de captura de tweets robusta y resolver el problema de la disponibilidad de servidores
   La aplicación de captura de tweets cuando pierda la conexión con Twitter debe intentar restablecerla de nuevo hasta que lo consiga y dejar toda la historia de las conexiones en un fichero de log.
   Es preciso crear un daemon para arrancar esta aplicación automáticamente en el inicio del sistema y para pararla de una manera ordenada antes del apagado del servidor. Si la captura de tweets no se realiza en paralelo con un servidor de backup es conveniente que el daemon avise mediante un email de alerta antes de ser apagado para activar la captura en un servidor provisional.
2. Para elegir los hashtags hay que anticiparse “adivinando” los hashtags triunfadores, monitorizar por exceso e ir ajustando los hashtags conforme vayan definiéndose. Esto requiere estar pendiente de lo que ocurre en Twitter hasta que se tengan identificados los hashtags relevantes  y que la aplicación de captura de tweets permita ser reconfigurada sobre la marcha.
3. Para seleccionar la información relevante hay que posprocesar la información obtenida actuando en tres frentes: crear filtros para eliminar posible spam, suprimir información no relevante, y refinar la selección que ofrece Twitter:
   • Filtrar spam es fácil porque los spamers son muy cansinos: Twittean siempre lo mismo y los hacen con algún bot de forma compulsiva. Cuando se selecciona el top de los autores quedan al descubierto. Solo es necesario crear un filtro de tweets con los nombres de usuarios spamers más destacados.
   • Filtrar información no relevante lo más práctico es buscar el top de los hashtags y ver cuales de ellos no son relevantes con los datos que estamos analizando y se les añade al filtro de tweets.
   • Refinar selección de Twitter: Twitter intenta dar información por exceso, por ejemplo si monitorizamos el hashtags #esp, enviará los tweets que contengan esp o #esp, tanto en mayúsculas como en minúsculas. En algunos casos esto no es conveniente y se debe hacer un filtrado más estricto de los hashtags.
4. Para aliviar el uso masivo de disco se pueden almacenar los tweets  en módulos de un tamaño manejable y comprimirlos. Algunos lenguajes como Python son capaces de abrir ficheros comprimidos e incluso leerlos a la misma velocidad que a la de los descomprimidos.

Espero que estos consejos sean de utilidad y si alguien está trabajando con datos de Twitter y quiere compartir experiencias, me encantaría que contactase conmigo.

Actualmente Twitter es una de las mayores fuentes de información en tiempo real de Internet alimentada por millones de usuarios. Durante el último mes he intentado buscar respuestas estas preguntas:

• ¿Cuál es la cantidad de tweets?
• ¿Qué se puede obtener con los APIs de Twitter?
• ¿Cuáles son las limitaciones del API de Twitter?
• ¿Qué persistencia tienen los tweets?

Lo que he averiguado lo he  representarlo en una infografía para los muy ocupados y en modo textual para los que su curiosidad sea aún mayor.

¿Cuál es la cantidad de tweets?

El número de usuarios de Twitter  y por tanto el de tweets generados tiene un crecimiento espectacular.  El despegue comenzó en el 2009 y en un año se ha multiplicado por 25.  Con este tráfico de entrada cualquier evento global es una prueba de fuego para Twitter, como ha sido el caso de la Wold Cup que nos ha traído de nuevo a la ballena azul.

Durante la segunda semana de la World Cup se ha alcanzado el record de  3.283 TPS (Tweets Per Second) y la media actual es de 750 TPS.  Esto hace casi inalcanzable obtener tal cantidad  de información (y almacenarla) por lo que habrá que pensar en  soluciones creativas para poder obtener los datos que se deseen.

¿Qué se puede obtener con los APIs de Twitter?

Twitter ofrece tres APIs:   Streaming API,  REST API y  Search API aplicables a necesidades diferentes.

El Streaming API proporciona un subset de tweets en casi tiempo real. Se establece una conexión permanente por usuario con los servidores de Twitter y mediante una petición http  se recibe un flujo continúo de tweets en formato json.  Se puede obtener una muestra aleatoria (statuses/sample), un filtrado (statuses/filter) por palabras claves o por usuarios. Sin embargo, los métodos más interesantes cómo obtener todo el caudal de tweets (statuses/firehose) o sólo los tweets que tienen enlaces (statuses/links) o los tweets con retweets (statuses/retweet) “Is not a generally available resource” :-(

El Search API suministra los tweets con una profundidad en el tiempo de 7 días que se ajustan a la query solicitada. Es posible filtrar por, cliente utilizado, lenguaje y localización. No requiere autenticación y los tweets se obtienen en formato json o  atom.

El REST API ofrece a los desarrolladores el acceso al core de los datos de Twitter. Todas las operaciones que se pueden hacer vía web son posibles realizarlas desde el API.  Dependiendo de la operación requiere o no autenticación, con el mismo criterio que en el acceso web. Sopota los formatos: xml, json, rss, atom.

El Search API ofrece una información más limitada del tweet,  en concreto sobre los datos del autor en el que solo indica el Id,  el screen_name y la url de su avatar. Los otros dos APIs si ofrecen el perfil completo del autor en el momento de la escritura del tweet.

¿Cuáles son las limitaciones de  los APIs de Twitter?

En el Streaming API el flujo es continuo y la velocidad de recepción de tweets tendrá fluctuaciones que dependerán del ancho de banda de los dos extremos de la conexión y la sobrecarga de los servidores de Twitter. Actualmente estoy haciendo medidas en dos servidores y publicaré los resultados tan pronto como estén disponibles.

En el Search API y en el REST API existe una limitación de 150 peticiones a la hora por usuario o por IP si la llamada no está autenticada.
Es importante saber cómo realizar la  paginación de las  peticiones de una manera óptima para sacarle el  máximo partido.

(*) hemos obtenido los seguidores de Barack Obama que sobrepasa los 4,5 millones de followers

¿Qué persistencia tienen los tweets?

Aunque todos los tweets residan en las BB.DD. de Twitter hay una limitación temporal para obtenerlos.

-



Tenía pendiente hacer pública la herramienta que utilicé  en el experimento del hashtag #manifiesto y en el resumen visual de la conferencia WWW2010. Me lo ha recordado @paco229 en este tweet:

paco229 en su momento @congosto dijo que iba a publicar los scripts que usó para hacerlo #inp
8:01 AM May 19th via TweetChat

Le he sacado un poco de brillo al script y lo he documentado para que lo pueda usar quién esté interesado en sacar información de Twitter.

El script asume que el formato de entrada es el modo texto de la  herramienta tweetbackup. Está escrito en python y permite extraer la siguiente información de un conjunto de tweets:

• los autores y cuantos tweets han escrito
• las palabras y el número de veces que se han utilizado (es posible filtrar las palabras irrelevantes)
• los hastagh y el número de repeticiones
• el número de tweets por cada día
• el número de tweets por hora
• las urls y el número de repeticiones, el ranking de los sitios web mencionados y de los servicios acortadores de urls.

Descargar tweets_info.py

He aprovechado para cambiar el diseño de barriblog-wiki para publicar tambien allí las herramientas que vaya realizando. Espero que sean de utilidad