Mes: abril 2013

Presentación formal del sistema de corrección: SEAL

El viernes pasado Aníbal y Martín realizaron la presentación formal del sistema de corrección de trabajos de programación y con ello completaron sus estudios para el graduarse de ingenieros en informática.

El nombre formal del sistema es SEAL: Sistema de Entregas Automatizadas Libre, un nombre apropiado en el sentido que representa lo que hace el sistema, pero desde el punto de vista comercial no tiene mucha onda (ya estamos trabajando en buscar un mejor nombre).

Como suele suceder en la presentación de los trabajos finales de carrera, la mayor parte de la audiencia son familiares de los alumnos que presentan y por lo tanto es poco lo que entienden de lo que se presenta. Siendo conscientes de esto, Aníbal y Martín prepararon una presentación muy didáctica para explicar su trabajo. Básicamente utilizaron la metáfora de un viaje a la luna para explicar el desafio que para ellos representaba hacer este trabajo de fin de carrera. Personalmente me gusto mucho la presentación, respeto los tiempo, resultó entretenida y expuso de forma adecuada el trabajo realizado.

Ha sido un gusto para mi trabajar con Aníbal y Martín, espero haberles aportado al menos un granito para su formación profesional. Al mismo tiempo les agradezco por haber confiado en mi para guiarlos en el trabajo.

¡Mi felicitaciones a los flamantes ingenieros!

presentacion_seal

El material utilizado en la presentación está disponible aquí.

Implementado un pipeline de continuous delivery en .Net

La semana pasado estuve trabajando en el tema de referencia. Como suele ocurrir cuando se trabaja con tecnología Microsoft, el stack de herramientas a utilizar es bastante distinto del utilizado al trabajar con tecnologias no-Microsoft.

Como build server hicimos un primer intento de usar TFS, pues el proyecto ya lo venia utilizando como repositorio de código y herramienta de gestión. Pero luego de dos problemas, desistimos y decidimos apostar a lo seguro: Team City. ¡Ja!, seguro que más de uno pensó que iba a decir Jenkins. No, hace un año aproximadamente analicé ambas herramientas y llegué a la conclusión que para ambientes Microsoft era más apropiado utilizar Team City.

Como herramienta de build usamos MSBuild.

Para realizar los pasajes entre ambientes, dado que nuestra aplicación es web, optamos por la propuesta de Microsoft: MSDeploy.

Continuará…

Todo un día de troubleshooting y el problema era el DNS

Resulta que conseguimos un nuevo servidor para instalar el Jenkins. La instalación como de costumbre fue muy simple, lo que llevó un poco más de trabajo fue configurarlo para que buildeara (este término me parece que no existe) nuestro proyecto.

Como parte de nuestro proceso de despliegue, era necesario que uno de los Jobs ejecutara un merge de svn.

Estuve 2 horas para hacerlo funcionar. Resulta que al correr el job obtenia un error del svn diciendo que no podia conectar al servidor. Entonces entré a probar distintas cosas para encontrar la razón del error. Me conecté al server svn, me dió ok. Revisé el plugin de conexión a svn y googleando encontré que podia haber problemas con mi versión, entonces lo actualicé. Volví a probar, el mismo error. Actualicé la versión de svn, el problema persistia. Empecé a pensar que el problema estaba en servidor svn, pero desde mi máquina conectaba OK. Pensé que habría un problema con el job, entonces cree otro. Al pepe, el error persistía.

Así seguí probando cosas, hasta que finalmente escribí al proveedor del servicio quien me confirmó que el servicio estaba funcionando bien y me preguntó que DNS estaba usando. Me fijé en el server y estabamos usando el DNS de Google, lo cual «me dejó tranquilo». Pero para mi sorpresa la gente de soporte del servicio svn me indicó que el DNS de Google no es una buena opción y que durante el año anterior habian tenido varios problemas. ¡Ja! ¿¡quien lo iba a imaginar!? Esta es la respuesta textual de la gente de soporte:

I would not recommend using Google’s DNS, it’s been very flakey the past year, so much so we no longer use it internally at all. Here are some other options: UltraDNS, Dynect, OpenDNS, Norton DNS.

Bueno, en sí, no fue todo el día, pero fue mucho más de lo que debería haber sido.

Presentación formal del sistema de corrección

Llegó el gran momento, la presentación formal del sistema que significa no solo un hito en la vida del sistema como producto, sino que también es fin de una etapa para quienes lo construyeron: Martín y Aníbal. Con la presentación del sistema estos dos alumnos FIUBA terminan su estudios de Ingeniería en Informática. Por el momento, me limitó a copiar la invitación formal que se distribuyo entre la comunidad FIUBA y la semana próxima daré más detalles sobre la publicación del sistema.

El viernes 26/04 a las 18 horas, los estudiantes Aníbal Alejandro Lovaglio y Matín Mauro Zucchiatti presentarán en el Lab. E del Departamento de Computación su Trabajo Profesional «SEAL (Sistema de Entregas Automatizadas Libre)», que realizaron con la tutoría del Ing. Carlos Fontela y el Ing. Nicolas Paez como co-tutor.

Resumen:
El presente trabajo se enmarca en la problemática de corrección de trabajos prácticos en las materias de programación. La mayor parte de la producción a evaluar se trata de programas de computadora, y resulta claro que la funcionalidad de los desarrollos constituye el núcleo de la atención dedicada por los docentes a la hora de corregir las entregas. Sin embargo, esta porción del trabajo muchas veces hace perder tiempo valioso que debiera utilizarse para revisar aspectos conceptuales, como el diseño de las soluciones o la separación de incumbencias dentro de los distintos núcleos de abstracción de dicho
diseño. Es decir que muchas veces se invierte tiempo en ver que las entregas funcionen, o cumplan con casos de pruebas, pero lo que realmente importa no es que funcione, sino cómo está construido, y cómo funciona.
Existiendo ahora tantas herramientas que nos permitirían hacer esto de manera automática, es imperativo que se abandone el trabajo artesanal de testing y que se pueda dedicar el tiempo de los docentes en cosas que requieran del criterio de una persona.

Breve descripción de la metodología, indicadores, etc. que llevaron para su gestión
La gestión del proyecto se hizo usando una metodología basada en Scrum, pero adaptada a las condiciones del equipo de trabajo, ya que los tiempos dedicados al proyecto no eran regulares y la interacción entre los miembros del equipo está limitada por las circunstancias laborales de cada uno. De cualquier manera se usó el desarrollo guiado por user stories, y se midió el avance por burndown chart de proyecto.
El desarrollo del proyecto fue pensado en una única fase, con el objetivo del proyecto cumplido a su fin.
Se trabajó con un servidor de integración continua, que después de cada commit, compila, comprueba la sanidad del nuevo código y redespliega la aplicación, poniendo disponible la nueva versión.

Están todos invitados.

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.

 

Desafio: de Heroku a Linode

Hace un tiempo comenté que estaba trabajando en un prueba de concepto para migrar una aplicación de Heroku a Linode.  Ahora parece que efectivamente tendremos que mover nuestra aplicación de Heroku a Linode.

Personalmente lo que más me inquieta es el monitoreo de la aplicación, ya que la misma se ejecutará en más de un server. No es que no sepa como implementarlo, sino que hacerlo requerirá un trabajo interesante de setup y tal vez algún cambio en la aplicación.

Continuará….

Cambiando la forma en que enseñamos: primero la tarea y luego clase

Generalmente el docente dicta una clase y luego le da a los alumnos algún texto para profundizar/repasar el tema visto en clase. Casi sin quererlo la semana pasada invertí esta dinámica y obtuve interesantes resultados. Paso a explicar:

Resulta que la semana pasada en EIS comenzamos a estudiar las técnicas y herramientas de análisis. Vimos modelado de dominio, diagramas de estado, visual story mapping y teníamos que ver también user stories. Como no nos alcanzó el tiempo para ver este último tema, les dije a los alumnos que lo investigaran por su cuenta.

La clase siguiente abordamos el tema de user stories, pero dado que los alumnos ya habían investigado al respecto, los invité a que ellos mismo preparan una clase al respecto. Salí del aula para buscar un café y los dejé para que prepararan la clase. Al regresar, expusieron el tema de una forma que me sorprendió, la exposición fue correcta y bastante completa. Faltó mencionar algunas cosillas, pero sinceramente estuvo mucho más completa que lo que yo había esperado.

Una vez finalizada la exposición de los alumnos, volvimos a repasar los conceptos vistos, profundizando en algunos puntos, destacando otros y mencionando algunas cosillas que habían faltado.

La experiencia me resultó por demás interesante y estoy convencido que a los alumnos les resulto más entretenido y al mismo tiempo el tema les quedó mucho más claro.

User Stories vs. Casos de uso

Es común que en una primera aproximación tienda a verse las user stories como análogas a los casos de uso del Proceso Unificado, en el sentido que ambos artefactos describen en cierto modo una funcionalidad del sistema. Personalmente creo que esta analogia no es apropiada, ya que mientras un caso de uso es efectivamente una especificación de un requerimiento, la user story podría a lo sumo el título de dicho requerimiento.

Es más, en un punto podríamos decir que las user stories son en su espíritu contrarias a los casos de uso: mientras que los casos de uso pretenden contemplar los detalles del requerimiento para que el programador pueda realizar una implementación completa y correcta del requerimiento, las user stories son intencionalmente vagas pues lo que buscan es promover el diálogo entre quien debe implementar la funcionalidad y quien la ha requerido.

¡Que lindo es ser Product owner en estas condiciones!

Como ya he comentado, he estado trabajando con un par de alumnos de FIUBA en la construcción de un sistema de corrección de trabajos prácticos. A lo largo del proyecto he ocupado diversos roles: director, consultor, tester, etc, pero sin duda el que más tiempo he ocupado y que más he disfrutado es el rol de Product Owner.

Es la primera vez que ocupo este rol y ¡que linda experiencia me ha resultado! Creo que en gran medida esta satisfacción se debe a que el equipo (los alumnos en este caso) han sabido contentarme, no solo construyendo un producto que satisface mis necesidades, sino que también han logrado que el trabajo sea fácil de llevar. ¿De qué estoy hablando? De cosas en un punto simples u obvias pero que no siempre se dan. Puntualmente, han entregado un producto de valor, han sabido adaptarse a los cambios pedidos, me han dado visibilidad completa y contínua del estado y el avance del proyecto y en líneas general han facilitado mucho mi trabajo como product owner.