El pasado 19 de junio tuve la suerte de poder atender al JBCNConf la conferencia sobre Java que se organiza en Barcelona de unos años para aquí. Acudí allí enviado Fon, que es la empresa donde trabajo para dar cuenta de lo que allí se contó. El evento estuvo muy bien organizado, con ponentes que tenían mucho nivel y temas interesantes del mundo «Java». La mayoría de las charlas se englobaron en los temas de arquitecturas orientadas a eventos (Event driven, CQRS, etc), programación reactiva, principios del desarrollo de micro servicios y las novedades de Java 9. Parece que estos son y van a ser los temas más de moda en los meetups de Java en los próximos meses. Dentro de las charlas que atendí, las que más me gustaron fueron:
Java Libraries You Can’t Afford to Miss de Andrés Almiral
En esta charla, Andres Almiral explicó en tiempo record, una lista de librerías que el considera muy útiles para cualquier desarrollador Java.
Varias de las librerías que explicó fueron algunas muy conocidas como Lombok, Mockito, Jackson o Guava. Otras librerías interesantes que comentó fueron:
- Retrofit(http://square.github.io/retrofit/): permite crear clientes de apis rest declarando un interface, de manera muy similar a como lo hace Feign de Netflix, pero utilizando un builder para instanciarlo.
- Mbassador(https://java.libhunt.com/project/mbassador): es una librería que implementa el patrón observable de una manera muy eficiente y sencilla de usar.
- Jdeferred(https://github.com/jdeferred/jdeferred): librería que nos permite hacer promesas para tratar con acciones asíncronas de manera similar a como lo hace angular 2.
- Junitparams(https://github.com/Pragmatists/JUnitParams): permite parametrizar pruebas unitarias con lo que se puede evitar repetir mucho código.
- Spock(http://spockframework.org): es un Framework de Groovy que nos permite escribir pruebas de una manera muy legible cercana al BDD. Vimos ejemplos de clases Java con pruebas unitarias hechas con Spock en diferentes charlas, lo que indica que esta combinación es cada vez más usada. Creo que sería interesante hacer alguna prueba de concepto en la comunidad backend, reescribiendo algunas pruebas unitarias usando Spock para ver las ventajas y desventajas de usarlo.
- Awaitility(https://github.com/awaitility/awaitility): está librería nos facilita la creación de pruebas cuando tenemos sistemas asíncronos, definiendo por ejemplo asserts configurados para tener una respuesta en un determinado timeout o fallar en otro caso.
- Wiremock(http://wiremock.org): nos permite hacer mocks o stubs de apis rest que no tenemos disponibles, por ejemplo porque estamos en el entorno de pruebas. Aquí hay un tutorial donde está bien explicado http://www.baeldung.com/introduction-to-wiremock.
He encontrado la charla aquí, es de otro evento pero cuenta lo mismo. Todavía no están disponibles los vídeos con las charlas, pero supongo que en algún momento los publicarán porque las grabaron todas y las del año pasado están publicadas.
Real World Java 9 de Trisha Gee
Esta charla fue bastante interesante. La ponente, desarrolladora en Jetbrains (los autores de Intellij), comentó las novedades de Java 9 mostrando y escribiendo código en directo. Explicó que Java 9 es más eficiente en varios aspectos, ya que implementa mejoras en la gestión de la memoria, gestión del hardware, mejor performance en general, mejor documentación, etc.
Solo por esto ya merecería la pena usarlo. También recorrió cada una de las grandes features de Java 9:
- Jigsaw: funcionalidad que mejora la modulariad y encapsulación del código. A partir de Java 9, si utilizamos esta funcionalidad(no es obligatorio por temas de compatibilidad con versiones anteriores) tendremos que añadir en cada módulo un fichero llamado module-info.java donde definimos el nombre del módulo, que clases o paquetes son accesibles desde fuera de nuestro modulo y cuáles se requieren. Parece que va ser un poco lioso al principio y Trisha recomendaba utilizarlo en proyectos nuevos más que hacerlo en proyectos ya muy avanzados. Trisha hizo ejemplos utilizando Intellij y la buena noticia es que este IDE tiene una buena integración y va escribir este fichero casi por si mismo, siguiendo indicaciones nuestras al resolver fallos de compilación relacionados con la definición del fichero module-info.java. Por ejemplo si no tenemos acceso a un paquete de una librería que tenemos incluida en gradle, Intellij va ser capaz de añadir la línea importándolo al resolver el fallo de compilación resultante de no tenerlo.
- Nuevos métodos factoría para inicializar colecciones. Comentó que en su opinión esta va ser la funcionalidad más utilizada. Vamos a tener nuevos métodos para inicializar listas, mapas, etc, de manera menos tediosa que ahora. Por ejemplo un mapa se va poder inicializar escribiendo: Map.of(«Hello», 1, «World», 2).
- Java 9 incluye nuevos métodos e interfaces para hacer programación reactiva dentro de Java SE 9 Reactive Streams API.
También he encontrado el vídeo de esta charla en otro evento.
When, why and how to CQRS de Sebastian Daschner
Sebastian explicó los principios del patrón command query responsibility segregation (separar lecturas y escrituras, comunicación entre servicios solo por eventos, etc) y mostró una demo con un pequeño ejemplo, implementando 3 servicios siguiendo este patrón. Esta charla fue interesante porque a pesar de que es un tema muy de moda, del que se habla mucho, es bastante complicado encontrar ejemplos claros, y su ejemplo fue muy sencillo y fácil de entender, poniendo un poco de luz en el tema. La charla también circula en por Internet, si estáis interesados en CQRS os la recomiendo https://www.youtube.com/watch?v=iK8x1mUPwCE . El código de su ejemplo esta aquí https://github.com/sdaschner/scalable-coffee-shop
Star Trek: BDD Enterprise de Tomasz Dubikowski
Esta charla nos sorprendió porque parecía que iba a ser peor de lo que fue en un primer momento. La presentación consistió en un recorrido por la experiencia laboral de Tomasz lidiando con proyectos donde se intentó seguir la metodología Behaviour driven development (BDD) y como en su opinión no es una práctica muy viable por lo complejo de las relaciones entre los departamentos de desarrollo y negocio. Como conclusión Tomasz recomendaba hacer las pruebas unitarios utilizando Spock, que como explicaba antes es un Framework de Groovy que tiene una sintaxis muy cercana al BDD. Decía que era una solución de compromiso, que sin llegar a ser BDD puro, conseguía pruebas legibles para gente no técnica. Esta charla también circula por Internet pero solo en polaco…
The Long Road de Sandro Mancuso
Para cerrar el evento, Sandro Mancuso autor de The Software Craftsman, dio una charla no técnica acerca de como enfocar el oficio de desarrollador, entrando en temas como cuando cambiar de trabajo, que empresas evitar, etc. Fue muy interesante, de hecho arrancó varios aplausos espontáneos y hubo algún momento curiosos, como cuando preguntó que cuales de nuestras empresas estaba buscando gente y prácticamente toda la sala levanto la mano. Está charla está en Internet porque ya la había dado en otro evento, aquí está el enlace.
Taller de Test Refactoring de Wlodek Krakowski
El último día teníamos opción de escoger dos talleres prácticos de entre ocho y el primero al que acudimos fue el impartido por Wlodek Krakowski, con la temática de refactoring. El ponente es team leader y profersor en trainings sobre refactoring y demostró ser un auténtico maestro en la materia. 20 minutos después de empezar el taller nadie en la sala estaba escribiendo código, ya que era imposible seguir todos los cambios que estaba haciendo mediantes atajos de teclados de Intellij a toda velocidad, en una muestra de auténtico virtuosismo con este IDE. El refactoring que hizo (podéis ver el código aquí https://github.com/wlodekkr/tests-refactoring) consistió en refactorizar una típica clase con pruebas de una API rest hechas usando MockMvc. Básicamente aplicó el patrón builder a todo lo que tenía más de dos líneas de código y simplificó las pruebas muchísimo.
En resumen, ha sido un evento muy recomendable y agradezco a la organización el esfuerzo y a mi empresa Fon hace el esfuerzo de mandarme.
Coconut code 