Categoría: Ingeniería de software

Curso de Extreme Programming y tutorial de desarrollo de aplicaciones con Padrino

Desde hace un tiempo vengo trabajando con mi colegas de Kleer en la preparación de un curso de desarrollo de aplicaciones con prácticas ágiles. En cierto modo es un curso intermedio/avanzado de Extreme Programming. Durante el curso se verán temas como SCM, BDD, TDD, Mocking, Continuous Delivery, Pair programming, Design Patterns, SOLID, etc.

La idea del curso es ver estos conceptos y poner manos a la obra programando una aplicación empresarial utilizando Github, Travis, Ruby, Padrino y Heroku, entre otros. Dado que la idea es trabajar sobre los conceptos previamente mencionados, nosotros proveeremos una aplicación base sobre la cual se desarrollará el curso y sobre la que los alumnos deberán implementar nuevas funcionalidades poniendo en práctica los conceptos/prácticas en estudio.

Aprovechando el desarrollo de esta aplicación, he decido ir generando una serie de artículos y videos a modo de tutorial, para mostrar cómo encarar el desarrollo de una aplicación utilizando las mencionadas prácticas y herramientas.

Para facilitar las cuestiones de setup, estoy utilizando una máquina virtual con Linux Mint 14. Pueden descargarse la imagen base en forma totalmente gratuita desde virtualboxes.org. Esta imagen se puede ejecutar en diversas plataformas utilizando Virtual Box.

Una vez que tengan la imagen funcionando, es necesario instalar algunas cosillas, cuyo detalle pueden ver aquí.

En los próximos días comenzaré a publicar videos de 5 minutos mostrando como desarrollar la solución utilizando las mencionadas herramientas.

Prometedor curso online de Ingeniería de Software

Esta semana estoy comenzando un nuevo curso online en Coursera. En este caso se trata de un curso ofrecido por Standford y si bien el título es «Startup Engineering» el contenido está enfocado en cuestiones de ingeniería de software para contextos de startups web. La dinámica parece ser muy similar a la del curso Berkeley que tomé el año pasado. Tengo muchas expectativas, ya veremos.

Continuous Delivery, una visión de alto nivel

No quiero entrar en detalle sobre definiciones, beneficios e impedimentos relacionados a esta práctica. Creo que hay suficientes fuentes de información en la web al respecto (con solo googlear el término continuous delivery encontraremos alrededor de 18.000.000 resultados).

Asumiendo que el lector ya está familiarizado con las definiciones básicas, quiero compartir mi visión de esta práctica.

Un concepto central en la práctica de continuous delivery es el denominado Deployment Pipeline. El mismo modela el proceso de la organización para materializar la implementación de una idea/necesidad del negocio. Dos puntos a destacar:

  • Hablamos de organización y no de equipo, porque este proceso involucra varios sectores de la organización más allá del equipo de desarrollo.
  • Hablamos de materializar una idea/necesidad de negocio. No basta con que el software esté desarrollado, la necesidad no se resuelve con el código dentro de un repositorio o en un paquete .zip, sino con el software corriendo en un ambiente donde pueda ser utilizado por el cliente.

La primera parte de este este Deployment Pipeline debe darlo el equipo de desarrollo con la implementación de la práctica de integración continua, lo cual puede llegar a ser un interesante desafío si el equipo trabaja sobre código legacy (entiéndase legacy=sin pruebas). Aquí es importante destacar que incorporar la práctica de integración continua va mucho más allá de poner un Build Server a monitorear el repositorio, compilar el código y ejecutar los tests.

La segunda parte del Deployment Pipeline es la que involucra a otros sectores de la organización, pues es la parte que recorre los distintos ambientes hasta llegar a producción.

Un caso real de conflicto entre atributos de calidad

Existe entre ciertos atributos de calidad una relación conflictiva. Un caso típico lo representan seguridad y usabilidad.

Una técnica común para implementar seguridad, es pedir al usuario el ingreso de una clave a la hora de realizar ciertas operaciones. En algunos casos, esta técnica se lleva al extremo pidiendo al usuario confirmación, re-confirmación e ingreso de clave, por operaciones que el usuario considera «triviales». Esto suele fastidiar al usuario, el cual, con el fin de tener una mejor experiencia en el uso de la aplicación, termina desactivando las verificaciones de seguridad. Aquellos que han trabajado con Windows Vista es posible que hayan experimentado una situación de este estilo.

Esta semana viví otro caso similar: tuve que realizar unos tramites en la AFIP. Un portal tan seguro como anti-usable. Ventanas emergentes por todos lados, postback contantes, scrolls infinitos, etc, y casi nada de web 2.0. Pero más allá de esto resulta que la clave de usuario (llamada clave fiscal) tiene asociada un nivel de seguridad que habilita a realizar ciertas operaciones. En mi caso necesitaba realizar una operación que requería un nivel de seguridad de clave superior al que yo tenia. Entonces, me surgió la gran pregunta: ¿cómo hago para elevar el nivel de seguridad de mi clave? Respuesta: es un trámite personal que debe realizarse en una oficina de la AFIP, ja!

Ojo, esto no es una crítica a la AFIP, sino un ejemplo real del conflicto entre estos dos atributos de calidad: seguridad vs. usabilidad.

Prácticas de desarrollo y delincuencia cotidiana

Este post surgió a partir de una charla con mi colega Gabriel Iglesias.

Estábamos hablando sobre prácticas de desarrollo en distintos contextos: la industría, la universidad, proyectos open source, etc.

Gabi comentó que en un momento le tocó trabajar en un contexto donde habia varias «malas» prácticas (comitear código en el repositorio sin el correspondiente mensaje de log, no respetar la convención de codificación, utilizar nombres de variables no descriptivos, etc). Esto no me extrañó en lo más mínimo, pues hay muchos contextos así, pero el hecho de que sea algo común no significa que sea correcto ni que uno deba aceptarlo. Es ahí donde surge la relación con la delincuencia. Hoy en día los actos delictivos son algo cotidiano en ciertas zonas de nuestro pais, pero ello no significa que sean correctos.

Ahora pensando a la distancia se me ocurre otra relación entre estas dos cuestiones:  un programador que no respecta las convenciones y/o no pone los mensajes de log en los commits ¿no es acaso un delincuente? Para pensarlo. Fin.

PD: Gracias Gabriel

Retrospectiva de Ing. de Software, primer cuatrimestre 2012

Antes de entrar en detalle sobre los resultados de la retrospectiva, quiero destacar por qué hacemos restrospectivas. La respuesta es simple: para mejorar. La idea es revisar como se desarrolló la materia intentando identificar puntos positivos y negativos, y partir de su análisis definir: qué cosas mantener, qué cosas cambiar y que cosas probar. Ahora sí, vamos a la restrospectiva.

Para la retrospectiva, utilizamos la técnica del timeline, mi favorita para estos casos (cierre de cuatrimestre). Lamentablemente, solo participaron 5 de los 7 alumnos. De todos los items identificados, una cuarta parte estaba relacionada a cuestiones «de ambiente» ajenas a la materia y sobre las cuales prácticamente no tengo posibilidad de influencia (por ejemplo: fallas en la infrastructura informática de la universidad). Respecto del resto de los items, esto es lo relevante:

Items a mantener

  • Estructurada iterativa de la materia
  • Actividades de aplicación
  • Dictado de una clase en forma remota
  • Presentación de invitados de la industria
  • Dinámica de evaluación final
  • Restrospectiva al final de cada iteración y restrospectiva final

Cuestiones a mejorar

  • Dificultades varias con Sinatra
    • Recomendar un tutorial y darlo con anticipación suficiente
  • Evaluación online
    • Hacer revisar las preguntas por un tercero para asegurar que sean claras y evitar posibles ambigüedades
    • Hacer una al final de cada iteración
    • Resolver las dificultades técnicas de la herramienta para permitir ver el resultado y las respuestas correctas al finalizar la evaluación
  • Retos del profesor (si, yo, los sermoneo mucho cuando no cumplen con las tareas)
    • No calentarme tanto
    • Mejorar las formas
    • Automatizar la corrección y parte del feedback con alguna herramienta
  • Material utilizado en clase no disponible (en algunas clases utilicé ppts que luego no compartí)
    • Publicar el material utilizado o bien ser explícito de antemano que no será publicado
  • Poca visibilidad de las notas
    • Publicar las notas al final de cada iteración

Para probar

  • Lecturas voluntarias: compartir algunas lecturas/videos opcionales que les permitan sumar «puntos adicionales» al presentarlos al resto de la clase
  • Proveer una guia de lectura para todas las lecturas, asi leen más enfocados
  • Dedicar los primeros 10 minutos de la primer clase de la semana para repasar los puntos destados de la lectura realizada

Bueno, esto es todo, voy a intentar incorporar todas estas cuestiones el próximo cuatrimestre.

Cierre de cuatrimestre en UNQ, segunda promoción

El jueves pasado realizamos la restrospectiva de cierre del cuatrimestre. Comparto aqui algunos números:

  • Este cuatrimestre se anotaron 7 alumnos
  • Los 7 completaron la materia
  • La nota final promedio fue 7,42
  • Tuvimos 30 clases organizadas en 4 iteraciones
  • Tuvimos 2 visitas de profesionales de la industria
  • Leimos más de 12 artículos
  • Hicimos varios ejercicios de BDD y TDD con Ruby
  • Desarrollamos 3 aplicaciones trabajando en grupo, utilizando Scrum, user stories, cucumber, sinatra y github.
  • Hicimos varias actividades para ejercitar diferentes prácticas: pajarraco scrum, fábrica de aviones, estimación de subastas, etc.

Creo que este segundo cuatrimestre ha sentado las bases para lo que pretendo que sea la materia, con lo cual el próximo cuatrimestre será muy parecido.

En el siguiente post, compartiré los resultados de la retrospectiva.

Nota: los iconitos representan a los alumnos ausentes el día de cierre que fue cuando tomamos la foto.

Cómo enseñar/aprender a estimar

Tengo la impresión de que este es un tema muy pobremente tratado en los contextos académicos. Digo esto basado en mi experiencia personal y en lo que he hablado con varios colegas.

En mi caso vi la temática estimación en una clase en una materia, donde el docente realizó una explicación de diversos métodos. Nada más, sólo una explicación teórica. Nada de práctica para pudieramos entener mejor los métodos. Lamentablemente creo que esto no fué una situación aislada, pues he hablado con varios colegas de diversas casas de estudios y la situación no es muy distinta.

Personalmente creo que la estimación, al igual que varias de las actividades de la ingenieria de software, es una actividad que se aprende a partir de la práctica.

Cuando tuve que preparar el tema estimaciones para la materia que dicto en UNQ, determiné utilizar el siguiente enfoque:

  1. Explicar algunas generalidades sobre estimación (quien, cuando, para que, etc)
  2. Comentar brevemente los métodos más difundidos
  3. Explicar en detalle dos métodos
  4. Hacer un ejercicio grupal de estimación en clase
  5. Darles un apunte para lean y refuercen lo explicado en clase
  6. Pedirle a los alumnos que estimen cada tarea de la materia antes de realizarla
  7. Hacer un segundo ejercicio grupal de estimación en clase

El punto (6) lo hemos hecho a lo largo de todo casi toda materia, estimando y planificando cada tarea (esto es: cada alumno lleva un excel donde registra cuando va realizar la tarea de la materia y cuando tiempo estima decicarle). Luego de realizada la tarea, deben registrar también el tiempo real insumido. Con esto apunto a que los alumnos no solo hagan el ejecicio de estimar, sino que también se acostumbren a planificar.

Obviamente este enfoque me lleva más de una clase, pero creo que bien vale la pena.

Mi dream team

Estaba preparando mi clase de Ingeniería de software de mañana, cuando me vino a la mente la idea que quiero compartir con este post.

Resulta que esta clase va a tener dos partes: revisión de las  evaluaciones y visita de un invitado. Estaba pensando en como presentar al invitado cuando decidí que con una simple oración debería ser suficiente:

«Si tuviera que armar un dream team para llevar adelante un proyecto de desarrollo de software, este individuo seria la primer persona que incluiria»

Tal vez alguien lea esto y piense que la persona merecedora de esta frase debe ser un excelente programador, muy habilidoso, muy productivo, etc, etc. Un groso en una palabra. Y en parte sí, lo considero un groso, pero… ¿es un excelente programador? Mmm, si pero no es el mejor que conozco ¿es muy productivo? mmm…si nada nada del otro mundo.

Entonces…¿por qué he de incluirlo en mi dream team? Porque es un profesional capaz de adaptarse al contexto, tiene una sólida formación, es criterioso pero sobre todas las cosas: es una persona en la que tengo absoluta confianza y con la que sé que puedo trabajar armónicamente.

¿Y tú? ¿que cuestiones tendrías en cuenta para armar tu dream team?

Architectural Kata @ Agiles BAires

Ayer tuve el gusto de participar de un architectural kata facilitado por @MartinSalias. La actividad se realizó en el contexto del encuentro mensual de la comunidad ágil de Buenos Aires y contó con más 20 asistentes.

Nos dividimos en grupos de 5 personas y usando hoja y papel cada grupo trabajó en resolver un desafio de arquitectura en un lapso de 45 minutos. Como mencionó uno de los participantes (creo que @ajlopez sino me equivoco) : «… pasamos más tiempo interpretando la consigna y debatiendo el alcance,  que en las cuestiones técnicas» y aunque parezca llamativo que creo este intercambio resultó muy enriquecedor.

Luego cada grupo cada grupo tuvo 5 minutos para exponer su solución y otros 5 minutos para responder preguntas.

Simple, concreto y enriquecedor.