Manejo de información sensible con git-secret

Es habitual cuando hacemos aplicaciones tener que lidiar con información sensible como ser contraseñas y tokens de acceso. A esta información sensible se le suele llamar secretos. En la actualidad la práctica habitual es almacenar estos secrets en herramientas creadas específicamente para ello y que suelen llamarse Administradores de Secretos (Secret Managers) o Bóvedas.

Algunas nubes proveen soluciones propietarias para esta cuestión como es el caso de AWS Secret Manager y Azure Key Vault pero también existen soluciones open source como Vault que pueden instalarse on-prem. Usando estas herramientas uno puede guardar en ellas su información sensible (secretos) y luego conectar al administrador de secretos con los ambientes donde quiere usar dicha información.

Pero también existen un conjunto de herramientas que posibilitan guardar secretos en repositorios Git, una práctica no muy recomendada. Estas soluciones son extensiones y/o complementos de Git y lejos están de compararse funcionalmente con los administradores de secretos, pero para proyectos personales, chicos o no críticos, son una opción completamente válida. Básicamente estas soluciones toman los archivos con la información sensible y le aplican algún tipo de encriptación de forma tal que quedan almacenados en Git pero estando encriptados. Soluciones de este tipo son git-crypt y git-secret. Es precisamente esta última herramienta la que vengo usando. A continuación voy a compartir de forma resumida como funciona.

La herramienta funciona como una extensión de Git y en conjunto con GPG, o sea: necesitamos instalar GPG (dependiendo del sistema operativo puede que ya venga instalado) y git-secret (las instrucción de instalación de git-secret son muy simples y están publicadas en su página oficial).

Una vez que tenemos la herramienta instalada podemos ir al repositorio git donde queremos agregar información sensible y lo primero que debemos hacer correr el comando git secret init para indicarle a git-secret que queremos guardar información sensible en el repositorio en cuestión. Este comando va a crear un directorio .gitsecret que será utilizado por git-secret.

A continuación vamos a indicarle a git-secret nuestro mail (asociado a nuestra clave pública gpg) para que podamos tener acceso a la información sensible que guardemos en el repositorio. Esto lo hacemos con el comando git secret tell nicopaez@mimail.com.

A esta altura ya estamos en condiciones de comenzar a agregar información sensible. Supongamos entonces que tenemos un archivo con información sensible llamado secretos.txt y entonces queremos indicarle a git-secret que queremos que maneje este archivo para lo cual ejecutamos git secret add secretos.txt. Un efecto de este comando es que el archivo secretos.txt, que tiene la información sensible sin encriptar ha sido agregado al gitignore porque precisamente no queremos que git lo versione.

El siguiente paso es «ocultar» (encriptar) la información sensible ejecutando git secret hide. Este comando generará un archivo encriptado por cada uno de los archivos que hayamos agregado previamente como secretos. En este caso, se habrá generado un archivo secretos.txt.secret que contendrá la información encriptada del archivo secretos.txt. y que podrá ser agregado sin problemas al repositorio git (es seguro hacerlo porque su contenido está encriptado). El último paso es hacer git add y commit con el archivo secretos.txt.secret.

Resumiendo como queda la historieta:

  • el archivo secretos.txt.secret contiene nuestra información sensible encritada y está versionado en nuestro repositorio git. Toda persona con acceso al repositorio podrá acceder al archivo, pero al estar este encriptado, no podrán ver si contenido.
  • el archivo secretos.txt, no está versionado por git y solo existe localmente en mi máquina para poder ser utilizado por mi aplicación.
  • Si yo me clonara otra vez el repositorio, no tendría el archivo secretos.txt (pues no está versionado en el repositorio) sino que tendría que generarlo a partir de ejecutar git secret reveal. Este comando toma los archivos encriptados (en este caso secretos.txt.secret) y los desencripta. Obviamente para poder hacer esto, el usuario en cuestión tiene que tener permisos para acceder a la información sensible (esto se hace con el comando git secret tell que ya ejecutamos previamente y que a continuación explicaré con mayor detalle.

Hasta aquí tenemos la configuración inicial, con esto de ahora en más cada nuevo archivo con información sensible (o cada modificación) deberemos ejecutar git secret add y git secret hide y a continuación el usual git add y git commit.

Una última cuestión es cómo compartir esta información sensible con otros miembros del equipo. Para esto vamos a necesitar la clave pública gpg de la persona a quien querramos dar acceso (esa persona deberá exportar su clave haciendo gpg –armor –export your.email@address.com > clave_publica_de_un_colega.gpg). Dicha clave será típicamente un archivo que en primer lugar tendremos que importar con gpg haciendo gpg —import clave_publica_de_un_colega.gpg. Teniendo la clave importada podremos dar acceso a la persona en cuestión ejecutando git secret tell colega@email.com. Finalmente el último paso, que es fundamental, es reencriptar todos los secrets, para esto primero haremos un git secret reveal y a continuación un git secret hide -d.

Bien, esto es todo. Si deciden utilizar la herramienta para algún proyecto (más allá de probar lo que describí en este artículo) les recomiendo ver la documentación oficial de la herramienta.

4 confusiones habituales sobre TDD

Recientemente hablaba con un cliente sobre TDD y su poco uso en la industria a pesar de sus probados beneficios. Durante la charla me encontré, sin haberlo meditado previamente, hablando sobre confusiones habituales respecto de TDD que a mi parecer le juegan en contra.

La primer confusión, y posiblemente la más común, es confundir TDD con una técnica de testing. TDD no es una técnica de testing, como su nombre lo indica es un técnica de desarrollo. Al creer que es una técnica de testing, hay desarrolladores que directamente la dejan de lado (sin siquiera probarla) pensando que no es para uso de los desarrolladores sino para el uso de los testers :-(. Algo que aporta a esta confusión es que en algunas instituciones TDD es estudiado en materias de testing/calidad en lugar de materias de diseño/desarrollo. A favor de los confundidos admito que el nombre (Test-Driven Development) a pesar de ser preciso, puede resultar confuso.

Otra confusión que he visto reiteradamente en quienes comienzan/intentan utilizar TDD es ir directo al código sin absolutamente ningún ejercicio de diseño preliminar . La técnica es muy explícita en cuanto a comenzar por los tests y trabajar en pequeños incrementos. Pero ello no significa que no pueda (¿o deba?) hacer un poco de diseño preliminar, haciendo incluso algún diagrama y pensando en el diseño «final» (o diseño a mediano/largo plazo). En una época (allá por los ’90) había gente que hacía diseños muy detallados y luego pasaba de una a intentar implementar esos diseños en código. Luego de esa experiencia poco feliz, algunos se fueron al otro extremo sin siquiera pensar un poco antes de saltar al código. En lo personal siempre me gusta comenzar haciendo un diagrama del dominio del problema antes de saltar al código. Al mismo tiempo, cuando salto al código no es para implementar de una el dominio completo, sino que la implementación del dominio la hago incrementalmente generando incluso versiones reducidas/incompletas pero entregables al usuario. De esta forma puedo llegar a generar varias versiones de cara al usuario antes de tener materializar la visión inicial del dominio (que por cierto, es una visión que va evolucionando a medida que voy aprendiendo más del dominio).

Omitir premisas de la técnica es también una error habitual. TDD no es solamente comenzar por la prueba, hay varias cuestiones más y entre ellas una fundamental es trabajar en pequeños incrementos. Al no trabajar en pequeños incrementos, las pruebas que escribimos pueden ser más grandes/complejas y requerir mayor esfuerzo para hacerlas pasar. Al mismo tiempo podemos estar complicando el diseño (y la implementación) innecesariamente.

Finalmente, algunos creen que al hacer TDD no es necesario un esfuerzo de testing posterior y entonces no es necesario contar con la colaboración de testers en el proceso de desarrollo. Dado que TDD no es una técnica de testing, necesitamos testear nuestro software más allá de que hallamos hecho TDD. Obviamente que las características de ese testing van a ser distintas dependiendo de si el software fue desarrollado haciendo TDD o no. De entrada, si hicimos TDD el esfuerzo de testing posterior va a ser mucho menor pues varios casos ya van a estar testeados. También debemos tener presente que los tests generados en el ciclo de TDD son distintos a los tests que un tester realiza a posteriori, esto es así porque el objetivo de unos y otros tests es distinto. Más aún, TDD es una técnica surgida en un contexto Agile donde el rol de tester es radicalmente distinto a rol del tester en un contexto «tradicional» (no Agile) pero esto es material de otro artículo.

Libre recomendado: Wild West to Agile

Hace unos días terminé de leer este libro. Simplemente excelente. Su autor es Jim Highsmith, uno de los autores del Manifiesto Ágil. Jim ha escrito más de un libro y muchos artículos que nunca leí. Esa fue una de mis motivaciones para leer este libro.

El libro es en gran medida un repaso histórico, desde la perspectiva personal del autor, de la evolución de las metodologías y procesos de desarrollo. A lo largo del libro Jim va contando sus experiencias (que comienzan allá por los años 60) y que llegan hasta la actualidad. Creo que para quienes trabajamos en cuestiones de metodología y procesos es una excelente referencia para entender la evolución de la forma de trabajo y como una cosa llevó a la otra. Por otro lado creo que para aquellos «amantes de agile» es un lectura obligada para entender cómo fue gestándose Agile. El libro está plagado de anécdotas que van ejemplificando las distintas corrientes a lo largo del tiempo.

Una cosa que me gustó mucho del libro es la cuidada terminología. Jim dice explícitamente que prefiere hablar de Desarrollo de Software en lugar de Ingeniería de Software, reavivando esa eterna polémica. También habla explícitamente sobre «métodos estructurados», «metodologías monumentales», «métodos ágiles», «agile» y «agility». También hace una clara diferenciación entre método, metodología y mindset, términos que muchas veces se confunden (sobre todos los dos primeros).

Cuando habla de Agile hace explícita mención a prácticas técnicas y también a prácticas de gestión, resaltando las importancia de estas últimas.

En la parte final del libro se mete en temas de transformación digital y escalamiento. Aquí no habla de SAFe ni LeSS sino de EDGE y unFIX.

En fin, el libro me gusto mucho y lo super recomiendo.

Invitación & Iniciativa: Desarrollo con NicoPaez

El próximo lunes 15 de enero comenzaré esta nueva iniciativa. La idea es que voy a desarrollar una aplicación de forma iterativa e incremental, dedicando tan solo 15 minutos por día y aplicando las prácticas «modernas» desarrollo (BDD/TDD, CI, Test automation, etc) y gestión (slicing, estimación, planificación). En cierto modo voy a estar poniendo en práctica gran de los temas que vemos en MeMo2.

Estaré trabajando en Ruby casi puro, voy a intentar evitar utilizar complementos mágicos como Rails de forma que sea fácil seguirme y que incluso, quienes gusten, puedan trabajar a la par utilizando algún otro lenguaje.

Creo que mantener las sesiones acotadas a 15 minutos puede ser un gran desafío, pero en principio es la intención. Dicho esto, los interesados en participar me pueden mandar un mensaje aquí y los agrego a la cita para que les quede en el calendar y puedan acceder el meet.

¡Nos vemos el lunes 15 de enero a las 12:00 (hora Argentina, o sea: GMT-3)!

Actualización: comparto aquí el video de la primera sesión donde explico varios detalles de la iniciativa (alcance, grabación, etc)

Idea para trabajo final de carrera: SLR Assistant

La revisión sistemática de literatura (SLR) es un método de investigación muy comúnmente utilizado en medicina pero que desde hace un tiempo también se ha empezado a utilizar en investigaciones de Ingeniería de Software. Como su nombre lo indica, una SLR es una revisión sistemática, o sea, se revisa literatura siguiendo un proceso bien definido y que ha sido extensamente documentado por diversos autores entre los que cabe destacar a Barbara Kitchenham, posiblemente la máxima referente del tema en el área de Ingeniería de Software.

En cierto modo, siempre que hacemos investigación, revisamos investigaciones anteriores mínimamente para poder establecer un estado del arte y asegurarnos no estamos reinventando la rueda con nuestro trabajo. Pero la cuestión con las revisiones SLR es que se hacen con un proceso claramente definido que le da cierta rigurosidad y profundidad. Esto hace que una SLR pueda constituir una publicación en sí misma. En línea con esto yo mismo publiqué una revisión sistemática sobre la enseñanza de métodos ágiles cuando estaba haciendo mi trabajo final de especialización.

Típicamente cuando se trabaja en un revisión hay una primera fase de diseño y luego una de ejecución. Justamente la ejecución implica revisar artículos, extraer información, procesarla y finalmente sacar conclusiones. Esto es un proceso no trivial, bastante trabajoso que bien amerita tener una herramienta de soporte. Existen algunas herramientas para ayudar en el proceso de una SLR, pero a mi parecer tienen varias limitaciones (y poca adopción). También es habitual que la gente utilice herramientas genéricas como ser hojas de cálculo.

Dicho todo esto, mi idea de trabajo final de carrera es una hacer una herramienta de soporte para hacer revisiones sistemáticas: SLR Assistant. El trabajo incluiría hacer la herramienta y (al menos) una revisión sistemática para entender el proceso y probar la utilidad de la herramienta desarrollada. Interesados contactarme aquí.

La hora del Scrum Master técnico

Una publicación reciente de la Scrum Alliance sobre las habilidades en mayor demanda en la actualidad dice textualmente, entre otras cosas, «Delivery-facing agile roles, such as Scrum Masters, are being expected to be technical experts in addition to their agile responsibilities.» Esto está muy en línea con lo que yo mismo he observado en algunos de mis clientes.

Ocurre que en muchas organizaciones se toma el rol de Scrum Master como «exclusivo», o sea: se contrata una persona con habilidades de Scrum Master (y tal vez algunas otras habilidades «blandas») pero sin habilidades técnicas. Esto no está mal, pero tampoco pidamos peras al olmo: una persona sin habilidades técnicas será poco lo que podrá aportar en cuestiones técnicas de desarrollo/delivery. Creo que justamente en línea con este fenómeno (personas que solo saben de Scrum trabajando como Scrum Master) la última versión de la guía de Scrum no habla del Scrum Master como un rol sino como un conjunto de responsabilidades. Esto, a mi parecer, explicita el hecho de que las responsabilidades de «Scrum Mastering» puede ser tomadas por un Developer o algún otro rol (siempre que no haya conflicto de intereses).

Situación recurrente: una persona en el rol de Scrum Master con formación de Scrum Master pero sin formación en sistemas. La organización que lo contrata quiere «delivery» y en parte por ello espera que la persona en el rol de Scrum Master haga más que Scrum dicta del Scrum Master. Pedir que programe puede sonar mucho, pero pedirle habilidades de gestión suena bastante más razonable y aquí está muchas veces la cuestión. La gente que estudio sistemas estudio algo de gestión de proyectos pues es tema presente en todas las carreras de sistemas y hoy en día es muy posible que también haya estudiado Agile en general y Scrum en particular.

En parte fue esta situación la que me llevó a armar el Taller de Prácticas Técnicas para Scrum Masters que tan buena aceptación viene teniendo. En este taller vemos algunas cuestiones técnicas y también algunas cuestiones básicas de gestión de proyectos.

Siguiendo en esta línea de trabajo, estoy empezando a armar un Taller de Técnicas de Facilitación & Gestión para Tech Leads. el cual estará destinado a gente técnica que quiera tomar responsabilidades de facilitador de equipo, Scrum Master, etc. Obviamente tendrá algunos puntos de contacto con los del otro taller pero será un taller diferente y orientado a una audiencia diferente.

Si alguien está interesado en este taller puede contactarme por este formulario y le compartiré más información.

[off-topic] Las Heras Basket 2023

Una vez más hago una excepción en la temática habitual de este espacio para compartir algunos datos y sensaciones de mi otra pasión: el basket.

Este año volvimos a juntar a la banda para darle más constancia a la práctica del deporte. Ese mismo grupo de Las Heras Basket del que ya escribí en alguna otra ocasión en este espacio. 

Lo primero que hicimos fue tramitar un espacio para practicar, hablamos con el secretario municipal de deportes, Pablo Dotti, para poder utilizar el gimnasio municipal.

Luego contactamos a Ale Palomero, quien nos formó basketbolísticamente a varios de nosotros, para que nos entrene.

Y así, en marzo, empezamos a entrenar y a jugar algunos partidos amistosos contra otros equipos de la zona.

En mayo/junio llegó la invitación de la gente de Lobos Athletic Club para armar una liga de Maxi Basquet (maxi es el nombre que se le suele dar a la categoría de mayores de 35 años). Se armó un grupo de coordinación, en el cual estuve participando como representante de nuestro equipo, y empezamos a darle forma a la liga. Se empezaron a sumar equipos: Dorrego (Navarro), Roque Perez Basket y Unitarios (Marcos Paz). Luego de un par de reuniones por Zoom y algunos encuentros de partidos amistosos para conocernos largamos la Liga Lobense de Maxi Basket. Acordamos jugar una fecha cada 2 semanas en una única sede rotativa. Luego de la primera fecha se sumó un sexto equipo: Sportivo (25 de Mayo).

El pasado 16 de diciembre se jugó la última fecha de liga donde Unitarios se consagró como campeón de esta primera edición de la liga. Nosotros quedamos en el sexto lugar, últimos pero contentos con haber completado el campeonato. Por momentos pensé que no lo lograríamos por estar muy cortos de jugadores. Yo en lo personal apenas pude participar en dos fechas debido a una lesión de tobillo que me paró 3 meses y a algunos compromisos personales. Logramos completar la participación en la liga pero me temo que no logramos consolidar un equipo para la competencia. Una muestra de esto es que solo tuvimos un jugador que pudo estar presente en todos los partidos.

Más allá de nuestra participación en la liga, completamos el 2023 con un total de 24 partidos (9 victorias y 15 derrotas).

En lo personal estoy muy contento con lo logrado. Creo que de cara al año próximo tenemos el desafío de volver a participar de la liga y adicionalmente intentar consolidarnos como equipo afianzando una identidad de juego.

Para cerrar quiero agradecer:

  • A Pablo Dotti y al gobierno municipal por habernos prestado el gimnasio.
  • A Ale Palomero que no dudó ni un minuto cuando lo fuimos a buscar para sumarse a esta iniciativa
  • A la gente de Lobos por haber tenido la iniciativa de comenzar con la liga y habernos invitado a participar.

Sobre el uso y la enseñanza de Mob/Pair Programming

La práctica de Pair-Programming es un caso que me llama poderosamente la atención:

  1. Es una práctica que formalmente tiene ~25 años (o tal vez incluso más) [1].
  2. Hay numerosos estudios que respaldan sus beneficios [2,3] y por ello es que la utilizo en mis proyectos y también la enseño en mis cursos.
  3. Pero curiosamente es una práctica muy poco utilizada [4].
  4. Finalmente es una práctica mal interpretada, o sea: hay gente que cree que Pair-Programming es simplemente sentar dos programadores a trabajar en una máquina cuando en realidad hay mucho más que eso. (de esto no tengo pruebas pero tampoco dudas).

Este es un tema que en MeMo2 le damos bastante importancia por varias cuestiones:

1. Los beneficios que trae la convierten en una práctica importante.

2. «El ruido» y malas interpretaciones que hay sobre esta práctica.

3. Creemos fundamental que los alumnos prueben usar la práctica: si no la prueban en nuestra materia creemos muy poco probable que tengan chance y ganas de probarla en otros contextos.

Este cuatrimestre en MeMo2 pedimos a los alumnos que en el primer trabajo grupal nadie escriba código en solitario, o sea: estaban obligados a trabajar todo tiempo haciendo mob/pair programming. Obviamente antes de esto explicamos la dinámica de esta práctica.

En el segundo trabajo grupal cambiamos la consigna, les sugerimos que hagan mob-programming durante toda la primera iteración y que luego de eso trabajen de la forma que consideren más apropiada en las dos iteraciones siguientes. Pero fue solo una sugerencia y como tal no había obligación que la siguieran.

Una vez finalizado el segundo trabajo hicimos una actividad donde les pedimos a los alumnos que individualmente evaluaran la experiencia con cada una de las técnicas, solo-pair-mob, considerando: 1) cuánto utilizaron cada técnica y 2) cúan útil/cómodo que les resultó.

A continuación comparto los resultados para que el lector saque sus propias conclusiones. Yo hace mucho que me convencí que el camino no es solo, parece que no soy el único.

Referencias

[1] Beck, K. (1999). Extreme Programming Explained: Embrace Change. United Kingdom: Pearson Education.

[2] L. Williams, R. R. Kessler, W. Cunningham and R. Jeffries, «Strengthening the case for pair programming,» in IEEE Software, vol. 17, no. 4, pp. 19-25, July-Aug. 2000, doi: 10.1109/52.854064.

[3] Chong, Jan & Plummer, Robert & Leifer, Larry & Klemmer, Scott & Eris, Ozgur & Toye, George. (2005). Pair programming: When and why it works.

[4] Paez, N., Fontdevila, D., Gainey, F., Oliveros, A. (2018). Technical and Organizational Agile Practices: A Latin-American Survey. In: Garbajosa, J., Wang, X., Aguiar, A. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2018. Lecture Notes in Business Information Processing, vol 314. Springer, Cham. https://doi.org/10.1007/978-3-319-91602-6_10

Cierre de cuatrimestre 2023-2 en MeMo2 @ FIUBA

Terminamos el cuatrimestre y me alegra tener la sensación de que seguimos mejorando. Continuamos con el horario matutino de 8 a 11, excelente. Y mantuvimos el mismo porcentaje de clases presenciales/virtuales.

Como siempre hicimos un par de ajustes respecto del cuatrimestre anterior, algunos de ellos basados en el feedback de los alumnos y otros surgidos del equipo docente.

  • Uno de los ajustes más importantes fue ser más explícitos sobre la «programación colaborativa» (mob y pair programming), por momentos pedimos explícitamente que no programen en solitario. Esto generó cierta «incomodidad» entre algunos alumnos por verse obligados a coordinar horarios con sus compañeros para hacer algunas tareas. Pero creemos que el resultado fue muy positivo ya que percibimos que se trabaron menos con cuestiones técnicas lo que les permitió terminar las tareas en menos tiempo y con menos grado de «frustración».
  • Una novedad fue que para los trabajos grupales, agregamos un facilitador «externo» para las retrospectivas al final de cada iteración iteración. O sea: cada grupo ya tenia un docente en el rol de Product Owner y a eso agregamos un segundo docente que solo se sumaba para facilitar las retrospectivas.
  • Otro de los ajustes, no tan visible para los alumnos, tuvo que ver con la infraestructura que utilizamos para el trabajo final debido a algunos cambios en Okteto. Básicamente dejamos de utilizar Okteto y directamente pusimos (casi) todo a correr en nuestro propio cluster Kubernetes en Digital Ocean.
  • También pusimos un poco más de foco en las cuestiones relacionadas a la operación o mejor dicho lo que suele llamarse «build for operations»
  • Finalmente, estrenamos un nuevo trabajo final que nos trajo renovados desafíos para el equipo docente.

Tanto en la retrospectiva final como en la encuesta de cierre, tuvimos feedback muy positivo de los alumnos. Comparto algunos números de la encuesta:

  • La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (11)
  • La evaluación general de la materia (en promedio) dio 9.0, lo cual es mayor que el cuatrimestre anterior (8,8).
  • Respecto del porcentaje de clases presenciales/virtuales, 10 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: 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.
  • La dedicación semanal a la materia extra clase dio un promedio de 8,7 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 63 (esta es una métrica que puede tomar valores en el rango -100 +100)

Algunos otros números del cuatrimestre:

  • Comenzamos la materia con 13 alumnos dos de los cuales abandonaron aproximadamente a mitad de cuatrimestre. Finalmente completaron la cursada 11 alumnos. Luego todos aprobaron el final.
  • Tuvimos 40 tareas individuales que incluyeron: lecturas, videos, cuestionarios y ejercicios de programación
  • Tuvimos 1 tarea para trabajar en parejas y dos trabajos grupales con grupos 3 o 4 alumnos
  • La calificación promedio de aprobación fue 7,1

Resulta curioso que si bien los números de la encuesta dieron mejor que el cuatrimestre anterior, la calificaciones fueron más bajas, un fenómeno para analizar.

Respecto de la dedicación, el análisis de la información reportada por los alumnos nos indica que:

  • La dedicación promedio extra-clase por persona sin considerar los trabajos grupales fue de 65 horas
  • La dedicación promedio extra-clase por persona para los trabajos grupales fue tp1: 6 horas y tp2: 14 horas
  • En términos generales la dedicación extra-clase promedio por persona a lo largo de toda la materia fue de 7,7 horas semanales.

Ingeniería de Software Continua: Fin de primer cuatrimeste & Inscripción 2024

La semana pasada completamos el primer cuatrimestre de la Diplomatura en Ingeniería de Software Continua. Dictamos dos materias: «Diseño y Evolución de Arquitecturas de Software» e «Ingeniería de Software Moderna» las cuales tuvieron 12 alumnos, un muy buen número para la dinámica de clases que diseñamos. El feedback de los participantes fue muy positivo y desde el equipo docente también quedamos muy contentos.

Para ser preciso debo decir que no yo dicté ninguna materia, sino que cuando digo dictamos lo hago desde mi rol de coordinador de la carrera.

El dictado del segundo cuatrimestre comenzará en Abril 2024 con otras dos materias: «Operación y Gestión de Servicios de Software con DevOps» y «Continuous Delivery«, esta última está a mi cargo. Dada la flexibilidad con la armamos el plan de estudio, los interesados en hacer la carrera pueden sumarse en este segundo cuatrimestre y luego completar el diploma en la segunda mitad de 2024. Más aún, si alguien no quiere hacer la carrera completa sino alguna materia puntual, también es posible. Para despejar estas dudas y cualquier otra que los potenciales interesados puedan tener, este miércoles 13 a las 12:00 horas (hora Argentina, gmt-3) estaremos dando una charla informativa (online). Los interesados en participar pueden completar este formulario para que les pasemos los datos de conexión.