Convenciones de trabajo

Desde que trabajo en forma independiente suele ocurrirme que de tanto en tanto me toca trabajar con gente nueva. Obviamente no toda la gente trabaja de la misma forma ni con las mismas convenciones. Es por esto que hace un tiempo decidí tomar un enfoque bien explícito respecto a convenciones de trabajo de cara a evitar eventuales fricciones. Comparto aquí algunas de las convenciones de trabajo que suelo utilizar

Reunión acordada = reunión agendada

Muchas veces las reuniones se coordinan hablando, pero para que realmente ocurran en tiempo y forma encuentro la necesidad de agendarlas. Ya lo decía uno de mis primeros jefe «If you don’t schedule it, it won’t happen«. Es por esto que una vez acordada la hora y lugar de reunión suelo poner la reunión en mi agenda y enviar una invitación a todos los participantes. Adicionalmente, dependiendo del tipo de reunión suelo agregar en la cita el temario a tratar.

Hora de agenda  = hora de inicio

Los horarios muchas veces son un tema delicado. Personalmente cuando agendo una reunión a las 10.00 espero que la reunión comience a las 10.00, ello implica que todos los participantes esten presentes al menos 1 minuto antes en la sala de la reunión. Esto que a algunos nos parece trivial, no lo es para todo el mundo. Mucha gente parece entender que si la reunión está agenda a las 10:00, entonces esa es la hora en que se disponen a trasladarse hacia la reunión, lo cual ocasiona obviamente que la reunión arranque bastante más tarde. Algunos otros interpretan que las 10.00 es hora en que deben ingresar a la sala de reunión, lo cual hace que entre que saludan, se sientan, se acomodan, abren el cuaderno/notebook, tardan al menos 5 minutos más para poder comenzar con la reunión. Situaciones similares ocurren con la hora de finalización. Hay gente que llegada la hora de fin, sigue con la reunión como si nada. Personalmente lo que suelo hacer cuando está llegando el final de la reunión es intentar redondear y eventualmente consultar a los participantes si están de acuerdo con estirar la reunión algunos minutos más (siempre indicando cuantos minutos más) para poder cerrar la reunión ordenadamente.

Mail recibido, mail respondido

Cuando mando un mail de trabajo con consultas/validaciones, espero un respuesta en un plazo no mayor a 36 horas hábiles. Obviamente yo mismo suelo responder en ese plazo cuando soy quien recibe los mails. Incluso cuando la respuesta sea un simple «OK«, espero recibir un mail, pues de lo contrario queda la duda de si el destinatario leyó el mail, está de acuerdo y no respondió por no tener nada que agregar o si no respondió por haber recibido/leído el mail.

Notas de reunión

Luego de cada reunión donde se toman decisiones suelo mandar un mail compartiendo un resumen de lo hablado incluyendo los puntos destacados y si las acciones siguientes (si las hubiera). Del mismo modo espero que en caso de no poder asistir a una reunión sobre una cuestión en la que estoy involucrado, espero que alguien comparta las notas de los hablado.

 

Lamentablemente no siempre logro que todo el mundo adhiera a estas convenciones, pero cuando lo logro realmente me evito muchas fricciones.

Taller de Prácticas DevOps

Aquellos que siguen mi blog saben que desde hace ya hace ya un buen tiempo vengo trabajando fuertemente con prácticas DevOps. Además de aplicar estas prácticas en mis propios proyectos de desarrollo, también he estado involucrado en iniciativas de automatización en grandes empresas como OLX y Technisys. Todo esto me ha permitido acumular experiencia, conocer herramientas y probar distintas estrategias de implementación.

Con la excusa de bajar de tierra todo este conocimiento/experiencia y compartirlo, hace un tiempo comencé a preparar un curso. El título por el momento es «Taller de prácticas DevOps»,  pero más allá del título, la idea es conocer/repasar un conjunto de prácticas (y herramientas asociadas) que han cobrado popularidad en los últimos años y que tienen un impacto directo en el time-to-market y la capacidad de responder a cambios de negocio en forma rápida desde las área de sistemas. El programa preliminar del curso es:

  • El movimiento DevOps
  • Prácticas DevOps: automatización y versionado
  • Un vistazo a las herramientas infraestructura : Chef, Puppet y Ansible
  • Un vistazo a las herramientas virtualización: Vagrant y Docker
  • Casos de reales de implementación
  • Recomendaciones para dar los primeros pasos

La primer edición de este taller la dictaré en las oficinas de Kleer en Argentina el próximo 15 de diciembre. Más información aquí.

Reflexiones sobre el programa de Agiles 2015

La conferencia ha terminado y en mi opinión ha estado muy bien. Al igual que en los últimos años, el programa estuvo compuesto por 3 tipos de sesiones: keynotes (sesiones plenarias), sesiones de open space y sesiones seleccionadas del call for papers. Es en estas últimas que voy a centrar este artículo.

Desde el punto de vista del contenido de las sesiones creo que hemos tenido una mejora de calidad respecto a años anteriores. Obviamente esto es una opinión completamente subjetiva basada en mi percepción personal y en comentarios de personas con las que hablé (tener presente que mi subjetividad puede ser muy alta pues yo mismo estuve involucrado en la selección de sesiones ;-)). 

Al mismo tiempo ocurre que el proceso de selección de sesiones utilizado en esta ocasión requirió mucho más esfuerzo que en años anteriores. La duda que aún tengo es si ese esfuerzo adicional efectivamente se tradujo en un mejora proporcional de la calidad de las sesiones. Me pregunto: ¿hay alguna forma de mejorar la calidad de las sesiones sin invertir tanto esfuerzo en proceso de selección?

Mi sensación es que no hay garantías sobre la calidad de las sesiones y al mismo tiempo creo que cualquier proceso de selección siempre tendrá una carga de subjetividad que terminará generando algunas disconformidades. En este sentido el gran desafío radica en maximizar la calidad disminuyendo las disconformidades. Y no olvidemos que la calidad también es una propiedad subjetiva, ¡ja!.

Durante la conferencia hubo algunos espacios de discusión sobre esta cuestión en los que Alan insistió en ir hacia un formato de conferencia completamente Open Space. Esta idea me gusta por el hecho de que disminuye drásticamente el esfuerzo que debe hacer el equipo organizador en la selección de sesiones (pues todas las propuestas son automáticamente aceptadas), pero al mismo tiempo me parece que aún nos falta cierta maduración en el uso del formato Open Space, o sea, como comunidad hemos realizado muchas conferencias con formato Open Space pero a pesar de ello muchas de las sesiones presentadas en nuestros Open Spaces parecen muy improvisadas y carentes de preparación, dos cuestiones que en la mayoría de los casos perjudican la calidad. Hablamos también sobre posibles estrategias para evitar la improvisación extrema/general. El camino parece ser que las sesiones sean propuestas de forma previa y que la propia comunidad pueda dar feedback de forma temprana. Esto es algo que se ha probado en algunos casos y ha reportado buenos resultados. Pero curiosamente lo probamos en Argentina y a mi parecer no funcionó pues hubo propuestas presentadas sobre las que nadie dio feedback y también propuestas presentadas cuyo autor ni siquiera asistió a la conferencia. De todas formas creo que tenemos que experimentar. La duda que me surge es si ese lugar de experimentación debe ser la conferencia latinoamericana o alguna otra conferencia local.

Continuará…

Agiles 2015: octava edición, ¿alguien lo imaginaba?

Hace un tiempo haciendo limpieza de mi casilla de correo encontré un mail de @jgabardini invitandome a participar de la organización de lo que fue Agiles 2008.

agiles_2008

Con gran gusto acepté la invitación, un par de meses después la iniciativa se materializó y tuvimos la primera edición de la Conferencia Latinoamericana de Método Ágiles: Ágiles 2008.

Desde entonces la conferencia se ha realizado todos los años de forma ininterrumpida en distintos países de la región: Argentina, Brasil, Perú, y Colombia. Este año le toca a Uruguay y por eso estoy escribiendo este artículo sentado en un bar de Montevideo ubicado en el barrio «Ciudad Vieja».

Ya desde la previa, esta edición se destaca por dos hecho inéditos:

  • la mitad de los participantes de la conferencia son extranjeros (históricamente la cantidad de extranjeros no ha superado el 40%)
  • las entradas se agotaron semanas antes de la conferencia (de hecho estoy casi seguro que nunca antes se habían agotado).

El evento comienza en un par de horas, gran parte de los participantes ya están en la ciudad y la ansiedad va en ascenso.

Me pregunto: ¿alguno de los miembros del equipo organizador de Ágiles 2008 se imaginaba que llegaríamos hasta aquí? Yo sinceramente no.

Automatización de pruebas en AS400

Hace un par de semanas comencé a trabajar un proyecto con @dfontde y @CodeRaguet para automatizar pruebas de una aplicación AS400/RPG. Nunca en mi mi vida había hecho nada con esa tecnología y creo que justamente ese fue un factor clave para que decida involucrarme en el proyecto.

Nuestro primer día de trabajo, uno de los programadores de la aplicación en cuestión nos hizo un breve tour introductorio a la plataforma AS400, al lenguaje RPG y a la aplicación sobre la cual debemos trabajar.

Dadas las particularidades de la plataforma y de cómo está construida la aplicación, decidimos tomar un enfoque de caja negra. Básicamente vamos a intercambiar mensajes con la aplicación via una cola. De esta forma nuestras pruebas se reducen a correr un setup (el cual hay que codear en RPG), escribir un mensaje en una cola, leer la respuesta de otra cola y verificar dicha respuesta. Todo esto lo vamos a codear en Java, que si bien no es «el sueño del pibe», me resulta bastante más amistoso que RPG.

Hicimos una primer prueba de concepto exitosa para entender la interacción Java/PC <-> RPG/AS400. En este momento estamos analizando la herramienta de especificación de pruebas para lo cual estamos haciendo una prueba de concepto con FitNesse.

Continuará…

El fenómeno JavaScript

Si bien JavaScript tiene unos cuantos años, desde el auge de la web 2.0 su popularidad ha ido constantemente en ascenso. En los últimos años han aparecido diversas herramientas y frameworks que permitieron a JavaScript ir más allá de los navegadores web.

Como efecto colateral, ya no importa si uno se consideraba programador Java, C# o Ruby, hoy por hoy todo el mundo debe tener cierto manejo de JavaScript.

Personalmente nunca me gustó JavaScript pero a pesar de eso no dudo en usarlo cuando creo que es la opción apropiada para una determinada solución. Eso me llevo a trabajar con jQuery y Node.js.

Recuerdo que hace dos o tres años, mientras que en el mundo JavaScript empezaban a surgir diversos frameworks y herramientas, en el mundo de los Sysadmins empezaban a popularizarse herramientas de automatización de infraestructura. Justamente en el aquel momento me encontré en un contexto en el que tuve que elegir trabajar como desarrollador FrontEnd con JavaScript o bien tomar un rol de SysAdmin/DevOp y meterme con las herramientas de automatización. Precisamente fue esta última opción la que elegí. Creo que profesionalmente aquella fue una elección muy acertada pues el manejo de herramientas de automatización me permitió participar en diversos proyectos muy interesante. Pero hace un par de meses me rendí, siendo consciente que ya no es posible escapar de la marea JavaScript me puse a aprender AngularJS y agregué a mi backlog Meteor y React.

 

Cursos en la previa de Agiles 2015

Como de costumbre en la previa de Agiles 2015 habrá un conjunto de cursos organizados de forma independiente. En ese contexto estaré dictando en Montevideo mi Taller de Continuous Delivery y Prueba automatizada.

El términos generales el taller está divido en 2 partes. La primera enfocada en los conceptos centrales de la práctica de Continuous Delivery y un conjunto de técnicas y herramientas para su implementación que incluyen Jenkins, Puppet y Docker. La segunda se enfoca en la automatización de pruebas, lo cual constituye un punto fundamental en toda estrategia de Continuous Delivery. En esta segunda parte veremos herramientas tales como JUnit, Cucumber-JVM y FitNesse. Si bien el taller tiene una base conceptual independiente de toda tecnología, la parte práctica de automatización de pruebas se realiza con Java.

Los detalles de logística e inscripción están disponibles en la página de Evolución Ágil.

Prácticas DevOps: 3 repos por proyecto

Desde que empecé a trabajar fuerte con prácticas de DevOps, hace unos 2 o 3 años que todos mis proyectos tienen al menos 3 repositorios.

El primer repositorio es el que almacena el código fuente de la aplicación. En realidad dependiendo de la complejidad del proyecto, puede que haya más de un repositorio para el código fuente.

El segundo repositorio es el almacena la configuración de la aplicación. Este repositorio tiene típicamente un 1 branch por ambiente. Hay que destacar que estoy branches nunca se mezclan, sino que evolución a la par. Cuando la aplicación requiere de un nuevo parámetro de configuración, el mismo debe ser agregado simultáneamente a cada uno de los branches con el valor correspondiente para el ambiente asociado.

Finalmente el tercer repositorio es el que contiene los scripts de deploy. Dependiendo de la infraestructura del proyecto puede que sean simplemente scripts de bash, ansible, puppet o similar.

Se viene WISIT 2015

Este sábado 19 de septiembre se llevará a cabo la jornada principal del Workshop de Ingeniería en Sistemas y Tecnologías de la Información, WISIT 2015 organizado por la gente de Proyecto Uqbar. Esta tercera edición tendrá su jornada principal en las instalaciones de la Universidad Nacional de Quilmes. Hablo de jornada principal, pues ya hubo algunas actividades que realizaron la semana pasada en instalaciones de Universidad de Buenos Aires.

El programa completo de la jornada incluye varias propuesta muy atractivas con cuestiones de Big Data, Devops, lenguajes de programación y Agile. Respecto de esto último tengo el honor de haber sido invitado a participar de un panel de discusión sobre metodologías ágiles bajo la consigna «Presente y futuro de las metodologías ágiles«.

Como de costumbre la entrada es gratuita pero hay que registrarse aquí.

En mi opinión es una jornada para no perderse.

wisit15

Capas de automatización

Este último año y medio he estado trabajando intensamente en cuestiones de automatización de pipelines e infraestructura en general, usando principalmente Jenkins, Puppet y herramientas afines.

En particular, estos últimos meses he trabajado en la automatización de despliegues de un producto software bastante complejo. La complejidad en este caso está dada por la gran cantidad de componentes de código e infraestructura involucrados: varias bases de datos relacionales, bus de servicios, sistema de colas, servidor de aplicaciones, servidor web, dispositivos móviles, etc. Al mismo tiempo el producto tiene un requerimiento de correr sobre distintos sabores de infraestructura (Oracle, IBM, OpenSource), lo cual requiere que cada ambiente (desarrollo, test, etc) tenga también varios sabores.

Para la generación de estos ambientes y el deploy de la solución a cada uno de ellos diseñamos una arquitectura de automatización/deploy de 3 capas la cual describo brevemente a continuación.

Capa 1: Sistema operativo

El primer paso es levantar los servidores con el sistema operativo correspondiente (para el caso mencionado CentOS y Oracle Linux) y realizar algunos ajustes de base sobre el mismo (configuración de red, usuarios, etc). En general esto se hace utilizando la API de la plataforma de virtualización y algunos scripts de base. Puntualmente en el mencionado caso usamos el Hypervisor de VMWare y Puppet.

Capa 2: Software de base

Ya con el sistema operativo instalado y servidor 100% funcional hay que instalar software de base: motor de base de datos, el service bus, el web server, etc. Cada uno de estos componentes hay que instalarlos y configurarlos acorde a seteos específicos de la solución. En el caso mencionado esto lo hicimos usando scripts Ansible que se disparan desde RunDeck

Capa 3: Aplicación

Lo último que resta es instalar la solución en cuestión, lo cual implica crear los schemas de base datos, desplegar las aplicaciones en los servidores/contenedores web, desplegar los flujos en el bus de servicios, etc. En el caso en cuestión esto lo tenemos implementado con simples bash scripts que lanzamos desde Jenkins.

La implementación de esta solución en este caso puntual requirió del trabajo de distintas áreas de la organización: gente de infraestructura (capa 1), gente de operaciones (capa2), gente del grupo de producto (capa3) y obviamente hubo también un cierto esfuerzo de coordinación de todos ellos.

Hay algunas cuestiones de la implementación de este caso que aún hoy no me convencen (como usar Puppet Y Ansible al mismo tiempo, hubiera preferido usar sólo 1 de ellos) y que son consecuencia de decisiones tomadas por los distintas áreas de la organización. Más allá de las herramientas particulares, creo que el esquema general de esta solución es replicable en otros contextos usando incluso otras herramientas, es por ello que decidí compartir estas líneas.

capas_automatizacion