Hoy sí marcho, #UniversidadPública

No suelo hacer paro ni tampoco marchar en movilizaciones. No es que no adhiera a los reclamos que motivan estas acciones, sino que simplemente no terminan de convencerme este tipo de expresiones. Dudo de su efectividad.

Sin embargo hoy sí marcho porque creo que estamos en un situación insostenible, sin precedentes y muy riesgosa. No para mí en particular sino para nuestra sociedad en general. Los hechos concretos son que los salarios docentes (y creo que los no docentes también) no han tenido actualizaciones relevantes y acorde a la inflación del último año. Esto ha provocado una pérdida muy importante del poder adquisitivo. Asimismo ha traído como consecuencia que ya tengamos docentes dejando sus puestos en la universidad pública, ya sea para trabajar en universidades privadas o incluso en universidades del exterior. Y ni hablar de la situación de los investigadores. Conozco casos concretos, con nombre y apellido, y temo que este fenómeno se generalice. Aún cuando el gobierno diga que no piensa cerrar las universidades públicas, la realidad es que las está desfinanciando (al igual que hace con otros sectores).

Sin duda hay cuestiones a mejorar pero la actitud del actual gobierno no va en línea a mejorar nada. La universidad pública, a pesar de todas las falencias que pueda tener, ha sido siempre uno de los pocos caminos de movilidad social e igualación de oportunidades. Y esto para mí está hoy en día en riesgo.

Claro que uno puede entender la situación «excepcional» del país, pero sinceramente parece que la cuestión se extiende mucho más allá. El gobierno actual, no solo no otorga financiamiento suficiente sino que tampoco da visibilidad hacia adelante. Creo que la situación podría ser distinta si el gobierno dijera «hoy no hay plata y debemos ajustar, pero el año próximo restauraremos el presupuesto«, pero no es el caso, ya que en el presupuesto presentado para el año próximo nada se ve de esto. A esto se suman las mentiras de los funcionarios que pretenden desacreditar el reclamo y que no hacen más que generar violencia. Comparten cifras incorrectas que nada tienen que ver con la realidad.

Y no me vengan con ganzadas del tipo «¿Y porque no te marchaste contra gobiernos anteriores?«, porque la situación actual no tiene precedentes como tampoco la tiene la actitud impresentable de los funcionarios hablando sin saber y mintiendo.

Trabajo en la universidad pública desde hace más de 20 años. Vengo haciendo toda la carrera docente escalón por escalón. Comencé como colaborador no rentado, luego fui ayudante de segunda (mientras era estudiante), ayudante de primera (cuando me recibí), concurse como JTP y finalmente hoy en día soy profesor adjunto. Actualmente trabajo en dos universidad públicas (UBA y UNTreF), en un caso con dedicación simple y en el otro semi-exclusiva, son unas 30 horas semanales que reparto entre docencia, investigación y extensión. Tengo excelentes evaluaciones de los cursos a mi cargo, dirijo trabajos finales de carrera y colaboro en el consejo asesor del departamento. Desde el año 2016 trabajo en investigación, publicando consistentemente 2 o 3 artículos artículos formales cada año. Así y todo, mi salario apenas llega a cubrir la canasta básica. No es sostenible. Personalmente tengo la posibilidad de trabajar en el sector privado y hoy en día la informática es una actividad muy bien paga, pero no ocurre lo mismo con todas las disciplinas. Hoy colegas que la están pasando muy mal y lo que se está destruyendo hoy en día puede llevar mucho tiempo recuperarlo.

Es por todo esto, por mis colegas docentes, por mi estudiantes, por mis hijos y por nuestra sociedad que hoy marcho a defender la universidad pública.

Libro: Hexagonal Architecture Explained

Hace un par de días terminé de leer este libro, escrito por el mismo Alistair Cockburn, descubridor de este patrón. Curiosamente la publicación inicial fue hace unos 20 años en algunos artículos informales. A lo largo de todos esto años fueron apareciendo diversas publicaciones sobre la arquitectura hexagonal, algunas de ellas del propio Alistar, pero recién hace un par meses fue publicado este libro.

El libro está muy bien. Explica claramente la técnica/patrón, no solo desde un punto de vista práctico y con ejemplos de código sino también desde un punto de vista conceptual.

Lo leí en el kindle con lo cual no tengo en claro la extensión del libro pero creo que aproximadamente la mitad del libro son reproducciones de artículos previamente publicados con algunas correcciones/comentarios. No pretendo hacer un juicio sobre esto, solo describo el hecho.

Una cuestión que me gustó mucho del libro es que deja bien claro el alcance del patrón lo cual me parece muy necesario ya que he visto muchas publicaciones de otros autores incluyendo cuestiones que claramente no son parte del patrón. Un ejemplo muy habitual de esto es decir que el interior del hexágono (o sea la lógica de negocio) se estructura de acuerdo a un estilo Domain-Driven Design, algo que yo suelo hacer pero que está más allá de la arquitectura hexagonal, o sea, la arquitectura hexagonal no se mete en qué hacemos dentro del hexágono.

En lo personal creo que si alguien pretende simplemente aplicar la arquitectura hexagonal en un proyecto, no necesita leer todo el libro, posiblemente con leer la primera parte o algunos de los artículos (recientes) del propio Alistair puede ser suficiente. Sin embargo, para aquellos curiosos que quieran ir más allá y hacer el ejercicio de profundizar en el patrón, sus implicancias y sus conexiones, este libro es un pieza fundamental.

Mis Notas de la 10 Pines Conf 2024

El viernes pasado estuve participando de la 10 Pines Conf, un evento cerrado para miembros de 10 Pines y algunos invitados externos, que desde hace un par de años la gente de 10 Pines organiza con motivo del día del programador.

Más allá de escuchar muy buenas charlas, tuve la oportunidad de reencontrarme con varios colegas, algunos de ellos ex-alumnos de mis materias/cursos.

Una curiosidad que me llamó la atención es que hoy en día hay en 10 Pines varias personas que fueron alumnos mios en distintos contextos (UBA, UNTreF y UNQ).

De todo lo que escuché hubo 2 charlas que me gustaron mucho. La que dió EmilioG sobre LiveView Native, una herramienta del ecosistema Exilir/Phoenix para crear aplicaciones móviles. Una de las cuestiones que me más me gusto de la charla es que Emilio arranco haciendo una demo en vivo y recién luego de eso explicó como funcionaba la herramienta. La otra charla que me gustó mucho fue la que dieron FacuG, ErnestoA y LucasW que contaron su experiencia haciendo un plugin de IntelliJ, mucha data valiosa.

Una cuestión interesante de esta conferencia es que la hacen en la oficina de 10 Pines utilizando las salas de reuniones. Esto hace que el orador esté sentando a la mesa junto con su audiencia. De esta forma las charlas son «chicas» generando cierto ambiente de cercanía con el orador y permitiendo a todos preguntar y profundizar en algunas cuestiones. En línea con esto, en la charla de Emilio no éramos más de 10 personas mientras que en la de FacuG, rondaba las 20 (con gente de pie alrededor de toda la mesa.)

Agradezco a EmilioG por la invitación y ojalá tengamos muchas más 10 Pines Conf (y también me inviten 😉 )

City Building Game @ UNTreF

El martes pasado en mi curso de Ingeniería de Software hicimos este juego como actividad para poner en práctica un proceso «Scrum-like». Este juego fue diseñado por mis colegas Alejandra Alfonso y Emilio Gutter.

En general veníamos usando el juego del Pajarraco Scrumero porque teníamos grupos chicos (no más de 10 alumnos), pero este cuatrimestre tenemos 30 alumnos y nos pareció que el City Building escalaba mejor que el Pajarraco. Y creo que no nos equivocamos. Si bien en alguna conferencia hemos hecho el Pajarraco con unas ~80 personas, en ese caso contábamos con muchos materiales y varios facilitadores. El Pajarraco requiere de materiales muy específicos (ladrillitos tipo Rasti) mientras que el City Building básicamente requiere de elementos de librería (tijeras, papel y pegamento) que son más fáciles de conseguir.

Lamentablemente Emilio y Alejandra no hay publicado el juego aún. Sin embargo cuando le comenté a Emilio que estaba escribiendo este post, me prometió en breve publicar todos los detalles del juego, así que los interesados pueden contactarlo directamente a él.

Cierro con algunas modificaciones que hicimos al guión original del juego:

  1. Descartamos el papel glase, lo reemplazamos por papeles de colores (tipo los de taquitos de oficina), hojas blancas y lápices.
  2. De la mano de lo anterior agregamos un nuevo rol a los equipos: el pintor.
  3. Solo 4 minutos de iteración nos pareció muy poco, creemos que sería mejor hacer iteraciones de 5 o 6 minutos.
  4. Redujimos el número de tijeras por equipo, creemos que salvo el cortador de círculos, los otros cortadores se pueden arreglar para cortar «a mano».

Sobre el ascenso y la caída de Agile, una opinión más

Me acerqué a agile allá por 2003. A diferencia de mucha otra gente, no me acerqué via Scrum sino via XP. Comencé a aplicarlo en proyectos hacia 2005. Pero no fue hasta 2008 que empecé a ver crecer el movimiento más allá de mi entorno. Conferencias, Meet-ups, Cursos, Certificaciones y oportunidades laborales.

Eso llamado «Agile» parecía funcionar, generaba interés, gente y empresas con ganas de «comprar». Una demanda creciente, una oportunidad de negocio. Un negocio. Y la demanda de agile no paraba de crecer. Y creció en diversas dimensiones. Por un lado agile traspasó las áreas de IT (donde inicialmente había surgido) y por otro lado gente de otras disciplinas se metió en IT. Agile coaches y Scrum Masters eran demandados por todos lados. Con esa demanda también florecieron aquellos vendiendo formación de Agile coaches y Scrum Masters. Alguno estuvieron mucho más preocupados por la venta que por la formación. Y Agile coaches y Scrum Master comenzaron a aparecer por todos lados. El agile industrial complex (Martin Fowler dixit)en su máxima expresión. Un fenómeno del cual fui (¿soy?) parte.

En un momento la torta comenzó a escasear, la tortilla se dió vuelta. Agile comenzó a perder credibilidad, a ser «mala palabra» para algunos y «puro cuento» para otros. Y los puestos de Agile Coaches y Scrum Master quedaron el ojo de la tormenta. Alguien le llamó «la crisis de la agilidad».

No sé en qué va a terminar esto, solo puedo decir que de los 3 equipos con los que trabajé en lo que va del año, el que mejor desempeño tiene es precisamente el que no tiene una persona exclusiva en el rol de scrum-master/coach 🤷‍♂️

FIUBA: un graduado aportando valor a la sociedad

Hace unas semanas completó su trabajo final de carrera, el ahora Licenciado en Sistemas, Joaquin Casal. Tuve el honor de ser tu tutor a lo largo del desarrollo de su trabajo. Conozco a Joaquín desde hace varios años, fue alumno de MeMo2 y luego de completar la materia se sumó al equipo docente.

El objetivo del trabajo de Joaquín fue desarrollar una aplicación para la fundación Hemocentro. El trabajo fue un desarrollo punta a punta en el sentido de que incluyó desde el análisis hasta la construcción y puesta en producción.

En lo personal estoy muy conforme contento y conforme con el trabajo realizado por Joaquín, ha sido un honor poder colaborar con él. La aplicación desarrollada quedó funcionando operativamente, resolviendo un problema de una organización concreta y ejecutándose en la plataforma Azure.

Para quienes que quieran darle una mirada todo el proyecto está disponible bajo licencia de código abierto en Github.

El trabajo final de carrera suele ser un desafío para los alumnos. De hecho resulta curioso que muchas veces el desafío pasa más por encontrar el tema más que por llevarlo adelante. En ocasiones los alumnos terminan haciendo un desarrollo, que al igual que suele ocurrir con cualquier TP, sirve para aprobar pero luego no tiene ningún uso ni impacto, no agrega valor a nadie. Es por ello quiero que destacar el trabajo realizado por Joaquín porque más allá de haberse recibido, implementó una solución que agregar valor a una organización de la sociedad civil. ¡Felicitaciones Joaco!

Cierro con algunos números del trabajo:

  • Horas trabajadas: 260
  • Duración calendario: 8 meses
  • Cantidad de iteraciones/semanas: 33
  • Cantidad de historias de usuario resueltas: 86
  • Cantidad de tests automatizados: 422
  • Cobertura: 90%

Foto realizada al final de la presentación del trabajo: Joaquín, yo y las usuarias (Natalia y Paula).

Diplomatura en Ingeniería de Software Continua: charla informativa 2024-2

Ya está abierta la inscripción para la Diplomatura en Ingeniería de Software Continua que dictamos en UNtreF junto a Diego Fontdevila, Carlos Fontela, Andrés Diaz Pace, Diego Marcet y Federico Casuscelli.

En estos días estamos completando la primera cohorte de graduados (nos falta cerrar notas de una de las materias) pero al margen de ese detalle ya hemos tenido muy buen feedback de los estudiantes y estamos trabajando en algunas mejoras de cara a la nueva cohorte que comenzará en septiembre.

Como de costumbre vamos a hacer una charla informativa para contar sobre los contenidos, forma de cursada, etc y atender consultas de los potenciales alumnos. Dicha charla será este miércoles 31 de Julio a las 9:30 hs hora argentina (aclaro que es hora argentina por que al ser una carrera 100% online ya nos ha pasado de tener estudiantes de diversos paises).

Los interesados en participar de la charla informativa pueden completar este formulario y les enviaremos el link de acceso.

La materia faltante en la universidad

Una problemática cotidiana de los sistemas de software es el mantenimiento y evolución de los mismos. Es común encontrar en los planes de estudio diversas técnicas para aplicar durante el desarrollo inicial del software de cara a facilitar su futuro mantenimiento y evolución.

Pero es poco habitual para los estudiantes tener que lidiar con el mantenimiento y evolución de código existente. Más aún, es poco habitual que los alumnos tengan que trabajar con código ajeno. No me refiero a tener que utilizar componentes desarrollados por otros sino a tener que modificar código escrito por otros.

Las técnicas para mantener y evolucionar código ajeno no son necesariamente las mismas que las que se utilizan para facilitar el futuro mantenimiento y evolución. Más aún, esas técnicas son tanto de índole técnico como también de índole de gestión.

Algunas de estas cuestiones intentamos cubrir en MeMo2@fiuba. Justamente cada vez que doy estos temas vuelvo sobre esta idea de tener una materia exclusivamente centrada en «código legacy».

Al mismo tiempo creo que estudiar estas técnicas requiere de aplicación práctica, no basta con estudiarlas teóricamente. Esto es lo que me lleva a pensar que es necesario una materia para lidiar con esta problemática.

No estoy seguro que sea una materia para estudiar en un carrera de grado, por el simple hecho de que me parece necesario que antes de abordar estos temas, los estudiantes dominen cuestiones Ingeniería de Software y también (sobre todo) tengan cierta experiencia de aplicación en «mundo real».

Cierre de cuatrimestre 2024-1 en MeMo2@fiuba

Terminó el cuatrimestre y es tiempo de análisis. Fue un cuatrimestre un poco más intenso que lo habitual, en parte por la cantidad de alumnos (tuvimos el doble de alumnos que el cuatrimestre anterior) y en parte por el perfil de los alumnos (distinto al habitual).

Comenzamos el cuatrimestre con 24 alumnos, 3 de los cuales abandonaron antes de la semana 7. Al momento de comenzar el TP2 tuvimos una baja más. De los 20 alumnos que comenzaron el TP2, 18 aprobaron la cursada de la materia.

Tuvimos 38 tareas individuales que incluyeron:

  • 7 cuestionarios
  • 8 ejercicios de programación
  • 12 videos
  • 9 lecturas
  • 2 tareas nivelación / setup

Usamos la misma infraestructura que el cuatrimestre pasado, varios servicios de suscripción gratuita/académica (gitlab, render, neon, etc) y pagamos por algunos otros, concretamente invertimos unos 40 dólares en un pequeño cluster de Kubernetes en Digital Ocean.

Si bien aún no hicimos la retrospectiva del equipo docente, creo que en general estamos conformes con el resultado. También creo que el cambio del perfil de los alumnos va a requerir algunos cambios en la materia, principalmente dedicar un más tiempo a algunos temas (modelado y arquitectura) y generar nuevos materiales de estudio.

Comparto algunos números de la encuesta de cierre de la materia:

  • La encuesta fue contestada por 17 alumnos (sobre 20 que completaron el curso)
  • La evaluación general de la materia en promedio dio 9.0 (igual que el cuatrimestre anterior)
  • Respecto del porcentaje de clases presenciales/virtuales, 14 alumnos lo consideraron apropiado mientras que 2 alumnos hubieran preferido más presencialidad y solo 1 hubiera preferido más virtualidad.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas; claridad de los docentes: 4,7/5; Conocimientos de los docentes: 5/5; Dinámica de las clase: 4,6/5; Materiales de estudio: 4,5/5.
  • La dedicación semanal a la materia extra-clase dio un promedio de 8,9 lo cual me parece puede estar un poco distorsionado por la últimas semanas en las que los alumnos trabajaron en el trabajo final.
  • El NPS nos dio 70 (esta es una métrica que puede tomar valores en el rango -100 +100)

Algunos otros puntos para destacar de este cuatrimestre:

  • Creo que logramos mantener la dinámica y calidad del curso a pesar del incremento de la cantidad de alumnos y su cambio de perfil.
  • Tuvimos muy buen feedback de las clases presenciales.
  • En el feedback libre de la encuesta de cierre un alumno escribió: «La materia es interesante, le da un enfoque serio a algo que durante la carrera había considerado chamuyo/humo.«

Desafíos y recomendaciones para la enseñanza de TDD

Recientemente nos notificaron de la aceptación de este artículo para ser presentado en el track de educación de la conferencia CLEI 2024.

Este artículo es resultado de un trabajo de investigación de varios meses. El mismo consistió en entrevistar diversos expertos, docentes y entrenadores de TDD para entender los principales desafíos y recomendaciones para su enseñanza. Una vez realizadas las entrevistas aplicamos una técnica llamada análisis temático para extraer, analizar y sumarizar lo dicho por los entrevistados.

Los 3 desafios más mencionados fueron:

  • La falta de conocimiento previo (por ejemplo separación de incumbencias)
  • La dificultad para hacer el cambio de mindset (test last -> test first)
  • La complejidad técnica (por ejemplo al tener que lidiar la UI)

Al mismo tiempo las 3 recomendaciones más importantes fueron:

  • Que los estudiantes hagan mucha práctica
  • Que el docente/entrenador sea un practicante
  • Explicar los beneficios

Más allá de los 6 puntos mencionados, el trabajo de investigación nos dejó varias cuestiones para profundizar. Entre ellas un punto que en un punto puede resultar llamativo: el lenguaje de programación utilizado para enseñar no parecer ser una cuestión relevante. Al mismo tiempo más de un entrevistado hizo referencia al uso de Gherkin.

Si alguien está interesado en leer el artículo completo puede contactarme aquí.