Me quedé sin chapa. Sin chapa de “Mi primera CAS”. Conocí a varias personas que la llevaban orgullosos. Espero que para ellos significara lo mismo que significó para mí mi primera CAS.
Ésta, como aquella, ha sido una gran experiencia. La de este año ha sido enooorme, comparada con la de Cáceres. Hemos asistido más de 700 personas. Ha tenido que ser un trabajo monumental organizarla, así que desde aquí mis agradecimientos y admiración a todos los que la han hecho posible: organizadores, patrocinadores y voluntarios. Olé!
La conferencia fueron dos intensos días llenos de charlas interesantísimas. Dos días que saben a poco. Sobretodo porque no he podido disfrutar de las cañas de después, o las quedadas fuera del evento. Y también porque, a pesar de que todos los asistentes estuviéramos en la misma sala para tomar café y comer, me ha resultado imposible entablar conversaciones con todas las personas que quería. ¡Agotador! Pero muy motivador a la vez.
Sigamos con las charlas a las que asistí, y qué me llevé de ellas:
Apertura, Carlos Blé
Carlos habló de la necesidad de hablar inglés, no porque sí, si no para aprender de las fuentes. También habló de la importancia de hablar otro lenguaje, extraño para los desarrolladores, el de negocio. De esta forma nos entenderemos mejor ambas partes. Fue una charla muy inspiradora, fenommenal como apertura. Me quedaría con la frase:
Tú eres el único responsable de tu carrera
Your application is not your framework, de Enrique Comba
¿Por qué cuando te preguntan por tu applicación dices qué framework estás usando? Habla sobre qué hace de verdad tu aplicación. Enrique habló de muchos conceptos alrededor de los frameworks: convention over configuration, mezcla de lógica de negocio con la lógica impuesta por el framework. ¿Qué beneficios trae separar la lógica de tu aplicación del framework? Separación de responsabilidades, velocidad en los tests automáticos y sobretodo claridad en el propósito y estructura de tu aplicación.
Continuous delivery, de Peter Marshal
Peter compartió su experiencia en llevar a un equipo desde el desarrollo de una aplicación a la vieja usanza hasta alcanzar puestas en producción diarias. En las slides de la presentación encontrarás multitud de consejos para llevarlo a cabo, pero yo me quedaría con estos conceptos o enseñanzas:
- La entrega contínua es enfocarse en la excelencia técnica
- Conforme avanza el tiempo, el mayor problema de las aplicaciones con problemas es que los bugs aumentan mientras que las funcionalidades desplegadas disminuyen.
- La clave está en la simplicidad
- Lleva su tiempo madurar (equipo, producto, compañía,…)
Building resilient integrations, de Dave Moore
Esta charla tuvo su parte teórica y su parte práctica. De la parte teórica, decir que debemos entender que los fallos están en todas partes, por lo que es nuestro trabajo hacer software que no falle, que sea tolerante a fallos de sistemas externos. Algunas técnicas para hacerlo podrían ser: tests automáticos (no mienten, la documentación sí), aislar integraciones que herramientas de terceros (creando interfaces que las separen de nuestra applicación), utilizar nuestro propio modelo de datos, política de reintentos de conexión,…
En el taller de después tuvimos la oportunidad de poner todo esto en prática. Un taller super divertido.
Continuous integration in CartoBD, de Juan Ignacio Sánchez
Juan Ignacio empezó fuerte, comentando que, aunque hay millones de herramientas, es el equipo quien realmente puede hacer que la integración, entrega y despliegue contínuo funcionen.
¿Cómo lo hacen en CartoDB? Planeándolo desde antes que la gente entre a trabajar con ellos, despligando desde el primer día, planes iterativos e incrementales, tests, code reviews, pull requests, feature toggles, pequeñas releases a grupos controlados de usuarios (canary releases), posibilidad de hacer rollback rápidamente (pequeños despliegues llevan a que esto sea posible), análisis post-mortem de grandes fallos, mucha instrumentación y monitorización.
Keynote técnica, de Leo Antolí
Leo hizo incapié en lo más profundo de agile y lean: no te creas lo que te cuenten, pruébalo y si te funciona úsalo, si no te funciona, descártalo. Hay mucho estudios que dicen que una práctica es X veces mejor. Analiza esos estudios y te darás cuenta de que son humo. Pon en duda el pair programming, TDD, mejoras en productividad, code dojos, code retreats, craftsmanship, deuda técnica, tasa de proyectos software fallidos,…
Como buena keynote, lo que me llevo de esta charla son pensamientos, dudas, cuestiones. Debo entender que el software no es el fin, es un medio para conseguir un fin. Deja de usar números no probados. Cuenta experiencias propias (no sirven para demostrar nada, pero son algo real). Y sobretodo, mantén un espiritu crítico.
Keynote viernes, de Rachel Davis
Esta keynote trató de introducir cambios, de introducir tiempo para el aprendizaje. Debemos crear tiempo para ello a lo largo de nuestra semana. No tengas prisa en introducir cambios, la gente necesita tiempo.
De esta keynote quiero recordar dos consejos de Rachel: comparte lo aprendido (por ejemplo en esta CAS), invierte tiempo en profundizar en lo aprendido.
Escapando del modelo mete-saca, de Ricardo Borillo
¿Estamos seguros de que lo que quiere el usuario es un simple sistema CRUD? ¿No hay una forma de aportar más valor? Un CRUD es muy genérico, seguro que no resuelve las necesidades del usuario con la mejor eficiencia.
Ricardo analizó qué nos lleva a este modelo: pobres historias de usuario, mal definidas, que nos llevan a hacer cosas generales; los frameworks (como ORMs); y arquitecturas de usuario pobres, con componentes maestro-detalle, consumo de apis REST,… todo esto nos conduce al modelo mete-saca.
La solución propuesta por Ricardo, un único punto de entrada (en contraposición a los múltiples endpoints REST) con una arquitectura CQRS. Cada comando correspondería con una acción del usuario, una historia de usuario, un caso de uso muy específico, que nos conduciría a tener las mínimas funcionalidades desarrolladas con la máxima eficiencia y la mejor usabilidad para el usuario.
Economía del software, de Luis Artola y Guillermo Gutierrez
Luis y Guillermo nos condujeron en un viaje apasionante desde las necesidades de negocio hasta detalles del código, tales como las dependencias. En el camino, comentaron multitud de conceptos, de buenas prácticas, hicieron referencia a charlas de todo el evento (lo que pone de manifiesto lo amplio de su charla).
Concepto clave: negocio quiere entrega de valor, minimizando costes y riesgos pero manteniendo opciones abiertas. El mayor en el software es el coste de evolución. Cuanto más difícil sea cambiar algo, más costoso será a lo largo del tiempo. El desarrollo iterativo e incremental reduce los riestos. El despliegue de pequeñas funcionalidades, interfaces, inversión de control son formas de crear opciones.
Effective UI testing, de Enrique Amodeo
Todo comenzó con el dilema: ¿debo testear cada clase individual o todo el sistema? Pues ni lo uno, ni lo otro. En cuanto a la interfaz gráfica, la podríamos dividir en dos dominios: la presentación y la lógica de usabilidad.
¿Como testear cada parte? Para testear la presentación debemos mockear el DOM del navegador. Para testear la lógica de usabilida, debemos mockear el acceso al servidor. Basándose en eso, Enrique recomienda seguir dos prácticas: encapsular los accesos al servidor y los accesos al DOM.
Trabajo para casa
- Parece que integración, entrega y despliegue contínuos son prácticas básicas para empresas exitosas.
- Prepara las conferencias a las que asistas: busca el lugar donde se va a celebrar e imprime un plano de las salas que se van a utilizar, crea una checklist con las cosas que hacer antes de asistir a un evento. Como por ejemplo prepar preguntas a hacer a gente interesante que quiero conocer (me gustó aquello que hiciste/dijiste, discrepo con aquello que …)
- Echar un vistazo a la herramienta Screen Hero
- Libro recomendado por Leo Antolí: Pensar rápido, pensar despacio
- Libro recomendado por Rachel Davis: Drive (cómo introducir cambios)
- Busca slide de Rachel Davis sobre Sources of learning
- Busca referencia a lo que falta de SOLID: RCCASS
- ¿Qué es el patrón Page Object?
- Slide con las mejores prácticas recomendadas por Enrique Amodeo