Infra definida para el TP2 de MeMo2 @ fiuba

Después de varias averiguaciones y algunas pruebas de concepto ya tenemos bastante encaminado el diseño del pipeline e infraestructura del TP2. El sistema a construir consta de dos aplicaciones/artefactos: un bot de telegram y una web-api.

El bot de telegram lo vamos a correr en kubernetes, más precisamente en el servicio de Kubernetes de Azure utilizando la opción Azure for Students ofrecida por Microsoft, la cual incluye 100 dólares de crédito y no requiere de tarjeta de crédito.

Las web-api la vamos a correr en Heroku pero en lugar de usar el modelo de runtime tradicional de Heroku, vamos a correr la aplicación en un contenedor. Esto es: en lugar de hacer push del código fuente directo a Heroku, lo que hacemos es construir una imagen Docker y luego indicar a Heroku que corra un contenedor basado en esa imagen.

Si bien, en términos de infraestructura a bajo nivel, el bot y la api van a correr en distintos runtimes, a nivel proceso ambas aplicaciones correran como un contenedor Docker. Al mismo tiempo el proceso de build y deploy va a ser el mismo para ambas aplicaciones, ofreciendo al equipo de desarrollo una experiencia de trabajo uniforme. En un escenario real es poco probable utilizar una estrategia de este estilo, porque tener dos plataformas de runtime implica un mayor costo operacional pero en nuestro contexto creemos que puede resultar interesante para mostrar explícitamente a los estudiantes como, a partir de ciertas técnicas, es posible lograr un buen nivel abstracción de la infraestructura.

El pipeline de CI/CD lo implementaremos con GitLab utilizando la suscripción Gold que GitLab ofrece para contextos educativos.

Un detalle que me parece relevante mencionar es que, si bien vamos a utilizar productos/servicios de determinados vendors, tenemos la intención de mantener la menor dependencia posible con caraterísticas específicas/propietarias de cada vendor.

En siguientes artículos explicaré como será el modelo de ambientes y pipelines que armaremos tomando esta infraestructura de base.

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.

Sobre nuestra dinámica de aula invertida

En las dos materias que dicto (UBA y UNTreF) utilizamos la misma dinámica de clases. la cual está basada en una estrategia de aula invertida con técnicas de educación centrada en el alumno y evaluación constante. Más allá de las definiciones formales, y en términos concretos, esto implica que cada tema que estudiamos en la materia consta de tres instancias: estudio, aplicación y evaluación.

Aclaración: en las siguiente secciones cuando digo aula me refiero al tiempo/espacio compartido sincrónicamente entre alumno y docente en forma semanal

1. Estudio

Ocurre fuera del aula, el alumno debe sentarse a estudiar, típicamente viendo uno o varios videos o leyendo un texto. Esto reemplaza la típica clase magistral donde el docente expone pasando diapositivas. Es justamente este tipo de clases las que convertimos en videos y que los alumnos consumen fuera del aula.

2. Aplicación

Esto ocurre dentro del aula y puede tomar distintas formas dependiendo del tema en particular, pero siempre intentamos que sea una actividad interactiva. Puede que sea una sesión de mob-progamming o alguna actividad de simulación (como el Pizza Game) utilizando alguna herramienta de soporte como Miro, Mentimeter, Kahoot o similares.

3. Evaluación

La evaluación ocurre también fuera del aula y dependiendo del tema puede ser un ejercicio de programación y/o un cuestionario.

De esta forma cada tema es estudiado y evaluado individualmente. Luego complementariamente tenemos dos trabajos integradores donde los alumnos trabajan en equipos y ponen en práctica todos los temas ya estudiados de forma integrada.

Cierre de un cuatrimestre atípico en MeMo2@fiuba

Cerramos el cuatrimestre de MeMo2@fiuba en una modalidad 100% online y en términos resumidos creemos que estuvo muy bien.

Como herramientas de soporte utilizamos Jitsi para las clases online, Canvas LMS como aula virtual y GitLab como plataforma de desarrollo. En términos descriptivos este cuatrimestre tuvimos:

  • 22 inscriptos, 1 abandono, 21 aprobados
  • 46 tareas individuales que incluyeron 7 ejercicios de programación y 12 cuestionarios con sus correspondientes lecturas y videos
  • 2 trabajos grupales, uno de alcance variable y esfuerzo fijo y otro de alcance fijo y esfuerzo variable
  • 2 visitas de profesionales: Pablo Najt y Matias Gorostegui, gracias a ambos

Más allá de los números hay dos cuestiones interesantes que los alumnos destacaron. Por un lado la predisposición de los docentes para mejorar clase a clase lo cual quedó evidenciado en el hecho de que al final de cada clase les pedimos a los alumnos completar una breve encuesta para tener feedback específico de la clase. Por otro lado la buena adaptación de la materia a la modalidad online, de hecho algunos alumnos nos destacaron como la materia que mejor se adaptó. Siendo sinceros, creemos que no hicimos demasiados cambios para la modalidad online básicamente porque ya teníamos la materia planteada en un modalidad híbrida e invertida, basada fuertemente en el uso del aula virtual y mucho material en video.

De acuerdo a nuestra encuesta interna del curso tuvimos casi los mismos números que el cuatrimestre anterior:

  • Evaluación general del curso: 8.5 / 10
  • Claridad de los docentes: 4.3 / 5
  • Conocimiento de los docentes: 4.8 / 5
  • Dinámica de clases: 4.3 / 5
  • Materiales de estudio: 4.2 / 5
  • Dedicación promedio extra clase: 8.5 hs. semanales
  • Conformidad con la nota de aprobación: 4.4 / 5
  • Nota promedio de aprobación de la materia: 7.8

Por otro, en términos de feedback más general surgido de las encuestas y de la actividad de cierre, nos encontramos con algunos temas recurrentes (como usar python en lugar ruby y tener más cuidado al dar feedback de los ejercicios) y algunos otros temas nuevos (como agregar material sobre object-relation mapping y ver las cuestiones de configuration management antes del TP1).

Finalmente, puertas adentro del equipo docente creo que el trabajo fluyó que en cuatrimestre anteriores y en parte me parece que se debe a implementamos una reunión de de sincronización semanal (la weekly).

Consideraciones para elegir un trabajo final de carrera

En las carreras de informática en Fiuba no hay, a mi entender, una definición lo suficientemente clara sobre los trabajos finales de carrera. Hay documentación, pero no hay una materia (como ocurre en otras universidades) donde los alumnos sean asesorados o tengan algún tipo de seguimiento. El alumno debe encontrar un director para su trabajo y acordar con él un tema.

En este contexto suelo recibir varias consultas de los alumnos y uno de los primeros consejos que les doy es que dejen en claro el objetivo personal que persiguen con el trabajo. Con esto no me refiero a la temática del trabajo sino a su expectativa personal, doy tres posibles ejemplos:

  • Recibirse y listo: la realización del trabajo final es requisito para recibirse y puede que el alumno quiera puntualmente eso. No tiene ninguna expectativa adicional. En este sentido el trabajo final es, en términos de transcendencia, como cualquier otro trabajo práctico de la carrera: una vez evaluado, ha cumplido su objetivo: la aprobación; entonces se archiva y nunca nadie lo vuelve a tocar.
  • Iniciar un emprendimiento: dado que el trabajo final requiere típicamente al menos un cuatrimestre de trabajo, puede ser una oportunidad interesante para aprovechar y hacer que ese trabajo final sea el puntapié inicial de un potencial emprendimiento.
  • Hacer un aporte a la comunidad: otra opción interesante para aquellos con intención de que su trabajo final tenga transcendencia más allá de la aprobación de la carrera es hacer algún tipo de aporte ya sea desarrollando una aplicación para una alguna institución, colaborando con un proyecto open source existente o incluso generando un nuevo desarrollo open source.

Esta es una clasificación muy genérica que no cubre todos los casos. De hecho mi propio trabajo final no entra en ninguna de estas categorías. De todas formas creo que plantearse la pregunta de las expectativas personales puede ser muy útil para definir el tema y sobre todo para armar el plan de trabajo.

Cierre del segundo cuatrimestre 2019 @MeMO2

Completamos una edición más de la materia, en términos estrictos es la quinta, pero dado que la primera solo tuvo 2 alumnos, estoy más inclinado a considerar que esta fue la cuarta.

Personalmente estoy muy conforme con el resultado y flujo de la materia. Y sin duda esto fue posible gracias a un equipo docente conformado por varios ex-alumnos. Además de Emi y yo como docentes nombrados, contamos con la colaboración de JoaquínC, TomasZ, JazminF, AldanaR, NachoI y PabloR. Gracias totales a todo el equipo.

Comenzamos el cuatrimestre con 21 inscriptos en guaraní, pero 2 de ellos nunca asistieron a clase. De los 19 que asistieron la primera semana, 2 abandonaron antes del comenzar con los trabajos grupales. Los 17 restantes completaron la materia.

En términos generales no hicimos cambios mayores respecto de lo que fue el primer cuatrimestre. Tuvimos:

  • 18 tareas individuales que incluyeron varios ejercicios de programación y unos 10 cuestionarios con sus correspondientes lecturas y videos
  • 2 trabajos grupales, uno de alcance variable y esfuerzo fijo y otro de alcance fijo y esfuerzo variable
  • 2 visitas de profesionales de la industria, Fede Diaz y Diego Sánchez, gracias a ambos

En feedback de los alumnos fue muy positivo y entre los accionables de mejora identificamos:

  • Hacer algún repaso tipo cierre de cada tema luego del cuestionario comentando los puntos destacados
  • Dar lecturas más cortas / enfocadas
  • Hacer una actividad para que los alumnos presenten sus propias experiencias profesionales
  • TP: Intentar que las iteraciones sean de jueves a jueves
  • TP: Durante el TP2 dedicar los lunes a repasar/acordar las especificaciones y ejemplos

Finalmente comparto algunas estadísticas de la encuesta final del curso completada por los alumnos (estos números son de la encuesta interna, los resultados de la encuesta que realiza el departamento aún no están disponibles):

  • Evaluación general del curso: 8.5 / 10
  • Claridad de los docentes: 4.7 / 5
  • Conocimiento de los docentes: 4.9 / 5
  • Dinámica de clases: 4.1 / 5
  • Materiales de estudio: 4.1 / 5
  • Dedicación promedio extra clase: 9 hs. semanales
  • Confirmidad con la nota de aprobación: 4.1 / 5

La nota promedio de aprobación de la materia fue 8 (desvío 0.96).

Estadísticas del nuevo cuatrimestre en MeMo2

Ya hemos completamos la segunda semana de clases. Tenemos 18 alumnos y un equipo docente con 2 profesores y 6 colaboradores, con lo cual deberíamos poder tener un flujo de seguimiento mejor que el cuatrimestre pasado.

Comparto aquí algunas estadísticas del perfil de alumnos que resultan llamativas:

  • Más del 70% de los alumnos ya están trabajando en alguna actividad afín a la carrera
  • Hay una variación muy grande en la cantidad de materias aprobadas: el alumno con más materias aprobadas tiene 33, mientras que el que tiene menos tiene 17

Condición laboral

Cantidad de materias aprobadas

Cantidad de materias aprobadas

Preparando MeMo2, 2019-2c

Luego un muy buen primer cuatrimestre tenemos la vara más alta para este segundo. A partir del feedback obtenido en las encuestas y las retros con alumnos y con el equipo docente tenemos en mente lo siguiente:

  1. Creemos que la dinámica general de la materia funciona muy bien, con lo cual la mantendremos y solo haremos pequeños ajustes en cuestiones puntuales.
  2. A pesar de que algunos ya confirmaron que no podrán, continuaremos con ex-alumnos en el equipo docente (se están sumando 4 nuevos colaboradores). Esto, además de ayudarnos con la carga de trabajo, también nos permite tener una mirada distinta dentro del equipo docente. Al mismo tiempo es un manera de formar futuros docentes.
  3. Mantendremos el stack de herramientas de soporte (eso es: Google Groups, Canvas Campus y GitLab) e intentaremos incorporar el uso de Kahoot.
  4. También mantendremos el stack de desarrollo con Ruby/Sinatra/Padrino, aunque actualizaremos a Ruby 2.5.1
  5. Renovaremos los ejercicios y el TP final, aunque muy posiblemente mantendremos el JobVacancy como TP1
  6. Vamos a realizar algunos ajustes en la dinámica de los ejercicios de programación individuales y en su corrección. Queremos que las correcciones y el feedback sean más uniformes. Para esto último tenemos que trabajar internamente para generar más guías y rubricas para las correcciones y también vamos a intentar implementar un mecanismo de revisión de correcciones entre los docentes.

Como para cerrar quiero destacar algunos puntos relevantes para quienes planeen cursar este segundo cuatrimestre de 2019:

  • La asistencia a clase es obligatoria y por ende la controlamos
  • La materia es intensa, require de una dedicación constante a lo largo de todo el cuatrimestre lo cual implica unas 8 horas semanales de trabajo extra-clase.
  • Si bien no tenemos el tradicional mecanismo de evaluaciones parciales en papel, el sistema de evaluación que utilizamos genera menos tensiones de parte de los alumnos, pero al mismo tiempo requiere mayor disciplina y dedicación.
  • Las clases comienzan 19.00 (puntual)
  • La primera clase será el Jueves 22/8, ¡no falten! la primera clase siempre es muy importante para setear expectativas)

Cierre MeMo2 2019-1

Se fue un cuatrimestre más y es momento de análisis. Comencemos por los fríos números:

  • 32 inscriptos (34 formalmente pero 2 nunca asistieron a clase)
  • 3 abandonos antes de la sexta semana
  • 23 alumnos completaron la materia con promoción
  • 5 alumnos pendientes de final
  • 19 tareas individuales (11 cuestionarios y 5 ejercicios de programación)
  • 2 TPs grupales
  • 1 visita de la industria
  • Evaluación general de la materia: 8.9 (según encuesta interna)
  • Opinión general de la materia: 4.6 (según encuesta del departamento)
  • Claridad de los docentes (según encuesta interna): 4.8 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.9 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 4.3 / 5
  • Dedicación promedio extra clase (según encuesta interna): 8 hs. semanales

Por otro, más allá de los números la sensación es muy positiva. Basado en el feedback recibido tanto en las encuestas como en las retrospectivas creo este resultado es consecuencia de 3 puntos destacados:

  • Un cambio de orden en los temas de la materia poniendo más foco inicialmente en cuestiones de programación. Esto a mi parecer facilitó en entendimiento de los temas de proceso y el desarrollo de los TP grupales.
  • La incorporación de ex-alumnos al equipo docente. Si bien una ex-alumna había colaborado en algunas cuestiones el cuatrimestre anterior, esta vez con contamos con varios ex-alumnos que colaboraron a lo largo del todo el cuatrimestre.
  • La temática del TP final que incluyó el desarrollo de un Bot de Telegram. Creo que esto generó cierta motivación entre los alumnos.

No están en la foto los ex-alumnos que participaron como colaboradores: Jessica, Josefina, Anarella, Facundo, Pablo y Martín.

Notas sobre el nuevo plan de Ingeniería en Informática de @fiuba

Notas sobre el nuevo plan de Ingeniería en Informática de @fiuba

En el marco del Plan 2020 la Facultad de Ingeniería de la UBA está haciendo nuevos planes de estudio para todas las carreras entre las cuales están la Ingeniería en Informática y la Licenciatura en Análisis de Sistemas. El plan de la licenciatura es bastante nuevo (2015) pero el de la ingeniería no. Salvo algunas modificaciones menores el plan actual de la Ingeniería en Informática es el mismo plan con el que estudié yo a fines de los 90′.

Hace un par de semanas asistí una presentación que realizó la comisión curricular que está trabajando en el nuevo plan de Ingeniería en Informática.

En términos generales me gustó la forma que va tomando en nuevo plan. Comparto algunas observaciones al respecto.

Al comienzo de la presentación mencionaron algo así como que “los egresados de nuestra carrera están muy bien vistos en el mercado por su formación”. Comparto parcialmente: creo que efectivamente hay una muy buena percepción/desempeño de nuestros egresados, pero no estoy tan seguro que sea por la formación académica. Creo que esto es en gran parte por cuestiones “accidentales”, creo que nuestros egresados son en primer lugar gente perseverante, que está acostumbrada a lidiar con dificultades (materias con horarios que se superponen, docentes “dificultadores”, paros, recursos limitados y demás cuestiones extra académicas). Creo que esa capacidad de luchar y superar la adversidad contextual es lo que representa un diferencial en el egresado de fiuba. En cierto modo esto es lamentable, yo quisiera que nos destacaremos por la formación académica, pero me parece que actualmente no es así (vengo con esta idea desde hace ya varios años).

También se mencionaron los distintos factores que tuvieron presentes para la conformación del nuevo plan. Me resulto llamativo que no hayan mencionado el tema de las deserciones. Yo tengo la sensación de que el ratio ingresantes/egresados es muy malo y creo que también que hay una cantidad no menor que abandona cuando le falta solo la tesis/TP.

Respecto del esquema de materias me gustó y aunque parece que la parte de Ingeniería de Software (que es mi área) ha sido reducida, no me parece mal porque creo que ciertos temas de la ingeniería de software deben versen en forma transversal (por el ejemplo el tema testing y ciertos aspectos de planificación/organización).

Sentí cierta decepción al ver que la carga de materias de ciencia básica es todavía muy alta. Se eliminó Quimica 1, pero se agregó Matemática Discreta (que me parece bien) y se mantiene Análisis Matemático 3 (yo que la hubiera dejado como electiva). También se mantienen Fisica 1 y 2 (espero que al menos eliminen los contenidos repetidos entre Física del CBC y Física 1).

Entre las novedades que me resultaron más relevantes están:

  • La inclusión de Teoría de Algoritmos y Arquitectura de Software como materias obligatorias
  • La inclusión de contenidos de seguridad en forma transversal en varias materias
  • Una nueva materia llamada Infraestructura con foco en virtualización, cloud, etc.

Por otro lado tuve algunas charlas informales con miembros de la curricular que trabaja en el plan 2020 de la licenciatura y según me comentaron, el nuevo plan no tendrá modificaciones muy relevantes ya que el plan actual es bastante nuevo.

Con estos nuevos planes parece decantar que la Licenciatura en Análisis de Sistemas ofrecerá una sólida formación en cuestiones de Ingeniería de Software mientras que la Ingeniería en Informática formará gente con perfil más técnico. De todas formas hay que destacar que cada alumno tiene la posibilidad de armar su propio perfil a partir de la materias electiva que elija.