Ya en frio y dos semanas después de la presentación de los ganadores, he decidido ordenar mis pensamientos sobre el iWeekend universitario que se realizó en la Universitat Jaume I y compartir mis impresiones.

Antes de empezar, me gustaría explicar en que consiste un iWeekend de boca de los propios organizadores:

iWeekend es una experiencia intensa e innovadora que reúne a emprendedores y profesionales con talento de diferentes perfiles para votar ideas y llevarlas a la realidad, mediante el desarrollo de un business plan y un prototipo. Todo ello de manera colaborativa y en un fin de semana.

Distribución de los equipos

Ante todo, comentar que estuve en el evento echando una mano a la parte técnica como mentor, pero mi intención inicial era poder mezclarme un poco más con otros colectivos y así aprender un poco en áreas desconocidas para mi como el marketing o los negocios.

En este sentido, no tuve mucho éxito, ya que la distribución de los equipos no lo permitió. Compartiendo impresiones con más gente que asistió al que se organizó el mismo fin de semana en Valencia, la conclusión fue unánime: ¿Porqué los grupos de marketing, negocio y técnico que están colaborando en un mismo proyecto no están trabajando físicamente juntos?

En nuestro caso, los equipos se dividieron por salas en función del área a la que pertenecían y el proyecto en el que trabajaban. Esto creo que dificultó mucho la comunicación y la sensación del equipo técnico era de incertidumbre.

En mi opinión, hay que fomentar más el trabajo en grupo y la colaboración en este tipo de eventos, dejando atrás la visión clásica de equipos estancos.

El equipo técnico

Una de las mejoras partes sin duda. Aunque los equipos estaban formados por estudiantes, todo el equipo demostró una gran profesionalidad e implicación. Hay que añadir a todo esto, que eramos el equipo menos numeroso y que hasta el final del primer día, no se pudo picar ni una línea de código debido a cambios de visión en los proyectos seleccionados.

Uno de mis objetivos que sí se cumplió fue introducir al equipo en las metodologías ágiles, trabajando todo el fin de semana con Kanban. Para ello, montamos un panel para gestionar de forma visual las tareas de ambos proyectos y el resto se redujo a auto-organización del equipo … Me encantó comprobar lo fácil que se adaptó el equipo a esta forma de trabajo.

Lástima que el equipo técnico fuera tan escaso, ya que nos tocó enfrentarnos a los dos proyectos ganadores sin demasiado espacio de tiempo, sin muchos recursos y con sólo un par de diseñadores gráficos. Sobra decir que lo que sí que había y fue el mayor motivante, era la ilusión de la gente y las ganas de superar el desafío. Esto es lo que realmente te carga las pilas en este tipo de eventos!!!

El resultado

Del iWeekend UJI salieron dos proyectos, los cuales se eligieron tras las votaciones del viernes. Uno de ellos, 7 global, aunque no era un proyecto “iWeekend” sino más un PYME, consiguió que los equipos trabajaran a tope y fue el que más partido logró sacar del fin de semana. Este proyecto tenía como objetivo ayudar a clientes que no estaban consiguiendo el impacto deseado en el mercado, ayudándoles a renovar tanto su imagen, como las prácticas empresariales utilizadas … Ah, y todo ello en una semana!!

El otro proyecto, byebyeMarks, se centraba más en la idea de poder vender el talento y la capacidad de innovación que tiene los estudiantes, y de como las empresas pueden aprovecharla para enriquecer su I+D. Este proyecto sí tenía en su ADN el componente de negocio, colaboración e impacto en internet que no tenía el otro, pero los continuos cambios en el objetivo final del proyecto hicieron que no acabara de definirse hasta el domingo por la mañana. En consecuencia, la parte técnica en este proyecto, la cual era bastante más compleja que en el anterior, quedó sin mucho margen de maniobra y tuvo que conformarse con un esbozo de lo que podría ser el portal final.

En definitiva, un fin de semana intenso y gratificante, en el que también hubo tiempo para ideas divertidas, como la que tuvo Ricardo. Ricardo presentó una idea que no salió elegida sobre popularizar las camisetas con mensajes positivos, como en la película de Hancock. Pués la idea que se le ocurrió, consistió en repartir su tarjeta de visita en un post-it con forma de corazón y hacer que el 80% de la gente la pudiera lucir en el pecho. Toda una muestra de como repartir cariño entre los asistente y de paso conseguir un poco de publicidad al mismo tiempo.

Señoras y señores, les presento al equipo iWeekend UJI 2011!!!!

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?

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.

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 …

“”"
Estamos aquí para poner en contacto a profesionales que quieren mejorar. Para tener un lugar donde encontrar intercambios de puestos de trabajo. Donde unos abren sus puertas a otros para compartir experiencia, conocimiento y metodologías. Todo ello con el objetivo de aprender.
“”"

Este interesante espíritu fué el que motivó mi interés por entrar en contacto con profesionales del mundo del desarrollo ágil de los que poder aprender buenas prácticas y aspectos avanzados de testing.

IPSA ha sido la empresa elegida gracias al talento de su plantilla, la cual cuenta entre sus filas con cracks como @jjballano y @AlfredoCasado.

Como en todo buen intercambio, mi objetivo era poder ofrecer algo al equipo de IPSA, así que durante nuestras conversaciones iniciales, descubrimos el interés de estos por el mundo de la firma digital, los formatos de firma y las APIs existentes.

Bajo estas premisas llegué ayer a Madrid con la intención de pasar cuatro días con el equipo e intercambiar experiencias relativas a testing y firma digital.

Tras el amable recibimiento de @jjballano a mi llegada, comenzamos a comentar distintos aspectos interesantes del desarrollo en los que podríamos colaborar. Empezaba a estar ansioso ya por ponernos manos a la obra y comenzar a trabajar

Hoy ha sido mi primer día en las oficinas de IPSA. El día ha comenzado con una reunion con el equipo de desarrollo con el fin de encontrar puntos de interés comunes, y no han tardado en surgir ideas como hacer un spike para testear las posibilidades de CryptoApplet y otras librerías de firma, así como la posibilidad de hacer un pequeño seminario sobre formatos de firma.

Posteriormente, hemos entrado en el día a día del equipo cumpliendo con la demo que tenían pendiente y una posterior retrospectiva y planificación del siguiente sprint.

Me ha sorprendido gratamente la cantidad de personas de negocio que este equipo es capaz de congregar y como se implican estas en el proyecto (unos minutos antes de la demo ya estaban todos por allí exigiendo la realización de la reunión).

Aunque hoy no hemos podido contar con @AlfredoCasado que estaba fuera de la oficina, he tenido la posibilidad de concluir el día haciendo unos tests de generación de firmas longevas XAdES X-L con @jjballano.

Mañana toca sesión de testing aprovechando que en este sprint hay muchas tareas de este ámbito, aunque es posible que también abordemos alguna tarea de front con JavaScript ya que es un punto que tocamos muy a menudo en las aplicaciones UJI.

En conclusión, primera toma de contacto y día intenso de Scrum y spikes de firma digital.

Mañana más

La primera parte del curso se completó con la jornada “Accesibilidad en primera persona” impartida por Miquel Martín y organizada por decharlas:

Posteriormente y junto a David Gonzalez (del Servicio de Comunicaciones y Publicaciones de la UJI), impartí un pequeño curso teórico/práctico en el que explorar los principales aspectos definidos por las guías de accesibilidad del W3C (WCAG 1.0 y WCAG 2.0) y cómo aplicarlas a nuestros sitios web realizando validaciones automáticas con TAW o HERA, o revisiones manuales.

A continuación os dejo las slides de la presentación a modo de resumen. El resto del material del curso lo podeis encontrar aquí.

Desde hace ya un tiempo que venimos utilizando Jenkins como servidor de integración contínua. El problema es que a medida que el número de proyectos aumenta, también lo hace el número de notificaciones por correo que recibimos de Jenkins informando al equipo del estado de los proyectos.

Como casi siempre con estos sistemas de notificación, la gente comienza a prestar menos atención a los correos recibidos y como consecuencia, se relaja la atención sobre el estado de las builds.

Intentado ver como corregir este efecto, vimos en internet distintos experimentos con sistemas visuales de notificación como semáforos o espadas laser, así que decidimos poner en marcha uno basado Nabaztag.

Nabaztag es un juguete electrónico en forma de conejo que, mediante una conexión wifi, es capaz de recibir y reproducir mensajes externos o ficheros MP3.

El objetivo era que el Nabaztag fuera el encargado de informar al equipo de viva voz cuando comienza una build, cuando concluye con éxito y, sobretodo, cuando falla.

Comenzamos a plantearnos como desarrollar un plugin de conexión con Jenkins, ya que Nabaztag proporciona un API REST para poder lanzar comandos. El caso es que Jenkins es una excelente herramienta para la que ya existen innumerables plugins, y como no podía ser de otra forma, ya existía un plugin para comunicación con los Nabaztag

El proceso de instalación fue realmente sencillo. Ir a Jenkins, agregar el plugin de Nabaztag y configurarlo:

Desde que lo pusimos en marcha, se ha convertido en uno mas del equipo, y gracias a webs como finecarrots, puede ir renovándose y cambiando de look.

Nuestro Nabaztag en San Valentin:

O para la feria de Abril:

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