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.

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).

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í.

Seminario de Postgrado en Software Delivery (3º edición)

La semana pasada confirmamos la realización de la tercera edición del Seminario de Postgrado en Software Delivery de UNTreF.

Este seminario está centrado en el proceso de desarrollo y entrega de software,cubriendo diversas prácticas tanto a nivel técnico como de gestión. El contenido está estructurado sobre la base de un conjunto de estudios formales y casos de estudio en torno a organizaciones de alto desempeño. En especial se destacan las ideas desarrolladas por Forsgren, Humble y Kim en su libro »Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations» (IT Revolution, 2018).Los objetivos del seminario son:

Entender el impacto de las capacidades de Software Delivery en la performance del negocio
Entender las prácticas técnicas y de gestión que mejoran la performance de delivery
Conocer posibles estrategias para la adopción de las mencionadas prácticas

El seminario está destinado a:

Profesionales de la industria (independientemente de su rol) que pretendan mejorar su práctica de software delivery
Docentes e investigadores que se desempeñen el temás de ingeniería de software y quieran familiarizarse con en el estado de la práctica de software delivery

Vamos a mantener el mismo formato que la edición anterior, eso es: una duración calendario de 3 meses, con un encuentro online de 150 minutos cada 15 días. Esto hace un total de 15 horas de clase repartidas en 6 encuentros. A esto se se suman otras ~40 horas de estudio/trabajo fuera del aula (algo así como unas 3 horas de trabajo constante todas las semanas adicionalmente al tiempo de clase). Las fechas de los encuentros serán:

2022-04-13
2022-04-27
2022-05-11
2022-05-25
2022-06-08
2022-06-22

Siempre en el horario de 9:30 a 12:00 (hora argentina, GMT-3).

Una de las novedades esta edición es que estaremos sumando al Lic. Diego Marcet al equipo docente.

Si bien el seminario se dicta en el contexto de una universidad nacional que ofrece carreras de grado gratuitas, este seminario es pago (como suele ocurrir con las actividades de postgrado). En esta edición el costo rondará los AR$ 10.000, digo rondará porque es una cuestión que me excede, yo no manejo esta recaudación ya que tengo un sueldo fijo que me paga la universidad por ser empleado permanente. De todas formas, siempre tramitamos algunas becas, principalmente destinadas a docentes y empleados de organismo públicos.

El día 23 de Marzo a las 9:30 haremos una charla abierta de presentación del seminario para todos los interesados los cuales deben registrarse aquí para que les compartamos el link de acceso. Adicionalmente a esta reunión, aquellos que quieran saber más sobre este seminario pueden encontrar algunos artículos en mi blog bajo la etiqueta seminario-sd y obviamente siempre pueden escribirme en casos de más dudas.

Highlights sobre el libro «Test-Driven Development By Example»

Esta semana terminé de releer este libro fundacional de TDD. Como ya mencioné no estoy convencido de que sea el punto de entrada más apropiado para aprender TDD, pero sí estoy convencido que todo practicante de TDD debería leerlo.

Personalmente creo que es un libro para leer de punta a punta, sin los capítulos de la tercera parte de libro tratan sobre patrones y se pueden leer en forma descolgada a modo de consulta, los capítulos de las dos primeras partes están dedicados al desarrollo de dos ejemplos en profundidad que luego son referenciamos en los patrones de la tercera parte.

El libro trata ciertas cuestiones de TDD que muchas veces se pasan por alto, algunas veces se las menciona a la pasada y otra vez ni siquiera se mencionan. Algunas de estas cuestiones que me parece vale la pena destacar:

El trabajo en forma iterativa y en pequeños pasos es realmente central a TDD. Beck habla de ciclos de 10 minutos (pag. 143).
Es completamente válido retroceder para avanzar, si llegamos a un punto donde estamos integrando nuestro código y vemos que hemos roto algo, puede resultar conveniente tirar lo hecho y comenzar de nuevo (pag. 149). Como estamos trabajando en incrementos realmente chicos, lo que vamos a estar tirando no es mucho, es solo el último incremento. Esto lo veo muy relacionado a la técnica Test and Commit or Revert.
La técnica «Log String» (pag. 146) es increíblemente simple y útil a la vez que definitivamente le voy a dedicar un artículo exclusivo.
Para el programador el código de test es tan importante como el código de dominio. Esto está mencionado de distintas formas a lo largo del libro y como consecuencia de esto no es raro que la cantidad de código de test sea similar a la cantidad de código de dominio. Asimismo el uso de patrones de diseño aplica tanto al código de dominio como al código de test.
Si bien el flujo de trabajo es codear un test a la vez, Beck recomienda comenzar la sesión de programación haciendo una lista de los casos que intentaremos cubrir durante la sesión (pag. 126). Esta lista también la utiliza para registrar casos/situaciones que puedan ir surgiendo durante la sesión sin perder el foco de trabajo: estoy trabajando en un caso, surge una idea, la anotamos en la lista y seguimos con los que estábamos (pag. 137)
A la hora de escribir los tests puede resultar conveniente comenzar por escribir el Assert (pag. 128)
Refactorizar es fundamental, no es posible hacer TDD sin refactorizar y una de las principales razones (o posiblemente la más importante) para refactorizar es evitar la duplicación de código (en realidad más que evitar duplicación de código lo que buscamos es evitar la duplicación de conocimiento). Esto es mencionado en varios lugares a lo largo del libro. Como que Beck está obsesionado con esto.
El apéndice 2 del libro desarrolla un ejemplo muy chiquito pero muy clarificador de la esencia de TDD.
El orden en que codeamos los tests puede impactar enormemente en el proceso de TDD (pag. 200). Un determinado orden puede hacer que el proceso fluya armónicamente mientras que la misma lista de tests codeada en un orden distinto puede llevar a un callejón sin salida.

Sin duda hay varias cuestiones más para destacar de este libro, pero estas son las que a mi me resonaron.

Fira: un juego con raíces académicas

Hace un tiempo comenté que estaba dirigiendo un trabajo final de carrera que consistía en el desarrollo de un videojuego. Ya estamos en el tramo final, por el momento viene todo según lo planificamos: 24 semanas a un ritmo de unas ~30 horas semanales. Si no surgen imprevistos, estimo que estaremos presentado el trabajo durante marzo. El juego ya está jugable hace varias iteraciones y de hecho ya hemos recibido feedback de varios beta users. Un detalle interesante es la intención de hacer de este juego un producto comercial y en ese sentido se ha trabajado con profesionales para externos a la facultad para el desarrollo de los artefactos multimedia (gráfica, sonido, etc). El nombre comercial del juego es Fira y ya está disponible (preview) en la plataforma Steam. Aprovecho para invitar a la audiencia a descargar el juego y darnos su feedback.

Desconozco como suelen trabajar los estudios que se dedican al desarrollo de este tipo de videosjuegos pero creo que la forma en que encaramos el desarrollo viene funcionando muy bien. Esta forma de trabajo es básicamente lo que enseñamos en MeMo2 y tiene que ver con el uso de varias prácticas básicas de ingeniería de software: feedback temprano, integración continua, planificación adaptativa, prueba automatizada, propiedad compartida, uso convencione, etc.

Si bien no he estado muy involucrado en cuestiones de programación, he aprendido muchas cuestiones técnicas de la mano de los alumnos. Creo que el desarrollo de este tipo de juegos es un mundo en sí mismo y por ello creo que bien podríamos tener en FIUBA una materia dedicada a esto.

Estas últimas semanas estuve participando de algunas sesiones de programación con los alumnos y me reencontré con C++. No es un lenguaje de mi preferencia pero me parece importante que todo ingeniero de software tenga alguna experiencia con C++.

Búsqueda de especialista UX

Con el equipo de Radiocut tenemos la intención de dar una vuelta de rosca a la experiencia que ofrecemos a nuestros usuarios. En particular estamos considerando rehacer nuestra aplicación móvil y para ello estamos buscando algún especialista en UX para que nos ayude.

Imaginamos en principio una contratación temporal de una persona que sea usuaria de Radiocut.

Si eres esta persona, te pedimos que completes este formulario y nos contactaremos contigo a la brevedad.

Si estás leyendo esto y no crees ser la persona que buscamos pero conoces a alguién que podría serlo, por favor hazle llegar este mensaje.

Comenzando a estudiar TDD

En el contexto de mi investigación sobre TDD decidí a arrancar desde cero a pesar de llevar ya varios años aplicando y enseñando TDD. La técnica Test-Driven Development (TDD) fue «creada» por Kent Beck durante los 90. Y pongo creada entre comillas porque el mismo Beck se define asimismo como «redescubridor» de TDD. Al margen de este acto de humildad, la realidad es que si bien Beck había leído sobre la idea de escribir el código de prueba antes que código funcional, TDD es una técnica que implica mucho más que esa idea.

Sinceramente desconozco cual sea primera mención formal a Test-Driven Development, pero la primera que yo conozco data de la primera edición del libro Extreme Programming Explained escrito por Beck y publicado en 1999. En dicho libro Beck no habla exactamente de Test-Driven Development como técnica sino que simplemente habla de escribir los tests antes de la funcionalidad y hace referencia a esto como estrategia Test-First.

Recién en su libro Test-Driven Development by Example publicado en 2003, Beck entra en los detalles de la técnica TDD. Hace ya años que no recomiendo este libro como puerta de entrada a TDD, porque personalmente me costó mucho hacer el salto de lo que propone el libro «al mundo real». Tengamos presente que los ejemplos del libro (que básicamente son 2 ejemplos tratados con bastante profundidad) están centrados en lo que podríamos denominar la capa de dominio y no lidian con nada de la infraestructura. Esto está muy bien para entender las ideas centrales de la técnica pero resulta insuficiente para poder aplicarla en «contextos industriales». Sin embargo, a partir de mi trabajo de maestría volví a leer el libro y esta relectura me llevó a revalorizarlo. Me resulta interesante cómo algunas cuestiones que descubrí practicando TDD están mencionadas en el libro, pero que en mi primera lectura yo pasé completamente por alto. Más aún, tengo la sensación de que algunas de esas cuestiones son reiteradamente subestimadas por practicantes y «evangelizadores» de TDD. Una de esas cuestiones es la naturaleza iterativa de TDD. Esta naturaleza iterativa, que también es parte central de Agile y DevOps, implica que tenemos que estar dispuestos a avanzar en una dirección con intención exploratoria aún cuando eso pueda implicar volver atrás. Llevado al código esto puede implicar escribir código (funcional o de prueba) sabiendo que en breve lo eliminaremos. Y cuando digo en breve no es dentro de 3 semanas o 3 meses, sino tal vez dentro de 15 minutos.

Son muy pocos los libros que he vuelto a leer de punta a punta. Muchas veces leo un libro de punta a punta cuando lo leo por primera vez y luego vuelvo a leer (generalmente a modo de consulta) algún capítulo en particular. Pero esta vez decidí volver a leer Test-Driven Development by Example de punta a punta otra vez y creo que ha sido una gran inversión pues me ha permitido reflexionar, cuestionarme y entender más profundamente algunas cuestiones.

Mientras escribo estas líneas reflexiono y me convenzo de que si bien yo estoy empezando mi investigación sobre TDD leyendo Test-Driven Development by Example, no es lo que yo recomendaría a un practicante, o sea, a alguien quien aprender TDD para aplicarlo en desarrollo de software. De hecho, la cuestión de por dónde empezar a aprender TDD es una de las cuestiones intento abordar en mi trabajo de investigación.

Tesis de maestría: Enseñanza de TDD

Este año me he propuesto completar mi tesis de maestría. Ya tengo el proyecto planteado y aprobado. La temática del mismo tiene que ver con desarrollar una propuesta para la enseñanza del desarrollo guiado por pruebas. Y si bien en el título de este post menciono TDD, Test-Driven Development, mi planteo es bastante más amplio que el clásico ciclo Red-Green-Refactor, mi idea es centrarme en el desarrollo guiado por pruebas pero desde una perspectiva más «holística» similar la que plantean Freeman y & Pryce en GOOS, viendo el desarrollo guiado por pruebas como un proceso de construcción de software que va más allá del diseño, la codificación y la prueba y que abarca también cuestiones de análisis, requerimientos, deployment y delivery.

La tesis en sí, es la forma de comunicar el trabajo de investigación que uno realiza. Dicho trabajo de investigación puede extenderse por meses o incluso años. Típicamente los trabajos de tesis de maestrías académicas son planteados para ser completados en un año calendario, pero eso no siempre se cumple. En mi caso armé un calendario de trabajo de apróximadamente un un año, pero dado que un año me parece un marco de tiempo demasiado extenso, plantee algunos hitos intermedios representados por publicaciones de las distintas cuestiones que vaya resolviendo.

Más allá de las publicaciones formales que realice, mi idea es ir compartiendo en este espacio algunos de mis avances. En este sentido va este primer post.

Dicho esto, si están interesados en la enseñanza, la prácticas y el aprendizaje de la técnica de desarrollo guiado por pruebas, les recomiendo estén atentos a este espacio.