Categoría: opinion

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.

Curso de Introducción al Desarrollo de Software, usando Python y a la XP

La historía es así: una ONG dicta un curso de ~2 meses de introducción a la programación para jóvenes que rondan los 20 años de cara a iniciarlos en la temática y dar un primer paso de una potencial carrera en el sector. Luego la ONG hace un acuerdo con una empresa para continuar la formación de los jóvenes. La empresa tiene la intención de complementar la formación de los recién iniciados en la programación de cara a que puedan sumarse a un equipo de desarrollo. Es ahí donde entro yo para implementar esta formación. Todo esto en modalidad 100% virtual debido a situación de pandemia.

Con muchísimos detalles de implementación de por medio, hoy por hoy estoy dictando este curso de ~3 meses que además de programación con Python/web incluye algunas cuestiones básicas de desarrollo al estilo XP como versionado, unit testing, tdd, integración continua, revisiones de código, pair-programming, orientación a objetos, etc.

Esto me llevó a acercarme mucho más al mundo Python que hasta el momento yo venía utilizando principalmente para cuestiones de scripting. Así que ahora estoy cotidianamente trabajando con Pytest, Pylint, flake8, etc, etc. Personalmente estoy muy motivado con como viene fluyendo el curso. En futuros posts compartiré algunos detalles más.

La influencia de Agile en el uso de prácticas de desarrollo

Este el título del artículo de investigación que estaré presentando en Congreso Bianual de IEEE Argentina. Este artículo, cuya autoría comparto con Diego Fontdevila y Alejandro Oliveros, es parte del resultado de nuestra participación en la iniciativa HELENA Survey. La presentación será esta tarde en el bloque de 15 a 17 hs., la participación es gratuita pero requiere registración aquí.

En forma resumida encontramos que entre las prácticas de desarrollo más utilizadas, las prácticas de gestión/organización son prácticas que fueron introducidas por los métodos ágiles. Al mismo tiempo vemos que las prácticas técnicas más utilizadas son principalmente prácticas previas a los métodos ágiles pero que estos últimos han reconocido e incorporado. En cierto modo podríamos leer esto como lo que la industria tomó de Agile es principalmente técnicas de gestión/organización.

La publicación de este trabajo marca el cierre de una etapa en mi trabajo de investigación. Esta etapa que inició allá por 2016 estuvo enfocada en estudios de índole principalmente exploratoria sobre el uso de métodos ágiles de desarrollo de software. El año próximo continuaré trabajando en otra línea de investigación relacionada a la enseñanza de ingeniería de software (tema que ya vengo trabajando desde 2018) y comenzaré a trabajar en el estudio de prácticas de desarrollos de software.

La motivación de estudiar las prácticas concretas de desarrollo surge a partir de ver que muchos equipos no utilizan un método/enfoque/proceso particular sino que más bien utilizan algún tipo de «enfoque híbrido» que combina prácticas de diferentes enfoques/métodos/procesos. En particular me interesa estudiar experimentalmente dos prácticas: Pair-programming y Test-Driven Development.

Algunas reflexiones sobre Agiles 2020, la conferencia y la comunidad

Hace un par de semanas se llevó a cabo la conferencia Agiles 2020 y en ese contexto participé de una sesión de «historia» junto a algunos otros colegas del grupo organizador del primer Agiles allá por 2008. Agradezco a MaríaT y LinaP por haber tomado la iniciativa de armar la sesión. Mientras escuchaba hablar a algunos colegas en la sesión me fueron surgiendo algunas reflexiones que quiero compartir aquí.

Creo que nadie de aquel grupo de 2008 imaginaba que la conferencia llegaría hasta aquí: 13 ediciones consecutivas en 8 países de la región, 1 edición 100% online y una edición 14 confirmada para celebrarse en 2021 en Panamá (el noveno país anfitrión).

Una cuestión curiosa de esta continuidad es que se da sin que haya una organización formal ni un steering committee. A diferencia de otras comunidades no hay en Agiles un figura legal detrás de la organización. En el caso de Agiles Argentina está la Sociedad Argentina de Informática, pero no todos los países tienen una figura así. Año a año el grupo de organización es distinto pudiendo incluso ocurrir que de un año para el siguiente se renueve todo el equipo de organización. Esto tiene algunas cuestiones positivas y algunas otras no tanto. Entre las no positivas está el hecho de que potencialmente se pierda «conocimiento», como ha pasado en más de una ocasión (y lo puedo decir con seguridad porque estuve ahí).

Es interesante que en el equipo organizador de este año no participó formalmente ninguno de lo «miembros fundadores» lo cual refuerza esta idea de renovación completa y continuidad. Esto lo digo sin tener una certeza absoluta ya que en la página de la conferencia no encontré ninguna mención al grupo organizador. (si estoy equivocado tal vez algún lector pueda corregirme).

Aquella primera conferencia de 2008, más allá de iniciar la tradición de la conferencia anual, dio origen a una comunidad que inicialmente tomó forma en un lista de correo de Yahoo! y que en algún momento de los últimos años «se mudó» a un grupo de Telegram que hoy en día cuenta con más de 1000 participantes.

A lo largo de todos estos años la conferencia fue variando en distintos aspectos entre los que a mi parecer se destacan dos: formato y temática. En términos de formato tuvimos conferencia tradicional (con convocatoria de sesiones), con keynotes, sin keynotes, con Open Space, sin Open Space, todo Open Space, etc. Realmente se han probado diversos formatos. En cuanto a temática, me animo a decir que igual que el manifiesto ágil, inicialmente hubo un foco en desarrollo de software que en los últimos años fue inclinándose hacía cuestiones más generales de «agilidad». Lo mismo pasó con la comunidad, donde hoy en día participa gente que no tiene relación con el desarrollo de software. Un hecho en relación con este cambio es el cambio de nombre de la conferencia: inicialmente la habíamos bautizado como «Conferencia Latinoamericana de Métodos Ágiles, Agiles XX» y en algún momento de los últimos años (no puedo precisar cuando) pasó a ser «Jornadas Latinoamericanas de Agilidad, Agiles XX».

Personalmente participé de 10 de ediciones y en 3 ocasiones forme parte del grupo organizador. A lo largo de todo este tiempo mi participación y sentido de pertenencia a la comunidad ha ido variando como consecuencia «del match de expectativas». Personalmente mis inquietudes, gustos e intereses pasan por el desarrollo de software y no me despierta mayor interés hablar de «Agilidad» en otros contextos. Es por ello que en el último tiempo me he sentido más afín con otras comunidades, conferencias y espacios de intercambio. Me consta que algunos otros colegas comparten este pensamiento y ello ha planteando cierto debate sobre si Agiles es un espacio de intercambio para gente del desarrollo de software y más particularmente para gente de perfil más técnico. Algunos colegas como AndresJ cree que sí, yo cada vez tengo más dudas. Sin embargo debo admitir que en este último Agiles me encontré con varias sesiones relacionadas al desarrollo de software que me resultaron muy interesantes.

Para cerrar esta reflexión les comparto una foto de la remera que habíamos hecho para el grupo organizador de Agiles 2008 que aún tengo en mi guardarropa.

Para los interesados en repasar la historia y la evolución de AgilesXX pueden encontrar aquí los distintos artículos al respecto que he escrito a lo largo de todos estos años.

«Good enough» Software Engineering

Por estos días me encuentro leyendo el libro «Software Craftsmanship: The New Imperative» de Pete McBreen. Es un libro que tiene casi 20 años y que a mi entender no ha tenido gran difusión. De hecho yo lo encontré por casualidad. No es mi idea en este artículo resumir el libro sino simplemente detenerme en esta idea de «Good Enough Software Engineering» que es una de las ideas que menciona el autor en la primera parte del libro y que recientemente me resonó mucho a partir de un intercambio de mensajes con mi colega Carlos Peix.

McBreen pone en tela de juicio el «enfoque formal» propuesto por la ingeniería para el desarrollo de software. Argumenta que la ingeniería de software resulta sin duda un enfoque apropiado para ciertos tipos de sistemas que implican el desarrollo conjunto de hardware + software y que ponen en juego la vida humana. En este sentido menciona proyectos militares y aeroespaciales. Sin embargo cree que el enfoque de ingeniería de software no es apropiado para el desarrollo de lo que llama «software comercial», cuyo desarrollo no requiere del desarrollo de un hardware particular y que no pone en juego vidas humanas, pero que tiene ciertas restricciones de mercado. Dicho de otra forma: los trade-offs que pueden hacerse en cada uno de estos dos tipos de proyectos son distintos y eso da lugar a distintos enfoques. Según MeBreen el desarrollo de software comercial va mejor con un enfoque de «good enough software» que con un enfoque de «Ingeniería».

Creo que somos varios a los que nos resuenan estos cuestionamientos que hace McBreen. De hecho recuerdo un artículo de David Parnas publicado en IEEE Software: Software Engineering – Missing in Action: A Personal Perspective, en el cual también se cuestiona el enfoque de ingeniería para el desarrollo de software. McBreen insiste en que para muchos contextos (la mayoría según él) hay enfoques más apropiados que el de ingeniería de software. Más aún, cree que hay varios enfoque posibles pero se inclina a hacia un enfoque de «artesanía».

Estas reflexiones plantean interesantes dilemas para practicantes y académicos. Como practicantes debemos entonces ante cada nuevo proyecto decidir que enfoque utilizar. Como académicos aparecen algunos cuestionamientos profundos:

  • ¿está bien que las carreras de informática sean ingenierías o deberían ser licenciaturas y de esa forma despegarse de la «carga conceptual/cultural» que la ingeniería impone?
  • ¿es posible/conveniente cubrir dentro de una misma carrera enfoques de ingeniería y de «no ingeniería»?
  • ¿deberíamos tener carreras más específicas en línea con distintos enfoque de desarrollo?

Mi sensación es que en la actualidad muchas carreras, independientemente de su nombre, proponen un enfoque ingenieril pero luego una importante porción de sus egresados terminan trabajando en proyectos que podrían resultar más afines a un enfoque de artesanía.

Un detalle importante aquí es que un enfoque de ingeniería no es más completo ni abarcativo que un enfoque de «no-ingeniería» sino que es divergente. Esta divergencia que yo veo no es necesariamente conceptual sino «operativa» en un punto: las carreras tienen un límite de tiempo, enseñar un enfoque de ingeniería trae de entrada toda una base de conocmiento que reduce el espacio/tiempo para estudiar otras cuestiones. Esto queda muy en evidencia cuando en la actualidad vemos «ingenieros de software» que no buenos desarrolladores. Mi percepción es que muchas de las carreras actuales de «Ingeniería» (más allá de que sean formalmente ingenierías o licenciaturas) no forman buenos desarrolladores.

En fin, creo que este tema da para mucho, continuaré.

Estilos de TDD: London vs. Chicago

Hace un tiempo cobró cierta popularidad entre los practicantes de TDD el debate sobre los denominados estilos o escuelas de TDD: «London» y «Chicago». Hay varias explicaciones en la web sobre las diferencias de estos estilos ([1][2][3][4]) que podríamos resumir brevemente en dos dimensiones:

  • Flujo
    El estilo Chicago (también denominado «tradicional») propone un desarrollo de adentro hacia afuera, se comienza por los objetos del dominio y luego se agrega la capa de interface/controllers.
    El estilo London propone un desarrollo de afuera hacia adentro, lidiando de entrada con las cuestiones de interface/controllers y llegando a los objetos de dominio a partir de las necesidades que la interface/controllers nos va demandando.
  • Aserciones:
    En el estilo Chicago los tests hacen asserts sobre el estado de los objetos y los resultados.
    En el estilo London los tests están más enfocado en la interacciones entre los objetos y para ello depende en gran medida del uso de mocks.

Estos dos estilo dieron un salto de popularidad a partir de una serie de videos realizados por Bob Martin y Sandro Mancuso. En estos videos Bob (Chicago) y Sandro (London) muestran y comparan el desarrollo de una aplicación (Rest API) utilizando estos dos estilos.

Al estilo Chicago se lo suele asociar al libro Test-Driven Development by Example de Kent Beck mientras que al estilo London se lo suele asociar con el libro Growing Object-Oriented Software Guided by Tests de Freeman y Pryce. Sin embargo, a mi parecer, comparar los enfoques London y Chicago a partir de estos dos libros me parece errado porque el alcance y foco de las propuestas descriptas en estos libros es distinta. El libro de Beck es un libro que tiene un foco claro en el uso de TDD a nivel del modelo de objetos de dominio. Por su parte, el libro de Freeman tiene un foco es más amplio, apunta al proceso de desarrollo de una aplicación (no solo del modelo de objetos de dominio). Es así que el libro de Freeman contempla también cuestiones como arquitectura hexagonal, walking skeleton e integración continua. Tengamos presente que el libro de Beck es de 2003 mientras que el de Freeman es de 2009. Al mismo tiempo en su perspectiva de desarrollo de una aplicación, el libro de Freeman plantea un doble ciclo de tests donde el ciclo interno es el que coincide con el ciclo de TDD que plantea Beck. Es por esto que no creo que sea Freeman o Beck, sino que los veo como complementarios.

Volviendo a London vs. Chicago, un punto central en la discusión es el uso de mocks. Si solo pensamos TDD para el desarrollo del modelo de objetos de dominio puede que el uso de mocks no resulte útil. Pero si ampliamos el foco de la discusión y consideramos el desarrollo de una aplicación completa incluyendo las cuestiones de «infraestructura» (interfaces, persistencia, etc.), entonces los mocks toman otra relevancia/utilidad.

Continuará…

[1] https://josemyduarte.github.io/2018-12-09-tdd-outside-in/
[2] https://devlead.io/DevTips/LondonVsChicago
[3] https://dev.to/hiboabd/a-beginners-explanation-of-the-chicago-london-approaches-4o5f
[4] https://nvoulgaris.com/comparing-tdd-flavours/