Categoría: opinion

Nerdearla 2023: Integración Continua 3.0

La semana pasada me notificaron que mi propuesta de sesión «Integración Continua 3.0» había sido aceptada en Nerdearla. Asimismo me dijeron que la idea es que la presente, valga la redundancia, presencialmente. Hay algunas sesiones que serán grabadas en forma previa a la conferencia y luego serán transmitidas por streaming durante los días del evento, pero al parecer mi sesión la daré en vivo en un de los escenarios de la conferencia en CC Konex con transición en simultáneo. Aún no tengo los detalles de agenda pero si puedo compartir algunos detalles de lo que hablaré en la sesión.

Comencemos por el título. Lo de 3.0 responde a tres épocas distintas en la evolución de esta práctica.

1.0: el origen

El inicio de esta práctica se remonta a fines de los ’90 con el surgimiento del enfoque de desarrollo propuesto por Extreme Programming. La figura a continuación muestra la relación de la práctica de Integración Continua (continuous integracion) con el resto de las prácticas de Extreme Programming. Dicha figura pertenece al libro Extreme Programming Explained de Kent Bent, publicado en 1999.

Yo conocí está práctica allá por 2003 precisamente leyendo ese libro y luego la profundicé leyendo el ya clásico artículo de Integración Continua de Martin Fowler publicado en el año 2000. La primera vez que implementé esta práctica fue con la herramienta Cruise Control. Poco tiempo después me fui inclinando al uso de Hudson (que luego daría origen en Jenkins). Por aquellos años también tuve la oportunidad de utilizar las primeras versiones de Microsoft Team Foundation Server. Hacia 2010 recuerdo que me mi herramienta favorita para hacer integración continua era Team City.

2.0: Continuous Delivery

Para mi la segunda era en la evolución de la integración continua se da a partir de 2010 con el hito de la publicación del libro de Humble y Farley: Continuous Delivery. Este libro aún hoy, con más de 10 años, sigue siendo un referencia indiscutible en la materia. Entre otras cuestiones, este libro formalizó el término «pipeline». En lo personal transité gran parte de esta época utilizando Jenkins y Travis-CI.

3.0: CI/CD

Ya a partir de 2016 y de la mano del movimiento DevOps empezó a tomar una gran popularidad el término «CI/CD» haciendo referencia a «Continuous Integracion / Continuous Delivery» y gradualmente la práctica de integración continua fue llegando al mainstream. La cantidad de herramientas para implementar esta práctica inundaron el mercado (Spinnaker, Tekton, Bitrise y CircleCI por nombrar algunos) y los proveedores de servicios de Git se sumaron la fiesta (BitBucket Pipelines, Github Actions, Gitlab-CI, etc).

Como suele ocurrir, junto con la popularidad, llegan los negocios, las imprecisiones y las confusiones. En parte esto es lo que me motivó a proponer mi sesión: aclarar algunas cuestiones.

La idea de mi sesión es comenzar haciendo un breve repaso del origen y evolución de la práctica (lo que describí aquí pero con mayor detalle) y luego adentrarnos en un conjunto de recomendaciones y patrones para su implementación que he ido recogiendo a los largo de 20 años usando esta práctica. Veremos opciones para: diseñar pipelines desde cero, refactorizar pipelines existentes, escalar, manejar particularidades para pipelines de mobile, de frontend, entre otros. Nos vemos…

Testear en Producción, pero seriamente

Para muchos «testear en producción» es una acción temeraria, un pecado, una situación riesgosa, indeseada. Y es típicamente así cuando el único testing que hacemos es en producción, cuando cada cambio que introducimos en producción es muy grande, cuando los procesos de despliegue son manuales y esporádicos.

Pero si trabajamos en pequeños incrementos, hacemos TDD, testeamos de forma sistematizada, automatizamos la tareas repetitivas y desplegamos de forma frecuente, entonces no hay mucho de que temer. Esto es lo que comentaba Nayan Hajratwala en su sesión «Embrace these Three Fearsome Words: Test in Production» en Agile 2023. Estoy muy de acuerdo con esto pues esta propuesta esta muy en línea con lo que yo mismo hice las pocas veces que decidí probar en producción.

Un habilitador imprescindible en mi opinión para poder testear en producción es tener la capacidad de «segmentar funcionalidades por grupos de usuarios», esto es: poder definir subconjuntos de usuarios para que solo ellos puedan acceder a ciertas funcionalidades. Algunos autores llaman a esto «Dark launch«. Esta práctica no es más que una variación de la práctica de feature toggles que permite desacoplar el deploy («instalación» en producción) y el release (disponibilización para el usuario).

Alguien podrá preguntarse, ¿porque testear en producción si tengo la posibilidad de testear en ambientes previos? Puede haber varias razones, comparto dos que son las que he experimentado:

  1. Hay ocasiones en las que testeamos en producción porque hay ciertas condiciones que solo están disponibles en dicho ambiente, típicamente integraciones con otros sistemas. En ese caso lo que estamos haciendo en producción es una prueba de integración y la hacemos luego de haber testeado todo nuestro código de forma previa al despliegue en producción.
  2. Hay otras ocasiones que testeamos en producción para tener feedback real a nivel «negocio». Caso típico: queremos validar una hipótesis de negocio, queremos ver como nuestros clientes/usuarios reaccionan ante una nueva funcionalidad o variante de una funcionalidad existente. En este caso no estamos testeando si el software hace lo que habíamos pensado, sino que estamos testeando una idea de negocio.

Nuevo plan de Ingeniería Informática en FIUBA (2023)

Finalmente el martes pasado, 8 de agosto, el Consejo Directivo de la FIUBA aprobó el nuevo plan de estudios de la carrera de Ingeniería en Informática. Esto ocurre en el contexto de la iniciativa «Plan 2020» en la cual la facultad se propuso generar nuevos planes para todas sus carreras, pero que por motivos diversos, llega con años de retraso.

El lo personal no estuve involucrado en la creación de este nuevo plan, es una tarea de la Comisión Curricular de la carrera de la cual yo no formo parte. Pero como docente del departamento de computación suelo recibir consultas de los alumnos respecto de la carrera en general. Es por ello que comparto aquí algunas opiniones respecto de este nuevo plan.

Cabe destacar que tiempo atrás escribí sobre un borrador de plan que se había compartido, pero había sido elaborado por otra comisión, o sea: el plan se empezó a trabajar con una determinada formación de la comisión curricular y un director pero el plan publicado ahora fue creado por una comisión liderada por otro director de carrera y otros miembros. Y si bien algunos miembros se mantienen, no estoy seguro de hasta qué punto esta comisión mantuvo el trabajo realizado por la anterior o hasta que punto, hicieron borrón y cuenta nueva.

En primer lugar hay un cambio significativo respecto de las cuestiones de ciencia básica. No hay ninguna materia de química (ni siquiera en el CBC) y solo quedan dos materias de Física: la del CBC y una nueva materia llamada «Física para Informáticos». También hay algunos cambios menores en las materias de matemática.

Por otro lado, en cuestiones de informática, hay varias cuestiones a notar, detallo algunas materias:

  • Introducción al Desarrollo de Software: me parecen interesantes los contenidos que plantea de forma temprana en la carrera, me gusta que ya tempranamente habla de Desarrollo Orientado por Pruebas (asumo que se refiere a TDD). No me gusta tanto la mención explícita a front-end y back-end pues me parece que es una cuestión tecnológica «de moda».
  • Paradigmas de Programación: entiendo que se la considera equivalente a Algo3 pero no lo veo tan así pues por un lado incluye cuestiones de otros paradigmas más allá de OO y al mismo tiempo no veo ninguna mención a cuestiones de ing. de software (nada de TDD, ni unit testing y tampoco patrones)
  • Ingeniería de Software 1: parece que algunas de las cuestiones que «sacaron de algo3» las metieron aquí, puntualmente las cosas de diseño, oo, patrones. Creo que quedó más parecida a la materia de Ingeniería de Software 1 que se dicta en Exactas. Yo la veo distinta a MeMo 1 en parte por contenido y también porque es una materia 8 créditos (MeMo 1 es de 6).
  • Ingeniería de Software 2: pinta como lo que vengo dando en MeMo2 (de hecho los contenidos mínimos son los mismos) pero tiene 8 créditos cuando MeMo2 tiene 6. Intentaré averiguar que onda.
  • Taller de programación: sus contenidos mínimos me suenan muy distintos a los de la materia que se dicta actualmente y me resulta intrigante cómo se plasmaran en un curso.
  • Empresas de Base Tecnológica: la 1 me parece como un mix de varios temas «de materias de Las Heras» (en general en Las Heras se dicta materia de organización/gestión). La 2 pinta mejor, trae algunas cuestiones de innovación, startups, etc.
  • Gestión del Desarrollo de Sistemas Informáticos: entiendo que esto es lo que viene dictando Carlos Fontela en la materia de gestión de proyectos que dicta actualmente. Pinta bien aunque me llama la atención lo de «Análisis del Impacto Socioambiental» (según averigué es un lineamiento de la facultad que todas las carreras tengan algo de esto)
  • Taller de Seguridad Informática: me parece bien que se haya puesto esta materia, creo que seguridad es un tema muchas veces postergado. Los contenidos son debatibles pero por algo hay que empezar.
  • Electivas: veo muchas que me suenan a «data / machine learning» y solo arquitectura de software del área de Ingeniería de Software. No vi ninguna materia relacionada a operaciones, infraestructura, data centers, etc, cosa que si había en alguna versión preliminar del plan.

En lo personal creo que es un buen plan, mucho más adecuado a los tiempos actuales que el plan anterior. También creo que está mucho más enfocado en cuestiones de informática (y no tantas generalidades de ciencia básica). Por último pero no menos importante, el plan tiene una estructura distinta que entre otras cosas elimina las orientaciones y que constituye una carrera más corta (al menos en los papeles): son en total 10 cuatrimestres incluyendo el ciclo de ingreso.

Este nuevo plan se pondrá en funcionamiento este segundo cuatrimestre de 2023 con la oferta de 3 materias aún cuando falta la aprobación del Consejo Superior de la UBA, cosa que debería ocurrir en las próximas semanas.

Actualización 2023-09-08: el plan ya es oficial, fue aprobado por el consejo superior. Aún no lo actualizan en la página de la facultad pero se puede descargar desde la página de UBA, aquí.

Nuevo proyecto: refactoring, Python y OpenAI

Esta semana comencé a trabajar en un nuevo proyecto. En términos simples voy a acompañar a un grupo de devs en el refactor de una de sus aplicaciones. A la pasada vamos a revisar algunas cuestiones de diseño, arquitectura, testing y posiblemente a la pasada veremos un poco de TDD.

Venía intentando escaparle a la ola de AI, pero ya no más pues este proyecto trabaja con OpenAI, así que, más obligado que por gusto, me toca meterme en este mundillo.

El refactor surge a partir de la necesidad de agregar ciertas nuevas funcionalidades que con el diseño actual podrían resultar no tan fáciles de introducir. Entonces la idea es seguir la estrategia de Beck: «for each desired change, make the change easy (warning: this may be hard), then make the easy change» o sea:

  • primero vamos a refactorizar el código existente para facilitar la implementación de las nuevas funcionalidades
  • a partir de esa refactorización vamos a poder agregar algunos test «chicos/unitarios» ya que el código solo tiene pruebas «grandes/de aceptación» que son caras y no ofrecen suficiente cobertura
  • una vez finalizado el refactor y agregados nuevos tests, avanzamos el desarrollo de la nueva funcionalidad
  • bonus track: el desarrollo de la nueva funcionalidad lo hacemos guiado por tests (tdd)

Continuará…

Notes and resources of my talk at #Agile2023

Last Thursday afternoon I delivered my talk «Technical Practices Walkthrough for non-technical People» at Agile 2023 Conference.

The session was attended by an enthusiastic audience of over 100 participants, and I was delighted to see that nearly everyone stayed engaged until the very end. From the positive atmosphere in the room, I believe it was a successful and impactful session. I am glad to share that I accomplished all the objectives I had planned for the talk.

Overall, I feel gratified by the experience and want to express my gratitude to the Agile 2023 Conference organizers for letting me share my knowledge and insights.

At the end of the session I gave away some of my books (both in Spanish: Construcción de Software, una mirada ágil y Experiencias ágiles).

Here you have some resources I mentioned/used during the talk:

  • The slides are here
  • One of the books I gave away at the end of the session is available for free to read online here
  • The application I used to perform the demo is online at https://jobvacancy.com.ar
  • In this article, I describe a case were I combined the use of slicing feature toggles.

Picture of the audience minutes before starting the session

Sobre la Guia Oficial de eXtreme Programming

En Scrum que existe una guía oficial que los autores mantienen actualizada. También existe una organización (en realidad creo que más de una pero la que conozco yo es la Scrum Alliance) que ofrece certificaciones de Scrum. En este sentido es razonable pensar que quien se acercó a Agile con Scrum, luego quiera acercarse a Extreme Programming (XP) y busque la guia oficial de XP.

Pero en XP no hay guía oficial, perdón si llegaron a este post buscando esa guía oficial. Al menos ahora saben que no existe :-). Tampoco existe una certificación oficial de XP, ni una XP Alliance.

En términos de publicaciones creo que los más cercano a una guía oficial es la serie de libros «XP Series» de la editorial Addison-Wesley publicada entre 1999 y 2005. En dicha serie se incluye el libro fundacional de XP escrito por Beck: «Extreme Programming Explained, Embrace chance» que a mi parece no es el mejor libro de la serie. No leí todos los libros de la serie en parte porque no pude conseguirlos, varios de ellos están discontinuados, de hecho algunos los conseguí usados. Dos libros que me parecieron excelentes fueron «Planning Extreme Programming» de Beck y Fowler y «Extreme Programming Installed» de Jeffries, Anderson y Hendrickson.

Por otro lado, un libro que a simple vista no parece de XP pero que definitivamente lo es, es el libro de James Shore «The Art of Agile Development«. La segunda edición, publicada en 2021, creo que es una descripción muy acertada de lo que podría considerarse un «XP Moderno».

En lo personal, creo que cada vez tiene menos sentido hablar de «métodos/marcos/metodologías» de desarrollo de software. Podemos debatir valores, principios, mindsets y luego bajar a prácticas concretas en las que materialicemos esos valores pero no necesitamos un rótulo para eso. Creo que las combinaciones pre-armadas de «valores + principios + prácticas» empaquetadas bajo un rótulo pueden agregar valor para un equipo/organización que recién empieza, pero a medida que conformamos grupos de trabajo más estables los «combos» agregan cada vez menos valor por el simple hecho de que el grupo de trabajo se convierte en un equipo y empieza a generar sus propias prácticas.

Cierre de cuatrimestre 2023-1 en MeMo2 @ FIUBA

Cerramos un cuatrimestre más con algunas particularidades. Una de las más destacadas fue el horario de cursada: dimos la materia en horario matutino de 8 a 11 hs. Otra de las particularidades fue la relación entre la cantidad de alumnos y la cantidad de docentes que nos permitió dar feedback bastante detallado en las entregas de los alumnos.

El feedback de los alumnos en la encuesta de cierre la cual nos arrojó los siguientes números:

  • La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (10)
  • La evaluación general de la materia (en promedio) dio: 8,8 lo cual es menor que el cuatrimestre anterior (9,1) pero es mayor al promedio histórico (8,4). Adicionalmente el desvío fue mínimo: nadie calificó la materia con menos de 8.
  • Respecto del porcentaje de clases presenciales/virtuales, 9 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,6/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,4/5; Materiales de estudio: 4/5.
  • El NPS nos dio 60 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 60 es muy bueno)

De la restrospectiva de cierre nos quedamos con los siguientes accionables:

  • Agregar un ejercicio individual con el bot para familiarizarse antes del TP2
  • Dar un video o clase mostrando el flow de desarrollo guiado por pruebas desde el bot hasta la api
  • Dar la opción de usar infra gratuita o paga (por los propios alumnos) y considerar también que los propios alumnos gestionen su infra

Algunos otros números:

  • Respecto a la dedicación, tuvimos 28 clases de entre 2 y 3 horas cada una. Por otro lado la dedicación extra clase, en promedio por alumno, fue de un total de 116 horas (51 horas de tareas individuales, 12 horas de tp1 y 53 horas de tp2) repartidas en 16 semanas. Esto nos da unas 7,25 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre. Claro está que en este promedio hay semanas de 2 horas de dedicación extra clase y hay otras de 15 horas.
  • Tuvimos 42 tareas individuales, 1 en parejas y 2 TPs.
  • Tuvimos 14 inscriptos, solo 11 que asistieron alguna clase y finalmente 10 que aprobaron la cursada.
  • La nota promedio de aprobación de cursada fue 8.

Guía Oficial de Scrum, ¡chau!

En mis materias vengo utilizando la Guía Oficial de Scrum pero a partir de dos charlas distintas que tuve con colegas en la última semana he decidido dejar de usarla.

Resulta que una de las modificaciones «recientes» de la guía oficial de Scrum es que elimina los roles. En realidad no elimina los roles conceptualmente, sino que elimina el término «rol» y en su lugar habla de responsabilidades (accountabilities), o sea: «Scrum Master» es un conjunto de responsabilidades, «Product Owner» es un conjunto de responsabilidades, etc. Según me comentaban mis colegas expertos en Scrum (cosa que yo no soy) es para evitar la usual creencia de que las responsabilidades de Scrum Master deben ser tomadas por una única persona y que esa persona debe dedicarse de forma exclusiva a ello. Pero precisamente eso es un rol, «un conjunto de responsabilidades». Entonces si conceptualmente hablamos de roles pero no queremos usar el término roles, creo que lo que se está haciendo es una «precarización» del vocabulario y al mismo tiempo se genera ruido y confusión para aquellos que sabemos lo que es un rol.

Por otro lado tengo la sensación que la guía cada vez tiene menos cuestiones relacionadas al desarrollo de software, posiblemente consecuencia del uso de Agile/Scrum fuera de contexto de IT. Pero dado que lo que estudiamos en mi materias es desarrollo de software, estas nuevas versiones de la Guía de Scrum, me resultan cada vez menos útiles.

Es por esto que de ahora en más ya no usaré la guía oficial de Scrum como material de estudio sino (algunos de) los siguientes materiales:

  • El artículo «Scrum Development Process» de Ken Schwaber de los años 90
  • El libro «Scrum and XP from the treches» de Henrik Kniberg
  • El resumen de Scrum de mi libro «Construcción de Software»

De Chicago a Londres, artículo aceptado

En línea con la estrategia de enseñanza de TDD que seguimos en FIUBA y UNTreF, escribí este artículo que fue aceptado en el Simposio Argentino de Educación en Informática de las Jornadas Argentinas de Informática, JAIIO 52. Al margen de la presentación del artículo que haré en el contexto del Simposio, tengo planeado hacer un charla abierta (meet-up online) para compartir esta experiencia. Si están interesados esten atentos a este canal.

La paradoja de los Ingenieros de Software

Es habitual hoy en día encontrar gente «autodenominándose» Software Engineer sin tener un título formal de ingeniero o disciplina universitaria aledaña. Personalmente no creo que sea una cuestión relevante pues a diferencia de lo que ocurre con otras ingenierías, la ingenieria de software no es una disciplina regulada, o sea: para construir un puente es necesario el aval legal de un ingeniero civil pero para construir un software no es necesario el aval legal de un ingeniero de software.

Por otro lado, algunos de los que somos Software Engineer «con título», dudamos de la denominación «ingeniero» o mejor dicho dudamos de que el Desarrollo de Software deba ser considerado formalmente una ingeniería. He aquí la paradoja:

No ingenieros que quieren ser ingenieros e ingenieros que dudan de serlo

Varios referentes de la disciplina se han pronunciado respecto de este dilema, uno de ellos es David Parnas en su artículo «Software Engineering – Missing in Action: A Personal Perspective«. Otro autor que trata la cuestión es Pete McBreen en su libro Software Craftsmanship.

Esta visión «ingenieril» del desarrollo de software llevó a que las carreras de Ingeniería Informática/Sistemas en Argentina tengan varias materias de ciencia básica (física y química entre otras) compartidas las demás ingenierías. En lo personal y viendo la carrera que yo cursé me hubiera gustando tener menos contenido ciencia básica y más contenido de específico de informática.

En fin, los años pasan y la polémica se renueva.