Mes: febrero 2022

Seminario de Postgrado en Software Delivery (3º edición)

La semana pasada confirmamos la realización de la tercera edición del Seminario de Postgrado en Software Delivery de UNTreF.

Este seminario está centrado en el proceso de desarrollo y entrega de software,cubriendo diversas prácticas tanto a nivel técnico como de gestión. El contenido está estructurado sobre la base de un conjunto de estudios formales y casos de estudio en torno a organizaciones de alto desempeño. En especial se destacan las ideas desarrolladas por Forsgren, Humble y Kim en su libro ​»Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations» (IT Revolution, 2018)​.Los objetivos del seminario son:

  • Entender el impacto de las capacidades de Software Delivery en la performance del negocio
  • Entender las prácticas técnicas y de gestión que mejoran la performance de delivery
  • Conocer posibles estrategias para la adopción de las mencionadas prácticas

El seminario está destinado a:

  • Profesionales de la industria (independientemente de su rol) que pretendan mejorar su práctica de software delivery
  • Docentes e investigadores que se desempeñen el temás de ingeniería de software y quieran familiarizarse con en el estado de la práctica de software delivery

Vamos a mantener el mismo formato que la edición anterior, eso es: una duración calendario de 3 meses, con un encuentro online de 150 minutos cada 15 días. Esto hace un total de 15 horas de clase repartidas en 6 encuentros. A esto se se suman otras ~40 horas de estudio/trabajo fuera del aula (algo así como unas 3 horas de trabajo constante todas las semanas adicionalmente al tiempo de clase). Las fechas de los encuentros serán:

  • 2022-04-13
  • 2022-04-27
  • 2022-05-11
  • 2022-05-25
  • 2022-06-08
  • 2022-06-22

Siempre en el horario de 9:30 a 12:00 (hora argentina, GMT-3).

Una de las novedades esta edición es que estaremos sumando al Lic. Diego Marcet al equipo docente.

Si bien el seminario se dicta en el contexto de una universidad nacional que ofrece carreras de grado gratuitas, este seminario es pago (como suele ocurrir con las actividades de postgrado). En esta edición el costo rondará los AR$ 10.000, digo rondará porque es una cuestión que me excede, yo no manejo esta recaudación ya que tengo un sueldo fijo que me paga la universidad por ser empleado permanente. De todas formas, siempre tramitamos algunas becas, principalmente destinadas a docentes y empleados de organismo públicos.

El día 23 de Marzo a las 9:30 haremos una charla abierta de presentación del seminario para todos los interesados los cuales deben registrarse aquí para que les compartamos el link de acceso. Adicionalmente a esta reunión, aquellos que quieran saber más sobre este seminario pueden encontrar algunos artículos en mi blog bajo la etiqueta seminario-sd y obviamente siempre pueden escribirme en casos de más dudas.

Highlights sobre el libro «Test-Driven Development By Example»

Esta semana terminé de releer este libro fundacional de TDD. Como ya mencioné no estoy convencido de que sea el punto de entrada más apropiado para aprender TDD, pero sí estoy convencido que todo practicante de TDD debería leerlo.

Personalmente creo que es un libro para leer de punta a punta, sin los capítulos de la tercera parte de libro tratan sobre patrones y se pueden leer en forma descolgada a modo de consulta, los capítulos de las dos primeras partes están dedicados al desarrollo de dos ejemplos en profundidad que luego son referenciamos en los patrones de la tercera parte.

El libro trata ciertas cuestiones de TDD que muchas veces se pasan por alto, algunas veces se las menciona a la pasada y otra vez ni siquiera se mencionan. Algunas de estas cuestiones que me parece vale la pena destacar:

  • El trabajo en forma iterativa y en pequeños pasos es realmente central a TDD. Beck habla de ciclos de 10 minutos (pag. 143).
  • Es completamente válido retroceder para avanzar, si llegamos a un punto donde estamos integrando nuestro código y vemos que hemos roto algo, puede resultar conveniente tirar lo hecho y comenzar de nuevo (pag. 149). Como estamos trabajando en incrementos realmente chicos, lo que vamos a estar tirando no es mucho, es solo el último incremento. Esto lo veo muy relacionado a la técnica Test and Commit or Revert.
  • La técnica «Log String» (pag. 146) es increíblemente simple y útil a la vez que definitivamente le voy a dedicar un artículo exclusivo.
  • Para el programador el código de test es tan importante como el código de dominio. Esto está mencionado de distintas formas a lo largo del libro y como consecuencia de esto no es raro que la cantidad de código de test sea similar a la cantidad de código de dominio. Asimismo el uso de patrones de diseño aplica tanto al código de dominio como al código de test.
  • Si bien el flujo de trabajo es codear un test a la vez, Beck recomienda comenzar la sesión de programación haciendo una lista de los casos que intentaremos cubrir durante la sesión (pag. 126). Esta lista también la utiliza para registrar casos/situaciones que puedan ir surgiendo durante la sesión sin perder el foco de trabajo: estoy trabajando en un caso, surge una idea, la anotamos en la lista y seguimos con los que estábamos (pag. 137)
  • A la hora de escribir los tests puede resultar conveniente comenzar por escribir el Assert (pag. 128)
  • Refactorizar es fundamental, no es posible hacer TDD sin refactorizar y una de las principales razones (o posiblemente la más importante) para refactorizar es evitar la duplicación de código (en realidad más que evitar duplicación de código lo que buscamos es evitar la duplicación de conocimiento). Esto es mencionado en varios lugares a lo largo del libro. Como que Beck está obsesionado con esto.
  • El apéndice 2 del libro desarrolla un ejemplo muy chiquito pero muy clarificador de la esencia de TDD.
  • El orden en que codeamos los tests puede impactar enormemente en el proceso de TDD (pag. 200). Un determinado orden puede hacer que el proceso fluya armónicamente mientras que la misma lista de tests codeada en un orden distinto puede llevar a un callejón sin salida.

Sin duda hay varias cuestiones más para destacar de este libro, pero estas son las que a mi me resonaron.

Fira: un juego con raíces académicas

Hace un tiempo comenté que estaba dirigiendo un trabajo final de carrera que consistía en el desarrollo de un videojuego. Ya estamos en el tramo final, por el momento viene todo según lo planificamos: 24 semanas a un ritmo de unas ~30 horas semanales. Si no surgen imprevistos, estimo que estaremos presentado el trabajo durante marzo. El juego ya está jugable hace varias iteraciones y de hecho ya hemos recibido feedback de varios beta users. Un detalle interesante es la intención de hacer de este juego un producto comercial y en ese sentido se ha trabajado con profesionales para externos a la facultad para el desarrollo de los artefactos multimedia (gráfica, sonido, etc). El nombre comercial del juego es Fira y ya está disponible (preview) en la plataforma Steam. Aprovecho para invitar a la audiencia a descargar el juego y darnos su feedback.

Desconozco como suelen trabajar los estudios que se dedican al desarrollo de este tipo de videosjuegos pero creo que la forma en que encaramos el desarrollo viene funcionando muy bien. Esta forma de trabajo es básicamente lo que enseñamos en MeMo2 y tiene que ver con el uso de varias prácticas básicas de ingeniería de software: feedback temprano, integración continua, planificación adaptativa, prueba automatizada, propiedad compartida, uso convencione, etc.

Si bien no he estado muy involucrado en cuestiones de programación, he aprendido muchas cuestiones técnicas de la mano de los alumnos. Creo que el desarrollo de este tipo de juegos es un mundo en sí mismo y por ello creo que bien podríamos tener en FIUBA una materia dedicada a esto.

Estas últimas semanas estuve participando de algunas sesiones de programación con los alumnos y me reencontré con C++. No es un lenguaje de mi preferencia pero me parece importante que todo ingeniero de software tenga alguna experiencia con C++.

Búsqueda de especialista UX

Con el equipo de Radiocut tenemos la intención de dar una vuelta de rosca a la experiencia que ofrecemos a nuestros usuarios. En particular estamos considerando rehacer nuestra aplicación móvil y para ello estamos buscando algún especialista en UX para que nos ayude.

Imaginamos en principio una contratación temporal de una persona que sea usuaria de Radiocut.

Si eres esta persona, te pedimos que completes este formulario y nos contactaremos contigo a la brevedad.

Si estás leyendo esto y no crees ser la persona que buscamos pero conoces a alguién que podría serlo, por favor hazle llegar este mensaje.

Comenzando a estudiar TDD

En el contexto de mi investigación sobre TDD decidí a arrancar desde cero a pesar de llevar ya varios años aplicando y enseñando TDD. La técnica Test-Driven Development (TDD) fue «creada» por Kent Beck durante los 90. Y pongo creada entre comillas porque el mismo Beck se define asimismo como «redescubridor» de TDD. Al margen de este acto de humildad, la realidad es que si bien Beck había leído sobre la idea de escribir el código de prueba antes que código funcional, TDD es una técnica que implica mucho más que esa idea.

Sinceramente desconozco cual sea primera mención formal a Test-Driven Development, pero la primera que yo conozco data de la primera edición del libro Extreme Programming Explained escrito por Beck y publicado en 1999. En dicho libro Beck no habla exactamente de Test-Driven Development como técnica sino que simplemente habla de escribir los tests antes de la funcionalidad y hace referencia a esto como estrategia Test-First.

Recién en su libro Test-Driven Development by Example publicado en 2003, Beck entra en los detalles de la técnica TDD. Hace ya años que no recomiendo este libro como puerta de entrada a TDD, porque personalmente me costó mucho hacer el salto de lo que propone el libro «al mundo real». Tengamos presente que los ejemplos del libro (que básicamente son 2 ejemplos tratados con bastante profundidad) están centrados en lo que podríamos denominar la capa de dominio y no lidian con nada de la infraestructura. Esto está muy bien para entender las ideas centrales de la técnica pero resulta insuficiente para poder aplicarla en «contextos industriales». Sin embargo, a partir de mi trabajo de maestría volví a leer el libro y esta relectura me llevó a revalorizarlo. Me resulta interesante cómo algunas cuestiones que descubrí practicando TDD están mencionadas en el libro, pero que en mi primera lectura yo pasé completamente por alto. Más aún, tengo la sensación de que algunas de esas cuestiones son reiteradamente subestimadas por practicantes y «evangelizadores» de TDD. Una de esas cuestiones es la naturaleza iterativa de TDD. Esta naturaleza iterativa, que también es parte central de Agile y DevOps, implica que tenemos que estar dispuestos a avanzar en una dirección con intención exploratoria aún cuando eso pueda implicar volver atrás. Llevado al código esto puede implicar escribir código (funcional o de prueba) sabiendo que en breve lo eliminaremos. Y cuando digo en breve no es dentro de 3 semanas o 3 meses, sino tal vez dentro de 15 minutos.

Son muy pocos los libros que he vuelto a leer de punta a punta. Muchas veces leo un libro de punta a punta cuando lo leo por primera vez y luego vuelvo a leer (generalmente a modo de consulta) algún capítulo en particular. Pero esta vez decidí volver a leer Test-Driven Development by Example de punta a punta otra vez y creo que ha sido una gran inversión pues me ha permitido reflexionar, cuestionarme y entender más profundamente algunas cuestiones.

Mientras escribo estas líneas reflexiono y me convenzo de que si bien yo estoy empezando mi investigación sobre TDD leyendo Test-Driven Development by Example, no es lo que yo recomendaría a un practicante, o sea, a alguien quien aprender TDD para aplicarlo en desarrollo de software. De hecho, la cuestión de por dónde empezar a aprender TDD es una de las cuestiones intento abordar en mi trabajo de investigación.