Categoría: Trabajo

Técnica pomodoro con Tick Tick

Hace un tiempo empecé a usar TickTick para poder trackear todos los temas abierto que tenía. Probé varias cosas antes de llegar a este servicio: Trello en varias variantes, Notas, ToDo’s y hasta mails sin leer acumulados. Ninguno me funcionaba, de todos lo que probé el que más interesante me resultaba era Bullet Journal. Buscando alguna forma de hacerlo online y multidispositivo llegue a TickTick. Algun dia capaz que escriba sobre el proceso que me arme, pero hoy en particular me gustaría hablar de la técnica pomodoro que esta app me hizo re-rescubrir.

La técnica pomodoro en pocas palabras

La técnica tiene un par de reglas fáciles pero que aumenta mucho la productividad. Lo podemos resumir en:

  1. Seleccionar la tarea sobre la que queremos trabajar
  2. Poner un timer en 25 minutos.
  3. Trabajar en la tarea (y solo en la tarea) hasta que el timer avisa que pasaron los 25 minutos.
  4. Después de 25 minutos nos tomamos un breve descanso de 5 minutos.
  5. Luego del descanso volvemos al paso 1.
  6. Cada 4 ciclos nos tomamos un descanso más largo, de 15 minutos.

Es clave que durante los 25 minutos que dura el pomodoro no nos dejemos interrumpir. Hay muy pocas cosas que no puedan esperar 25 minutos en el peor de los casos.

Pomodoro usando TickTick

Pomodoro en la app TickTick. Tambien esta en la web.

Intente varias veces usar pomodoro. Nunca logre tener un éxito. Un dia, mientras usaba TickTick, descubrí que tenía un timer para hacer pomodoro. Hice 1 ciclo y me gusto. Hice 2 ciclos y me gusto más. Cuando estaba por arrancar el tercer ciclo me interrumpieron y no pude hacer ninguno más durante el día.

En otro momento esto lo hubiese tomado como un fracaso. Pero a la noche, cuando hice un repaso del día, me di cuenta había cerrado más temas durante esa 1 hora en la que hice los 2 pomodoros que durante el resto del día plagado de meetings.

Mientras pensaba en esto se me presentaron unas preguntas: ¿Quien dice que hay que hacer 8 horas de pomodoro al día? y luego ¿Cuántos pomodoros hacen falta para sacarle el mayor provecho posible al dia sin estar limitado por la técnica? Mi objetivo son 4, no siempre lo logro, y eso esta bien.

Pomodoro como base para el Deep Work

Si no leiste Deep Work te lo recomiendo. Al menos el resumen, del que, hasta ahora, no escribí un artículo. En una oración podemos decir que deep work habla de que: en un mundo plagado de distracciones el éxito lo obtienen quienes pueden hacer foco y cerrar temas.

Y bueno… mira como vienen a encajar las piezas ¿no?. Un sistema para trackear tareas. Una técnica para facilitar el foco. Un mindset que se empieza a formar. Todos los condimentos necesarios.

Ahora soy un defensor de la técnica pomodoro. Sabiendo que tenemos que elegir la cantidad de ciclos que más se adecue a nuestros días. Tendremos días donde podremos hacer varios. Otros ninguno. Yo, por ejemplo, tengo los Jueves de meetings. Ese día se que no voy a hacer ninguno, pero también sé que esos Jueves son los que me populan la lista que ataco el resto de la semana usando lo que más me convenga para cada tarea. Para varias es efectivamente la técnica pomodoro, pero otras las puedo encarar de otra forma.

Escribir el primer borrador de este articulo me tomo exactamente 1 pomodoro, el timer sonó mientras escribía la última oración del párrafo anterior. Luego de mi merecido descanso voy a usar otro pomodoro para revisar, formatear y agregar las imágenes. Sin la técnica pomodoro me podría haber tomado varios días llegar hasta aquí.

Manejo de dependencias python en AWS lambda con layers

Imaginemos lo siguiente: estas armando un proyecto desde cero y te estas apoyando 100% en las herramientas de amazon: para exponer tus servicios a internet usas Api Gateway y para autorizar a los usuarios estas usando un custom authorizer, (en lambda, serverless FTW), etc. Bueno eso es lo que yo estaba probando, una POC, para entender cómo se mueven las cosas y divertirme un rato.

Los detalles del código no son muy importante, arme una serie de clases tratando de respetar SOLID y de dejar algo bien testeable, hasta hice algo de CI con los pipelines de Bibucket. Fuera del código escrito por mi toda la solucion depende de PyJWT, una biblioteca que nos permite interactuar con JWT.

Ejemplo de proyecto para función lambda.

En mi local y en los pipelines es muy sencillo, pip install -r requirements.txt(En un virtualenv porfavor, python con virtualenv siempre, a menos que usen docker) y se instala la única dependencia que defini allí (PyJWT). Con eso ya puedo probar y hacer todo lo que necesito. Pero en lambda no se puede correr pip install. Entonces la dependencia no existe y los imports fallan.

Para solucionarlo explore algunas opciones. Varios intentos después estas son las 2 que me funcionaron.

Instalar las dependencias en el root del proyecto y subir un zip

La primer opción que tenemos para que lambda encuentre las dependencias de python es subirlas explicitamente en nuestro package de deployment. Es sucio, pero funciona. Asi, por ejemplo podemos, estando en el root de nuestra función lambda: 

pip install -r requirements.txt -t .

Con esto nos quedarán las dependencias instaladas “al lado” de nuestro código. Armamos un zip con todo, lo subimos y sale andando, se encuentran las dependencias y todos felices. Pero es una solución sucia y poco escalable.

El primer problema que tiene esto es que es muy probable que nuestro paquete pese demasiado como para ver el código en el editor online que tiene lambda. El segundo es que estaríamos mezclando el código que mantenemos con las dependencias y generando una estructura de carpetas propensa a errores.

Instalar las dependencias python en un layer/capa de AWS lambda

Lambda nos permite mantener layers. Un layer es una porcion de codigo que mantenemos por fuera de nuestra función lambda. Ese layer puede ser reutilizado por diferentes lambdas. Alli podemos subir lo que queramos, codigo propio, configuraciones, dependencias.

Acceso a los layers en AWS Lambda

Un punto importante es que nosotros creamos un layer y cuando lo subimos tenemos que indicar la compatibilidad con las funciones lambda. En mi caso, por ejemplo, tuve que indicar que mi layer es compatible con Python 3.7, que es el lenguaje base que utilice para desarrollar la función lambda.

Tuve que intentar varias veces hasta que logre que funcione c0mo espero. Lo primero que hice fue agarrar la carpeta completa de la dependencia, zipearla y crear ese layer. Luego en la función lambda lo agregue… obviamente no funciono.

Agregar un layer a una función lambda

Luego de un par de pruebas detecte que era por la estructura de carpetas. Si queremos que python encuentre las dependencia instaladas en un layer de aws lambda tenemos que respetar la estructura que sigue pip al instalarlas en un virtualenv. Esto es específico para cada versión de python, igualmente al crear el layer nos pide que indiquemos con que versiones somos compatibles, asi que no hay problema.

Entonces… para que nuestra función lambda encuentre las dependencias python que tenemos en un layer necesitamos que estas dependencias esten en una carpeta /python/lib/PythonVersion/site-packages/ en mi caso fue python/lib/python3.7/site-packages/ quedando algo tan sencillo como correr:

pip install -r requirements.txt -t python/lib/python3.7/site-packages/

zip -r dependencies.zip python

La primer linea instala todas las dependencias en la estructura de carpetas definida: python/lib/python3.7/site-packages/, empezando desde el directorio actual. La segunda línea lo mete todo en un zip.

Luego hay que agarrar el zip y subirlo al layer.

Al final… en nuestra función lambda apuntamos a la versión específica del layer y magicamente las dependencias funcionan. Esto nos deja un paquete deployable mucho más pequeño y legible ya que solo estamos subiendo nuestra lógica y no todo lo extra que nos permite ejecutarla.

La imágenes del artículo las saque de aca: https://aws.amazon.com/es/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/ ademas es un buen punto de partida para profundizar sobre lo layers de aws lambda.

The Phoenix Project, tus problemas de IT no son tan unicos

Hace un par de años me recomendaron leer The Phoenix Project, no lo hice, en parte porque tenía otros temas, pero principalmente porque mi dominio del idioma Inglés no me lo permitia. Ahora, hace un par de dias, me lo volvieron a recomendar y esta vez si lo pude leer. Es una novela, si, pero refleja tan bien lo que es trabajar en un proyecto de software que ahora no paro de recomendarlo a todo el mundo.

The Phoenix Project nos cuenta la historia de Bill, un DevOps devenido en manager, que queda a cargo de todo el equipo de operaciones de un gran compañia donde sistemas es tomado como área de soporte del core de negocio que es el de producir partes para autos. A lo largo de las páginas lo acompañamos en algunos éxitos y varios fracasos relacionados a tener un sistema productivo.

Los autores, muy sabiamente, van introduciendo muchos conceptos y promoviendo prácticas que creen que son beneficiosas para proyectos de IT. Lo hacen de forma tal que uno acompaña a Bill a lo largo de camino de aprendizaje. A su vez nos encontramos con algunos personajes entrañables y con algunos otros que nos generan rechazo. Me vi constantemente haciendo paralelismos entre los personajes y personas de mi día a día.

Ya en las primeras páginas arranca con un outage general causado, en parte, por Bill dejándose convencer de deployar a producción un proyecto sumamente riesgoso. Luego de eso, y de noches sin dormir, Bill comienza a entender que cosas causaron esa caída y cómo solucionarlas. En esencia toda la primer parte cuenta el típico camino del héroe, en este caso con una historia de IT por detrás.

Uno de los conceptos que introduce el libro es el definir el trabajo. ¿Que es trabajo en IT? Responder esa pregunta te habilita pensar tus procesos como cualquier otra actividad productiva. Hacer software es ingeniería no es arte y se tiene que abordar con un punto de vista ingenieril. Eso me gusta. Al final llegan a la conclusión de que el trabajo es:

  • Proyectos del negocio.
  • Proyectos internos.
  • Cambios.
  • Trabajo no planeado.

Donde el trabajo no planeado es lo peor que nos puede pasar.

El paso siguiente es pensar el desarrollo de software como un todo. Usando el concepto de las tres vías. Concepto que se trabaja en otros libros y sobre el que se puede profundizar pero que se puede resumir en:

  • Primera via: El trabajo fluye en una sola dirección… Entonces buscamos evitar el retrabajo y nos esforzamos en hacer que ese fluir sea el mejor posible. Para ellos tenemos que encontrar los cuellos de botella y accionar de forma tal que aumentemos nuestro throughput.
  • Segunda via: Ciclos de retroalimentación (feedback) cortos y amplificados. Muy de Lean, fail fast y esas cosas. En vez de desarrollar durante 12 meses para deployar algo que ya está obsoleto hacerlo de forma tal que uno pueda salir a producción 10 veces por dia.
  • Tercera via: Experimentacion continua, para aprender de los errores y lograr la maestría. Es como dicen, la practica hace al maestro. Y practicar implica equivocarse y aprender de ello.
La primera via Dev -> Ops. La segunda via el feedback, Ops -> Dev. La tercera vía todo lo que pasa en el medio con ciclos cortos que nos permitan aprender.

Es importante que sepamos que es una novela. No es un manual, no es una guia y mucho menos es un libro que nos pretende vender una forma de trabajo. De todas formas al leerlo, si son del mundo de IT, van a notar que lo que les duele a los protagonistas son las mismas cosas que nos duelen a nosotros en nuestro día a día.

Al final nos damos cuenta que nuestros retos no son tan únicos como nos parecen cuando nos encontramos con ellos por primera vez. Que los retos que se enfrentan los roles más cercanos a management son muy similares en en todos los rubros y que el éxito viene de lograr que todas las partes trabajen en conjunto.

Un gran complemento a este libro, mucho mas tecnico, es The DevOps Handbook, que recorre las tres vías con sumo detalle. A su vez hace un par de meses (Noviembre de 2019) publicaron The Unicorn Project, donde se abarca esta misma temática pero desde el punto de vista de los desarrolladores.

En The Unicorn Project se presentan los 5 ideales:

  • Localidad y Simplicidad
  • Foco, Flujo y Alegría
  • Mejora del trabajo diario
  • Seguridad psicológica
  • Foco en el cliente

Estoy deseoso de leer este libro, me parece un buen complemento a The Phoenix Project. Ambos libros creo que tienen por detrás un montón de conceptos e ideales que no son tan explícitos pero que hablan de una nueva de trabajar. Conceptos muy relacionados con el agilismo y que está bueno incorporar.

Hablando de pruebas de stress en una meetup

Hace unos días participé en una Meetup sobre testing en las oficinas de Intive (Donde trabajo). Lo mio no es el testing. Ni el manual, ni el automatizado. Pero por cuestiones de necesidad tuve que meterme en ese mundo. La verdad es que aprendi muchisimo haciendolo tanto de cuestiones de código, como de base de datos e infraestructura y, obviamente, de testing, en la meetup intente contar algunas de esas cosas que aprendí.

A continuación les dejo el video. Mi intervención arranca en el minuto 28 mas o menos. En la presentación donde hago algunas cosas en vivo trato de hacer un recorrido sobre todas las cosas que fuimos aprendiendo y haciendo para llegar a hacer 100 mil request por minuto.

La verdad es que el video no lo vi completo… Pero el dia que participe de la meetup me diverti bastante. Era la primera vez en la que presentaba algo para público externo. Y también la primera vez en la que hacía una presentación mientras hacia cosas en vivo y no en base a diapositivas.

Recibi buen feedback. Y como dije anteriormente me gusto resultó muy divertido hacerlo y charlar con el público a medida que iba haciendo las diferentes cosas que quería mostrar. Mientras charlabamos iba haciendo cosas con Jmeter, luego wrapeando los test con Taurus y por último usando Blazemeter para hacer los reportes.