Mes: octubre 2019

Nuevos talleres para fin de año

De aquí a fin de año tengo agendados dos talleres y en paralelo estoy empezando a diseñar algunos nuevos para el año próximo.

El próximo lunes 11 de Noviembre voy a estar dictando una nueva edición actualizada mi taller de DevOps (más info aquí)

Durante diciembre estaré haciendo una nueva edición de mi taller online de Introducción a Docker & Kubernetes (detalles del temario aquí)

Por otro lado, a partir de algunas charlas y consultas que escuché en conferencias y meetups en los últimos meses, se me ocurrió armar algunos nuevos talleres.

Los nombres al igual que la estrategia de delivery aún la tengo que pulir, pero las ideas las tengo bastante claras:

  • Dev para Ops: unas de las cosas que viene de la mano de las iniciativas de DevOps es el manejo de Infraestructura como Código y junto con ello viene todo un conjunto de prácticas del mundo de desarrollo y de ingeniería de software que muchas veces son desconocidas para la gente que trabaja en cuestiones de Operaciones / Infraestructura / IT. Cuestiones como programación, modularización, abstracción, planificación, versionado, documentación, testing, etc. La idea de esta taller es cubrir estos temas desde una enfoque hands-on teniendo como audiencia a gente de Operaciones / Infraestructura / IT.
  • Git Internals: hoy en día el uso de Git es moneda corriente, pero me parece que la mayoría de los usuarios no sabe cómo funciona Git en detalle, ya sea porque utilizan Git desde algún IDE que oculta los detalles o porque solo utiliza las operaciones básicas. Este taller sería como una continuación de mi Taller de Git que armé hace unos 7 años.
  • Integración y Entrega continua 2.0: estas son dos prácticas de las más populares en la actualidad pero no son prácticas nuevas. Asimismo en los últimos años ha habido una explosión de herramientas de soporte a estas prácticas que se suman al clásico Jenkins. En este taller vamos a explorar los fundamentos conceptuales de estas prácticas junto con diversos criterios para elegir una herramienta y los patrones de implementación más populares.
  • Patrones de desarrollo de microservicios: microservicios es un tema picante y popular y como suele ocurrir con estos temas siempre gente intrigada y confundida. A esto se suma el hecho que un par de clientes me han consultado por capacitaciones en esta temática

Interesados en participar o conocer más de estos talleres me puede escribir por este medio.

Agile, Economía, Tradicionalistas e Innovadores

El clima político que se ha vivido en Argentina desde el comienzo de las campañas electorales me llevo reflexionar sobre las posibles relaciones entre Agilismo y los tan mencionados modelos económicos que tanto han sido nombrados en estos últimos tiempos. Antes de adentrarme más en el tema quiero aclarar que no soy experto en estos temas, sino un simple ciudadano de a pie, cuyas ideas pueden implicar razonamientos erróneos. Hecha la advertencia, avanzo.

Dentro de lo que ha dado en llamarse «Agile» o «Agilismo» hay a mi entender dos corrientes que yo personalmente denomino «los tradicionalistas» y «los innovadores».
Los tradicionalistas son lo que ven los métodos ágiles como literalmente los describe el manifiesto: «…formas mejores de desarrollar software…» y por consiguiente lo aplica puntual y concretamente al desarrollo de software.
Los innovadores son los que tienen una conexión más profunda con el Agilismo y lo aplican en diversos contextos de su vida, excediendo por mucho el desarrollo de software e incluso el ámbito laboral. Yo personalmente me considero tradicionalista pero tengo varios amigos y colegas que sin duda se ubicarían en el grupo de los innovadores.

Para los tradicionalista me parece que no hay conexión entre agile y los modelos económicos.

Pero en el caso de los innovadores sospecho que puede llegar a haber cierta conexión. Los innovadores «van con agile a todos lados» y eso hace que agile se filtre indefectiblemente en la discusión de modelos económicos. Y cuando hablo de modelos económicos no me refiero necesariamente a cuestiones de macroeconomía sino también a cuestiones más del día a día como la forma en que nos organizamos dentro de una organización. Un dato en este sentido: en el meetup de Agiles Argentina suele hablarse con bastante frecuencia de organizaciones horizontales. En contraposición a eso, mientras escribo estas líneas me viene a la memoria una conversación con un colega que me cuenta que está trabajando en un corporación internacional y que están implementado SAFe lo cual me hace pensar que estoy escribiendo boludeces (perdón el término, puede que no suene elegante pero es muy gráfico).

En fin, me cuesta articular argumentos, tal vez porque soy un tradicionalista. Voy a cortar aquí y voy a intentar validar algunas ideas con colegas innovadores a ver opinan.

Continuará….

Un caso de Infra as Code

El manejo de infrastructura como código es relativamente simple cuando la infraestructura es Kubenernetes, pero cuando no es así la cuestión se puede tornar más compleja.

El proyecto en el que estoy trabajando actualmente no utiliza Kubernetes, sino servidores (VMs) con CentOS 7. El front (ember.js) es servido desde un Web Server Apache y el back (java) corre en un Wildfly (jboss). Por otro lado tenemos un SQL Server (el setup de la instancia está fuera de nuestro alcance, pero nosotros nos encargamos de manejar el esquema de datos)

Para manejar todo esto tenemos:

  • Scripts para levantar la VM en la plataforma de VMWare
  • Scripts Ansible para aprovisionar las VMs instalando y configurando Apache, Wildfly, Java, etc
  • Scripts flyway para evolucionar el esquema de base de datos

Estos scripts los utilizamos para administrar 4 ambientes:

  • Desarrollo / Integración
  • Demo
  • Test / Homologación
  • Producción

Adicionalmente a estos ambientes compartidos cada developer tiene una VM (vagrant) local en su máquina de desarrollo, que también es aprovisionada con los mencionados scritps. Este me parece que es un punto central en un esquema de infraestructura mutable: cada developer tiene en su máquina un ambiente para probar que tiene el mismo runtime que el ambiente productivo. Esto no es menor ni tampoco muy común, ya que en general el ambiente del developer tiene un sistema operativo desktop mientras que el resto de los ambientes tiene un sistema operativo server.

De esta forma, más allá de tener versionada la infraestructura, tenemos ambientes uniformes.

Más notas de nerdear.la

A pesar de que la agenda de charlas y workshops del segundo día me resultaba super interesante, estuve en menos charlas y más en el co-working. Sin embargo pude ver la charla de Dr. TDD de Nico Papagna, excelente.

Más allá del charlas creo que el evento estuvo excelente, la organización fluyó muy bien, me parece que se respetaron los tiempos de las sesiones y la conexión a internet me pareció estable y con velocidad apropiada para trabajar. Por cuestiones familiares no pude asistir al día 3, una lástima porque el programa también pintaba de diez.

Quiero felicitar a la gente sysarmy que son los organizadores de nerdearla porque la conferencia se viene superando año a año y a pesar de aumentar la cantidad de participantes, el nivel de conferencia sigue subiendo. Adicionalmente quiero agradecer a @emaraschio que fue mi anfitrión el día que tuve que dar mi charla.

Notas de nerdear.la día #1

A pesar de la copiosa lluvia la asistencia fue impresionante, no tengo idea del número pero había mucha gente. Al momento de finalizar las palabras de apertura el auditorio principal estaba llenísimo. Como orador me sentí muy cómodo, casi un rockstart: acceso al secto vip, escenario elevado y un auditorio con mucha gente para escuchar mi charla. Si bien estoy acostumbrado a dar charlas, el hecho de que el escenario estuviera elevado y que el auditorio fuera tan grande, me generó cierta dificultad para interactuar con la audiencia. De hecho, no tuve interacción hasta el final de la charla cuando le acercaron micrófonos a la audiencia. Una de las preguntas que recibí fue:

«[…] ¿crees que hay alguna componente cultural por la cual no tenemos (en Argentina) la disciplina/orden/coinciencia para hacer test automatizados? […]»

Mi respuesta fue:

Me parece que es una cuestión que tiene más que ver con la mentalidad de los empresarios que con los que desarrollamos software. En Argentina hay algunas empresas que contratan ingenieros para hacer tests pero también hay empresas que contratan psicólogos para hacer tests»

Me parece importante hacer un par de aclaraciones sobre mi respuesta. En primer lugar no tengo nada contra los psicólogos, dije psicólogos en forma genérica para representar gente que típicamente no tiene formación ingenieril. No es que crea que todo el testing deba ser hecho por ingenieros, pero si pretendemos automatizar tests es necesario que parte del grupo de personas que se encargarán del trabajos de testing deben formación técnica/ingenieril.

Aquí están disponibles para descarga los slides que utilicé.

Todas las charlas que vi me parecieron muy buenas pero la que me resultó más interesante fue la de Juan Pablo Borna quien conto varias experiencias de trabajo como Production Engineering en LogDevice/FaceBook.

Más allá de las charlas, dediqué un buen rato al networking, me reencontré con varios colegas que hacía tiempo que no veía.

Para cerrar este post dejo una hermosa postal que vi cuando me estaba retirando de la conferencia.

Charla: Testabilidad y Arquitectura de Prueba

Este jueves 17 de octubre voy estar dando esta charla en el contexto de la conferencia Nerdearla. La cita es este jueves a las 15.10 el Centro Cultural Konex en la ciudad de Buenos Aires.

Nerdearla es una conferencia gratuita que ya tiene varias ediciones. Yo he asistido en años anteriores cuando se realizó en el Centro Cultural San Martín, pero esta vez será mi debut como orador. Más allá de mi participación hay un conjunto de muy nutrido de charlas que incluye temas como Kubernetes, IoT, SRE y seguridad entre otros. ¡No se lo pierdan!

Taller de TDD en UDAV

Ayer estuve haciendo mi Taller de Test-Driven Development en la Universidad Nacional de Avellaneda. Del taller participaron unos 15 alumnos de la carrera de Ingeniería Informática. Personalmente me gustó como salió y me sentí muy cómodo.

Agradezco a @jplagostena y @TefiMiguel por la haber habilitado esta oportunidad y por coordinación, impecable.

Comparto aquí algunas fotos y los materiales: