Titiritero Reloaded

Titiritero es un mini-framework que desarrollamos para Algo3 de cara a ocultar algunas complejidades técnicas como manejo de componentes Swing, threads y otro, que los alumnos suelen enfrentar al realizar sus trabajos prácticos. De esta forma, los alumnos pueden concentrarse en el modelado de objetos que es el principal objetivo de la materia.

Este framework lo comencé yo mismo como ejemplo de implementación de un gameloop siguiendo premisas de diseño MVC. Más tarde algunos otros docentes y alumnos de materia hicieron algunos aportes. De esta forma la base de código fue creciendo de forma medio caótica.

El fin de semana pasado estaba preparando la clase de MVC e introducción a Titiritero para lo cual me puse a desarrollar un nuevo ejemplo basado en Titiritero. Me crucé con un par de comportamientos inesperados y cuando intenté arreglarlos no hice más que sumar más inestabilidad. Claro, esto no me sorprendió porque titiritero tenia una cantidad mínima de pruebas y su cobertura no superaba el 20 %.

Entonces decidí cortar por lo sano y reescribir el framework completo usando TDD y contemplando algunas mejoras que tenia en mente desde hacia ya un tiempo. Para tener un mejor control de los aportes de código realizados por terceros, decidí hostear el proyecto en GitHub para asi poder usar el modelo fork-pull request.

Ttiritero v2.0 está publicado en GitHub y tiene una cobertura superior al 90% 😉

Un ejemplo de cómo usarlo puede descargase desde aqui, para correrlo es necesario Java JDK 1.6+ y Ant.

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.

Sobre los trabajos finales de carrera en FIUBA

Para recibirse de ingeniero en informática en la UBA es necesario realizar un trabajo final, el cual puede ser una tesis o un trabajo profesional.

La tesis es un trabajo de investigación de caracter individual, que se realiza bajo la dirección de un profesor y que es evaluado por tres jurados entendidos en el tema de la tesis. Esta tesis es una tesis de grado y como tal no require extender la frontera de conocimiento, o sea no es necesario un aporte de transcedental a la materia en cuestión. En algunos casos este tipo de tesis suele denominarse tesina. Un esquema típico de una tesis de este nivel en un área de ingeniería podría consistir en:

  1. Caraterizar un problema
  2. Analizar las soluciones actuales (estado del arte)
  3. Proponer una solución distinta (por ejemplo utilizando una tecnologia de reciente aparición)
  4. Analizar pros y contras del nuevo enfoque propuesto.

Una particularidad de las tesis en Fiuba es que requieren que se implemente algo, o sea: hay que codear.

El trabajo profesional es la realización de un «trabajo de la vida real».  El mismo se puede realizar de a dos alumnos y requiere la supervisión de un profesor el cual también se encarga de la evaluación del trabajo. En ocasiones los alumnos aprovechan el auspicio de sus empleadores para realizar su trabajo profesional en el contexto de su actividad laboral y de esa forma «matar dos pájaros de un tiro».

En ambos casos es necesario presentar un anteproyecto y a partir de la fecha de aprobación del mismo, los alumnos cuentan con un periodo de un año para presentación del trabajo/tesis. Generalmente este anteproyecto suele presentarse cuando el trabajo ya cuenta con cierto grado de avance. Tradicionalmente (y en la actualidad la cuestión sigue igual) la mayoría de los alumnos opta por la realización de trabajo profesional en lugar de tesis, tal vez sea porque a simple vista genera menos incertidumbre que la realización de una tesis. O sea, la tesis es un trabajo de investigación y la carrera no nos prepara para realizar trabajo de investigación. En general al llegar al final de la carrera todo alumno tiene experiencia investigando como utilizar una herramienta o como resolver un problema técnico, pero ello es bastante distinto al trabajo requerido para realizar una tesis.

En está página se listan las tesis realizadas por los ingenieros en informática de la UBA hasta el día de hoy.

En mi caso, yo elegí hacer una tesis, pues tuve la suerte de por esas casualidades de la vida cruzarme con un tema que me inquietó y que me motivó a realizar un trabajo de investigación que luego se convirtió en mi tema de tesis (en su momento escribí al respecto).

Continuará…

Aventura gráfica made in Argentina (ex-FIUBAs)

La semana pasada me llego un mail de compañero de Francisco Saenz contandome del lanzamiento de Reversion, una aventura gráfica desarrollada por un conjunto de alumnos de Fiuba: Francisco (mi compañero), Fernando y Facundo.

Estos tres muchachos se conocieron en su época de estudiantes en Fiuba, luego de un par de años fundaron la empresa 3F Soluciones en el contexto de la cual desarrollaron este juego. El año pasado, Francisco y Fernando estuvieron de invitados en mi materia en UNQ donde contaron sobre el surgimiento de la empresa, su forma de trabajo y el proceso de desarrollo de este juego. Todos quedamos facinados con la presentación y muy expectantes al lanzamiento del juego que se llamaria Reversion.

Bien, finalmente el momento llegó, desde hace unos está disponible para descarga el primer capítulo de Reversion. Tal vez lo más llamativo del juego es que está ambientado en Argentina y pueden reconocerse en las distintas pantallas escenas inconfundibles de pasajes de Buenos Aires.

Dado que los juegos no son mi fuerte, les dejo el link al anuncio escrito por los creadores y para quienes les interes el backstage, les recomiendo ver el blog que escribe el equipo de desarrollo.

Mis felicitaciones al equipo de 3F y ojala les vaya muy bien con esta iniciativa, chau, ¡ me voy a jugar!

Primer cuatrimestre 2012: ¡largamos!

Asi es, largamos y casualmente en esta ocasión el cuatrimestre comenzó al mismo tiempo en FIUBA y en UNQ. Curiosamente la mi mátricula de alumnos se invirtió respecto del cuatrimestre pasado: mientras que en Ing. de Software (UNQ) tengo menos alumnos (pasé de 15 a 7) en Algo3 (FIUBA) tenemos alrededor de 50 alumnos (casi el doble que el cuatrimestre anterior).

El comienzo fue bastante movido, de hecho las clases comenzaron la semana pasada y recien ahora me pude hacer un tiempo para escribir un par de líneas. Algo interesante es que en ambas materias noto una mejora respecto del cuatrimestre anterior:

  • En Algo3, a pesar de tener más alumnos, las cantidad de consultas sobre el TP0 se redujeron notablemente. Lo cual a mi entender tiene que ver con 2 cuestiones: el enunciado del TP fue menos ambiguo y al mismo tiempo las explicaciones en clase previas a la entrega del TP0 fueron lo muy claras.
  • En Ing. de software, me asignaron un aula ¡excelente!: pizarra blanca enorme, mesas altas con ruenas y banquetas. Por otro lado tengo un alumno del  cuatrimestre pasado que me va a estar dando una mano como colaborador, lo cual espero nos permita tener un mejor seguimiento de los alumnos.

Si bien las materias tratan sobre distintos tópicos, en ambos casos estamos poniendo un importante énfasis en las pruebas: TDD, BDD, etc.

Otro punto común es que en ambos casos vamos a estar utilizando como herramienta de apoyo la plataforma Moodle.

Planes de estudio de informática, RedUNCI y ConFeDI

Por estos dias me encuentro trabajando con miembros de las comisiones curriculares de las carreras de informática de FIUBA preparando una propuesta para ser presentada en el contexto de la iniciativa de unificación de las carreras de informática llevado adelante por RedUNCI y ConFeDI.

RedUNCI (es la Red de Universidad Nacionales con Carreras de Informática) y ConFeDI (Consejo Federal de Decanos de Ingeniería) son dos instituciones argentinas referentes en lo que hace a informática (la primera) e ingeniería (la segunda).

Resulta que en 2009, el Ministerio de Educación decidió «estandarizar» las carreras de informática para lo cual convocó a estas dos instituciones. El resultado fue la resolución 786/2009 la cual define 5 carreras en el área de informática:

  1. Licenciatura en ciencias de la computación
  2. Licenciatura en sistemas
  3. Licenciatura en informática
  4. Ingeniería en Informatica/sistemas
  5. Ingeniería en Computación
La mencionada resolución define las incumbencias y ciertos contenidos curriculares mínimos (y de bastante  alto nivel) de cada carrera. Para la definición de las licenciaturas se tomó como referencia la visión de la RedUNCI mientras que para las ingenierias se tomo como referencia ConFeDI. Esto llevó a que si bien en todos los casos estamos y hablando de carreras de «computación/informática/sistemas» (o pongan el nombre que les guste) hay hoy en dia diferencias incluso en los contenidos minimos. Las licenciaturas estan estructuradas en 6 áreas de conocimiento:
  1. Ciencias Básicas
  2. Teoría de la Computación
  3. Algoritmos y Lenguajes
  4. Arquitectura, Sistemas Operativos y Redes
  5. Ingeniería de Software, Bases de Datos y Sistemas de Información
  6. Aspectos Profesionales y Sociales
Al tiempo que las ingenierías están estructuradas siguiendo la filosofia del Confedi según la cual toda ingeniería se constituye de 4 áreas:
  1. Ciencias Básicas
  2. Tecnologías básicas
  3. Tecnologías aplicadas
  4. Complementaria
Esto plantea un inconveniente no menor a instituciones como FIUBA que dictan licenciatura e ingeniería.
Es en parte por ello que en la actualidad RedUNCI y ConFeDI estan liderando una iniciativa para identificar los contenidos mínimos comunes para todas las carreras de informática.
En linea con todo esto, FUIBA ha elaborado en los últimos años nuevos planes de estudio tanto para la licenciatura y la ingenieria. Estos nuevos planes de estudio (que aún no estan vigentes) fueron elaborados por las correspondientes comisiones curriculares en forma independiente.
A continuación les dejo los links a la resolución del ministerio y las propuestas de nuevos planes de informática de FIUBA.

Resolución  786/2009 del Ministerio de Educación.

Propuesta de Nuevo Plan de estudios Ingeniería Informática

Propuesta de Nuevo plan de estudios Licenciatura en Análisis de Sistemas

Acceso a ACM para gente Fiuba

ACM (Association for Computing Machinery) es una organización que nuclea profesionales y científicos de la computación y «colabora»* en la difusión de conocimiento en este área. En este sentido la ACM tiene una seria de publicaciones periódicas entre las que se destaca la revista Communications of ACM, que ha sido portadora de famosos artículos como GoTo Statement Considered Harmful de Dijkstra.

La buena noticia es que ahora los alumnos de fiuba pueden acceder a los recursos de ACM en forma totalmente gratuita. Para ello simplemente tienen que configurar sus exploradores para usar el proxy de revistas de fiuba**. Para conectar a este proxy es necesario contar con una cuenta de correo de fiuba (@fi.uba.ar).

¡Que lo disfruten!

* Colabora es una forma de decir, pues si bien ACM concentra muchas publicaciones en la denominada ACM Digital Library, el acceso a la misma es restringido.

** No publico la dirección del proxy por cuestiones de seguridad, los interesados pueden contactarme en privado o bien contactar directamente a soporte Fiuba.

Peer Reviews

Estaba degustando un aperitivo post-cena mientras hacía un poco de zapping entre las pestañas de mi explorador. Fue entonces cuando me topé con un mail de un ex-compañero de trabajo consultando sobre el tema de referencia. Puntualmente la consulta fue:  ¿cuáles serían los 4 puntos más importantes a tener en cuenta para hacer un peer review? Luego de pensarlo brevemente, comencé a redactar mi respuesta cuando caí en la cuenta que era un tema interesante para compartir y entonces decidí publicarlo aquí.

Haciendo un poco de memoria, creo que mi primer acercamiento a este tema fue con Code Complete, el clásico de Steve McConnell. Pero no estoy seguro, tal haya sido cuando cursé la materia Calidad con Alejando Oliveros en Fiuba.

Comencemos por el principio. El términos generales podemos decir que el peer review es una técnica de revisión del trabajo producido por una persona, realizada por sus pares. El fin de este tipo de actividad suele variar levelmente dependiendo del campo de aplicación, pero usualmente tiene que ver con el aseguramiento del cumplimiento de normas/estándares, la detección de oportunidades de mejora y la validación (esto último es muy común en el campo académico, previo de la publicación de trabajos de investigación).

Bajando a concreto y hablando especificamente del ámbito de desarrollo del software, un peer review es una revisión de un artecfacto (código, especifición, etc) realizada por su autor y un conjunto de pares con el fin de evaluar su contenido técnico y/0 calidad.  La técnicas existentes para realizar este tipo de revisiones varian considerablemente en su nivel de formalidad. En un extremo podriamos encontrar el collective ownership de los métodos ágiles y en otro las inspecciones formales propuestas por el IEEE. En medio hay unas cuantas alternativas. ¿cual de todas es la más apropiada? Dependerá del fin concreto de la revisión y de la cultura de la organización donde pretenda implementarse.

Volviendo a la pregunta de mi colega que motivo estas lineas, asumo en primer lugar que su inquietud apunta a implementar la práctica de peer review en una organización y no a simplemente realizar UN peer review. Al mismo tiempo asumo que estamos habland de review en el sentido de revisión de artefactos y no de evaluar el desempeño general de una persona. Dicho esto, los principales puntos a considerar son a mi enteder:

  1. El objetivo del peer review
  2. La cultura organizacional
  3. La conformación del equipo
  4. El proceso

Si bien los items estan enumerados, dichos números no representan necesariamente su orden de importancia. Más allá de eso, tanto (1) como (2) son fundamentales para determinar la técnica concreta a utilizar y ello sin duda tiene impacto en (3) y (4).

En cuanto a (1), si el objetivo es la implementación de alguna práctica de mejora certificada como la propuestas por modelos como CMMi, entonces tal vez las inspecciones formales propuestas por Michael Fagan resulten muy convenientes.

En lo referente a (2), hay que tener mucho cuidado puessi en la orgnaización hay gente de gran antiguedad que puede sentirse amenaza por este tipo de prácticas. En casos así, la implementación puede llegar a resultar verdaderamente muy dificil y de no hacerlo con la debida precaución podría llegar a resultar contraproducente.

Respecto a (3) creo que el equipo debiera estar conformado por gente con cierto reconocimiento de sus pares, gente que ha demostrado sus habilidades técnicas y que es reconocida por sus pares independiente del título que ostenta dentro de la organización.

Finalmente respecto a (4)  resulta importante mirar el proceso completo, pues solo hacer revisiones y registrar los resultados, no va a llevar por si solo a la mejora. Es necesario definir que hacer a partir de los hallazgos de la revisión.

Algunas recomendación claves a la hora realizar revisiones:

  • El foco es la detección, no la corrección
  • El management no participa de la revisiones (a excepción de lo que se esté revisando sea algún artefacto de gestión como un plan)
  • Lo que está bajo revisión es el artefacto, no la persona que lo produjo
  • Entrenar a los revisores
  • Preparar checklist para realizar las revisiones

Para los interesados en profundizar puedo recomendar algunos materiales que acabo de chequear en mi biblioteca:

Otro titulo importante en esta temática (pero al que no he tenido accesso) es Peer Reviews in Software, de Karl Wiegers.

Por último, les dejo algunos link interesantes sobre el tema:

Espero este ayude a resolver las dudas de mi colega.

¡Nos leemos!

Eventos (académicos) 2012

Durante el año pasado mientras estudiaba para las materias que cursé en la maestría de la UNLP, se me ocurrieron dos artículos que me gustaría desarrollar para presentar en algún congreso y casualmente recien empezado el año tengo tres posibles eventos donde presentarlos.

El primero es ArgenCon, organizado por la sección argentina de IEEE. El mismo se desarrollará del 9 al 13 de Junio  en Córdoba. La fecha límite para el envío de trabajos es el 15 de Marzo.

El segundo evento es la edición 41 de las JAIIO, este año organizadas en conjunto con la UNLP entre el 27 y 31 de Agosto. La convocatoria de trabajos trabajos esta abierta hasta el 30 de Abril.

Finalmente el tercer evento que tengo en el radar es Foro Mundial de Educación en Ingenieria (WEEF: World Engineering Education Forum). Sinceramente nunca había nunca había escuchado hablar de este evento (tal vez porque no siempre se realiza en Argentina). El mismo será organizado por UTN y se desarrollará en Buenos Aires del 15 al 18 de Octubre. La fecha límite para el envio de trabajo es el 2 de Marzo.

Volviendo a los trabajos que tengo en mente, el primero es sobre el enfoque que estoy utilizando en UNQ para dictar ingeniería de software. El otro es sobre algunas ideas que he venido madurando para la enseñanza de la programación en los cursos introductorios de programación.