Agile

Imagen de http://www.harringtonstarr.com/agile-methodology-best-option-software-delivery/

Todo el mundo habla de Agile, scrum, Kanban, XP o de ser más agile. Pero, ¿qué es agile?

Agile comenzó cuando 17 personas se juntaron en Utah en el 2001 y crearon el manifiesto agile.

Personalmente, agile es una filosofía y una forma de ver las cosas. Solo hay que comprobar que el manifiesto contiene también 12 principios. Esos principios me gustan más que el manifiesto.
Por ejemplo, el primer principio que es muy bueno y dice: “nuestra prioridad número uno es satisfacer al cliente con frecuentes entregas de software que aporta valor”.

Además agile es una forma de solucionar varios problemas que tenemos en el desarrollo de software. Los principales problemas que intenta solucionar son los siguientes:

Los requisitos cambian

Porque el cliente no tiene claro lo que quiere, porque no hemos entendido lo que quiere, porque ha surgido una nueva funcionalidad que puede ayudar al cliente más que los requisitos actuales, porque ha surgido una nueva funcionalidad que es necesarias para poder dar valor a las demás. Seguramente que puedas sacar más porqués por tu cuenta, pero lo que está claro es que cambian.

El coste se va de las manos

Y el coste se va porque no somos buenos estimando proyectos, porque nos confundimos en el desarrollo, diseño o toma de requisitos, porque añadimos mayor complejidad a nuestros diseños o código lo que hace que vayamos avanzando más lentamente, porque nos encontramos problemas que no conocíamos o que conocíamos pero que no hicimos nada al espectro o que aún conociéndolos y haciendo algo al respecto nos hizo perder mucho más tiempo de lo esperado, porque dejo la empresa gente que trabajaba en el proyecto, porque gente del proyecto es movida a otro proyecto con mayor importancia para la empresa.

El valor obtenido es muy pequeño

Este problema es una combinación de otros problemas. Como por ejemplo, de los dos primeros ya que si los requisitos cambian pero no hacemos nada al respecto el cliente obtendrá menos valor y además si el coste aumenta mucho quizás el valor que le hemos dado no compense.

En resumen, agile es una filosofía que ayuda a resolver los principales problemas que tenemos en el desarrollo de software.

Codemotion 2016

Imagen de Codemotion https://2016.codemotion.es/

He podido asistir este año a un gran evento a nivel nacional como es Codemotion.

Estoy muy contento de haber podido asistir ya que nunca había participado en nada parecido (no con este tamaño y de varios días). Además, me acercó a uno de mis objetivos para el 2016.
Como decía, ha sido mi primer año en Codemotion y tengo que decir que ha estado muy bien. Se nota que es una de las citas obligatorias a nivel nacional.

Como regla general, asistí a las charlas de las personas a las que conocía virtualmente y fue un acierto porque a todas las charlas que fui conociendo el speaker me gustaron.

Para el próximo año tengo que ir preparado para los workshops. Había muchos interesantes pero sin tener nada preparado no tenía mucho sentido el asistir.

En este artículo me voy a enfocar en las charlas a las que fui y que más me gustaron, pero antes, me gustaría dar las gracias a los organizadores porque organizar un evento de más de mil personas, a un precio muy asequible (pagué alrededor de 130 euros) y hacerlo con ponentes de calidad debe de ser un trabajo de titanes. GRACIAS.

Las siguientes apartados contienen información de las tres charlas que más me han gustado.

Agustín Cuenca – Cacahuetes y monos digitales o sobre como sobrevivir a las 6Ds

Esta fue la primera charla a la que asistí, después de la keynote, y fue un gran acierto.
Agustín habló del porqué de los sueldos bajos de los programadores en España y de las 6Ds.
Me gustó mucho porque es muy bueno comunicando y porque lo que contó me hizo pensar sobre el futuro del desarrollo del software.
Uno de sus hilos argumentativos fue que en un futuro los programadores no seremos necesarios. Esta parte fue la que me hizo pensar.

La pena de esta charla es que no fue grabada, pero tenemos las slides en el siguiente enlace:

http://www.slideshare.net/agustincnc/codemotion-2016-cacahuetes-y-monos-digitales

Mark Heckler – Living on the Edge (Service): Bundling Microservices to Optimize for Devices

Mark no hablaba español. Así que la charla fue en inglés.

El tema tratado tuvo poco que ver con el título. Una pequeña introducción de microservicios poniendo como ejemplo Netflix y después lo que hizo fue el crear aplicaciones con spring boot desde cero que formaban un ecosistema de microservicios.

Lo que me gustó de la charla fue la cantidad de componentes que están integrados en spring y que te permiten crear microservicios en poco tiempo.

Su charla si que fue grabada y está en el siguiente enlace:

Roberto Canales – Intraemprendimiento para frikis

Había visto varias charlas Roberto que me gustaron mucho debido a su forma tan simple de explicar. En este caso la charla fue de como Autentia, la empresa en la que es CEO y da servicios informáticos a empresas, están creando sus propios productos y cuál es el camino que están recorriendo.
A quien no le gusta escuchar de los errores de los demás 🙂

La charla también fue grabada:

Más charlas

Si quieres más, muchas de las charlas fueron grabadas y las podrás encontrar en la página de Codemotion:

https://2016.codemotion.es/agenda.html#5732408326356992

Toda charla que tenga un icono con forma de botón de play y de fondo azul es que fue grabada. Para acceder al vídeo, tienes que acceder a la ficha y pulsar el icono que te comento.

Resumen

El siguiente tweet es un buen resumen de Codemotion:

Me ha gustado mucho el evento. Mucha gente pero muy chulo. Seguro que el próximo año vuelvo #Codemotion2016

— Enrique Martín (@kikers25) November 19, 2016

* Modificado 02-12-2016: Solucionado algunos errores ortográficos

Ventajas de Spock para testear en Java

Imagen de http://www.playbuzz.com/jamesk20/leonard-nimoy-versus-spock-can-you-tell-which-quotes-are-from-his-famous-star-trek-character

Introducción

Groovy es un lenguaje de programación dinámico para la máquina virtual de Java (JVM). Esto hace que sea muy fácil de configurar para alguien con experiencia en Java.
Lo que más destaca de este lenguaje es su sintaxis (syntax sugar) que facilita mucho el desarrollo. Y además es muy fácil comenzar a programar porque lo han hecho muy amigable para la gente que viene de Java. Es casi un superconjunto de Java.

Dentro del extenso ecosistema de Groovy tenemos Spock, que es una framework para escribir test. Spock tiene como ventaja principal la legibilidad de los test. Hace que los test sean muy fácil de entender sin ni siquiera saber nada de Spock o Groovy.
Lo más interesante de Groovy y Spock para alguien que viene de Java es que podemos tener nuestro código fuente en Java y los test en Spock.

Ventajas de Spock

En este apartado se listan los que son a mi entender las mayores ventajas de Spock frente a Java.
En cada apartado hay un ejemplo de como es el código en Spock y en Java para que puedas comprobar de la forma más clara posible la diferencia entre uno y otro. En la parte izquierda de las imágenes aparece el código con groovy y spock y a la derecha el código con java y junit.
Para los ejemplos de java se ha utilizado JUnithamcrest y mockito.

Los ejemplos en Groovy fueron creados por Iván López y los escritos en Java están escritos por mí. En el siguiente repositorio puedes encontrar el código fuente:

https://github.com/kikers25/codemotion-2015-spock

El repositorio lo escribió Iván para una charla sobre Spock y lo he extendido añadiendo los test que aparecen pero en Java porque me parecía que es más fácil ver las ventajas si se ven los dos juntos.

  • Nombre de los test unitarios son cadenas

Los nombres de los test unitarios son importantes para entender que es lo que hace el código del test. En Java, el nombre del test es el nombre del método y no se pueden escribir espacios. Por lo que se tiene que utilizar algún tipo de método para que el lector sepa que hay un espacio. En mi caso suelo utilizar guiones bajos.
Con Spock esto no es necesario porque el nombre del test es una cadena. Así, podemos escribir espacios y otros caracteres que no son posible de utilizar en Java.

 

  • Estructura de cada test en bloques

La separación en bloques de los test escritos en Spock es lo que hace que la legibilidad del test mejore mucho.
Los bloques están basados en el lenguaje gherkin y los bloques más comunes (aunque hay más) que se utilizan en un test son given, when y then. Estos bloques inicializan los objetos a utilizar (given), ejecutan la acción a probar (when) y comprueban que el resultado es el esperado (then).

 

  • Inicialización de clases, listas y mapas

La inicializacion de objetos en groovy es de lo más fácil porque no necesitamos el crear un constructor con todos los métodos, si no que por defecto tiene un constructor al que puedes pasarle en modo de clave y valor todos los atributos que quieres inicializar del objeto. Personalmente utilizo mucho el patrón constructor (builder pattern) para crear objetos para mis tests. Con groovy no es necesario.
Además crear listas y mapas es muy intuitivo y fácil de leer.

 

 

  • Tablas de datos

Con diferencia esta es una de las mejores características de Spock. Añadir test que hacen lo mismo pero con diferentes valores para los parámetros de entrada y el valor de salida utilizando una tabla de datos es una gran funcionalidad. Fíjate en las diferencias en la imagen de abajo.

 

  • Herramienta de dobles de test completamente integrada

Utilizo jmock y mockito para crear mis dobles de pruebas para mis test. Con Spock no necesitas el buscar ninguna librería ya que viene integrada. Lo único que no me gusta es que para que una clase mockeada devuelva un valor no es necesario especificarlo a la clase. Lo que es lo mismo el framework es lenient por defecto.

 

  • Mensajes de error cuando un test falla

Los mensajes de error son más claro que utilizando hamcrest.

Resumen

Groovy en combinación con Spock tienen muchas ventajas a la hora de escribir test si lo comparamos con Junit, Hamcrest y Mockito.
La configuración es muy fácil, resulta fácil el empezar a programar y la legibilidad de los test es muy buena. Es el framework para testing más completo que conozco.

Extra

Si te parece interesante tanto Groovy como Spock y quieres saber más. Los enlaces que aparecen a continuación son vídeos de las charlas de Iván López y Andrés Viedma sobre Spock:

https://www.youtube.com/watch?v=RjH1bd9D2Qs 
https://www.youtube.com/watch?v=D7TjLThg95I