domingo, noviembre 07, 2010

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

domingo, noviembre 07, 2010 por Martín


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!
















sábado, noviembre 06, 2010

Yahoo lanza S4

sábado, noviembre 06, 2010 por Martín


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.

viernes, noviembre 05, 2010

JavaOne y Bonilla TV

viernes, noviembre 05, 2010 por Martín

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.

jueves, noviembre 04, 2010

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

jueves, noviembre 04, 2010 por Martín


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.

miércoles, noviembre 03, 2010

¿Está tan mal Irlanda como dicen? Parte II

miércoles, noviembre 03, 2010 por Martín


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.

martes, noviembre 02, 2010

Como exponer 100.000 passwords de tus clientes y quedarte tan ancho

martes, noviembre 02, 2010 por Martín


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 :-)

lunes, noviembre 01, 2010

¿Está tan mal Irlanda como dicen? Parte I

lunes, noviembre 01, 2010 por Martín


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.

domingo, octubre 31, 2010

Cambio de aspecto en el blog

domingo, octubre 31, 2010 por Martín

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!

sábado, octubre 30, 2010

Sobre captchas, tickets y conciertos

sábado, octubre 30, 2010 por Martín


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 :-)

sábado, mayo 29, 2010

Más ofertas para Javeros

sábado, mayo 29, 2010 por Martín

Ú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

miércoles, abril 14, 2010

Un par de ofertas de trabajo

miércoles, abril 14, 2010 por Martín

No suelo poner ofertas de trabajo en el blog pero estas dos son de un cliente de Jobsket, Paradigma Tecnológico. Se trata de una quizás podríamos llamarlo nueva consultora, gente que viene de consultoría tradicional y sabe todo lo mal que se pueden llegar a hacer las cosas. Así que por lo que sé, están intentando hacerlo bien. De hecho patrocinan la Conferencia Agile Spain.

Las dos ofertas son para Madrid:


A ver si a alguno os valen.

lunes, abril 12, 2010

Cañas Áxiles en Santiago de Compostela

lunes, abril 12, 2010 por Martín

Este Miércoles a las 19:00 vamos a hacer unas "cañas áxiles" en Santiago de Compostela para tantear un poco el pulso de la comunidad ágil en Galicia.

Por si algún gallego se apunta, aquí dejo el enlace al hilo donde lo estamos organizando.

Saludos!

miércoles, marzo 24, 2010

Programas "Made In China"

miércoles, marzo 24, 2010 por Martín


Hoy he tenido una conversación que es bastante recurrente en esto del mundo de Internet. Básicamente el argumento sería el siguiente:

"Es que hoy por hoy en Internet yo puedo construir cualquier servicio desarrollado por 3 o 4 programadores llevándolo a China, Europa del Este o Uruguay. Por el sueldo que pago yo aquí en España puedo tener un crack allí."


(vaya por delante una nota, y es que yo soy español pero todo lo que voy a comentar en esta entrada sería igualmente aplicable a una empresa uruguaya, china o de europa del este que quisiera hacer offshoring en España, Portugal o Malta por decir algo)

A más de uno seguro que os suena el argumento. Típico caso de offshoring. El problema de estos argumentos es que siempre vienen de gente que no tiene ni idea de desarrollo de software y se creen que pueden encargar un container de líneas de código y listo, a vender. La realidad es que sí que lo pueden hacer, pero como en la mayoría de los casos sucede lo mismo que pasa con cualquier otra importación de bienes, lo bien que te salga la jugada dependerá de lo que quieres recibir y la calidad que necesitas. Por ejemplo, traerse programas de fuera tiene sentido cuando:


  • Se trata de pequeñas porciones de código, componentes muy concretos y aislados, plantillas, diseños web para trabajos muy concretos, y en definitiva cualquier llamémosle software que pueda ejecutarse o integrarse con facilidad y no requiera de ningún tipo de mantenimiento adicional o necesite únicamente un mantenimiento a corto plazo. Por ejemplo, encargar un reproductor de vídeos, o un visor flash de cadenas para una joyería (como un amigo mio), o una plantilla para el blog corporativo se me antojan como tareas sobre las que no necesitas llevar demasiado control.

  • Cuando no requieras ningún tipo de propiedad intelectual o no te preocupe que te copien. Tenlo claro. Si encargas un diseño a una tienda offshore no te esperes demasiada exclusividad en el resultado. Si encargas un programa para gestionar torneos de pádel, no te extrañe que después otra web tenga un programa como el tuyo (bueno, siendo optimistas, siempre puedes intentar firmar algo con ellos y confiar en que tu abogado sepa de chino en caso de que te copien).

  • Cuando no necesites mucha calidad en el resultado. Cualquiera que haya trabajado con este tipo de factorías ya lo sabe. Yo he tenido tres experiencias. Y los resultados han ido desde desastroso hasta aceptable. Pero siempre que se ha querido un plus de calidad ha sido necesario el poner fondos extra y apretar. Pero es que es normal. Hay gente que se piensa que contrata esclavos chinos que viven en una nave en la que en lugar de máquinas de coser tienen PCs encendidos todo el día, ahí con el Eclipse, y al final la mayoría de las veces son trabajadores asalariados que harán lo mínimo necesario para terminar la tarea. Así que muchas veces o aceptas y te fías con lo que te ofrecen o no te queda otra que supervisar.

  • Cuando necesitas un prototipo sucio de algo y no te importa la calidad. Simplemente necesitas el tener algo que presentarle quizás a un inversor, o para lanzar y ver si hay mercado, etc. Es decir, cuando tienes muy claro de antemano el que si la cosa va para serio, tendrás que contratar gente y rehacer todo desde cero.



En cualquier otro caso, olvídate. Cualquier desarrollo complejo necesita que seas dueño de él, de uno u otro modo. Tendrás que mejorarlo, ampliarlo, mantenerlo. Querrás algo que no esté fallando continuamente. Algo de calidad. Algo que sea resistente, algo que sea predecible. Seguramente necesitarás un produto que funcione para cien usuarios y siga funcionando para cien mil, o por lo menos que se pueda ampliar sin tener que empezar desde cero. El desarrollo de software es algo muy intelectual, no es como fabricar sillas en china.

Recuerdo un caso, en una empresa de las que estuve, en el que el desarrollo era complejo, pero como era un poco marroncillo tuvieron la genial idea de llevárselo a la India. Era como un merge especial de nuestro producto, que nadie quería hacer, así que nada, para allá se fue. Como había muchísima pasta, asumieron que con un ejercito de desarrolladores en la India podrían solucionar el problema rápidamente. Cuando me fuí, habían pasado ya tres años desde que empezara el proyecto. El resultado era seis millones de euros gastados, un proyecto sin ninguna traza de terminarse, un equipo en la India con decenas de personas que había rotado ya en más de tres ocasiones y no quedaba absolutamente nadie del equipo original y un banco muy cabreado. Eso sí, cuando se mandaba a alguien de visita a intentar poner algo de orden, siempre traía anécdotas muy graciosas.

Sinceramente, a parte de los casos que expongo arriba, el único modo que se me ocurre para que una externalización de este tipo funcione, es el que tus socios sean de otro país. Es decir, si tienes un socio en Venezuela por ejemplo (o si eres de Venezuela y tu socio es de España, para que no haya malentendidos), entonces la situación es diferente. Porque esa persona/equipo se beneficiará de lo que hace con algo más que un simple salario de esclavo. Un equipo que desarrolle un producto y qe por ejemplo adquiera los derechos de explotación y comercialización en su continente, aunque sea a comisión, va a ser muchísimo más productivo y tendrá mucha más responsabilidad que otro equipo que simplemente se dedique a mandarte líneas de código en un barco.

Me gustó también mucho lo que nos comentaba Carlos Espinal, en Seedcamp, y era que su compañía sólo invertía en empresas que fuesen dueños y productores de sus propios productos. Es decir, que si eras una startup con 2 MBAs que tenían una fantástica web creada en Polonia por cuatro dueros, ya podías ir saliendo por la puerta. La principal razón, nos comentaba, era porque ¿qué iba a pasar cuando no tuvieses más dinero para comprar fuera? Se trata de una visión mucho más economista, pero no deja de ser cierta. Si los desarrolladores no son parte del equipo, no son socios, o simplemente trabajan por un simple salario. ¿Qué vas a hacer cuando se acabe el dinero? ¿Quién va a programar? ¿Vas a pedirnos más dinero? ¿Y si no hay dinero, ya se ha acabado el proyecto?

Por cierto que yo no he podido ir a la charla pero todo esto que escribo, si no me equivoco está bastante relacionado con lo que cuentan este fin de semana David Bonilla y Jerónimo López en su HumanWare, o explicado con sus propias palabras: "Un programador no es un botijo".

Y no me enrollo más. Seguro que más de uno tiene experiencias que compartir. ¡No dudéis en comentarlas!

sábado, marzo 20, 2010

La horda de testers

sábado, marzo 20, 2010 por Martín

El término Mongolian Horde proviene de las hordas mongolas de Genghis Khan y sus hijos que conquistaron gran parte de Asia y Europa durante los siglos 13 y 14. La estrategia que seguían en sus combates era lanzar miles y miles de soldados contra sus enemigos sobrepasándolos en número y consiguiendo victorias sencillas.



Mongolian Horde es un término que se utiliza en la actualidad en el mundo de los negocios al tratar de resolver un problema a base de asignar más y más personas a la resolución del mismo, pensando (muchas veces inocentemente) que el disponer de más personas asignadas a una tarea hará que ésta llegue satisfactoriamente a su fin. En el mundo del software este término toma relevancia especial por lo habitual que han llegado a ser este tipo de situaciones. George Stepanek lo explica muy bien en su libro "Why software projects fail":

A naive project manager who saw developers as equivalent to each other would be tempted to use the so-called "Mongolian Horde" approach, which uses a large number of cheap and inexperienced developers. Just as with the original Horde, the end result is chaos. Even allowing for their limited design and programming skills, the developers just don't have the experience to organize and deliver a system of this scale.

Some developers can even bring negative productivity to a team. They may not understand the sophistication of the team's code, and will introduce bugs that require lots of rework. They may demand so much help that their own work fails to compensate for the lost productivity of the other team members...


En uno de los últimos proyectos en los que he trabajado me encontré con algo muy similar, pero en un campo en el que nunca lo había experimentado, que es el del testing de programas. Tener testers no es algo demasiado habitual en España, salvo en grandes empresas, mientras que en Irlanda era el pan nuestro de cada día. En todos los proyectos en los que participé había un departamento separado de pruebas. No sólo eso, los testers no tenían idea de programación, ni siquiera eran informáticos. La idea es en este caso tener personas con experiencia en el negocio que aunque no esan informáticos sepan realmente como debe funcionar la aplicación, y no tenga ideas preconcebidas sobre desarrollo de software sino que se comporten como meros usuarios. No es mala idea, pero eso es otro tema.

El caso es que en uno de estos proyectos estaban unos ocho testers. Pero había un problema, nuestro software, que básicamente era una conversión entre formatos de ficheros para entornos bancarios, tenía miles y miles de posibles entradas y salidas. El equipo de testers era muy tradicional, y su lider se negaba a recibir cualquier tipo de ayuda de automatización. Esto hacía que cada vez que lanzábamos una release, que era tras tres semanas porque en desarrollo seguíamos el dictamen Agile, tenían que probar todas esas combinaciones manualmente. Algo totalmente imposible. Nunca llegaban al 20% de pruebas, así que poco a poco el producto iba ganando más y más bugs lo que nos afectaba a desarrollo.

La solución ideada por los managers fue crear una Horda de testers. Contrataron más personas e incluso una agencia externa de testing. Llegó a haber un equipo de 38 testers!!! ¿Os lo podéis imaginar en una empresa que no llega a los 100 empleados? Ni que decir tiene que la iniciativa fue un fracaso. Ellos mismos se dieron cuenta de que tener más testers no significa probar más y mejor la aplicación. De hecho el número de errores aumentó y el número de pruebas realizada disminuyó. Era simplemente demasiado complejo el controlar y formar a tanta gente en tan poco tiempo como necesitaban.

¿Cuál fue la solución? En este caso el marrón me tocó a mi, pero desde desarrollo conseguimos convencerlos de que la única opción es que nos dejasen proporcionarles herramientas para automatizar su trabajo. Lo que hicimos fue separar un grupo de swats (desarrolladores kamikaze jejeje) que creamos un sistema para que ellos pudiesen diseñar tests automatizables. Muy simple y en lenguaje natural. De modo que ellos definian los tests y por detrás nosotros lanzábamos sin que se diesen cuenta acciones de HTMLUnit que iban probrando las páginas webs. Imaginaros, un test podría ser:

- upload /tmp/Test1.xml
- Login:username=martin,password=martin
- click "Results"
- assertExists "Upload Test1.xml successful"
- Validate /results/Test1.xml

Esto es algo totalmente inventado, el lenguaje era incluso más sencillo que esto. Pero os da una idea. Además, los testers podían reutilizar los tests, para crear sus propias cadenas de tests más complejos. En un principio recibieron la herramienta con escepticismo. Ya sabeis, "Aquí vienen estos con más trabajo con lo ocupados que estamos". Pero en cuanto vieron que ahora podían repetir los tests cuando quisieran, que no tenían que andar continuamente haciendo el mismo setup manual, y que un test que les llevaba media hora hacerlo pasaba a llevarles un minuto, la historia cambio. En unas pocas semanas tenían automatizado el 30% del trabajo, mucho más de lo que habían conseguido nunca. Y lo más importante para nosotros, los desarrolladores, al incluir los tests en la build, teníamos garantía de que todo funcionaba.

No sé si alguno de vosotros habéis vivido una experiencia similar, pero os animo a compartirla. Espero que os haya interesado mi historieta.

jueves, marzo 18, 2010

Como escalar tu startup técnicamente

jueves, marzo 18, 2010 por Martín

Poco os puedo explicar yo sobre eso, todavía estamos en la fase de escalar como negocio así que mucha escalación técnica aún no necesitamos. Pero por casualidad descubrí el otro día un video en vimeo muy recomendable donde gente de Doppler, exs de Twitter, Google, etc. explican como fue su proceso de escalabilidad que les han permitido llegar a donde han llegado.

Seedcamp Week '09. Day 3. Technical Panel from Seedcamp on Vimeo.



Tiene partes muy recomendables.

sábado, febrero 20, 2010

Transparencias Spring2GX Madrid 2010

sábado, febrero 20, 2010 por Martín

El pasado Viernes tuve la oportunidad de estar en Grails 2GX con Jordi y Dani presentando nuestra experiencia con Jobsket y Grails. El evento estuvo para mi gusto muy bien, sobre todo con una excepcional asistencia (sobre 450 inscritos y el salón de actos casi lleno) lo cual crea un entorno perfecto de networking, muy de agradecer ya que hay muy pocos eventos técnicos en España. Allí pude poner cara a gente de Agile Spain, otros conocidos de Internet, y curiosamente gente de mi anterior empresa a los que nunca había conocido personalmente.

Alberto Vilches ha publicado un resumen muy completo en su blog y lo mismo ha hecho Tomas Lin en su blog, aunque este último en inglés.

Hemos publicado en Slideshare las slides de nuestra presentación para los que no hayan podido estar ahí:



En la presentación hacíamos una demo del producto que podéis encontrar en YouTube:



Un saludo.

miércoles, febrero 17, 2010

Presentando en Spring 2GX Madrid

miércoles, febrero 17, 2010 por Martín



Todavía no lo había comentado en el blog pero este Viernes estaremos en Madrid presentando nuestra experiencia con Jobsket en el que va a ser casi con toda seguridad uno de los eventos de programación más importantes del año en España, Spring 2GX Madrid donde presentaremos "Productividad máxima con Grails y Java".

Se trata de un evento totalmente gratuito, y que debe todo el mérito a organizador a Sergi Almar y javaHispano y también escuela de groovy que es uno de los principales promotores de Grails en España. No os lo deberíais perder, no porque vayamos nosotros la verdad, sino porque cuando todo el mundo está cobrando por los eventos, este no cuesta ni un euro.

Creo que hay ya varios cientos de personas registradas (creo que rondando los 300 o más), así que el evento promete bastante como oportunidad de networking. Si os pasáis por allí, no dejéis de saludar.

sábado, febrero 13, 2010

TV oriented development

sábado, febrero 13, 2010 por Martín



En una de las empresas en las que trabajé en rlanda me pasó lo que probablemente fue ha sido el momento más rocambolesco de mi carrera. Y es que a veces los managers tienen una extraña concepción de lo que puede y no puede motivar a un equipo.

Os pongo en situación: Un banco pagando X dinero (mucho, mucho) al mes durante 24 meses y la aplicación no ha llegado a nada. Ya se sabe como son estas cosas. Grandes especificaciones que tardan meses en completarse y mientras tanto ni una línea de código, a vivir. Llega el momento y resulta que no llegamos a esos 50000 usuarios concurrentes que necesitamos. Hay que contratar personal extra. Ahí llego yo, con seis meses ya de retraso acumulado y sin rumbo claro. Pasan los meses y poco cambia. Por mucho que queramos hacer cosas todo está dirigido por especificaciones inamovibles e irrealistas. Proyecto abocado al fracaso.

Llega el momento del ultimatum. El banco lo quiere ya y necesitamos la aplicación en quince días. ¿Cómo podemos motivar al equipo? Pues a alguien se le ocurrió la siguiente idea tan fenomenal y que he bautizado como TVDD o TV-Driven Development:


  1. Comprar una televisión de 42 pulgadas (doy fe de que se puede reusar posteriormente para apostar a las carreras de caballos).

  2. Colocar la televisión en la entrada para que sea lo primero que ven los empleados al entrar en la oficina.

  3. Mostrar lo más grande que se pueda la cuenta atrás para el día fatídico. 15,14,13,12,...

  4. Preparar un PowerPoint cada día donde figuren las incidencias más críticas en JIRA y mostrarlo en grande como índice.

  5. En sucesivas páginas del PowerPoint, relatar la incidencia y el responsable de arreglar esas incidencias.

  6. Hacer saber a los empleados que esta medida es para que todos mantengamos el foco en el objetivo a conseguir en las próximas dos semanas y que nadie se dedique a otra cosa más que a solucionar sus incidencias.



Así que los "afortunados", y me incluyo porque a mi me tocó alguna, llegábamos por la mañana tan tranquilo y nos encontrabamos con un pantallón donde veías los días, y si "tenías suerte" tu nombre saldría en grande y tendrías tus minutos de gloria ya que alguien te habría asignado un marrón del que probablemente nunca habías oido hablar porque se había colado entre los cientos de documentos Word que los business analyst habían estado reenviando de aquí para allá.

Si alguno está interesado en aplicar esta metodología en su empresa, por favor que me avise primero para evitar acercarme a un kilómetro a la redonda :-) No os tengo que decir que la metodología falló estrepitósamente. En realidad nos lo tomamos bastante a guasa. Lamentablemente la cuenta atrás terminó en el número 7. El banco canceló el proyecto y hubo que despedir a la mitad de la plantilla.

El final es feliz ya que la empresa perdió mucha de la gente que no estaba favoreciendo al rumbo. De hecho, eramos !9 arquitectos! (para unos 50 desarrolladores) y nos quedamos en 3, lo que es un número mucho más razonable. Conseguimos que se cambiase la forma de trabajo a una metodología ágil y reconstruir el producto con iteraciones claras. La empresa por fin, tras unas semanas consiguió un producto que vender, y de hecho se consiguió vender a varios bancos mucho más pequeños. Han pasado varios años, muchos nos hemos ido y la empresa no está pasando los mejores momentos, pero es uno de los lugares donde más he aprendido sobre como transformar algo que está podrido desde su raíz incapaz de sacar algo a la luz en una empresa que realmente produce productos y vende software que funciona.

En definitiva, que si un proyecto está retrasado, seguramente ni el no tener una televisión de 42", ni el no tener una cuenta atrás, ni el no tener JIRAs amenazantes, ni el traer refuerzos de última hora van a hacer que el proyecto se salve. Profesionalidad y asumir el "mea culpa", reconocer que las cosas se están haciendo mal y cambiar completamente el chip.

En mi opinión, sólo con la honestidad se puede salir adelante en proyectos como este. No sé si alguno tenéis experiencias parecidas. Os animo a compartirlas

jueves, enero 28, 2010

Kanban vs. Scrum en castellano

jueves, enero 28, 2010 por Martín


A esto le hay que dar publicidad. Angel Medinilla lo comenta mucho mejor en su blog. Desde hace unos días en Agile Spain estaban traduciendo el libro Kanban vs. Scrum al castellano.

El resultado de la traducción ha quedado un poco grande (74Mb), pero están en ello. Los cracks que nos permiten disfrutar del contenido traducido son Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano.

Gracias a todos ellos. El libro lo podeís descargar desde aquí.

PS: Imagen via crisp.se

jueves, enero 21, 2010

We Are Developers!

jueves, enero 21, 2010 por Martín

Se me pasa Enero y todavía no he escrito ningún post serio. Y esto no puede ser. En Diciembre tuve la suerte de ser invitado a las III Jornadas Java de Alicante donde hablé un poco sobre mi experiencia en el desarrollo ágil. Las transparencias de mi charla están aquí, pero como tuvimos mala suerte no hubo manera de recuperar el audio. Así que como hay una serie de diapositivas que necesitan su explicación, voy a ver si tengo la constancia para mantener una serie de posts sobre el tema.

La primera imagen que mostraba en la charla era super llamativa:



Es un cartel de la película 300. Esta es una de las cosas que he aprendido desde que soy desarrollador. Y es que un equipo pequeño puede hacer las cosas mucho mejor que un equipo 50 veces mayor. Parece una barbaridad, pero al menos a mi la experiencia me ha mostrado que es así. En mi caso personal tengo a Jobsket. No nos quiero tirar flores. Somos tres personas y hacemos lo que podemos, lo mejor que podemos. Pero todos los clientes a los que vamos se quedan alucinados con el producto y con el hecho de que seamos tres personas en el equipo. Técnicamente todo el mundo coincide en que somos mucho mejores que las alternativas. El aspecto comercial ya es otra historia, claro :)

Pero no quiero ser egocentrista aquí. En la charla hablaba de otra historia. Una historia de tres amigos que fueron capaces de hacer un producto mejor y más querido que el desarrollado por una empresa con más de cien personas dedicadas al mismo. Mis amigos tenían el software funcionando a los pocos meses, mientras que a la empresa en cuestión le llevó años ponerlo en marcha, y creo que aún están en ello. Cuando lo puso en producción causó el caos absoluto: pésimo rendimiento y consumo de memoria y recursos, falta de usabilidad, quejas de los usuarios, vamos que casi causan una huelga general.

Por el contrario todos los usuarios del software de mis amigos lo quieren con locura. ¿Cómo lo consiguieron? Pues siguiendo una serie de medidas muy simples y de mucho sentido común:

  • Desarrollo iterativo.

  • Despliegue de versiones cada poco tiempo.

  • Implementar sólo las funcionalidades que quieren los usuarios.

  • Reunirse frecuentemente con los usuarios y que sean ellos los que decidan como quieren que funcione el interfaz.

  • Evitar el desarrollo en cascada. No perder el tiempo con arquitecturas mastodónticas que tardan meses en materializarse.

  • No perder demasiado el tiempo en documentación. Es necesaria, pero al estar los usuarios tan metidos en el diseño del sistema, lo cierto es que todos ya sabían como se usaba la aplicación. Evitar documentar al principio.

  • Trabajo. No hace falta ser los mejores para que todo funcione. Normalmente con dedicación, empeño y disciplina todo se consigue.



Son unos cracks. La gran clave por la que los usuarios querían la aplicación artesanal y no la llamémosla industrial era sin duda la involucración de los usuarios. En realidad el equipo de mis amigos no eran tres personas, sino que eran ellos tres más los cientos de usuarios que participaron en su desarrollo. Usuarios que fueron construyendo ellos mismos la aplicación. Usuarios a los que se les tuvo muy en cuenta a la hora del desarrollo. Y a la hora de la verdad, los usuarios sienten esa aplicación como suya. Es algo en lo que han participado y que se ha desarrollado tal y como a ellos les es más útil para ahorrarse trabajo. Trabajando de esta manera, es muy difícil que los usuarios prefieran otro proyecto, lo desarrollen, 3, 30 o 300 personas.

No sé si soy yo pero para mi el cartel y la película de 300 me recuerda un montón a un departamento de desarrollo. Me imagino que otros departamentos pueden pensar lo mismo del suyo, pero el hecho de que somos un tipo de trabajadores que suele estar aislado, que sufre la ira de managers y usuarios :), y ahí estamos, resistiendo, intentando ser profesionales y hacer las cosas bien mientras los comerciales nos asedian con nuevos marrones y funcionalidades. No sé como lo veis vosotros, pero a mi se me asemeja la historia bastante. Eso sí, al final los espartanos siempre pierden. mmmm, da que pensar :)