Lucene, Grids, Heaps y otras cosas del montón

En el penúltimo post explicaba la importancia en ciertos escenarios de que los objetos tengan una vida de corta duración. Only the good die young. Uno de esos escenarios es el caso en el que tengamos una Heap enorme, caso en el que la recolección de basura puede llevar mucho tiempo.

¿Y qué tamaño puede tener uno de esos Heaps tan enormes? Recuerdo hace años que tener un Heap de 512Mb ya era la caña. Después, cuando estabamos haciendo aplicaciones de trading hace ya casi cinco años, jugábamos con Heaps de 4gb, que no estaba mal pero ya resultaba bastante pequeño, pero era fruto sobre todo de las limitaciones de los sistemas operativos de 64 bits y en producción si que nos íbamos a 8, pero con la incertidumbre de no saber con exactitud que iba a pasar.

Escribiendo micro-benchmarks con jmicrobench

Tal y como escribía hace unos días, mi opinión es que los microbenchmarks no son una técnica recomendada para sacar conclusiones sobre el rendimiento global de nuestros programas.

Sin embargo sí que existe una serie de circunstancias en las que es importante el conocer el rendimiento de tu lógica de negocio. Por ejemplo cuando estamos trabajando en sistemas que requieren procesar una gran cantidad de transacciones por segundo. Imaginaros quizás un sistema de pagos por Internet, o el software de una casa de apuestas, o la línea de almacén de un gran fabricante de lo que sea.

En estos casos no sólo es necesario el tener la confianza en que el software va a soportar el volumen esperado sino que es necesario garantizarlo. ¿Cómo lo podemos garantizar? Con tests. Pero hacer los tests puede ser complicado. Por eso se hacen útiles frameworks para la creación de microbenchmarks como jmicrobench del que nunca había oido hablar pero que en breve os contaré en otro post como he llegado a el.

jmicrobench es una extensión de jUnit que define un nuevo ejecutor de Tests: PerformanceTestRunner que se encarga de ejecutar nuestros tests y de calcular el número de operaciones por segundo que ejecuta, su media, e incluso de generar gráficas. Un test de rendimiento se crearía de la siguiente forma:

GC: Only the good die young

Una frase popular dentro del frikimundo de la Garbage Collection es "Only the good die young", que proviene además de una canción bastante popular de Billy Joel y que le viene que ni pintada.

Un poco de background para la frase. Todo esto depende de la máquina virtual utilizada, pero tomando como referencia Hotspot que es una máquina virtual generacional, tenemos que la memoria se divide en dos generaciónes: Young generation y Tenured generation. Cada una de estas zonas a su vez está dividida en otras zonas, pero esto lo vamos a obviar por razones de simplicidad.

La Young Generation es mucho más pequeña que la Tenured Generation. Por lo tanto, la recolección de basura ahí es mucho más rápida. Pero aún más importante, la recolección de basura en la Young Generation se hace constantemente y no requiere parar los diferentes threads de la máquina virtual de Java, mientras que normalmente (recordad, esto es una visión meramente pedagógica y simplificada) la recolección de basura en la Tenured Generation exige parar todos los threads de la máquina virtual.

¿Qué has hecho este verano? Soy programador

Una de humor para el Martes. Supongo que es viejo pero me lo he encontrado y me ha hecho mucha gracia. ¿Qué has hecho este verano?

La historia de Monster

Mr. Jordi Monné me avisa de que en Mixergy entrevistan a Jeff Taylor, el fundador de Monster.com. El señor Jordi es muy listo porque sabe que si me lo dice yo haré un resumen y así no tendrá que verse la entrevista. ¿Verdad? Verdad. He tomado unas notas de lo que ya es historia de Internet.

¿Cómo se crea el mayor imperio de clasificados de empleo del planeta? Atendiendo a la entrevista mi respuesta sería siendo el primero. En 1993 Jeff Taylor era dueño de una agencia de clasificados tradicional. Una agencia de publicidad enfocada en la colocación de personal. Es decir, gran empresa busca gente y ellos se encargan de poner los anuncios en los periódicos. Ni siquiera era una agencia de contratación. Pero les iba muy bien. Hacían 400.000 dólares al año.

Pero tras la crisis algunos de sus clientes tenían problemas, así que le dijeron: "O buscas formas mejores de anunciarnos o buscaremos quien lo haga por ti". Eso sí es motivación. Y a Jeff se le ocurrió crear una BBS (todavía no había webs), y llamarle Monster. Monster viene de la idea de tener una base de datos monstruosa. Lo que pasa es que pronto se dio cuenta de que no le llegaba con la BBS, porque quería imagenes, así que le pasaron el contacto de una empresa que hacía cosas para un sistema que se llamaba Mosaic (seguían sin existir las páginas web). Y así empezó todo. Monster fue el dominio 454 en ser registrado y cuando empezó todo sólo existían 200 páginas web en el mundo.

Lecciones sobre AWS aprendidas en Netflix

Tal y como escribía hace unos días, la arquitectura de Netflix está basada en Amazon Web Services. La compañía, decidió a principios de año migrar su arquitectura a Amazon.

En el blog de Netflix, comparten cinco lecciones que han extraído de su experiencia al mover su arquitectura desde su propio data center a la nube:

Notas sobre la arquitectura de Facebook Chat

En la línea de las notas de arquitectura que suelo publicar voy a escribir hoy un post con un resumen de notas que he ido sacando sobre un documento acerca de la arquitectura del chat de Facebook. Si os interesa el tema entonces os pueden interesar también las notas sobre la arquitectura de Facebook del año pasado. Empiezo.

En 2007 en Facebook se dan cuenta de que necesitan un Chat, seguir los mensajes entre muros es un infierno. El código surge en el 2007 de lo que en Facebook denominan un Hackathon, es decir quedarse los ingenieros durante toda una noche programando. No es hasta el 2008 cuando se manda el primer mensaje y lo lanzan oficialmente.

Las estadísticas del chat dan miedo:

• 800+ million user messages / day


• 7+ million active channels at peak


• 1GB+ in / sec at peak


• 100+ channel machines

McMafia

Durante estos días ha tocado irse de vacaciones, y más importante he pasado unos días en el hospital por una operación de rodilla que tenía pendiente desde hace unos añitos. Así que me ha quedado bastante tiempo para leer.

Uno de los libros que he leído es McMafia. Se trata de un libro no relacionado con la informática que le gustará a todos aquellos a los que les guste el tema del crimen organizado.

El libro resulta algo difícil de leer por la cantidad de nombres y hechos que aparecen que hacen que si vas leyendo unas cuantas páginas al día te pueda ser algo complicado seguir el hilo. Yo me lo compré en inglés porque quería que no se me oxide el vocabulario, pero la verdad es que en este caso seguramente obtaría por comprar la versión traducida, ya que como os digo el seguir tanto nombre, tanto hecho y tanta fecha se hace aún más complicado en otro lenguaje.

Documentos sobre seguridad de Microsoft

A todos los que os interese el tema de la seguridad quizás os interese saber que desde Noviembre, Microsoft ha comenzado a publicar una serie de documentos de referencia relacionados con la seguridad en entornos web.

Estos documentos describen diferentes vulnerabilidades e intentan presentarlas de forma que puedan ser comprendidos por personas situadas en diferentes puestos de trabajo: desde el tomador de decisiones al tester pasando por arquitectos y desarrolladores. En el momento de la publicación de este post hay tres documentos disponibles:

Creando mejores tests

Alfredo Casado ha publicado hace unos días en su blog un artículo muy recomendable donde comparte con todos una serie de consejos a la hora de crear mejores tets.

Alfredo nos recomienda tratar a nuestro código de tests como si fuese de producción y además explica una de las funcionalidades más interesantes de JUnit 4.7, que no conocía por cierto, que es la creación de reglas (Rules) que permiten extraer código común que se utiliza en todos los tests.

No cuento nada más. El que quiera saber más que lea su artículo: Escribiendo mejores tests.

La arquitectura de Netflix

Adrian Cockcroft, Cloud Architect en Netflix ha compartido unas transparencias en Slideshare bastante interesantes sobre el servicio de streaming de video Netflix.

Las transparencias están orientadas tanto a desarrolladores como a ingenieros de sistemas. Las notas que se sacan son bastante interesantes y son bastante densas, de hecho entran en bastantes detalles según comenta su autor en su propio blog para atraer a ingenieros a su equipo, ya que están contratando. Y vaya si están contratando. En su web tienen unas 100 posiciones abiertas ahora mismo. Como siempre me pasa, este post iba a ser una simple referencia pero ha terminado en una recopilación de notas.

SSD vs. memoria RAM en MySQL

Interesante reflexión en el blog de Percona sobre si tener más memoria RAM tiene ya sentido cuando los discos SSD están cada vez más baratos.

En sus pruebas crearon un conjunto de datos de 230Gb. y empezaron a darle caña al MySQL
variando el tamaño del buffer de datos de memoria. Aquí están los resultados:

Citas clásicas de programación

Este post está copiado y pegado vilmente de esta fuente original:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil
- C. A. R. Hoare

Walking on water and developing software from a specification are easy if both are frozen
- Edward V Berard

It always takes longer than you expect, even when you take into account Hofstadter’s Law.
- Hofstadter’s Law

Ejemplos de Startups sostenibles

Siguiendo con el tema de ayer y el hecho de que la recomendación de estar full-time en una Startup es una tontería, en HackerNews preguntaban hace unos días a su comunidad que pusiesen ejemplos de personas que ahora mismo estaban viviendo de su Startup.

Como dice alguien en el hilo en cuestión, se trata de un post bastante motivador ya que salen ejemplos de Startups de personas reales, que están viviendo de su trabajo y que la mayoría encima no han recibido ningún tipo de ayuda externa. Además, si os leéis los ejemplos veréis que muchos de los emprendedores no tuvieron que empezaron full-time con su Startup, y sólo dieron ese paso cuando veían que empezaban a tener clientes o cuando estaban ya obteniendo beneficios de su esfuerzo.

Emprender en España. Mito 1: Trabajo full time

El pasado sábado me comentaba Ferrán que a ver si escribía un poco sobre mi experiencia con Jobsket. Básicamente mi/nuestra experiencia ha sido y está siendo un continuo vaivén de sensaciones. Unas veces parecía que ibamos a arrasar y otras que estábamos acabados, y así seguimos :)

Recuerdo hace unos meses que intenté escribir un post que resumía el primer año de Jobsket, y tuve que parar, porque es que había tantas cosas que no era capaz de escribirlo todo ni en uno, ni en dos posts, y al final se quedó en el tintero.

Ahora voy a intentar redimirme e intentaré en las próximas semanas ir publicando cosillas sobre mi experiencia. Básicamente una de las cosas que más me ha desilusionado de internet son el ver como en España se copian alegremente consejos de otros países como pueda ser Estados Unidos o el Reino Unido. Total, si lo recomiendan por allí, tiene que ser cierto. A fin de cuentas, esos son los que más saben. Pues bien, muchas de esas recomendaciones a nosotros no nos han funcionado. Así que dentro de esta serie de mitos comenzaré a poner cosas que habría hecho de otra manera, por si a alguien le vale.

Mito 1: Trabajo full time

Consiste básicamente en decir que si no te dedicas al 100% en tu proyecto es que no tienes credibilidad. Es una frase muy habitual entre los inversores. Pues bien, esto de que necesitas estar trabajando full-time para emprender podéis tener claro que es una memez absoluta. Así que mi consejo para cualquiera que se esté planteando dejar su trabajo para emprender es simplemente que lo olvide, y si lo hace como mucho que lo haga capitalizando el paro primero, que por lo menos ingresará algo.

Vamos a ver, a los inversores como os comentaba les gusta decir mucho esto. ¿Por qué? Ni idea, creo que porque lo han leído por ahí. Podéis tener claro que el trabajar a tiempo parcial es de las últimas razones por las que os van a decir que no. Tu si vas a un inversor, en el supuesto caso de que quieras ir, con un tráfico de la ostia de la mano, o mucho mejor, si vas con varios clientes potentes de la mano, o mucho mejor aún si vas con unos buenos ingresos mensuales, entonces a este inversor le va a dar igual si trabajas full-time, si trabajas partial-time o si no trabajas en el proyecto (Nota: con le va dar igual me refiero a ese preciso instante). Los inversores no son tontos y bien saben distinguir un buen negocio que funciona y que tiene buena pinta. Y no hay más. ¿Que no llevas nada de eso? Bueno, entonces tienes otros problemas y ninguno de estos es el trabajar a tiempo parcial. Sin embargo el trabajar a tiempo parcial sin embargo es una de las mejores excusas para que te digan que tu proyecto no vale.

Un ejemplo de empresa que va cada vez más bien y trabajaron a tiempo parcial son mis amigos de Linking Paths, que han hecho un producto cojonudo que se llama StageHQ y a los que no se les pasó ni por la cabeza el dejar de currar para hacer su producto. Estos señores han estado haciendo proyectos para terceros para financiarse y poder permitirse hacer StageHQ. Y lo han conseguido y ahora tienen un producto que ha vendido tickets en todo el mundo por valor de más de un millón y medio de dólares. Ahí es nada. ?¿Otro ejemplo? Panoramio, a tiempo parcial hasta que daba dinero.

Yo sinceramente, os digo que al final nos arrepentimos de no haber hecho lo mismo que ellos, porque por muy buen producto que hagas, que el nuestro es el mejor en su campo, el hecho de pasar meses sin ingresar apenas dinero es muy jodido, y te va quemando. Si os podéis permitir el compaginar el emprender con hacer consultoría, trabajos como freelance o seguir en vuestro empleo, mi consejo es que lo hagáis, porque además esas actividades son siempre una buena oportunidad de hacer contactos que os pueden venir bien para el futuro.

Y simplemente no hagáis caso de gente que copia consejos de otros lados y se les llena la boca diciendo lo que funciona en otros mercados. Que sí, que pueden funcionar en otros países porque hay mucha más cultura de emprendedores, pero Spain is very different my friend. Así que nada, ahí os queda mi más sincero consejo, menos hacerle caso a guruseles monta-chiringuitos-de-Internet y utilizad vuestro tiempo en trabajar primero muy bien el análisis de mercado, en probar a lanzar el producto y ver como se acoge, en ver como reacciona el mercado a vuestra aplicación, en recoger las primeras ganancias, o en conseguir los primeros clientes, y sólo cuando veáis que la cosa va avanzando pensar en dedicaros full-time.

Esto por supuesto, es una opinión muy personal.

Libro sobre Procesado de Lenguaje Natural

La semana pasada escribía sobre el aprendizaje máquina y como lo utilizaban en bit.ly. Uno de las piezas que habilitan el aprendizaje máquina es el capacitar a un sistema informático para comprender la información que está procesando.

Esta información normalmente viene en lenguaje humano, y necesita ser comprendida. Y bueno, ya sabéis que no es lo mismo dormir, que durmiendo que dormido. Que ejemplo más malo por favor. En fin que en Lingpipe han puesto a disposición de todo el mundo un libro que explica los fundamentos del procesado del lenguaje natural. Os paso el link por si a alguno le interesa.

Nuestra aplicación Facebook "Trabaja con Nosotros"

La verdad es que no lo había comentado porque la mayor parte de los que visitáis este blog ya conocéis Jobsket, la Startup de la que soy fundador junto con Daniel Latorre y Jordi Monné, pero es que el éxito ha sido tal que lo voy a comentar. Además así, si alguno la conocéis os podéis pasar.

Facebook está de moda, no cabe duda. "Trabaja con Nosotros" es una aplicación que permite a las empresas publicar ofertas en Facebook. ¿Cómo? Muy fácil, simplemente se registran en nuestra herramienta de empresas Jobsket ATS, enlazan la página de Facebook y su cuenta en nuestro ATS y una vez que publiquen una oferta, ésta saldrá en su página de Facebook. Así de sencillo. ¿Cuál es la ventaja? Que los candidatos pueden inscribirse en sus ofertas directamente desde Facebook, sin salir de la red social, y aumentando su base de fans, manteniendo la cercanía, etc. etc. Podéis ver un ejemplo en la página de Facebook de EGA Consultores.

Eventos virtuales de Alt.NET hispano

Un descubrimiento del Sábado Áxil que realizamos este pasado sábado han sido los VAN de Alt.NET hispano.

La verdad es que conocía la comunidad Alt.NET, pero confieso que nunca me había preocupado de seguirla. Al fin y al cabo, trata sobre .NET, y mi experiencia con .NET es absolutamente nula, casi la misma que con el resto de productos de desarrollo de Microsoft. Vamos, que tampoco me podía imaginar que dentro de esta comunidad pudiese haber cosas, que aún siendo muy interesantes, me pudiesen servir para mejorar profesionalmente.

Facebook venderá créditos para micropagos en Game y Tesco

Wow, esto de los micropagos promete ser la bomba. Ayer me enteraba que Facebook comenzará a vender créditos para su servicio de micropagos en el Reino Unido en los supermercados de Tesco y en las tiendas de Game. Por ahora esta "moneda" se puede utilizar únicamente en 200 aplicaciones y juegos de Facebook pero se comenta que pronto se podría utilizar en aplicaciones externas vía Facebook Connect. ¿Tiembla PayPal?

Finanzas para emprendedores

La semana pasada terminé de leer Finanzas para Emprendedores un libro de Antonio Manzanera Escribano, economista de carrera en el Banco de España y anteriormente consultor en McKinsey & Company, y que ahora es Director de Savior Venture Capital, firma de servicios de capital riesgo especializada en desarrollo de negocio y asesoramiento financiero a startups y emprendedores.

La verdad es que en un principio no me esperaba gran cosa del libro pero tengo que decir que tras leerlo sólo puedo decir que es una pena que no hubiese aparecido hace un par de años cuando empezábamos con Jobsket. En mi opinión este libro ahora mismo es una lectura fundamental para cualquier persona que se esté planteando la entrada de un inversor en su negocio, ya sea un business angel, una empresa de capital de riesgo o cualquier otra entidad. El libro te explica conceptos fundamentales como el valor pre-money, el valor post-money, las diferentes cláusulas de un contrato con un inversor, explica como afrontar una negociación basándose para ello en aspectos de la teoría de juegos. Y lo más importante, todo esto lo hace con ejemplos, sí, no sólo teoría sino también práctica, números, algo palpable con lo que te puedes sentar con lápiz y papel y hacer tus propias cuentas. En definitiva muy completo.

Machine Learning en bit.ly

Bit.ly es un servicio acortador de URLs que se hizo popular gracias el éxito de Twitter. La limitación a 140 caracteres de los mensajes de esta aplicación hizo necesario este tipo de aplicaciones que pronto se hicieron populares. Se trata de una compañía que ha recibido sobre 12 millones de dólares en capital riesgo, ampliamente criticada por tratarse de un programa que puede hacerse en diez líneas de código siendo generosos.

Pero detrás de bit.ly hay mucho más. La mayoría de analistas hacen hincapié en la escalabilidad del sistema, y en el ser capaz de procesar de procesar nada más y nada menos que 10 millones de URLs por día, manejando 100 millones de eventos diarios. Inicialmente puede parecer trivial, pero si nos paramos a pensar, todos esos datos representan información, información que de algún modo les interesa a los usuarios (si dejamos de lado los usos malintencionados de bit.ly, por supuesto).

¿Qué se puede hacer con esta información? Ahí es donde entra el motivo del post de hoy. Una fantástica presentación que tienen en InfoQ en la que una simpática Hilary Mason, científica en bit.ly, explica los orígenes del aprendizaje máquina y como todo esto nos afecta en el día a día y en especial como se puede utilizar con la enorme cantidad de datos de los que bit.ly dispone ahora mismo.

No puedo más que recomendar a todos el ver y escuchar la presentación porque Hilary sabe convertir un tema tan árido como son las matemáticas y la inteligencia artifical en algo que cualquier persona puede comprender por muy alérgica a las matemáticas que pueda ser. La presentación dura una hora y recorre toda la historia de la inteligencia artificial, desde Eliza hasta nuestros días, con anécdotas divertidas e interesantes.

Uno de los datos más curiosos es el ver como el tema de Machine Learning es algo bastante de moda ahora mismo, y como el número de demandas de puestos de trabajo con estos conocimientos se ha incrementado considerablemente en los últimos años.

Una de las razones es que en los últimos años se han encontrado por fin aplicaciones prácticas a conceptos teóricos que hasta ahora no se les veía utilidad alguna, pero que ahora conforman parte de nuestro día a día. Es el caso por ejemplo de las recomendaciones de libros o productos. Recomendaciones basadas en la clasificación de datos de manera supervisada, o no supervisada. Amazon es el caso más ejemplar con su "Personas que han visto/comprado este producto han visto/comprado esto otro". Es fácil darse cuenta de que esta funcionalidad no sólo se trata de algo que puede ser muy útil al usuario sino que tiene un impacto directo en las ventas de la compañía. Los usuarios mirarán más, descubrirán nuevos productos y comprarán más.

Respecto a estas recomendaciones hay anécdotas interesantes, como el que Amazon recomendase accidentalmente vibradores a las personas que compraban cierto tipo de bolígrafos graciosos. Un ejemplo de como el aprendizaje no supervisado puede jugarnos malas pasadas. O como una compañía como Netflix puede ofrecer un premio de un millón de dólares a aquellos que mejoren su algoritmo de recomendación.

Y ahí es donde reside realmente el poder de bit.ly, no en lo que hace sino en la información que conoce. Bit.ly sabe exactamente dónde estamos pinchando 100 millones de personas al día. Y eso es información muy valiosa. Saben lo que nos gusta, los artículos que leemos, y las personas que comparten nuestros intereses. Con toda esa información es fácil que a uno se le ocurran ideas de como explotarla.

Por cierto que muchas de las cosas que se comentan en bit.ly las hacemos en Jobsket, no con enlaces sino que con currículums y ofertas de trabajo. Aunque claro, nosotros no tenemos ni tanta información, ni tanto dinero :-)

Always ship trunk

Paul Hammond product manager de Flickr hizo una presentación en Velocity 2010 donde hablaba lo anticuados que están los sistemas de control de versiones cuando toca crear aplicaciones web.

Durante los últimos años parecía que SVN se había convertido en el rey de los sistemas de control de versiones, pero pronto aparecieron nuevos jugadores. Mercurial y Git son formas diferentes y más distribuidas de controlar el ciclo de desarrollo de software, pero según Paul, ninguno de todas estas alternativas está realmente pensada para el desarrollo web. Y lo cierto es que si lo pensamos fríamente y dejando a un lado las preferencias personales, no le falta razón.

La principal razón para crear una rama ha sido siempre la misma. Ese cliente que pide esa funcionalidad especial, que además la tenemos que hacer para ayer, y que vamos a dedicar a unas personas concretas a que la hagan mientras que el resto del equipo hace sigue con su desarrollo. Esas ramas pueden quedarse ahí o ir adquiriendo vida propia, e incluso evolucionar a productos nuevos, quien sabe. Pero el desarrollo en ramas, tal y como comenta Paul Hammond, parece estar más orientado a las aplicaciones tradicionales de servidor o de escritorio que a la web.

Paul argumenta que en la web no hay versiones, hay la versión. Esa es la versión que manejarán tus usuarios. Bueno, en realidad no es así, no es tan fácil. Tenemos entornos de producción, pre-producción, desarrollo, betas, QA, unos tendrán unas funcionalidades, otros tendrán otras funcionalidades. Incluso podemos querer probar ciertas funcionalidades en producción pero en modo oculto, o habilitarlas para un cierto subconjunto de usuarios, o tener la capacidad de habilitar o deshabilitar ciertas funcionalidades en tiempo real, o hacer tests A/B para comparar la efectividad de ciertos cambios, y un largo etcétera de posibilidades.

¿Existe algún sistema de control de versiones que te ayude a hacer esto? No, o al menos Paul no lo conoce (yo tampoco). La solución son añadir condiciones al código. Todo esto añade complejidad y puede ser bastante peligroso, pero por otra parte resulta muy efectivo. La recomendación general es guardar los switches en algún lugar centralizado donde se pueden habilitar o deshabilitar fácilmente.

A mi por ejemplo esta es una de las cosas que más me gusta de Grails, copiado de Rails y que te permite tener diferentes entornos de ejecución con diferentes configuraciones e incluso crearte tus propios entornos. Todo eso lo podemos combinar con algunos interruptores que nos permitan habilitar o deshabilitar funcionalidades en tiempo real y tendremos una única aplicación en la trunk que podremos controlar a nuestro antojo.

Sencillez operacional vs. complejidad en la configuración. ¿Qué preferís vosotros? ¿Tiene sentido el tener múltiples branches en el mundo web?

PS. Tenéis el enlace a la presentación arriba, pero hay más notas aquí.

Sábado Áxil, este sábado en Santiago de compostela

Tal y como anuncian en la página web de Axilmente, la comunidad promotora del Agilismo en Galicia, este Sábado se celebrar el primer "Sábado Áxil", una iniciativa novedosa en nuestra comunidad y que ya se han efectuado en otras zonas de España gracias a la comunidad de Agile Spain.

El evento está abierto a todo el mundo, en especial a todos aquellos a los que les guste esta profesión, que les guste programar, o analizar, o diseñar, o dirigir, o hacer de jefe, pero lo fundamental es que exista entusiasmo. No se trata de ningún evento orientado a super-programadores ni nada similar, sino un evento orientado a toda la gente a los que nos gusta hacer las cosas bien y mejorar cada día.

El plan es muy sencillo: No hay plan. El evento se ejcutará bajo el formato Open Space y cada uno planteará temas sobre los que le gustaría hablar o escuchar. Y a partir de ahí ya se verá. Eso sí, como es el primer evento, parece que hay planificadas algunas charlas por si no se encuentran temas. Habrá también taller y kata. Y como no, cervezas planeadas para el final de la sesión.

Tenéis la agenda aquí y lo único que pide la organización es que os inscribáis utilizando este formulario para tener una idea de cuanta gente va a ir.

Yo voy a ir. ¿Alguien más se apunta?

Revisitando Tiobe 2010

Hace tres años, en el 2007, escribía sobre lo sensacionalista que era un informe de Tiobe, el índice sobre la popularidad de los lenguajes de Programación, que declaraba a Ruby en decadencia porque su índice de popularidad había decrecido en los últimos dos meses.

Y la verdad es que revisitando estos días el índice de lenguajes, no me equivocaba demasiado. De hecho el boom de Ruby se sucedió entre la fecha del artículo y 2009 donde parece que llegó al máximo apogeo. Pero bueno no es de eso de lo que quería meditar hoy sino más bien de otras cifras y gráficas interesantes que se extraen de la edición de Noviembre del índice.

Me parece muy interesante por ejemplo el analizar la gráfica de lenguajes:



Se puede ver muy claramente como Java, y otros lenguajes tradicionales como pueden ser C y C++ han ido cediendo programadores durante los últimos ocho años que han sido asumidos por otros lenguajes. Un buen puñado se habrán ido a Ruby que en los últimos años se ha convertido en un lenguaje muy popular. Python ha sido otro de los beneficiados de esta migración, sin duda ayudado por el soporte de Google. C# también ha mantenido una subida constante pero quizás más lenta de lo que cabría esperar.

Lo que sí que impacta bastante es el subidón de Objective-C, y es que está claro que Apple llega a todas partes. Objective-C ha pasado de ser el lenguaje número 42 en popularidad en el 2005 a estar en el puesto 8 en la actualidad, por encima incluso de Ruby o Perl. Y es que ¡parece que hay muchos iPhone que programar!

Respecto al tipado dinámico frente al tipado estático la cosa parece que está estancada. Según la gráfica, los lenguajes dinámicos tuvieron bastante tirón del 2004 al 2008 pero ahora parece que se han estancado en el crecimiento.

Pero bueno, ya se sabe, igual que Go fue el lenguaje con mayor crecimiento del 2009 (¿pero alguien lo usa?) y llegó Apple y convirtió a Objective-C en uno de los lenguajes más populares de los últimos años, pues podría suceder cualquier cosa que mueva la balanza a uno u otro lado. No nos queda más que esperar.

El servidor más seguro del mundo está en Los Alpes

O eso dice su dueño. Le llaman el Fort Knox Suizo y se encuentra emplazado en lo que antaño era un refugio nuclear en el los Alpes suizos.

El centro de datos está formado por dos bunkers independientes situados bajo tierra, en el corazón de la montaña, y unidos por un túnel subterráneo de 10 kilómetros de largo. La compañía que diseñó el refugio de datos ha aprovechado además los recursos de la montaña y la peculiar situación para refrigerar los servidores de manera natural. Así, todo el sistema de refrigerado se abastece de agua que proviene de un lago glaciar subterráneo.

El lugar para emplazar el refugio quizás no esté tan pensado, ya que como comentan en Wired, que publicó este mes un reportaje sobre tan peculiar lugar, en el valle cercano a la montaña se encuentra la mayor concentración de billonarios de todo el planeta, y aquí estoy especulando, quizás guarden más que datos en sus cajas acorazadas.

El refugio que tuvo un coste de construcción de alrededor de los 30 millones de euros, contiene lo último de lo último en cuanto a seguridad, reconocimiento facial, plásticos anti-bala, filtros de aire militares capaces de filtrar impurezas atómicas y químicas, hotel de emergencia y cámaras acorazadas cortesía de bancos suizos. Y por supuesto su funcionalidad más deseada es la que proviene de su uso original, puede sobrevivir a un ataque nuclear.





Si queréis conocer más sobre esta bestia de la seguridad os recomiendo ver el artículo de wired.

Koobface, historia de un crimen 2.0

Los que sigáis este blog o mi Twitter os habréis dado cuenta de que de un poco a esta parte me he ido interesando por temas de seguridad y cibercrimen. Me parece un mundo apasionante sobre el que puedo pasar horas leyendo sin aburrirme. Es increible le economía sumergida que tenemos ahora mismo funcionando en la red y con la que convivimos diariamente.

Koobface, el tema de este post de hoy, es un gran ejemplo de como los avances en la red se pueden utilizar por una red de cibercrimen para conseguir enriquecerse sin apenas causar ningún daño, realizando pequeñas transacciones de manera masiva y aprovechando las dificultades operativas y burocráticas que surgen al intentar desactivar una red que opera en múltiples zonas geográficas, múltiples jurisdicciones y que mueven cantidades de dinero tan pequeñas cuando se miran de manera unitaria que no generan ningún tipo de denuncia.

Todo el contenido de este post lo he recopilado de un fenomenal documento Nart Villeneuve quien fue capaz de infiltrarse en la red de Koobface y durante meses estuvo investigando su modus operandi, para ahora publicar un informe que resulta enormemente impactante y que a muchos les puede abrir los ojos ante la magnitud y sofisticación de las redes de ciberpiratas que se encuentran operando en la actualidad. Nada del contenido de este post es original y os recomiendo sobre todo leer el informe, pero si lo preferís leer resumido y en castellano podéis continuar :)

Koobface, anagrama de Facebook, es una red de bots que aprovecha las redes sociales para propagarse. Koobface utiliza estas redes sociales (Bebo,
Facebook, Friendster, Fubar, Hi5, MySpace, Netlog, Tagged, Twitter, y Yearbook) para transmitir mensajes con links a contenido malicioso. Estos links se enmascaran con el servicio de acortamiento de URLs bit.ly. Para un usuario de a pie, no es sencillo detectar la página maliciosa.

Muchas de estas páginas eran blogs falsos en Blogspot (hasta 350.000) que redirigían a servidores falsos que simulaban ser videos de YouTube y donde había banners para la descarga de software malicioso enmascarado bajo falsos codecs de video o actualizaciones de software. Y ojo que la cosa no termina ahí. A esto le tenemos que sumar el uso de SEO para colocar estos blogs maliciosos en el top de los buscadores, y la resolución de CAPTCHAS que se conseguía que fuesen las propias víctimas los que los resolviesen y que se utilizaban para crear nuevas cuentas de blogs maliciosos y cuentas de Facebook para propagar los links.

Pero parémonos por un instanate a analizar los componentes de este cóctel, porque estamos ante la esencia de la web social, la web 2.0 llevada a la máxima expresión del cibrecrimen. Por un lado tenemos redes sociales donde los usuarios somos más propensos a hacer clic en enlaces que nos mandan nuestros amigos. Tenemos también acortadores de URL, populares gracias a Twitter, y que tienen como consecuencia que las personas no se fijan en lo que hacen clic. Cientos de miles de blogs falsos y servidores enmascarando páginas que se han convertido en el día a día de cualquier consumidor habitual de Internet como es YouTube. Perfiles de Facebook con miles de fans que propagan links como la espuma. Cuentas falsas de Google Reader o Google Buzz donde colocar y propagar más y más enlaces maliciosos. Como decía, el cóctel perfecto para crear una red de ganancias millonarias y con muy pocas posibilidades de ser cazados.

Una red como Koobface no puede sobrevivir sin que exista toda una economía sumergida. El informe habla y da nombres de proveedores de hosting amigables a este tipo de organizaciones y que rechazan sistemáticamente todas las reclamaciones que reciben; también se nombran otras redes de bots amigas que entre ellas se ayudan para propagarse las unas y las otras mucho más rápidamente; sistemas de pagos que permiten el canjeo de dinero que proviene de este tipo de prácticas; personas dispuestas a ceder sus cuentas corrientes como "mulas" que sirven de canal para mover el dinero; y por supuesto redes de afiliación que paguen por esos clics y esas instalaciones. Casi nada.

En este caso, la red de Koobface se monetiza a través de dos modelos enormemente lucrativos para las redes de bots: El pago por clic de modo que miles de ordenadores infectados ejecutan software que ejecutan falsos clics en anuncios, y el pago por instalación de programas en los ordenadores de las víctimas. ¿Qué tipo de programas? Por ejemplo falsos antivirus que cuestan de 30 a 100 dólares y sobre los que el "instalador" se puede llevar de un 30% a un 90% de como comisión. Un negocio realmente rentable.

A diferencia de otras redes, Koobface no roba ningún tipo de información de tarjetas de crédito ni información bancaria. Sí se apropia sin embargo de contraseñas de redes sociales como Facebook, Messenger, etc. en un esfuerzo para propagarse más rápidamente.

En un año los creadores de Koobface han conseguido más de 2 millones de dólares.

Para los que os interese saber más sobre Koobface podéis leeros el completo informe en PDF. Es impresionante. Para abrir apetito aquí podéis leer algunos datos que dan una idea del tamaño de la red:

• Cuentas de Facebook: 21.790


• Total de amigos: 935,000/Cuentas con amigos: 3105


• Total de blogs: 350.854


• Cuentas de Google: 522.633


• Cuentas de Google Reader: 4.842


• Cuenta de 100mb (hosting gratuito): 4.044

Para terminar, no sé si a los que hayáis leído el informe os habrá parecido igual que a mi, pero me ha parecido un trabajo de investigación excelente. En mi opinión la prensa debería comenzar a alertar a la gente de que este tipo de cosas existen. Quizás esta red en concreto pueda resultar demasiado sofisticada para el usuario de a pie. Pero sí que convendría poner más énfasis en los peligros de una red que día a día se vuelve más compleja.

Microbenchmarks, lenguajes dinámicos y la web

Hay una frase en inglés que es "lies, dammed lies and statistics" y viene a significar que tenemos mentiras, malditas mentiras, y las estadísticas, y que se utiliza cuando la gente utiliza datos numéricos y estadísticas para intentar sustentar argumentos que de por sí pueden resultar débiles.

Hace unas semanas alguien me preguntaba en qué lenguaje podía hacer un proyecto web. Yo le contesté que podría probar Groovy o Ruby. A lo que el me respondió que había pensado en Java porque había visto muchos estudios que mostraban que estos lenguajes eran demasiado lentos. Pues bien, ahí tenemos un ejemplo del uso de números para fines interesados, en este caso para mover la balanza hacia un lenguaje u otro.

Es cierto que los lenguajes dinámicos son más lentos que los estáticos, ya que gran parte del procesado de los programas se posterga a tiempo de ejecución. Pero la cuestión es, ¿es esto realmente tan relevante? Quizás hace años lo fuese, en las primeras betas de cada lenguaje, pero ahora mismo definitivamente no lo es. A los que vivimos hace ya muchos años toda la historia del "Java es más lento que C++" creo que nos suena todo esto de algo.

Pero intentaré plasmar un ejemplo en esta entrada que creo que explica el por qué es absolutamente irrelevante la diferencia de rendimiento en el mundo de Internet. Imaginémonos algo de lógica de negocio. Java ahora ya está considerado como rápido, así que ¿cuanto nos podría llevar? Pongamos 10 ms. para hacer fácil el ejemplo. Ahora imaginémonos el mismo código en Groovy cinco veces más lento, o sea que serían 10 milisegundos. La gráfica de rendimiento nos quedaría como sigue:

Una nota: si buscáis por Internet os encontraréis órdenes de magnitud de todo tipo, desde 3x hasta 300x, muchos de estos tests son incorrectos por el hecho de usar tipos de datos primitivos, y cualquiera que haya usado Groovy/Ruby/Python/etc. habréis visto que esos ordenes de magnitud tan grandes son irreales. Si os interesa aquí explican más.

Pero volviendo al ejemplo, partimos de 10 ms. contra 50 ms. que es de por sí una diferencia de rendimiento muy importante (y reitero que lejos de la realidad). ¿Escogeríais directamente Java?, a fin de cuentas parece mucho más rápido. Bueno, antes de contestar y ya que estamos hablando de aplicaciones web, introduzcamos en la gráfica el resto de componentes de una petición típica: DNS, servidores varios, bases de datos, etc. A ver como queda la cosa:



¡Vaya! La diferencia que antes parecía tan enorme ahora ya no lo parece tanto. Aclaro que he utilizado valores que a mi me han parecido adecuados. Seguro que serán diferentes si hacéis un estudio serio sobre el tema, pero creo que no irán desencaminados. Hagamos cuentas:

• DNS: 60 milisegundos


• Latencia: 200 milisegundos


• Apaches, weblogics, tomcats, etc.: 160 milisegundos


• Base de datos: 200 milisegundos

En resumen y sumando nuestra lógica de negocio del caso anterior:

• Lógica de negocio en Java: 630 milisegundos


• Lógica de negocio en Groovy: 670 milisegundos

Sorpresa, sorpresa. Lo que era un 5x ahora es un 1.06x O dicho de otro modo, si antes parecía que había un 500% más de rendimiento ahora se ha convertido en un 6%, y creo que he sido bastante generoso.

Y ¿a dónde quiero ir con todo este análisis? A que si estamos eligiendo un lenguaje para nuestro próximo proyecto, para nuestra plataforma corporativa, para nuestra startup, para ese proyecto de cliente, o para aprender, lo menos en lo que nos debemos fijar es en los microbenchmarks ya que no indican absolutamente nada. Hay excepciones. Claro que sí, siempre las hay. Por ejemplo si tenemos que programar algún algoritmo de cálculo intensivo que sólo hará eso, calcular, y donde no influyen factores externos; o programando autómatas; o creando aplicaciones en entornos muy limitados como móviles. En estos casos tenemos que tener más cuidado, pero no es lo habitual.

En la mayor parte de los casos lo más razonable es fijarse en otras características como lo fácil que será programar, el soporte de entornos de desarrollo, lo amplia que es la comunidad de ese lenguaje, la cantidad de documentación y libros disponibles, la cantidad de programadores que voy a poder encontrar en el mercado laboral, lo difícil que pueda ser la curva de aprendizaje, y muchas otras cosas que seguro que se os ocurren.

Pero el rendimiento.... ya no es tan fundamental como antes.

MySQL y los pools de Threads

Estaba repasando algunas entradas en la red sobre MySQL y me he encontrado sobre este artículo que habla del problema que tiene MySQL con la gestión de Threads y en particular con la plataforma Java.

Básicamente el problema es que MySQL se ejecuta como un único proceso. Este proceso crea un Thread para cada una de las conexiones que recibe. En MySQL lo implementaron de este modo porque parece que era realmente rápido. Pero entonces se encontraron con esas plataformas que, como Java, están llenas de pools de conexiones.

Para los que no estéis familiarizados con este concepto, la idea de un pool de conexiones consiste en reservar de antemano las conexiones a recursos externos como son las bases de datos. El conectarse a un recurso externo suele ser una tarea costosa en cuanto a tiempo, y por lo tanto el mantener una estructura de memoria donde se guarden conexiones abiertas que se puedan reutilizar cada vez que nuestro programa accede a ese recurso, parece una buena idea. Cualquier servidor de aplicaciones Java que utilicéis funciona de este modo, Tomcat, Glassfish, WebSphere, WebLogic, el que sea. En otros lenguajes como .NET o Rails también es algo típico.

Y ese es básicamente el problema. La persona que administra el servidor de aplicaciones puede decidir el crear un pool grande: "Voy a reservar 500 conexiones porque vamos a tener muchos usuarios concurrentes". Lo que hará el servidor de aplicaciones es abrir 500 conexiones y mantenerlas abiertas de por vida, aunque no se utilicen. Como consecuencia en MySQL se abren 500 threads, aunque no se utilicen.

Lo ideal sería que MySQL tuviese también un pool de conexiones, pero por ahora va a ser que no. Parece que MySQL 6.0 sí lo va a tener aunque están resolviendo algunos problemillas.

Por cierto si utilizáis MySQL, el blog de Percona tiene dos artículos bastante interesantes:

1 - MySQL utilizado como base de datos NoSQL en memoria SSD
2 - Percona como alternativa a Oracle tras el lio de los precios con InnoDB

Fotos del Centro de datos de Hadoop

En un artículo en InformationWeek de hace unos meses tienen algunas de las fotos del centro de datos y el equipo de Hadoop. Las imágenes son bastante impresionantes. Hace nada Yahoo lanzó S4, muy relacionado también con el tema de Hadoop.

¿Alquilarías un Director Técnico?

Hace poco leía en la prensa financiera algo que me ha sorprendido bastante. Un ex Vice Presidente de Merrill Lynch y veterano en las Tecnologías de la Información que ha creado una compañía para alquiler de CTOs, acrónimo de Chief Technical Officer o en Español lo que sería un Director Técnico.

Esta compañía se especializa en el sector financiero. ¿Y por qué querría alguien del sector financiero alquilar a un CTO? Bueno, básicamente la idea es que las agencias de trading, gestoras de capital, gestoras de fondos, y otros gamblers financieros en general se dedican a las finanzas. Sin embargo tienen que tratar en el día a día con montones de herramientas diferentes, algunas de ellas junto con la elección tecnológica pueden ser muy relevantes a la hora de captación de fondos.

Es decir que la labor del CTO es fundamental pero muy puntual. En estos casos la necesidad de tener un director técnico en el equipo de manera permanente es muy dudosa. En su web lo resumen de la siguiente manera:

"Institutional investment is key to hedge funds. Investors are now demanding greater transparency, reporting and accountability. Many aspects of this apply to technology and the associated business processes. Cambridge CTO brings you institutional-strength process and management, filling the gaps left by multiple technology vendors across infrastructure, market data, trading systems providers and other business partners. Our engagements provide you with the level of diligence that investors are seeking; additionally relieving you from routine technology management, allowing your focus on core business."

A mi la idea me parece bastante buena. No deja de ser una consultoría tradicional, pero aquí lo que vendes es el mandarte a un super-consultor, la creme de la creme de los CTOs, para que esté contigo un par de semanas, te ayude a definir tu estrategia y te pase la factura. Hablamos claro de un coste que si fuera permanente sería muy alto. Me imagino que en Londres un CTO en el sector financiero no debería bajar de las 100.000 libras anuales tirando por lo bajo, así que ya es un gasto.

Y la cuestión es, ¿funcionaría esto en España? Está complicado, ¿verdad? Pero nunca se sabe. Si eres una persona con experiencia en el sector y contactos en empresas que se lo puedan permitir y se ajusten a estas necesidades no parece un mal negocio. ¿Qué opináis?

Un día en el centro de operaciones de Facebook

Hace unos meses, Tom Cook, Ingeniero de Sistemas de Facebook daba una charla en el evento Velocity 2010 de O'Reilly donde describía como es el día a día dentro del servicio de operaciones del gigante americano de las redes sociales.

La charla comienza con algunas estadísticas que le quitan el hipo a cualquiera:

- La gente pasa 16000 millones de minutos diarios en Facebook
- Se comparten 6000 millones de piezas de contenido al mes
- Se suben 3000 millones de fotos al mes
- Hay un millón de implementaciones de Facebook Connect

A todo ello contribuye que 50 de los 100 sitios más visitados del mundo integren Facebook de algún modo, ayudando a llegar a los 400 millones de usuarios de este 2010. Para soportar esta carga de usuarios, Facebook tiene dos centros de datos. Uno en la costa Este y otro en la costa Oeste de Estados Unidos y están construyendo uno nuevo en Oregon. Todos sus servidores utilizan Linux y su distribución es CentOS.

Nada más comenzar la charla uno se da cuenta de que Facebook es un lugar donde la opinión de los ingenieros tiene realmente mucho peso, para bien o para mal. Está claro que no es trata de un lugar habitual. Algo que me ha sorprendido por ejemplo es que la propagación de parches y cambios a producción se hace con BitTorrent, moviendo ese código a más de diez mil servidores. Otro uso interesante de BitTorrent.


Pero hay cosas todavía más sorprendentes. Facebook está hecho en PHP. Sin embargo parece que el rendimiento llegó un punto en el que no era aceptable. Lejos de cambiar de plataforma, ya que a sus ingenieros les gusta PHP, crearon una herramienta interna para traducir el PHP a C++, compilándolo después con g++. El resultado fue un 50% de aumento en el rendimiento que podríamos trasladarlo, aunque no sea estríctamente así, a un 50% menos de servidores. Sea como sea, el crear un traducor de PHP a C++ no parece que sea el tipo de decisión recomendable para todas las compañías que quieran más rendimiento.

Otro modo que tienen de aumentar el rendimiento es utilizar cachés (Memcached) y una enorme cantidad de memoria RAM: más de 300Tb de datos en vivo en diferentes cachés. Utilizan MySQL en la base de datos. Sobre MySQL en Facebook ya puse unas notas hace un año en el post "Notas sobre la arquitectura de Facebook".

La principal conclusión que he extraido de esta charla es que Facebook es, sin ninguna duda, una de esas compañías dirigidas principalmente por el equipo de operaciones. Está claro el peso de este departamento en el proceso de desarrollo y producción. En mi experiencia, trabajar en este tipo de empresas puede llegar a ser un auténtico infierno en los casos en los que el equipo de producción esté demasiado aislado del equipo de desarrollo, en los casos en que los procesos de trabajo estén demasiado cargados de burocracia o en los casos en que el departamento de operaciones tenga excesivo celo en cuanto a la implantación de cambios y nuevas funcionaliades.


Facebook nuevamente es diferente. Tom Cook comenta en su charla como los ingenieros de operaciones se mezclan con los ingenieros de desarrollo para trabajar conjuntamente en los parches y funcionalidades. Asimismo, los desarrolladores adquieren plena autonomía y responsabilidad sobre sus actos, de modo que deben participar en todas las fases de despliegue y sentarse con el equipo de sistemas a la hora de pasar cambios a producción.

Una de las consecuencias de esto es que en Facebook han eliminado la capa de QA. Esto en mi opinión es un error, pero no cabe duda de que Facebook es un sitio diferente. Me imagino que todo el desarrollo de productos y parches estará dirigido por procesos controlados, pero desde luego la impresión que se extrae de la charla es que los ingenieros tienen poco más que barra libre para introducir cambios a su antojo sin el más mínimo control de calidad. Claro, uno después se explica como en funcionalidades que no son 'core' como puedan ser las aplicaciones Facebook, un día las cosas funcionan y otro no :-)


Pero entonces, ¿cómo suplen esta falta de control de Calidad? Con un gran énfasis en la monitorizacíon y la instrumentación. Todo lo que sucede en los servidores de Facebook está completamente controlado. Para ello disponen de herramientas internas o usan software Open Source como Ganglia, Nagios o CFEngine. Pueden controlar en cualquier instante el estado de cualquier servidor, rack, cluster o centro de datos. Además de resaltar la importancia de la monitorización y la instrumentación se hace relevante también el automatizar la reacción ante caidas de cualquiera de estos componentes, ya sea eliminando el nodo, reiniciándolo, etc.

Una cosa queda clara en la charla. En Facebook no se toman las operaciones a broma. Aunque nuevamente hay cosas muy desconcertantes en cuanto al control de calidad. En la charla muestran herramientas de comunicación interna que se utilizan para que todo el mundo en la compañía conozca el estado de los sistemas en cualquier momento independientemente de tu puesto en la compañía. Es algo sin duda fantástico. Pero asimismo cuando sucede un problema lo que se entiende de la charla es que lo resaltan en su portal interno de noticias y esperan a que ningún ingeniero introduzca código, ya que éstos tienen la capacidad de introducir cambios en cualquier momento. Esto no hace más que reafirmar en mi interior que Facebook no es una empresa tradicional, y que por el contrario ofrece ese sentimiento de funcionamiento bastante anárquico en ciertos aspectos.

Por último, os dejo el video por si interesa verlo vosotros mismos.

Tipos de programadores por sus gestos con el teclado

Hace unos días gracias al Twitter de José Manuel Beas descubrí una viñeta magnífica hecha por otro twittero, sbastn. Mis disculpas por adelantado porque la voy a fusilar diréctamente y ponerla por aquí ya que me ha parecido genial.