viernes, diciembre 19, 2008

Hadoop@Facebook

viernes, diciembre 19, 2008 por Martín


Los que trabajan en el mundillo de Hadoop seguro que ya conocen que Facebook hacía bastante uso de esta herramienta. Yo, por mi parte, me encontré la semana pasada con un conjunto de notas en las que se comenta el uso que Facebook esta haciendo de esta herramientas. Las notas son ya de Junio de este año, asi que como comento, alguno ya las tendrá más que vistas.

La verdad es que las notas son bastante impresionantes. Aquí va un pequeño resumen:

  • Facebook tiene una enorme cantidad de datos históricos, fruto de las decenas de millones de usuarios y el mas de un billón(americano) de páginas vistas por día, que necesita almacenar y procesar.

  • Comenzaron a utilizarlo en el 2007 con cierto escepticismo, pero parece que pronto se probó útil tras realizar algunas aplicaciones internas de proceso de datos. Alguna como Facebook Lexicon, una herramienta para contar la ocurrencia de palabras en los muros de los usuarios, ha visto la luz externamente.

  • Facebook tiene ahora mismo desplegados múltiples clusters de Hadoop, constando el más grande de 250 núcleos y 1 Petabyte de espacio en disco.

  • Cada día cargan sobre 250Gb de datos comprimidos (2 Terabytes descomprimidos) en Hadoop, y hay cientos de trabajos que se encargan de explotar estos datos.

  • Las aplicaciones realizadas han ido evolucionando de aplicaciones estadísticas hacia aplicaciones más interesantes como la detección de spam o el determinar la calidad de las aplicaciones de terceros.

  • Hadoop se ha mostrado como simple de utilizar y de aprender. En Facebook, los desarrolladores son libres de elegir el lenguaje que quieran para sus aplicaciones con Hadoop. El acceso a datos lo realizan utilizando un subconjunto del lenguaje SQL, lo que hace mas sencillo su manejo.

  • Con el tiempo han ido añadiendo algunas funcionalidades propias de un sistema de data warehousing que han desembocado en un framework llamado Hive desarrollado por Facebook pero que ahora es un subproyecto de Hadoop.



Otras notas mias sobre Hadoop.

lunes, diciembre 15, 2008

Jobsket gana la Beca Alzado 2008

lunes, diciembre 15, 2008 por Martín


Que alegría hoy al ver que Jobsket ha ganado la Beca Alzado 2008.

En Octubre anunciamos públicamente Jobsket e iniciamos el proceso de registro. Desde entonces hemos estado trabajando sin parar (en nuestros ratos libres). Hace unos meses cuando anunciaron la Beca Alzado, que por cierto es una iniciativa fenomenal, no le dimos demasiada importancia porque el producto todavía estaba muy, pero que muy verde. Pero poco a poco fue mejorando y llegó un momento en que necesitábamos, sí o sí, el evaluar nuestra idea.

Por eso nos presentamos a Jobsket, para que no sean sólo nuestros amigos y conocidos los que nos digan que lo que estamos haciendo es muy interesante. Y parece ser que alzado.org y la gente que está detrás (Luis Villa, César Martín y Eduardo Manchón) han considerado que sí, que puede funcionar. Por eso estamos enormemente agradecidos y creo que este premio puede ser un empujón mediático y de moral realmente importante.

Seguro que los que leéis esto ya estáis suscritos a la beta, pero si no lo estáis no se a que estáis esperando :-)

Por cierto que hemos creado el blog de Jobsket donde tambien hablamos un poquillo del premio. No se os olvide añadirlo a vuestros RSS :)

domingo, diciembre 14, 2008

Un context ad de Domingo perfecto

domingo, diciembre 14, 2008 por Martín

Repasando mis lecturas domingueras me he encontrado con un chiste de Domingo (via otra vez ReadWriteWeb). Trata sobre Facebook y como hoy por hoy es posible que te enteres antes por Facebook de lo que pasa en tu vida que por la gente con la que vives.



El chiste tiene su gracia, pero para mi lo realmente bueno es el anuncio de PlentyOfFish. ¡La asociación entre el anuncio y el post es brillante! De hecho me ha hecho mirar en el contenido del feed a ver como diablos lo han hecho, y lo único que encuentro serían las referencias a FriendFeed o Facebook en el texto del post, o el propio texto en la imagen. No sé si es casualidad o no, pero si no lo es entonces está claro que en el equipo de FeedBurner hacen los deberes.

Google publica un libro para desarrolladores sobre seguridad en navegadores web

domingo, diciembre 14, 2008 por Martín



Últimamente Google ha estado cogiendo algo de mala fama por reusar contenido libre, atacar todos los frentes posibles, pero no devolver nada a la comunidad. Pues bueno me entero via ReadWriteWeb de que acaban de publicar un libro titulado Browser Security Handbook bajo licencia Creative Commons 3.0.

El autor del libro es Michael Zalewski y su contenido está principalmente orientado hacia desarrolladores web. El libro consta de tres partes, la primera comenta los fundamentos de los navegadores web en cuanto a gestión de URLs, soporte de JavaScript, CSS, ett. La segunda parte trata sobre la seguridad en los navegadores web y procede a comentar diferentes mecanismos y los compara para diferentes navegadores; por último, la tercera parte comenta algunos sistemas experimentales de seguridad y características especificas de algunos navegadores web como Internet Explorer o Mozilla.

Parece un libro a tener en cuenta. Si os interesa el tema, y no lo habéis hecho ya, pasaros también por mis posts sobre OWASP que contienen entradas con información similar.

martes, diciembre 09, 2008

¿Escala Java? Entrevista a Todd Hoff.

martes, diciembre 09, 2008 por Martín

Ayer estuve escuchando un podcast de JavaWorld en el que entrevistan a Todd Hoff y en el que charlan alrededor de treinta minutos sobre Java y escalabilidad. Todd Hoff es la persona que está detrás del sitio web de referencia hoy en día en cuanto a escalabilidad, High Scalability. Os podéis descargar este podcast en formato MP3 desde este enlace

El podcast es ameno de escuchar, y se centra alrededor de la pregunta de sí Java es una plataforma escalable o no. Aquí va un resumen de algunos de los puntos tratados y con los que no puedo estar más de acuerdo:


  • La escalabilidad no depende del lenguaje sino que depende de la arquitectura. Un sistema no escalará más por estar escrito en Ruby, C, Java o Scala sino que escalará dependiendo de la arquitectura del sistema, de si se puede hacer caching, sharding, si el procesado es síncrono o asíncrono, si se está o no compartiendo estado entre nodos, etc.

  • El gran valor de Java está en la platforma, las herramientas y la comunidad, y eso inevitablemente ayuda a escalar. Si tengo algún problema, hay innumerables fuentes de información para solucionarlo. Si un framework no funciona, hay innumerables alternativas para sustituir ese framework.

  • Java favorece demasiado al desarrollador. El sistema de bloqueos de alto nivel, el fomentar el compartir estado o el sugerir la arquitectura en capas o la recolección de basura no ayudan en cuanto a alta escalabilidad. Se favorece la escalabilidad vertical, es decir un servidor con 24Gb de RAM en lugar de 6 de 4Gb. Todo esto ha hecho que aparezcan soluciones "raras" como Azul que virtualiza en Hardware la JVM y que nunca deberían haber sido necesarios.

  • Intentar moverse a un modelo de SaaS. ¿Es realmente necesario un servidor de aplicaciones? Linkedin por ejemplo basa su arquitectura simplemente en Jetty. Las capas tienden a estorbar cuando hablamos puramente de escalabilidad.



Se tratan otros temas pero eso es con lo que me quedo. Por cierto que en la propia High Scalability hacen también un resumen sobre esto mismo y otros temas que se han ido comentado últimamente sobre Java y su habilidad para escalar.

lunes, diciembre 08, 2008

Cuenta gratuita en ExternalTest.com para los lectores de Pensamientos Agiles

lunes, diciembre 08, 2008 por Martín


Este es un post que me hace mucha ilusión ya que es absolutamente la primera vez en la que alguien se pone en contacto conmigo para regalar algo a través de este blog. Todo viene a raiz de este post y este comentario.

El autor del comentario es Enrique Dominguez y muy amablemente me ha ofrecido una cuenta grauita para su producto ExternalTest y, lo que es mejor, una cuenta grauita para todo lector de este blog al que le interese. Lo único que tenéis que hacer para reclamarla es registraros en ExternalTest y enviar un email al usuario Enrique en su dominio externaltest.com (supongo que entendéis esto, el que no lo entienda es que no merece la cuenta :P) simplemente mencionando en el subject "BRIGOMP".

Atención, es importante que enviéis el email con el mismo email que uséis para registraros. El tipo de cuenta es "gratuita ilimitada", por lo que no os caducará jamás y podéis configurar hasta tres tests diferentes. Si tenéis requisitos más complejos podéis contactar con Enrique.

ExternalTest es un producto muy interesante. La funcionalidad es la que se podría esperar en este tipo de productos, y sirve para monitorizar servicios, no sólo HTTP sino que muchos otros protocolos como FTP, POP3, DNS, etc. Además tiene un modo de análisis de rendimiento que te viene a ofrecer los mismos datos que explicaba en el post sobre webpagetest. Repitiéndome en lo comentado en dicho post, el mayor atractivo es la ejecución de tests desde diferentes localizaciones lo que nos permite evaluar el impacto de la latencia sobre nuestras páginas web.



ExternalTest es un servicio muy orientado al mundo empresarial pero cualquiera que tenga una página web le puede sacar partido. Yo mismo se lo he sacado hoy mismo cuando mi servidor se ha caido y he recibido el email de alerta. Hay otros servicios como Pingdom que vienen a hacer lo mismo pero por lo que me comenta Enrique, los servicios adicionales que ofrecen son bastante más limitados:

"Pingdom es un servicio similar en lo básico, nosotros tenemos productos más avanzados para empresas como XTbox o XTvirtuabox que permite a nuestros clientes contar con todas las capacidades de monitorización en entornos locales (esto lo usa por ejemplo Prisacom en España para probar las latencias existentes entre sus accesos locales y los realizados desde sudamérica, por ejemplo) o XTsec, que permite realizar de manera automatizada pruebas de vulnerabilidades conocidas sobre tu paltaforma..."


Muchas gracias Enrique por el detalle.

sábado, diciembre 06, 2008

Lets pull a "sickie"

sábado, diciembre 06, 2008 por Martín

Es Domingo, así que toca chiste. Rompo por un momento la temática habitual de este blog para comentar algo que, por lo que he visto, nos choca a todos los españoles trabajando en irlanda. Se trata de los "Sick Days", o como diríamos nosotros "estoy enfermo, no puedo ir a trabajar".

Aquí en Irlanda, tomarse un día libre por enfermedad es realmente sencillo. Cada empresa se comporta de manera diferente frente a los sick days, aunque por lo general se pagan. Cada empleado, tiene derecho a cogerse dos días sick consecutivos sin que la empresa pueda pedirle ningún justificante, cosa que sería considerada como acoso. En la práctica, muchas empresas ni se preocuparían de comprobar nada incluso si un empleado se coge muchos más días, aunque quizás ahora con la crisis económica les interese un poco más.

Pues bueno, con todo este background informativo os podréis imaginar que los irlandeses tienen una extraña tendencia a caer enfermos. Especialmente en Viernes y en Lunes, mira tú que casualidad. Y es más, mira que esta extraña enfermedad suele afectar sólo a los que están fijos en las empresas, porque jamás he visto enfermar a alguien que cobre por días :)

Hablando con amigos irlandeses, todos coinciden en lo mismo, y es que, y a mi esto es lo que me parece más increible, ven estos sick days como un derecho que ellos tienen para que si un día les duele la cabeza, están resacosos, o no se encuentran bien para trabajar, o simplemente sus niveles de desidia se han disparado, pues puedan tomárselo libre. El argumento principal es que no van a ser productivos porque se sienten como enfermos. ¡Vaya cara vamos! :)

Pero bueno, aquí lo más importante es tener sentido del humor, y saber reirse de uno mismo. Y yo cuando veo este anuncio de Meteor en la tele es que me hace muchísima gracia. No sé que tal será de entendible ya que uno ya se ha acostumbrado al acento irlandés, de hecho sólo ver unos tipos vestidos de reno con acento irlandés barriobajero ya tiene su cierta gracia. Ahí os lo dejo a ver si os gusta.



Ay, my heads ringing :)

viernes, diciembre 05, 2008

Mapa de Startups: España vs. Irlanda

viernes, diciembre 05, 2008 por Martín

Los de Crunchbase han creado una aplicación de Google Maps muy chula, CrunchVision, que muestra un mapa de Google donde se ven las startups que están registradas en su base de datos.



En el mapa del mundo se puede apreciar claramente cuales son los hervideros de startups. La zona de California con 2109 compañías registradas mientras que la costa Este se va a las 1815. En Europa, la zona central acumula 965 startups de las cuales 485 se concentran en el área Londres/Paris. España se posiciona bastante en la cola con un total de 58 startups registradas. Esto no quiere decir que sólo existan 58 startups, ni mucho menos, significa únicamente que tan sólo esa cifra se ha registrado.

Echando un vistaza al mapa de España se puede ver lo que todos nos esperamos, y es que la mayoria se concentra en torno a Madrid y Barcelona. 27 compañías en la ciudad Condal.



Por curiosidad y para los más vagos, un par de capturas de la localización de algunas de las startups en Barcelona y Madrid.







Si nos vamos a Irlanda, un país con alrededor de la novena (contando irlanda del norte) parte de habitantes, pues resulta que está muy, pero muy cerca en número de startups registradas. Un total de 49 compañías, que son tan sólo 9 menos. O sea que tenemos una compañía menos por cada 9 millones de habitantes. Vaya estadísticas que me saco :-)



Haciendo un poco de zoom, pues lo esperado, la mayoría se concentra en el centro Dublín donde hay unas 28 compañías registradas.



Esto no es ningún tipo de estudio ni nada por el estilo ni se deben sacar conclusiones precipitadas, pero ¿por qué no tenemos más compañías registradas? Mi opinión personal es que es un tema de falta de nivel de inglés y concentración exclusiva en el mercado local. Dos factores que limitan enormemente las exportaciones de software. Pero esta es simplemente mi opinión. ¿Cuál es la vuestra?

jueves, diciembre 04, 2008

Latencia, monitorización de redes y microbursts.

jueves, diciembre 04, 2008 por Martín


El software para operar en mercados de valores es realmente apasionante. Desde fuera puede parecer muy aburrido pero una vez que estás dentro descubres que se trata de una lucha constante por la optimización. Minimizar la latencia es fundamental. En ese mundo, el que consigue que sus operaciones lleguen antes al mercado es el ganador. Y ahí cualquier cosa, ya sean switches, routers, servidores de aplicaciones o esa clase Java que está al final de toda la cadena y que envía el mensaje a la cola de MQ son importantes.

Todas estas cosas se multiplican por 1000 cuando estamos en una época de incertidumbre, y que en cualquier momento el mercado puede bajar un 5% o una moneda puede desplomarse frente a otra en cuestión de minutos. Muchas empresas emplean herramientas de monitorización para tratar de descubrir patrones de operación en el mercado. Estas herramientas pueden ser internas, como Wily Introscope con la uqe he trabajado y que no puedo más que recomendar, o externas.

Las herramientas internas tienen la ventaja de integrarse muy bien con el stack de la aplicación y de ofrecer información bastante específica, como tiempos que tardan en procesarse mensajes en colas, o el tiempo que tarda en ejecutarse un método determinado, etc. Sin embargo el inconveniente es que añaden una carga extra de proceso que irremediablemente impacta en la latencia, por lo que al final te ves obligado a desplegar una versión con monitorización mínima en producción; aunque son fenomenales para desarrollo, ya que ahí puedes permitirte monitorizar muchos más datos.

Por otra parte hay herramientas externas que funcionan ajenas a las aplicaciones y servidores y que se basan simplemente en capturar el tráfico de las redes y en analizar sus patrones para proporcionar información, generar gráficos y lanzar eventos a partir de ésta. Dentro de este sector se encuentra Endace. Por cierto que si os interesa el tema, Corvil es una empresa irlandesa que está teniendo también bastante éxito en este mundillo.

En Low Latency han publicado un pequeño podcast/entrevista de siete minutillos que explica algunas de estas cosillas y que es bastante ameno de escuchar. Es un poco publicitario, porque el entrevistado es Paul Doyce, Technical Manager de Endace, pero se lleva bastante bien.

También os lo podéis descargar directamente desde este link.

Photo via travel_aficionado@Flickr.

miércoles, diciembre 03, 2008

Probando el rendimiento de páginas web con webpagetest

miércoles, diciembre 03, 2008 por Martín

El otro día por una lista de correo a la que estoy suscrito descubrí
webpagetest
(dos post seguidos de descubrimientos, esto ya parece el blog de "Martín el Descubridor"). Lo he estado probando y la verdad es que es una herramienta espectacular. Fundamental para el análisis de rendimiento de páginas web.

Por una parte, nos permite evaluar el impacto de la latencia en nuestra aplicación web, ya que podemos probar como se cargarían las páginas desde Estados Unidos y Nueva Zelanda. Una pena por cierto que no tengan ningún host en Europa.

Por otra parte, los informes que te muestra son realmente completos. Por defecto, webpagetest carga la página que le mandas dos veces. Una para evaluar la carga inicial, y dos para evaluar como funcionan las cachés. Lo que esperaríamos normalmente es que la segunda ejecución sea mucho más rápida que la primera. Veamos el resultado si cargamos por ejemplo la página de Twitter:



Ok, si hacéis clic en la imagen lo veréis mejor. Han sido 4.5 segundos. Algo lentillo diría yo, aunque cierto es que es un servidor con carga y que muestra bastantes cosillas en la página principal. Aún así, una de las cosas que me llama la atención es la cantidad de bloques naranjas que se ven. Los bloques naranjas son establecimiento de conexión, y no deberían suceder tan a menudo si tu servidor permite el establecimiento de conexiones persistentes, algo por otra parte bastante común en la mayoría de servidores. Patrick Meenan, el creador de webpagetest, lo explica muy bien en este post.



Esta segunda imagen nos da una mejor idea de como funciona twitter. Bastante caché, uso de ETags, librerías javascript comprimidas, imagenes comprimidas y no CDN. Interesante.



En la imagen superior se observa que la recarga de la página ha dado unos mejores resultados, aunque todavía se aprecia que se ha empleado un segundo entero en descargarse la librería de lightbox. Seguro que hay mucho que mejorar por ahí. Se sigue también apreciendo que el servidor no mantiene conexiones persistentes.

Y bueno, a parte de todo esto webpagetest te ofrece un informe en formato texto con todo lo que se debe arreglar.


Mmm, por cierto, que se me olvidaba una cosa. ¿Es importante la latencia? Probemos a cargar Twitter desde Nueva Zelanda:



7.2 segundos. 3 segundos más que desde los Estados Unidos. Pobres amigos de las antípodas que tienen que soportar estas cosas :)

Lo que no acabo de ver es por que aquí sí que se utilizan conexiones persistentes. O será que quizás el servidor no lo muestra... ¿álguien que me ayude con esto?

El servidor de Nueva Zelanda nos ofrece bastante detalle sobre las diferentes peticiones, y como veis todos los recursos están en Estados Unidos, así que se tendrá que notar el efecto del límite en la velocidad de la luz:



Bueno, no sé lo que os parece a vosotros pero a mi me parece una herramienta super útil.

martes, diciembre 02, 2008

Utilidad para crear imágenes de progreso para tu aplicación web

martes, diciembre 02, 2008 por Martín

Estaba necesitando un gif animado para mostrar una página de progreso y me he encontrado con esta pequeña utilidad para crear las típicas imágenes de progreso que se pueden encontrar por todas partes.

Por si a a alguno le resulta útil.