Entonces... ¿Hadoop no es nada?

Efectivamente, podríamos decir que Hadoop, en sí, no es nada. No es nada al menos en el sentido en el que , equivocadamente, mucha gente piensa.

Hay una creencia bastante extendida de que Hadoop es una base de datos distribuida o una base de datos NoSQL (ver post Bases de datos NoSQL... ). No, no es eso. Veamos lo que sí es.

Hay infinidad de documentación sobre Hadoop en Internet, así que tampoco pretendo entrar demasiado en detalle, además, necesitaría más tiempo y más de un post. No es el objetivo.

Para empezar, podemos echar un vistazo a la página web de Hadoop (http://hadoop.apache.org/), donde ya nos deja claras las cosas desde el principio:

"La librería de software Apache Hadoop, es un framework que permite el procesamiento distribuido de grandes cantidades de datos a través de clusters de ordenadores, usando un modelo simple de programación"

Librería, Framework,...Vaya, que decepción, así que ¿para usarlo hay que programar?. Pues si, en efecto. Es lo mismo que si instalamos en nuestro ordenador el ".Net Framework 4.0". Nos da la herramienta, pero la casa la tenemos que construir nosotros.

El proyecto Apache Hadoop, consta de tres subproyectos: Hadoop Common, Hadoop HDFS y Hadoop MapReduce, que combinados de forma conjunta, nos proporcionan las herramientas necesarias para construir un sistema que, como dice el enunciado, nos permita procesar grandes cantidades de datos, en un modelo distribuido, con alta disponibilidad, usando un hardware barato y con un alto rendimiento. La verdad es que dicho así, suena muy bien.

Ya veremos más adelante lo que son Common, HDFS y MapReduce. De momento, vamos a centrarnos en las cinco características, que nos han llamado la atención:

Procesamiento de grandes cantidades de datos

Hadoop sirve para procesar GRANDES cantidades de datos, y digo GRANDES con mayúsculas, porque estoy hablando (es un decir) de muchos miles de millones de datos. Si no es el caso, pensemos en otra solución (aunque puedes seguir leyendo el post hasta el final).

Modelo distribuido

El que sea un modelo distribuido, no es solo una ventaja, es también una necesidad. Excepto si es para desarrollar, no sirve de nada montar un sistema basado en Hadoop con una sola máquina. Se puede hacer, pero como digo, solo para desarrollar o "cacharrear" con ello. De hecho, necesitaríamos al menos dos. (Cloudera proporciona una distribución bastante estable y sencilla, que permite simular un cluster en una sola máquina y se instala en unos pocos minutos).

Hasta aquí, lo que parecían ventajas, alguien lo puede ver como inconvenientes. Pero bueno, sigamos...

Alta disponibilidad

Esto está muy bien. Si se rompe una máquina, el sistema sigue funcionando. No perdemos los datos y el sistema se recompone para repartir la carga entre los nodos restantes. Evidentemente, cuantos más nodos tenga nuestro cluster, más protegidos estaremos frente al fallo de alguno de ellos.

Que el sistema siga funcionando pese a la caída de un nodo, no es nada especial, pero el que el sistema redistribuya la carga, si es una importante ventaja.

Hardware barato

Este es otro punto interesante. No necesitamos grandes máquinas, prácticamente cualquier PC con disco duro, procesador y memoria, nos sirve para incorporarlo al cluster, además no tienen por que ser todos los nodos iguales. Cada nodo soportará una carga proporcional a los recursos de los que dispone.

Para que no todo sean ventajas, hay que decir que en el apartado de networking, si es preciso gastarse unos euros. Montar un cluster de un par de docenas de nodos, con PC's de 300€, está muy bien, pero si los unimos con un switch de 10MB, por muchos nodos que añadamos, el rendimiento no mejorará.

Alto rendimiento

En este caso, la potencia no nos la proporciona Hadoop sino la acumulación de nodos al cluster, cuantos más nodos, más rendimiento. Obvio ¿no?.

Dado que podemos utilizar un hardware barato, incrementar la potencia de nuestro cluster, no requerirá una fuerte inversión, además, el escalado horizontal es prácticamente ilimitado.

Ya ha quedado claro al principio, que Hadoop es una herramienta, o más bien un conjunto de ellas:

Hadoop Commons: Son un conjunto de librerías y utilidades sobre las que se soportan el resto de subproyectos. Dan soporte para interactuar con el sistema de archivos distribuidos, gestionar el control de acceso a los nodos, colas de trabajos, etc..

HDFS (Hadoop Distributed File System): Es el sistema de almacenamiento distribuido en el que se soportan las implementaciones de Hadoop. Consta de un nodo primario o "NameNode" que  controla los "DataNodes", que son cada uno de los nodos donde finalmente se almacenan los datos.


MapReduce: Es en si el framework que nos permite desarrollar las aplicaciones que son capaces de procesar en paralelo los datos suministrados.

Los trabajos MapReduce se basan en la separación de los datos de entrada (tareas Map), que son enviados como entrada a las tareas de agregación o combinado (tareas Reduce). Que lío ¿no?.

La verdad es que puede parecer complicado pero en realidad es más simple de lo que parece. Pongamos el ejemplo tonto, que no tiene utilidad práctica, pero si didáctica:

Supongamos que tenemos un fichero de texto con varias líneas y queremos contar las palabras distintas que hay en el texto y saber cuantas veces aparece cada una de ellas.

El primer grupo de tareas Map, recibiría cada una de las líneas del fichero y se encargaría de separar cada línea en sus diferentes palabras. Estas palabras se pasarían a las tareas Reduce, que se encargarían de contar las apariciones de cada palabra, así en diferentes niveles de agrupación (tareas Reduce encadenadas), hasta conseguir el resultado final.

En realidad se trata de ir separando los datos hasta el nivel de granularidad adecuado y después agruparlos para conseguir la segmentación deseada.

¿El truco? tareas sencillas que realizan solo una parte del proceso. Si tenemos muchas de estas y trabajando todas a la vez, tenemos un resultado espectacular.

Y esto, a mi ¿para que me sirve?. Esta es la pregunta del millón.

Lo primero que hay que tener claro es que Hadoop no es la panacea para resolver los problemas de almacenamiento, disponibilidad, sustitución de bases de datos, etc.. Hadoop es bueno, pero solo para resolver unas problemáticas muy concretas.

Quizá, para no perder el tiempo, lo primero que se debería hacer es conocer "Que NO es Hadoop". Para empezar, recomiendo la propia Wiki de Hadoop.

Hadoop es una herramienta excepcional, pero solo si se utiliza para el propósito adecuado.

Aunque pueda parecer a simple vista algo muy complicado de poner en marcha, en realidad no lo es tanto. La instalación de los componentes es relativamente sencilla (Proveedores como Amazon, tienen disponibles nodos preinstalados listos para usar). En realidad, solo nos tenemos que preocupar de desarrollar nuestros programas MapReduce y para ello podemos utilizar varios lenguajes como Java, C++, Python, etc., así que alguno de ellos nos resultará más próximo y será más fácil comenzar.

Yo no trabajo por 800 euros

Esta es la frase con la que me encontré haciendo un zapping la semana pasada. En realidad, creo que fue "Yo no trabajo por 800 míseros euros". Se trataba de un programa de televisión, en el que participaban entre otros, unos jóvenes del movimiento 15M.

En el punto en el que yo llegué, hablaban en concreto sobre lo difícil que lo tienen los jóvenes para encontrar un trabajo. Hasta aquí todos de acuerdo, pero mi sorpresa llegó cuando uno de ellos; que creo recordar nunca había trabajado; espetó la frase lapidaria "Yo no trabajo por 800 míseros euros".

Al oír la frase, me llamó la atención y seguí escuchando el debate. La verdad es que acabé impresionado, o más bien indignado, hasta tal punto que apagué la televisión.

Entiendo que un joven que acaba de terminar la carrera (no se si era el caso), aspire a un trabajo relacionado con sus estudios y con una retribución salarial acorde a su nivel de estudios o experiencia, si es el caso. Lo que no entiendo es como se puede hablar con desprecio de un trabajo de 800 euros.

Seguramente este joven (o esta, no lo recuerdo), vive en casa con sus padres, no le falta comida, ropa y dinero para gastar el fin de semana, porque sus padres se lo pueden permitir.

Supongo que si no tuviera el paraguas de sus padres y sin otra fuente de ingresos, no le haría tantos ascos a los 800 míseros euros. De hecho, hay familias enteras en este país, que viven con esos ingresos.

Aplaudo que los jóvenes reivindiquen reformas laborales, económicas o sociales, de hecho creo que lo deberían hacer más frecuentemente y con más ahinco. También estoy de acuerdo que en la situación económica actual, los jóvenes tienen muy complicado encontrar un trabajo, independizarse, etc.

A veces escucho decir, que antes los jóvenes lo tenían más fácil, había trabajo para todos. Es cierto que antes había más facilidad para encontrar trabajo, pero también creo que es cierto, que se ha perdido cierto "garbo" o "coraje" para saber buscarse la vida, aunque en esto, seguramente parte de la culpa recae en los propios padres.

La situación laboral es complicada para los jóvenes que buscan trabajo, pero no nos olvidemos que es complicada también para los que no son tan jóvenes y cuando se tienen responsabilidades, lo primero es saber buscarse la vida.

Hay un punto que me gustaría resaltar, y es que tan complicado es encontrar un trabajo como saberlo mantener. En esta vida nadie te regala nada.

No nos engañemos, las empresas no son ONGs y están ahí para ganar dinero, así que no nos van a dar nada que no nos hayamos ganado previamente. Bien es cierto que hay quién se aprovecha de la coyuntura para para dar una vuelta de tuerca más y engordar la cuenta de resultados a costa del sacrificio ajeno.

Un trabajo de 800 euros no es para toda la vida, pero puede servir para adquirir experiencia, saber valorar el trabajo y ser un primer paso para encontrar otro mejor.

El tiempo, ese bien tan preciado

A menudo nos surgen reflexiones sobre el poco tiempo que tenemos, lo que nos gustaría hacer si tuviéramos tiempo o como malgastamos nuestro tiempo, entre otras.

Está claro que el tiempo es un bien muy preciado, todos creemos tener poco y queremos tener más. Algunos incluso cambiarían dinero por tiempo.

 En muchas de las circunstancias en las que nos referimos al tiempo, lo hacemos usando las mismas expresiones que utilizamos para referirnos al dinero: gastar el tiempo, ahorrar tiempo, invertir el tiempo, robar tiempo, etc., pero el tiempo no se puede atesorar y utilizarlo cuando lo necesitamos, tampoco podemos comprarlo o venderlo, el tiempo sencillamente pasa, da igual en que lo hayamos ocupado. 

Existen algunas iniciativas que se denominan "bancos de tiempo", donde por decirlo de una forma sencilla, se deposita el compromiso de disponibilidad de x horas de tu tiempo para realizar una actividad, las cuales se pueden canjear por otras tantas x horas del tiempo de otra persona en otra actividad. Como iniciativa de comunidad, no está mal, pero ¿por que llamarlo banco de tiempo?.

Ya que se utiliza el símil del banco, como si de dinero se tratase, veamos que la similitud no lo es tanto:

En un banco se deposita dinero por diferentes motivos: seguridad, rentabilidad, etc. Si yo deposito el compromiso de 1 hora de mi tiempo en uno de estos bancos, pasado un año, ¿tendré más de 1 hora?, pues no, ni mi tiempo estará más asegurado.

Si no tengo tiempo, ¿puedo pedir un préstamo? ¿que garantía daré?, pero yo necesito tiempo para estar con mi familia y con mis amigos, ¿va a venir un señor que sí tiene tiempo para estar con mi familia?, en fin, sin comentarios.

Si yo no tengo tiempo para arreglar un grifo, puedo cambiar ese tiempo con un fontanero para que me arregle el grifo, pero también puedo pagarle con dinero. ¿He comprado tiempo?, pues tampoco.

Hablamos también de "ladrones de tiempo", refiriéndonos a pequeñas interrupciones en nuestro trabajo, pero ¿se queda el ladrón con mi tiempo, yo tengo menos y el más?.

El tiempo es una dimensión en un solo sentido, solo fluye hacia adelante, aunque según Stephen Hawking e incluso el propio Albert Einstein, a distintas velocidades según donde nos encontremos. Por ejemplo, el la singularidad, al borde de un agujero negro.

Si tuviéramos una máquina del tiempo que nos permitiera viajar a través de él, ¿tendríamos más tiempo?, pues tampoco. Da igual cuanto tiempo haya pasado para los demás, el nuestro no habrá encogido o estirado.

Decía San Agustín: "No hubo tiempo alguno en que no hubiese tiempo".

Siempre hay tiempo, solo tenemos que elegir lo que hacemos mientras este trascurre de forma inexorable a pesar nuestro.

La cuestión, no es tener más tiempo, sino que nos sintamos a gusto con las actividades que hemos realizado durante su trascurso. Unas veces "hemos aprovechado el tiempo",  otras veces lo hemos "malgastado" y otras, sin más, lo hemos "gastado", da igual si hemos estado trabajando o de vacaciones.

Hay bienes inmateriales, como el tiempo o la razón. El tiempo, todos tenemos el mismo y todos queremos tener más, en cambio la razón, no todos tenemos la misma, pero todos creemos tener suficiente.

Sobre cerdos y gallinas

Aunque muy conocida la fábula o chiste del cerdo y la gallina, lo voy a reproducir en versión libre, para que sirva de introducción para el que no lo conozca.

“Se encuentran un cerdo y una gallina y deciden abrir un restaurante.

El cerdo dice: ¿como llamaremos al restaurante?

La gallina responde: Huevos con bacon

El cerdo contesta: No me parece justo, yo estaría comprometido mientras que tú solo estarías involucrada”

Los roles “cerdo” y “gallina” están presentes en todos los ámbitos de la vida, no solamente en SCRUM :-). En todas las comunidades, sociedades, equipos y convivencias, hay roles cerdo y gallina en mayor o menor medida.

La diferencia entre estar involucrado o comprometido, que a priori, se podría asociar al nivel de riesgo que se toma al participar en un proyecto; laboral o sencillamente de relación, en muchos casos se vuelve algo absolutamente subjetivo y cada uno cree ocupar un rol, que no es visto así por los demás.

Tenemos como “gallinas innatas” a aquellas personas que que se dedican a “estar”; en algunos casos, solo a “figurar”, que arriman el hombro en contadas ocasiones y solo, cuando no queda más remedio. Algunos de estos “fasiánidos”, suelen tener una habilidad especial, para aparecer cuando ha finalizado el trabajo.

Tenemos como “cerdos de vocación”, a aquellas personas que lo dan todo, que no reparan en sacrificios para conseguir el buen fin del proyecto y con los que puedes contar cuando se ponen las cosas feas. Este tipo de “suidos”, a menudo se ven eclipsados por los “fasianidos” cuando las cosas salen bien y cargan con las culpas cuando la cosa se tuerce.

Esta categorización puede parecer un poco extremista y de hecho, lo es, pero ¿le suena a alguien?. La realidad no es blanca ni negra y oscila sobre la escala de grises con el tiempo.

¿podemos elegir nuestro rol? . No, generalmente nos viene impuesto en cada caso, además no suele ser buena idea cambiarlo, no suele acarrear buenos resultados. Cada momento y cada escenario son una partida distinta, solo puedes jugar las cartas o pasar la mano, habrá otras.

El grado de implicación y compromiso es difícil de medir, además, bajo determinadas circunstancias, todos tendemos a pensar que los demás son las “gallinas” y nosotros los “cerdos” y esto en realidad no es más que un reflejo de nuestra propia frustración.

El cerdo y la gallina, sí pueden poner un restaurante juntos, solo hace falta cambiarle el nombre a "La tortilla de patata".

Las nubes también se caen II

Habrá que esperar algunas semanas más, antes de sacar conclusiones acerca de como va a afectar a Amazon y al Cloud Computing en general, la caída de los servicios de Amazon (Las nubes también se caen), pero de momento no parece que vaya a ser una catástrofe para Amazon, ni que esto vaya a provocar un cambio de tendencia en la adopción del Cloud Computing por parte de las empresas.

Lo que si es seguro, es que este "incidente", va a marcar un punto de inflexión en muchos aspectos relacionados con el Cloud Computing.

Amazon tendrá que hacer algo más que pedir disculpas a sus clientes y regalarles 10 días gratis de servicios. Tendrá que volver a ganar la confianza perdida y para ello deberá actuar en varias líneas de mejora.

Evidentemente, deberá poner el foco en como mejorar los procesos de mantenimiento, automatización de tareas, supervisión de procesos, monitorizaciones, etc. ya que en este caso han sido los causantes del problema.

Desde el punto de vista técnico, deberá replantearse el modelo de replicación de datos entre Zonas. Está claro que los mecanismos de aislamiento entre Zonas de Disponibilidad, no han sido lo suficientemente efectivos. El factor comunicaciones ha sido determinante.

En cuanto a comunicación y transparencia también deberá aprender de lo ocurrido. Desde siempre han sido bastante reacios a dar más información y explicaciones que las estrictamente necesarias, pero tiene que pensar que la información a sus clientes ante una caída de este tipo, puede ser beneficiosa en el sentido de que los propios clientes pueden colaborar en restaurar la situación global, ayudando a restaurar la suya propia.

El SLA que proporciona Amazon no está a la altura de las circunstancias. Cualquier empresa que decida externalizar los servicios con un tercero, negociará un SLA con su proveedor. En este caso Amazon no puede negociar con cada cliente un SLA particular ¿o si?, pero lo que si puede hacer, es proporcionar un SLA de verdad, donde se garantice algo más que un porcentaje de up-time.

Pero no solamente Amazon se deberá poner las pilas, y cuando digo Amazon, quiero decir además Microsoft, Akamai, Google, IBM, etc., sino los propios "usuarios". El proveedor Cloud ofrecerá una serie de ventajas y garantías para asegurar la disponibilidad del servicio, o en su caso, minimizar el impacto de una caída, pero el propio cliente debe hacer lo propio con su modelo de aplicación y despliegue. No es tan sencillo como poner la aplicación "en la nube" y esperar que el proveedor Cloud haga el resto.

El diseño de las aplicaciones, desde el punto de vista de disponibilidad y de seguridad es un aspecto que no va a cubrir en su totalidad el proveedor. Tampoco es que sea algo distinto de lo que se debiera hacer en un modelo on-premise, pero el contexto es diferente y las herramientas de las que dispone el cliente, no son las mismas.

Como se suele decir, "a río revuelto, ganancia de pescadores" y a buen seguro, otros proveedores Cloud, verán en este capítulo, una excelente oportunidad de ampliar su base de clientes, no solo por que abandonen Amazon, sino porque muchos de ellos, o al menos los más importantes, diversificarán sus implementaciones Cloud entre varios proveedores.

Lo que le ha pasado a Amazon, le puede pasar a cualquiera. Mejor dicho, le ha pasado a casi todos, en mayor o menor medida.

En general, no creo que vaya a cambiar nada en cuanto a la estrategia; a nivel de decisión; de movimiento hacia la nube, aunque quizá los modelos híbridos de nube pública y privada ganen posiciones frente al modelo de nube pública en exclusiva. Reddit, uno de los afectados por el "apagón", ya se ha pronunciado en este sentido.

Las nubes también se caen

La semana pasada se produjo la caída de los servicios EC2 de Amazon (Amazon Elastic Compute Cloud), los cuales tardaron varios días en recuperarse al completo. La caída afectó a conocidas empresas como Foursquare, Reddit, Quora o Hootsuite entre otras.

El impacto mediático ha sido notable, sobre todo teniendo en cuenta que en plena efervescencia del Cloud Computing, una caída de este tiempo en un proveedor de la envergadura de Amazon, da argumentos a los detractores del Cloud Computing.

Amazon tiene sus datacenters repartidos en 5 regiones; 2 en EE.UU. (costa este y oeste), uno en Europa (Irlanda) y 2 en Asia (Tokio y Singapur); y cada región se separa varias Zonas de Disponibilidad (AZ – Availability Zone). Cada AZ está aislada de las demás y entre ellas no debe haber puntos comunes de fallo, al menos es lo que publicita Amazon.

Todo comenzó el jueves 21 de abril, durante una operación rutinaria en la AZ del Norte de Virginia en la Región Este de EE.UU.. Por un error, se desvió el tráfico de uno de los routers a la red de backup, que dispone de menos capacidad y una mayor latencia. Esto provocó una atasco que se se convirtió en una reacción en cadena, primero en nodos EBS (Elastic Block Store), después en las API de control de los cluster EBS, el RDS (Relational Database Service), que se soporta en el EBS. Esto acabó afectando a todas las AZ's de la misma región.

Amazon no proporciona un servicio de replicación entre regiones, aunque si entre AZ's, a cambio, proporciona un API para que cada usuario pueda gestionar la tolerancia a fallos entre regiones. Aunque en menor medida, por este motivo otras regiones tuvieron pequeños “atascos”, que Amazon lo cuantifica en un 0,07%.

Muchos clientes, se han quejado de la poca transparencia e información que proporcionó Amazon durante la caída. En un principio la única información fue la que proporcionaba el monitor de AWS  (Amazon Web Services). De hecho, algunos clientes indican que si hubieran dispuesto de más información acerca de los motivos, hubieran podido recuperar antes sus sistemas.

Algunas quejas, como las de Justin Santa Barbara (Why the sky is falling), fundador y CEO de FathomDB, van en el sentido de que AWS no cumple sus propias especificaciones y ha roto sus promesas de disponibilidad dentro de las AZ's, aún cuando los sistemas desplegados siguieran las especificaciones de Amazon al respecto.

Pero no todo el mundo se ha quejado del incidente, de hecho hay quién indica que el perjuicio sufrido está compensado con las prestaciones y el precio que Amazon proporciona a sus clientes.

La verdad es que no todos los clientes de Amazon en la AZ afectada, que por cierto, es la más concurrida, se han visto afectados, o al menos de la misma forma. En concreto NetFlix o Twilio, no sufrieron las consecuencias.

En el caso de Twilio; según explica Evan Cook en su blog, el diseño de sus aplicaciones, el poco acoplamiento entre ellas y la distribución de los servicios, les ha permitido no verse afectados por esta caída. Quizá Amazon quiera incluir algunas de las recomendaciones que hace Evan, en sus propuestas de despliegue.

Después de todo el chaparrón, Amazon ha publicado un informe, que lo han denominado “post-mortem” explicando lo ocurrido y donde finalmente dice que “recompensará” a los clientes con instancias EC2 en la AZ afectada, con el equivalente a 10 días del consumo de los volúmenes EBS, instancias EC2 e instancias RDS, que tenían contratados en el momento de la caída.

Curiosamente, dado que la caída del servicio ha sido de 4 días, y teniendo en cuenta que; tal y como publican en el FAQ, el up-time que garantiza es del 99,95%, legalmente no se han incumplido los términos de SLA.

Ahora es tiempo de sacar conclusiones, no solamente por parte de Amazon, sino por parte de proveedores de Cloud Computing y de usuarios, actuales y futuros. Esto debe servir para aprender y mejorar los servicios y aplicaciones que corren en este modelo. En cierto modo, es bueno que pasen estas cosas.

El rastreo de iPhone y Android

Hace unos días se conocía que los iPhone e iPad  de Apple guardaban un registro de las posiciones de los usuarios (más bien de sus teléfonos) y que por si fuera poco, esos datos se registraban en un archivo sin protección. Unos días más tarde, conocemos por un artículo en The Wall Street Journal, que Google hace lo mismo con sus teléfonos Android .

El tema ha creado bastante revuelo desde que se ha conocido. Corea del Sur ha pedido explicaciones a Google y el senador de EE.UU. Al Franken, ha hecho lo propio con Apple, escribiendo una carta a Steve Jobs, en la que le pide respuestas a una serie de preguntas sobre el tema.

En el caso de Apple, se disculpan diciendo que los datos de localización solo se registran cuando el usuario utiliza una aplicación que requiere localización, después los datos se envían encriptados cada 12 horas a Apple. 

En el caso de Android, la información se recoge cada pocos segundos y se envía varias veces por hora a los servidores de Google, con la diferencia de que en este caso, los datos se relacionan con el identificador único del teléfono. Google se disculpa diciendo que lo hace bajo el consentimiento del usuario.

Google y Apple, no pierden tiempo en tomar posiciones en los servicios de localización y coger su trozo de pastel en este mercado, en el que según Gartner, alcanzará los 8,3 billones (US) de dólares .

A mi personalmente, no me apetece que alguien pueda saber donde he estado en los últimos meses, aunque es por el mismo motivo por el que no tengo un perfil de Facebook donde publico las fotos de mis últimas vacaciones.

Como de todo tiene que haber en este mundo, hay quién a todo esto le encuentra la gracia y lejos de molestarles el asunto, se divierten revisando sus itinerarios y como no podía ser de otra forma, publicándolos en Facebook o cualquier otra red social, nada nuevo teniendo en cuenta el éxito de Foursquare o Facebook Places.

Al poco de conocerse la noticia de que los iPhone guardaban los datos de localización en un archivo desprotegido, estaba disponible la aplicación iPhone Tracker, una aplicación de código abierto, que permite visualizar los sitios en los que se ha estado en los últimos meses, desde que comenzó la grabación de los datos.

Si los datos de geolocalización son de fácil acceso y a eso le sumamos que los ataques dirigidos cada vez son más frecuentes y precisos, no será de extrañar que ya esté en circulación algún tipo de malware específico para iPhone, encaminado a saber donde han estado ciertas personas en los últimos meses.

En el caso de iPhone, también existe una aplicación llamada Untrackerd que borra constantemente el archivo donde se guardan estos controvertidos datos.

Releyendo Scrum y XP desde las Trincheras

El otro día se me ocurrió volver a leer el clásico de la literatura Scrum “Scrum and XP from the Trenches”, con el objetivo de comparar la aplicación de Scrum que se comenta en el libro y la que practicamos en mi organización. 

Cuando leí el libro por primera vez, antes de comenzar a aplicar Scrum, a medida que leía el libro trataba de prestar atención en aquellos aspectos en los que el autor ponía más énfasis, suponiendo que una vez inmerso en la práctica, esas cuestiones serían a las que más importancia darle. De forma inconsciente, fui haciendo una selección de estos aspectos para quedarme con un top-10.

Después de volver a leer el libro, e intentar hacer un top-10, la verdad es que lo he tenido más difícil, ya que algunas cuestiones que pasé por alto en su momento, han adquirido ahora una especial relevancia.

En el libro se insiste en que no hay una regla única para aplicar Scrum y que se debe probar con diferentes formas de hacer las cosas, hasta dar con la que mejor se ajusta al contexto donde se aplicará. En efecto eso es así, tanto que incluso si en la primera iteración de su aplicación nos encontramos cómodos, debemos probar a hacer cambios, incluso a sabiendas de que alguno de los cambios que hagamos será a peor, pero eso también sirve para encontrar el modelo óptimo para tu caso.

No se debe tener miedo a cambiar las cosas incluso si creemos que lo que hacemos ya está bastante bien. La mejora continua, debe ser una constante.

Volviendo al tema del libro, uno de los aspectos a los que se le da mucha importancia, pero que yo no supe ver en su plenitud tras la primera lectura, es el conocimiento de la velocidad de los equipos. Al principio pensé que era un indicador más, pero he observado que es vital en dos aspectos que inicialmente no di demasiada importancia: la reducción del riesgo y la mejora continua.

Reducción del riesgo: La estimación y la planificación de un proyecto, no tendrá base objetiva si no conocemos este dato y por lo tanto, estaremos más expuestos a incurrir en retrasos y sobrecostes, sobre todo cuanto más grande sea el proyecto.

Mejora continua: La evolución de la velocidad de los equipos, será un claro indicador de la madurez de los equipos, y como eso se traduce en una mejora de sus resultados. Si analizamos los picos y valles en la evolución de las velocidades y los contrastamos con acciones o cambios introducidos en los equipos, podremos sacar jugosas conclusiones.

Otro aspecto que ha adquirido una especial relevancia para mi, ha sido la importancia del artefacto “Sprint Burn Down Chart”, sobre todo si comparamos la evolución de estas gráficas a lo largo de los distintos Sprints. El seguimiento diario de su evolución permite aprender mucho de como estamos distribuyendo y abordando las historias. No hace falta asistir a todos los “Daily” para darse cuenta mirando este gráfico, de que algunos miembros del equipo repiten durante demasiados días “Sigo trabajando en X”.

La verdad es que ha sido un buen ejercicio leer de nuevo este libro, ha sido como juntarse con algún colega para compartir experiencias sobre Scrum.

No se si ya lo ha dicho alguien antes, pero se me ocurre que un buen consejo para finalizar, sería: “Se práctico y no escatimes esfuerzos en ahorrar trabajo”.

Si alguien no conoce el libro y está interesado en su lectura, se puede descargar de Internet en formato PDF, tanto en inglés como en castellano. Es una lectura amena y no lleva demasiado tiempo leerlo.

No pongo ningún enlace ya que se puede encontrar con facilidad y existen numerosos sitios de descarga.

20 años de Linux

Para algunos será una eternidad y para otros un suspiro, pero la verdad es que ya han pasado 20 años desde que el señor Linus Benedict Torvalds escribió el ya célebre mensaje de correo en el que anunciaba la creación de lo que más tarde, todos conoceríamos como Linux:

“Hello everybody out there… I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) … It is NOT portable …and it probably will never support anything other than AT-harddisks, as that’s all I have :-(”

En aquellos momentos, allá por abril de 1991, cuando Linus escribía este mensaje, no podía ni imaginarse la repercusión de lo que estaba gestando, así como tampoco lo equivocado que estaba cuando pensaba que nunca soportaría otro hardware más allá de su 386.

Evidentemente  hay mucha gente que no sabe que es esto del Linux, pero sin darse cuenta, en muchos casos lo están usando sin saberlo, en su teléfono móvil, en su cámara fotográfica o en el mismo cajero automático.

Aunque no sean los hitos más importantes en la historia de Linux, me gustaría reseñar unos pocos, que por diferentes motivos, me parecen interesantes:

• Agosto de 1991- El nacimiento: se publica la primera versión del kernel de Linux
• Abril de 1993-La primera apuesta por Linux: aparece Slackware la primera distribución de Linux y la más antigua ya que aún existe.
• 1996-Nace TUX:  Larry Ewing crea TUX, el pingüino símbolo de Linux.
• 2003-La apuesta de los gigantes: IBM sorprende al mundo con el anuncio de IBM-Linux durante la Super Bowl.
• 2010-Se abre una nueva era para Linux: Google crea Android, basado en el kernel de Linux

Aunque no lo podría catalogar como un hito, entre 2009 y 2010 la distribución Ubuntu, que aunque lleva en la calle desde finales de 2004, da un salto cualitativo acercando Linux al usuario de a pié, haciendo una distribución más fácil de usar y más amigable que otras anteriores, de hecho, actualmente tiene una cuota del 50% entre los usuarios de Linux.

Durante estos 20 años ha habido luces y sombras, pero Linux se ha mantenido firme, buscando su sitio poco a poco, a pesar de detractores como el propio CEO de Microsoft, Steve Ballmer, quién llegó a calificarlo en 2001 como:  "Linux es un cáncer que se pega a la propiedad intelectual"

A lo largo de estos 20 años, hemos ido viendo como Linux iba cambiando, algunas veces incluso a peor; el propio Linus llegó a decir en algún momento, que KDE era un desastre; pero poco a poco ha ido ganando posiciones en todos los sentidos.

La mayoría de los sitios web en Internet utilizan servidores Linux, los grandes superordenadores también, pero el desktop siempre se le ha atragantado. En este sentido Ubuntu y Android están consiguiendo cambiar la tendencia. ¿El truco?, hacer las cosas más fáciles para el usuario, esa siempre ha sido la clave del éxito. No solo sirve disponer de miles de aplicaciones gratuitas para Linux si estas son difíciles de instalar, de actualizar o de usar.

En alguna entrevista, Linus ha reconocido que Ubuntu ha hecho un gran aporte al mundo Linux por su sencillez de uso para el usuario final, aunque por otro lado también reconoce que no es cómodo para los desarrolladores del Kernel, pero ¿Cuántos desarroladores de Kernel hay?.

Donde Linus no tiene dudas es con Android, ¡está encantado!

Aunque habrá que esperar hasta agosto… Feliz Cumpleaños, Linux!!!

Factores clave en la adopción de Scrum por las empresas de TI

Las metodologías ágiles en general y Scrum en particular, están gozando de creciente aceptación y aplicación en nuestras empresas de TI. Aunque estas metodologías no son nuevas, si es verdad que en los últimos 2 o 3 años se han percibido sus beneficios de forma sustancial, todo ello motivado seguramente por aspectos externos como el propio mercado, la crisis económica, etc.

La metodología Scrum tiene unos fundamentos sencillos y aunque a primera vista pueda parecer simple de aplicar y nada nuevo respecto a lo que hemos venido haciendo tiempo atrás, en realidad no es así y aunque sus principios son pocos y sencillos, es imperativo seguirlos para que la aplicación de la metodología consiga el objetivo.

Sin entrar en detalle de como se aplica la metodología, que significan sus roles, artefactos, métricas, etc., si me gustaría señalar algunas cuestiones clave para la aplicación de Scrum y sobre las cuales merece la pena reflexionar antes de adoptar esta metodología.

En cualquier caso, antes de plantearse adoptar Scrum como metodología de trabajo, habrá que pararse a pensar si cumplimos ciertos requisitos o qué podemos hacer para cumplirlos antes de comenzar.

Aunque hay muchos aspectos importantes a valorar, como por ejemplo la comunicación, la implicación del cliente, la estabilidad, etc., quiero centrarme en dos que para mí tienen una especial relevancia: El Cambio organizacional y el Compromiso del equipo.

El cambio organizacional

Por lo general, en la mayoría de las empresas, existe un organigrama demasiado jerarquizado, que no encaja demasiado en la definición de roles de Scrum. En este sentido, la dirección de la empresa debe remodelar la estructura para “achatar la pirámide”.

El cambio organizacional, es quizá el más controvertido a la hora de aplicarlo. Ya no tiene sentido hablar de Jefe de Departamento, Jefe de Proyecto, Analista Funcional, Analista Programador, Programador Senior, etc. donde cada uno parecía tener sus funciones acotadas y de la misma forma que representaba la estructura, se procedía a un trabajo en cadena, donde cada uno hacía una parte y se la pasaba al siguiente. Esto en Scrum ya no tiene sentido.

Es un error habitual, es asimilar el rol tradicional de Project Manager al de Scrum Master. Un Project Manager puede convertirse en Scrum Master, si sus skills le permiten ser un facilitador, pero ya no tiene por que ser un buen gestor. Ahora el equipo se autogestiona.

Es complicado para la empresa, acometer un cambio en la estructura, pero seguramente es más complicado para las personas, que de repente pierden su “status” y se disuelven en un “Scrum Team”. Esto hay que saberlo gestionar adecuadamente para que se traduzca en una oportunidad en vez de una amenaza para las personas.

El compromiso del equipo

En Scrum, el equipo y el trabajo en equipo adquieren una nueva dimensión, ahora el equipo es un ente con atribuciones que hasta ahora, solo recaían en ciertas personas en particular. Ahora el equipo se autogestiona y toma sus propias decisiones.

El objetivo es pensar en el equipo como un ente único, pero queramos o no, los equipos los forman las personas y las personas tienen sus virtudes y sus defectos.

Las personas brillantes son siempre bienvenidas en todos los equipos, pero el problema surge cuando alguna de estas personas por ego profesional o personal, trata de imponer sus criterios o manipular al resto del equipo. Las individualidades deben supeditarse al equipo y el éxito o el fracaso es siempre del equipo, no de las personas por separado.

Cualquier persona, siempre tiene algo que aportar al equipo, solamente es cuestión de buscar que es y aprovecharlo. No sirve dejarse llevar, siempre hay que aportar.

Dentro del equipo, las personas deben confiar unas en otras y ser transparentes en su trabajo, si no es así, deberán cambiar algunos de sus anteriores hábitos.

El cambio de mentalidad puede llegar a ser un problema si no se gestiona adecuadamente por parte de la organización. En este sentido, será preciso hacer una labor de mentalización y convencimiento para que las personas tengan claro que su apuesta debe ser por el equipo.