Mes: marzo 2022

Cierre y estadísticas del desarrollo de Fira

El lunes pasado fue la presentación formal Fira, el trabajo final de carrera de Facundo Gertsner y Matias Feld y del cual fuí director. La presentación la hicimos presencialmente en la facultad acorde a la normativa vigente pero adicionalmente fue transmitida por Twitch, donde quedó disponible para posterior visualización.

Comparto algunas métricas que pueden resultar de interés para otros alumnos:

  • 23 iteraciones de desarrollo
  • Más de 860 horas de desarrollo
  • Más de 600 pruebas automatizadas
  • ~1300 commits
  • Más de 20 GB de assets

A estos números hay que contextualizarlos considerando:

  • Desde que comenzamos a hablar sobre el trabajo con los alumnos (fines de 2020) hasta que se presentó el trabajo (mazo 2022) pasaron más de 14 meses.
  • Adicionalmente a las horas de desarrollo, los alumnos invirtieron una cantidad no menor de horas en capacitación e investigación, principalmente dedicadas a aprender Unreal (el motor sobre el que está construido el juego)

Algunas otras cuestiones que me parecen interesantes para destacar por no ser tan habituales en los trabajos finales de carrera:

  • Matias y Facundo decidieron aprovechar el trabajo final de carrera para comenzar un emprendimiento comercial. Esto resulta muy interesante pero trae también algunos desafíos como ser el hecho de regular las potenciales tensiones entre el aspecto comercial y el aspecto académico. Ejemplo: comercialmente el producto podría requerir más tiempo de desarrollo que el inicialmente estipulado; al mismo tiempo desde el punto de vista académico pretendemos que los alumnos terminen su formación en un tiempo acotado. Es justamente en este tipo de cuestiones donde el director debe guiar a los alumnos.
  • Al momento de finalización del trabajo académico, el producto no se encontraba comercialmente finalizado pero sí había tenido una validación de mercado (como director no habría podrido dar el trabajo por finalizado sin esta validación). El juego tuvo ~400 descargas de la versión beta y más de 25 mil visitas a la página de promoción.
  • El desarrollo de un juego de este tipo requiere del desarrollo de piezas artísticas (imágenes, texturas, animaciones, sonidos, música, etc). Esto implicó que parte del trabajo de los alumnos incluyera la gestión con los artistas/profesionales proveedores/creadores de estas piezas. Este trabajo de gestión es una tarea habitual para un ingeniero pero resulta algo casi inédita en un trabajo final de carrera.

Bueno, esto es todo sobre Fira. Felicito a Matias y Facundo por el trabajo realizado y les agradezco por haberme permitido ser parte de esta aventura.

El desafío del profeta en su tierra

Una hay famosa frase que dice «Nadie es profeta en su tierra» que hoy en día me resuena muy frecuentemente. Durante 10 años trabajé como consultor, mis clientes me llamaban para resolver ciertas cuestiones. En cierto modo, los equipos con los que trabajaba me venían como «el profeta» que traía «la palabra». Más allá de que nunca me sentí cómodo en ese rol, me resultaba muy curioso que en más de una ocasión mis propuestas no eran muy distintas a las que algún miembro del equipo ya había hecho. Pero claro, nadie es profeta en su tierra. Por alguna razón, si la sugerencia la viene un compañero con el que trabajas a diario, es como que la sugerencia tuviera menos valor. Pero si la sugerencia la hace alguien externo, es como si resultase de mayor valor.

Hoy en día, estoy trabajando en un equipo y me encuentro en la situación inversa a la que me encontraba antes. Propongo algo y no se le da mayor importancia, pero eso mismo lo dice un externo y es palabra santa. Pero el problema no termina aquí. Hay una gran cantidad de cuestiones (casi todas) para las que no hay un consultor externo y en esos casos me encuentro yo solito intentando convencer a mi equipo. Durísimo, en gran medida porque en el equipo somos todos «veteranos de guerra», gente con ~20 años en la profesión, cada uno con sus experiencias, mañas y gustos e intentando trabajar en un esquema bastante horizontal en lo que refiere a las decisiones técnicas.

El desafío me resulta interesante pero también desgastante y hasta frustrante por momentos. En una ocasión llegué a tener una discusión porque un colega insistía en que hacía demasiadas pruebas y que eso hacía más lento el desarrollo. Y por ello pretendía que yo escribiera menos pruebas. Yo no podía creer lo que estaba escuchando. De hecho inicialmente no lo entendí. En un momento me sentí como Fantino diciendo: «Pará pará pará, ¿vos me estas diciendo que queres que yo escriba menos pruebas?». Naturalmente al hacer TDD uno suele escribir más pruebas que cuando se agregan las pruebas a posterior, con lo cual podría decirse que es cierto «hago muchas pruebas». Pero de ninguna forma creo que eso haga más lento el desarrollo, al menos no en un grado relevante. O sea, es cierto que si hiciera menos pruebas podría llevarme menos tiempos ¿pero cuanto menos? ¿5 horas en lugar de 6? No creo que esa diferencia en tiempo justifique «romper» mi proceso. Trabajo de una forma que me da seguridad y me permite trabajar de una forma eficiente, confiable y predecible.

Menos mal que uno ya está curtido y muchas balas no le entran, porque este tipo de cuestiones no hacen más que poner en tela de juicio las aptitudes personales y podrían destruir la autoestima y motivación de gente más sensible.

Por suerte, más allá de las diferencias profesionales, es toda gente bien intencionada y hablando (casi siempre)se puede logran consenso, pero no es fácil.

En fin, esta situación me llevó a buscar ayuda, por un lado hablando con algunos colegas y por otro buscando en biblioteca donde encontré un librito muy útil aunque no muy popular: «Driven Technical Change» (de Terrence Ryan) que me dió algunas ideas que estoy probando. En un par de semanas (o meses) les cuento que tal me va.

Presentación de Fira, un videojuego con raíces académicas

Comenzamos las primeras conversaciones a fines de 2020. El primer mail en la lista de correo del equipo data de febrero de 2021. Presentamos la propuesta formal a la comisión curricular a comienzos de junio 2021. La primera iteración de desarrollo comenzó el 23 de agosto de 2021. Fueron un total de 24 iteraciones. Fueron más de 800 horas de desarrollo a las que hay que sumar el tiempo invertido en estudio/capacitación (los chicos tuvieron que aprender Unreal) que se invirtió antes del inicio formal del desarrollo.

Finalmente, este lunes 28 será la presentación formal del trabajo y con ello Facundo y Matias completarán su carrera de Ingeniería en Informática. La presentación será a las 17:00 hs. en la sede Paseo Colón de la Facultad de Ingeniería y también será transmitida por Twitch por el canal del departamento de computación.

¡Nos vemos!

Diseño ágil con TDD

Ayer terminé de leer la edición 2020 de este libro escrito por Carlos Blé. Ya había leído (parcialmente) la edición anterior allá por 2011, pero el año pasado Carlos tuvo la gentileza de regalarme esta nueva versión (¡gracias!) y me comentó que tenía modificaciones importantes así que aproveché que estaba estudiando TDD para mi tesis de maestría y decidí leer el libro de punta a punta.

En una oración: el libro me gustó mucho. Sentí mucha afinidad en la forma de trabajo que relata y también en los consejos que el autor ofrece a título personal.

Encontré un punto de contraste interesante con otros libros de TDD. Creo que la mayoría de los libros que he leído sobre TDD (al igual que la mayoría de charlas, cursos y videos sobre TDD que he visto/presenciado) tienen un tono muy extremo, muy «todo o nada», muy «esto es así» (creo que yo mismo muchas veces peco con ese tono) pero este libro (y creo que Carlos en general) tiene un tono «de mesura», un matiz que me resultó muy ameno y que imagino puede resultar mucho más efectivo a la hora de intentar convencer a alguién de utilizar TDD.

Otra cuestión destacable del libro es no se queda en la explicación de la técnica sino que también trata sobre el uso de la técnica en distintos contextos «reales» de aplicación: en qué tipos de proyectos utilizarla TDD, cómo utilizar TDD en proyectos de código legado, como empezar a utilizar TDD, etc. Trata también la clásica rivalidad de los estilos Chicago vs London de sin necesariamente tomar partido (menciona su preferencia pero no la considera una bala de plata para todo contexto).

Otro punto no menor a destacar es que es uno de los pocos libros (¿acaso el único?) de TDD en castellano.

Creo que es un recurso interesante para aprender TDD, tal vez no entra en tanto detalle como otros libros de TDD pero al mismo cubre muchas más cuestiones, o sea: va más en anchura que en profundidad lo cual me parece bueno para un libro introductorio.

El libro está disponible en formato digital en LeanPub. Muy recomendado.

Desafíos en la formación de un equipo docente

Hace unos 20 años que estoy en la docencia. En todo ese tiempo he sido parte de varios equipos docentes en distintas materias e instituciones. Hace unos 10 años tuve por primera vez un curso a mi cargo. Pero recién en 2019 estuve en la situación de conformar un equipo estable de más de 2 personas. Hasta ese momento siempre había dictado las materias a mi cargo yo solo o en compañía de otro docente. Estando solo no había opciones, todo el trabajo debía hacerlo yo mismo. Siendo 2 y ambos con muy similar experiencia y perfil, en general dividimos el trabajo en parte iguales apuntando a que ambos podamos dictar todos los temas de la materia. No hacemos distinción entre teoría y práctica porque en la dinámica de nuestra materia no existe tal distinción.

Pero hoy en día, en el equipo de la materia a mi cargo en FIUBA, somos 10 personas con distintos perfiles y experiencia. Graduados, estudiantes, rentados y no-rentados. Esto, a mi entender, hace que la distribución de tareas no sea tan simple. Me pregunto si alguna capacitación para docentes incluirá este tipo de cuestiones: armado de una equipo docente. Me late que no. Como docente responsable formalmente a cargo del curso, soy responsable de todo lo que ocurre en la materia. Claro que puedo delegar tareas, pero si algo no van bien, «me vendrán a buscar a mi».

Hay dos cuestiones que me resultan muy desafiantes en este contexto:

  1. De cara a los alumnos el mayor desafió que veo es la uniformidad. Siendo varias personas en el rol docente dentro de un mismo curso uno esperaría cierta uniformidad de criterios. Obviamente que puede haber diferencia de matices pero hay un conjunto de cuestiones centrales en las que todos deberíamos estar alineados. En este contexto entran los criterios de evaluación. Debería ser irrelevante para los alumnos que docente realiza la corrección de una entrega pues todos deberíamos aplicar el mismo criterio y por ende el resultado debería ser el mismo.
  2. De cara hacia el propio equipo docente encuentro un desafió importante en la distribución de tareas. Dentro del curso hay distintos tipos de tareas que varían en dedicación, responsabilidad y experiencia/conocimiento. Una cuestión que condimenta este tema es el hecho de que parte del equipo docente no está rentado. Esta situación de docentes no rentados es una práctica habitual en las universidades públicas argentinas, pero excede este artículo, ya lo trataré en otro.

Respecto de la primera cuestión creo que he encontrado una estrategia efectiva con la que estoy conforme. Respecto de la segunda, venimos operando de una forma que funciona pero que no termina de convencerme.

Al margen de estas cuestiones operativas formar un equipo implica muchas más cosas, más complejas y más profundas. Cuestiones de principios, solidaridad, vínculos, valores, sentido de pertenencia, etc, etc. Estas cuestiones de índole «más humano» requieren tiempo y oportunidades de interacción, dos elementos escasos cuando todos los miembros del equipo tiene una dedicación muy acotada en el contexto de la materia. Yo personalmente como responsable del curso dedico entre 5 y 10 horas semanales, pero un colaborador no rentado difícilmente dedique más de 5 horas por semana. Y como condimento adicional le sumamos la situación de pandemia que nos quitó el vernos en persona, un condimento importante para establecer vínculos personales.

Continuará…

Cero + Infinito

El miércoles volví a pisar la UBA, pero no fue para visitar mi querida Facultad de Ingeniería sino para visitar la Facultad de Ciencias Exactas y Naturales. El motivo de mi visita fue para asistir a la charla sobre ciencia de datos que dió Sebastián Ceria. En realidad, siendo totalmente sincero, la charla de Ceria fue una excusa para ir a conocer el flamante edificio de la facultad llamado Cero + Infinito.

Vista desde uno de los extremos del edicio Cero + Infinito

No vi demasiado del edificio pero lo que vi me bastó para el asombro sobre considerando el contraste con los aledaños pabellones 1, 2 y 3 de Ciudad Universitaria. El edificio no es solo funcional sino que también es lindo. Tiene mucho vidrio lo cual le da una mucha luminosidad, terrible contraste con los otros pabellones de Ciudad Universitaria que tienen tanta luz como la baticueva. En realidad ahora que lo pienso creo que la mayoría de los edificios de la UBA son bastante oscuros (destaca en esta categoría la sede Las Heras de la Facultad de Ingeniería que literalmente es un catedral gótica).

Me gustó tanto que me dieron ganas de dejar mi working-from-home (con el que estoy muy contento) y mudarme una oficina de este nuevo edificio.

La charla fue en una sala auditorio con butacas tipo cine (muy cómodas) y con muy buena acústica. Como era de esperar, todo el mundo con barbijo (salvo obviamente el orador).

Facultad de Ingeniería sede Las Heras

La charla me resultó muy interesante. Cubrió algunas cuestiones de historia, de su desarrollo profesional (Sebastián es matemático de formación y profesionalmente se ha dedicado al tema datos), habló sobre algunas cuestiones de la nueva carrera de datos de la facultad (que por como habló da la sensación que participó del diseño de la carrera) y también habló del vínculo de la llamada ciencia de datos y las diversas herramientas matemáticas. Según comentaron la charla será publicada en redes.

Preparando MeMo2 @fiuba para volver al aula

Aún no está declarado el fin de la pandemia pero la UBA ha determinado el regreso a las aulas. En particular la facultad de ingeniería ha habilitado un esquema «flexible» en el que cierto porcentaje de clases puede dar en modo virtual. La paradoja es que en particular en MeMo2 creemos que la gran mayoría de las clases sería más conveniente darlas en forma virtual. En fin, siguiendo las regulaciones vigentes hemos planificado para dar la mayoría de las clases en forma presencial. De la mano de la presencialidad estamos también modificando algunas clases retomando algunas dinámicas que solíamos utilizar en la pre-pandemia.

Otro de los cambios que aún estamos evaluando implementar es una variación en el régimen de cursada para los alumnos inscriptos bajo el código 7510 (ver MeMo2 nos es TDD). La idea es que estos alumnos tenga un régimen de cursada más tradicional con parcial y final incluyendo en los mismos algunos temas adicionales de patrones de diseño.

A partir de un libro que leí recientemente hay dos dinámicas que me gustaría incorporar en las clases:

  • Class Take-away: al final de cada clase resumir en 3 bullets los puntos más relevantes de la clase. O sea, la idea es que los alumnos colaborativamente identifiquen estos 3 bullets.
  • Course log: cada alumno llevará en su repositorio personal un resumen de cada una de las clases incluyendo las cuestiones que le hayan resultado más relevantes de la clase

Cierro con una recomendación para los alumnos que vayan a cursar con nosotros: No falten la primera clase y si por alguna razón no pueden asistir contactense conmigo a la brevedad.

Comenzando con React Native

Estamos semana comenzamos a trabajar en la nueva aplicación móvil de Radiocut. A diferencia de la aplicación anterior que estaba construida con Cordova/Ionic, esta vez decidimos utilizar React Native.

Son varias las razones para trabajar con una tecnología de este tipo en lugar de trabajar directamente con tecnología nativa:

  • Somos un equipo chico, generalista y «multi tecnología», trabajar con tecnologías nativas sería demasiado esfuerzo ya que tendríamos que codear y mantener dos aplicaciones completamente distintas (una android y otra ios) en lenguajes distintos, Java/Kotlin y ObjectiveC/Swift ninguno de los cuales forma parte de nuestro stack actual.
  • Las características de la nuestra aplicación no requieren trabajar con tecnología nativa, creemos que casi todas las funcionalidades las podemos implementar sin mayores complicaciones sin tener que tocar código nativo.

Una vez decidido el uso de React Native hay dos cuestiones que debemos definir en forma temprana: el CLI y el lenguaje. El proyecto React Native se crea con una herramienta de línea de comandos (CLI) que genera código y simplifica el bootstrap del proyecto. En este sentido una opción es usar el CLI de React Native pero hay también otra opción: Expo CLI. Importante: ambos CLIs son herramientas JavaScript con lo cual para instalarlos solo necesitamos de Node/NPM.

Expo CLI nos ofrece un bootstrap simplificado, o sea, nos provee un proyecto base que ya cuenta con varias cuestiones «pre-configuradas». Al mismo tiempo no requiere que nos instalemos el tooling para desarrollo nativo (Android SDK/xCode) ya que el build final de nuestra aplicación se hace en el servicio cloud ofrecido por Expo.

Por su parte el CLI de React Native nos provee «menos asistencia», hay más cuestiones que tendremos que manejar nosotros mismos y al mismo tiempo tendremos que instalarnos el tooling para desarrollo nativo.

Comparativamente los puntos que tenemos que considerar para eligir el CLI son:

  • El binario generado por Expo termina típicamente siendo más pesado que el binario que genera el CLI de React Native.
  • Expo CLI nos simplifica muchas cuestiones y nos provee un mayor nivel de abstracción y por su parte el CLI de React Native nos «hace trabajar más» pero nos da un mayor control de la aplicación/código.
  • Al trabajar con Expo CLI dependemos del servicio cloud de Expo para la generación del binario final.

La forma en que estas 3 cuestiones impactan en cada proyecto son particulares de cada proyecto. En nuestro caso decidimos ir por el CLI de React Native.

Una vez elegido el CLI, podemos avanzar con la creación del proyecto y eso lleva a una nueva elección: el lenguaje. Podemos trabajar con TypeScript o JavaScript. En nuestro caso elegimos JavaScript ya estamos acostumbrados a trabajar con lenguajes de tipado dinámico y todo nuestro código client-side ya está escrito en JavaScript puro.

Hasta aquí, nuestros primeros pasos. En siguientes entregas iré compartiendo:

  • Setup de la infra cd CI/CD
  • Manejo de configuración de APP
  • Publicación en los stores

Continuará…

Dirección de trabajos finales de carrera

Luego de recibir varias consultas de alumnos para que dirija sus trabajos finales de carrera, he decidido resumir aquí algunas cuestiones/condiciones referentes mi forma de trabajo como director.

  • La dinámica de trabajo es al estilo Agile/XP tal como enseñamos en MeMo2, esto es: iteraciones semanales de tiempo fijo, 1 reunión de seguimiento (review+planning) semanal, entrega continua, gestión adaptativa, etc.
  • En línea con el punto anterior, solo dirijo alumnos que hayan cursado MeMo2 en mi curso, esto se debe a que no quiero tener que lidiar explicando la forma de trabajo, si cursaron MeMo2 entonces ya lo conocen.
  • Ya desde el planteo del proyecto apunto a que el trabajo no exceda de ninguna manera los 365 días.
  • Como consecuencia de los puntos espero una dedicación semanal (por alumno) de al menos unas 10 horas semanales.
  • La documentación (propuesta e informe técnico) la prefiero escrita en Latex, en particular me inclino por trabajar con Overleaf que ofrece una muy buena experiencia de trabajo colaborativo online al estilo Google Docs.
  • Para los trabajos que impliquen un desarrollo de software, apunto a que sean publicados bajo licencia open source.
  • Para los trabajos que sean más del tipo «research» apunto a que el trabajo sea publicado en alguna conferencia y/o revista.

Estos puntos representan una guía que pretendo seguir, pero en determinados casos son cuestiones «charlables». Quienes estén interesados en que dirija su trabajo pueden contactar por aquí.