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.

Cambio de aspecto en el blog

Los que conozcáis este blog desde hace tiempo y os paséis por la web habréis notado un cambio notable de aspecto.

He instalado una plantilla algo más profesional. Tendré que acostumbrar a ella y a la forma de categorizar los posts. Seguramente tenga que pasar algún tiempo editando etiquetas y todo esto.

Espero que comprendáis que seguro que habrá cosillas que no funcionen. Iré corregiéndolas con el tiempo.

Saludos!

Sobre captchas, tickets y conciertos

Han pasado casi cinco meses desde mi último post, y la verdad es que hoy me he pasado por el blog y me he sorprendido al ver 990 lectores por Feedburner. Evidentemente, la mayoría de estos lectores son como yo, no leen los feeds a los que están suscritos, pero vaya que me ha hecho pensar "pero que coño estoy haciendo que estoy abandonando este blog en el que tanto trabajo he puesto". Así que he hecho el propósito de poco a poco ir retomando la actividad. A ver cuanto dura :)

Y empiezo con un tema que hace tiempo que había visto y me había entusiasmado. Últimamente no sé que pasa pero me he vuelto un apasionado de todo lo relativo a los cibercrímenes. Así que quizás tenga nueva temática para el blog. Este tema lo recordé gracias a un gran y muy educativo artículo de José Manuel Alarcón llamado reCaptcha, mucho más de lo que ves a simple vista, y en el que explica muy detalladamente como funcionan los Captchas y por qué hay tanta gente deseando romperlos. Si sois de los que piensan que son simplemente dos palabrejas que hay que meter de vez en cuando para ver si somos robots o no, echarle un vistazo porque veréis que hay mucho más.

La verdad es que a mi lo que más me gusta es la parte oscura :-) Pero voy al tema. Creo que todavía estaba en Irlanda cuando leyendo el Metro había visto que habían detenido a una banda que se dedicaba a saltarse Captchas para comprar tickets de conciertos. Recuerdo que me sorprendió porque me pareció la caña. Pues bien, hace tan sólo unos días leía que ese caso será definitivamente juzgado en Marzo, ya que hasta ahora se encontraba en un laberinto legal, pero definitivamente una juez de Nueva Jersey ha decidido proceder al juicio donde se busca condenar a esta banda por fraude electrónico y diversos abusos contra una ley de Anti Hacking o algo así :)

Podéis ver la historia completa en Wired que a mi me ha parecido apasionante. Nada más y nada menos que 25 millones de dólares en beneficios ha hecho esta gente, en siete años de nada. Para ello contrataban bloques de IPs y varias redes de ordenadores remotos que lanzaban contra webs como Ticketmaster en los momentos en los que comenzaban las subastas más interesantes, haciéndose con grandes cantidades de tickets. Algunos datos del juicio son impresionantes. Por ejemplo en el 2006 consiguieron comprar 882 de los 1000 tickets disponibles para la Rose Bowl (título de futbol americano universitario) o en 2007 que compraron 1924 tickets para los playoffs de los Yankees.

Pero lo mejor fue cuando Ticketmaster se dio cuenta de que algo no iba bien y cambió el algoritmo a utilizar Re-Captcha. Entonces la banda decidió crear bots para descargarse todos los captchas, que están identificados por ids, y creó una enorme base de datos de cientos de miles de Captchas asociados con sus respectivas ids. Bueno, ya sabéis para que sirven estos trabajos que se anuncian por correo "Trabaja desde casa. Gran sueldo. No se requieren ningunos estudios!", o quizás simplemente contrataran personas al kilo para leer captchas. También parece que configuraron su red de bots para que cometieran fallos a posta para evitar ser cazados por los filtros anti-fraude de las casas de tickets.

Pero la red iba todavía más allá. Ellos ya no eran ni siquiera los que vendían los tickets. Ejercían de intermediario. Había una red completa de brokers de tickets, usease reventas, que les proporcionaban sus datos y su tarjeta de crédito a la red, y la banda lanzaba sus ordenadores garantizándoles la compra, entiendo que por su correspondiente márgen. La leche, vamos.

No sé si vosotros os podíais imaginar que los Captchas daban para tanto pero a mi todo esto me parece de película :-)

Más ofertas para Javeros

Últimamente ando un poco metido a job board. Algo que habrá que arreglar en los próximos meses. Por ahora ya tengo pensadas algunas cosas, falta materializar, y claro, tiempo.

Mientras tanto, quizás alguien esté buscando trabajo en Java. La empresa Biko nos acaba de publicar dos ofertas muy interesantes en Jobsket. Una es para un perfil Junior, y otra es para un perfil senior. Conociendo a Joserra desde hace muchos años en Internet seguro que es un buen sitio para trabajar y para familiarizarse con buenas prácticas, metodologías ágiles y TDD.

Os las dejo aquí por si a los que visitáis este blog os interesan:

http://www.jobsket.es/trabajo/biko2-2006-sl/desarrollador_senior_java


http://www.jobsket.es/trabajo/biko2-2006-sl/desarrollador_junior_java

Además por lo que publican en video, parece un buen sitio para trabajar jejeje