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.

Gráfica del fraude de tarjetas de crédito este año en USA

En Bank Info Security han publicado una gráfica muy interesante sobre los fraudes más importantes que se han llevado a cabo durante lo que va de año dentro de los Estados Unidos.

Para nosotros, en Europa, no es demasiado relevante pero si pasáis el ratón por la gráfica podréis ver la descripción de todos estos casos y se puede apreciar que es algo que nos puede pasar a cualquier de nosotros en cualquier lugar. ¡Da miedo!

Yahoo lanza S4

Con un dominio muy molón Yahoo acaba de lanzar hace nada S4. Se trata de una "Distributed Stream Computer Platform" o para que nos entendamos, una librería/plataforma para procesar grandes cantidades de datos que van llegando continuamente en tiempo real.

Hace nada acaban de publicar una entrada en su blog presentando el proyecto. Se trata de llevar la filosofía que MapReduce y Hadoop han popularizado para el procesado de trabajos en batch al procesado de datos que fluyen en tiempo real. Ellos ponen el ejemplo del análisis mediante técnicas de aprendizaje por computador de miles de búsquedas por segundo realizadas por millones de usuarios diariamente en el buscador de Yahoo.

Todo esto de manera que sea distribuido, es decir que haya múltiples nodos que se dividan el procesado de ese flujo de datos; que sea escalable, es decir que para soportar el procesado de más información sólo sea necesario introducir más máquinas; y que sea tolerante a fallos, es decir que si algún nodo se cae, haya otro que sea capaz de procesar esos datos.

La plataforma es Open Source, la han liberado bajo la licencia Apache y está desarrollada completamente en Java.

JavaOne y Bonilla TV

Esto post llega con muchísimo retraso, pero como comentaba hace unos días, este blog ha estado desconectado bastante tiempo. Pero nunca es tarde si la dicha es buena. Hace unos meses me encantó la iniciativa de David Bonilla. El y Jerónimo López se fueron a la JavaOne y tuvieron el detalle de grabar todas esas cosas que nunca vemos en los videos y de mostrárnoslos en un formato muy ameno. Gracias David y Jerónimo.

Aquí tenéis, si os habéis perdido Bonilla TV y su cobertura de la JavaOne. Estaría bien continuar la iniciativa, ¿verdad?

Para los vagos una muestra.

La lista de la verguenza de España: Las 100 principales empresas de software europeas

Estos días he estado categorizando los posts del blog y he dado con algunos temas muy interesantes. Uno de ellos tiene que ver con un post de hace nada menos que 3 años.

Mostraba la lista con los 100 vendedores de software más importantes de Europa en el 2007. Por supuesto, no había ni una sóla empresa española en el listado.

Claro, con estás he pensado. ¿Y cuántas empresas habrá ahora en el 2010 en al listado? ... ¿Qué creéis?

En efecto: NINGUNA UNA (Gracias Carlos. Había buscado 'ES' en vez de 'SP'). Oye por lo menos en tres años ya tenemos a una. !!! Panda Security, y hay que decir que tienen mucho mérito.

Aquí tenéis para nuestro lamento personal la lista de los mayores vendedores europeos de software del 2010.

¿Está tan mal Irlanda como dicen? Parte II

Como comentaba en el post anterior, no cabe duda de que Irlanda está mal. Sin embargo, en tecnología sigue siendo el lugar para trabajar. Las empresas más grandes están todas allí. ¿Queréis trabajar en Apple? Os podéis ir a Cork, buscan analistas, soporte, gente de Business Intelligence.

¿Os va más la bucólica Galway? Podéis trabajar en SAP o en Cisco (enlace genérico ya que no iba su web de recruitment, pero son uno de los que más Contracts buscan).

Si os gusta más Dublin tenéis Facebook reclutando a cientos y Google casi a miles vamos. ¿Os va más la nube? ¿Qué tal entonces Amazon que buscan muchos expertos de seguridad y desarrolladores, o SalesForce que van más a tema redes y desarrollo de negocio? ¿Y a quien no le gustaría trabajar para una compañía de poker, que está de moda? Está paddy power, que buscan de todo. El chico español que me compró el coche cuando me volvía encontró trabajo en Full Tilt Poker.

En fin, hay muchísimo. Mi CV debe estar por todas las agencias habidas y por haber y os comento que cada día me suelen llegar ofertas (automatizadas, ojo, no me voy a tirar el farol de que andan detrás de mi). Y algunas descripciones a uno le hace caer la baba. A ver que os parece si no:

Un project manager con Agile. ¿Saben lo que es eso aquí en España?: "My client is a medium sized international organization who specialises in e-commerce application development. The are seeking to hire a contract Project Manager for 6 months to help roll out Agile Software Methodology within the organisation. There is a very high possibility of this contract being extended."


Desarrolladores, en Galway. Pinta a Cisco. Agile un plus. ¿Qué tal el sueldo? "My client is a leading Software House just outside Galway City. They currently have 6 java and 6 C++ Software Engineer positions currently available. Agile development experience would be advantageous Salary is up to €75,000 and negotiable depending on experience Pension, VHI, Life assurance, parking, Bonus is very good"

Business Analysts con Agile... vamos, como en nuestras consultoras: "Role: Business Analyst ( 4 jobs available) Location: Dublin Salary/Benefits DOE : 55,000 - 80,000 with Healthcare cover fully paid, Pension, 25 days holidays, bonus. Business Analysis in an AGILE ENVIRONMENT Min 1 yrs ( Web Based ) ESSENTIAL - Understanding of the purpose of User Stories / putting a visual context around a user story"

Este no sé, pero suena que es una pasada. Será Amazon quizás: "I am working exclusively for a client of mine on a huge project and your name came up in a search.This client is a leading E-Commerce organisation with a global presence.We have a significant number of positions available in each of the following areas: Senior Java/J2EE software engineers,Software Development Managers,Build and Release Engineers,E-Commerce PM’s,Software test engineers,Product managers. If you have genuine drive and ambition, and want to join the best company in the world developing cutting edge software on a massive scale, I would like to speak with you as soon as is possible."

Otro: "Senior / Lead Java J2ee Developer. Location: Dublin 2. Key Skills: SCRUM environment - J2EE (EJB, JMS, MDB), Oracle (9i, 10G), MQ and XML, running on a variety of operating systems and middleware products.Money: 60 – 70K + Bonus + Health Insurance + Pension Contribution"

Contracts, salario en la media quizás, tirando a barato. El rango normal es de 250 a 600: "The client has got back to me today and needs 3 developers to start immediately, the rate for this contract is €350 - €380 per day. If you are not available, please pass on these details to any of your friends that might be looking for there next contract.Java/J2ee 5 years minimum experience. Development skills in multi tier Environment required. Agile / Scrum"

Bueno y paro porque estaría todo el día. Estas posiciones son sólo algunas seleccionadas de las que me llegaron estas últimas dos semanas. En serio que no es por nada especial. Debo estar en todas las listas de spam de reclutamiento posibles. La idea es que, sinceramente, en cuanto a tecnología yo en Irlanda sólo veo más y más compañías estableciéndose, centros de investigación y desarrollo que abren, grandes compañías que abren delegaciones, startups, startups y startups que nacen y reciben muchísimas ayudas, ...

Que queréis que os diga, ¿crisis? Seguro que sí. ¿que pueden entrar en quiebra técnica como Islandia o Grecia? Seguro que también. ¿Que van a salir de la crisis mucho antes que nosotros? A mi no me cabe duda, o por lo menos a mi me parece que están apostando a caballo ganador.

Como exponer 100.000 passwords de tus clientes y quedarte tan ancho

Ayer, Abe Voelker hacía públicos varios fallos de seguridad muy graves en las web Progress Software (los que compraron IONA en el 2008). Se trata de fallos muy básicos que exponena públicamente los datos personales, incluyendo las contraseñas, de más de 96.000 clientes. Casi nada.

No voy a entrar en detalle en como acceder a esos datos, ya que todo está explicado en el blog de Abe, y el que quiera puede probar. Pero si os paráis a leer en detalle el artículo, veréis que son realmente conceptos tan simples que uno se pregunta si ha habido algún tipo de revisión de código. Me imagino que los programadores serían inexpertos, más razón para revisar el código. Si ese era el caso es una gran falta de responsabilidad del responsable del proyecto. Si ha sido por desidia, la responsabilidad es doble, del autor y de su superior.


El primero de los ataques, porque vaya es que no sé ni si se pueden definir como ataques, es el acceder a una URL de mantenimiento de perfil, que no se encuentran protegidas. Si ahí pones el nombre del usuario de cualquier persona que haya solicitado alguna mejora en el software de Progress, verás todos sus datos.

La contraseña aparece con asteriscos, pero que no os engañe, es simplemente el campo HTML, si vamos al código fuente el password está en texto plano.

El segundo ataque ya no funcionaba a la hora de escribir esto. Quizás hayan borrado el CGI, o quizás sea simplemente un error tipográfico y se pueda todavía acceder a la información, lo cierto es que no lo he intentado. Pero era más de lo mismo salvo que se exponía toda la información en texto plano en formato XML. Alguno podrá decir, "pero es que hay que conocer los login de todos los usuarios". Nada demasiado complicado cuando tienes una People Community Search. Cualquiera podría hacer un bucle y conseguir las contraseñas de todo el mundo.

Otra curiosidad es que parece ser que las únicas contraseñas que estaban en texto plano eran las de sus usuarios y clientes. Las contraseñas de sus empleados estaban encriptadas, eso sí en SHA1 sin salt. Bueno, pero algo es algo si lo comparamos con la información de los clientes. Supongo que les costaba mucho el reutilizar el código.

El otro día casualmente comentaba con un cliente lo importante que es no utilizar las mismas contraseñas en los diferentes servicios. El me comentaba que siempre utilizaba la misma, y tampoco veía demasiado peligro en ello. Puede que no, a mi tampoco me importa demasiado que me hackeen mi cuenta de Facebook. Pero si ya entran en mi cuenta de Paypal, entonces sí que me puede hacer más pupa :-)

¿Está tan mal Irlanda como dicen? Parte I

No sé la prensa de vuestras regiones/países, pero os puedo garantizar que la prensa gallega es bastante constante en lo que respecta a resaltar la mala situación de Irlanda, la isla esmeralda, otrora tigre celta (celtic tiger) y ahora relegado al apodo gatito celta (celtic kitten). Y para muestra un botón:

http://www.lavozdegalicia.es/pdf/2010/10/H10P1.pdf
La amenaza de bancarrota despierta a Irlanda de sus sueños de nuevo rico
Los Irlandeses buscan un culpable para la crisis
¿Seguirá Irlanda la estela de Grecia?

Bueno, son sólo unas pocas de muchas noticias similares y que claro, hacen que mi suegro y muchos más me estén continuamente soltando comentarios "Qué mal está Irlanda.", "¿Has visto lo que ponen de Irlanda?" Si es que parece que soy ya Brian Cowen. ¿Pero, de verdad está tan mal Irlanda?

Pues la verdad es que sí. Irlanda tiene unos enormes problemas en particular el deficit público debido ya no sólo a la crisis inmobiliaria, que ha dado muy fuerte, sino también a las pésimas infraestructuras y la terrible organización de los servicios públicos. Cualquiera que haya tratado con los servicios públicos irlandeses, desde alcaldías hasta la Hacienda de Irlanda sabrá que son absolutamente encantadores. En serio, eso de mandar una email a Hacienda y que te respondan educadamente al día siguiente para mi es como ciencia ficción; o ir a la seguridad social y que te expliquen todo perfectamente, te ayuden, y todo sin una mala cara, es una pasada.

Ahora bien, son tan eficientes, amables y confiados que se pasan. Uno de los grandes problemas es que tienen cuatro personas para lo que se hace con una, y los salarios que hay que pagar no son como los de aquí. Que aquí los médicos cobran pasta, pero allí no bajan de 200.000 euros como quien dice. Y un administrativo el sueldo mínimo ponle 40.000 tirando muuuuuy por lo bajo, al fin y al cabo el salario mínimo son 1400 (o eran, no sé si ha cambiado) euros al mes.


Pero casi lo peor es lo confiados e inocentes que son. ¿Sabéis lo único que hacía falta hasta hace un año para cobrar el paro? Que alguien fuese con tu DNI a correos cada mes. Aunque no fueses tú. El paro en Irlanda son unos 150€ semanales, que no es mucho, pero si tienes un hijo ya te vas a los 350€ semanales. O sea que una persona puede ingresar unos 1500€ y no me extrañaría que si el otro miembro de la familia también esté en paro pudiese cobrarlo también.

Entonces, tú que harías si eres polaco (por ser los más afectados). Pues lo que hacían muchos. Teniendo en cuenta que el salario medio de Polonia rondará los 600€, parece una buena idea el irse a casa y cobrar el paro que te lo manda cada mes un amigo. Y de paso, hasta me puedo coger un trabajo en Polonia porque total hasta ni se enterarán, y si no quiero líos pues de freelance en negro. Negocio redondo.

Claro, de esto se dieron cuenta. De hecho cuando yo me fuí se comentaba el tema en los periódicos. Y decidieron mejorarlo. Ahora obligaban a las personas a ir con su tarjeta de identificación personal a cobrar el paro. Es decir, que obligaban a estos pillos a coger un avión de ryanair cada vez para cobrar el paro, estar un par de días con sus amigos en Dublin y volverse a casa. No parece un mal plan, ¿no? Por supuesto nada de cursos obligatorios como aquí, o de retirarte el paro si rechazas trabajos, etc. etc. ¿Os imagináis estas medidas en España? Nos vamos a la quiebra en dos meses :D

Pero bueno, me imagino que en este año y medio que llevo fuera algunas cosas habrán mejorado. O eso espero. Le tengo mucho cariño a ese país. Ahora bien, para mi la realidad es que en tecnología sigue siendo el lugar para trabajar. Pero eso me lo guardo para el siguiente post.