Iniciativa Online: #HablemosDeSoftware

A partir de la actividad “Consultorio DevOps” que hice el martes pasado se me ocurrió armar un espacio recurrente de encuentro y debate: #HablemosDeSoftware.

La idea es conectarnos mientras dure este tiempo de aislamiento para tratar distintas temáticas y compartir experiencias. La participación es abierta y la idea es que cada encuentro este centrado en una temática particular. Algunos de los temas que tengo en mente son:

  • ¿Resulta conveniente hacer TDD?
  • Solo-Programming vs Pair-Programming vs Mob-Programming
  • Sobre cómo Trunk-based development cambiará tu vida
  • Prácticas modernas de desarrollo en aplicaciones legacy
  • Alternativas para implementar CI/CD
  • ¿De verdad hay que automatizar las pruebas?

A esto se suman los temas que los participantes quiera traer.

La propuesta para la semana próxima (martes 7/4, 19.00 hs ARG) es hablar sobre Roles y Estructura de equipo.

El con el siguiente link puedes agregar el evento a tu calendario:

El mejor libro de arquitectura

La semana pasada terminé de leer el libro “Building Evolutionary Architectures” y me resultó posiblemente el mejor libro de arquitectura que lei en mi vida (y eso que he leído varios libros sobre el tema).

Compré el libro porque me atrapó el título y ya había leído otras cosas de los autores. El libro no delira con definiciones abstractas, es muy concreto y el planteo de “evolvability” como propiedad de la arquitectura me resultó muy novedoso y super apropiado en la actualidad. Si bien por momentos me hizo un poco de ruido el tono “grandilocuente” con el que se refiere a los arquitectos corporativos, finalmente me terminó convenciendo el lugar y las responsabilidades que les asigna (que lejos está de lo que suelo ver cotidianamente en la industria).

Algunos otros puntos que me parece vale la pena destacar son:

  • La idea de usar fitness functions para verificar el cumplimiento de ciertas propiedades de la arquitectura
  • ¡Habla de testing! Lo cual no es común en los libros de arquitectura
  • Trata diversas cuestiones de negocio/organización que no siempre están presenten en los libros de arquitectura. Entre estas cosas habla de la estructura de equipo.
  • Toma muy en cuenta la arquitectura física y el potencial acoplamiento que esta puede generar.
  • Cubre cuestiones tanto de green field projects como de brown field projects

Si tienen la oportunidad, bien merece dedicarle un tiempo.

Notas del Consultorio DevOps

Ayer hice la actividad online del Consultorio DevOps y personalmente me parece que fue un éxito. Durante toda la sesión hubo alrededor de 25 personas conectadas. Fueron aproximadamente unos 80 minutos de sesión.

Comencé compartiendo algunas definiciones y estudios académicos y luego largamos las consultas y el debate. Personalmente me gustó mucho como salió la actividad. Me resultó muy gratificante encontrar entre los participantes algunos ex-alumnos y algunos lectores habituales de mi blog.

Le agradezco a todos los participantes y estén atentos porque el martes próximo (7 de Abril) se viene otra sesión (más info en breve).

Consultorio DevOps, una visión académica basada en la experiencia

Algunos post/tweets que escribí con anterioridad sobre el tema DevOps generaron cierta polémica y me llegaron varias consultas. Por ello es que el martes próximo a las 19 horas voy hacer una sesión online sobre DevOps. La idea es compartir una visión académica del tema, algunos casos de estudio y atender consultas. Algunos de los temas/situaciones a tratar serán:

  • “En mi empresa hay “DevOps” pero seguimos con las mismas fricciones del día a día”
  • Por qué DevOps no debería ser un área
  • Cuándo DevOps podría ser un área
  • ¿Qué es un Ingeniero DevOps?
  • ¿Existen los Ingenieros DevOps?
  • Cuándo no (y cuándo sí) contratar Ingenieros DevOps
  • DevOps, Lean y Agile
  • La relación entre DevOps y SRE

A esto se suma todo lo que participantes quieren traer.

Update: el link de conexión lo compartiré por las redes minutos antes de comenzar.

Update2: el link de conexión es: http://nicolaspaez.com.ar/condevops

Preparando el inicio de un cuatrimestre atípico

Hoy comenzaremos informalmente las clases de MeMo2 en Fiuba. Más allá de la cuarentena el cuatrimestre ya venia condimentado con un incidente en el sistema de inscripción que retrasó la inscripción 1 semana.

Si bien el inicio del cuatrimestre se encuentra fijado oficialmente para el 13 de abril, es muy posible dadas las condiciones que terminemos teniendo un cuatrimestre “online”. En nuestro caso particular ya veníamos trabajando con un campus virtual como complemento a las clases presenciales. En esta situación ya tener el campus virtual listo es un punto muy importante en caso de tener que llevar un cuatrimestre online. El campus virtual nos permite compartir materiales, intercambiar consultas y realizar actividades de evaluación (quizzes). También tenemos un canal de Slack para chats compartidos.

Lo que aún no tenemos resuelto es el tema de la video conferencia. Si bien en cuatrimestres anteriores hicimos algún experimento, ninguno resultó completamente satisfactorio. Es por ello que hoy haremos una primera actividad en la que probaremos Google Meet. Hicimos algunas pruebas preliminares y creemos que nos puede funcionar bien. La actividad que haremos hoy será optativa, ya que formalmente hasta el 13 Abril no se puede comenzar oficialmente con las clases. Mañana les cuento que tal nos fue.

Si algún docente está trabajando en mover su materia a un esquema online y tiene dudas puede contactarme por este medio, confío en que puedo dar una mano.

Todos contra master: Trunk-Based Development

Más de una vez me he encontrado con gente sorprendida cuando le comento de esta práctica, por ello quiero compartir algunas reflexiones y explicaciones.

La idea es bastante simple, todo el equipo trabaja sobre un mismo branch todo el tiempo. Siendo un poco más laxos con la definición es posible trabajar sobre distintos branches en la medida que dichos branches no vivan más de 1 o 2 días.

La práctica de Trunk-Based Development va muy en línea con la practica de integración continua la cual, como su nombre lo indica, propone integrar el producto en forma continua mínimamente 1 vez al día. Desde la perspectiva de integración continua uno podría trabajar en distintos branches pero al fin del día uno debería integrar todos esos branches. Esto no es opinable ni discutible, es una definición. Puede gustar o no, pero es así como la práctica fue definida hace ya ~20 años. El punto es, no podemos decir que hacemos integración continua si estamos escribiendo código en distintos branches por varios días. En todo caso podemos decir que hacemos integración frecuente o esporádica, pero no continua, lo cual no tiene nada de malo.

Ahora bien, cuando uno piensa en hacer Trunk-Based Development surgen una serie de preguntas sobre cómo manejar diversas situaciones. No voy a entrar en detalle sobre esas diversas cuestiones, simplemente les voy a recomendar este excelente libro de Paul Hammant: https://trunkbaseddevelopment.com/book/.

Adicionalmente a los consejos de Hammant voy a compartir un conjunto de prácticas/premisas que yo suelo utilizar en conjunto con Trunk-Based Development.

  1. En primer lugar hablamos de un equipo chico, no más de 6 o 7 personas commiteando.
  2. Al mismo tiempo ese equipo chico trabaja en un pieza chica, un bounded context o un microservicio. Eventualmente puede trabajar en varios bounded context pero cada uno en un repositorio separado.
  3. Todo el código se escribe en pairing o mobbing, lo cual reduce la cantidad de cantidad de commits.
  4. Todo el código se escribe haciendo TDD, lo cual colateralmente genera una alta cobertura que funciona como una red de seguridad cuando están entrando varios commits sobre el mismo branch.
  5. Las funcionalidades están cortadas en “pequeñas fetas”, esto permite trabajar en pequeños incrementos que pueden completarse rápidamente (1, 2 o 3 días máximo).
  6. Ante cada commit, se integra el código, se buildea y se corren pruebas unitarias, se despliega a un ambiente compartido y se corren pruebras de aceptación. Si todo esto va bien, estamos en condiciones de ir a producción.

Se que algunos de estos puntos pueden resultar polémicos, incluso más polémicos que Trunk-based Development, pero esto es lo que a mi me suele funcionar. No digo que estoy vaya a funcionar en todos los contextos, pero creo que para descubrirlo hay que probarlo.

MeMo2: materiales de estudio para ir adelantando durante la cuarentena

Para aquellos alumnos inscriptos en MeMo2 para este primer cuatrimestre de 2020 que quieran ir adelantando algo de trabajo les comparto aquí algunos materiales de estudio que utilizaremos en la materia:

Si algún alumno estudia todos estos materiales y quiere adelantar más, no dude en contactarme.