Notas de mi primer Codemotion

Es uno de los eventos para desarrolladores por antonomasia al que me apetecía ir desde que conocí de su existencia allá por la tercera edición. A la quinta fue la vencida y así fue la experiencia

Seguramente no seré el primero en escribir sobre Codemotion 2016, ni creo que sea el que más tenga que aportar, pero quería hacerlo por dos razones. Por ser la primera vez que disfruto de la experiencia, y por darles las gracias a toda la gente que hizo posible el evento.

Empezaré por lo segundo.

Poder disfrutar del conocimiento y las experiencias de tantos y tan buenos compañeros de profesión es un lujo que no siempre valoramos como se merece. ¿Que hubo charlas mejorables? Pues claro, es normal. ¿Que te decepcionó algún ponente o sesión? Elemental, querido Watson. Es gente con las pestañas quemadas de picar código, que sacan ratos de donde no los tienen para prepararse una presentación y contarte temas que seguramente dominan mucho más de lo que a veces transmiten. Es que no es fácil. Invito al que quiera a hablar del tema del que se sienta más experto, a que lo haga ante 100 personas entre las que puede haber grandes expertos en la tecnología que esté abordando. Impone, y mucho.

Así que, desde aquí mi especial agradecimiento a todos los que han dedicado tiempo, esfuerzo y dinero (los churros de Modesto San Juan para desayunar el sábado fueron todo un detalle) para preparar sus temas y compartirlos con nosotros. Les admiro por ello y los considero un ejemplo a seguir.

Volviendo al evento en sí, mis objetivos iniciales de aprendizaje giraban en torno a Progressive Web Applications (PWA) y Polymer, todo lo que pudiera coger de software craftmanship, algo de machine learning, con la boca pequeña, la verdad, pues estoy lejos de poder hacer algo serio, Big Data, aprender los conceptos de React/Redux/Flux, Groovy, algo de DevOp, por supuesto temas relacionados con Java y tenía especial interés en CQRS y event sourcing.

Como supongo que suele ser habitual, seleccioné charlas por encima de mis posibilidades, y habría tenido que desdoblarme astralmente para poder asistir a todas las que elegí, pero es un síntoma evidente de que había cantidad y calidad, algo que se agradece. Sí tenía claro que no quería perderme la charla de Carlos Ble, ni el cierre de David Bonilla, y que daría preferencia a las charlas que no se iban a grabar, dejando para un visionado posterior las de otros grandes de la España techie, como Joaquin Engelmo Moriche no-hablando de testing y Jorge Barroso y su charla con el sugerente nombre de Time to grow up, imprescindibles desde mi punto de vista.

Lo primero que recomiendo es ir en compañía y si puedes compartir charlas, mucho mejor. Enriquece mucho comentar los temas escuchados en los descansos y las networking beers ganan muchos enteros. En mi caso tuve la suerte de juntarme con dos cracks, uno de ellos conocedor de otros codemotions, que nos dio un paseo previo por las instalaciones para conocer la ubicación de los tracks y contarnos los entresijos del evento.

Desvirgué el Codemotion con Yerai Darias dándole caña a JMX, una tecnología de la que había leído, pero que no había visto en acción. Se quedó algo corta, pero nos permitió ver lo esencial y saber hasta qué punto podíamos utilizarla en nuestro día a día.

Pasamos después a conocer lo esencial de progressive web apps con Polymer, explicado de forma muy clara, sencilla y amena por Víctor Sánchez y Gloria Bueno, aunque se me quedó algo básico, pero entiendo que tenian un taller posterior en el que seguramente entrarían en harina.

Pasadas estas primeras charlas pude disfrutar de una de las cosas más valiosas del codemotion: la ‘conversación’ que se crea entre lo que aprendes en una ponencia, las ideas que intercambias al terminar con los compañeros sobre su aplicabilidad en el día a día, y cómo se enriquecen esos conocimientos con nuevos enfoques y matices en charlas posteriores sobre el mismo tema. Aunque pueda suponer un coste de oportunidad, recomiendo elegir un tema de mucho interés para tí y tratar de asistir a dos charlas que lo traten. A mí me pasó con el event sourcing, que desconocía, y quedé gratamente sorprendido tanto por el concepto, genialmente explicado por Emma Sesmero en su charla Mantén tus datos ágiles con event-sourcing, como por el caso practico visto en Akka persistence, CQRS/ES y otras siglas del montón, de Javier Santos. Ambos se complementaron maravillosamente bien colmando mis ansias de conocimiento. Chapó para ellos.

En mi cuarta charla, sobre aplicaciones isomórficas con React, he de reconocer que me equivoqué de lleno, precisamente por lo contrario a la de PWA. Es cierto que no me fijé en la etiqueta Advanced del detalle de la agenda hasta después, y fue muy advanced cuando yo necesitaba algo más intermediate. Lo que más me dolió fue perderme la charla de Jerónimo López hablando de JMH, que además no se grababa, y errar en la elección respecto a la otra charla de React que se daba a esa misma hora en otro track. Lección aprendida: mirar el nivel de las charlas antes de elegir, sobre todo en temas en los que eres un zoquete.

Cosas de ‘solucionólogos’ y otros consejos interesantes

Ya por la tarde del viernes disfruté de uno de los tesoros de este año, aprender cómo trabaja el mismísimo Carlos Ble, mientras nos enseña a mejorar la forma en que afrontamos las necesidades de nuestros clientes, todo ello condensado en su charla Aprender a distinguir el problema de la solución.

Nos contó que nos acercásemos más al usuario, que observásemos cómo trabaja, que hablásemos con él e identificáramos sus problemas reales. A veces pecamos de ser solucionólogos y pasamos de soslayo por el problema, lo cual se agrava porque en demasiadas ocasiones, la persona del cliente que nos traslada las necesidades del usuario es otro técnico y te propone soluciones en lugar de contar los problemas del que utilizará nuestro software. Nos propuso profundizar en el problema a la par que convencíamos a estas personas para que nos hablasen de su necesidad, que ya le llegaría el turno a la solución. Es un enfoque muy cercano al design thinking, del que me confieso seguidor.

También nos aconsejó que si no tienes tiempo de conocer qué es lo que el usuario quiere, es mejor ofrecer una solución más abierta que otra más cerrada. Cuando el usuario vaya dando feedback, será más fácil cambiar tu sistema y adaptarlo a lo que realmente necesita.

Y por supuesto evita añadir complejidad accidental o innecesaria. Hazlo todo sencillo. Nos encanta meter cosas nuevas, para aprender cómo funcionan… incluso a costa del cliente, pero esos artificios en el futuro nos pasarán factura. O bien hacer optimización demasiado pronto. Tiempo tendrás de hacerlo.

Por último, me quedo de su charla con una perla que algún día me gustaría aplicar. Nos contó los valores que tienen en Codesai, la empresa de la que Carlos Ble es CEO, lo cuales revisan a menudo y trasladan a sus clientes para que conozcan su propuesta de valor y de paso, para que les dejen trabajar tranquilos. Brutal ejemplo para todo aquel que quiera dedicarse a trabajar con calidad para otros.

Terminaba el primer día y aún pude destilar un par de elixires de los buenos, como el argumento que nos trasladó Luis Orlando en Big Data para Javeros con Apache Flink. Muchas veces nos encandilamos con nuevos lenguajes, metodologías o paradigmas y nos encanta trabajar con trending-tech-hypes , pero puedes terminar ahogándote en un lenguaje o framework desconocido y usado sólo por los más frikis. Luis recomendó ser prácticos y buscar herramientas más cercanas a tu catálogo de recursos en los que te veas seguro y que además haya una comunidad amplia y activa detrás para echarte una mano. Como es el caso de Java y Flink para hacer BigData.

De la charla de RESTful API del montillano Jesús Espejo Hidalgo, me quedo con el pragmatismo del ponente y de su enfoque. Yo, que soy defensor y divulgador de las best practices y los estándares, y que he caído demasiadas veces en el dogmatismo, aprendí que muchas veces nos cerramos en banda ante las digresiones sin pensar si la rebeldía está justificada o no. Ser un talibán de cualquier tema no es bueno por definición y, como oí en varias charlas, hay que conocer y dominar el dogma para llegar a ser un buen pragmático. Tomo nota.

Segundo día y arrancamos por todo lo alto

El sábado, comenzamos desayunando churros con otro grande de España, Modesto San Juan, del que tenía referencias por Twitter, pero al que no seguía ni había visto antes, la verdad. En esta charla, la casualidad sentó a nuestro lado a Joaquín Engelmo, y a su lado, a Jerolba. Ver tanto talento en tan pocos metros cuadrados y con tanta cercanía, me llegó hondo.

Aprovechando la coyuntura, estuvimos charlando con @Kinisoftware sobre testing y TDD, por unas dudas que me quedaron tras una charla suya a finales de la pasada primavera en las oficinas de tuenti. Un regalo inesperado del codemotion.

Modesto San Juan, aparte de churros, repartió conocimientos y vivencias con gran maestría y lucidez. Tomó como punto de partida el lema central de la camiseta que nos entregaron el primer día, la deuda técnica, y nos contó cómo desarrollar para nuestro yo del futuro.

Habló de Integración Driven Design, una evolución de DDD que tendré que investigar, y nos contó cómo hacer expresivos los nombres de los elementos de nuestro codigo: clases, paquetes, etc. Me resultó curioso el enfoque de tener una clase para cada operación realizada (EditCustomer.cs, GetCustomerDescriptions.cs, etc.), cuando uno de los compañeros de Codemotion me comentó que ellos lo usaban en sus desarrollos Java basados en arquitectura hexagonal, me hizo pensar que tengo otra tarea pendiente, aunque sólo sea documentarme.

Me encantó la comparativa entre STUPID y SOLID que se auto explica con la diapositiva que usó:

Nos lanzó una recomendación sobre la infraestructura que usamos, diciendo que debíamos referirnos a ella con nombres más orientados a negocio, es decir, no hablar de Oracle, sino del servicio de búsqueda en nuestro catálogo o el servicio de almacenamiento de expedientes, etc. Interesante enfoque este de poner en el centro aquello que da valor al usuario, no al desarrollador.

Hablando de tests incidió en un tema ya escuchado en otra charla, aunque con un enfoque más proactivo. Dijo que hay que trabajar el pragmatismo conociendo el dogmatismo. El dogma te lleva a hablar y hacer TDD, FIRST, AAA, SUT y el pragmatismo te lleva a hacer testing de forma apropiada.

Antes de irnos a comer, le tocó el turno al testing con Andrés Viedma y quedé cconvencido de por qué usar Spock en lugar de JUnit / Mockito para mis tests Java. Hay que reconocer que, aparte de facilitar la cada vez más necesaria verbosidad de las pruebas, permite usar mecanismos habituales en las pruebas, como tests repetitivos en función de parámetros o el uso de mocks, con mucho menor esfuerzo que en JUnit. Habrá que probarlo.

Después, y en la misma sala, Rafa Alonso nos mostró la solución que han desarrollado para hacer pruebas desde la interfaz gráfica, ofrecida como código abierto y basada en Selenium. El valor de lo que han hecho está en que se puede probar con Java, sin tener que recurrir a Selenium Driver. Si no tienes la posibilidad de disponer de un grupo de QA, échale un vistazo porque puede venirte muy bien.

Por la tarde del sábado llegó la hora de las redes neuronales, un tema en el que he empezado a adentrarme gracias a un compañero, que me ha metido el gusanillo en el cuerpo, y al curso de Andrew Ng en Coursera que espero terminar algún día, cuando pasen los apretones actuales. De esta charla saqué dos consejos y un enlace. Las recomendaciones de Gema Parreño parecen triviales pero tienen pinta de que te van a ahorrar muchos disgustos. El primero, que antes de hacer aprendizaje automático debes contar con una buena arquitectura de datos, y el segundo, que nunca hagas un deep learning para empezar, es mejor entender bien una regresión lineal o una support vector machine e implementarla, y luego dar el salto. Respecto al enlace, Gema nos recomendó un sitio para arrancar desde cero con Tensorflow, que todo sea dicho fue la aplicación que me enganchó a esto del machine learning allá por noviembre del 2015.

Tras eso llegó mi momento frontender del Codemotion, tras el chasco de React. De la charla de CSS escalable y mantenible, muy bien presentada por Sergio Álvarez, constaté que aunque un backender como yo se meta en berenjenales front, con los que he aprendido mucho, la clave está en tratar de hacerlo bien y buscar, como siempre, las buenas prácticas, así que tampoco lo hemos hecho tan mal. Aprendí en la charla que hay que tener cuidado con los selectores por identificador y que es mejor hacerlo con clases y atributos. Y sobre un tema que siempre me ha parecido crucial, el ponente recomendó usar BEM (Block Element Modifier) como convención de nombrado de clases CSS, así como una estructura organizada de directorios para las hojas de estilo y, y aquí sí que hemos flaqueado, usar clases diferentes para temas de estilos de otras para ejecutar acciones JavaScript.

Un viaje inesperado

Se acercaba el final del evento y, no sé si por el cansancio o por el destino, nos equivocamos de track y nos perdimos la charla de Iván López sobre Groovy. A cambio pude disfrutar de The Developer Journey, una charla en la que se trataron temas muy interesantes con mucha experiencia detrás, aunque quizá se intentaron cubrir demasiados asuntos sin profundizar suficiente en ellos.

Por mi parte, y dado que en los últimos tiempos he estado tratando temas de refactorización de aplicaciones de código legado, me quedé con varias frases interesantes de los dos ponentes:

Hay que eliminar el miedo a cambiar las cosas.

Es fundamental alcanzar una mentalidad colectiva sobre la refactorización.

Junto a esas dos perlas me anoté la tarea de investigar las razones que frenan la refactorización en aplicaciones que lo están pidiendo a gritos, para tener herramientas para combatirlas cuando me toque.

Y cerró David Bonilla, al que sigo desde hace años en su newletter semanal pero que nunca había visto en vivo. Las pasó canutas con los problemas de visualización de las diapositivas lo que, junto al anuncio de inversión en su empresa, afectó algo al foco de la charla, aunque considero que no a su mensaje, algo con lo él mismo no estará de acuero, a tenor de lo concomentado al día siguiente en su bonilista.

De su charla me quedo con la idea de volver a dar a las bases de datos la relevancia que se merecen. En los últimos tiempos, con ORMs, APIs de persistencia y otros artefactos, hemos querido soslayarlas pero están ahí, y son un elemento importante de nuestras soluciones.

He de reconocer que cuando ficharon a David Bonilla y su equipo de Otogami/Runnics en 8kdata para trabajar en su producto ToroDB, me pareció que entrar en un mercado como el de las bases de datos, cubierto por demasiados buenos actores tanto de software propietario como de código abierto, era una locura, pero nunca me había planteado la cantidad de bases de datos que existen en el mercado y la cantidad de pasta, y de datos, que mueven. Un mercado enorme en el que quizá no sobren actores, la verdad.

Esas son las 15 charlas que presencié en mi primer Codemotion, aunque no terminó ahí la cosa. Ya he logrado ver 7 presentaciones más en vídeo y tengo apuntadas otras tantas que no me perderé, cueste lo que cueste. Y si puedo, hay otras 20 más que quisiera ver aunque se me junten con la siguiente edición. Por otro lado, al lunes siguiente nos reunimos los dos codemotioner del equipo con el resto y estuvimos intercambiando ideas y proponiendo cosas a aplicar en nuestro trabajo, algo que hacemos a menudo, pero pocas veces con tanto contenido. Y además me llevo una lista de temas para profundizar, de buenas prácticas para aplicar y de consejos a seguir que en esencia me harán ser mejor profesional.

Para concluir, quiero darme un tirón de orejas. A veces caemos en el simplismo de pensar que de cada charla solo se sacan un par de ideas, pero si eso fuera cierto y me dieran un folio con 15 títulos y dos frases por título, una por cada idea de cada charla, a cambio de asistir al evento, no lo tomaba ni por asomo. Lo que da valor a esas dos ideas en primer lugar es que las destilamos cada uno de nosotros, en base a lo que sabemos y a lo que creemos que podemos hacer con ellas. Seguro que mis dos ideas no coincidirían con las de mi vecino en la grada. Pero también aporta mucho valor al mensaje el envoltorio que cada ponente le da, cómo lo contextualiza, cómo lo adorna o lo simplifica, cómo logra inspirarte o cómo logra derribar barreras mentales que tenías cuando entraste por la puerta. Eso, querido lector, es oro puro, así que te recomiendo asistir a la próxima edición, porque artículos posteriores como este, sólo nos sirven a los que los escribimos.

Gracias por vuestro tiempo y no dejéis de revisar los vídeos de las últimas ediciones e inscribiros a la próxima, no os decepcionará.