18 OctUna de Concordion

Con esto del Agile Open Spain 2009 estoy dejando de mano muchas cosas, pero no quiero abandonar el blog, así que aunque sean casi “microblogs” voy a intentar no dejar de escribir.

Dicho esto, voy a aprovechar que para el próximo miércoles en el grupo de Agile Spain en Madrid me he comprometido a hacer una presentación de 5 minutos para defender el tema “Pruebas de Aceptación Automatizadas con Concordion” y voy a dejar un par de apuntes aquí.

En el estupendo blog “Dos Ideas” he visto hace poquísimo un artículo con un par de screencasts en español sobre cómo usar Concordion + Selenium. Muy útil.

Para los que utiliceis .NET y queráis usar Concordion.NET, éste es vuestro blog (en inglés).

Lo siento, no hay tiempo para más. :(

23 SepEl fin del verano


El fin del verano llegó. Ya estamos de vuelta en el cole, se acabaron las vacaciones, la playa, también se acaba el calorcito, las terracitas… Igual que con el principio de año, las listas de propósitos de enmienda proliferan. En mi caso, mi periodo sabático se ha acabado y comienza un periodo diferente: el de salir del desempleo. Para mi particular inicio de curso tenía algunas tareas e incluso asignaturas pendientes. Con vuestro permiso voy a hacer un recuento público del estado de las mismas.

Mi caja de herramientas

Hace algo más de un año me dije que tenía que mejorar mis conocimientos teóricos y prácticos en varios aspectos de la Ingeniería del Software (concretamente SOA y DDD), montarme un ecosistema software (con su control de versiones, su integración continua, su wiki y todo) y añadir a mi caja de herramientas algunos frameworks, herramientas y lenguajes a los que hacía tiempo que les tenía ganas (concretamente Wicket y Spring 2.5, con sus anotaciones y todo, un DVD con herramientas de IBM que sigue en la estantería aún sin abrir, y Ruby y Groovy).

Bueno, SOA salió de la ecuación bastante rápido. Demasiadas cosas y ya se sabe: “el que mucho abarca, poco aprieta”. Aunque pude asistir a una charla que dió Udi Dahan en Madrid gracias a iMeta y que, además de aclararme un montón de dudas, me enseñó cómo hacer “SOA de verdad”, con servicios realmente autónomos. En cuanto a DDD, sigo ahí peleándome con el calendario y mis obligaciones diarias, pero algún día conseguiré tener mi ejemplo “end-to-end” para poder explicar esto de los repositorios, la “ignorancia de la persitencia” y todo eso que cuando lo lees resulta tan elemental pero a la vez tan difícil de traducir en líneas de código. Incluso creé en su momento un googlegroup, pero me temo que no le estoy dedicando tiempo ninguno y pido disculpas por ello.

El ecosistema software está funcionando en mi portátil a pleno rendimiento: Hudson, Subversion, Dokuwiki, Maven, Eclipse. ¿Se me olvida algo? ¡Ah! ¡Sí! Sonar. Aunque éste lo tengo un poco aparcado… Me quedan en el tintero afinar cosas como tener una buena estructura para los builds con Maven y las pruebas de integración y funcionales, probar cómo va eso de Git, probar el Testability Explorer de Misko Hevery (que por cierto tiene un blog sobre testing muy recomendable).

En cuanto a Wicket, he hecho mis pinitos, pero tengo que explotarlo aún más. Desde luego, lo que tengo claro es que antes muerto que JSF. :) Spring 2.5 está más o menos dominado: no era tan complicado. Y mi relación con Ruby-Rails y Groovy-Grails es un poco rara. No termino de creer en ninguno de los dos, pero aun así este verano he estado insistiendo a mi sobrino Nico para que aprendiera, le instalé el Aptana y le ayudé a refactorizar alguno de sus ejemplos de Ruby (el pobre no había llegado al capítulo de las subrutinas y yo dándole caña, ¡es que no tengo corazón!). El día 3 voy al curso que Escuela de Groovy organiza junto a JavaHispano. Este verano he estado jugando (no me atrevo a decir más) con Eclipse y un plugin bastante apañado, pero sigo sin “pillarle el puntillo”. No sé, debe ser que me pilla un poco viejo o que he perdido el gusto por programar…

Para no perder la práctica he estado entrenando un poco, pero claro, nada serio. Quizás lo más interesante fue el ejercicio del libro de Refactoring. Por cierto, me estoy haciendo (a ratos, porque no consigo tener la continuidad ni la serenidad de espíritu necesarios) un codekata que me está resultando bastante interesante.

De todos modos, hay temas que han salido de mi caja de herramientas (por lo menos por una buena temporada) como OSGi o JAX-WS.

Concordion

¡Ay! Mira que tengo ganas de poner lineas de código mías en Concordion. Incluso tengo un “issue” asignado desde hace la tira… pero de veras que no consigo sacar el tiempo necesario para programar. Ni pomodoros ni nada. Eso sí, conseguí mavenizarlo y que las “releases” se publiquen automáticamente en el Repositorio Central de Maven.

Tengo a medias un taller sobre especificaciones ejecutables que quiero armar usando Concordion, pero una vez más… “el que mucho abarca poco aprieta”.

Agile Spain

Realmente éste ha sido y es mi gran caballo de batalla. En principio mi interés consistía en formarme “formalmente” en esto del agilismo. Así que me apunté a un curso de Scrum de dos días que no tenía mala pinta y que no era “fu*ing expensive” como los CSM. Además lo daba un andaluz, como yo. Mala suerte. Me nació el pequeño en medio del curso. Por suerte, Ángel es un tipo muy amable y comprensivo y me dejó repetir el curso (desde el principio, je, je).

El 7 de junio de 2008 creé la lista de correo “heredando” el nombre de una comunidad que había ido languideciendo en los últimos años, pero no hubo nadie más hasta el 21 de julio que se añadió Juan Gutiérrez desde Finlandia. Pasaron algunos meses hasta que Jorge Uriarte y Xavier Quesada propuesieron la refundación y ahora somos 230 en la lista (aunque seguro que hay más gente que la lee y no está suscrito, pero los Googlegroups no dejan poner Google Analytics :( ) e incluso vamos a organizar el primer Agile Open en España, con 150 asistentes y una lista de espera que nos lleva hasta los 233 que hay ahora mismo. Pero es que además, para primavera queremos organizar algo aún más grande, como ensayo para una conferencia a nivel internacional. El día 2 nos han invitado a una reunión en red.es para ver de qué manera podemos colaborar. !A mi se me ocurren muchas ideas! Y también estoy en contacto con Agoranews (los que están haciendo la cobertura audiovisual del SIMO). Ojalá de unos o de otros podamos conseguir que se graben algunas o todas las sesiones del Agile Open, pero queda poco tiempo así que no sé. ¡Pero apretaré para el evento que haremos en primavera!

Buff, pero éste no era mi objetivo cuando empecé con esto de Agile Spain. Yo sólo quería hacer que los que hacían agilismo en España “salieran del armario”, de esa manera, pícaro yo, sabría a quién enviar mi CV. Pero la cosa se ha salido un poco de madre y me han invitado a grabar un par de podcasts (uno para JavaHispano y otro para 32minutos). Pero el colmo ha resultado cuando desde la Tenerife LanParty 2009 me han invitado a dar una charla sobre esto del agilismo. Y encima han quedado muy contentos y todo. Total, que resulta que cuando escribes en Google “agilismo” salgo en casi todos los primeros resultados. Vamos, que casi sin haberlo querido estoy bien posicionado.

Viendo que esto parecía que me abría una oportunidad profesional interesante, decidí explorarla este verano. Para ello he empezado a trabajar en un estudio de mercado sobre “agile coaching” en España. Quiero aprovechar el Agile Open para pasar una encuesta a los asistentes y así poder sacar conclusiones un poco más científicas que simplemente una sensación. Luego dejaré el estudio a dominio público porque para mi ya será suficiente y, quién sabe, quizás ayude a otros a decidirse por un camino similar.

He hablado con varios emprendedores y freelancers (con Ángel, con Abel, con Leo, con Xavi) y todos me dicen que adelante, sin miedo. Pero yo soy un “cagao” y tengo muchas reticencias. ¿De verdad se vive mejor como autónomo? Mi madre, hace muchos, muchos años, era propietaria de una tienda de ultramarinos (que antiguo suena eso) y estaba esclavizada por su trabajo. Por cuenta ajena, al menos tienes un horario (que tienes derecho a respetar). Pero claro, conociéndome, ese argumento suena a “excusa barata”.

Así que, claro, ahora me surge una pregunta: ¿Y ahora qué? ¡Ah! ¡Sí! Pues decidir si preparo el CV y lo subo a Jobsket o, por el contrario, preparo un porfolio de servicios y me hago freelance “porlagloriademimadre”.

13 MaySalvando las distancias

Voy en metro, ilusionado, camino del segundo día del curso de Scrum de Medinilla. Y me he pillado el libro de Gojko Adzic “Bridging the Communication Gap” porque ayer surgió el tema de las especificaciones ejecutables y los roles dentro del equipo. Pero estoy un poco desentrenado porque hace mucho que no voy en metro con tiempo para leer, y el iPod lo tengo vacío de podcasts por escuchar, así que me he puesto la “música aleatoria” y mientras escucho de lo más variado (desde la deliciosa Joy Denalane hasta M-Clan, que no veas cómo me animan) he pensado en tomar notas para cumplir con una “cierta obligación”: explicar lo que me ha parecido el libro.

Gojko Adzic es un tipo que habla en inglés con un acento balcánico realmente difícil de seguir (al menos para mi), así que pensé que era buena idea comprar el libro para entender a qué se refiere cuando habla de talleres de especificaciones y de pruebas de aceptación ejecutables en entornos ágiles. Además, Gojko Adzic también imparte cursos sobre Domain-Driven Design y esa relación entre DDD y pruebas de aceptación es algo que me interesa bastante.

Voy a ser sincero, también compré el libro porque es el primero en el que se habla de Concordion, la herramienta open source en la que modestamente colaboro. Pero son apenas unas páginas y el valor del libro es mucho más que eso.

Adzic explica la importancia de que “la gente del negocio” hable el mismo idioma que “la gente técnica”. Esto muchos lo entienden como obligar a clientes y usuarios a que hablen en términos tecnológicos como “altas, bajas, modificaciones y listados (CRUD en inglés)”, o peor aún, de tablas, campos y relaciones.

En DDD hablamos de un lenguaje ubícuo, o único en todo el proyecto, y que es el que usan tanto técnicos como usuarios. Esto permite reducir los defectos producidos por malentendidos y tiende puentes entre ambos mundos, abriendo la posibilidad a una verdadera colaboración.

Un inciso melancólico. Voy ahora mismo montado (mientras escribo estas notas en mi moleskine) en el metro ligero y me he acordado de ese par de meses intensos que viví y trabajé (sobre todo lo primero) en Melbourne (Australia). Allí fui usuario del “tram” y he de decir que me parece un medio de transporte público de lo más interesante porque es a la vez rápido, cómodo y silencioso.

Pero sigamos con el libro. El grueso del mismo se basa en hablar del “agile acceptance testing” y de cómo buscamos ponernos de acuerdo en qué es lo que hay y lo que no hay que desarrollar. Para esto usamos ejemplos realistas en vez de requisitos abstractos. “Los ejemplos demuestran cómo debería actuar el sistema y cómo debería ayudar a los usuarios a hacer su trabajo”. Adzic propone que estos ejemplos sean creados por todo el equipo de implementación, no sólo por un “experto del dominio” (también conocido como “analista de negocio”) como en modelos de desarrollo más tradicionales. “Usamos los ejemplos para discutir el dominio y asegurarnos de que no hay malentendidos”.

Según Adzic, el uso de ejemplos realistas obliga a pensar más acerca de los problemas. De hecho, comenta cómo se producen muchas discusiones entre los expertos cuando se plantean ejemplos para casos extremos; discusiones que incluso les hacen a veces revisar sus propios procesos de negocio. ¡Vaya! Si resulta que podemos ayudar a nuestros clientes en vez de simplemente observar su comportamiento “desde fuera”, como si fueramos “supernanis con corbata”.

Damned! ¡Me he saltado una parada! Estaba tan concentrado… Menos mal que la frecuencia del metro ligero éste es alta y he podido llegar sólo un par de minutos tarde. Buff…

De vuelta del estupendo curso de Ángel Medinilla, sigo con el resumen del libro y me fijo en que no he explicado esto de los ejemplos. Vamos, que no he puesto ejemplos de ejemplos. :-) Adzic pone un ejemplo en la página 45 de una regla de negocio relacionada con el descuento que le podemos ofrecer a un cliente, pero a mi me gusta más el que explica David Peterson en la web de Concordion. Es bastante más completo porque nos lleva desde la historia de usuario (el requisito) hasta la prueba de aceptación automatizada (en forma de ejemplos). Es interesante cómo David hace mucho hincapié siempre en que debemos especificar con ejemplos que expliquen comportamientos muy elementales y dejar para otras especificaciones todo aquello que quedaría fuera. Son los “Further details” en el ejemplo. También Adzic habla de esto en su libro, pero menos; y yo creo que es importante esta anotación al margen para aquellos que queráis “tomar este camino” para hacer pruebas de aceptación.

En “Bridging the communication gap” también se explica cómo conducir estas reuniones (talleres de especificación) e incluso aconseja sobre algunas herramientas. Pero creo que es interesante explicar cómo pueden encajar estos talleres en nuestro calendario semanal (ágil).

Adzic sugiere lo siguiente:

Release es todo aquello que hacemos después de la demo para dejar bien cerrado el sprint. Etiquetamos en subversion, hacemos copias de seguridad, ponemos las versiones del nuevo sprint en los pom.xml (si usamos Maven y si es que tenemos que cambiar de versión), limpiamos las pizarras… y mientras esto lo pueden ir haciendo algunos desarrolladores (típicamente los becarios, je, je) pues el resto puede estar preparando el sprint primero revisando el backlog y luego, ya con los becarios incorporados, estimando las historias y decidiendo lo que se podrá hacer razonablemente en el sprint (las próximas dos semanas).

Ojo, es una manera de organizar el trabajo durante un sprint, pero lo importante de esto es que el dueño del producto (también conocido como jefe de proyecto, analista de negocio, o incluso tester, según vuestro “mapeo” preferido) se encarga de trabajar las historias de usuario (redacción y priorización) y de los ejemplos (criterios de aceptación) antes de los talleres de especificación, pero realmente es el equipo en su totalidad quien acuerda lo esencial de los criterios de aceptación mediante la discusión que se ofrece en esta reunión. Para los que ya estéis algo picados con esto del agilismo, me permito recordar “las tres Ces” (card, conversation, confirmation). Éste es el momento ideal para la conversación, aunque ya se haya tenido una conversación previa cuando se han estimado las historias de usuario en el Sprint Planning Meeting (usando terminología Scrum).

Bueno, y hasta aquí hemos llegado. Espero que os resulte útil. Y si alguien más se ha leido este libro y quiere contrastar aquí su opinión, estaré encantado de poder charlar con vosotros porque mi intención es preparar una presentación (o un taller, ya veré) sobre este tema y exponerla bajo el “paraguas” de Agile Spain.

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

Ya está disponible la versión 1.3.1-RC5 de Concordion. Podéis usarlo con Maven (de momento, hasta que se publique en el Repositorio Central de Maven) declarando el repositorio remoto del proyecto:

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

Acabo de terminar de solicitar la publicación en el Repositorio Central de Maven de la versión 1.3.1-RC5 de Concordion. Hasta aquí nada novedoso, pero resulta que nuestro código está alojado en Google Code y no es tan fácil automatizar todo este proceso.

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.

25 FebConcordion: un ejemplo

Hace ya varios meses que estoy involucrado en el proyecto Concordion, un framework para construir y ejecutar pruebas de aceptación. Desde entonces hasta ahora el código base no ha cambiado significativamente, pero hasta ahora seguíamos sin tener un ejemplo de uso con el código fuente incluido más completo que el HolaMundo del proyecto concordion-samples. En el artículo de hoy voy a pagar esta deuda.

Concordion

Las principales características de Concordion son:

  • Las especificaciones se escriben en XHTML
  • libertad absoluta de formato, que favorece escribir las especificaciones orientadas a comprobar los comportamientos en vez de orientadas a “scripts”
  • no es necesario conocimiento técnico para poder escribir las especificaciones

  • Las especificaciones se instrumentan para ejecutar código Java sin restricciones, puesto que las fixtures son clases Java que heredan de una extensión de TestCase de JUnit (o anotada con @ConcordionRunner) y que se vinculan con las especificaciones por convenio (se llama igual que la especificación pero con el sufijo Test)
  • No hay ficheros de configuración
  • Está disponible en el Repositorio Central de Maven
  • groupId
    org.concordion

    artifactId
    concordion

    version
    1.3.0

  • Se ejecuta como cualquier test JUnit
    • el resultado de la ejecución son los mismos XHTML pero iluminando los textos instrumentados con verde si se cumple la condición, rojo si no se cumple o amarillo si se ha producido una excepción
    • también hay un plugin Maven que produce un resumen del resultado de la ejecución que recorre todos los XHTML resultantes y que mejora el que produce el plugin Surefire para los JUnit

    Proyecto de ejemplo

    He creado un proyecto en GoogleCode para, entre otras cosas, ir realizando todas estas pruebas. Anteriormente había escrito un artículo donde se trataba de ilustrar el uso de Spring y de JPA juntos. Ahora he incorporado un ejemplo que ilustra cómo pasar de una historia de usuario sobre el Mantenimiento de un Catálogo de Productos para una tienda. Esto es un poco CRUD, pero poco a poco iremos viendo cómo incluso en ese escenario podemos orientarnos al comportamiento.

    ¿Cómo descargar y probar este ejemplo?

    Para descargar este proyecto podéis seguir las instrucciones:

    svn co http://shopaas.googlecode.com/svn/trunk/shopaas shopaas

    Podéis revisar los siguientes detalles por si queréis cambiarlos.
    En shopaas/pom.xml

    …y a continuación podéis construirlo usando Maven. Para ello, ejecutad:

    cd shopaasmvn clean install cobertura:cobertura site

    Si todo ha ido bien, podréis comprobar que se ha generado un “site” del proyecto en la carpeta target/site.

    Desgraciadamente no he conseguido aún que queden correctamente enlazados los módulos, por lo que es necesario ir hasta la carpeta shopaas/services-acceptance-test/target/site y abrir el fichero index.html con nuestro navegador favorito para poder ver el resultado de las pruebas de aceptación (incluso el informe de cobertura de las mismas).

    Si ejecutáis la construcción del proyecto desde la linea de comandos, es posible también que tengáis un problema de falta de memoria (Error “Java Heap Space”), para evitarlo tendréis que ejecutar antes que nada “set MAVEN_OPTS=-Xmx128m”. A mi me ha dado este problema cuando lo he probado en Windows XP con un JDK 1.6.0_11, y sospecho que tiene que ver con los valores por defecto que elige la JVM en este entorno. Pero tampoco lo tengo 100% seguro.

    maven-concordion-plugin

    No sé si para el momento en el que probéis esto ya estará publicado en el Repositorio Central de Maven el plugin que permite obtener informes resumidos de Concordion. Si no fuera así, también deberéis descargar el código del maven-concordion-plugin y construirlo con mvn install.

    Cobertura

    El informe de cobertura del código (“code coverage”) ha sido algo que me ha costado especialmente puesto que el código a instrumentar no está en el mismo módulo que las pruebas, de modo que he usado una combinación de los plugins maven-antrun-plugin y build-helper-maven-plugin. Como podréis comprobar, así podemos conocer con bastante certeza si hay código que llevamos a producción para el que no tenemos ninguna prueba. Mmmm, sí que es interesante, ¿verdad?

    Automatización

    Pero lo más interesante es que está completamente automatizado. También están las pruebas de aceptación de la UI que os mostré en un artículo anterior. Por tanto, tenemos pruebas unitarias de los componentes internos, pruebas de aceptación de los servicios de aplicación (escritas en lenguaje de negocio) y pruebas de aceptación de la UI (independientes de la implementación de los servicios de aplicación, o no, esa es nuestra decisión). Con lo que sólo nos queda, en cada “release”, darnos un paseo por la aplicación por aquellos puntos críticos o para los que el coste de hacer una prueba automática sea excesivo. Pero el resultado neto es que hemos ganado en confianza y reducido el tiempo que tardamos en entregar un proyecto. En estos tiempos de crisis, eso es importante, ¿verdad?

    Recursos

    También hay disponible un tutorial de Concordion. Además, a continuación incluyo una lista de enlaces de interés:

    Feedback (o reacciones)

    Por favor, espero que me hagáis llegar vuestros comentarios cuando probéis esto. Me ayudarán mucho a mejorar este ejemplo. No tengo claro cómo organizar el código para que Maven me construya todo como es debido y eso le resta claridad al resultado final, que debería ser que el “Product Owner” o los “expertos del dominio” pudieran navegar hasta el resultado de las pruebas de aceptación y discutir tanto sobre su definición como sobre el resultado de la ejecución.

    También hay dos conjuntos de código diferentes: users y products. El primero corresponde a aquel ejemplo que hice hace ya unos meses y el segundo es el que he estado trabajando últimamente y que pretendo que me sirva como piedra de toque para ir encontrando patrones o plantillas.

    26 DecEditor para Concordion

    Papá Noel me ha traído esta Nochebuena un plugin Eclipse para facilitar el trabajo con Concordion. Si abro una especificación (un fichero html) con el editor Concordion, se abre una ventana de edición con dos pestañas: una con la especificación y otra con la fixture (el fichero java asociado). De la misma manera, si abro la fixture (un fichero java) con este editor, se abre una ventana de edición con las mismas dos pestañas y los mismos contenidos. Las fixtures se editan con el editor Java estándar y las especificaciones html con el editor web, que a su vez tiene dos pestañas: una con la vista de diseño y otra con la de previsualización. Además, la vista de diseño web está dividida y muestra arriba la página web para editar en formato WYSIWYG y abajo en puro HTML.

    He basado el desarrollo en el ejemplo de editor multipágina que viene con Eclipse y en el WicketBench, un editor para Wicket que hace muchas más cosas y del que he tomado prestadas algunas ideas también para el futuro. Sin embargo, aún tengo que trabajar mucho este plugin porque es la primera vez que hago algo útil con Eclipse RCP y tengo mucho que aprender. De momento, los siguientes pasos serán:

    1. hacer pruebas unitarias (para poder refactorizar)
    2. refactorizar (es mejor no mirar al código ahora mismo)
    3. crear automáticamente el desplegable en forma de site (ahora es un jar que construyo manualmente)

    Podéis descargar el jar y simplemente dejarlo en la carpeta “plugins” de vuestra instalación de Eclipse.

    Felices Fiestas a todos, por cierto.

    12 JunConcordion en Español

    Ya está disponible una traducción en español del tutorial de Concordion. Yo he puesto el castellano y David ha puesto las fotos.
    Espero que esto ayude a que este magnífico framework se popularice entre la comunidad hispanohablante, que somos muchos.

    09 JunDegesys apuesta por Concordion

    En la empresa para la que trabajo hemos comenzado a usar Concordion para las pruebas de aceptación. Lo cierto es que la sencillez de implementación de Concordion, la fácil integración dentro del proceso de desarrollo (especialmente gracias a la mavenización) y las sugerencias de David Peterson (el creador) han hecho que rápidamente haya sido asumido por la mayoría como una opción mucho mejor que Fit.