Analizando el hilo de Manuel Bartual

Si has seguido Twitter estos días, seguro que habrás visto la que se ha liado con el hilo de Manuel Bartual. Si no lo has visto, te recomiendo que le eches un ojo a partir de este primer tweet. Si bien la historia no es nada especial, la forma de hacerlo sí que ha sido "revolucionaria". Manuel nos ha narrado en primera persona y "en directo" sus "vacaciones", teniendo enganchados a al menos 400.000 seguidores (que se dice pronto), todos ellos pendientes de saber qué iba a pasar a continuación.

Sin meterme en la parte literaria, me ha apetecido echarle un ojo a los tweets y ver si detectaba algo interesante. El análisis que os traigo no es exhaustivo y puede tener algún error, ya que lo he hecho en un par de ratos tontos que me aburría. Tampoco busco probar ningua hipótesis, es un mero análisis exploratorio. 

Estáis advertidos.

- El primer paso: Obtener los mensajes.

Manuel ha estado publicando desde el día 21 hasta el día 27 de Agosto. Obviamente esto implica que recuperar los mensajes a mano es inviable.

La primera idea que me vino a la cabeza fue cargar la página completa del autor en Twitter  y mirar si el HTML era "parseable" (se podían extraer los mensajes) de forma fácil. No obstante, el código es demasiado enredado, mucho JavaScript y demás para poder tener los datos limpios.

Como digo, me parecía demasiado enrevesado extraer los mensajes del código, así que me puse a buscar alguna librería por ahí que te permitiera pedir los mensajes a la API de Twitter. Tuve suerte y relativamente rápido encontré esta librería que precisamente te permite conectar con Twitter desde Python. Tuve que hacer un par de cambios al ejemplo que venía en su web, ya que Twitter te limita a obtener los mensajes de 200 en 200, pero nada complicado. Dejo aquí el código fuente por si alguien lo quiere reutilizar.

Último mensaje (en bruto) de Manuel, con el texto "¿Hola?"

Ya tenía los mensajes. Decidí obtenerlos la mañana del 27 a las 13.06h hora de Madrid. Es decir, que me guardé sólo desde el primero al que termina en "¿hola?", pues considero que es el fin del relato. Si en estos días hay más tuits relevantes, puede que repita el análisis, pero de momento me vale hasta ahí. Menciono la hora a la que he obtenidos los mensajes, ya que al ser datos dinámicos, los "Me gusta"/"Favoritos" o "Retweets" son los que he obtenido a dicha hora, probablemente ahora sean más.

En total extraje 374 mensajes.

- El segundo paso: Mirar los metadatos.

Twitter nos ofrece bastante información más allá del texto. Entre otras cosas, nos dice la fecha exacta de publicación de los mensajes, el número de favoritos que tienen, los RTs que se han hecho hasta ese momento, el idioma, etcétera. Antes de mirar los textos en sí, podemos hacer un repaso de estos metadatos, además como tenemos la fecha de cada mensaje, podemos estudiar series temporales.

Lo primero que podemos mirar es cuándo se publicaron mensajes:

En esta primera gráfica vemos cómo empiezan los tweets el día 21 a última hora y cómo la mayoría se concentran a última hora del 25 y a lo largo del día 26.

Si los agrupamos por días vemos que, efectivamente, la gran mayoría se concentran en el día 26 con alrededor de un tercio de mensajes del total:

Es curioso porque estos datos van bastante correlacionados con el número de RTs y Favoritos por cada mensaje, es decir, que parece que a medida que su hilo gana fama, Manuel publica más; o bien publica más y por ello gana fama (o no, porque correlación no implica causalidad, como ya nos decía XKCD).

El dato atípico de la izquierda con un número de Favoritos y RT tan alto se corresponde con el primer tweet del hilo, que es el que está destacado en su perfil y que probablemente sea el que más gente se ha leído, compartido, gustado y guardado. 

Es curioso ver como los Favoritos superan siempre a los RTs, lo que implica que en este caso se prima el "gustar" y "guardar", frente al "compartir".

Parece también haber algunos tweets concretos que destacan sobre el resto de la tendencia y que además coinciden con ser el último o el primero del día, como si la gente dijera "hoy has hecho un buen trabajo" o "me alegro de que vuelvas".

Se puede ver también como a lo largo de los días la popularidad va subiendo, siendo los mensajes del día 26 los más populares en ambas categorías.

- El tercer paso: mirar el contenido de los mensajes

Una vez analizados los metadatos, podemos empezar a mirar por encima los datos en sí. 

Para empezar podemos comparar la longitud de los mensajes, tanto en caracteres como en palabras:

Estos datos son bastante uniformes, pero se ve una ligera tendencia hacia el 26 y 27 donde los tweets empiezan a tener menos caracteres y sin embargo un número parecido de palabras (o algo inferior al resto de días).

Esto podría deberse al ritmo que se marca en esos tweets, ya que Manuel está intentando crear tensión: los mensajes o contienen menos información, o son muchos y de frases cortas para darle más velocidad y emoción al texto, lo que se reflejaría en su popularidad.

Esto obviamente lo deduzco no sólo de la gráfica superior (en la que no se aprecia tanto) si no conociendo el contenido de los textos. Vamos, que quiero ver la correlación más que realmente verla en estos datos. Pero para el análisis, de momento encaja como hipótesis.

Por un lado hemos visto el número de caracteres y por otro el número de favoritos, ¿qué pasaría si sacamos el número de favoritos con respecto a la longitud del mensaje? Pues que obtenemos esta gráfica:

Ahora se ve más clara esa hipótesis que antes planteábamos: los últimos tweets del hilo acumulan una gran popularidad con respecto a la longitud de estos. Sobre todo el último, que con sólo una palabra acumula más de 40K favoritos.

Por otra parte, podemos analizar las palabras más utilizadas. Para ello he utilizado la herramienta NLKT que permite realizar procesamiento del lenguaje natural (en este caso el español) desde Python.

Los 374 mensajes están formados por 6.024 palabras, y si quitamos las repeticiones obtenemos 1.260. Quitando las palabras "irrelevantes" (stopwords en inglés), que corresponderían a conjunciones, pronombres, preposiciones..., nos quedan 1121 palabras. Si comprobamos cual es su frecuencia obtenemos el siguiente ranking:

Parece que la "habitación" y el "hotel" eran clave :)

Aunque todos sabemos que el protagonista fue el "bollo", aunque sólo aparezca dos veces, una en singular y otra en plural.

Por otra parte, podemos mostrar esta misma información, pero de forma más resultona, con una nube de palabras. En estos gráficos el tamaño de la palabra es directamente proporcional al número de apariciones: cuantas más veces aparezca una palabra en el texto, más grande es la palabra en la imagen. Para este caso he usado esta otra librería:

- En definitiva:

Manuel ha hecho un gran trabajo, ha sabido llamar la atención aprovechando un medio que muchos consideran muerto, pero a pesar de todo ha conseguido destacar y mantenernos atentos a sus mensajes.

Espero que os haya parecido curioso el análisis, si alguien quiere algún detalle más o quiere los datos en bruto, podéis dejarme un comentario o contactarme por Twitter.

¿Y qué saco yo de todo esto? Pues:

- He aprendido a obtener los mensajes de alguien en Twitter.

- He repasado algún detalle para presentar las gráficas.

- He tocado un mínimo de NLKT para procesar los textos.

- Y he aprendido a dibujar nubes de palabras chulas.

Y todo en un día. No está mal, como dice Manuel: 

Todo está bien 🙂

— Manuel Bartual (@ManuelBartual) 27 de agosto de 2017

El Test de Turing, o cómo saber si las máquinas piensan

Imaginemos por un momento que hubiésemos desarrollado la máquina más inteligente del mundo, al menos tan inteligente como un ser humano y que fuese capaz de pensar. ¿Cómo podríamos demostrar que es capaz de pensar? Esta misma pregunta se la planteó Alan Turing, uno de los más importantes teóricos de la computación y pionero en el campo de la inteligencia artificial.

 

Aunque depende mucho de qué entendamos por inteligencia, Turing propuso en 1950 una prueba (hoy conocida como el Test de Turing) basada en el Juego de la Imitación. Este juego consistía en tres personajes, un hombre y una mujer en una habitación y un juez situado en otra sala aislada de la primera. El hombre tenía que intentar engañar al juez convenciéndole de que era la mujer, mientras que la mujer tenía que convencer al juez de que la mujer era ella. El juez debía decidir a base de preguntas quién era la mujer y quién era el hombre.

 

La prueba que Turing propone un caso similar: en una habitación aislada hay un juez humano, mientras que en otras dos salas hay un individuo humano y la máquina a ser juzgada. Para comunicarse, Turing propone que la comunicación se realice utilizando teletipos, de manera que la escritura o la voz no afecte al criterio del juez. Si la máquina es capaz de pensar y razonar como un humano, el juez no será capaz de diferenciar entre la máquina y el humano, no sabrá decir quién es quién. Esto quiere decir, que si el juez no es capaz de identificar a la máquina y la confunde con el humano, podríamos considerar esa máquina como inteligente ya que es capaz de imitar el comportamiento humano. Turing afirmaba que “existirá Inteligencia Artificial cuando no seamos capaces de distinguir entre un ser humano y un programa de computadora en una conversación a ciegas”.


Fuente

Un ejemplo aplicado del Test de Turing son los CAPTCHA, esos códigos ilegibles que tienes que introducir para acceder a una web de los que ya hablamos, que aunque no siguen estrictamente el Test, si que representan la idea que Turing propuso: diferenciar al hombre de la máquina mediante una prueba.

 

 

 

Pero volviendo a la idea del Test, ¿que se engañe al juez demuestra que la máquina es capaz de pensar? La respuesta a esta pregunta es no, ya que lo que realmente demuestra este experimento es que la máquina es capaz de aparentar que piensa, y lo hace al menos tan bien como lo haría un humano. Pero, ¿cuál es la diferencia entre pensar y aparentar pensar? Quizás no tenga demasiada relevancia a nivel práctico, y lo importante es que una máquina sea capaz de elaborar una respuesta inteligente a las preguntas que le hagamos, independientemente del método seguido para elaborar dicha respuesta.

 

En cualquier caso, estamos aún lejos de conseguir que una máquina supere el Test. Esto se debe principalmente a la vasta amplitud de posibilidades que se presentan al tener un problema tan abierto: no hay límites en el tipo de preguntas que el juez puede hacer, siendo estas de cualquier tema que podamos imaginar y con todas las segundas intenciones que el juez quiera, y no hay límites en las posibles respuestas que se pueden dar. Sencillamente hay demasiadas posibilidades. 

 

Sin embargo, como ya vimos con el caso de Watson, en ciertas ocasiones donde el ámbito sea acotado y reducido a una porción de conocimiento, y con un mecanismo concreto, las máquinas van acercándose. En este post se recogen algunos avances en distintas áreas, como el reconocimiento facial, el ajedrez y la música entre otras. Aún nos queda mucho por delante, pero seguimos avanzando.

 

Si os interesa leer más sobre el tema, aquí tenéis el enlace al artículo original de Turing  y si quereis saber más sobre Turing hay muchos artículos sobre su legado, aquí os dejo uno de ellos.

Cuando las máquinas comenzaron a dejarnos obsoletos [Detallado 8]

Hace tiempo que las máquinas comenzaron a dejarnos obsoletos. Comenzaron reemplazándonos como mano de obra, pero no van a terminar ahí. Hoy os traigo la historia de Ken Jennings como ejemplo de lo que está por venir. Espero que os guste.

Ken Jennings

De pequeño, Ken Jennings era el típico sabelotodo que se pasaba el día leyendo enciclopedias y acumulando datos curiosos. Estos datos variaban mucho, desde la frecuencia de la órbita del cometa Halley o el tamaño del pastel de calabaza más grande del mundo. Gracias a esta curiosidad innata y a su capacidad para retener esta información pudo presentarse al concurso americano Jeopardy.  

La gracia de este concurso está en que, en lugar de preguntar directamente a los concursantes, a estos se les da una respuesta, una pista, y deben ser ellos los que elaboren la pregunta. Por ejemplo: una respuesta del concurso podría ser "El Padre de la Patria; en realidad, no cortó un árbol de cerezo", a la que el concursante debería responder "¿Quién es George Washington?".



Ken Jennings participando en Jeopardy

En el caso de Ken, él fue el concursante de Jeopardy capaz de acumular la racha más larga de programas consecutivos ganados. Sumó un total de 75 programas, acumulando un premio final de más de dos millones y medio de dólares.

Y Ken estaba contento. Había sido una racha espectacular, la gente le saludaba por la calle celebrando con él su éxito. Tantos años de acumular datos se habían visto recompensados. Todo iba bien. Hasta que IBM se propuso ganarle.

Watson

Tras la victoria de Deep Blue sobre Gari Kaspárov en su famosa partida de ajedrez de 1997, IBM estaba buscando el siguiente gran reto donde pudieran demostrar las capacidades de la Inteligencia Artificial. En 2004, Charles Lickel, el gerente de investigaciones para IBM, vio la racha ganadora de Ken Jennings en Jeopardy mientras cenaba en un restaurante con sus compañeros de trabajo, y en ese momento pensó en cual podría ser su próximo gran reto: vencerle. Es entonces cuando, tras convencer a sus superiores, se comienza el desarrollo de Watson, el sistema informático desarrollado para ser capaz de participar y ganar en Jeopardy.

La dificultad del concurso Jeopardy reside en dos grandes bloques: entender la pista dada y formular la pregunta correcta. En la primera parte es donde Watson lo tendría más difícil, pues esta pista se da en lenguaje natural, es decir, en el lenguaje humano, en este caso en inglés. El gran problema de trabajar con el lenguaje natural es la ambigüedad semántica que este presenta. Una palabra puede significar diferentes cosas según su contexto. Por ejemplo, “amo” puede referirse a la primera persona del presente del verbo “amar” o al dueño de una propiedad. Para conseguir resolver estos problemas, Watson no tenía un único programa, si no que era capaz de ejecutar varios programas a la vez, de manera que observando cual de todas las respuestas obtenidas con ellos era la más frecuente era capaz de econtrar la respuesta correcta. Una vez entendida la respuesta, era relativamente sencillo buscar en su inmensa base de datos, de más de 4 terabytes, a qué información se refería, y a partir de ahí, sólo quedaba la pequeña tarea de elaborar la pregunta.

Tras siete años de desarrollo y pruebas, en febrero de 2011 Watson se enfrentó en un concurso especial de Jeopardy contra Ken y Brad Rutter, los dos mejores concursantes de toda la historia del programa. Para que Watson no tuviera ventaja, también tuvieron que elaborar un pulsador electrónico que este podría pulsar con un dedo robótico. Y no dejó de pulsarlo. Watson fue capaz de vencer a ambos concursantes sin que estos tuvieran la más mínima posibilidad de plantarle cara.

¿Cuánto duraremos?

Esta victoria es muy destacable. En el caso de Deep Blue, el superordenador campeón de ajedrez que antes mencionábamos, su victoria sobre Kaspárov mostró la increíble capacidad de cómputo que un ordenador puede alcanzar. Pero al fin y al cabo, el ajedrez es un juego cerrado, en el sentido de que el número de posibles jugadas, si bien es muy grande, este es finito, ya que existen unas reglas bien definidas sobre cómo se mueve cada pieza. En el caso de Jeopardy esto no es así. El número de posibles pistas es enorme, mucho más grande, y estas requieren una interpretación por parte del concursante. Existe ambigüedad e imprecisión en muchas de ellas. Es precisamente el ser capaces de resolver este tipo de ambigüedades una de las características que nos separa a los humanos de las máquinas. O nos separaba.

En el video que os dejo al final de la entrada, Ken cuenta que su sensación tras el concurso fue la de sentirse obsoleto. Una máquina, un conjunto de cables conectados entre sí, había sido capaz de ser mejor en aquello en lo que él era considerado como uno de los mejores. De algún modo, debió de sentirse como aquellos trabajadores de las fábricas que trabajaban manualmente, a los que un día y sin previo aviso, se les sustituyó por máquinas de vapor capaces de hacer su mismo trabajo más rápido y mejor.

Por primera vez en la historia estamos ante la situación donde las máquinas van a ser capaces de realizar tareas cognitivas, es decir, donde las máquinas van a ser capaces de realizar tareas donde se requiere conocimiento. Desde hacer composiciones musicales, hasta la toma de decisiones en empresas. Y también serán capaces de hacer tareas más rutinarias como conducir o limpiar la casa.

¿Debemos, por tanto, temer por nuestras vidas y pensar que vamos a ser reemplazados? Para nada. La tecnología está a nuestro servicio. Pensar en que ya no tendremos nada que hacer sería como haber pensado que los caballos iban a desaparecer porque se inventaran los coches, o que las escaleras dejarían de existir por tener ascensores. La tecnología nos va a permitir realizar nuevas tareas gracias a que ella va a poder encargarse de ayudarnos. Queda mucho tiempo por delante y muchos avances que lograr, pero la Inteligencia Artificial va a abrirnos nuevas puertas. Y no sé vosotros, pero yo estoy deseando ver qué hay detrás…

Tú también deberías saber programar

Estos días he estado viendo por Facebook y Twitter circular una genial campaña de Code.org fomentando la enseñanza de la programación en las escuelas de Estados Unidos. Pero, ¿por qué deberías saber programar? Pues las razones son varias, así que voy a intentar explicarlas desde mi punto de vista como informático que soy.

Fuente

 

Programar te enseña a pensar de forma ordenada

 

Lo primero que aprendes cuando comienzas a programar es que el ordenador es una máquina estúpida. Sí, por mucho que te pueda sorprender desde fuera, un ordenador no sabe hacer nada por su cuenta. Programar consiste precisamente en ayudarle con ese problema, consiste en decirle al ordenador, paso a paso, qué debe hacer y cómo debe hacerlo. Programar es darle una serie de instrucciones al ordenador. Como este es muy rápido y muy obediente, es capaz de llevarlas a cabo obteniendo grandes resultados, pero por su cuenta no sería capaz de elaborar nada.

 

Pero para saber darle estas órdenes al ordenador, primero debes saber qué problema tienes, cómo se debe de resolver, qué pasos debes seguir y cómo divivirlo en subproblemas para poder solucionarlo. Estas características son esenciales para cualquier persona en otros ámbitos, no sólo en los relacionados con la programación, ya que te permite enfrentarte a los problemas de una manera eficiente.

 

Programar te permite entender el mundo que te rodea

 

Hoy en día prácticamente todo se hace con la intervención directa o indirecta de un ordenador. Desde tu lavadora a tu teléfono móvil, actualmente y cada vez más, todo lleva incorporado un ordenador. El saber programar te permite entender cómo funcionan las cosas que te rodean, y te da una ventaja frente al resto de gente que no lo conozca. Obviamente, no necesitas saber cómo funciona exáctamente al milímetro cada dispositivo, pero con conocimientos de programación puedes hacerte una idea general de por dónde van los tiros.

 

Es un caso similar a los automóviles: salvo que seas un experto en mecánica no vas a conocer todas y cada una de las piezas del motor de tu coche; pero sí que sabes que tu coche funciona con un tipo de combustible, tiene ciertas piezas que tienes que reponer cada X kilómetros y sabes cuando está funcionando bien y cuando no. Con un ordenador pasa algo similar, tener algo de conocimiento te da una ventaja.

Fuente

Por otro lado la programación está extendida en tantos sectores y tan distintos que tienes mucho donde poder elegir. Que te gustan los videojuegos, puedes ser programador de videojuegos. ¿Te gusta la moda? Pues echa un vistazo a "wearable computers". Y así con todos los sectores que puedas pensar. Prácticamente en cualquier campo que te imagines puedes aplicar la programación.

 

Programar es sencillo y divertido

 

Cuando uno no conoce qué es programar se piensa que es algo complicado, donde tienes que romperte la cabeza, no tener vida social y ser un friki de las matemáticas para entenderlo. Esto no es así. La mayoría de los programas son sencillos en cuanto a las operaciones que realizan, no manejan operaciones matemáticas más complejas que la suma, y en general los programas suelen encargarse de mezclar informaciones y combinar resultados de otros programas.

Por supuesto puedes encontrarte diversos niveles de dificultad; y eso es lo interesante, que según vas aprendiendo eres capaz de resolver cosas cada vez más complejas. En mi caso mi primer programa fue una aplicación que te calculaba el menor de tres números dados. Luego hice otra que te saludaba, le dabas tu nombre y te decía "Hola X". Luego te decía adiós y cambiaba la forma de saludarte cada vez. El caso es aprender lo básico e irse interesando por ello. A partir de ahí, el límite es tu imaginación.

Fuente

Programar se parece a resolver puzzles o a resolver sudokus, o más bien a resolver un laberinto. Tienes un punto A de partida, que normalmente son unos datos de entrada y con ellos tienes que llegar a obtener un resultado B, el camino que hay que seguir es lo que tú debes definir. Y esto es lo divertido, es ir peleando y pensando cómo elaborar esos pasos para conseguir llegar hasta meta, teniendo en cuenta que los datos A pueden ser variados y que hay siempre más de una forma de llegar hasta B. Y cuando eres capaz de llegar a resolverlo, esa sensación es incomparable. En la programación tú eres capaz de crear cosas desde cero. Eres el creador de un programa capaz de resolver algo por su cuenta. En pocos campos vas a poder tener ese superpoder.

 

Programar es algo que se debería enseñar en el instituto, por supuesto en un nivel básico, y que sirviera de base para tener un poco de conocimiento de en qué consiste y qué puedes llegar a conseguir. Al menos tener unas nociones de qué es la programación.

 

Y si yo no te convenzo...

 

Puedes ver el siguiente vídeo que forma parte de la campaña que te comentaba antes, donde gente como Bill Gates (fundador de Microsoft), Mark Zuckerberg (fundador de Facebook) o Gabe Newell (fundador de Valve) entre muchos otros te dan sus motivos para que intentes iniciarte:

 

 

Reutilizando esfuerzos

A veces hay gente que piensa de manera muy original, saliendose del patrón habitual del pensamiento corriente, es el llamado pensamiento lateral. Os dejo con esta historia porque a mí la verdad que me ha dejado impresionado por la sencillez pero a la vez potencia de la solución que plantea.

Hace unos años, un ingeniero de la Carnegie Mellon University, Luis von Ahn, elaboró un método para mejorar la seguridad en las páginas webs.

El objetivo era evitar el uso abusivo de programas autmáticos que interactuaran con los formularios de una web. Había que buscar algo que un usuario pudiera hacer, pero fuera complicado para una máquina, con el fin de evitar que esta pudiera automatizar el proceso. Para ello, se le ocurrió poner una imagen generada de manera aleatoria, asociada al formulario de la web, de tal manera que si se quería enviar el formulario, se tenía que poner el contenido de esa imagen en un campo del formulario, algo sencillo para el ser humano (aunque no siempre), pero muy complicado para un ordenador por la complejidad de leer la información de esta imagen. Había inventado el CAPTCHA.

Ejemplo de CAPTCHA

Sin embargo, se dió cuenta de que cada usuario, cada vez que introducía los valores de estas imagenes, perdía una media de 10 segundos por cada uno de ellos, por lo que al cabo del día multiplicado por los miles o millones de usuarios que utlizan los CAPTCHA, resultaba en una cantidad enorme de tiempo desaprovechado. ¿Cómo se podría aprovechar ese esfuerzo individual de manera colectiva?

Pues precisamente aprovechando la dificultad de la solución del problema. Es decir, si lo que hace que esa medida sea segura es que el ordenador no sabe leer esos textos, utilicemos ese esfuerzo de cada usuario para que el ordenador pueda leer textos.

Actualmente hay varios proyectos en marcha sobre digitalización de libros ( Google Books por ejemplo ), y uno de los principales problemas que se encuentran es que no son capaces de transformar las imagenes obtenidas desde el scanner a texto, ya sea por la calidad original del papel, bajo contraste o cualquier otro problema.

Por lo que la idea de este ingeniero ha sido reutilizar el esfuerzo.

Para ello utiliza dos imagenes, por un lado un CAPTCHA normal, generado de manera aleatoria que el usuario tendrá que escribir correctamente. Por otro lado la imagen digitalizada que el ordenador no es capaz de leer. Ambos se le muestran al usuario, que no sabe cual es cual, con lo cual para poder acceder a la web deberá introducir ambos correctamente, salvo que el único que será comprobado es aquel que fue generado por el ordenador, y el texto que el usuario introduce para la imagen que el ordenador no era capaz de reconocer será almacenado; de esta manera, finalmente, el ordenador eligirá aquella palabra más repetida entre todos los usuarios para esa imagen, pues será la más probable, y por tanto, se podrá digitalizar ese texto.

Proyecto ReCAPTCHA

Es decir, que en el momento que estás haciendo un CAPTCHA estás ayudando a la vez a digitalizar un libro. El usuario no lo nota, pero ese esfuerzo puede ser aprovechado.

Este y otro caso también interesante sobre como traducir la web de manera gratuita, son explicados por el propio Luis von Ahn en la siguiente charla TED. No os la perdais, está en inglés pero podeis ponerle subtítulos.

Como siempre, si te ha gustado, comparte esta entrada con los botones que aparecen debajo

¿Cómo ven el mundo los robots?

Seguro que todos reconoceis la imagen de arriba, se trata de un fotograma de la película Terminator, que representa cómo veía este robot encargado de aniquliar a John Connor.

Pues los actuales robots no distan demasiado de esta película en cuanto a ver se refiere. Cómo podeis ver en el siguiente video, se muestran las diferentes aplicaciones de la visión artificial en campos muy diversos, desde el tráfico, reconocimiento facial o hasta el estudio de bacterias. Aplicando realidad aumentada, se muestra la información que interese superpuesta a la imagen real.

Aquí os dejo el vídeo; da que pensar para la próxima vez que veas una cámara, ya que puede que realmente te esté viendo y sobre todo, te esté entendiendo.

Mi entrevista con Google

Ha pasado ya prácticamente un año, y aunque no conseguí el puesto en su día, creo que merece la pena contar la historia de como funciona el proceso de selección, puede que a más de uno le ayude. Aquí os dejo mi pequeña aventura con la empresa de la gran G.

El comienzo de todo

Todo comenzó a través de una oferta de trabajo en el portal de empleo de Google. Esta oferta la vi en Octubre de 2010, mientras estaba de Erasmus en Helsinki. Concretamente, la oferta era para un "internship" (unas prácticas) para un puesto en Google EMEA (Europa y Oriente Medio). Como estaba acabando la carrera y no tenía perspectivas de trabajo, pensé que podía ser una buena idea. Imagínate, empezar a trabajar haciendo unas prácticas en Google, hubiese sido la bomba.

Para la oferta mandé un resumen con todas mis notas de la carrera, un currículo y una carta de presentación escrita por mí. Tanto el currículo y la carta eran muy básicas, ahora me doy cuenta tras haber buscado empleo en más sitios que podía haberlos mejorado mucho e incluir alguna carta de presentación.

De todos modos, no tenía mucha convicción en que contactaran conmigo, esa oferta era a nivel global, un puesto en Google... Tendrían miles de solicitudes como para que se fijaran justo en la mía. Me acuerdo además perfectamente un día, volviendo de fiesta con un amigo en el autobús, hablando de la vida y me preguntaba que cual sería mi trabajo ideal. Y le dije "pues trabajar en Google molaría mucho, es más, he mandado un currículo a una oferta que vi, pero no creo que me elijan, es muy difícil".

El primer mail

Poco más de un mes después, el 23 de Noviembre recibo este mail:

Hi Javier,

Thanks for your application! My name is **** and I received your details as I recruit post-graduate/doctorate engineers for full-time roles at Google in EMEA.
Currently I'm hiring for development opportunities which commence at any stage during 2011.

So, unless you're applying for further study (MSc/PhD?), would you like to be considered for full-time software development roles at Google?

I'd be happy to bring you through the interview process and if you're keen to progress, please let me know the best times, dates and number to reach you for a preliminary (non-technical) chat.

Thanks for your time,
****

 Y ahí se me disparó el corazón: no sólo habían leído mi solicitud, si no que me habían seleccionado como posible aspirante, y no sólo eso, si no que me ofrecían puesto de desarrollador a tiempo completo. (Esto después descubrí que se debía a que los internship sólo los permiten si estas estudiando en la carrera.)

Este correo lo recibí a las 23.30h y aunque era un poco tarde, llamé a mis padres para que se conectaran al skype, tenía que contarselo. Al principio se extrañaron y preocuparon por las horas, pero lo entendieron en seguida. Además mandé varios sms a mis amigos para dar la noticia, ya que estaban de viaje y no tenía a nadie cerca a quien contárselo.

A partir de ahí empezamos a intercambiar correos, para ver cuando podían llamarme para explicarme el proceso, de momento no sería una entrevista, sólo un poco de explicación.

La primera llamada

Al final concretamos para el 7 de Diciembre a las 13h. A todo esto yo seguía de Erasmus, acabando el proyecto de fin de carrera entre viaje y viaje y alguna que otra fiesta...

La llamada duró como media hora o incluso algo menos, al principio me preguntaron por mi situación: que estaba estudiando, cuando iba a acabar la carrera... Y me insistieron mucho en qué estaba haciendo de proyecto de fin de curso. La verdad que en esa llamada lo pasé un poco mal, estaba nervioso, era hablando por teléfono con un nativo inglés... La cosa fue complicada, pero me defendí lo mejor que pude.

En esa conversación me explicaron el proceso:

-La primera parte sería un test online de programación, podía hacerlo en Java, Python o C++. Me dieron una web para entrenar: TopCoder en el que podría hacer problemas similares en dificultad a los que me enfrentaría en esta prueba (muy recomendable).

-La segunda parte sería una prueba de programación igual que la primera, pero con un ingeniero por teléfono y un documento de GoogleDocs.

La verdad que como estaba bastante ajetreado acabando el proyecto y tampoco estaba muy fresco programando (llevaba casi más de medio año sin tocar Java), les pedí que me dieran un poco de tiempo para prepararme.

La preparación

La verdad que el siguiente mes fue el más complicado, había vuelto a España a pasar las Navidades con la familia, ver a los amigos y demás. Había terminado el Erasmus, pero había decidido que a comienzos de año volvería a Finlandia a buscar curro. Si no me salía lo de Google, trabajar en Finlandia era la segunda mejor opción. Otro día os cuento esa historia.

Pues ese mes, o mes y medio, entre la llamada y el primer test me los pasé haciendo un montón de ejercicios en TopCoder. Al principio necesitando mirar muchas cosas, repasando muchos conceptos y recordando cosas olvidadas (APIs, estructuras de datos, algorítmica...) Vamos, como si me estuviera preparando para los exámenes de Febrero tras pegarme más de 8 meses sin programar. Os haceis una idea.

La verdad es que entrené mucho, todos los días hacía al menos tres o cuatro ejercicios, pero conseguí coger otra vez la dinámica. Por otro lado estaba muy motivado e ilusionado, con lo que no me costaba demasiado ponerme.

A todo esto, volví a Helsinki, otra vez a la nieve y a la oscuridad del invierno finlandés. Me había mudado de casa y estaba viviendo con un amigo que todavía estaba de Erasmus.

La primera prueba

Cuando consideré que estaba listo (a la semana de instalarme en Helsinki de nuevo) contacté con ellos para realizar la primera prueba.

Me mandaron un mail con un enlace a una web de pruebas de programación, tenía 7 días para elegir hacer la prueba, pero cuando abriera el enlace, sólo tendría 90 min para completar el examen.

Me dieron un enlace de prueba primero para que conociera un poco la web y trasteara como era. La verdad es que era muy similar a TopCoder: un documento en blanco, un compilador, y la posibilidad de hacer pruebas con datos de entrada. El tiempo no sería un problema pues me había entrenado para hacer ejercicios a contrarreloj.

Así que el 22 de Enero hice la prueba.

Ellos no me permiten dar a conocer las pruebas, pero os diré que fueron tres problemas, los dos primeros eran muy sencillos y los respondí en unos 10 minutos cada uno. El último de todos ellos era algo más complicado, aunque también lo pude sacar. En este tardé un poco más, pero cuando acabé aún me quedaban como unos 25 minutos, así que pude optimizarlo un poco.

La verdad es que estaba preparado para algo más complicado, pero no fue así. Mejor.

Y lo peor vino después: a esperar respuesta, durante al menos 21 según ellos.

Los resultados

Pasaban los días y no daban noticias. Esos días estaba buscando trabajo por Helsinki, con lo que invertía mi día en mandar currículos y buscar ofertas, pero con pocos resultados, fue una etapa difícil.

El 19 de Febrero, viendo que no contestaban y habiendo pasado los correspondientes días, les mandé un mail muy educado pero preguntando que *$%# pasaba con mis resultados. Esta fue su respuesta:

Hi Javier - thanks for checking back with me.  

That is a long time ago - so I just checked and you scored well!
Congratulations :-)

So the next stage is a phone interview.

All the details about how to prepare are below.

Can you let me know when you would feel ready to have a phone interview with an engineer, where you would have a Google Open document running at the same time, so that you can code in real time with the engineer?

Cheers,
****

Así que había pasado la primera prueba, el esfuerzo había merecido la pena. Estaba super contento, os podéis imaginar. 

Pero ahora había que prepararse otra vez, aunque esta vez no dejaría pasar tanto tiempo.

La segunda prueba

Mientras tanto, yo iba haciendo alguna que otra entrevista con empresas por Helsinki, aprendiendo también muchas cosas en ellas: como comportarse, que esperaban oir de ti, que decir, que no...

A la vez, intentaba concretar una cita con Google para ver cuando podíamos hacer esta segunda prueba.

Pero la cosa se complicó. Encontré trabajo en Helsinki para empezar el día 14 de Marzo, en la empresa en la que estoy ahora mismo trabajando. Con lo que, mi horario para entrenarme y las posibilidades de hacer la entrevista se veían complicadas.

Por suerte me dieron facilidades para hacer la entrevista por la tarde y con suficiente tiempo para llegar a casa y desconectar. Así que fijamos una entrevista el día 16 de Marzo a las 19.00h.

Y esta vez, las cosas no fueron tan tan bien. Los problemas que me pusieron no eran excesivamente difíciles, pero me fallaron un poco los nervios, alguna vez me bloqueé con algunas cosas sencillas. Las pruebas no las puedo contar, pero otra vez, no fueron complicadas.

Quizás fue por estar hablando con un ingeniero y no estar concentrado a mi aire y tener que explicar todo, quizás por el teléfono que tuvimos algún problema, o quizás porque venía del curro donde estaba empezando y al principio todo era estudiar cosas nuevas... Pero en definitiva: no rendí al 100%.

En cualquier caso, saqué todos los ejercicios que me puso (aunque en algún momento me "ayudó" con un "estás seguro de ese valor", la misma ayuda que te puede hacer un profesor en un examen). Aún así, algo de esperanza en seguir con el proceso si que tenía.

Los resultados de nuevo

Afortunadamente, esta vez fueron mucho más rápidos, y al día siguiente tenía este correo:

Hi Javier,

Thank you for your time and interest in Google.  XXXX enjoyed speaking with you on the phone about the Software Engineering position.

We carefully reviewed your background and experience, and though we do not have a position that is a strong match with your qualifications at this time, we will be keeping your resume active in our system. We will continue to use our database to match your profile with new opportunities and will reach out to you if we find an opening for which you may be qualified.

Thanks again for your interest in Google's careers and unique culture; we hope you will remain enthusiastic about our company. If you have any questions, please feel free to contact me at *****@google.com.

Kind Regards,

****

Vamos, que no, que gracias pero que no seguíamos el proceso.

¿El fin del sueño?

Pues si algo aprendí mientras buscaba información del proceso de búsqueda, es que Google no da sólo una oportunidad, y si no lo consigues a la primera, lo puedes seguir intentando. Además ya conocía como era el proceso, con lo que podía aprender de mis errores.

Pero eso sí, hay que dejar pasar un tiempo.

Así que al mes y medio de la última prueba, me puse en contacto con ellos, actualizandoles mi situación laboral y diciendoles que si había alguna posibilidad de volver a intentarlo, me lo hicieran saber.

Esta fue su respuesta:

Hi Javier,

Thanks for your email - that's great to hear that you're doing well.

If you focus on developing your Java fluency, I'd be happy to set up another interview in September, if you are still interested. We're supposed to wait a year, but you soak up so much new info at the start of your career that you may be ready sooner....

Make sure that you do some amateur / opensource projects on the side too - or do some TopCoder stuff - that's always helpful :-)

Good luck - stay in touch,
****

Y aquí estamos. En Septiembre. 

Tormentas en la Nube

Como veis, soy un tío con mucha chispa para los nombres de las entradas. Fuera de bromas, me gustaría analizar un poco lo que ha pasado con Amazon y dar mi opinión al respecto, ya que el Cloud Computing fue el tema de mi proyecto de fin de carrera, así que algo he leído sobre el tema ;)

¿Qué ha pasado?

Por si no te has enterado, o estas leyendo esta entrada en un futuro lejano a los incidentes de ayer, te comento el incidente. Ayer domingo 7 de Agosto de 2011, a las 20.00h, el servicio de Cloud Computing que Amazon ofrece en sus servidores de Dublín sufrió una interrupción total del funcionamiento de todos su servicios.

El motivo, al parecer, fue la caída de un rayo que provocó el corte del suministro eléctrico y la descarga afectó del sistema de control de emergencia que tendría que haber activado los generadores suplementarios. La caída total duró unas tres horas, mientras se sincronizaban los generadores manualmente.

Esto ha desembocado en que miles de páginas y servicios web de Europa hayan estado inaccesibles durante unas horas en algunos casos y en otros ya llevan un día como en Menéame.

Este incidente ha dado lugar a que muchos se hayan lanzado a criticar a machete este modelo y poco más que declarando que el apocalipsis está al llegar si se sigue utilizando esta diabólica tecnología.

¿Qué es el Cloud Computing?

Para empezar, el Cloud Computing no es una tecnología, es un modelo de negocio. Aclaro esto porque muchos oímos hablar de "la nube esto" o "la nube lo otro" como si fuese alguna tecnología como los móviles o las pantallas planas LCD.

Lo que ofrece el Cloud Computing como modelo es un servicio, en lugar de un producto. Es decir, en lugar de comprarme una aplicación con una clave y un cd que instalo en mi maquina, aquí compro una suscripción mensual a la aplicación y las cosas las instalas en remoto, en la nube.

Y cuando digo en la nube me refiero a que se instala en las megagranjas de servidores que ofrece Amazon, Google o el proveedor de turno.

¿Qué ventajas trae esto?

La primera de todas es que yo sólo pago por lo que uso. Que uso veinte, pago veinte; que uso tres, pago tres; y además lo bueno de estos servicios es su capacidad de escalar las necesidades, es decir, si tengo una tienda online, es probable que en período de Navidades el número de clientes se me dispare y sin embargo en verano en pleno periodo vacacional no venda nada. En el modelo tradicional tendría que encontrar un punto de compromiso entre verano-navidades para calcular los recursos estáticos (que no varían en el tiempo) que contrataría. Con la nube gano flexibilidad, sólo contrato lo que necesito, ni más ni menos.

Otra ventaja está en las pequeñas empresas o con menos recursos, que simplemente no puede permitirse comprar y montar un centro de datos con sus instalaciones físicas, con la nube no necesitas una inversión tan grande. Además, no necesitas contratar personal que lo mantenga, pues en principio con la nube será el que se encargue de ello.

Y por destacar otra ventaja más y no alargarlo mucho, con la nube tienes accesibilidad remota estes donde estes, ya que para ti es un sistema descentralizado y con un mero navegador puedes acceder desde cualquier lugar del mundo en cualquier momento.

Principales problemas

El principal problema que tiene este modelo es que estás delegando responsabilidades y cuando delegas, dependes de lo bien que lo haga el otro, y parece que en este caso no lo han hecho muy bien.

Por otro lado, el modelo de Cloud Computing no ofrece a penas nuevos riesgos con respecto a cualquier otro servicio online, porque al final del todo, no deja de ser un servicio web con almacenamiento y proceso de datos, vamos, un servidor de toda la vida.

El problema viene en que si un servicio es atacado o sufre algun percance sólo se ve afectado ese servicio, pero en el caso de la nube, si una nube es atacada o sufre un percance, muchos servicios pueden verse afectados, como ha sido el caso.

Errores de Amazon

Lo que no puede volver a ocurrir es lo que ha sucedido en este caso, ya que más que un problema del modelo o la arquitectura usada, ha sido un problema de la gestión de la seguridad informática.

Cuando se habla de seguridad informática, mucha gente piensa en virus, firewalls y demás software informático, pero también forma parte de este campo el estudio de la seguridad física, de las amenazas y vulnerabilidades que un sistema puede tener más allá del software. En mi caso, este tipo de posibles incidentes los he estudiado en la carrera y hay que tenerlos en cuenta a la hora de diseñar un sistema de información. Existen múltiples normativas, como la familia ISO27000 que recogen una serie de pasos y consejos a seguir a la hora de diseñar un sistema informático, desde el punto de vista de la gestión de la seguridad de la información.

En el caso de Amazon, no puede ser que un rayo haga caer todo tu servicio en Europa durante más de un día. Lo primero porque deberían haber sido más rápidos en reactivar la corriente con los generadores, y en cualquier caso, creo que deberían de disponer de algun sistema de emergencia de replicación de datos que permita trabajar a esa nube desde otra localización, bien sea con una copia reciente de los datos o una replicación en tiempo real. Lo que no puede ser es que centralices una nube sin ningún tipo de servicio de réplica (otro data center), que no tiene porque estar operativo en todo momento, pero sí ser activable en caso de una caída general como esta.

 Imagino que, como mínimo, ahora tendrán un centro de datos en Dublín, otro en América y otro en Asia (por tener controladas todas las zonas horarias). No sería descabellado tener un cuarto centro listo para casos de emergencia como este. Porque no dudo que tuvieran copias de seguridad de escasos minutos antes de que cayera el caso, pero de nada me sirve tener una copia de mis datos si no tengo donde usarlos.

Por otro lado, la lentitud de toda la restauración está siendo extremadamente lenta, es inadmisible que con lo importante que es el tiempo hoy en día, que se llegan a ofrecer servicios con menos de un minuto de fallo al año, se tarden más de 24 horas en restaurar un servicio.

Consejos para las empresas

Uno de los errores que seguro han cometido más de una empresa es no tener otra alternativa a este servicio, es decir, que han confiado demasiado en un único proveedor. Si bien puede resultar muy caro tener dos proveedores al mismo tiempo, el no tener capacidad de reacción puede salir también muy caro.

En seguridad hay que llegar a alcanzar un punto de equilibrio entre lo que puedes perder en caso de que ocurra un incidente y el coste de paliar o evitarlo, y no siempre es fácil, pero hay que tener en cuenta que estas cosas pasan. Para esto existen las auditorías de seguridad, los análisis de riesgo y demás estudios que permiten evaluar y tomar decisiones sobre estas materias.

En conclusión

Ahora vais a ver en todos los medios que acusan de todos los males al Cloud Computing, llamandolo moda, olvidandose de que esto mismo podía haber sucedido a cualquier otro servicio.

Desde mi punto de vista creo que se equivocan, porque no es el futuro, es el presente, porque este tipo de servicios lo usamos todos los días: Google, Youtube, Spotify, Google Docs, Gmail, Dropbox etc etc Y la tendencia es que sigan creciendo, pues como ya he comentado, por costes sales beneficiado con el Cloud Computing y los riesgos que entraña son los mismos de siempre, depende de su gestión.

Porque eso sí, todo depende de como se gestionen las cosas y aquí Amazon la ha fastidiado bien.

Los cables de Internet [Detallado 1]

La verdad es que yo hasta hace unos años no me lo plantee, pero es curioso saber cómo funciona Internet físicamente hablando. Con este post estreno los detallados, que como su propio nombre indica, son posts un poco más explicados que los habituales.

A raíz de una noticia, oí hablar de ciertos cables submarinos que habían sido cortados y habían impedido el acceso a Internet en algunos países árabes. Pero no lo podía creer al principio, cómo iba a haber un cable desde Europa hasta América o desde América hasta Asia cruzando todo el océano... Pues resulta que no hay uno, hay muchos, más de los que pensarías.

Descubriendo lo que no quieren que descubramos

Un buscador web funciona mediante dos fases, la primera se basa en un programa que rastrea webs y las almacena en un índice. La segunda parte consiste en las consultas a ese índice. A estos programas que van indexando la web se les denomina arañas y como buen programa que son, lo indexan prácticamente todo. Y digo prácticamente todo, porque hay un estándar de facto que promueve que este programa primero compruebe un archivo llamado robots.txt, el cual contiene una lista de las páginas a no indexar.

Con esto consiguen que las arañas de Google, Bing o cualquier otro buscador bien educado no acceda a lo que los creadores de la página no quieran, y por lo tanto cuando tú busques en su índice, estas páginas no se muestren en los resultados. Pero este archivo nos puede facilitar a nosotros descubrir cosas interesantes, y como buen curioso que soy, decidí probar cosas en webs al azar, y aquí os traigo algunos de los resultados.

No tech hacking [VIDEO]

Hay una conferencia que descubrí en El lado del mal, un blog de seguridad informática, que siempre me ha gustado mucho ya que trata de la llamada inegnieria social.

Esta conferencia es de la DefCon 15 pero realmente no es nada técnica ni necesita conocimientos previos para entenderla. Y he ahí la gracia, se llama "No tech Hacking" y explica como sacar información tan sólo observando detalladamente, el famoso "Leer es gratis y se aprende mucho". Es muy entretenida pues el tio es un showman, y el final por cierto, no tiene precio. Es en inglés pero se entiende fácilmente, podeis activar los subittulos. Merece la pena, aquí os la dejo, disfrutadla:

El siguiente paso

El otro día estaba charlando con unas amigas y, mientras solucionábamos los problemas del mundo, surgió la idea de que las máquinas, refiriéndose a los ordenadores, en lugar de facilitarnos la vida, nos la están complicando cada vez más.

Surgió el debate sobre la inteligencia de las máquinas, y si podrían a llegar a ser lo suficientemente listas como para suplantarnos. Y ahí surgió la idea de querer hacer con las máquinas lo mismo que el ser humano lleva haciendo durante toda su existencia, cuando estas pueden hacer mucho más que nosotros en algunos campos. Grave error que nos impediría realmente aprovecharlas. Hay que ver más allá. Ese es el siguiente paso que tenemos que dar.