Hoy estoy especialmente prolífico en el blog. No sé si tendrá que ver con que he estado escuchando un podcast de JavaHispano en el que entrevistaban a Jaime Cid y en el que hablaban de la Empresa 2.0 según Oracle.
Bueno, resulta que tengo un iPod, con el que escucho podcasts, que obtengo de la red mediante RSS. Sigo varios blogs, algunos técnicos y otros menos. Asisto a presentaciones que se han guardado en GoogleVideo, Youtube u otras redes por el estilo. He hecho algún curso online y he participado en algún que otro webinar. Participo en varios foros y comunidades online, p.ej. Agile Spain. Con cierta asiduidad publico en mi blog y además, sigo y soy seguido por Twitter: por la web, porque no tengo iPhone. Ya os oigo decir “¡Ay! ¡Pobrecito! ¡Que no tiene iPhone!”. Tengo todo mi correo en las nubes y comienzo a tener documentos, presentaciones, videos e incluso un calendario. ¡¡Incluso código!! Claro, también estoy en LinkedIn y en Facebook. Mis “bookmarks” los tengo también en Foxmarks (parecido a Delicious). Muchas de las páginas que visito las comparto con GoogleReader o incluso subrayo lo más interesante con Diigo. Y además, el día 2 de abril estaré en Madrid en el taller sobre “Cloud Computing” que organiza Abiquo.
¿Se me olvida algo? Como dice Jaime Cid en el podcast, “para saber qué es esto del Web 2.0, hay que practicarlo”.
Creo que soy un hombre 2.0, bueno, quizás sólo un adolescente, pero es que me conservo muy bien para mi edad.
Archive for March, 2009
29 MarSoy un hombre 2.0
29 MarUdi Dahan en Madrid
El próximo 7 de abril va a impartir en las oficinas de Microsoft en Pozuelo (Madrid) un tutorial sobre SOA y DDD como parte de los Architecture Days 2009 que organiza iMeta (multinacional con sede en Málaga). Y aunque Udi está relacionado fundamentalmente con el mundo .NET, Hadi Hariri (uno de los organizadores del evento) me ha explicado que el tutorial es a nivel de diseño, por lo que no se entra en detalles específicos de ningún lenguaje o plataforma (léase .NET o Java).
Así que he decidido pegarle otro pellizco a mis deteriorados ahorros para escuchar lo que nos tiene que decir “The Software Simplist” (en inglés, ups).

29 MarSalir de la crisis requiere aportar valor
En España llevamos un importante retraso con la utilización de estas metodologías, pero estamos ante una oportunidad única. La crisis requiere que los profesionales de la informática seamos capaces de aportar más valor a nuestro trabajo.
Bueno, también los bancos tendrán que ayudar un poco con el tema de los créditos y los empresarios y emprendedores con su cuota parte de riesgo. Pero nosotros, en la parte que nos corresponde, tenemos que dar un paso adelante y dejar ese típico fatalismo ibérico del “que inventen ellos” o del “total, aquí eso nunca lo podremos hacer…”.
Ánimo, plantaos delante de vuestros jefes y explicadles que hay otras maneras de desarrollar software y que pasan por centrarse en aportar valor a los clientes, y no en echar cubos y cubos de “sangre, esfuerzo, lágrimas y sudor”… y documentos, claro.
Por cierto, en Agile Spain estamos recopilando todos los cursos de Scrum que se van a organizar en los próximos meses en España. Algunos son bastante económicos, pero si aun así vuestro presupuesto no da para eso, estad atentos a la lista de correo porque anunciaremos en breve una charla gratuita sobre Scrum que impartirán nuestro compañero Juan Gutiérrez y el profesor de la UPM Agustín Yagüe.
27 MarSincronizar de GoogleCode al Repositorio Central de Maven
Finalmente lo conseguí y la versión 1.3.1-RC5 de Concordion ya está en el repo1 de Maven. Y ahora está sincronizado el repositorio de GoogleCode con el repo1, con lo que ya no tenemos que depender de construir manualmente un bundle y abrir una petición en JIRA, como he explicado en una entrada anterior. ¡Guau! Esto es un avance. Ahora sólo hay que hacer release con los comandos “mvn release:prepare” y “mvn release:perform” y esperar a que ocurra la sincronización…
24 MarConcordion 1.3.1-RC5
http://concordion.googlecode.com/svn/repos/releases
Para los que tengáis un proyecto en GoogleCode y no sepáis cómo publicarlos en el Repositorio Central de Maven, podéis echar un vistazo al wiki del proyecto Concordion donde explico (en inglés) cómo hacer una release usando maven-release-plugin. También os resultará útil ver la solicitud que hice en el JIRA pues allí he ido relatando cómo he ido resolviendo el asunto. Lo siento, todo está en inglés, pero os lo puedo resumir:
1) Usar Maven 2.0.9 (yo utilizaba el embedder y hasta que no pasé a la 2.0.9 no conseguí avanzar)
2) Usar dav:https://concordion.googlecode.com/svn/repos/releases en la sección distributionManagement del pom.xml
3) Incluir username y password en nuestro settings.xml (tenemos que ser desarrolladores del proyecto para poder hacer commit en SVN, así que también para hacer deploy con Maven)
El último paso es, depués de hacer release, crear una entrada en el JIRA solicitando la sincronización. Yo he utilizado estos valores y estoy a la espera de conocer el veredicto.
“org.concordion”,”/home/maven/repository-staging/to-ibiblio/maven-svn”,”svn”,”Jose M Beas”,”jose.m.beas@gmail.com”,,”http://concordion.googlecode.com/svn/repos/releases/”

18 MarSubir una versión en GoogleCode al Repositorio Central de Maven
He utilizado maven-release-plugin para conseguir que ejecutando mvn release:prepare me haga en Subversion los siguientes cambios:
1) commit tras quitar el -SNAPSHOT de la versión y poner el número de versión 1.3.1-RC5 en el pom.xml
2) copia de esa revisión a la rama de etiquetas (tags) con el nombre adecuado (en mi caso concordion-1.3.1-RC5)
3) commit tras quitar el número de versión de la release y en mi caso dejar 1.3.1-SNAPSHOT, pero si hubiera sido la final hubiera puesto 1.3.2-SNAPSHOT, por ejemplo
Y luego, ejecutando mvn release:perform, Maven descarga el código etiquetado y ejecuta repository:create-bundle para obtener el bundle que manualmente debo subir al area de Downloads de mi proyecto.
Finalmente, con el bundle ya en un sitio público (y relacionado claramente con mi proyecto), solicito el “upload” en JIRA.
Todo el proceso lo he documentado en el wiki del proyecto (aunque, claro, está en inglés).
Espero que os ayude y si por casualidad os enteráis de cómo hacer “sync” desde GoogleCode, por favor, contadmelo porque quiero poder automatizar completamente el proceso. Yo, por mi parte, en cuanto tenga tiempo echaré un vistazo a Google Code Upload Maven Plugin.
Actualización:
He modificado el procedimiento para solicitar la publicación en el Repositorio Central de Maven para que se sincronice con un repositorio remoto (también en el SVN de GoogleCode). Más detalles en el siguiente post.
17 MarSalir de la crisis
a) Porque ahora hay que reducir costes y los errores son costosos (muy costosos)
b) Porque el sector ha madurado y se ha dado cuenta de que así no se puede seguir y se necesitan expertos en asegurar la calidad de los desarrollos.
c) Quizás es que se hayan dejado de contratar desarrolladores porque ya no hay desarrollos y, proporcionalmente, parezca que han subido las necesidades de otros puestos.
Obviamente descarto la opción b) por irreal y la c) porque me parece difícil de que sea así (es una sensación). En cambio, la opción a) me parece plausible. Es posible que, por fin, esté calando el mensaje de los 70 de que el coste de los errores de desarrollo se multiplica en varios órdenes de magnitud cuando éstos llegan a producción y en España estemos empezando a salir de la crisis del software.

16 MarLa culpa fue del agilismo
Reconozco que soy uno de esos radicales que andan por ahí adoptando criterios extremos. No hace mucho yo abogaba públicamente por eliminar los comentarios “inline” porque hacen más daño que beneficio y lógicamente muchos se quedaron con el titular pero no profundizaron en el argumento. Con esto de Scrum o XP “puros” pasa algo parecido y muchos se quedan en las palabras “gruesas” sin prestar (en mi opinión) suficiente atención al contenido. Me explico.
Creo firmemente (y hablo desde el fracaso de intentar hacer agilismo “a medias” varias veces) que si aplicas por primera vez un marco de trabajo cualquiera, digamos XP, digamos Scrum, digamos incluso RUP o lo que sea… es altamente recomendable aplicarlo lo más fielmente posible al libro que sea e intentar respetar al máximo el espíritu del creador, en el caso de los métodos ágiles, el Manifiesto. De lo contrario tienes muchas papeletas para fracasar. Y le echarás las culpas al Manifiesto y a los familiares vivos o fallecidos de UncleBob y sus amigos. Cuando en realidad lo que ha pasado es que has hecho simplificaciones que te venían bien, y apostaría a que han sido relajaciones de las prácticas que más disciplina imponen. ¿A que sí? Pues en ese caso la culpa no es de UncleBob sino tuya.

16 MarVersionado automático con Maven
La parte fácil
Antes que nada, os cuento lo que yo suelo hacer con el código cada vez que termino una iteración.
Supongamos que la versión actual es la 0.0.1-SNAPSHOT.
1) Me recorro todos los pom.xml donde he puesto 0.0.1-SNAPSHOT y le quito el -SNAPSHOT.
2) Hago commit de los pom.xml que he cambiado.
3) Etiqueto esta versión del código en el repositorio (en mi caso Subversion).
4) Vuelvo a recorrer todos los pom.xml para dejar la siguiente versión: 0.0.2-SNAPSHOT.
5) Hago commit de los pom.xml.
Y eso todas las veces…
Pues bien, resulta que hay un plugin de Maven que hace todo eso por mi: maven-release-plugin.
Antes de empezar yo aconsejo también hacer mvn clean install, pero no es obligatorio. Yo es que soy un poco obsesivo con estas cosas.
Para usarlo no puedo tener ningún “commit” pendiente, de lo contrario, el plugin se quejará. Es obligatorio también proporcionar la información de dónde está nuestro repositorio, para ello debemos incluir el apartado “scm” en los pom.xml que lo requieran (según los tengamos organizados):
https://shopaas.googlecode.com/svn/trunk/shopaas scm:svn:http://shopaas.googlecode.com/svn/trunk/shopaas scm:svn:https://shopaas.googlecode.com/svn/trunk/shopaas
El plugin sustituirá en estas cadenas los valores adecuados, por eso es aconsejable revisar cómo quedan estas secciones de los pom.xml las primeras veces.
Lo primero que hay que hacer es:
mvn release:prepare -DdryRun=true
Esta instrucción cubre los pasos 1, 2 y 3. La propiedad “dryRun” nos sirve para decirle al plugin si queremos o no hacer efectivos los cambios, si le damos el valor “true”, el plugin NO hará commit ni tag. También comprueba si hay dependencias con artefactos cuya versión aún es SNAPSHOT, pero esto no lo he probado, la verdad. Además, “release:prepare” ejecuta por defecto los siguientes “goals” sobre el proyecto: “clean verify”. Esto hace que se ejecuten las pruebas.
Cuando lo ejecutemos, por la consola Maven nos preguntará la versión de cada pom.xml (él no quita el “-SNAPSHOT” sino que pone la versión que nosotros le digamos). También nos pregunta cuál es el nombre con el que va a etiquetar esta versión en el repositorio de control de versiones. Y por último nos pregunta cuál es la versión que vamos a tener para trabajar después de este versionado (que suele ser la siguiente con el “-SNAPSHOT”). El plugin nos propone valores por defecto que podemos aceptar pulsando “intro”. Para cada pom.xml, la ejecución con “dryRun=true” nos dejará 3 ficheros: pom.xml.releaseBackup, pom.xml.tag y pom.xml.next, que se corresponden con el que tenemos antes de ejecutar (0.0.1-SNAPSHOT), el que se etiquetará como versión estable (0.0.1) y el que quedará en el “trunk” con la nueva versión de trabajo (0.0.2-SNAPSHOT). Pero el plugin no hará efectivos estos cambios porque le hemos dicho “dryRun=true”.
La parte difícil
Hasta aquí todo iba bien, pero el siguiente paso me dio problemas. Pero primero hay que ejecutar sin “dryRun” para que se hagan efectivos los cambios en SVN.
mvn release:clean release:prepare
release:clean sirve para limpiar los ficheros que haya podido dejar una ejecución anterior. También podemos usar releas:rollback para deshacer los cambios efectuados en SVN.
El primer obstáculo fue al usar el Maven embebido que viene con m2eclipse. Así que tuve que pasar a usar una instalación externa (concretamente la 2.0.9).
El segundo obstáculo fue al ejecutar el comando y encontrarme con el siguiente mensaje de error:
[INFO] Executing: cmd.exe /X /C "svn --non-interactive commit --file C:\Temp\maven-scm-2032301768.commit --targets C:\Temp\maven-scm-5209016095571570993-targets"[INFO] Working directory: C:\eclipseWorkspaces\MiTienda\shopaas[INFO] Tagging release with the label shopaas-0.0.1...[INFO] Executing: cmd.exe /X /C "svn --non-interactive copy --file C:\Temp\maven-scm-328141097.commit . https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1"[INFO] Working directory: C:\eclipseWorkspaces\MiTienda\shopaas[INFO] ------------------------------------------------------------------------[ERROR] BUILD FAILURE[INFO] ------------------------------------------------------------------------[INFO] Unable to tag SCMProvider message:The svn tag command failed.Command output:svn: Commit failed (details follow):svn: File '/svn/tags/shopaas-0.0.1/domain/pom.xml' already exists
El caso es que hay un bug (¡cómo no!) que, para colmo, no parece estar claro si está del lado de Maven o de SVN. Parece que maven-release-plugin hace “svn copy” para crear el tag y que, a partir de la versión 1.5.1 de Subversion esto mismo ha comenzado a fallar. Así que hay que hacer manualmente la siguiente chapu:
# mvn release:prepare=> fails# svn up -r head # mvn release:prepare -Dresume
De esta manera, los ficheros en .svn que han quedado chungos se arreglan con “svn up” y luego se continúa por donde se había quedado (con -Dresume). Con Eclipse consiste en primero hacer “Team / Update” y a continuación ejecutar Maven con el goal “release:prepare” y el Parameter “resume” (al que tenemos que ponerle el valor “true” porque la configuración del launcher que propone m2eclipse no permite añadir un parámetro con nombre pero sin valor).
Llegados a este punto podemos revisar que en nuestro servidor de SVN se han creado tres nuevas revisiones con el siguiente comentario:
* [maven-release-plugin] prepare release shopaas-0.0.1
* [maven-release-plugin] copy for tag shopaas-0.0.1
* [maven-release-plugin] prepare for next development iteration
Los ficheros que son cambiados tras la ejecución (los pom.xml) podemos compararlos con las correspondientes versiones anteriores. En mi ejemplo, el mismo trozo del pom.xml que muestro más arriba queda como:
https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1 scm:svn:http://shopaas.googlecode.com/svn/tags/shopaas-0.0.1 scm:svn:https://shopaas.googlecode.com/svn/tags/shopaas-0.0.1
Y en nuestro espacio de trabajo tenemos que la versión de los diferentes pom.xml ha quedado ahora como 0.0.2-SNAPSHOT, tal y como respondimos en su momento. También nos ha quedado un fichero release.properties con todas las versiones y trayectorias en SVN de los componentes versionados por este plugin.
Queda pendiente
Me queda aún por probar a realizar el despliegue de la nueva versión de manera automatizada. Para ello hay que usar el goal “release:perform”, que según parece ejecuta por defecto los goals “deploy site-deploy” después de obtener dicha versión desde el servidor de control de versiones.
02 MarAgile Spain : Entre bombones y tomates
Dado que el lugar de encuentro (un bar irlandés junto a la Plaza Real) no abría hasta la hora de comer, decidimos que mejor buscábamos otro lugar. Al salir de la Plaza Real nos encontramos con una terraza en la que nos “hicimos fuertes” y allí plantamos nuestro cuartel general. Sólo faltaba Xavier Quesada, que venía de Bélgica y se incorporó un poco más tarde. Desgraciadamente, la climatología no nos acompañó y algunos pasamos frío. Claro, ¡a nadie en Finlandia se le ocurre tomarse un café en la calle!
Xavi Albaladejo actuó como facilitador de la reunión y eso nos permitió ser muy productivos. Él es muy modesto y nos dijo que todo se trata de técnicas que su buen amigo Joao Gama le había enseñado, pero es evidente que no sólo hay que conocer las prácticas sino que también hay que saber cómo y cuándo aplicarlas (y cuándo no). La reunión se inició con una presentación de cada uno de nosotros, a la que Xavi nos pidió que añadiéramos también una breve explicación de quiénes somos y cuál es nuestra relación con el agilismo, además de qué es lo que esperabamos obtener de aquella reunión. Jorge “gadget” Uriarte tiene el momento grabado en video pero creo que problemas legales con la Ley de Protección de Datos le impiden difundirlo públicamente.
A continuación, nuestro facilitador sacó tarjetas con los diferentes temas que habíamos ido anotando en el wiki de la reunión en días anteriores, los completamos y finalmente los votamos. De esta manera pudimos construir nuestro backlog convenientemente priorizado por todos. Dado que algunos no podían quedarse todo el día, decidimos asignar un tiempo limitado a cada tema y medirlo con un “pomodoro” (un reloj de cocina). Quince minutos por tema más un minuto para las conclusiones correspondientes.
No os voy a aburrir con un detallado informe sobre lo que discutimos (de eso ya se encargará otro compañero, Jorge Uriarte), pero sí me gustaría recordar algunas de las cosas que más me gustaron. Sobre todo la buena onda con la que inmediatamente comenzamos a colaborar todos. Se notaba que nos movía una ilusión común y que nos sobraba generosidad (sobre todo a los que eran capaces de venir desde Barcelona, Bilbao, San Sebastián, Bélgica e incluso Finlandia para una reunión con desconocidos y sin objetivos fijos).
Hicimos dos sesiones, una por la mañana y otra por la tarde, después de comer. En la primera sesión tratamos los temas que más votos habían obtenido, es decir, los que más nos preocupaban a todos: organización interna, recursos disponibles y sobre todo “cómo difundir el agilismo”. Durante las diferentes discusiones salieron algunas preocupaciones recurrentes, como la sospecha de que hay mucha gente haciendo Scrum, XP, etc. pero que no sabemos dónde están ni cómo llegar a ellos. O cómo hacer llegar los conceptos a gente que los desconoce pero que estaría dispuesta a “probar la pastilla roja” (permitidme que yo también me apropie un poco de esta idea). Hablamos de llegar a las empresas a través de organismos oficiales y asociaciones profesionales, y de llegar a los estudiantes a través de las universidades. Vamos a trabajar ya el backlog de Agile Spain para empezar a realizar contactos encaminados a la difusión del agilismo y que nos permitan ir conociendo “dónde se esconden los agilistas en España”.
También hablamos sobre la organización del Agile Open Spain. Sería un evento organizado como un OpenSpace y contaríamos con la ayuda de la Agile Alliance y la experiencia de la organización de un evento similar por nuestros “hermanos” Argentinos, pero aún está todo demasiado verde como para que podamos explicar nada más.
Leo Antolí y Juan Gutiérrez no podían quedarse a la comida, así que los despedimos y nos marchamos a comer chipirones, pues Xavier Quesada estaba de antojo. Nuestro magnífico guía por las callejuelas de Madrid fue Jorge “gato” Uriarte pues había vivido hacía tiempo en Madrid y conocía bien la zona. No quisimos entrar en intimidades tratando de averigüar por qué conocía tan, tan bien la zona. Quizás a su esposa no le hiciera gracia.
Jorge nos llevó a un restaurante donde comimos y bebimos bastante bien, pero sin dejar de hacer lo que habíamos ido a hacer. Hablar de agilismo hasta en la comida. Contamos batallitas y compartimos risas, incluso antes del vino. Pero bueno, no todo iba a ser agilismo, también aprendimos los distintos niveles de vegetarianismo, desde el ovolácteo hasta el asceta.
Además de los postres, un surtido de tartas de perder el sentido, Xavier Quesada nos sorprendió con un regalo típico de Bélgica. Dejo a la imaginación del lector adivinar qué fue ese regalo…
Después de la agradable comida nos marchamos buscando un café donde seguir la reunión. Vaya, no sabía que los sábados podía haber tanta gente tapeando por Madrid.
Pero no nos importó demasiado: “inspect and adapt”. Y encontramos un garito en la mismísima puerta de metro de La Latina. Allí nos apalancamos y Ricardo Roldán sacó su portátil para enseñarnos el flamante Drupal 5 con el portal de agile-spain.com completamente migrado. Tenemos varias posibilidades donde alojar el portal, puesto que donde está actualmente resulta incómodo, sobre todo para Jorge Ferrer que, muy amablemente, lo sigue alojando y nos sigue ayudando siempre que puede. Xavi Albaladejo quedó encargado de realizar un diagrama explicando todos los recursos que actualmente maneja Agile Spain (el portal, la lista de correo, el wiki, el grupo del LinkedIn) y algunos otros que, si bien no forman parte de Agile Spain, en sentido estricto, sí que son sinergias que nos interesa mantener, al menos de momento hasta que podamos asumirlas en un futuro portal que de una imagen más homogénea de nuestra comunidad, y que son PlanetaScrum, el Drigg de Agilmática y el Directorio de ScrumManager.
También tratamos sobre la oportunidad o no de unificar todas las iniciativas de creación de comunidades ágiles en español. Es un tema interesante porque de ser posible nos permitiría ganar una “masa crítica” muy importante puesto que somos muchos los seres humanos que compartimos este idioma, sin embargo, hoy por hoy nos pareció un poco difícil de conseguir teniendo en cuenta lo poco maduras que están aún las comunidades ágiles hispanohablantes. Sin embargo, eso no quiere decir que no vayamos a intentar ir consiguiendo sinergias entre nosotros que nos pueden ayudar a crecer a todos. Xavier Quesada, que es un poco argentino, un poco belga y un poco español, va a ser nuestro “enlace” con los ágiles Argentinos y ya veremos qué vamos consiguiendo.
En esta segunda parte de la reunión intentamos usar el “pomodoro” pero, la verdad, no lo respetamos mucho. Y ciertamente creo que se notó porque fuimos un poco menos productivos, en mi opinión. En cualquier caso, el resultado final, para todos nosotros fue bastante satisfactorio, incluso para los que se pegaron el palizón de venir desde tan lejos, como Jorge Uriarte (que vino en coche de Bilbao y se volvía el mismo día), Jose Ramón Díaz (que venía de un periplo multimodal, coche y tren, desde San Sebastián), Xavi Albaladejo (que venía y se volvía en el AVE desde Barcelona), Juan Gutiérrez (que venía desde Finlandia) y Xavier Quesada (que venía desde Bélgica). Aún hay mucho por hacer, pero estoy seguro de que es sólo cuestión de tiempo que el agilismo en España sea “lo normal” en vez de “lo excepcional”.
P.S.
Para los que tengan curiosidad por vernos las caras… visitad las fotos que hizo Xavier “fotógrafo-profesional” Quesada y alguna un poco más cutrecilla que hizo un servidor.
ACTUALIZACIÓN:
Me pide Xavi Albaladejo que corrija un par de detalles:
- Cambiar el enlace de Open Space al artículo que hicimos en castellano en Agile Spain. http://www.agile-spain.com/
agilev2/que-es-como-hacer- open-space - Sobre el texto: “nos dijo que todo se trata de prácticas que vienen en su libro de cabecera (“Collaboration Explained”)”
Creo que se trata de una confusión. El libro lo saqué por la tarde para decir que es el libro de cabecera de un Scrum Master, pero lo cierto es que a quien le debo mucho al respecto es a mi amigo y coach personal Joao Gama, quien me enseñó esta técnica de reunión productiva. Entonces, si este texto debe existir, sería de más “justicia” poner algo así como:
“que utilizó técnicas que su buen amigo Joao Gama le había enseñado”
Bueno, pues queda corregido.

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6993111e-d635-42b5-8b80-7c776b8dbf55)