El alumno con el faso en la clase de Zoom

Era la tercera clase del cuatrimestre. Debido a la pandemia estábamos dictando la materia de forma virtual. Como de costumbre sólo un puñado de alumnos tenían la cámara encendida y participaban activamente de la clase. Llevábamos unos 40 minutos de clase cuando uno de los alumnos con cámara encendida, cómodamente sentado en un sillón, enciende lo que a mí pareció un faso (término usualmente utilizado en Argentina para referirse al cigarrillo marihuana). Inicialmente me sentí muy sorprendido, dudé sobre cómo actuar. Finalmente no hice nada, solo continué con la clase como si nada hubiera ocurrido.

Situaciones de este tipo nos llevan a reflexionar sobre las implicancias de las clases virtuales. El hecho de que fuera o no un faso es anecdótico, la discusión es igualmente válida si se tratara de un cigarro de tabaco. En una clase presencial creo que a nadie se le ocurriría encender un faso, ni siquiera un cigarrillo de tabaco. Pero en una clase virtual el alumno no está en las instalaciones de la institución, sino que generalmente está en sus propias instalaciones: su casa. Personalmente en clase suelo tomar mate o café, ya sea cuando estoy en el aula física en la universidad o también cuando estoy en el aula virtual desde mi casa. Debo admitir que en más de una ocasión, estando en un clase virtual, estuve tentado de destapar una cerveza pero finalmente no lo hice. Supongo que por una cuestión de “ética”: virtual o presencial estoy en un aula. De todas formas esta situación me hizo repensar el tema, aunque por ahora sigo limitándome a consumir café y mate durante las clases.

¿Qué piensa la audiencia?

No Pull-Request o Interfaces fluidas

Me invitaron a dar una charla en el track de Software Crafters de Agiles 2021 y no aún no tengo decidido de qué voy a hablar.

Tengo 2 temas posibles:

  • No Pull-Request: este es el título “marketinero”, pero siendo más sincero el título podría debería ser “Alternativas a los Pull-Requests”. La cuestión es más o menos así: el uso de Pull-Request es una práctica muy extendida en la actualidad pero su uso no siempre resulta positivo y al mismo tiempo que algunos equipos padecen de la acumulación de Pull-Request. Por otro lado el uso de Pull-Request y feature branches puede resultar un impedimento para la implementación de la práctica de Integración Continua. En esta sesión veremos técnicas alternativas que pueden darnos los beneficios que los Pull-Requests pero sin algunos de sus inconvenientes.
  • Diseño de Interfaces fluidas y DSLs: el uso de interfaces fluidas y DSLs ayudan a mejorar la legibilidad del código y en muchos casos también a reducir la cantidad de código repetido. Sin bien varios frameworks y librerías ofrecen DSLs y/o interfaces fluidas, su uso no es tan habitual en el desarrollo de aplicaciones. En esta sesión veremos algunos conceptos y técnicas para su implementación.

Ambas sesiones son de índole técnica pero la segunda incluye código y es justamente eso lo que me hace dudar dado que parte de la audiencia de la conferencia es gente que no necesariamente viene del mundo de la programación.

De todas formas, para tomar la decisión decidí publicar una encuesta en twitter, los invito a votar.

Nota: si bien la conferencia es paga, entiendo que el video de la sesión quedará disponible en YouTube.

Y un día elegí JavaScript

Resulta que tenemos que implementar cierta lógica para generar código HTML. Esa lógica podríamos codearla server-side con Python o bien client-side con JavaScript. Personalmente prefiero Python que JavaScript pero en este caso codear server-side con Python implica tener que tocar código de una aplicación Django mientras que en el caso de ir por el camino client-side/JavaScript estaría trabajando en un código completamente nuevo.

Mis compañer@s de equipo no parecían muy convencidos, estimo que porque se sienten mucho más cómodo en Python que yo, pero finalmente me dieron un voto de confianza. ¡¿Quién lo hubiera dicho?! Yo “vendiendo” JavaScript.

Continuará….

Eventos IT de Octubre

Los últimos días de Octubre pueden resultar días muy movidos para la gente de IT ya que tendremos 3 eventos importantes. Les cuento en orden cronológico.

Del 20 al 23 de Octubre será Nerdearla, un evento que ya con siete ediciones me animo a decir que se ha convertido en un clásico para la gente de IT al menos en Argentina. Sin embargo creo que el año pasado con su edición online ha generado repercusión en todo Latam. Personalmente creo que en la actualidad es uno de los mejores eventos del rubro. Este año contará con 150 charlas y talleres con speakers como Bjarne Stroustrup (creador de C++) y Brian Kernighan (creador de C). Como de costumbre el evento gratuito pero requiere registración.

Del 25 al 29 de Octubre será la PyConAr, aún no está publicado el programa y sinceramente no se mucho de esta conferencia. Nunca he participado pero he visto grabaciones de charlas de años anteriores que me parecieron muy buenas y dado que ahora estoy trabajando bastante con Python creo que este año participaré.

Del 27 al 30 de Octubre, tendrá lugar el Agiles 2021, denominado formalmente como “Jornadas Latinoamericanas de Agilidad”. Sin duda esta conferencia es mucho menos técnica que las anteriores. Sin embargo este año la lista de oradores incluye nombres como Bob Martin y Rebecca Parsons. El evento será online con un formato mixto de sesiones predefinidas (yo fui invitado a dar una) y sesiones que serán definidas por los propios asistentes (al estilo desconferencia). La registración tiene un costo de 10 dólares.

Notes from my TDD Heuristics Workshop

Yesterday I delivered this workshop at Agile Brazil Conference. It was the second run of this workshop, the first one was last week when I run a “beta” edition that allowed me to adjust several things.

Yesterday’s run was much better, we were able to do more coding and the flow of the workshop was much more clear. Just five people participated of the workshop, which was not surprising for me given that Agile conferences these days are full of people that does not code at all.

Here are the slides I used in the workshop with link to the resources I mentioned. I am very satisfied with the result of the workshop so it is very possible I include it in my software engineering courses.

Taller: Explorando heurísticas para TDD

Este es el taller que estaré facilitando la semana próxima en el contexto de Agile Brazil. Pero dado que es un taller nuevo (nunca antes lo hice) y que en el contexto de la conferencia lo realizaré en inglés, tengo intenciones hacer una corrida previa, a modo de prueba, en castellano y sin co$to, el martes próximo (5/10) a las 19.00 (GMT-3).

Les comparto aquí una breve descripción del taller.

Test-Driven Development es una de las prácticas más populares de Agile pero es al mismo tiempo una de las prácticas más difíciles. Incluso cuando la idea central TDD es fácil de entender, puede resultar verdaderamente duro de aplicar en escenarios no triviales. Entre los factores determinantes para un exitosa y cálida experiencia de TDD está la secuencia de tests que vamos eligiendo para guiar nuestro desarrollo. En este taller con modalidad “hands-on” exploraremos diversas heurísticas para un uso efectivo de TDD.

Personalmente he visto muchos programadores tratando de aplicar TDD y fallando una y otra vez. Yo mismo fallé la primera vez que intenté aplicarlo en un proyecto de industria allá por 2005. Aprendí de esa experiencia fallida, estudié, leí mucho y volví a intentarlo. Hoy en día llevo más de 10 años practicando y enseñando TDD. Estas experiencias y descubrimientos son las compartiré en este taller.

Durante el taller yo trabajaré con Java, Git e Intellij pero los participantes pueden trabajar con el stack de herramientas que gusten.

Los interesados en participar pueden contactarme aquí.

Importante: este taller está dirigido a gente que ya conoce TDD y que tiene experiencia práctica en el uso de TDD.

El riesgoso mensaje de los afortunados de sistemas

De vez en cuando veo en redes mensajes de gente que trabaja en sistemas con una onda:

No hace falta estudiar para trabajar en sistemas, yo soy Senior Lead Developer y nunca pisé la universidad.

Es cierto que hay mucha gente trabajando en sistemas sin haber estudiado formalmente una carrera de sistemas, pero de ahí a que cualquiera puede llegar a trabajar en toda/cualquier posición creo que hay una diferencia diferencia. Personalmente creo que una de las cuestiones que da un estudio formal es que habilita más oportunidades por el simple hecho de que hay empresas que valoran la educación formal a punto tal que para acceder a ciertas posición ponen como condición necesaria tener un título universitario.

Por otro lado creo que poner casos particulares como ejemplos puede ser contraproducente. El hecho de que “Pepito” haya logrado llegar a tal o cual posición sin tener un estudio formal no implica que el individuo promedio pueda hacer lo mismo. Tal vez “Pepito” tuvo un contexto, una suma de situaciones personales que derivaron en su éxito. Ojo, no estoy diciendo que sea todo simple consecuencia del destino, sino que tal vez “Pepita” aprendió a programar en la secundaria y tal vez tenia facilidad con el inglés y tal vez un tio le regaló una computadora. En fin, nada de otro mundo, pero son pequeñas cuestiones que en la suma pueden marcar la diferencia.

Conclusión:

Me parece excelente motivar a la gente para que trabaje en sistemas, “desmistificando” algunas cuestiones que muchos ven como una traba, pero creo que es fundamental hacerlo cuidando mucho el mensaje para no generar falsas expectativas y frustración.

Sobre la definición del Trabajo final de carrera

En las últimas semanas he recibido varias consultas sobre trabajos finales de carrera en FIUBA. Más allá de siempre recomendar dejar en claro el objetivo personal del trabajo, en estas ocasiones me encontré recurrentemente explicando una cuestión sobre la definición del trabajo y la presentación del proyecto. Lo escribo aquí para futuras referencias.

El primer paso formal del trabajo final de carrera es la presentación del plan de proyecto a la comisión curricular para su aprobación. Este un paso clave, y que a mi entender, en ocasiones subestimado. Si nos quedamos cortos en el nivel de detalle del plan de proyecto, corremos el riesgos que la comisión curricular no apruebe el proyecto. Al mismo tiempo si ponemos mucho nivel detalle sin tener suficiente conocimiento del dominio, la tecnología y el contexto, corremos el riesgos de estar embarcándonos en un trabajo mucho más extenso de lo esperado.

Entonces he aquí la clave: la formulación del plan de proyecto debe proveer el suficiente nivel detalle para que la comisión lo apruebe, pero para proveer ese nivel de detalle es necesario que tengamos suficiente conocimiento del dominio del proyecto, la tecnología que utilizaremos para la solución y el contexto del proyecto. Esta situación tiene distinto grado de “gravedad” en cada carrera/institución. En algunos casos no se pide tanto nivel de detalle en el plan de proyecto porque se espera que el proyecto incluya el esfuerzo de descubrimiento/análisis/requerimientos. Del mismo modo, en los casos en los que se pide mayor nivel de detalle se está, en cierto modo, forzando que al menos una parte importante del descubrimiento/análisis se realice previo/durante a la formulación del proyecto.

Si quisiéramos poner esto en términos formales (o de industria) podríamos pensar estas dos situaciones: en un extremo en una planificación adaptativa y en el otro en una planificación “up-front”. Al mismo tiempo si analizamos los trabajos finales desde una perspectiva de gestión de proyectos tenemos que generalmente los reglamentos establecen de forma fija los recursos/esfuerzo/presupuesto del proyecto (cada alumno debe trabajar X cantidad de horas como mínimo). También se establece un tiempo calendario máximo para completar el proyecto una vez aprobada la propuesta (por ejemplo 1 año calendario). De esta forma la dimensión variable del proyecto termina siendo el alcance y ahí la paradoja: en un planificación “up-front” muchas veces los alumnos (y también las empresas) intentan fijar un alcance, teniendo así las tres dimensiones del proyecto fijas de entrada: alcance, tiempo y recursos. Típico proyecto “llave en mano” con las ¿pocas? chances de que el proyecto llegue a buen puerto. Es así que nos encontramos con alumnos haciendo interminables trabajos finales y algunos otros que nunca siquiera lo empiezan.

La clave entonces podría estar en plantear un alcance variable, lo cual a mi parecer va mucho mejor con una planificación adaptativa que con una planificación “up-front”.

En términos formales, y dependiendo de las particularidades de la comisión curricular (o el organismo que sea que deba aprobar el plan de proyecto), puede que la mayor parte descubrimiento/análisis debamos hacerla antes o después de la aprobación del plan de proyecto. En base a lo que he hablado informalmente con miembros de las comisiones curriculares de FIUBA me queda la sensación de que en el caso de la Ingeniería el descubrimiento/análisis hay que hacerlo en su mayor parte antes de la presentación del plan de proyecto. En el caso de la Licenciatura el descubrimiento/análisis es en su mayor parte realizado una vez aprobado el plan de proyecto.

En este sentido, mi recomendación para los alumnos de Ingeniería en Informática es:

  • Conseguir un director y comenzar a trabajar
  • Presentar la propuesta formal una vez avanzando un porcentaje de ~30% del proyecto
  • Obviamente esta estrategia tiene el riesgo de avanzar en el trabajo y que luego la comisión no apruebe el plan de proyecto. Justamente es aquí donde resulta clave el rol del director para minimizar la chances de que el proyecto sea rechazado.

Continuous Delivery: Scripting para balanceador F5

F5 es una empresa que provee un conjunto de productos relacionados a networking: firewall, balanceador, etc. Es común encontrarse con balanceador F5 en ambientes productivos de alta carga para repartir carga entre varios nodos.

Al mismo tiempo, en aplicaciones de cierta criticidad, es común que las actualizaciones se hagan siguiendo alguna estrategia tipo “canary”, esto es:

  • “Se saca” un nodo del balanceador
  • Se le instala la nueva versión de la aplicación
  • Se verifica que la aplicación funcione correctamente
  • “Se restaura” el nodo en el balanceador
  • Se repite el proceso con cada uno de los restantes nodos

Cuando pretendemos trabajar en un esquema de continuous delivery es imprescindible que este proceso se haga de forma automatizada y para ello es necesario poder interactuar con balanceador programáticamente.

Dicho esto, he aquí un fragmento de código Python para interactuar un F5 Big-IP:

# este script depende de varias variables:
# * f5_login_url (url del balanceador para obtener el token)
# * f5_user (usuario de f5 para obtener el api token)
# * f5_pass (password de f5 para obtener el api token)
# * f5_self_service_url (url de la api del balanceador)
# * node_name (nombre del nodo sobre el que queremos operar)
# * node_id (id del nodo sobre el que queremos operar)
# * pool_id (id del pool del balanceador en el que está el nodo)


import requests
import json
import sys

# primero hay que loguearse y obtener un token
login_request = '{ "username":' + f5_user + ', "password":' + f5_pass }'
response = requests.post(f5_login_url, login_request)
if response.status_code == 200:
  response_json = json.loads(response.text)
  token = response_json["token"]["token"]
else:
  token = {}
  print('No pudo obtener token', file=sys.stderr)
  exit(1)

# sacamos el nodo
headers = { 'X-F5-Auth-Token': token }
disable_request = '{"name":"Self-Service_' + node_name + '", "resourceReference":{' \
  + '"link":"https://localhost/mgmt/cm/adc-core/working-config/ltm/pool/' + pool_id \
  + '/members/' + node_id + '"},"operation":"force-offline"}'
response = requests.post(f5_self_service_url, data=disable_request, headers=headers)

# restauramos el nodo
enable_request = '{"name":"Self-Service_' + node_name + '", "resourceReference":{' \
  + '"link":"https://localhost/mgmt/cm/adc-core/working-config/ltm/pool/' + pool_id \
  + '/members/' + node_id + '"},"operation":"enable"}'
response = requests.post(f5_self_service_url, data=disable_request, headers=headers)

Espero les resulte útil.