Mes: octubre 2012

Agiles 2012: Día #3

El día completo fue con dinámica de Open Space y fue facilitado por Alan Cyment (@acyment).

La primer sesión que asistí fue la propuesta por Hernán Wilkinson, en la que hablamos sobre lambdas, closures y continuations. Muy interesante (y muy techie).

Luego participé de la sesión sobre la comunidad, en la que compartimos experiencias de las comunidades de los distintos paises de latinoamerica.

Ya por la tardé, estuve en una sesión sobre contratos ágiles, de la cual me llevé algunos puntos interesantes. En particular me gustó el enfoque presentado por Carlos (@carlosgabriel_).

Finalmente, asistí a una sesión facilitada por un joven de Intel cuyo nombre no recuerdo, en la que debatimos sobre distintos enfoques para atacar la deuda técnica. De aquí tambień saqué una listita de ideas.

Hacia las 5 de la tarde, Alan facilitó en cierre del Open space y a continuación los presidentes del evento, EmilioG y Pablo RF, hicieron el cierre y facilitaron la retrospectiva. Más allá de los clásicos agradecimientos a los sponsors, voluntarios y organizadores, el cierre contó con el condimento adicional del anuncio de la sede de la seguiente conferencia: Agiles 2013 será en Lima, ¡allí vamos!

Agiles 2012: Día #2

El día comenzó con el excelente keynote de Martin Salias (@MartinSalias) hablando sobre agilidad en las organizaciones. Resultó muy interesante la reflexión de Martín sobre el hecho de que el manifiesto ágil en sus 4 afirmaciones solo hace referencia al software en una ellas: Software funcionando sobre documentación exhaustiva. Entonces, si reemplazamos Software funcionando por Innovación de producto, podemos aplicar el manifiesto a cualquier organización. Una particularidad interesante de este keynote fue que la última parte estuvo protagonizada por la audiciencia, ya que Martín invitó a los asistentes a compartir sus experiencias/opiniones.

Luego del keynote asistí a la sesión «Refactoring Conversation Smells», facilitada por Luis Parzianello (@lcparzianello) . Generalmente estamos acostumbrados a hablar de code smells para referirnos a situaciones en el código de una aplicación que delatan algún posible problema. En el mismo sentido, es posible detectar «posibles problemas» en las conversaciones. Basada en esta analogia, la sesión tuvo una primera parte de exposición/discusión y luego una segunda dedicada a actividades prácticas desarrolladas de a pares. Me gustó y espero poder aplicar algunas de las cosas vistas.

Luego del almuerzo asistí a la sesión dictada por Thomas Wallet, en la cual jugamos al Business Value Game, un juego muy entretenido sobre valor de negocio, muy apropiado para aquellos que se estan acercando al paradigma del foco en el valor propuesto por los métodos ágiles.

Este segundo día cerró con el evento social de la conferencia, que se desarrolló en el bar llamado Canario Negro, donde entre pizzas, cerveza y karaoke, pasamos una velada muy entretenida.

Agiles 2012: Dia #1

La jornada comenzó con el KeyNote de David Hussman, cuyo título me resultó más que llamativo: «Shut up and Play Yer Guitar». Para guiar la presentación utilizó una analogía con el dominio de la producción musical, viendo al equipo como el conjunto de músicos y al scrum master como el productor. Sobre este hilo conductor habló sobre cómo agile ha ayudado a operar transformaciones en la forma que desarrollamos software. Personalmente me gustó mucho la idea de que no trabajamos en desarrollo de software sino en construcción de productos. Tengo varias notas de esta sesión, pero antes de volcarlas necesito procesarlas.

La siguiente sesión que asistí, fue la que dicté yo mismo: «Tutorial de Integración Contínua». Quedé muy contento con cómo salió. El tutorial duró 2 horas, hubo unos 25 asistentes y casi todos se quedaron hasta el final. Un desafio que debí afrontar fue que el 20% de los asistentes trabajaba con la práctica, el 40% la conocia «levemente» pero no la aplicaba y el 40% restante apenas si la habia escuchado. A pesar de esto, creo que logré un buen balance entre la teoría y los detalles de implementación. Para guiar la sesión utilicé este Prezi.

Luego del almuerzo asistí a una sesión excelente dictada por Angel Núñez Salazar (@snahider). La sesión se llamó «Test-Driven JavaScript». En la misma se venimos todo un set de herramientas mientra codificamos un un ahorcado. Saqué un montón de herramientas para investigar: Mocha, Sinon, Chai, Grunt y otras. Quedé deslumbrado por la velicidad con la que trabajó Angél y por la profundidad de sus conocimientos.

La última sesión que asistí fue la dictada por José Romaniello (@jfroma): «Opensource para agilizar». La misma consistió principalmente en ciertas ideas/opiniones que José quería compartir, algunas de las cuales me resultaron muy interesantes. Entre ellas me gustó una que se podria resumir como: «open source no es solamente poner disponible el código, sino que también sea posible realizar aportes».

Finalizada la jornada en UTN, cerramos la jornada en una cerveria del barrio universitario.

Agiles 2012: un poco de contexto

El evento se realiza en Universidad Tecnológica Nacional, Facultad Regional Regional (el mismo lugar donde se realizó JAIIO en año pasado).

En esta ocasión el viaje lo hice junto a mis colegas Kleerianos, salimos de Buenos Aires en un convoy de dos autos alrededor de las 15 hs. y arribamos a Córdoba alrededor de las 22 hs.

El evento está organizado en 3 dias, los 2 primeros de sesiones «tradicionales» y el tercero 100% open space.

En los próximos dias estaré escribiendo sobre lo que vaya aconteciendo en la conferencia.

Probando excepciones

¿Como probar que un método lanza una excepción ante una determinada situación excepcional? Usando NUnit o JUnit 4, basta con escribir el método de prueba y poner una simple anotación indicando el tipo de excepción esperada.

@Test(expected = ExceptionEsperada.class)  
public void xxxxxx(){
      // ejecutamos la código que debiera lanzar la excepción
}

Pero no todos los xUnit brindan esta posibilidad, entonces debemos apelar a una estrategia similar a la siguiente.

public void test_xxxxxx(){
     try{
         // ejecutamos la código que debiera lanzar la excepción
         fail(); // si ejecución llega hasta esta línea, entonces significa que no se lanzó la excepción esperada y por ende la prueba ha fallado
      }
      catch(ExceptionEsperada ex){
          /* si estamos aqui, entonces se ha producido la excepción esperada y no es necesario
             hacer nada pues a menos que se indique que algo ha ido mail, se asume todo estuvo 
             bien */
       }
       catch(Exception ex){
          // si estamos aqui, es que la excepción que se ha lanzado, no es la esperada, por lo tanto la prueba ha fallado
          fail();
       }
    }

Asi de simple, espero les resulte útil.

Escribiendo pruebas unitarias para código legacy

Desde que volví a trabajar en consultoría este es uno de los temas que más me he encontrado. Sinceramente no me sorprende pues:

  • TDD y la automatización de pruebas, son dos temas que están en claro ascenso de popularidad
  • Casi toda la bibliografía de TDD parte de la base de la creación de aplicaciones desde cero
  • Pero en una porción importante de casos, la gente ya cuenta con una aplicación, la cual muchas veces no ha sido diseñada de forma de facilitar su prueba

Casualmente ayer me crucé con un caso extremo. Resulta que hace un par de semanas dicté un workshop de TDD. Ayer me contactó uno de los asistentes para hacer una consulta de como encarar un caso concreto: tenia que agregar una funcionalidad a la una clase existente. La clase en cuestión tenia más de 3000 líneas de código. Si si, leiste bien, son tres ceros después del tres, o sea, tres mil líneas de código. El problema de una clase tan grande, es que resulta dificil que sea cohesiva. Se supone que pasar ser cohesiva, una clase debe hacer UNA cosa y hacer bien. Con tantas líneas, es muy posible que dicha clase esté haciendo demasiadas cosas.

Pero el problema que motivaba la consulta no eran las 3000 líneas de código, sino el constructor de dicha clase. Resulta que el constructor además de recibir varios parámetros, instanciaba un componente para conectarse a la base de datos. Eso impedia realizar una prueba unitaria de la clase, pues el solo hecho de instancialar implicaba conectarse a la base. Tampoco no habia chances de mockear la conexión pues era instanciada directamente dentro del constructor. ¿que hacer entonces?

Lo primero que uno intentaria es hacer un refactoring de la clase, pero dado que no existian pruebas de la misma, cualquier modificación implicaba un gran riesgo. Luego de analizar varias alternativas llegamos a una solución de compromiso, que nos permitiria escribir tests unitarios: agregar un constructor sin parámetros, que tenga la lógica para lanzar un excepción si era invocado en un ambiente distinto al de desarrollo/test. De esta forma podriamos instancias la clase en forma aislada en un ambiente de test y  aseguramos que no sea instanciada de esta forma en caso de estar en un ambiente distinto.

 

Preparando en Tutorial de Integración Continua

Esta semana estuve comencé a preparar el material el tutorial que voy a dictar en Agiles 2012. Decidí tomar como base el material que utilicé para la actividad que hice en Agiles@BsAs.

Entre las modificaciones que pienso incluir están Sonar, Gradle y algo de teoría de continuous delivery.

De cara a adaptar mejor el contenido a las particularidades de la audiencia, generé un formulario para relevar los conocimientos de aquellos que tengan planeado asistir. Este es el formulario en cuestión, que también está publicado junto a la descripción del tutorial en el sitio de la conferencia.

Un caso real de conflicto entre atributos de calidad

Existe entre ciertos atributos de calidad una relación conflictiva. Un caso típico lo representan seguridad y usabilidad.

Una técnica común para implementar seguridad, es pedir al usuario el ingreso de una clave a la hora de realizar ciertas operaciones. En algunos casos, esta técnica se lleva al extremo pidiendo al usuario confirmación, re-confirmación e ingreso de clave, por operaciones que el usuario considera «triviales». Esto suele fastidiar al usuario, el cual, con el fin de tener una mejor experiencia en el uso de la aplicación, termina desactivando las verificaciones de seguridad. Aquellos que han trabajado con Windows Vista es posible que hayan experimentado una situación de este estilo.

Esta semana viví otro caso similar: tuve que realizar unos tramites en la AFIP. Un portal tan seguro como anti-usable. Ventanas emergentes por todos lados, postback contantes, scrolls infinitos, etc, y casi nada de web 2.0. Pero más allá de esto resulta que la clave de usuario (llamada clave fiscal) tiene asociada un nivel de seguridad que habilita a realizar ciertas operaciones. En mi caso necesitaba realizar una operación que requería un nivel de seguridad de clave superior al que yo tenia. Entonces, me surgió la gran pregunta: ¿cómo hago para elevar el nivel de seguridad de mi clave? Respuesta: es un trámite personal que debe realizarse en una oficina de la AFIP, ja!

Ojo, esto no es una crítica a la AFIP, sino un ejemplo real del conflicto entre estos dos atributos de calidad: seguridad vs. usabilidad.

Algunas prácticas para organizar el trabajo

Hoy quiero compartir algunas prácticas para organizar el trabajo que cobran mayor relevancia cuando uno trabaja de forma independiente.

Establece horarios

Puede que al sentirte más dueño de tus tiempos terminés trabajando en cualquier horario, lo cual luego te lleva a comer en cualquier horario, lo cual te lleva a dormir en cualquier horario, lo cual te lleva directamente a un mal estado de salud.

Estaceble tu horario de trabajo dentro del horario comercial o a lo sumo sólo un par de horas defasado. Al mismo tiempo no te acostumbres a contestar mails de los clientes fuera de tu horario y si lo haces, escribelos, pero no los envies, no es bueno que los clientes se acostumbren a que les respondas en cualquier horario.

Evita el cambio de contexto

Cada cambio de contexto, requiere cierta adecuación lo cual disminuye tu productividad al tiempo que «va limando tu cabeza». Esto lo vivo todos los jueves y me afecta al extremo. Un jueves típico, comienzo el día programando C#, luego doy clases en FIUBA con Smalltalk y finalmente cierro el día dando clases en UNQ con Ruby, al llegar a casa tengo menos cerebro que una lechuga.

Si trabajas en consultoría y debes visitar a tus clientes, intenta aprovechar al máximo cada visita. Yo generalmente intento particionar mi dia en 2 slots: mañana y tarde. Cuando agendo una sesión de trabajo con un cliente busco, dentro de lo posible, que ocupe todo el slot.

Planifica con anticipación suficiente

El planificar tus actividades con anticipación te permitirá acomodarlas mejor en tu agenda y prepararte apropiadamente para llevarlas acabo. Personalmente intento programar todas mis actividades con al menos una semana de anticipación y siempre intento a más tardar el viernes al mediodia tener definida mi agenda de la semana siguiente.