Mi paso por la CAS 2015

2015-12-07

Esta última semana tuve la oportunidad de asistir a la Conferencia de Agile Spain (CAS) 2015 en Madrid. Empezaré con mis reflexiones sobre el evento. Seguidamente expondré un pequeño resumen de las charlas a las que pude asistir.

Reflexiones

Ha sido la primera vez que asisto a la CAS. Este año batió record de participación con 700 participantes. En primer lugar quiero felicitar al equipo de organización porque sé que ha debido ser muy duro hacer el excelente trabajo que han hecho. Yo como participante lo he pasado muy bien.

Me ha encantado tener otro encuentro con muchos amigos de la comunidad. Por otro lado este evento también me ha permitido conocer a grandes profesionales. Es muy inspirante encontrar a tanta gente tan motivada y con diversos perfiles dentro de la industria del software. En cualquier conversación en la que pudieras unirte asomaba la oportunidad de aprender de la otra/s persona/s. Ha sido muy acertado ir al evento ya que además he podido tomar un montón de apuntes y notas para compartir con los demás compañeros de trabajo y de la comunidad.

En esta CAS también hemos tenido la oportunidad de reunirnos casi todo el equipo de Carlos Blé & Associates. Aunque no hayamos hablado todos juntos tanto como nos hubiera gustado, fue muy emocionante ir a cenar y las conversaciones que teníamos para opinar cada charla.

Por último después de varios meses sin ver a mis grandes amigos Juan y Miguel, la CAS nos ha permitido volver a encontrarnos y ha sido muy bonito el reencuentro. Me alegra ver que a ambos les va muy bien. Ya les estoy esperando con un Coding Dojo preparado para su vuelta a Gran Canaria este mes.

A pesar de haberlo pasado muy bien y haber aprendido mucho, tengo que mencionar dos pequeñas críticas:

Keynotes

Tan solo una en mi opinión llega a la altura de lo que yo esperaba que fuese una keynote (recalco que las demás me han gustado pero como charlas). Esta fue la de Leo Antoli. Su mensaje era precisamente dejar a un lado los dogmas y evaluar por nosotros mismos que funciona en nuestro entorno y que no. Tras la charla estuve unos minutos cuestionándome cuáles prácticas considero importantes en mi día a día y por qué. Tuve la oportunidad de debatir con Leo sobre el movimiento Software Craftsmanship y a pesar de las discrepancias me encantó el debate. En las otras keynotes también me llevé un mensaje principal:

  • Eugenio Moliní. Sé el cambio que quieres ver en el mundo
  • Rachel Davies. La importancia de tener un equipo motivado y con ganas de formarse.
  • Corinna Baldauf. No conformarse con hacer retrospectivas, sino entrenar para hacerlas bien.

Charlas.

Me habría gustado que hubiera charlas más técnicas y que estas tratasen de concretar algo más. Muchas de las charlas del track Mejorando Software se me han quedado demasiado introductorias. Me encanta Agile porque ha conseguido que los equipos se unan y ha servido para crear un entorno en el que nos sentimos muy motivados y productivos. Esto ha conseguido que el movimiento Agile empiece a evolucionar y crecer también en aspectos como la organización de equipos, entrega de producto, el crecimiento personal…

No obstante, no debemos olvidar cuál es su origen y debemos hacer una fuerte insistencia en que también sean las prácticas técnicas las que formen parte del cambio. Así como la formación a nivel individual para crecer a nivel profesional y rendir a mejor nivel dentro de un equipo. No olvidemos que nuestro objetivo número 1 es entregar software de calidad. Lo cual se hace imposible si el nivel técnico de los desarrolladores es bajo.


Aquí dejo los resúmenes con algunas de las notas que tomé en cada charla.

Apertura del track: Mejorando Software

Carlos abrió este track explicando con un toque muy divertido y humorístico cómo ve el perfil de un desarrollador. Explicando entre otras cosas la importancia de conocer el inglés, leer libros, formarse… Además nos deleitó con un baile que nos tuvo durante minutos riéndonos.

Your application is not your framework

Bueno nosotros ya tenemos esta lección estudiada. Yo llegué tarde a esta charla pero algunos compañeros me dijeron que fue bastante introductoria. No obstante, me gustaron los puntos que recalcó Enrique Colba refiriéndose a los beneficios de desacoplarte del framework: **separación de responsabilidades, tests más rápidos, clarifica el propósito de la aplicación así como su estructura.

El arte de dar feedback (Comunicación Verbal No Violenta)

Esta charla me encantó. Esta me llamaba mucho la atención ya que considero que no consigo expresarme bien cuando trato de comunicarme. Agradezco muchísimo a Alberto porque esta charla ha sido muy inspiradora para mí. Pasaré a mencionar aquellos consejos/tips que considero más importantes: Evitar ser Chicote cuando damos feedback, empatizar con la otra persona, transmite lo que sientes, no etiquetar a las personas, las comparaciones son odiosas, matizar, observa para poder evaluar, tratar de agradar las peticiones de los demás, mensajes constructivos en lugar de ataques, expresar tus necesidades a los demás

Building resilient integrations

Dave Moore en esta intentó explicarnos la importancia de protegernos al integrarnos con sistemas de los cuáles tenemos poco o ningún control. En la parte teórica, nos habló de no confiar en integraciones de terceros, hacer wrap de las dependencias para facilitar su uso y aumentar nuestra confianza, parallel changes… La parte práctica se basó en hacer un cliente http. Básicamente teníamos una API y su pequeño contexto y teníamos que hacer un cliente para consumirla tratando de cubrir todos los posibles errores. Fue un taller bastante divertido en el que surgieron conversaciones muy interesantes. Fue más corto de lo que nos habría gustado así que la continuaremos en las próximas semanas en la comunidad.

Integración continua en CartoDB

En esta Juan Ignacio Sánchez nos explicó la forma que tienen de trabajar en CartoDB. Haciendo hincapié a la importancia de la entrega continua para obtener feedback. Explica también como trabajan con Pull requests y feature flag entre otras cosas para poder lograr esto. Destaca que es arriesgado y que es necesario tener un fuerte equipo de DevOps y muchos planes B. Menciona entre otras, las siguientes ventajas: es más barato, no hay día de deploy, es fácil hacer un revert, progreso más visible…

Escapando del modelo de desarrollo mete-saca

Esta sin duda fue mi favorita. Probablemente porque se acercó más al enfoque técnico y por el contenido en sí. Ricardo empezó hablando de la importancia de evitar hacer interfaces de usuario basadas en escribir y leer los datos a modo de tablas. Debemos ser capaces de abstraer conocimiento de los datos para ofrecer al usuario lo que realmente necesita. Dice que para esto es necesario tener buenas historias de usuario que expresen realmente la funcionalidad. Además nos habla de dos conceptos muy interesantes. Por un lado CQRS (muy resumido, un patrón que trata de separar la escritura de la lectura). Esta charla me hizo comprender bastante mejor como funciona. Por otro lado, nos habla de tener aplicaciones que manejan comandos, teniendo un único endpoint en el lado del servidor. Es decir, comunicarme con el servidor mediante la misma url enviando un comando concreto. Lo cuál en mi opinión hace mucho menos costoso el desarrollo de tu controlador y te permite tener más control sobre esta parte de tu código. Además al final de la charla nos recomienda que echemos un ojo a los canales de youtube de facebook y netflix.

Software Economics

Se habló de todo. Especialmente me gustó que trataran de reflejar como las decisiones que tomamos tienen una repercusión directa en la economía de nuestro software. Por eso debemos ser capaces de explicar la importancia de un refactoring, de utilizar determinadas prácticas/metodologías… Se habló la aplicación de conceptos como la inversión del control o arquitectura hexagonal (entre otros) nos ofrece más opciones a la hora de tomar decisiones. También pensar en grupos de clases en lugar de en clases individuales es un concepto relevante. Se le dio un enfoque muy interesante a la charla respecto de la duplicidad. Evitar duplicidad a toda costa podría generar una explosión de dependencias. Por la tanto debemos hacer trade-offs antes de negarnos a duplicar partes concretas.

Effective UI testing

En general explicó como dividir nuestro vista en capas muy alineado a lo que viene a ser MVVM (Model View View-Model) para luego poder usar un web driver que explotase esta división a la hora de hacer tests. Expresó la importancia de que la vista debe tan solo renderizar y que la mayor parte de lógica visual debería estar en nuestros View-Models. Siendo estos los que tienen una mayor suit de tests. Fue una charla bastante introductoria.

Dando amor a los tests

Se expusieron una serie de medidas muy sencillas con las que mejorar la legibilidad y mantenimiento de los tests. Casi todo lo que se expuso era ya bastante familiar para los practicantes de TDD. Tips como usar builders, evitar el abuso de mocks, un assert por test, DRY… Hago especial importancia al tema de los SetUp ya que últimamente también me he dado cuenta de lo que Kini nos expuso. En ocasiones, es mucho más valioso para un test que los SetUps estén en el test en lugar de llevárselo a un método de inicialización (SetUp, @SetUp…). Esto es porque el test puede perder demasiado contexto lo cual dificulta su entendimiento.