Event: Going Deep with Windows Azure

This past Tuesday and Wednesday Microsoft Argentina hosted the Going Deep with Windows Azure training event. We took care of second day sessions:

  1. Azure Service Bus
  2. Hadoop on Azure
  3. Node.js and Java on Windows Azure
  4. Azure Websites
  5. Azure Virtual Machines

I was in charge of the third session. I started talking about the different technologies supported by Azure and then I focused on just 2 of them: Node.js and Java. In both cases I did a brief explanation and then I run a demo.

For Node.js I deployed to azure the Pictionary sample developed by my colleague David Frassoni (alias Harry). I did it from a machine running Ubuntu and using the new Git Publishing feature offered by Azure.

In the case of Java, I create a Java Web application using Tomcat 7, Eclipse for JEE Developers and the Eclipse Plug-in for Windows Azure. I run the application i the local emulator and then showed how to deploy it to Azure.

Here is the slide deck I used in the session.

Agile Open sobre Software Libre

El evento se realizó en las instalaciones de la Facultad de Informática de la Univesidad de Belgrano. El facilitador fue DiegoF y hubo más de 30 asistentes. Tomé varias notas durante el evento, pero lamentablemente perdí mi anotador ese mismo dia, ups!. Por suerte Fer Claverino grabó este video resumiendo algunas de las ideas habladas. También Ingrid escribió al respecto en su blog.

Personalmente me alegró reencontrarme con Mariano Simone  (ex-alumno y colaborador de Algo3), simplemente un fenómeno con quien espero poder trabajar en algún momento. En una sesión que compartimos Marino mencionó algunas aplicaciones open source de FDV Solutions (la empresa donde trabajar actualmente).

Una de las sesiones en las que participé fue sobre motivación y manejo de expectativas en los proyectos open source. En ella compartí algunas de las situaciones que viví liderando la traducción de Pharo By Example.Me llevé varias ideas, pero ninguna completamente convincente.

Otra sesión interesante en la participé fue sobre puntos en común/diferencias entre métodos agiles y proyectos desarrollados con dinámica open source. Uno de los participantes de la sesión fue Federico (no recuerdo su nombre) quien participa en la distribución de Linux/Debian.

Sobre el final del evento hablamos de organizar un open space sobre la temática educación. La idea seria realizarlo hacia fines de Julio para que los asistentes puedan aplicar las ideas surgidas el próximo cuatrimestre. Los mantendré informado.

Team City organizational setup alternatives

The way we decided to manage the continuous integration process is to have one build server per project, that is an exclusive virtual machine with a Team City install running on it. These strategy gives each team full control over the server without having to worry about other projects.

Other alternative, that I think is more frequently used, is to have only one build server for the whole organization and several build agents. When using this strategy the build server concentrate the all build configurations, checkouts the code and delegate to an agent the execution of the build steps. If you have two projects with incompatible software requirements (i.e. one project running on Windows and other on Linux), then you could setup one Windows agent and Linux agent.

Last week I setup an environment following this second alternative. I took 2 machines, in the first one I installed a full TeamCity environment: server and agent, and in the second one I installed just an agent. It was very straight forward. One additional benefit of this setup is that it allows run builds in parallel.

Técnicas para administrar el backlog de proyecto

La semana pasada como parte de mis tareas cotidianas en Southworks, estuve trabajando en la capacitación de un nuevo compañero. Como parte de la capacitación le expliqué algunas técnicas que solemos utilizar para manejar el backlog de nuestros proyectos y luego de hacerlo decidí ponerlo por escrito para que esté accesible para la comunidad en general. Este es el link al post que escribí (está en inglés)

Ojala les resulte útil.

«Los ingenieros son la Victorinox de la sociedad»

Hace unos dias un colega me compartió este artículo del cual extracté el título de este post. La frase pertenece a Adolfo Guitelman, vicepresidente del Centro Argentino de Ingenieros.

Algunos datos estadísticos que aporta el artículo son:

  • En la argentina se estima que hay un ingeniero cada 6600 habitantes mientras que en paises como Israel y China hay 1 cada 1500.
  • Actualmente se reciben unos 6000 ingenieros por año, de los cuales el 32% egresa de la UTN
  • El tiempo promedio para que un ingeniero se reciba es de ocho o nueve años
  • En FIUBA, durante 2011, egresaron unos 450 ingenieros
  • En ITBA durante 2011, egresaron 240 ingenieros industriales

 

¿Incluiran esas cifras a ingenieros agronomos? No creo

¿E ingenieros en sistemas/informática/computación? Estimo que si

Backlog management Tips

In this post I want to share some tips about this topic.

Backlog basics (or preliminary definitions)

Some people tend to think that a backlog is just a simple list of items. I don’t think that is true; I try to use the word backlog to refer to a list of items that are prioritized and estimated. Of course, the prioritization is done by the customer while the estimation is done by the technical team.

What are the items in the backlog? Depending on the context, the items can by user stories, use cases or simply tasks. When working on a development project I try to avoid having tasks in my backlog because in many cases tasks do not add value to the customer who prefers user stories. In most cases, what really adds value to the customer is working software and that is represented by a group of user stories.

The backlog is commonly used to organize work but is also used to provide visibility of the project’s status .

Backlog recommendations

Make the status EXPLICIT

A very common strategy to show the status in a consumable way is to use a semaphore pattern (green-yellow-red): Done, In progress, Blocked, Pending. Using this convention is very easy to detect smells. For example, if there are many yellow stories it could mean that there is too much work in progress, and you are not focused on completing specific stories.

Note: if you are using a dashboard, then the status is given by the position of the item in the dashboard.


Limit the work in progress

Completed items are the only real measure of progress, so you should focus on completing items instead of accumulating stories in progress. This leads us to the following question: How many stories can be in progress at the same time? There is no single answer; it depends on the length of time, but each person should work on ONE item at a time. In a particular situation it could be that two items are closely related, so you could decide to work on them both at the same time. But if you have 3 team members and 10 items in progress, you should look at the situation.

INVEST in SMART

When working with user stories, it is good practice to keep the INVEST acronym in mind:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable Testable

Beyond user stories, I think these considerations are very useful when creating a backlog, no matter what your items are.

Other famous acronym related to planning and very used when defining goals is SMART:

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-boxed

More information about these acronyms can be found here.

My backlog

The following picture is a screenshot of the backlog of my current project. I have highlighted some important properties:

Me aceptaron un trabajo y no me avisaron

Esto es algo que nunca me habia pasado, mmm, en realidad puede que me haya pasado anteriormente y no me haya enterado, ja!

Resulta que a comienzos de abril me llegó un anuncio del VII Congreso de Tecnología en Educación y Educación en Tecnología. Cuando entré al ver sitio y ví las áreas de interés decidí enviar un trabajo. Tomé un trabajo que habia realizado el año anterior anterior para la materia Psicología Cognitiva, lo ajusté al formato solicitado y luego de validarlo con el compañero con quien hice el trabajo, lo envíe. El tiempo pasó y nunca tuve noticias.

Pero el sábado anterior al congreso,  me llamó mi compañero y tuvimos una charla que más o menos fué:

– El: ¿vas al congreso?

– Yo: no, ¿por?

– El: porque el trabajo fue aceptado y figuras en el programa del congreso

– Yo: no puede ser, nadie me notificó y solo restan dos dias para el congreso. ¿A vos te avisaron algo?

– El: no, yo me enteré cuando entre a ver el horario de presentación de otro trabajo que envié y del que sí me notificaron, si queres me encargo de presentar este trabajo también.

Y así era, el trabajo había sido aceptado y nunca que llegó notificación alguna. Inmediatamente escribí a los organizadores para pedirles confirmación, pero la respuesta llegó 3 días después de finalizado el congreso. El trabajo fue presentando por mi compañero. La respuesta de la organzación (como ya dije: 3 dias luego del evento) fue que habian notificado a mi compañero.

Desafio de diseño: objetos inteligentes (resolución)

(continuación de Desafio de diseño: objetos inteligentes)

Hay varias formas de atacar este problema de la “testeabilidad”.

La primera opción que muchas veces viene a la mente, es hacer públicos los métodos privados y testearlos unitariamente. Si desde el punto de vista práctico esta opción puede parecer viable, cuando la miramos desde el punto de vista conceptual resulta incorrecta, pues dichos métodos son conceptualmente privados y no seria correcto cambiar su visibilidad para solo probar la clase. Si estuvieramos trabajando con C# Visual Studio nos ofrece una alternativa basada en reflexion para acceder a miembros privados de la clase, pero conceptualmente esto sigue siendo incorrecto.

Si pensamos el problema un poco más, nos daremos cuenta que puede que la clase tenga algunos problemillas de responsabilidades. Para ser más explícitos, tiene demasiadas responsabilidades: decidir si moverse y en caso positivo hacerlo, decidir si disparar y en caso positivo hacerlo, etc, etc. Bueno, si asumimos este diagnostico entonces hemos dado el primero paso: identificar el problema.

Repensemos la cuestión una vez más. Una clase que toma muchas decisiones (si X, si Y, si X, etc) y hace muchas cosas (X, Y, Z, etc). Cada una de esas cuetiones las hemos encapsulado en un método privado de cara a tener un código más legible. ¿y si fueramos un paso más allá? ¿Que tal si convertimos cada uno de ese métodos privados en una clase? De esta forma tenenemos una clase con la lógica de movimiento, otra clase con la lógica de disparo y asi sucesivamente. Así nuestro objeto inteligente tiene mucho menos código y su responsabilidad está limitada a coordinar “las estrategias” de movimiento, disparo, etc, etc. Al mismo tiempo cada estrategia puede ser testeada independientemente.

Bueno, este ha sido el primer desafio, próximamente vendrán algunos más.

Retrospectiva del tutorial de integración contínua

Hoy dí el tutorial de integración contínua que anuncié hace un par de dias.

Como de costumbre comencé con una dinámica para romper el hielo y conocer el perfil de los asistentes. Resulto que todos estaban familiarizados con la práctica de integración contínua pero no todos las utilizaban. De la gran mayoría de la sí la utilizaba una una interesante porción no había realizado el setup del del ambiente de integración, sino que utilizaban un ambiente que alguién más en su organización había configurado.

Luego de la apertura, la sesión transitó guiada por esta presentación que armé para la ocasión. Sinceramente la presentación no fué tan interactiva como me hubiera gustado, pero que estoy contento con el resultado: pudé contar todo lo que habia planeado (e incluso algunas cosillas más), hubo espacio que los asistentes hicieran sus aportes y también para contestar consultas. Nadie se animó a trabajar a la par mia e ir configurando su propio ambiente, pero creo que en parte fue porque mi forma de encarar la sesión no fue lo suficientemente motivadora para ello. Definitivamente este es un punto a mejorar.Adicionalmente a lo expuesto en el material de la presentación, hablamos sobre algunas cuestiones conceptuales y también sobre algunas herramientas adicionales: Sonar, Janky and CloudBees.

Finalmente para cerrar pedí feedback con la técnica de las carita:

  • 🙂  18
  • 😐  0
  • 😦  0

(hay que considerar que unas 4 personas de fueron antes de que terminara la actividad)

Evento: Tutorial de Integración Contínua

El próximo miercoles a las  18.30 hs. voy a dar un tutorial de integración contínua en el contexto de los encuentros mensuales del grupo Agiles @ Buenos Aires.
La entrada es libre y gratuita, pero requiere registración previa. Los interesados pueden registrarse via Meetp up
A grandes rasgos la idea del tutorial es repasar los fundamentos que sustentan esta práctica y analizar distintas alternativas técnológicas para su implementación en los distintos lenguajes. Al mismo tiempo pondremos manos a la obra automatizando el build de algunos proyectos y resolviendo los problemas más comunes que suelen aparecer. Aquellos participantes que lo deseen pueden traer sus propias máquinas para trabajar y automatizar sus propios proyectos.