Se acabó una etapa

Bueno, ayer me dieron una noticia muy triste: ya no soy empleado de DEGESYS nunca más.

Me voy a permitir darles un mensaje desde aquí a mis ya ex-compañeros (y ex-compañeras, claro):

Han sido casi dos años de aventura compartida en la que, con muchos altibajos (especialmente por mi parte), estábamos construyendo algo realmente grande. La apuesta de Carlos y el resto del equipo directivo es muy difícil (casi una locura) y necesitan de vuestra ayuda. Eso no quiere decir que les déis una carta en blanco, sino todo lo contrario. La confianza se gana (por las dos partes), pero al final, alguien tiene que hacer que las cosas sean posibles. Y esos sois vosotros.

Por favor, no os veáis como simples trabajadores porque en DEGESYS tenéis las condiciones para ser algo más: podéis ser copartícipes de una aventura extraordinaria. Dentro de unos años, cuando hayáis conseguido el sueño de construir DEGESYS, entonces miraréis atrás y veréis lo que sois ahora y lo que seréis entonces. Y podréis estar orgullosos.

He estado en varias "start-ups", y aunque en todas siempre se me ha quedado un poquito de mi, os puedo asegurar que ésta es la que me dá más pena dejar, con diferencia. ¿En cuántas empresas que empiezan habéis podido ver una inversión tan grande y tanta paciencia hasta obtener ingresos? ¿En cuántas empresas habéis estado que tengan un Departamento de Desarrollo y donde el Proceso de Desarrollo sea tan importante como para DEGESYS? Preguntad por ahí y veréis que REALMENTE merece mucho la pena luchar por lo que podéis conseguir.

Por último, y aunque suene pedante (ya qué más dá), un único recordatorio: "la excelencia no es garantía de éxito, pero si buscáis la excelencia estaréis más cerca del éxito".

Ánimo y muchísima suerte.

Bueno, son cosas que pasan y ahora lo que toca es mirar hacia adelante y preparar un plan.

DDD in Practice

Hace ya varios meses que me estoy leyendo el libro de Eric Evans titulado "Domain Driven Design". Su lectura está siendo muy reveladora porque, por ejemplo, me ha terminado de convencer de la necesidad de evitar los modelos anémicos frente a los modelos ricos. Pero hoy me he leido un artículo publicado en InfoQ sobre DDD que me "he bebido casi inmediatamente" y que ha resultado incluso más clarificador que el libro de Evans (que prometo terminar de leer, por supuesto).

El artículo de Srini Penchikala es denso: no es el típico articulito (como éste que estáis leyendo ahora mismo) que comenta de pasada, sin profundizar, uno o dos artículos más o menos conocidos, sino que aporta una estructura en el discurso y contenidos que aclaran mucho las ideas.

El autor explica qué aporta DDD en cada momento del desarrollo de una aplicación y cómo lo hace. Explica la sinergia entre DDD y SOA y llega incluso a hablar de cómo debe ser el framework en el que basemos nuestro desarrollo: POJOs, DI y AOP y, por supuesto, para todo debemos poder hacer pruebas unitarias lo más fácilmente posible.

Me gustaría destacar el comentario que hace sobre el uso de anotaciones y, en particular, la propuesta de uso de las anotaciones @Configurable, @Repository o @Service que ofrece Spring y que ya estoy tardando en probar.


Quiero sacar tiempo de donde sea para poder probar la aplicación de ejemplo. Tengo muchas ganas de ver cómo ha resuelto:
a) la separación finísima que suele existir entre capa de presentación y de aplicación
b) las distinción entre validaciones y reglas de negocio.
c) la separación a veces difícil de explicar (y justificar su existencia) entre objeto del dominio, "repositorio" y DAO

Creo que ahí es donde solemos fallar todos al implementar cualquier arquitectura, por bien definida que esté ésta en "la pizarra". Bueno, yo más porque me temo que en mi proyecto actual tengo todos y cada uno de los "tufillos" ("smells") que indica Penchikala que deberían ser evitados.

Me ha dejado absolutamente intrigado la referencia que hace sobre ROO (Real Object Oriented), que por lo que he podido encontrar haciendo "googling" ha sido que es un "toolset" que están preparando desde hace años los de SpringSource, pero del que aún no se ha liberado nada. De todos modos, quizás no sea mala idea echar de una vez por todas un vistazo a Grails, visto lo productivo que puede ser si se usa con la orientación adecuada.

Me ha gustado también mucho cuando enfatiza el uso de generadores de código porque coincido plenamente en la necesidad de identificar qué pasos del desarrollo se pueden automatizar y usar frameworks para ello. Éste es mi objetivo desde hace años, aunque todavía no he conseguido encontrar la combinación adecuada; quizás porque siempre termino cayendo en la trampa de los "dominios anémicos" y las "capas de servicio hinchadas" ("fat service layer") con la vana esperanza de ahorrarme lineas de código.

Y por último, me apunto la idea de usar BNLs para especificar reglas de negocio o comportamientos de los sistemas (vamos, para hacer BDD o ATDD). Ahí, la sinergia con herramientas como Concordion resulta evidente...

Bueno, lo dicho, a ver si consigo sacar una tarde o dos para ver con detalle el código de la aplicación de ejemplo y saco alguna conclusión más. De momento, "en la pizarra" todo es muy, muy prometedor.

Concordion 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.

Degesys 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.

¿Qué es ser ágil?

En el contexto del desarrollo de software, tengo la extraña sensación de que demasiado frecuentemente se está aplicando el término ágil a lo que no es y eso está haciendo que comience a perder su significado.

Un proyecto ágil no es aquel que no documenta, ni planifica lo que se le va a construir, ni el que se despreocupa de la calidad porque lo importante es entregar cuanto antes. ¡¡TODO LO CONTRARIO!! Sólo se documenta lo que aporta valor (al cliente o al equipo de desarrollo), sólo se planifica aquello que es relevante en función de los requisitos definidos en cada momento y nunca se sacrifica la calidad sino que se negocian diferentes niveles de completitud en los requisitos.

Tampoco consiste en aplicar procesos mecánicos carentes de contenido o disparar con pruebas unitarias a toda clase que se mueva, sino que se implementan mecanismos de colaboración, construcción o comunicación siempre con el objetivo de mejorar en estos aspectos, no en los procesos en sí.

Un proyecto ágil alcanza una mejor calidad en el resultado final porque sus miembros trabajan continuamente para ello y no porque tiene procesos que lo garantizen.

Creo que lo más aclaratorio es leer el Manifiesto del Agilismo (en español o el original en inglés) o incluso mejor, los principios en los que se basa.

Estoy 100% de acuerdo con David Peterson en que aquellos que hemos descubierto mejores formas de desarrollar software tenemos una cierta obligación para con los demás y debemos ayudar a los demás a encontrar este camino. Cuidado, no digo con esto que los que "creemos" debamos dedicarnos a "convertir" a todo "no-creyente" que se cruce en nuestro camino, pero sí que debemos evitar el tirar la toalla y debemos ser firmes y apoyar especialmente a los cuadros directivos para que consigan encontrar "el camino hacia la luz".

P.S.
Perdón por la poesía barata... :-)