xml-utils.com

Presentación realizada en IPSA durante mi DeskSurfing:

Último día en IPSA, esta vez junto a @AlfredoCasado.

El objetivo de hoy era dar un repaso a todos los temas pendientes y acabar de completar así los aspectos que tenía pensados tratar en mi estancia. Esto ha hecho que hayamos podido reparasar aspectos bastante interesantes como:

• Testing de la capa REST
• Proceso de release con maven y de creación de distribuciones de producto con maven assembly.
• El uso del fichero META-INF/services para la carga dinámica de módulos.
• Creación de nuevos arquetipos para Maven.

En definitiva, una mañana muy interesante!!

Como mi tren salía hoy a las 17:00, hemos aprovechado la comida para despedirnos y tomar unas cañas con el equipo completo.

Gran equipo humano el de IPSA, que me ha hecho sentir como en casa durante toda la semana y han sido unos anfitriones excelentes

Hasta aquí mi DeskSurfing … ¿Cuando empiezas el tuyo?

Tras la vuelta de nuevo al panel para ver el estado de las tareas, hoy he comenzado preparando unas slides para la presentación que tenía que realizar a las 12:00 sobre “Infrastructura y servicios de firma digital”.

La verdad es que ha sido genial ver como ha venido un montón de gente de la empresa, y no sólo la gente del propio grupo de desarrollo. La sesión ha servido para dar un repaso al funcionamiento de una autoridad certificadora, algunos de los servicios que ofrece (OCSP/TSA) y el uso aplicado de los procesos de firma digital tanto en herramientas existentes como OpenOffice o Acrobat Reader, como su implementación en aplicaciones web con CryptoApplet.

Sinceramente, lo he pasado genial, ya que estas cosas me encantan

Tras la presentación, me he unido a @jjballano para comenzar una nueva tarea que tenía asignada y poder ver así un poco más en detalle el entramado de tests de la aplicación.

Hemos ido avanzando, pero la segunda parte ha quedado pendiente para el día siguiente.

Al final de la jornada, hemos decidido hacer una visita al Betabeers, donde parecía que podríamos encontrar una interesante conversación sobre Desarrollo móvil y JavaScript, acompañada de unas presentaciones de nuevos proyectos.

Al final nos hemos quedado poco rato, pero eso sí, hemos tenido una conversación muy intersante sobre JavaScript con uno de los valores en alza de estas semanas @pasku1.

Segundo día en IPSA: Testing day.

El día de hoy ha comenzado con la habitual reunión diaria frente al panel para ver en qué tareas comenzaba a trabajar el equipo. Después del reparto, me he unido a @AlfredoCasado para comenzar una de las historias de usuario que prometía dar guerra.

Aunque era una historia de usuario bastante delicada al afectar partes centrales del producto, es un lujo ver cuando una buena base de tests hacen que todo el trabajo se limite a ir haciendo pequeños ajustes, arreglar tests y finalmente poder añadir la nueva funcionalidad teniendo todo el sistema de nuevo operativo.

Durante la implementación de esta historia de usuario he podido ahondar un poco más en conceptos como los Rules de jUnit, el uso de builders para la inicialización de los datos o las mejoras de expresividada en los asserts con assertThat y Harmcrest.

No ha faltado la visión divertida, a la vez que instructiva de @AlfredoCasado en muchos aspectos del desarrollo, sobretodo en las comparaciones de Google Guice/Spring, JDBC/JPA y otras muchas

Al final ha sido un día muy productivo y casi casi hemos completado la historia asignada, con lo que mañana toca afinar unos pequeños detalles y listo.

Adicionalmente, hemos decidido hacer mañana una pequeña presentación a todo el equipo sobre temas de firma. Así que durante una hora intentaré darles una visión sobre los distintos enfoques que se pueden seguir, formatos existentes y herramientas disponibles como CryptoApplet. Espero que sirva para dar a la gente de IPSA una buena impresión de lo que es un DeskSurfing …

Eso es todo por hoy. Mañana más …

Desde hace algún tiempo, estaba cuestionándome la forma en que mis DAO realizaban las consultas a base de datos haciendo uso de mis entidades JPA (clases con anotaciones @Entity).

Inicialmente, opté por escribir las consultas en texto utilizando el lenguaje JPQL (Java Persistence Query Language). Esta me pareció una primera aproximación bastante sencilla, legible y rápida de realizar las consultas.

Como uso Spring Framework en mis desarrollos y suelo apoyarme en el JpaTemplate, mis consultas quedaban de la siguiente forma:

List listaEmpleados = jpaTemplate.find("from Empleado e where e.id = " + empleadoId);

Los problemas de utilizar esta sintaxis, aparecen rápidamente. El primero puede ser la seguridad, ya que me pueden inyectar código SQL y modificar el comportamiento de mis consultas.

Al margen de estas consideraciones, está el problema de que cuando comienzo a concatenar criterios, construir la cadena final que exprese la consulta a ejecutar se vuelve un proceso bastante complicado y muy propenso a errores.

Existen algunas maneras de evitar concatenar los valores de los filtros utilizando por ejemplo la clase MessageFormat de Java:

MessageFormat.format("from Empleado e where e.id = {0}", empleadoId);

O también la posibilidad de realizar las llamadas mediante “named params”:

Map params = new HashMap();
params.put("empleadoId", empleadoId);
jpaTemplate.findByNamedParams("from Empleado where e.id = :empleadoId", params);

Estas construcciones previenen la inyección de código SQL, pero seguimos teniendo el problema de que cualquier fallo que tengamos al codificar las consultas SQL, no se verá hasta que ejecutemos la consulta.

Está claro que deberíamos implementar tests que garanticen el correcto funcionamiento de nuestra capa de persistencia, pero sería deseable que este tipo de errores de codificación se pudieran detectar de forma más temprana.

Una de las soluciones al respecto es utilizar la Criteria API que tenemos disponible en JPA 2. Con esta API podemos construir las consultas de forma programática y evitar errores.

Básicamente, el uso de la Criteria API tiene el problema de que es un poco enrevesada de utilizar, de forma que las consultas producidas quedan muy poco legibles.

Ejemplo de consulta con la Criteria API:

CriteriaQuery query = builder.createQuery();
Root men = query.from(Person.class);
Root women = query.from(Person.class);
Predicate menRestriction = builder.and(
builder.equal(men.get(Person_.gender), Gender.MALE),
builder.equal(men.get(Person_.relationshipStatus),
RelationshipStatus.SINGLE));
Predicate womenRestriction = builder.and(
builder.equal( women.get(Person_.gender), Gender.FEMALE),
builder.equal( women.get(Person_.relationshipStatus),
RelationshipStatus.SINGLE));
query.where(builder.and(menRestriction, womenRestriction));


Como posible solución a estos escenarios, aparece QueryDSL. QueryDSL nos ofrece una sintaxis mucho más flexible y natural, siendo necesaria la generación de una serie de clases a partir de nuestras entidades JPA mediante el uso de APT (Annotation Processing Tool).

Esta generación es posible realizarla de forma automática mediante Ant o Maven.

En defintiva, que QueryDSL procesará todas las clases que tengamos con anotaciones del tipo @Entity, y producirá un nuevo conjunto de clases que permitirán construir consultas de una manera muy simple y semántica.

Con QueryDSL, la consulta anterior quedaría como:

JPAQuery query = new JPAQuery(em);
QPerson men = new QPerson("men");
QPerson women = new QPerson("women");
query.from(men, women).where(
men.gender.eq(Gender.MALE),
men.relationshipStatus.eq(RelationshipStatsu.SINGLE),
women.gender.eq(Gender.FEMALE),
women.relationshipStatsu.eq(RelationshipStatus.SINGLE));


Desde el pasado septiembre de 2010, nos planeamos un reto en la Universitat Jaume I de Castellón: Comenzar la transformación dentro de una administración pública, de un equipo de desarrollo clásico a un equipo ágil.

El objetivo es bien sencillo a la par que complicado de conseguir. Se trata de comenzar desde cero, cuestionarse la forma de trabajo de los últimos años y ver como mejorarla con el fin de profesionalizar el desarrollo dentro de un ámbito en el que, hasta hace muy poco, parecía impensable una transformación de este tipo.

Algunos estereotipos no han jugado precisamente a nuestro favor. La idea de funcionarios formando parte de un equipo ágil gestionado con Scrum y produciendo software de calidad parece una utopía para muchos, pero con el esfuerzo de un conjunto de profesionales con nuevas metas y motivaciones, todo parece posible.

De esta forma, con mucha ilusión y con la motivación de poder ser partícipes de un cambio organizativo, tecnológico y de mejora en la calidad de los productos elaborados, comenzó la andadura de la UJI en el mundo ágil.

Antes de empezar, no faltó la gran pregunta que dirigiría las primeras acciones planteadas. ¿Cómo se puede hacer esto en una administración pública?

En esta entrada voy a intentar responderla con el fin de compartir nuestra experiencia y nuestras inquietudes

El cambio que plateamos presenta nuevos retos a nuestros desarrolladores, así que la primera acción sería replantearnos el plan de formación del 2010/2011. Este nuevo plan de formación debería de dar soporte tanto al cambio metodológico como al puramente técnico, así que nuestra primera apuesta fue encaminada a aprender cómo las metodologías ágiles podían guiar nuestros pasos.

Con el primer curso de formación en Scrum, nuestro equipo aprendió nuevas técnicas para dar la mayor relevacia posible al usuario, a planificar los ciclos de desarrollo y a estimar el trabajo a realizar. Una nueva forma de trabajar. Una forma de trabajar más adaptada a las necesidades del negocio. Una forma de trabajar centrada en obtener entregas de calidad, en tiempos menores y que realmente puedan satisfacer las necesidades de nuestros clientes.

En este punto nos podríamos plantear ¿Porque elegir trabajar con metodologías ágiles? Pues por muchos motivos …

• - Contamos con un equipo de desarrollo de un tamaño medio y que trabaja en múltiples proyectos de forma simultánea
• - Nuestro cliente está muy cercano a nosotros (tanto que forma parte de nuestra organización: servicios de la propia universidad, departamentos, profesores o los propios alumnos).
• - Los requisitos son cambiantes: Nuevas leyes, nuevos requisitos impuestos por el ministerio, etc.
• - Nuestro cliente demanda software que funciona muy adaptado y personalizado a sus necesidades y cuyas funcionalidades básicas estén disponibles en el menor tiempo posible (entregas rápidas y frecuentes).

En definitiva, un modelo productivo ágil parece que puede ayudarnos a cumplir con estos objetivos y a poder trabajar como un équipo más cohesionado. ¿Será así?

Para intentar responder a esta pregunta, el primer paso fue la creación de un pequeño grupo de personas que, robando unas horas al dia a dia, dedicarían parte de su esfuerzo diario a un proyecto piloto que permitiera completar un demostrativo basado en la tecnología elegida. Y es que nuestro cambio, también pasa por la adaptación tecnológica y la revisión tanto de nuestro entorno de desarrollo, como de los lenguajes y tecnologías a emplear.

El problema inicial es el gran número de interrogantes planteados … ¿Qué lenguaje empleo como base de mis nuevos desarrollos? ¿Qué arquitectura planteo para mis aplicaciones? ¿Cómo diseño mi entorno para poder adaptarse al desarrollo ágil de software y a mis nuevos requisitos organizativos y de calidad?

Para intentar contestarlos todos, no hay que perder de vista el conjunto de la organización y a donde queremos ir. El planteamiento a largo plazo siempre ha sido la elaboración de software que pudiera convertirse en software libre y ser adoptado por otras universidades, así que necesitamos generar productos que sean facilmente integrables en los entornos más habituales. Este punto, junto a la existencia previa en nuestra organización de servicios y APIs que hacen uso de Java (como el proyecto CryptoApplet), provocó la elección de este lenguaje como base para los desarrollos internos.

Otro punto importante es la interoperabilidad de nuestras aplicaciones y de los formatos que manejan. Esto se ve plasmado, en numerosas ocasiones, en la necesidad de exponer ciertas funcionalidades como servicios a otras aplicaciones desarrolladas por terceras partes (sistemas, departamentos, proyectos, terceros, etc). En definitiva, se trata de conseguir “volcar” todo nuestro conocimiento del negocio en un stack de servicios que permitan su explotación y que acaben constituyendo un API universitario. En este punto, las tecnologías REST emergieron como una solución perfecta para nuestras necesidades.

Con un API de estas características, el desarrollo de los interfaces de cliente pasa a ser un proceso que puede desarrollarse en paralelo de una forma desacoplada. Inicialmente se están desarrollando todos los interfaces gráficos con tecnologías de cliente rico a través de web utilizando ExtJS, pero igual de fácil puede ser el desarrollo de una aplicación con cualquier otra tecnología que acceda al API diseñado: Android, Flex, Swing, WPF, etc. Lo importante es que el API REST exponga de una forma controlada y encapsulada, el acceso a los servicios de gestión de nuestro ERP universitario.

Por último sólo queda la revisión del entorno de desarrollo, otorgando importancia por igual tanto a la parte de gestión de historias de usuario, tareas, bugs, revisiones de código, etc (gestionado todo con JIRA Studio), como a la inherente al propio desarrollo compuesta por el repositorio de código (Subversion), el servidor de integración contínua (Hudson), el de gestión de artefactos (Maven + Nexus) o el de análisis estático del código (Sonar).

Con todas las líneas tecnológicas definidas y un par de cursos de apoyo de Java y de REST con Jersey, comenzamos el desarrollo del proyecto piloto, y por supuesto, del primer sprint

A partir de ese momento, la proridad del equipo de desarrollo del piloto se centra en completar las historias de usuario planificadas para el primer sprint y en diseminar el conocimiento adquirido al resto de desarrolladores que no participan de forma diaria en el proyecto. Para esto, se crean los viernes de “difusión de la palabra”. En estas sesiones de los viernes, el equipo piloto es el encargado de contar al resto de desarrolladores qué han aprendido esa semana y sentarse por parejas con el resto de desarrolladores para intentar aplicarlo de forma colaborativa a la base de código existente.

De esta forma y en definitiva, si juntamos un equipo con ganas y motivación de afrontar un cambio, una metodología ágil como Scrum y una nueva plataforma tecnológica adaptada a los objetivos que se desean alcanzar, puede ser posible el más dificil todavia … Que el equipo de desarrollo de una universidad o, en general de cualquier administración pública, pueda recorrer el camino hacia la profesionalización de la mano del desarrollo ágil. Aunque mucho mucho queda por recorrer