Categoría: opinion

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.

Aplicaciones varias para Desktops Linux

Aplicaciones varias para Desktops Linux

La semana pasada mi computadora con MacOS me dejó a pata y tuve que saltar a una máquina de backup con Linux. Podría haber sido Windows, pero no, preferí que sea un Linux. En particular elegí Linux Mint, un linux de la familia Debian.

Una vez instalado el sistema de base procedí a la instalación de herramientas varias.

En primer lugar instalé Terminator, una aplicación para manejar múltiples terminales.

Luego instalé un clásico: un clon Norton Commander, hay varios dando vueltas

Libro de Desarrollo Ágil de Software by 10 Pines

Fede Zuppa junto a otros colegas de 10 Pines están escribiendo un libro sobre desarrollo ágil de software. El libro está aún en proceso de escritura pero periódicamente Fede publica versiones preliminares. Tuve la oportunidad de leer una de esas versiones y a pesar de ya estar familiarizado con los temas abordados me pareció un material muy valioso.

Las explicaciones son claras y los distintos temas están presentados desde la experiencia práctica de 10Pines. Aquellos que gusten darle una leída las versiones preliminares pueden encontrarlas aquí.

Shell Script: amor y odio

Shell Script: amor y odio

Escribir scripts de shell no es una cuestión fancy. El lenguaje es bastante duro para quienes estamos acostumbrados a programar con lenguajes de objetos. Esto hace que a la hora de elegir una herramienta de scripting yo tienda a inclinarme por otras opciones como ruby o python. Pero a pesar de esto, me encuentro recurrentemente escribiendo scripts de shell. ¿Por qué? Básicamente porque funcionan en cualquier sistema Linux sin necesidad de instalar paquetes adicionales. Es por esto que siempre recomiendo a la gente que trabaja en automatización que aprenda shell scripting. Comparto algunos recursos que me han resultado muy útiles para este fin:

Mis notas del Campus-Party UY – día 2

Algunos datos de contexto general para empezar. El espacio del evento estaba dividido en zonas. La sala principal tenia stands en el centro, tres escenarios para charlas magistrales, la zona de workshops, dos espacio de trabajo (con tomas y cables de red) y la zona de prensa. En otro salón estaba la zona de comidas y finalmente en un tercer salón la zona de carpas.

A las 10.00 comencé con mi workshop de Extreme Programming en el que participaron de forma continua unas 14 personas (mas algunas otras que fueron y vieron) pero luego en la segunda parte, cuando pasamos al código, solo quedaron. Personalmente quedé muy conforme con como salio. Fue interesante el rango de edad y experiencia de los partipantes: hubo gente en sus primeros 20 años y otros llegando a sus 40. Al final del taller sorteamos algunos ejemplares de Construccion de Software y de los libros del AOC.

Ya por la tarde, luego del almuerzo, di mi charla «La ultima milla», estimo que por momentos la audiencia llegó a 100 personas. Hablé unos 45 minutos y luego di espacio para preguntas. Me sorprendió la gran cantidad de preguntas. Una vez finalicé la charla se me aceraron varias personas para seguir hablando. Parecé que dí en la tecla con un tema de interés.

Al terminar mi charla escuché la presentación de Neil Harbisson. Me resultó muy interesante como logro extender sus sentidos a partir de implantes cibernéticos. Creo que esta fue la charla con mayor audiencia que ví en toda la conferencia.

Mis notas del Campus-Party UY – día 1

Mis notas del Campus-Party UY – día 1

Llegué a la conferencia alrededor de las 10 de mañana y me fuí alrededor de las 19. Me sorprendió mucho la heterogeneidad de los asistentes. Durante la mañana percibí un público más adoscelente, estudiantes de secundaria o primeros años de educación terciaria. Ya por la tarde y sobre todo luego de la 5, empezó a llegar gente con un promedio de edad mayor.

Participé de un par de charlas entre las que destaco:

  • La charla de Personal Branding que dió la gente de la Universidad Católica de Uruguay.
  • La charla de la gente de Genexus en la que contaron el caso de la app de la liga mexicada de futbol

Más allá de las charlas tuve varias oportunidades de networking.

Mañana será mi turno de pasar al frente. A las 10 de la mañana estaré dando un workshop sobre Extreme Programming. Luego por la tarde, a las 15.30 daré una charla titulada: «La última milla, del fin de la iteración a la puesta en producción«. En el siguiente post les cuento que tal me fue.

Preparando MeMo2 2019

La primera novedad que tenemos es la extensión del equipo, 5 ex-alumnos de la materia se suman como colaboradores. Esperamos que esto nos ayude a mejorar los tiempo de corrección y tener una mirada del curso más cercana a los alumnos.

Por otro lado estamos ajustando la planificación y el contenido para hacer hacer más foco en cuestiones diseño y programación.

Según nos indica el sistema de inscripción parece que este cuatrimestre tendremos record de alumnos, hay momento hay 27 inscriptos.

En términos de herramientas seguiremos trabajando con Ruby y GitLab pero extendemos el uso de GitLab, o sea, más allá de la funcionalidad de repositorios e integración continua, utilizaremos también las funcionalidades de issue tracking.