Tabla de contenidos
Durante el último fin de semana del mes de septiembre 2018 tuvo lugar la 6a edición del (Software Crafters Barcelona 2018). Y Apiumhub tuvo ocasión de participar como sponsor Platinum y formar parte del grupo de speakers y abrir el evento con una reflexión. También, Albert Parrón – Arquitecto Frontend de Apiumhub dio una charla sobre MVP & FRP for a controlerless architecture.
Hubo múltiples conferencias en el Software Crafters Barcelona 2018 y estas son algunas notas de las que atendí.
Software Crafters Barcelona 2018 – Notas y reflexiones
Automatiza y vencerás por David Antón Lou
David nos dio herramientas para automatizar las distintas fases del proceso de desarrollo. Consejo:
Automiza (casi) siempre, (casi) todo.
La razón principal: si automatizas algo, seguramente el proceso sea más rápido y te pueda ayudar a ahorrar tiempo y dedicarlo más a la parte de negocio. También, reducirás la probabilidad de error humano simplificando los entornos.
Automatización del código
Antes de empezar con la programación, existe una parte que se repite: construir el esqueleto de la aplicación. No lo repitamos cada vez!
Una librería java para crear todo el código repetitivo (getters / setters / hashcode / equals …).
Sin embargo en mi opinión, todas estas características te las ofrece directamente Kotlin sin la necesidad de librerías externas y sin tener que cambiar nada si tu proyecto ya está en java. Además algunos IDE´s más potentes como IntelliJ ya hacen parte del trabajo.
Una herramienta que genera una aplicación esqueleto con Spring. Puedes elegir entre maven / gradle, java / kotlin / groovy, la versión del spring boot y sus dependencias. Una vez construido, se puede empezar a programar tu aplicación.
Otro generador de aplicaciones muy recomendable. En este caso, te construye la aplicación entera (backend + frontend). Alguna de las herramientas a utilizar son yeoman + spring boot (backend) + angular / react (frontend) + despliegue y la opción de CI o CD.
Packaging
Una vez el código esté finalizado, se tiene que empaquetar. Al ser un proceso tan repetitivo tiene que automatizarse.
Se basa en un archivo xml con instrucciones. No tiene dependencias de control.
Sigue basándose en un archivo xml pero tiene dependencias de control.
Tiene su propio lenguaje de dominio (DSL) basado en Groovy. Es el más potente de los tres. Sabías que desde gradle se pueden ejecutar tareas ant definidas en un build.xml?
Automatización de test
Automatiza todos los test cuando sean:
- Repetidos
- Tests de stress
- Tests con mucho tiempo de ejecución
- Partes críticas del negocio
Mejor no realices test en partes:
- Con cambios continuos
- De gran complejidad
Entorno de desarrollo
La configuración del entorno cada vez que llega alguien nuevo al proyecto puede llegar a ser una tarea muy tediosa. Automatízala con:
En Apiumhub apostamos por docker ya que nos ayuda mucho en la parte del empaquetamiento y el despliegue.
Automatizar el despliegue
Una vez tienes todo hecho, el último paso es desplegar el proyecto en un servidor.
Mantiene la configuración para los diversos entornos y ayuda a desplegar aquello construido.
Mide más y sufre menos, charla de Modesto San Juan en el Software Crafters Barcelona 2018
En nuestro mundo, cuando queremos mejorar el rendimiento de nuestra app, reducir el tiempo sin el servicio… debemos actuar basándonos en métricas, no con nuestros sentimientos. Hay que resolver estas 3 preguntas:
- Que estoy intentando mejorar?
- Cómo puedo medirlo?
- Cómo puedo resolverlo?
Herramientas
Una plataforma que crea dashboards con una visualización atractiva.
Una herramienta para monitorizar y crear alertas. Con métricas muy detalladas.
Acumular datos con prometheus y mostrar los resultados en grafana es una buena combinación para conocer las métricas de tu proyecto.
Un ejemplo sencillo:
- Justo antes del nuevo despliegue, haz una marca en grafana
- Despliega
- Desde ese punto, tienes la referencia para ver si tu rendimiento ha mejorado o empeorado.
Muestra la visualización de los recursos y cómo han interactuado entre ellos.
La idea principal es utilizar las métricas para mejorar todos tus procesos:
- Comprobar las peticiones más costosas a tu base de datos
- Mejorar tu CI / CD y ver cuánto tiempo tarda.
- Observar tus entornos de producción (ping errors, bad requests…)
- Evitar sorpresas en la nube: observar los gastos y ver si cambian..
- Evitar demasiada información!
Unos buenos dashboards de información serían los que tengan:
- logins + compra + tiempo de respuesta + despliegues
De un único vistazo, es fácil ver que cambios afectan a tu negocio.
Parallel changes, charla de Eduardo Ferro Aldama en el Software Crafters Barcelona 2018
Eduardo dio un buen workshop sobre cambios paralelos o sobre cómo mejorar nuestro código paso a paso:
- Pequeños cambios muy a menudo (CI)
- Trabajar de una forma efectiva con código legacy
- Arquitectura con evolución
Realizando cambios
Presta atención cuando:
- Web UI
>Uso de la feature toggles
- Una buena alternativa a la de mantener múltiples ramas.
- Una definición por Martin Fowler
- En su blog, tiene este otro artículo muy interesante
>Duplica la vista cuando tiene que ser modificada
> Si la vista no está conectada a la navegación principal, se puede actualizar de una manera más sencilla
- En comunicación, un buen principio a tener en cuenta:
Robustness principle (aka Pastel’s law)
Ser conservador en aquello que envías y liberal en lo que recibes
Comprueba sólo los datos que necesites, ignora el resto
- Sobre la lógica o rendimiento
> haz ramas por abstracción
Otra vez, artículo por Martin Fowler
«Branch by Abstraction» es una técnica para realizar un gran cambio a un sistema de software de una manera gradual que te permitirá ir actualizando el sistema de una manera estructurada mientras está todavía en proceso
>Después de un cambio:
Ha de validarse la información
Medir el rendimiento
- Arquitectura
> Strangler application
Artículo de Martin Fowler otra vez
Crear un nuevo sistema alrededor del antiguo ( el cuál está todavía en producción) hasta que la última versión está totalmente estrangulada y la puedes quitar.
En este artículo hay algunos ejemplos.
Una buena herramienta cuando realizas cambios paralelos puede ser scientist – github
Scientist es una librería para hacer test de refactoring, reescribir y mejorar el rendimiento en Ruby (actualmente ya hay versiones en otros lenguajes). Por ejemplo, ejecuta el código antiguo y el nuevo y con los resultados hace una comparación.
Desde el blog de informática de github, está este artículo describiendo la importancia del mismo y cómo lo aplican su código.
Open spaces
Una parte del primer día se dedicó a “open spaces”. Cualquier interesado en algún tema en particular proponía un tema informal. De entre todas las propuestas salieron charlas muy interesantes como production deployment, event storming, diversidad, código con ramas / trunk base development…
Conclusión Software Crafters Barcelona 2018
Esta ha sido una pequeña parte de todo lo que fue el evento. Un gran fin de semana con conferencias y workshops de alta cualidad. Cada año la conferencia mejora, y en parte es gracias a la gran labor de los voluntarios. Seguid así para futuras ediciones!
Si quieres saber más sobre Software Crafters Barcelona 2018, os recomiendo que os subscribáis a nuestro newsletter mensual aquí.
Barcelona como ciudad intelignete
Proyectos de ciudades inteligentes
Mapa de los “main players”: ecosistema startup y tech en Barcelona
Proyectos IoT que cambiarán el mundo
Ecosistema de salud digital en Barcelona
Inovación disruptiva: ejemplos
Los beneficios de la tecnología Scrum
Beneficios de la tecnología Agil
Metodo Kanban Principios y Ventajas
