Mes: abril 2019

Taller Online de Docker & Kubernetes: segunda edición completa

La semana pasada completamos la segunda edición de este taller. A diferencia de la primera edición, el flujo de los encuentros fue un poco más «trabado», pues hubo mucha charla. O sea, hubo un par de participantes muy entusiastas con muchas inquietudes que generaron preguntas, idas y vueltas. Esto esto estuvo muy bueno en cierto sentido pero al mismo tiempo generó que algunas de las explicaciones tuvieran menos profundidad o que incluso no llegaramos a hacer algún ejercicio. Al mismo tiempo hubo otros participantes que apenas hablaron. No se si una dinámica así (de mucha idea y vuelta) es mejor o no, pero definitivamente es algo a repensar y moderar para una siguiente edición.

Más allá de este detalle, el resultado del taller fue muy positivo. Estoy completamente convencido de este formato de curso y seguramente lo estaré utilizando en futuros cursos sobre nuevas temáticas.

Guía de Unit Testing – parte 1

Cada vez que empiezo a trabajar con un nuevo equipo, tarde o temprano teminamos hablando de pruebas unitarias. Al mismo tiempo es un tema que dicto en mis materias de Ingeniería de Software. Pero dado que no he encontrado un material que cubra el tema de una forma que me resulte 100% convincente, he decidido escribir esta guía. Aquí va la primera parte.

Las pruebas unitarias son una pieza fundamental para controlar la calidad del software que desarrollamos. A diferencia de lo que ocurre con otros tipos de pruebas, en el caso de la pruebas unitarias hay un concenso absoluto en que las mismas son responsabilidad del desarrollador.

Entre los beneficios que nos proveen las pruebas unitarias se cuentan:

  • Ayudan a encontrar problemas rápidamente, ya que por su naturaleza operan sobre una porción puntual y acotada de código
  • Actúan como un mecanismo de seguridad a la hora de hacer modificaciones en el código, facilitando así el desarrollo iterativo
  • Son en cierto modo documentación ejecutable lo cual a la largo plazo facilita la evolución del código

Estando entonces convencidos que queremos hacer pruebas unitarias, comencemos por dejar en claro que NO es una prueba unitaria. Según Michael Feather a test is not a unit test if:

  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can’t run at the same time as any of your other unit tests
  • You have to do special things to your environment (such as editing config files) to run it.

En términos más generales una prueba unitaria prueba un elemento en forma aislada, siendo ese elemento típicamente un objeto o un método.

Continuará…

Notas Retro, memo2@Fiuba

De cara a identificar oportunidades de mejora en la dinámica de la materia, ayer hicimos la primera retrospectiva del cuatrimestre. Hicimos el clásico keep-fix-try. Comparto algunos de los ítems más destacados:

Keep:

  • Dinámica de trabajo con GitLab
  • Bibliografía propuesta
  • Videos
  • Dinámica de interacción en la lista de correo de la materia

Fix:

  • Algunos ejercicios llevaron más tiempo de lo que se esperaba.
    • Es cierto, puntualmente 2 de las 8 tareas realizadas hasta el momento, insumieron más de las 6 horas estimadas.
    • Realmente es difícil saber cuanto tiempo le llevará a los alumnos completar un ejercicio, lamentablemente nos equivocamos en la estimación.
    • No hay mucho que podamos hacer al respecto de esto más que intentar estimar mejor.
  • Las consignas de algunos ejercicios fueron publicadas sin estar lo suficientemente pulidas, lo cual implicó que se fueran refinando mientras los alumnos ya estaban trabajando.
    • Es cierto que hubo algunos errores en las consignas, pero al mismo tiempo nos parece bien ir refinando las consignas en forma colaborativa a medida que se trabaja pues es lo que ocurre en el mundo real.
    • Nos llevamos como tarea, hacer algún mecanismo de review previo a la publicación para intentar que las consignas lleguen a la publicación estando más pulidas.

Try:

  • Que la retrospectiva la facilite alguien externo a la materia
    • Lo evaluaremos
  • Proveer una configuración Docker (como alternativa al vagrant que ya compartimos)
    • Lo evaluaremos
  • Hacer revisiones de código entre estudiantes
    • Lo evaluaremos

Al finalizar les pedimos a los estudiantes que evalúen a modo de termómetro los temas y la dinámica de la materia. Los resultados fueron muy positivos, ambas cuestiones dieron en promedio por encima de 8 (imagen adjunta)

Seminario de Postgrado en Software Delivery

Seminario de Postgrado en Software Delivery

Desde el grupo de investigación en Prácticas y Procesos de Desarrollo de Software de la Universidad Nacional de Tres de Febrero estamos planificando un seminario de postgrado en Software Delivery.

Venimos hablamos de esta idea desde el año pasado pero recién en Marzo comenzamos a trabajar en la preparación. De hecho el título del seminario aún no es definitivo. Estamos apuntando a una modalidad blended: encuentros presenciales + encuentros remotos + trabajos para realizar entre encuentros.

Respecto de la audicencia, es un seminario de posgrado, con lo cual esperamos egresados de carreras de grado en el área de informática/computación/sistemas, con experiencia en delivery de sistemas software-intensive.

Recién empezamos a trabajar en el contenido, sabemos que habrá algo de diseño/descubrimiento de producto, algo de trabajo en equipo y bastante de arquitectura, calidad y operaciones.

La idea también es que los participantes no vengan simplemente en modo alumno a escuchar. Sino que pretendemos también traigan sus propias experiencias y que el equipo docente actué más como guia/facilitador a lo largo de todo el seminario.

No tenemos idea de cuantos interesados en participar podrá haber, pero dada la dinámica que tenemos en mente, necesitamos al menos 6 participantes y posiblemente no más de 15.

Adivinanza: el proyecto con calidad

Advertencia: aunque el siguiente relato parezca ficción, doy mi palabra que es está basado en hechos reales.

Érase una vez una eṕoca en la que me toco trabjar en 2 proyectos en simultáneo. Pertenecian a organizaciones distintas. Ambos estaban construidos con la misma tecnología y ambos llevaban aproximadamente el mismo tiempo de desarrollo al momento que yo me sumé. Pero tenían algunas diferencias radicales.

A)
Un proyecto llevaba ya varios releases productivos y de hecho realizaba releases en forma frecuente. El otro proyecto tenía apenas un release que había ocurrido luego de casi 1 año de desarrollo.

B)
Un proyecto tenía pruebas automatizadas de distinto tipo que sumaban varios cientos: pruebas unitarias, de integración, de aceptación hasta incluso de performace. El otro proyecto no tenía más de 20 pruebas unitarias automatizadas, tenía muchos casos de prueba de ejecución manual pero que obviamente no se ejecutaban todo el tiempo.

C)
En un proyecto usaban trunk-based development y escribían todo el código haciendo pair-programming. En el otro proyecto usaban feature branches y merge-request/code-reviews.

D)
En un proyecto trabajaban a lo Extreme Programming. En el otro proyecto dicían hacer Scrum.

E)
En un proyecto el cliente estaba contento con los resultados y con la marcha del proyecto. En el otro proyecto el cliente no estaba contento con los resultado ni tampoco con como marchaba el proyecto.

En un proyecto me pidieron que los ayude a estabilizar el build y optimizar el tiempo que este tardaba en correr que solía rondar los 50 minutos. En el otro proyecto me pidieron dar una mano para mejorar la dinámica de trabjo en un sentido amplio.

Uno era el proyecto A y el otro era el proyecto B. Adivinen cual es cual.

Continuará…

Trabajos finales en UNTreF Computación

Algunas carreras de grado requieren que los alumnos realicen un trabajo final para completar su formación. Dependiendo de la carrera y la institución ese trabajo final recibe distintos nombres: tesis, tesina, trabajo final integrador, etc, etc.

En la carrera de Ingeniería en Computación de UNTreF los alumnos tienen que hacer un trabajo final integrador. Como parte del plan de estudios hay una materia en la que se orienta/prepara al alumno para realizar dicho trabajo, pero la realización del trabajo no es parte de esta materia. En el mejor de los casos, al finalizar la materia los alumnos tienen planteada la propuesta formal para realizar el trabajo final. La realización del trabajo requiere de la dirección de un profesor. Una vez terminado el trabajo un jurado de 3 profesores evalúan lo realizado.

Tiempo atrás tuve el honor el de ser parte de jurado de la primera camada de egresados de la mencionada carrera de UNTreF. Recientemente recibí un par de consultas de alumnos por la posibilidad de ser su director. Ello me disparó la idea de escribir este post para compartir algunas generalidades de mi visión y estrategia para la realización de trabajos finales.

En primer lugar y en términos reglamentarios el trabajo final debe representar una carga de unas ~200 horas. Esto es equivalente a una materia intensa: (6 horas semanales de cursada + 6 horas de estudio extra-clase) * 16 semanas. Lo cual significa que trabajando de forma ordenada y constante, el trabajo puede completarse en 1 cuatrimestre. Al mismo tiempo para que esto sea factible, el trabajo debería ser planteado en términos de esfuerzo/calendario fijo, dejando el alcance con cierto grado de variabilidad.

Se espera que en el desarrollo de este trabajo el alumno aplique de forma integral los conocimientos obtenidos durante la carrera. El tema debe ser acordado entre el alumno y el director. Yo personalmente tengo ciertas restricciones de temas, o sea, no dirijo trabajos de cualquier temática y al mismo tiempo siempre algunas ideas de posibles temas que me gustaría dirigir.

Adicionalmente, espero que los alumnos que hagan su trabajo final bajo mi dirección lo presenten en una conferencia académica como JAIIO-EST o CONAIISI.