Resumen 2019

Termina el 2019 y es tiempo de echar un ojo a lo que me ha pasado durante este año.

PuraVida Software

Una de las cosas más difíciles de explicar a aquellos que no me conocen (y a muchos que sí) es mi perfil profesional, sobre todo por la existencia de PuraVida Software.

PuraVida Software es una empresa como tal, con su CIF, razón social, etc que creé hace ya unos 10 años y con la queofrecía mis servicios como desarrollador. Sin embargo, durante este tiempo han surgido proyectos interesantes donde,por las razones que fuera, la empresa prefería tener a alguien en nómina por lo que digamos de alguna forma PuraVidaSoftware pasaba a estar "congelada". Sé que esto a veces genera cierta desconfianza porque da un aire de temporalidadpero si lo piensas bien, en nuestro sector lo único que hace que algo sea duradero es que el proyecto sea interesantey apoyes a la gente que participa en él, no la figura jurídica que se adopte.

Por otra parte, independientemente de la situación fiscal de PuraVida Software, yo he seguido usandosu paragüas para seguir haciendo aquellas cosas personales que me apetecen, como:

• publicar proyectos OpenSource

• patrocinios de comunidades como @MadrigGUG

• sponsors de eventos como @Greachconf

• charlas en diferentes eventos

• etc

La Q en QA

Este año he tenido la suerte (?) de poder trabajar en un equipo multidisciplinar como integrante del QA (quality assurance)y sufrir en mis propias carnes la poca valoración que se ha tenido (he tenido) a esta parte del desarrollo.

El proyecto era para una mega-empresa en un mega-proyecto con decenas de equipos que tras dejar atrás el monolito yase habían adentrado en el agile y con sus más y sus menos iba dando sus frutos. Tras probar diferentes organizacionesahora tenían grupos (pods que dirían los spotiferos, creo) con front, back, qa, su product owner, etc

Mi participación en este proyecto tenía una fecha fin muy concreta, de 3 meses, y como objetivo el intentar ver en quéforma podía ayudar a los QA a mejorar como reutilizar scripts, mejorar el uso de SoapUI, documentación, y cosas asía la vez que hacía labores propias del QA.

De este período creo que debería acuñar el término "Síndrome del último mono" o del QA que asume que su papel es probarlas mierdas de los otros. Un QA debe hacer ver al resto del equipo que TODO debe pasar por ellos: desde que se estáhaciendo la planificación, mientras se está desarrollando las funcionalidades, hasta que se hace la demo al productowner. Y esto lo tiene que hacer ver desde el minuto cero.

Básicamente en todos los pods he visto que sólo se cuenta con los QAs para las pruebas finales, con escaso tiempo antesde la entrega y que estos lo asumían como algo normal.

La Q de QA significa Calidad. Si quisieramos que sólo se dedicaran a hacer test los llamaríamos TA.

A título personal lo que sí les diría a los QA es que dejaran a un lado el maldito SoapUI que es el chocolate del loro.Mediante un interface gráfico (bastante feo) y a base de cajitas te hacen creer que estás automatizando tareas de testy lo que estás es cavando en un agujero donde no existe la reutilización ni el compartir. Refuerza a tus QA enprogramación (sobre todo en Groovy que es perfecto para este entorno), obligales a usar Git y que sean parte de loscode review y que automatizen todo. Si además consigues que dejen de lado Confluence como sistema para documentarsabrás que estás en el camino correcto

| | Si estás pensando que la solución es NO tener el equipo QA y delegar en el equipo, no te preocupes también tengoalgunos cachitos de historia que contar delante de unas cervezas. |

La K de Kubernetes

Después de estar jugando con la idea de Kubernetes, y una vez que Docker para lo que yo lo necesito estáen mi día a día, este año he decidido dar unos primeros pasos con él.

Muy temerariamente estuve "asesorando" a una empresa amiga que se estaban moviendo hacia k8s, siempre conscientes deque eran nuestros primeros pasos. Por suerte no sólo contaban con mis nulos conocimientos sino que los estabanhaciendo de la mano de una empresa de servicios con experiencia en el tema.

Por mi parte estuve probando a desplegar alguna de mis ideas en diferentes plataformas: Digital Ocean, AWS Fargatey Google Cloud. Me puse un presupuesto limitado de unos 10-15 euros al mes que pocas veces superé (creo que rondaronlos 10€) durante los 3 ó 4 meses. Con diferencia, para lo poco que sabía me quedaría con Google Cloud

Sin embargo, tras una charla de @pchico83 y @micael_gallego en el @CodemoMadrid sobre @oktetohq he descubierto unaplataforma perfecta para el aprendizaje de Kubernetes. Con sólo una cuenta en Github para identificarte disponesde un cluster con 5 namespaces, 8GB en cada uno para desplegar tus servicios.

| | Tanto como con Docker (y tantas herramientas) antes de usar un entorno gráfico utiliza la línea de consola.Kubernetes tiene kubectl y te permite administrar todos tus cluster desde la línea de comando. De esta formaaprenderás los conceptos y sufrirás todas las dificultades existentes para saber valorar luego qué aportan todala pléyade de herramientas que hay alrededor |

La B de Bots

Algunos piensan que este año ha sido mi año de los Bots (de Telegram). Razón no les falta. Lo que empezó como unapataleta por una prueba de código a una oferta de trabajo fallida me llevó a publicar unos 5 bots,un par de canales de Telegram y un plugin para Gradle Social Network (el cual había creado a finales del 2018pero ha sido este donde lo he usado de forma intensiva)

El bot de las cámaras de tráfico de Madrid, el de Barcelona o el de Granada, el localizador de fuentes públicas,en este verano tan caluroso, para Madrid, Barcelona, Granada y Cáceres, o el de los precios de las estaciones deservicio (gaolineras) con un sistema de diálogo un poco más elaborado han aportado, sin ser ninguno nada del otro mundo,muchas cosas para la mochila (material para charlas, conocer gente, descubrir nuevos canales de negocio, …​)

Tal vez de las cosas más interesantes que ha surgido de este tema, ha sido ver cómo @garciolo le gustó eldataset de las fuentes públicas y como no lo encontrábamos para Granada se hizo un repositorio Github y geolocalizóun buen número de ellas "a mano"

La C de Charlas

Echando la vista atrás he visto con sorpresa que este año no he presentado ninguna charla a @MadridGUG. Si biensoy consciente de que tras las vacaciones de verano me dije de apoyar a gente que querían dar alguna en lugar depresentarlas yo, creía que al principio de año habría dado alguna.

Tengo varias ideas que me rondan:

• Cómo hacer una app micronaut-desktop y controlarla vía web, al estilo de Torrent

• Revisar la prueba conceptual que hice de Micronaut y Ethereum y mostrar cómo unir Java con blockchain

• Primeros pasos de Kubernetes en Okteto

y alguna otra que todavía no tienen forma

A cambio de no proponer nada en @MadridGUG he tenido otras experiencias bastante interesantes:

En Mayo me despierto con un mensaje de Picolini, @francjp, proponiendome dar una 1/2 charla para un Meetup "la semana que viene sobre el tema que tú quieras". En estos temas si me tocan las palmas pues yo bailo así que le propuse "DocAsCode, una aproximación a la documentación contínua" algo sobre lo que luego hablaré. En su inconsciencia Fran pretendía llevar a dos ponentes para dos charlas cortas (de ahí lo de 1/2 charla) y obviamente al final tuvo dos charlas megalargas.

El tema de DocAsCode me tiene muy enganchado desde que descubrí @asciidoctor y personalmente me sentí muy cómodo con la charla pues además da muchas posibilidades de meterse con Word y Confluence. Señal de que no fue mal es que un par de asistentes, al terminar, me comentaran que les había parecido muy buena por hablar de un tema que nadie habla.

Tras ver un tweet de @jjmerelo anunciando que el C4P para @esLibre_ (conferencias sobre Software Libre en Granada) estaba abierto creo que dude 1 minuto en enviar la propuesta de "OpenSource para un mundo OpenData" y un poco después la de "DocAsCode". La verdad es que me apetecía salir de Madrid (visitar las provincias) y era una excusa perfecta. El proceso abierto, usando Pull Request de Github, tanto de enviar como de aceptar las charlas me encantó y creo que otras comunidades deberían plantearselo.

Ahora me doy cuenta que tenía que haber hecho un resumen en aquel momento más detallado de las charlas que asistí pero recuerdo a dos chavales de no más de 25 años hablando sobre Inteligencia Artificial y Programación Cuántica que me hicieron sentir muy viejo a la vez que ilusionado. También recuerdo el debate sobre el estado del OpenSource en España de miembros muy activos de este movimiento (confieso que a muchos de ellos los tuve que buscar después, pero eso es porque no soy de quedarme con los nombres)

De mis dos charlas la verdad es que no salí todo lo satisfecho que me hubiera gustado, probablemente por culpa del troll que llevo dentro:

• En la de OpenData me sentí como que estaba fardando de lo que había hecho con los datos abiertos del Ayuntamiento de Madrid, cuando nada más lejos de la realidad. Mi intención era "si un programadornormal como yo puede hacerlo, cualquiera puede. Sólo hay que echarle tiempo y ganas"

• La de DocAsCode creo que podría haberla hecho más amena o tal vez es que la comparo demasiado con la que había dado en el Meetup. En cualquier caso sí dió para discutir sobre ello con un par de interesados así que me quedo conque el tema tiene mucha chicha que contar

Por último @CodemoMadrid me confirmó que la charla de "OpenSource para un mundo OpenData" había sido elegida ytras la experiencia de haberla podido dar en @esLibre_ pude replantearla y personalmente salir muy satisfecho. Después de la charla pude hablar con un par de personas sobre ella y creo que algo de inquietud en el tema sí caló.

Otra K de Kanban

Llevo unos pocos meses en un equipo de trabajo donde se usa Kanban y la verdad que no está mal. Focalizar el esfuerzoen tirar de los tickets en lugar de empujarlos, sin sprints sino con entregas cuasi-contínuas y cosas así hace que si las cosas van medio bien uno se sienta productivo

Sin embargo, por mucho que quiera, Kanban no se escapa a la constante universal de que negocio te impondrá siempre lo urgente por encima de lo importante

Resumen

Aunque no lo creas, este post había tenido una versión previa muchísimo más negativa y pesimista. Este año, como tantos otros, ha tenido sus "palos", sus cosas malas, decepcionantes y desagradables y me encontré escribiendo sobre ellas más que sobre lo que el año me había aportado.

Sin saber nada de medicina sospecho que debemos de segregar algún tipo de compuesto químico que nos produce cierto placer, un revolcarnos en el barro, un cavar en un hoyo, que nos impide levantarnos y seguir adelante. Por suerte @montalegos estuvo al tanto y tras su revisión lo he reescrito. Con ello no quiero tapar las cosas "malas" y sólo mostrar las buenas sino que, partiendo que principalmente escribo para mí, opto por estas antes que por aquellas

A diferencia de otros referentes que tengo, yo no hago planes para el año que viene, lo más a 3 meses vista por lo que por ahora sólo tengo como tema a hacer el Workshop sobre Bot que voy a dar en el @Greachconf 2020. Son 3 horas y en inglés, por lo que las risas y momentos difíciles están asegurados