Etiquetado: algo3
El desafio de liberar un producto
En estos dias estoy trabajando en la liberación como producto del sistema de corrección de tareas de programación que desarrollaron unos alumnos de FIUBA bajo mi dirección. El producto, desde el punto de vista técnico ya está listo, de hecho ya lo estamos usando en Algo3, pero liberarlo como producto requiere de ciertas cuestiones, que hoy en día me doy cuenta que no suelen ser parte de la formación académica (o al menos no lo fueron de la mia).
El primer lugar tenemos una cuestión legal: la licencia. Si bien tenemos en claro que queremos que sea open source, no tenemos en claro las diferencias entre las distintas licencias. Al mismo tiempo, ocurre que nuestro producto está basado en otros componentes de software que tienen ciertas licencias y que deberíamos respetar. Por último, si bien queremos que sea open source, queremos que quienes decidan extender el producto respeten ciertos condiciones, por ejemplo que lo desarrollado siga siendo open source.
Por otro lado si uno pretende que el producto tenga cierto grado de adopción, es necesario que los interesados en utilizarlo cuenten con información básica sobre las funcionalidades del producto, sus requerimientos para ejecución, el procedimiento de instalación, cómo proceder en caso de problemas, roadmap de producto, etc. ¡Ah! y un tema no menor, el manual de usuario, ya sea en formato tradicional de texto o en formato de video.
Al ser un producto open source, es posible que los potenciales usuarios quieran extenderlo y/o personalizarlo, en ese caso es necesario proveer información técnica comenzando por cómo armar un ambiente desarrollo para el producto.
Por último una cuestión no menor: el nombre del producto. Generalmente cuando uno arranca un proyecto le pone un nombre, pero el nombre del producto es algo conceptualmente distinto del nombre del proyecto. El nombre del producto impacta directamente en varias cuestiones como ser la URL del sitio del producto y los diversos elementos de márketing.
¿Cómo enseñamos a programar?
Cada vez estoy más convencido que la programación es un oficio y como todos los oficios se aprende haciendo. Pero no haciendo en soledad sino con un maestro. Pensemos en un carpintero ¿cómo se forma? ¿leyendo libros? Tal vez, si, es posible que lea algún libro, pero no es su principal formación. Su principal formación es trabajando la madera junto a un carpintero ya experimentado, quien le va enseñando los gajes del oficio. Pero si miramos la forma en que suele enseñarse a programar lejos está de esto.
No hay diferencia entre universidades, institutos terciarios o centros de capacitación privados, en general todos siguen el mismo esquema. El alumno asiste a un curso donde el docente ofrece algún tipo de explicación inicial y luego le dá a los alumnos ejercicios para que resuelvan. Luego se hace una resolución general en el pizarrón o usando un proyector. Puede que también se entregue algún material de lectura. Pero sentarse a programar con el alumno, no, nunca. En el mejor de los casos, mientras los alumnos trabajan en la resolución de los ejercicios, puede que un docente se acerque para responder alguna consulta o para destrabar a un alumno que no logra avanzar en la resolución.
¿Por qué es esto así? no lo sé a ciencia cierta. Creo que puede haber diversos motivos.
En sus comienzos la programación surgió vinculada a la matemática y por ello puede que haya heredado su didáctica. También puede ser que los docentes no vean la programación como un oficio. En algunos casos podría argumentarse que la masividad de algunos cursos hace imposible que el docente se siente a programar con los alumnos. En fin, cada cual tendrá sus argumentos. En lo que a mi respecta, estoy convencido que la programación es un oficio y si bien en Algo3 tenemos cursos masivos y recursos acotados, intentamos programar con los alumnos haciendo dojos en clase o incluso algo de “community-programming” al desarrollar el trabajo final, donde cada docente puede sentarse con grupos de 3 o 4 alumnos a programar conjuntamente.
Sistema de gestión de trabajos prácticos
A mediados del año pasado se me acercaron dos alumnos de FIUBA, con la intención de que los dirigieran en el desarrrollo de su trabajo profesional de fin de carrera. La propuesta que traían no me convenció, pero en lugar de decirles que no, les hice una contra oferta y trabajar en una idea que tenia en mente desde hace un tiempo: una herramienta de gestión para de trabajos prácticos de programación. La idea no era del todo novedosa, pues ya había en nuestra misma facultad dos materias que ya tenian un sistema similar. Al mismo tiempo, puse una seria de condiciones respecto del producto final y de la forma de trabajo:
En cuanto al producto, pedí las siguientes cuestiones
- Pruebas unitarias y de aceptación automatizadas
- Alto porcentaje de cobertura
- Cumplimiento de las convenciones de código del lenguaje utilizado
- Implementación con tecnologias abiertas
Respecto de la forma de trabajo les pedí:
- Enfoque iterativo incremental con iteraciones semanales
- Proceso de trabajo tipo Scrum
- Visibilidad contínua
Con buen criterio los muchachos se tomaron un par de dias para pensarlo y finalmente aceptaron.
Hoy al cabo de 21 iteraciones, estamos a punto de salir en producción. Estamos arrancando el cuatrimestre y vamos a utilizar el sistema para gestionar los dos primeros trabajos prácticos de este cuatrimestre.
En próximos post compartiré más detalles del proyecto.
Desafio de diseño: objetos inteligentes (resolución)
(continuación de Desafio de diseño: objetos inteligentes)
Hay varias formas de atacar este problema de la “testeabilidad”.
La primera opción que muchas veces viene a la mente, es hacer públicos los métodos privados y testearlos unitariamente. Si desde el punto de vista práctico esta opción puede parecer viable, cuando la miramos desde el punto de vista conceptual resulta incorrecta, pues dichos métodos son conceptualmente privados y no seria correcto cambiar su visibilidad para solo probar la clase. Si estuvieramos trabajando con C# Visual Studio nos ofrece una alternativa basada en reflexion para acceder a miembros privados de la clase, pero conceptualmente esto sigue siendo incorrecto.
Si pensamos el problema un poco más, nos daremos cuenta que puede que la clase tenga algunos problemillas de responsabilidades. Para ser más explícitos, tiene demasiadas responsabilidades: decidir si moverse y en caso positivo hacerlo, decidir si disparar y en caso positivo hacerlo, etc, etc. Bueno, si asumimos este diagnostico entonces hemos dado el primero paso: identificar el problema.
Repensemos la cuestión una vez más. Una clase que toma muchas decisiones (si X, si Y, si X, etc) y hace muchas cosas (X, Y, Z, etc). Cada una de esas cuetiones las hemos encapsulado en un método privado de cara a tener un código más legible. ¿y si fueramos un paso más allá? ¿Que tal si convertimos cada uno de ese métodos privados en una clase? De esta forma tenenemos una clase con la lógica de movimiento, otra clase con la lógica de disparo y asi sucesivamente. Así nuestro objeto inteligente tiene mucho menos código y su responsabilidad está limitada a coordinar “las estrategias” de movimiento, disparo, etc, etc. Al mismo tiempo cada estrategia puede ser testeada independientemente.
Bueno, este ha sido el primer desafio, próximamente vendrán algunos más.
Desafio de diseño: objetos inteligentes
Estaba preparando un ejemplo para algo3 cuando me surgió esta cuestión.
Como ya he mencionado en algo3 solemos programar juegos. En general los juegos tienen ciertos personajes que van actuando autonomamente con el paso del tiempo, a estos objetos es a lo que llamo objetos inteligentes. Por poner un ejemplo, tomemos el clásico juego de naves Gálaga, donde las naves enemigas actuan autonomamente con cierta lógica interna.
Cuando llevamos esto a código siguiendo el paradigma orientado a objetos, estas naves solo debieran tener un método público del tipo actuar, el cual seria invocado desde el GameLoop. Dentro de dicho método, cada nave decidiria si moverse en una determinada dirección, o si disparar, o si hacer ambas cosas al mismo tiempo, etc. Con el fin de que dicho método no quede demasiado largo, generalmente extraeremos varios métodos privados: uno con la lógica de movimiento, otro con la lógica de disparo, etc, etc.
Ahora la cuestión es: ¿como escribir pruebas unitarias para esta clase cuando tiene un solo método con tanta lógica? Es claro que es posible escribir pruebas unitarias para estos casos, pero si intentan hacerlo verán que no les quedará código muy feliz, pues el código de arrange de cada prueba podria resultar bastante largo y engorroso de escribir debido a todos los caminos posibles dentro del método bajo prueba. Una opción para evitar esta situación podria ser hacer públicos los métodos privados y asi escribir pruebas por separado para la lógica de movimiento, para la lógica de disparo, etc, etc, pero esto implicaría poner públicos ciertos métodos que naturalmente seria privados, con el solo fin de hacer pruebas. Definitivamente esta opción me hace ruido.
¿Entonces? Tengo una propuesta, pero será parte de otro post, mientras tanto, los invito a lo que piensen.
Continuará….
Adopción de C# en aumento
Desde hace ya un par de años el Algo3, les permitimos elegir el lenguaje de programación a utilizar en el TP grupal. En un comienzo la elección estaba restringida a Object Pascal (Delphi) o Java y en la actualidad es Java o C#. Históricamente la mayoría de los alumnos se han inclinado por Java en una proporción de 4 a 1 (y estoy siendo generoso con C#).
Pero resulta que este cuatrimestre, particularmente en el curso JT (que es en el que estoy yo) ha habido una adopción masiva de C#, de 9 grupos, al menos 6 han elegido C#. La única explicación que se me ocurre para esta situación particular del curso JT es la influcia de los docentes.
En este curso somos 4 docentes: Pablo, Gabi, Diego y yo. Este cuatrimestre, desde que comenzamos a estudiar lenguajes de tipado estático, la mayoría de las clases las dieron Gabi y Diego, ambos afines a C#, por lo cual casi todos los ejemplos en nuestra clase fueron mostrados en C#. Esto, sumado al buen manejo de Gabi y Diego del Visual Studio, resulta una influencia considerable para los alumnos.
Pero la verdad recien la sabremos al final del cuatrimestre cuando hagamos la clase de cierre.
Un examen de Algo3 de 2001
Aprovechando el fin de año, decidí hacer una profunda limpieza de hogar. En el medio de la tarea encontré un sobre de papel con (casi) todos los exámenes de mi carrera. Entre ellos encontré mi examen de algoritmos 3, corregido por PabloS y con un 10 (uno de los pocos de mi carrera).
¿Que opinaria un alumno reciente de este viejo examen?
Tráfico de examenes en la clase de consulta
Ayer hicimos la clase de repaso previa al parcial en Algo3, una práctica que implementamos con muy buen resultado el cuatrimestre anterior.
Esta clase tiene una dinámica especial que difiere de la tradicional clase consulta: pedimos a los alumnos que se separen en grupos, cada grupo tiene 15 minutos para elaborar un set de preguntas sobre una unidad en particular, luego intercambiamos las preguntas entre los grupos para que las contesten y finalmente, hacemos una revisión entre todos de las preguntas y las respuestas.
El dato de color es que durante la clase de consulta de ayer, estábamos con PabloS y veíamos que algunos alumnos recolectaban plata, entraban y salían del aula llevando fotocopias. Esto llamó mi atención y disimuladamente me acerqué a ver de que se trataba. Resulta que el objeto de “tráfico” era un parcial resuelto tomado en un cuatrimestre anterior. En un primer momento me resultó muy chocante, pero luego de unos minutos, recordé que yo también solía hacer eso 
¿y quien no?.
Comienzo de clases en Fiuba
Esta semana comenzamos en segundo cuatrimestre. Como siempre voy a estar dictando Algo3 y también como suele ocurrir los segundos cuatrimestres, voy a dictar Teoría de algoritmos (TDA). Habiendo transcurrido la primer semana de clase, tengo algunas curiosidades para compartir.
Curiosidad 1: es la primera vez que tenemos más alumnos en TDA que en la práctica 1 de Algo 3. En TDA tenemos anotadas unas 45 personas, que en caso que todas cursen efectivamente la materia, va a hacer durísima la corrección de trabajos prácticos. Por otro lado en la algo3 tenemos alrededor de 20 alumnos y somos 4 docentes, lo cual es excelente, pues vamos a poder hacer un trabajo mucho más personalizado.
Curiosidad 2: en TDA tenemos dos alumnos de intercambio provenientes de Francia y según comentó DiegoF, en la práctica 2 de algo3 hay una alumna en la misma condición.
Curiosidad 3: bueno, en realidad no es una curiosidad sino una mejora, apenas comenzamos el cuatrimestre y ya tenemos definidos los 3 trabajos prácticos. Sinceramente no recuerdo que hayamos tenido una situación así previamente y es justamente esa la curiosidad.
Respecto de este último punto, como de costumbre en Algo3, procuramos que los trabajos prácticos sean juegos y este cuatrimestre no es la excepción. Los trabajos 1 y 2 son juegos, mientras que el trabajo 0, consiste en la implementación de ciertas leyes de mecánica clásica (velocidad, fuerza, etc, etc) que son necesarias para los trabajos 1 y 2. Otro punto positivo respecto a esto, es que en esta ocasión resolvimos el TP antes de entregarselo a los alumnos, para validar el alcance y la dificultad del mismo (resolvimos dijo el mosquito, en realidad yo solo sugerí que deberiamos hacerlo y fue Eugenio quien finalmente lo hizo).
Fin.
Planificación 2011-2 algo3@fiuba
Ayer durante la última fecha de examen integrador, realizamos una reunión de cátedra para planificar el próximo cuatrimestre.
Durante la reunión tratamos algunos de los puntos a mejorar detectados durante las retrospectivas del cuatrimestre anterior.
Puntualmente sacamos en concreto la definición de los 3 trabajos prácticos que vamos a dar y también definimos algunos puntos sobre la implementación de mejoras al titiritero.
Personalmente estoy muy contento con los trabajos definidos pues me parecen muy apropiados ya que van a permitir a los alumnos integrar conocimientos de otras materias y modelar problemas en distintos dominios.
