Nuevos cursos, nueva modalidad

Desde hace varios años vengo dictando cursos más a allá de mis materias en la universidad. Si bien las temáticas de mis cursos es compartida con los temas que suelo dictar en mis materias, los cursos implican un desafío distinto que amerita una dinámica distinta.

Una materia tiene usualmente (en Argentina) una duración de 16 semanas, lo cual permite “cocinar a fuego lento”, un mismo tema puede verse varias veces, con distintos abordajes, dando al estudiante tiempo y material complementario para digerirlo durante la materia.

Mis cursos han sido típicamente “one-shot”, uno o dos días, consecutivos, varias horas de corrido con duraciones totales variando entre 4 y 16 horas de clase. Sin embargo, para ayudar en el entendimiento de los temas, todos mis cursos tienen una parte práctica importante y es por ello que prefiero utilizar el término “taller” más que “curso”.

Creo que esta modalidad on-shot va bien para cursos/talleres introductorios, donde los participantes vienen a tener un primer acercamiento al tema y se llevan una lista de cuestiones para investigar/profundizar. El tema es justamente que esa investigación/profundización queda en manos del participante y completamente fuera del alcance curso. Para los casos en los que la inversión la hace el propio participante, el retorno de la inversión de haber participado del curso queda a criterio del participante. Pero para los casos en los que la inversión la hace una organización, las expectativas de retorno de la inversión son distintas. Usualmente la organización espera algún impacto positivo en el desempeño de la gente que participa del curso, lo cual me parece completamente razonable.

En 2019 hice un par de experimentos de cursos de “larga” duración, varios encuentros cortos (~90 minutos) a lo largo de varias semanas, con tareas para hacer “fuera del aula”. En aquel momento fueron un conjunto de talleres sobre Docker y Kubernetes y anduvieron muy bien. Esta misma dinámica utilizamos en el Seminario de Software Delivery y también tuvimos buenos resultados. Pero en el caso del seminario fuimos un paso más allá y en el trabajo final les propusimos a los alumnos que trabajen sobre una problemática de su organización. Con esta estrategia estoy diseñando mis nuevos cursos: 100% remoto, varias semanas, con un encuentro semanal de ~90 minutos, con trabajo e interacciones entre encuentros y con actividades de aplicación en el contexto/proyecto/organización de cada participante.

El primer curso que voy a ofrecer aún no tiene título pero tengo la intención de utilizar el stack de herramientas con el que estuve trabajando gran parte de 2020: netCore, Gitlab y Docker/Kubernetes. El foco del curso será Continuous Delivery. En los próximo días estaré publicando más información al respecto.

Balance del 2020

Se fue el 2020, un año particular marcado por una pandemia que nos impacto a todos. Muchos impactos con efectos negativos pero también con algunos efectos positivos.

En mi caso, dentro de la esfera laboral/profesional, el impacto de la pandemia resultó en un balance positivo. A nivel académico no tuvimos mayores complicaciones en la transición a la virtualidad, más aún, consideramos que muchas clases resultaron mejores porque los alumnos podían estar con sus computadoras trabajando durante la clase, cosa que generalmente no es posible cuando damos las clases en la universidad. De hecho, creemos que una vez vuelta la normalidad seguiremos manteniendo la mayoría de clases en modalidad virtual.

En lo que respecta a mi trabajo en la industria, fue uno de mis años record en términos de dedicación. Esto impacto en mi balance industria/academia que en años anteriores venía siendo mucho más parejo.

Dedicación academia vs. industria

La mayor parte de mi trabajo en la industria lo dediqué a trabajar con un equipo de desarrollo. También hice algunas actividades de capacitación y consultoría (en temas de devops y arquitectura).

Dedicación de mis actividades en la industria

Un aspecto en el que la pandemia tuvo un gran impacto fue en lo referente a conferencias y reuniones científicas. Algunas conferencias fueron canceladas, mientras que otras lograron adaptarse a un formato online, lo cual tuvo distinto grado de éxito. Personalmente creo que perder la presencialidad resulta negativo principalmente porque se pierden muchas interacciones humanas (conversaciones de pasillo, eventos sociales, etc). Por otro lado el pasaje a la virtualidad ha permitido la participación en conferencias/eventos a las que tal vez en forma presencial alguna gente no tendría chance de participar. Personalmente participé de 7 conferencias y 4 meetups.

Al margen de la pandemia un hito importante en lo personal es que logré completar mi Especialización en Tecnología Aplicada a la Educación en UNLP con la publicación de mi trabajo de investigación sobre la Enseñanza de Métodos Agiles en Argentina. También dentro del contexto académico publiqué un artículo investigación, envié otro a una revista (que está aún en evaluación), dirigí una trabajo final de carrera y dicté un curso de postgrado.

Releyendo todo esto, creo que a pesar de la pandemia, mi balance del 2020 en lo que respuesta cuestiones laborales/profesionales es positivo. Sin embargo soy plenamente consciente de que mucha gente sufrió grandes dificultades llegando incluso a perder su trabajo, es por ello que espero un mejor 2021 con trabajo para todos y todas.

Iniciativas para abrir la universidad en 2021

Hace tiempo que vengo reflexionando sobre este tema y el año pasado finalmente puse manos a la obra. Durante el primer cuatrimestre de 2020 dictamos, junto a Diego Fontdevila, el Seminario de Software Delivery, una iniciativa para ofrecer desde la universidad un herramienta de formación en un formato no tradicional, para un público con experiencia en desarrollo de software pero sin requerir formación universitaria. Luego, con Diego Marcet, en el segundo cuatrimestre y aprovechando la virtualidad obligada por la pandemia, “abrimos” el curso de Ingeniería de Software de la carrera de Ingeniería en Computación de UNTreF para permitir cursar a gente externa a la universidad.


Para este 2021 tengo la intención de continuar con esta idea de abrir de universidad. En este sentido ya tenemos confirmada la segunda edición del Seminario de Software Delivery (aún no está formalmente abierta la inscripción, pero los interesando pueden contactarme aquí) y también tenemos la intención de volver a abrir la materia de Ingeniería de Software para gente externa a la universidad en el segundo cuatrimestre (compartiré más información llegado el momento).

Adicionalmente a las dos iniciativas mencionadas y en línea con lo que escribí sobre el potencial círculo virtuoso universidad-estado, estoy trabajando junto a gente de una entidad estatal para armar un plan de capacitación anual. Si logramos que esto funcione, es una iniciativa que potencialmente podríamos replicar con otras entidades estatales.

Finalmente, tengo en mente otro experimento: sesiones de consulta para equipos de entidades estatales. La idea es poder asistir “gratuitamente” con sesiones semanales a estos equipos en cuestiones de ingeniería de software. Digo gratuitamente entre comillas porque si bien los equipos/entidades no deberían hacer ningún desembolso económico:

  • Ese desembolso económico ya lo está haciendo el estado al emplearme en la universidad pública
  • Esos equipos/entidades tendrían que colaborar con los estudios de campo de nuestro proyecto de investigación (básicamente participar de alguna entrevista/encuesta o alguna actividad por el estilo)

Aún me faltan definir varias cuestiones operativas y de implementación que iré compartiendo por este medio, pero si ya hay algún interesado en estas sesiones de consulta puede contactarme por aquí.

Software Craftsmanship: una visión distinta de nuestra profesión

Recientemente terminé de leer el libro Software Craftsmanship: The New Imperative de Pete McBreen. Es un libro que trata conceptualmente, o incluso podría decir filosóficamente, sobre la profesión del desarrollador de software. Creo que no hay muchos libros sobre esta temática, rápidamente se me vienen a la mente los tres que tengo en mi biblioteca: The Pragmatic Programmer (Thomas & Hunt), Soft Skills(Sonmez) y The Software Craftsman (Mancuso). Pero ninguno de estos libros tiene un enfoque filosófica tan profunda.

Es un libro que tiene casi 20 años y tal vez por ello hay cuestiones que hoy en día suenan como obvias pero que sin duda en su momento resultaron innovadoras y/o polémicas. El libro fue publicado en agosto de 2001, esto es apenas un par de meses después de la publicación del manifiesto ágil. Muchos de los puntos planteados en el libro suenan muy alineados con el manifiesto, cosa muy común hoy en día pero posiblemente muy llamativa en aquel momento.

Hace un par de semanas escribí sobre la idea de Good Enough Software que se expone en este libro. En línea con esa idea el autor hace una fuerte crítica al modelo de desarrollo propuesto por la ingeniería de software. A mi parecer algunas de esas críticas han quedado sin efecto en la actualidad por el simple hecho de que la ingeniería de software ha “evolucionado” incorporando, entre otras cosas, muchas ideas de los métodos ágiles. Sin embargo, hay algunas críticas que me parece siguen vigentes. En la visión del autor, la ingeniería de software propone una forma de trabajo basada en “hordas de programadores promedio” en contraposición con la propuesta de craftsmanship que sostiene “equipos pequeños de programadores muy buenos”. Y no termina ahí, dice que muchos de esos “programadores promedio” están “sobre remunerados”. Ante esto cree que las organizaciones, en lugar de contratar 15 programadores promedio sobre remunerados, deberían utilizar ese mismo presupuesto pero para contratar 3 programadores muy buenos (craftsmen). Esto haría que estos 3 programadores estuvieran muy bien remunerados y colateralmente esto ayudaría a elevar el nivel y de la profesión y la calidad del software generado.

EL libro me encantó y creo que es una lectura muy recomendada para aquellos profesionales de sistemas (no solo desarrolladores) que tengan ganas de reflexionar sobre el desarrollo de software.

Les dejo aquí algunos títulos/frases del libro:

  • Good developers are more valuable than their managers
    (totalmente de acuerdo, pero pocas veces reflejado en las remuneraciones)
  • Software Engineering forces us to Forget the individual
    (este planteo parece muy bueno, pero creo que en la actualidad es más preciso decir “software factories forces us to forget the individual”)
  • Craftsmanship is personal
    (de acuerdo)
  • Mastery implies taking responsibility for passing on the craft
    (esta idea me pareció muy buena)
  • Let your Software Craftsman pick the rest of the development team
    (esto me parece conceptualmente fantástico aunque nunca lo viví)
  • Avoid bleeding-edge technology is at all posible
    (muy de acuerdo, aunque dependiendo del contexto no siempre es posible)
  • Think applications, not projects
    (me gusta, muy en linea con ideas de equipos de producto y #noProjects)

Estilos de TDD: estilo Buenos Aires

Hace un par de meses mi colega Hernán Wilkinson, hizo una serie de webcasts que llamó Diseño a la gorra. En ese contexto Hernán dedicó un par de capítulos a explicar en detalle su estilo de TDD que, principalmente por cuestiones “marketineras” y contrastando con los la discusión London vs Chicago, denominó “Estilo Buenos Aires”. A lo largo de varias sesiones Hernán fue explicando su estilo mientras resolvía el mismo problema que resuelven Bob Martin y Sandro Mancuso en su debate de London vs. Chicago.

Lo que voy a contar a continuación surge en parte de lo explicado por Hernán en las sesiones de diseño a la gorra y en parte de algunos otras conversaciones que he tenido con Hernán.

En términos de de-adentro-hacia-afuera o de-afuera-hacia-adentro el estilo propuesto por Hernán es claramente de-adentro-hacia-afuera, esto es comenzar por el modelo de negocio y luego conectar la interfaces. Esto está en línea con el estilo Chicago pero según Hernán su estilo se distingue del estilo Chicago en por donde empieza el desarrollo de ese modelo de negocio. En su propuesta Hernán dice que comienza “por el medio”, esto es: comenzar por el modelo de negocio pero modelando primero los objetos “más grandes” que son los que suelen tener una relación más directa con las funcionalidades que ve el usuario de la aplicación.

Al margen del flujo de TDD, creo que la cuestión que personalmente me resultó más interesante de la propuesta de Hernán es la forma en que modela el negocio, particularmente el uso de metáforas, una de las prácticas originales (y me animo a decir menos populares) de XP. En interesante (y tal vez hasta polémico) que a medida que avanza el desarrollo, Hernán va comparando métricas de las 3 soluciones (Chicago vs. London vs. Buenos Aires). No quiero spoilear, pero los resultados de la comparación son muy interesantes aunque a mi parecer no tienen tanto que ver con el estilo de TDD sino con la forma de modelar los objetos.

Personalmente sigo prefiriendo la propuesta de Freeman, pero creo que la propuesta de Hernán es muy interesante y creo que para aplicaciones con modelos de negocio complejos puede llegar a resultar muy conveniente. Al mismo tiempo y hablando particularmente del caso de estudio (el denominado openchat), quiero destacar que, más allá del flujo de TDD, el modelo de objetos resultante de la solución de Hernán me resultó mucho más afín a lo que yo mismo hubiera generado (de hecho la solución de Mancuso/London me resultó demasiado “procedural” para mi gusto).

Más allá de la cuestión conceptual de TDD y el diseño de objetos quiero destacar la generosidad de Hernán y de 10 Pines en llevar adelante esta iniciativa ya que todo el material de estas sesiones (tanto videos como código fuente) están disponibles en la web en forma gratuita (cosa que no ocurre con los videos de la serie London/Chicago). Otro valor adicional de esta iniciativa es que los videos son la grabación en vivo del webcast lo cual agregar el condimento de las preguntas y comentarios de los participantes. Gracias Pinos.

Finalmente cierro con algunos destacados:

  • En el episodio 13 (parte 5 de London vs. Chicago), Carlos Peix muestra una solución estilo London utilizando Net Core.
  • En los episodio 14 y 15 (parte 6 y 7 de London vs. Chicago), Hernán muestra como agregar la persistencia al modelo desarrollado utilizando dos medios persistentes diferentes
  • El código de la solución desarrollada está disponible en Github
  • Más de TDD, en el episodio 5 se cuenta una breve historia de los closures

Preparando la infra para el TP de MeMo2 @fiuba

A partir de la pandemia el segundo cuatrimestre de 2020 en FIUBA quedó partido: 12 semanas en 2020 y 4 semanas en 2021 con un receso entre 21 de diciembre y 8 de febrero. Este receso nos dio la posibilidad de intentar innovar en ciertos aspectos del trabajo práctico final de la materia. El objetivo de este trabajo es poner en práctica de forma integral todo lo visto en la materia con un importante foco en cuestiones de proceso. En este sentido hay una parte del proceso (principalmente relacionada a configuration management) que históricamente hemos dejado un poco marginada principalmente por restricciones de infraestructura.

Típicamente el trabajo final consiste en el desarrollo y despliegue de una aplicación que comprende una API Rest y un bot de Telegram. Todo esto trabajando en una dinámica de Extreme Programming lo cual implica: BDD, TDD, Integración continua, despliegue continuo, automatización de pruebas, trabajando muy de cerca con el usuario, armando criterios de aceptación, etc, etc.

Hasta el momento venimos trabajando con Ruby + PostgreSQL, desplegando a cuentas gratuitas de Heroku y utilizando GitLab como plataforma de desarrollo (gestión de backlog, repositorio, CI/CD, etc). Debo agradecir aquí a Jetbrains (que provee gratuitamente sus herramientas a nuestros alumnos) y a GitLab (que no dio una licencia gold de su plataforma).

El servicio de Heroku está muy bien, pero su modelo de plataforma como servicio nos abstrae de ciertas cuestiones que nos gustaría que los alumnos vieran más de cerca, principalmente en lo que tiene que ver con manejo de la infraestructura de como código. En este sentido, estamos considerando ir hacía Kubernetes, eso implicaría mínimamente escribir los descriptores de pods, deployments, configmaps, etc, etc. No le vamos a pedir a los alumnos que hagan todo esto por su cuenta (pues implicaría que se ponga a aprender kubernetes lo cual excede por mucho el alcance de la materia), sino que lo haremos en forma conjunta (equipo docente y alumnos). Ahora bien, para dimensionar los recursos tenemos que considerar los siguientes puntos:

  • Son 7 grupos
  • Cada grupo necesita al menos 2 ambientes (test y prod)
  • Cada ambiente requiere al menos un pod para la api, un pod para bot y una base de datos (en principio de tipo relacional)
  • Nos gustaría contar también con alguna solución de logging centralizado tipo ELK pero no es algo imprescindible

Toda la infra de deployment ya la tenemos resuelta con GitLab.

La intención inicial es usar algún servicio cloud que nos provea Kubernetes y base de datos “as a Service”. La idea es no tener que pagar por esto, ya que al ser una universidad pública no podemos pretender que los alumnos pagen por esto y mucho menos vamos a pedirle a la universidad pagar por esto. Obviamente que una opción es que lo paguemos los docentes (opción que no descarto) pero me parece que puede ser una buena oportunidad algún cloud provider de colaborar con la formación de potenciales futuros empleados/clientes y de paso hacer un poco de marketing.

En próximos post iré compartiendo a medida que vayamos avanzando en el armado de todo esto.

Estilos de TDD: un voto para London

Hace un tiempo escribí sobre los estilos de TDD e intenté hacerlo de forma objetiva. Ahora pretendo continuar con la cuestión pero dando mi opinión.

No creo que haya un estilo que sea universalmente mejor que otro (no silver bullet). Creo que un determinado contexto puede resultar más conveniente utilizar uno u otro estilo. Personalmente me ocurre que en los contextos en los que suelo trabajar encuentro más conveniente una utilizar una estrategia del estilo London, o para ser más preciso: la propuesta de Freeman & Pryce. Para que se entienda mi posición explico un poco las generalidades de los contextos en los que suelo trabajar.

En primer lugar suelo trabajar muy cerca del usuario y con una estrategia de entrega continua. Al mismo tiempo, en los equipos en los que trabajo suelo ocupar un rol tipo “XP Coach” con el foco en lograr que el equipo pueda entregar software de valor, de calidad, de manera sostenible y predecible. Generalmente los equipos con los que trabajo no tienen experiencia en TDD. Típicamente trabajo en aplicaciones comúnmente denominadas como de “tipo enterprise / sistemas de información” . Generalmente me ocurre que los principales desafíos que el equipo enfrenta no vienen dados por la lógica de negocio ni el modelado del dominio sino por cuestiones “accidentales” como procesos manuales, desconocimiento/(des)control de la infraestructura, trabajo desordenado, burocracia, falta de comunicación, etc.

Es en estos contextos donde encuentro especialmente útil la propuesta de Freeman & Pryce, concretamente cuando proponen:

  • Comenzar con un walking skeleton que nos permita establecer las bases de la arquitectura de la aplicación de punta a punta.
  • Que ese walking skeleton este cubierto por una prueba de aceptación end-to-end
  • Incluir como parte de ese walking skeleton el proceso de versionado, build, test y deploy a un ambiente simil producción en un esquema de integración continua

Esto en un punto excede el estilo de TDD y por ello es me parece más preciso hablar de la propuesta de Freeman & Pryce que del estilo London cuando me refiero a estas cuestiones.

Ahora bien, una vez completo el walking skeleton entonces sí podemos hablar del estilo de TDD. Ahí la propuesta de Freeman & Pryce es comenzar “desde afuera” trabajando en el doble ciclo TDD (estilo London). Esto requiere del uso de test-doubles, posiblemente el punto más cuestionado de este enfoque. Las críticas a esta cuestión se deben principalmente al hecho de que puede resultar costoso el mantenimiento de los test-doubles a medida que la aplicación (y el diseño) van evolucionando. Coincido en que esta cuestión es un riesgo, pero en mi caso lo suelo mitigar tratando al código de tests con el mismo cuidado con el que trato al código de la aplicación y utilizando todo un conjunto de técnicas para asegurar su mantenibilidad. Muchas de estas técnicas están descriptas en el mismo libro de Freeman y Pryce, pero también hay algunas otras que he encontrando muy útiles en los libros de Gojko Adzic (Fifty Quick Ideas To Improve Your Tests, Specificacion by Example) y Gerard Meszaros (xUnit Test Patterns: Refactoring Test Code).

Una cuestión que quiero destacar de este enfoque es que me resulta muy conveniente la idea de ir diseñando/desarrollando la aplicación desde afuera porque eso nos pone en una posición de “cliente/usuario” de nuestro propio código, evitando en cierto modo la creación de métodos/comportamientos/atributos/artefactos que “el cliente” no requiera, entiendo aquí como cliente a “la capa/el objeto” que consume nuestro código y que indirectamente termina expresando la necesidad del cliente/usuario persona.

Introducción a Pytest

Desde hace ya unos cuantos años cada vez que me prepongo aprender seriamente una nuevo lenguaje de programación empiezo por escribir algunos tests en lugar del clásico (y poco útil) “hola mundo”. Es por esto que para quienes pretenden acercarse al mundo Python les traigo un video de introductocción a Pytest, uno de los frameworks de testing más populares del mundo Python.

Cierre de un año atípico en IngSoft @ UNTreF

El miércoles pasado cerramos un cuatrimestre atípico debido principalmente a la situación de pandemia. En términos formales tuvimos dos particularidades: todas las clases fueron virtuales y la duración del cuatrimestre fue de 14 semanas (y no de 16 como es habitualmente). Una curiosidad (o no tanto) es que de no ser por la pandemia es posible que el curso no se hubiera dictado ya que solo tuvimos 2 alumnos que estaban en condiciones formales de cursar la materia y con ese número es común que la universidad no abra el curso principalmente por la escasez de aula (tema muy polémico). Pero la situación de pandemia “nos sacó” del aula y de las restricciones asociadas. Es así que aceptamos en el curso algunos alumnos a los que les faltaba alguna correlativa y también a gente externa a la universidad. Esto último fue un experimento para “abrir” la universidad y que ahora terminado el curso, creemos que fue muy positivo.

Comparto algunas métricas del curso:

  • 14 clases
  • 31 tareas individuales incluyendo lecturas, videos, ejercicios de programación y cuestionarios
  • 1 trabajo grupal
  • 1 invitado de la industria
  • Cantidad de alumnos inscriptos 5
  • Cantidad de alumnos aprobados 5
  • Nota promedio de aprobación: 8.8
  • Dedicación promedio extra-clase por alumno por semana: ~6 horas

Serie de videos: Python a la XP

A partir del curso que mencioné en el post anterior, empecé a hacer una serie de videos para utilizar como parte del contenido del curso y también para ir entrenando yo mismo. Estos videos los voy a ir publicando en esta lista de YouTube que titulé Python a la XP.

Por el momento solo hay publicado un video que muestra la resolución de un ejercicio y que pone el foco en el proceso de desarrollo en términos de TDD y diseño incremental.

Aviso: no soy experto en Python, de hecho mi uso de Python es bastante básico, lo he utilizado principalmente para cuestiones de scripting junto con Ansible. Es por esto que seguramente encuentren en el video fragmentos de código que sean muy mejorables.