Tablero Integrado de Equipo

Me uní a mi equipo cuando este ya llevaba varios meses trabajando en el proyecto. Una práctica que me sorprendió es que todo el código de la aplicación pasa por una revisión de pares utilizando merge-requests. Personalmente prefiero el pair-programming a las revisiones de código pero ese es tema de otro post. El punto aquí es que esta forma de trabajo nos lleva a que frecuentemente se nos acumulen merge-request esperando a ser revisados y retrasando el flujo de entrega. Al mismo tiempo ocurre que el autor del merge-request no puede dar por cerrada la story y para no estar ocioso comienza a trabajar en una nueva story aumentando así el work in progress (wip). Punto aparte.

El fin de semana estaba leyendo el capítulo de Visual Management de @SolePinter y de repente se me ocurrió que si tuviéramos esta información bien presente al alcance de la mano eso podría ser un buen primer paso para la solución del problema. Como el equipo está distribuido, el tablero físico no iba a funcionar así que aprovechando que hacía rato que no programaba Ruby me senté y me dí el gusto de programar un tablero digital que muestra en una misma pantalla la cantidad de merge-request activos en todos nuestros repositorios, la cantidad de tareas en curso en nuestro backlog (consultando Trello) y algunas otras cosillas. Además de consultar la información tiene cierta lógica para actuar de semáforo, pintando de rojo o verde cada indicar dependiendo de cierto límites pre-configurados.

tid_v1

Si vemos que esto funciona es posible que siga agregando funcionalidades al tablero y en una de esas tal vez lo comparta para que lo usen otros equipos.

Nuevo libro: Herramientas Ágiles

Durante el AOC 2016 repetimos la experiencia del AOC 2015 y escribimos un libro y es justamente ese segundo libro el que ahora está disponible.

El primer libro trató sobre relatos de experiencias del uso del métodos ágiles. Este segundo libro trata sobre técnicas, lo cual me parece en cierto modo una camino natural: primero uno hace, experimenta, luego a partir de la experiencia repetida, generaliza dando origen a técnicas aplicables distintos contextos.

El libro está disponible en forma totalmente gratuita en diversos formatos digitales en la plataforma GitBook y también está disponible en forma físico en la plataforma Hesiodo (el formato físico no es gratuito).

¡Mis felicitaciones y agradecimientos a todos los autores por sumarse a esta iniciativa y lograr este nuevo entregable!

herramientas_agiles

El camino freelancer, parte 3: la mejor parte

Cuando empecé a recorrer este camino lo que más valoraba era la libertad horaria. Con el correr del tiempo comencé a valorar otros aspectos, todos ellos relacionados con la posibilidad de elegir: elegir mis proyectos, elegir mis clientes, elegir mis compañeros de trabajo, elegir la fecha y extensión de mis vacaciones.

Obviamente a la hora de elegir uno debe poner diversos factores en la balanza: expectativas económicas, motivación, finanzas, valor estratégico, diversión, seguridad, probabilidad de éxito, etc, etc. Lo bueno es que es uno mismo quien realiza la ponderación de cada uno de esos factores.

En este sentido si estas pensando en comenzar tu camino freelancer podrías ir pensando cuales sería tus criterios para elegir tus proyectos.

Continuará…

Time to learn Smalltalk: big opportunity

A while ago Stef and his troop started working on a MOOC (massive online open course) about Pharo Smalltalk.

The course is finally live and its formal name is Live Object Programming in Pharo.  The course content is very interesting because it goes far beyond Pharo Smalltalk. Of course it covers Pharo/Smalltalk syntax but it also covers OOP foundations and how OOP mechanisms are implemented in Pharo.

I think this course is a great opportunity for all those programmers who are not familiar with Smalltalk and specially those that are only familiar with static-type languages (like java and c#), believe me: Smalltalk will blow your mind!

The course started last week, but don’t worry it is seven weeks long so you are on time to join, just register here.

pharo_mooc

 

Jenkins 2 ha llegado

Así es, Jenkins 2 finalmente está aquí. Según se cuenta en el sitio oficial los puntos destacados de esta nueva versión mayor (major release) son:

  • Soporte nativo para delivery pipelines
  • Mejoras de usabilidad
  • Completa compatibilidad con versiones anteriores

Tuve la oportunidad de verificarlos cuando pasé uno de mis proyectos a la versión pre-release que Jenkins publicó hace un tiempo. Adicionalmente a esto noté:

  • «Independencia» de Maven, lo pongo entre comillas porque no estoy seguro que el término apropiado sea independencia. Lo que noté es que en la versión anterior, al crear un nuevo job existía la opción «proyecto Maven», cosa que ya no existe. Creo que inicialmente esto tenía sentido pues Jenkins había surgido en el mundo Java, pero en los últimos años creo que ha transcendido ampliamente el mundo Java y se ha convertido en la herramienta de-facto para integración continua.
  • Integración con Gradle para la definición de los pipelines, los cual tiene mucho sentido ya que Gradle es una herramienta que se posiciona como herramienta de build genérica capaz de buildear proyectos en distintos lenguajes.
  • Se removió el soporte nativo para repositorios CVS, quedándo nativamente soporte solo para Git y Subversion.

Más allá de estos puntos, un detalle que me llamó positivamente la atención fue que como parte del proceso de instalación, se ofrece instalar un conjunto de plugins que son los más comunmente utilizados por la comunidad.

A partir de esta nueva versión de Jenkins y de algunas charlas que he tenido con mi equipo actual de proyecto he decido empezar a trabajar en la preparación de un curso de Jenkins para dictar en Julio o Agosto.

Tipado estático vs. Tipado dinámico

Como de costumbre luego del almuerzo dominical, me senté con un café a leer mi lista de blogs. Fue en ese momento cuando me encontré con este artículo que había publicado Uncle Bob ese mismo día. El artículo está titulado «Type Wars» y en forma muy resumida es una recorrida histórica de esta interminable contienda, con opiniones intercaladas del autor y un cierre interesante.

Este tema del tipado es una cuestión que me encuentro recurrentemente en mis clases todos los cuatrimestres. En FIUBA la mayoría de los alumnos viene de programar Pascal, C y C++, mientras que en UNTREF todos vienen de programar Java. Cada vez que en las materias empezamos a trabajar con lenguajes de tipado dinámico (Smalltalk o Ruby) algunos alumnos se sienten desconcertados y en más de una ocasión surge el debate en clase. De ahora en más voy a referenciarlos directamente al artículo de Uncle Bob, más aún, voy a incluir el artículo como lectura obligatoria.

Para cerrar les recomiendo dedicar un rato para leer el artículo completo y les dejo aquí una frase excelente incluida en el mismo:

…when a Java programmer gets used to TDD, they start asking themselves a very important question: «Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?» Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python.

Extracto del artículo «Type Wars, de Uncle Bob«, artículo completo disponible en: http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

El camino freelancer, parte 2: las cosas no tan lindas

El trabajar de forma independiente trae de la mano ciertos beneficios pero también algunas cuestiones no tan «lindas», algunas de ellas conocidas y otras no tanto, sobre todo cuando uno viene de trabajar en relación de dependencia.

Debes encargarte de conseguir tus propios trabajos, ya no hay una organización que lo haga por ti. Este punto es posiblemente la mayor barrera para muchos que tienen la intención de iniciar el camino independiente. Personalmente creo que se percibe esta cuestión como mucho más difícil de lo que realmente es.

Debes encargarte de las cobranzas y finanzas. Cuando trabajas en relación de dependencia en general tu sueldo llega a comienzo de cada mes sin que tengas que enviar recordatorios ni andar persiguiendo a nadie. Cuando trabajas como independiente, dependiendo de quienes sean tus clientes puede que:

  • La persona que te contrata no es necesariamente la que te paga. Si tu cliente es una empresa puede que quien te contrate sea alguien del área de sistemas pero indefectiblemente quien te pagará será un área de proveedores o compras, gente que seguramente no te conozca y para quien serás posiblemente un proveedor más.
  • Los pagos los recibas en diferido, hay empresas que tienen políticas de pago a 30 días, o sea que: trabajas durante todo marzo, facturas a fin de marzo/comienzo de abril, pero cobras recién en mayo.

Debes encargarte de las cuestiones impositivas/legales, generalmente al trabajar en relación de dependencia tu empleador se encarga de la mayoría de estas cuestiones (al menos en Argentina), pero al ser freelancer estas por tu cuenta. Deberás contactar un contador para que te ayude con estas cuestiones o al menos para que te asesore inicialmente y luego llevar el tema tu mismo.

Debes planificar tus vacaciones siendo consciente de que puedes tomarte todas las vacaciones que gustes pero sabiendo también que durante ese período no generarás ingresos.

Se que todas estas cosas pueden sonar un poco abrumadoras, pero no lo son tanto y para que no pinte el bajón, en el próximo post prometo buenas noticias.

Continuará…

El camino freelancer, parte 1: motivación

Recurrente recibo consultas, tanto de alumnos como de colegas, sobre cómo hacer para comenzar a trabajar de forma independiente (freelance) y es por ello que finalmente he decido poner por escrito lo que he contestado ya muchísimas veces. Como un único post podría llegar a resultar muy extenso, he decidido escribir un conjunto de posts, cada uno de ellos enfocado en una cuestión particular. Este primer post lo voy a dedicar las motivaciones para trabajar independiente.

Cada vez que recibo una consulta de este tipo lo primero que hago es consultar al interesado cuales son sus motivaciones para querer trabajar de forma independiente. Esto es central pues dependiendo de la motivaciones de cada uno puede que el trabajo independiente no sea lo más apropiado.

Muchos me dicen que quieren trabajar como independientes para tener así mayor flexibilidad horaria. Bien, es cierto, en teoría el trabajar de forma independiente permite tener mayor flexibilidad horaria, pero ojo porque mayor flexibilidad no significa trabajar menos. Conozco muchos trabajadores independientes que trabajan muchas más horas que el promedio de los trabajadores en relación de dependencia que hacen el mismo tipo de tareas.  Al mismo tiempo, creo que hoy en día los esquemas de trabajo se han flexibilizado muchísimo (al menos en el mundo de la informática)  con lo cual es perfectamente factible trabajar en relación de dependencia con un acuerdo de homeworking casi completo y/o con un límite inferior a 40 horas semanales. Dada esta realidad, si lo buscas es flexibilidad horaria una opción a considerar antes del trabajo independiente, es trabajar en relación de dependencia en una empresa con «políticas flexibles».

Otro argumento común que suelo escuchar es «libertad»: «quiero tener la libertad de trabajar desde la playa o cualquier otro lugar». Este argumento es en un punto análogo al anterior, no hace falta trabajar de forma independiente para tener este tipo de libertad, existen hoy en día muchas empresas dispuestas que sus empleados trabajen en forma remota desde cualquier lugar. En general esperan que uno esté disponible en determinada banda horaria, lo cual es completamente razonable y al mismo tiempo es algo que también suele ocurrir a los freelancers.

Algunos me dicen que les gustaría trabajar utilizando determinadas tecnologías. Aquí la cuestión del trabajo independiente puede tener más sentido. En general las empresas trabajan con un conjunto determinado de tecnologías y no es común que vayan cambiando muy frecuentemente ante las modas del mercado. Incluso en aquellas empresas donde se trabaja con múltiples tecnologías, no suele ser tan simple moverse entre proyectos de distintas tecnologías si uno no tiene el mismo nivel de experiencia/seniority en todas ellas. Aún así creo que hay que distinguir dos escenarios: una cosa es querer trabajar con una determinada tecnología y otra distinta es querer poder cambiar de tecnología «frecuentemente». Lo primero bien puede resolver con una cambio de empresa, mientras que los segundo es más complejo, incluso trabajando de forma independiente.

Algunos otros argumentos comunes que suelo escuchar son:

  • Poder elegir en qué proyectos participar
  • Poder elegir cuando y cuanto vacacionar
  • Construir algo propio

Creo que todas son razones válidas y el trabajo independiente puede satisfacerlas, pero antes de mandarse hay que tener en cuenta algunos puntos «no tan felices» del trabajo independiente, pero ello será parte del siguiente post.

Continuará…

Estrategias de provisioning + deployment (parte 2)

En el proyecto en el que estoy trabajando actualmente utilizamos Ansible para hacer el provisioning de la infraestructura y CodeDeploy para manejar el deployment. CodeDeploy es un servicio que Amazon provee gratuitamente a los usuarios de EC2, la plataforma cloud de servidores virtualizados de Amazon.

El funcionamiento de CodeDeploy es bastante simple: copia archivos desde Github o S3 hacia el servidor destino y permite como parte de ese proceso ejecutar algunos scripts. Pero más allá de este funcionamiento simple, la parte más valiosa de CodeDeploy es la capacidad de trabajar en conjunto con el mecanismo de auto-scaling de Amazon de forma de simplificar el deployment a una cantidad variable de instancias ofreciendo incluso algunas variantes de estrategia (one-by-one, all-together, half-and-half).

La siguiente imagen ofrece una vista de alto nivel del proceso de deployment que estamos usando en el proyecto.

ansible_codedeploy

Continuará…