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

martes, enero 05, 2010

Vota por Jobsket en el BBVA Open Talent Contest

martes, enero 05, 2010 por Martín


Algunos lo habréis visto ya en el lateral de este blog. En Jobsket nos presentamos al concurso del BBVA Open Talent cuyo premio son nada más y nada menos que cien mil eurillos de nada.

Como sé que muchos (como yo con otros blogs) sólo leéis este blog por el lector de feeds, he decidido publicar este post para animaros a votarnos y ayudarnos a llegar a la siguiente fase.

Podéis votar desde este enlace: o pinchando en votar en el siguiente iframe:

A ver si hay suerte.

Un saludo y muchas gracias!

domingo, enero 03, 2010

¿Cuántos servidores puede administrar simultáneamente un administrador de sistemas?

domingo, enero 03, 2010 por Martín

Lo comentan en Data Center Knowledge y también en en Slashdot.

Entre los comentarios se sacan datos muy curiosos como que en Facebook asignan un administrador para cada millón de usuarios. Partiendo de que tienen más de 30000 servidores y 230 ingenieros, utilizando 30000 como el dato exacto saldrían 130 servidores por administrador.

En Microsoft todo está más automatizado y comentan que un sólo administrador trabaja dentro del ratio de 1000 a 2000 servidores.

sábado, enero 02, 2010

Lo más visto en Pensamientos Ágiles en el 2009

sábado, enero 02, 2010 por Martín

Bueno, primeramente Feliz 2010, que ya tocaba decirlo. Y seguidamente continuo con mi tradicional lista para los más curiosos de lo más visto en el blog en el 2010:


Este año la actividad de posteo ha decrecido considerablemente debido a Jobsket y parece que el 2010 tiene la misma pinta así que intentaré ser un poco más selectivo con las publicaciones. Muchísimas gracias a todos por las 37000 visitas que ha tenido este blog este 2009, casi nada. Casi tanto como los más de 800 subscriptores al RSS. Cifras increibles para este pequeño espacio y que son un reto para este año. ¡A ver si soy capaz de mejorarlas!

¡Feliz Año!

miércoles, diciembre 30, 2009

Resumen de Agilismo.es en AdictosAlTrabajo

miércoles, diciembre 30, 2009 por Martín

Que envidia la nota sobre el primer coding dojo organizado por agilismo.es en Madrid. En AdictosAlTrabajo publican una nota sobre como fue este evento. Destacan la edad de los participantes, parece que el preocuparse por tu código, por su calidad, por hacer bien lo que te gusta y en definitiva, por ser un buen profesional viene más a los treinta que a los veinte.

El video sirve para ponerle la cara a muchas de las personas que frecuentan Agile Spain. Y se nota que había muy buen rollo.

viernes, diciembre 11, 2009

Instantáneas del almacén de Amazon en UK

viernes, diciembre 11, 2009 por Martín

Un poco fuera de contexto pero no puedo evitar poner esta foto:



Se trata del almacén de Amazon en Milton Keynes, al sureste de Inglaterra. Impresionante. Le dedican un artículo en el Daily Mail.

Update: Creo que el de Swansea no se queda corto:



Más instantáneas aquí.

Podcast sobre test de aplicaciones

viernes, diciembre 11, 2009 por Martín

En javaHispano han publicado un podcast hace unos días donde participan Alfredo Casado, Julio César Pérez y Jose Luis Bugarín y que se lo recomendaría a todo el mundo ya que explica muy bien el por qué es tan importante hacer testing, sus beneficios y todo lo que no perdemos al no hacerlo. Al igual que comentaba yo mismo en mi charla en Alicante, de la que todavía tengo pendiente el escribir varios posts, estamos en un momento donde una persona que no haga tests no se puede considerar un buen profesional. Señores, quitémonos el chip de monos picateclas porque el desarrollo de software es mucho más, y el testing es sólo una de las habilidades que un desarrollador ha de tener. Muy buen podcast.



El podcast lo podéis escuchar aquí mismo o descargaros el MP3 original desde la página de javaHispano.

miércoles, diciembre 09, 2009

Apúntate a la Beca Alzado 2009

miércoles, diciembre 09, 2009 por Martín



Desde hace unas semanas se pueden enviar ya proyectos para la Beca Alzado 2009. Se trata de un concurso donde tan sólo hay que enviar una idea y la que el jurado considere la mejor se llevará un premio de 3000 euros. Lo mejor del concurso es que no hay ataduras de ningún tipo, es decir, el ganador del concurso no tendrá que ceder una parte de su empresa ni hacer nada a cambio. Tampoco hay ninguna fase de votación popular que tanto favorecen a los proyectos con comunidades establecidas, ni es necesario pues el mendigar votos por Internet o convertirte en fan del concruso en Facebook y estrategias similares que simplemente buscan promocionar el concurso.

En el 2008 nosotros ganamos la Beca Alzado y tengo que decir que todo lo prometido es cierto. Ninguna atadura. 3000 euros y listo. ¡Y que bien nos han venido! Quizás el hecho de que hubiese ganado un proyecto como Jobsket, tan complejo, esté echando un poco atrás a alguna gente este año, pero lo cierto es que me han comentado que el número de proyectos inscritos está siendo menor. Es por ello que os animo a todos a enviar vuestra ideas, ya que es algo que no lleva demasiado tiempo y si tenéis algo en mente, el ganar puede ser una enorme excusa para materializarlo.

Así que ánimo y mucha suerte a los que se presenten.

miércoles, diciembre 02, 2009

Transparencias III Jornadas Java de Alicante

miércoles, diciembre 02, 2009 por Martín

Ayer estuve hablando en las III Jornadas de tecnología Java en Alicante donde estuve hablando de metodologías ágiles y de como aplicar algunos de sus principios en lenguaje Java.

Creo que la charla fue bien y bueno os dejo aquí las transparencias. Me reservaré unos cuantos posts para hablar de la parte de historietas de guerra que en las transparencias no queda muy claro lo que significa.



Una pena no poder poneros el video pero a mitad de la charla se le acabó la pila al micrófono así que dejo de funcionar y no se oía nada por el streaming.

martes, noviembre 17, 2009

Estaré en la III Jornada de Tecnologías Java en la Universidad de Alicante

martes, noviembre 17, 2009 por Martín


Dentro de dos semanitas, el 1 de Diciembre tendré el placer de participar en la III Jornada de Tecnologías Java en la Universidad de Alicante a las que muy amáblemente me invitó a participar Domingo Gallardo.

El título de la charla es "Desarrollo y pruebas de proyectos Java en un entorno ágil" y bueno hablaré un poco sobre lo que voy contando aquí en este blog. Meteré bastantes batallitas irlándesas que es donde más me he empapado de todo lo que implica el agilismo, pero sobre todo intentaré explicar lo que significa para mi el ser un profesional del software, que es lo que siempre he querido ser, y como conseguirlo aplicando técnicas ágiles.

La charla lleva la coletilla Java pero será simplemente para poner algunos ejemplos. El 95% por cien de la presentación se puede aplicar a cualquier lenguaje. Pues nada, que os animo a pasaros por allí.

miércoles, noviembre 11, 2009

Ofertas de trabajo en Abiquo, Barcelona

miércoles, noviembre 11, 2009 por Martín


Diego Mariño, co-fundador de Abiquo me manda una serie de ofertas para que las publique por aquí, a falta de estar Jobsket listo para empresas :) Tal como anda la cosa es algo raro que alguna empresa busque de golpe más de cinco personas, pero esta empresa está en una fase importante de expansión y puede ser una buena oportunidad si alguien vive o no tiene problemas en mudarse a Barcelona. Además, que no se puede decir que haya muchas empresas innovadoras y donde pueda trabajar en cloud computing en España (¿hay alguna otra?) al tiempo en que compites contras superpotencias como Amazon, IBM, Microsoft, etc. así que seguro que hay emoción.

Os dejo por aquí los enlaces a las mismas por si no conocéis la empresa:

Java Architect

Tasks and responsibilities

* Develop standards and guidelines for the products
* Rollout and train guidelines to development teams
* Coordinate technical decisions
* Review and approve technical designs
* Manage the consistency, integrity and reliability of the architecture
* Advise senior management on current and future technologies
* You will report directly to the Chief Technology Officer



Senior Java Developer

Key Experience:

Core Java, Hibernate, Spring, Web Services, Java Software Engineer/Developer



Java Engineer

Key Experience:

Core Java, Hibernate, Spring, Web Services, Java Software Engineer/Developer.



Senior Flex Developer

We have 2 important opportunities available for highly skilled experienced senior flex/java developers to join the team. You should have more than 2 of years of development experience with Flex (client-side) and Java Developing (server-side) with a smattering of design and usability. It is equally important being formerly a hands on developer.



Virtualization Expert

Key Requirements

* Master’s or Bachelor’s Degree in Computing Science
* VMWARE, XEN, KVM, VirtualBox, Hyper-V (Installation and Administration)
* Storage Systems (OpenStorage, netApp, dell equalogic, etc)
* Network (Virtual Switch, network infrastructure, etc.)
* Programming skills (scripting, JAVA, etc.)
* Excellent communication skills (English & Spanish)



SysAdmin

Tasks and responsibilities

* Coordinate technical decisions
* Review and approve technical designs
* Manage the consistency, integrity and reliability of the architecture
* Advise senior management on current and future technologies
* Give support to the customers
* Maintain multiple services (web server, DNS, etc)
* Maintain and improve development environment
* You will report to the Chief Technology OfficerTasks and responsibilities



QA Test Engineer

* Test requirements and specifications for incorrect or incomplete information, assumptions and conclusions
* Apply that knowledge in the development and implementation of test plans, test objectives and test scheduling
* Organise and carry out functional and non-functional testing within an iterative Scrum-based development environment
* Collaborate closely with developers, product managers and support engineers to correctly identify, prioritise and resolve issues
* Create, review and maintain robust automated regression and data-driven tests
* You will report directly to the Chief Technology Officer

Todos los detalles en el post de su blog. Mucha suerte si os apuntáis.

lunes, noviembre 09, 2009

Tus builds de Hudson en Campfire

lunes, noviembre 09, 2009 por Martín

Ojeando los plugins de Hudson he descubierto de casualidad que desde hace un par de semanas está disponible un plugin para Campfire. Lo que quiere decir es que puedes configurar tus build para que publiquen sus resultados en Campfire. Para los que se nos olvida chequear el email y se nos pasa que hemos roto la build.

La página del plugin es esta y su instalación es trivial. Ojo que es necesario tener la última versión de Hudson para que funcione. Aquí tenéis el anuncio por parte de los autores. Una captura con la configuración:



Y su consiguiente resultado en Campfire:

jueves, noviembre 05, 2009

Como sacar un producto en Internet con presupuesto 0

jueves, noviembre 05, 2009 por Martín

Los chicos de TetuanValley han creado hace poco una escuela para Startups y hace unos días pedían en Twitter videos de empresas o personas que tuvieran algunos consejos para los equipos de la escuela.

En Jobsket nos hemos animado a mandar algo, y fruto de esto es el video que podéis ver a continuación:

Bootstrapping tips for the guys at TetuanValley from Jobsket on Vimeo.



Un colega me comentaba el look vagabundo que tengo en ese video, jejejeje, pero es que eso es parte de uno de los tips. ¡Ahorro de Costes! Así que hay que ahorrar hasta en crema de afeitar :D

En fin, el video está en inglés, pero un inglés de ese de los nuestros así que debería ser fácil de entender. Por si alguien no lo entiende os resumo los consejillos:


  • No buscar dinero de VCs o Business Angels al principio, al menos si no tienes contactos. Porque sólo con la idea es enormemente difícil, y si encima sois todos técnicos entonces hay 0 posibilidades.

  • Trabajar a tiempo parcial manteniendo el trabajo normal. Eso debería servir para ahorrar algo de dinero y forzar un poco de sacrificio. El sacrificio es bueno para ver si todos los socios están en el mismo barco.

  • Ahorrar por todas partes. Por ejemplo, nada de lujos como el cloud computing, con un simple servidorcillo virtual llega más que de sobra para tener ir prototipando.

  • No planear a largo plazo. Iteraciones de desarrollo y crecimiento muy cortas y que siempre generen algo "palpable". Pensar en tener algo a 4, 6, 12 meses es una locura, porque eso nunca pasa. Cuando no se tiene financiación, nunca se sabe cuando puedes tener una oportunidad para enseñar tu producto o cuando alguien se va a interesar por el. Por eso es muy importante forzarte a que cada poco tiempo, por ejemplo dos semanas, haya que desplegar un producto totalmente funcional. A partir de ahí, construir incrementalmente.

  • Buscar concursos buenos, bonitos y baratos. Los concursos nos permiten validar nuestra idea. Si ganamos o quedamos finalistas, significa que hay gente a la que le gusta. Si nunca llegamos a las finales, hay que obtener feedback porque es posible que no nos demos cuenta de algo que el resto de gente sí que está viendo en nuestro proyecto y que evita que triunfe. Si ganamos, es dinero barato porque muchas veces estos concursos no piden parte de tu compañía. La beca alzado 2009 es uno de esos concursos ideales. Desconfiar de otros concursos que buscan más su autopromoción (ej: para participar tendrás que invitar a 100 amigos de tu Facebook al concurso) que el ayudar al emprendedor.



Y nada más. ¡Espero que a alguien le sirva de algo!