Primeros eventos del año

Ya casi completando los dos primeros meses del año se va poblando la agenda de eventos. Comparto algunos que tengo en radar.

Campus Party Uruguay es una conferencia con un formato bastante particular: 3 dias inmersivos de charlas, talleres, networking y carpas. Si, literalmente hay gente que durante esos dias dormirá en carpa. Según me han comentado los organizadores esperan tener unos 2500 asistentes diarios y unos 80 oradores. Este evento tendrá lugar en Puntal del Este del 15 al 17 de marzo. En el contexto de este evento fui invitado a dar una charla y un taller.

La semana pasada se lanzó la convocatoria de charlas para la ArqConf, la fecha limité para en envió de propuestas es 15 de Marzo.

Del 10 al 13 de Abril se realizará en Bariloche el Agile Open Camp Argentina, pero la inscripción ya está cerrada.

Esta semana se publicó el sitio del Workshop de Investigadores de Ciencias de la Computación WICC 2019, una conferencia académica donde grupos de investigación presentan las líneas en las que están trabajando. Este año la conferencia se realizará en la Universidad Nacional de San Juan los días 25 y 26 de Abril. El llamado para presentación de trabajo cierra el 10 de Marzo. Con el grupo de investigación de UNTreF tenemos intención de presentar nuestro trabajo.

Del 29/4 al 1/5 se realizará en Nashville, USA la conferencia técnica de la Agile Alliance: deliver agile 2019.

Del 21 al 25 de Mayo tendrá lugar en Montreal, Canadá la XP 2019. Será primera vez que la XP se realizará fuera de Europa. A continuación de la XP, en la misma ciudad y compartiendo 1 día, tendrá lugar ICSE, la conferencia académica más importante de Ingeniería de Software. Será del 25 al 31 de mayo.

Nueva edición del Taller online de Docker & Kubernetes

Nueva edición del Taller online de Docker & Kubernetes

En la última semana estuve trabajando en preparar una nueva edición del taller. El temario será el mismo pero estuve ajustando algunos de los ejercicios y los materiales de estudio:

  • Introducción a Docker
  • Consideraciones para la elección de imágenes base
  • Recomendaciones para la creación de imágenes
  • El ecosistema de herramientas Docker
  • Tecnologías de contenedores más allá de Docker
  • Introducción a Kubernetes
  • Recomendaciones para el diseño de aplicaciones Kubernetes
  • Manejo de configuración con Secrets y ConfigMaps
  • El ecosistema de herramientas Kubernetes
  • Deploy y monitoreo
  • Distribución de aplicaciones Kubernetes con Helm

El taller será los días miércoles a las 20 hs. (hora Argentina, UTC-3). Serán 5 encuentros cada uno de ~90 minutos. La fecha de inicio será el miércoles 20 de marzo. Los interesados pueden preinscribirse aquí (si ya se habían preinscripto para la edición no hace falta que vuelvan a hacerlo, pues ya tengo sus datos y lo contactaré en forma privada).

Notas del workshop de TCR

Ayer por la tarde/noche en la oficinas de Grupo Esfera hicimos un mini-taller exploratorio de test && commit || revert. Fuimos 9 participantes, todos practicantes de TDD. Comenzamos la sesión con un poco de contexto:

  • El código va con tests. No se discute.
  • Los tests pueden hacerse a priori o a posteriori. Podemos debatirlo.
  • TDD implica Test a priori pero Test a priori no implica TDD. Es definición.

En términos formales hay dudas sobre los beneficios de TDD

There’s no convincing evidence that TDD consistently fares better than any other development method, at least those methods that are iterative.

What Do We (Really) Know about Test-Driven Development?
(2018) I. Karac and B. Turhan, in IEEE Software, vol. 35, no. 4, pp. 81-85, July/August 2018. doi: 10.1109/MS.2018.2801554

Algunos autores sugieren que los beneficios de TDD no se deben al hecho de escribir los tests a priori sino al hecho de trabajar en pequeños incrementos:

The claimed benefits of TDD may not be due to its distinctive test-first dynamic, but rather due to the fact that TDD-like processes encourage fine-grained, steady steps that improve focus and flow.

A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?,
(2017) D. Fucci, H. Erdogmus, B. Turhan, M. Oivo and N. Juristo, in IEEE Transactions on Software Engineering, vol. 43, no. 7, pp. 597-614, 1 July 2017.doi: 10.1109/TSE.2016.2616877I.

Dicho todo nos propusimos probar la técnica TCR que propone trabajar en mini-incrementos. Pusimos entonces las manos en el teclado para resolver algunos ejercicios. Lamentablemente nos quedamos cortos de tiempo, pero acordemos agendar otro encuentro para seguir experimentando.

Les dejo un video del propio Beck haciendo un ejercicio al estilo TCR.

Finalmente les comparto aquí un video que hice mientras resolvía la Kata de Chopper que propuse hacer como primer ejercicio del workshop.

Preparación para el taller exploratorio de tcr

Preparación para el taller exploratorio de tcr

El jueves próximo en el contexto de la semana de la agilidad voy a estar haciendo un taller exploratorio de la dinámica tcr (test && commit || revert). Para ejercitar esta dinámica resulta muy conveniente tener algún mecanismo de file watching que (cada vez que modificamos un archivo) se encargue de correr los test y hacer commit o revert dependiendo del resultado.

Durante el taller yo voy a trabajar con Ruby pero el taller se puede seguir perfectamente con cualquier lenguaje, solo es necesario tener Git y un algún framework de automatización de tests (algo de la familia xUnit es suficiente).

Para quienes quieran trabajar con Ruby, armé un setup con una configuración Guard para correr el flujo trc. Está disponible GitHub.

Sobre las Certificaciones DevOps

Sobre las Certificaciones DevOps

El tema certificaciones en el mundo IT siempre ha generado polémicas. Recuerdo que en mis primeros años de universidad estaban muy de moda las certificaciones de Sun, Oracle y Cisco.

Tiempo después se pusieron de moda las certificaciones de Agile. En particular la certificación de Scrum Master se ha vuelto muy popular (y muy debatida).

El año pasado se popularizó una ola de certificaciones de “Agile a Escala” con temas tales como SAFe, LeSS y Nexus.

Ahora me parece que estamos en una nueva ola de certificaciones. En los últimos 10 días recibí dos consultas concretas sobre certificaciones DevOps. Para sorpresa de algunos efectivamente existen certificaciones DevOps, listo algunas aquí:

Yo personalmente no tengo ninguna certificación, ni tampoco ofrezco certificaciones por los los cursos que dicto.

test && commit || revert

Esta es una idea experimental de la cual Kent Beck comenzó a hablar hace un par de meses. La primera vez que escuché al respecto me sonó raro. Ya llevo varias semanas dándole vueltas y me sigue resultado raro pero el hecho de haber estado probándolo me permitió reflexionar sobre mi flujo de trabajo al programar.

Más aún, he estado trabajando en un mini-taller exploratorio de TCR para compartir esta idea y poder destilarla en conjunto con otros practicantes. Voy a aprovechar el Open Space que se realizará en Buenos Aires en el contexto de la semana de la agilidad, los interesados traigan sus notebooks, git y ganas de codear.

No más .dlls en Git: infraestructura de desarrollo .Net

Una y otra vez me encuentro con equipos de desarrollo trabajando con tecnología .Net que guardan .dlls (librerías/packages) en repositorios de código fuente. Esto fue una práctica común en una época (lejana) y que yo mismo utilicé en algún momento. Pero desde la aparición de NuGet la gestión de librerías en en mundo .Net tomó un camino distinto.

Cuando uno tiene una dependencia de una librería a nivel binario, simplemente declara la dependencia en un archivo package.json y la herramienta NuGet se encarga de buscarlo en el repositorio binario y descargarlo. NuGet por default busca las librerías/paquetes en https://www.nuget.org/. Sin embargo hay dos casos donde seguramente no encontremos la librería en este repositorio:

  • Si estamos usando librerías de terceros, puede que por algún motivo esos terceros no hayan publicado el correspondiente paquete en nuget.org y dependiendo del tipo de licencia del paquete puede que no tengamos derecho a publicarlo nosotros mismos en un repositorio abierto.
  • Por otro lado es muy común hoy en día con el auge de los microservicios que uno tenga librerías propias que utilice en diversos proyectos de la organización y a menos que nuestros proyectos sean open source, es poco probable que querramos publicar esas librerías en nuget.org

Entonces, para estos dos casos la estrategia a seguir es utilizar un repositorio privado de binarios ya sea on-prem (instalando por ejemplo un Nexus) o utilizando algún servicio en la nube (como por ejemplo myget).

Si ponemos todo esto en contexto, una arquitectura de desarrollo de referencia podría incluir:

  • Un servidor de repositorios de código fuente, por ejemplo alguna implementación de Git como GitHub, GitLab o BitBucket.
  • Un servidor de CI/CD como Jenkins o TeamCity
  • Un servidor de repositorios de binarios NuGet como Nexus, MyGet o Artifactory