Codewars: jugar, practicar, codear

Hace unos días recordé este sitio que conocí hace unos años, al verlo mencionado en un tweet de mi amigo el Maestro.

A raíz de esa mención volví a visitarlo y me alegró ver cuánto progreso mientras yo no estaba mirando.

Codewars es básicamente un sitio de práctica. Está basado en la idea de Code Katas, pero extendido a formas adicionales como el Kumite (una especie de competencia entre desarrolladores), y todo en un entorno colaborativo donde los participantes mismos son quienes agregan y refinan los ejercicios, también votando y comentando tanto los planteos como las distintas soluciones.

Entre las características que más me gustaron es que hay:

• Diferentes niveles de dificultad
• Tags que agrupan los ejercicios por temas, niveles, foco
• Alto nivel de gamification: los participantes tenemos Kyu (niveles), Honor (puntos acumulados), seguidores, clanes y medallas entre muchas otras característica que generan una comunidad vibrante
• Foros y comentarios bien integrados
• Un gran contenido gratuito soportado por publicidad, pero que está bien integrada y es relevante (son siempre productos o servicios de desarrollo y los avisos no son molestos), más una oferta paga económica y que más allá de ofrecer unas pocas características avanzadas para quienes realmente le dedican mucho tiempo, es casi una membresía a un club de amigos.
• Y sobre todo, la chance de aprender y/o practicar en una variedad enorme de lenguajes:
  (en este momento) C, Clojure, CoffeeScript, C++, Crystal, C#, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, Lua, Objective-C, OCaml, PHP, Python, Ruby, Rust, Shell, SQL, Swift, Typescript, y otros que todavía no tienen Katas, pero están en proceso, como: CSS3, D, Erlang, Groovy, Julia, Kotlin, Liso, Perl, R, Racket, Sass y Scala.

Para los que ya saben que soy un enfermo de los lenguajes de programación, se dan cuenta que esto es un picnic para mi.

Recién retomé, y usualmente esto es para mi un equivalente a mirar series o jugar videojuegos: un pasatiempo estimulante. Los que quieran pueden encontrarme en Codewars y eventualmente podemos hacer un Kumite.

TDD rocks! con el Maestro Angel "Java" López (+videos)

Desde hace un par de meses el Maestro comenzó a grabar unos Hangouts sobre TDD, mostrando ejemplos de algunos de sus proyectos reales, mientras implementa funcionalidades.

Los vídeos no están en español, sino en Anglish (pueden aprender algo de este dialecto en este post previo), pero si hacen click en su nombre en YouTube encontrarán otros que tiene grabados en español. Me pareció particularmente interesante esta serie porque sigue un hilo temático.

Recuerden que además de multitud de conocimientos compartidos en Twitter, el Maestro también publica un post diario (al menos) los 365 días del año, en alguno de sus blogs:

• Blog técnico en español
• Blog técnico en anglish
• Blog ecuménico en español (recomiendo su serie de 50 posts: "¿Qué es la realidad?") 

¡Que disfruten la serie!

Video: creando una aplicación desde cero con TDD

TDD es una técnica de diseño sobre la que se habla bastante (pueden ver varios post sobre el tema aquí mismo) y que realmente hace una diferencia en la calidad del código que generamos, y nos permite encarar cambios más profundos, incluso a nivel de la arquitectura ce la aplicación, con mucha más confianza.

A pesar de que hay muchos tutoriales sobre el tema, no es tan frecuente conseguir recursos que vayan más allá de ejemplos sencillos, generalmente con poca funcionalidad, mínimas dependencias, etc.

En esta VAN (reunión virtual) de ALT.Net Hispano, el Maestro Angel "Java" López deja de lado por un rato la física cuántica y dedica poco más de dos horas a crear una aplicación desde cero con TDD, basándose en ASP.NET MVC 3. Pero más allá de Visual Studio o C#, la manera en que el Maestro avanza en el desarrollo de la aplicación puede servir para entender el proceso a cualquier programador, en cualquier lenguaje: pasos mínimos, refactorización, foco en el modelo, etc.

La sesión es larga, pero sumamente recomendable. Incluso para quienes ya practican TDD, permite apreciar un estilo definido de construcción que seguramente tenga influencia en el nuestro, aunque no lo adoptemos completamente, o nos haga replantear parte de la manera en que avanzamos con algunos pasos. Personalmente creo que para todo desarrollado (y mejor aún si se lo ve en equipo) estas son horas extremadamente valiosas para invertir, que ahorran semanas a futuro.

Recuerden también que hay casi 90 sesiones de este estilo en el portal de ALT.NET Hispano (cientos de horas de entrenamiento gratuito).

A continuación el video, en español, de 144 minutos de duración:

Video: Lenguajes dinámicos meta-circulares, por Hernán Wilkinson

En la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE, Hernán Wilkinson presentó esta sesión sobre lenguajes dinámicos en el contexto de entornos meta-circulares, un valor agregado a las características básicas de los tipos dinámicos.

Hernán es uno de los principales especialistas locales en programación y diseño orientado a objetos, uno de los miembros fundadores de FAST (la Fundación Argentina de Smalltalk) y organizador de la conferencia anual internacional Smalltalks que se realiza en Argentina en diversas localidades, en forma rotativa (la edición 2011 está corriendo hoy mismo en Quilmes).

Actualmente Hernán es uno de los socios de 10pines, una consultora de entrenamiento y desarrollo de software especializada en metodologías ágiles y buenas prácticas de ingeniería.

En la sesión (de una hora aproximadamente) podrán verlo explicar conceptos generales sobre lenguajes dinámicos, puntualizando la diferencia entre tiempos de evaluación y chequeo de tipos, y profundizando luego en la diferencia de flujo de trabajo al efectuar TDD en entornos meta-circulares como una imagen de Smalltak.

No tengo disponibles los slides de la sesión, pero una buena parte de la presentación incluye ejemplos sencillos en Java y en Smalltalk, con lo que el video es más importante. Van a continuación las cuatro partes de aproximadamente 15 minutos cada una.

Video: Programando de a pares con Emilio Gutter

En esta nueva sesión de programación de a pares me sumo a Emilio Gutter para hacer un ejercicio utilizando Java.

Conocí a Emilio a fines del 2006 cuando fuimos compañeros de equipo durante el curso de Certified Scrum Master dado por Tobias Mayer. Nos divertimos mucho durante ese curso, y varios de los que pasamos por ahí nos mantuvimos en contacto después a través de una primer lista de distribución que fue uno de los puntos focales de donde surgió el grupo de organizadores de la primer conferencia de la serie Ágiles: Ágiles 2008.

Emilio lleva más de 10 años trabajando en desarrollo de software y es un desarrollador trotamundos que ha trabajado en proyectos en Argentina, Brasil, UK, USA, Francia, Rumania y Bulgaria, por lo menos. Actualmente es uno de los líderes de su consultora 10pines, que brinda servicios de desarrollo, entrenamiento y coaching, con fuerte foco métodos ágiles, incluyendo un alto compromiso con la calidad y la cultura organizacional.

En el video podrán ver cómo hacemos un ejercicio de diseño en Java, usando Eclipse con JUnit 4 y la biblioteca de mock objects mockito y planeábamos utilizar también harmcrest,una biblioteca de matchers (o predicados) muy útil para realizar aserciones en las pruebas unitarias, pero no alcanzó el tiempo esta vez, así que quedará para más adelante.

Les dejo el video (de aproximadamente 25 minutos) y espero que lo disfruten:

Dobles de pruebas en Python llegados desde España

En un mensaje de ayer en la lista de TDD en español, el amigo Carlos Blé, autor de el único libro (que yo conozca) de TDD en español (y gratuito), anunció la publicación de su framework para Dobles de Prueba en Python, construido porque no encontraban en su equipo uno como lo que ellos buscaban, y también como ejercicio.

El framework se llama pyDoubles, y el proyecto está hosteado en BitBucket para quienes quieran colaborar o derivarlo (está publicado bajo licencia Apache 2.0).

Según explican en la documentación, pyDoubles sigue la nomenclatura propuesta por Gerard Meszaros (en su ya clásico libro xUnit Test Patterns) para clasificar los dobles de prueba en stubs, spies o mocks.

Resumiendo brevemente, en el entorno de las pruebas unitarias, los dobles nos permiten reemplazar dependencias externas (que no son las que queremos probar) por otros objetos que -sólo a efectos de la prueba- se comportan como los verdaderos, facilitando la prueba de el SUT (o sistema a probar, por sus siglas en inglés).

Uno de los ejemplos clásicos es usar un doble para la capa de datos de un componente, ya que al probar nuestra lógica no necesitamos un repositorio de datos real, porque es dificultoso de mantener pero además es mucho más lento que utilizar un objeto con la misma interfaz o protocolo, que simplemente me devuelve lo que espero en el contexto del test.

La diferencia entre stubs, spies y mocks es sutil y discutida usualmente en la comunidad (desde el famoso artículo de Martin Fowler "Mocks aren't Stubs"). Lo importante en este caso es que el framework soporta los tres tipos.

Como el sitio de pyDoubles está ahora en inglés, traduzco brevemente la introducción explicando las categorías:

STUB

Reemplaza la implementación de uno o más métodos en la instancia del objeto que juega como colaborador o dependencia, devolviendo el valor que explícitamente devolvemos en la prueba. El stub es un método, pero es común llamar stub también a una clase que los contiene. El stub no tiene ningún tipo de memoria.

SPY

Hace lo mismo que el stub, pero puede registrar los métodos que se llamaron durante la ejecución de la prueba y cómo fueron invocados. Se utilizan para verificar la interacción o comportamiento.

MOCK

Además de lo que hacen los stubs y spies, es más estricto en la especificación del comportamiento esperado del sistema a probar. Antes de llamar a cualquier método en un mock, la prueba debe declarar, usando el framework, qué métodos y cómo deben ser llamados para que este comportamiento se verifique por completo. De lo contrario, la prueba falla con una excepción "UnexpectedBehavior" (comportamiento inesperado).

 

Como ellos explican en la documentación no hay tipos de dobles "mejores" que otros. Los mocks son más estrictos y por lo tanto hacen que las pruebas que los usan sean también más frágiles (más susceptibles a fallar por cambios menores en la implementación). Los spies son más flexibles en ese sentido, pero no alcanzan cuando necesitamos especificar un comportamiento especial en gran detalle. El resultado es que usualmente se utilizan combinaciones de los tres.

En la práctica, como siempre, conviene siempre aplicar la solución más sencilla que funcione, usualmente empezando con stubs, y luego recurrir a spies o mocks tipos cuando la prueba lo requiere.

Para ver ejemplos del uso del framework, les recomiendo ir directamente a la documentación.

Video: Programando de a pares con Martín Alaimo

En este segundo video de la serie de sesiones de programación de a pares le toca el turno a Martín Alaimo, de Kleer.

Conocí a Martín en los comienzos de la comunidad Agiles.org en Argentina, cuando él todavía trabajaba en Accenture, y seguimos en contacto desde entonces, compartiendo varios eventos, viajes y peripecias del mundo del desarrollo.

Martín tiene algunas certificaciones más tradicionale como PMP (Project Management Professional) o Certified Java Developer, y varias dentro del campo ágil, como Certified Scrum Master Practitioner (la variante más concreta de esa certificación algo cuestionada) y más complejo aún, es uno de los pocos entrenadores certificados del curso de Scrum Development en América Latina (el único en Argentina y alrededores, hasta donde yo se).

Pero lo más importante no son los títulos sino la larga experiencia que demuestra desarrollando o enseñando, y la buena disposición para compartir esos temas con la comunidad, que lo han llevado a organizar los Yoseki Coding Dojo (de los que hablé en otro post) y asumir la responsabilidad de co-dirigir la organzación de Agiles 2011.

En esta sesión lo que tratamos de recorrer con Martín es el camino del diseño basado en dos prácticas complementarias pero que a veces parecen solaparse: TDD (Test-Driven Development) y ATDD (Acceptance Test-Driven Development).

Para el ejemplo, que codificamos en Ruby, usamos Cucumber para las pruebas de aceptación (ATDD) y RSpec para las unitarias (TDD).

Espero que les resulte interesante, y como siempre, esperamos feedback para saber por dónde continuar o qué temas tratar en más profundidad.

 

Video: Programando de a pares con Carlos Peix

Con este post comienzo una serie de entrevistas que tenía en mente desde el comienzo de este blog el año pasado, pero a la que no le encontraba el formato definitivo, hasta hace poco.
En realidad, me di cuenta que no quería hacer entrevistas convencionales, y me parece que lo mejor para nosotros desarrolladores es ver a otros en la práctica, así que estoy comenzando a grabar sesiones de programación de a pares.
La idea es aprovechar la excusa para darme el gusto de programar con amigos y conocidos de la industria regional. Algunos, como este primer caso con Carlos, serán sentados a la misma mesa, y algunos serán remotos, a distancias diversas según la ocasión. Como es tradición de este blog, tengo en mi backlog sentarme a programar en diferentes lenguajes, tecnologías, y en algunos casos tal vez no sea código sino diagramas en un pizarrón, o alguna charla más tradicional, pero siempre que pueda, será a código limpio.

---

Para iniciar la serie entonces, recurrí a varios amigos, y la primer víctima fue Carlos Peix. Nos conocemos desde hace más años de los que puedo recordar, a través de la comunidad Microsoft. Carlos es un desarrollador independiente con muchos años de experiencia y una actitud abierta a nuevas ideas, pero que no se deslumbra fácilmente con las nuevas modas y prefiere centrar su atención en las técnicas de diseño e implementación más perdurables. Es reconocido sobre todo como especialista en desarrollo web y el mundo .NET, pero siempre está mirando y practicando un poco de Java, Ruby o Smalltalk.
Carlos también participa activamente en la comunidad Agiles.org localmente y en la organización de Agiles 2011. Tiene un blog con varios videos muy interesantes que graba por iniciativa propia y al participar en otras comunidades, como Alt.Net Hispano, donde es presentador habitual.
En el video que grabamos (unos 20 minutos en total), Carlos trajo un ejemplo extraído de un caso real que le tocó, sencillo pero ya algo avanzado y con unas pruebas unitarias, y entre ambos hicimos una sesión de refactorización. El ejemplo es en C#, y usamos Visual Studio 2010 con ReSharper. Para quienes quieran ver el código con más detenimiento, dejo la solución al inicio del ejercicio, y la solución al final.

Yoseki Coding Dojo en Kleer

Siguiendo con la buena costumbre de los Coding Dojo, mis amigos de Kleer vienen organizando algunas de estas sesiones abiertas para escribir código entre muchos, como un ejercicio de trabajo en grupo, programación y entretenimiento. Ellos ya tienen un formato bastante definido para estas sesiones, llamadas Yoseki Coding Dojo en las que se van variando el lenguaje y el entorno.

El martes de esta semana me sumé a esta actividad, me encontré con otro amigo asistiendo, Carlos Peix, y me di el gusto de compartir con él la primera ronda de pair programming.

Esta vez trabajamos con Java/Eclipse. Parece que el próximo Yoseki será en Ruby, y si me dejan haremos uno en Javascript.

El problema que planteó el facilitador de turno, Pablito "Pablitux" Tortorella: escribir un contador de puntos de tenis. A continuación dejo las premisas generales para quien quiera practicar este Code Kata. Recuerden que la idea es realizar el ejercicio utilizando TDD, y puede hacerse como una Kata individual, o en un Dojo con varias personas.

La idea es hacer un contador de puntos de tenis. No soy experto en tenis y no me quedaron a mano los detalles que Pablo iba mostrando como historias de usuarios, pero creo que todos sabemos un poco cómo se cuenta: "15 - 0", "30 - 0", "40 - 0"; después los sets; detalles de convención como "30 iguales", etc.

Les dejo debajo los primeros tests (a propósito no dejo todos por si alguno quiere intentar por su lado). Quienes quieran pueden ver los fuentes completos de los tests y de la implementación.

Primeros tests:

package la.kleer.yoseki.tenis.tests;

import junit.framework.Assert;
import la.kleer.yoseki.tenis.Tablero;

import org.junit.Test;

public class TenisFixture {
   
   @Test
   public void tableroTituloConDosJugadores()
   {
      Tablero t = new Tablero("Martin", "Carlos");
      Assert.assertEquals("Martin vs Carlos", t.getTitulo());
   }

   @Test
   public void tableroTituloConDosJugadoresAlReves()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      Assert.assertEquals("Carlos vs Martin", t.getTitulo());
   }
   
   @Test
   public void tableroPuntajeInicial()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      Assert.assertEquals("0 - 0", t.getPuntaje());
   }
   
   @Test
   public void puntosJ1()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador1();
      Assert.assertEquals("15 - 0", t.getPuntaje());
   }
   
   @Test
   public void puntosJ2()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador2();
      Assert.assertEquals("0 - 15", t.getPuntaje());
   }

   @Test
   public void puntosJ1_J1()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador1();
      t.puntoJugador1();
      Assert.assertEquals("30 - 0", t.getPuntaje());
   }

   @Test
   public void puntosJ1_J2()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador1();
      t.puntoJugador2();
      Assert.assertEquals("15 iguales", t.getPuntaje());
   }

   // Aquí van más tests

}

Finalmente, les dejo una foto del grupo en acción:

 

[Video y Ejercicio] Agiles @ Buenos Aires: Coding Dojo

La semana pasada se realizó la reunión mensual de Agiles @ Buenos Aires, como anuncié en un post anterior.

No voy a repetir todo el detalle, sino a dejar el video de la introducción de Adrián Eidelman, y el arranque del ejercicio con el primer par frente a la computadora.

El resto se los ahorro porque son dos horas en las que no se llega a leer claramente el código y la conversación entre los pares no llega a distinguirse claramente. Es un tipo de actividad que requiere presencia directa para disfrutarla, y recomiendo que estén atentos si les interesa porque ya hay en marcha una iniciativa de Katayunos (desayunos entre tres o cuatro personas para practicar Code Katas), y cualquiera puede organizar algo así con sus compañeros de trabajo o de estudio.

Pero para que no se pierdan el total (aunque la gracia es el camino recorrido más que el punto final), dejo el ejercicio tal cuál como quedó resuelto durante la reunión (sin edición ni retoque), cortesía de Adrián. La plataforma y lenguajes son anecdóticos, pero en este caso se realizó en C# utilizando Visual Studio 2010 y NUnit como framework de testing.

Van primero los tests (un primer ejercicio puede ser tomar los tests y tratar de escribir el código sobre ellos):

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Moq;
using NUnit.Framework;
using NumerosRomanos;

namespace NumerosRomanos.Tests
{
    [TestFixture]
    public class Tests
    {
        Conversor conversor;

        Dictionary<int, string> valores;

        [TestFixtureSetUp]
        public void setUp()
        {
            conversor = new Conversor();
            valores = new Dictionary<int, string>();
            valores.Add(1, "I");
            valores.Add(5, "V");
            valores.Add(10, "X");
            valores.Add(50, "L");
            valores.Add(100, "C");
            valores.Add(500, "D");
            valores.Add(1000, "M");
        }

        [Test]
        [ExpectedException(typeof(ArgumentException))]
        public void El0ArrojaExcepcion()
        {
            int numeroArabigo = 0;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);
        }

        [Test]
        [ExpectedException(typeof(ArgumentException))]
        public void NumeroNegativoArrojaExcepcion()
        {
            int numeroArabigo = -1;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);
        }

        [Test]
        [ExpectedException(typeof(ArgumentException))]
        public void El4000ArrojaExcepcion()
        {
            int numeroArabigo = 4000;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);
        }

        [Test]
        public void El1DeberiaDevolverI()
        {
            int numeroArabigo = 1;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("I", numeroRomano);
        }

        [Test]
        public void El5DeberiaDevolverV()
        {
            int numeroArabigo = 5;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("V", numeroRomano);
        }

        [Test]
        public void El10DeberiaDevolverX()
        {
            int numeroArabigo =10;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("X", numeroRomano);
        }

        [Test]
        public void El2DeberiaDevolverII()
        {
            int numeroArabigo = 2;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("II", numeroRomano);
        }

        [Test]
        public void El3DeberiaDevolverIII()
        {
            int numeroArabigo = 3;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("III", numeroRomano);
        }

        [Test]
        public void El15DeberiaDevolverXV()
        {
            int numeroArabigo = 15;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("XV", numeroRomano);
        }

        [Test]
        public void El4DeberiaDevolverIV()
        {
            int numeroArabigo = 4;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("IV", numeroRomano);
        }
        [Test]
        public void El48DeberiaDevolverXLVIII()
        {
            int numeroArabigo = 48;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("XLVIII", numeroRomano);
        }

        [Test]
        public void RetornaValoreConocidos()
        {
        
            foreach(var i in valores.Keys)
                Assert.AreEqual(valores[i], conversor.ANumerosRomanos(i));

        }
    }
}

Y aquí está finalmente la implementación misma (para quienes quieran hacer trampa):

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace NumerosRomanos
{
    public class Conversor
    {
        List<int> valoresArabigos = new List<int> 
            {1,4,5,9,10,40,50,90,100,400,500,900,1000};
        List<string> valoresRomanos = new List<string> 
            {"I","IV","V","IX","X","XL","L","XC","C","CD","D","CM","M"};
    
        public Conversor()
        {
            valoresArabigos.Reverse();
            valoresRomanos.Reverse();
        }

        public string ANumerosRomanos(int numeroArabigo)
        {
            if (numeroArabigo<=0 || numeroArabigo>3999)
                throw new ArgumentException();


            string resultado="";

            while (numeroArabigo > 0)
            {
                foreach (var i in valoresArabigos)
                {
                    if (i <= numeroArabigo)
                    {
                        resultado += valoresRomanos[valoresArabigos.IndexOf(i)];
                        numeroArabigo -= i;
                    }
                }
            }

            return resultado;
       }
    }
}

Video: Kata con Números Romanos (Ruby, 15 minutos)

Como comenté el viernes, ayer tuvimos la reunión mensual del grupo Agiles.org en Buenos Aires, dedicada a un Coding Dojo en el que practicamos un ejercicio entre la docena de asistentes, rotando de a pares y avanzando con TDD para resolverlo.

El ejercicio en si consiste en pasar de números arábigos (los que usamos todos los días) a números romanos. Esta antigua forma de numeración tiene la particularidad de ser un poco irregular con sus dígitos que restan antes de llegar a los múltiplos de 5 y 10, como en el caso del 4 (IV) y el 9 (IX).

Lo bueno de este ejercicio en particular es que es bastante corto y las reglas son conocidas por casi todo el mundo. En el Dojo de ayer (del que pronto espero publicar un video con al menos la introducción y algunos momentos) llevó bastante tiempo porque ibamos rotando entre gente con diferente grado de conocimiento de la plataforma y lenguaje elegido (Visual Studio y C#), el teclado era raro para todos (menos para el dueño), y para muchos era la primera vez con ejercicios de este estilo y/o TDD.

Mientras rotábamos practiqué el ejercicio varias veces por mi lado y sobre el final hice una versión bastante parecida a lo que obtuvimos entre todos.

Dejo el video para quien le pueda interesar, con las siguientes aclaraciones:

• La respuesta no es la única correcta. De las que obtuve, es una de las más concisas.
• Lo que grabé es lo que se considera un Kata: hice el ejercicio muchas veces y al final fluyó bastante. Dura 15 minutos incluyendo tiempo de escribir algunos comentarios que representan lo que iba pensando. Probé relatarlo pero el tiempo era más largo porque no puedo escribir el códido tan derecho.
• Como siempre, la elección del entorno es arbitraria. Esta vez lo hice en Ruby usando unit/test que es lo más básico. Hice un uno con Ruby/RSpec pero me parece que va a llamar más la atención el framework de BDD que el ejercicio. Si hay interés puedo publicar otras variantes.
• En un Randori Dojo, aunque el ejercicio es el mismo, la dinámica es totalmente diferente. Lleva mucho más tiempo pero el foco está más en la práctica de las interacciones y el juego de pares que en la técnica misma. Recomiendo mucho hacer las dos cosas. Los katas son ejercicios más individuales, los dojos como ensayos con una banda.
• Espero que les guste la música. Si no, pueden dejar el video mudo. Todo lo demás está en el código.

Agiles @ Buenos Aires: Coding Dojo

El grupo Agiles.org organiza actividades de varios tipos en muchos puntos de América Latina.

Esta comunidad surgió fuertemente tras la primera edición de la conferencia latinoamericana Agiles 2008, y a partir de ahí el grupo en Argentina quedó consolidado, realizando muchas actividades por todo el país (anunciadas en la página Agiles Argentina).

Específicamente en Buenos Aires, se efectúan reuniones todos los meses, que se anuncian en la página Agiles@BsAs.

La próxima reunión es el martes que viene, 8 de febrero, en las oficinas de Southworks (Perú 375, 1er piso).  [disclaimer: es donde yo trabajo]

Lo interesante de esta próxima reunión en particular es que va a ser un Coding Dojo (estilo Randori), facilitado por Adrián Eidelman.

En palabras del propio Adrián:

"Un coding dojo es una sesión de codificación centrada alrededor de un desafío de programación. El desafío es sumamente pequeño en alcance y -en la versión Randori de un coding dojo- la totalidad de la audiencia participa para completarlo. Básicamente la solución se construye utilizando una única computadora y un proyector, en donde los desarrolladores van rotando de a pares cada una cantidad fija y acotada de tiempo, dejando lugar a que otras personas de la audiencia continúen. El objetivo es aprender, enseñar y mejorar nuestras habilidades de programación compartiendo con otros desarrolladores de software en un ambiente relajado."

La actividad como siempre es totalmente abierta y gratuita pero requiere inscripción previa, y vale la pena decidirse rápido porque el espacio no es infinito.

Espero ver a muchos de ustedes la semana que viene, codeando, y espero poder capturar en video todo lo que se pueda de la actividad, para compartir con quienes no puedan asistir.

 

Meditación programática: Koans

Los Köan (pronunciación japonesa del chino 公案) o Koan, son ejercicios mentales de la meditación Zen, consistentes en diálogos o preguntas que plantean un problema que muchas veces no tiene respuesta directa. El objetivo de un Koan es el aprendizaje durante el proceso de elaboración de la respuesta, más que la respuesta en sí.

Un ejemplo clásico es la pregunta: "Cuando dos manos aplauden hay un sonido. ¿Cuál es el sonido de una sola mano?".

Tomando esta idea como base, de manera similar a la idea de los Code Katas que comentaba en un post reciente, diferentes personas empezaron a generar Code Koans para diferentes lenguajes. Como siempre, la adaptación es libre y no sigue exactamente los mismos principios, sino que e inspira en la idea motora.

Los Koans dentro del campo de la programación parten del objetivo de comenzar con conceptos sumamente básicos y realizar ejercicios generalmente abiertos, pero que frecuentemente llevan a la necesidad de experimentar o investigar un poco más allá del alcance mismo del planteo.

Hay colecciones de Koans para varios lenguajes, entre ellos Ruby Koans (Jim Weirich y Joe O'Brien), JavaScript Koans (Liam McLennan), .NET Koans (Cory Foy) y los Clojure Koans (Aaron Bedra).

La mayoría de estos proyectos están inspirados en el primero, los Ruby Koans, de los que incluyo algunos ejemplos para que se entienda el concepto general.

Los Koan suelen estar agrupados por temas, por ejemplo en los de Ruby, hay series para arrays, blocks, clases, excepciones, módulos, strings, y muchas más.

Los Koans se basan siempre en la práctica de Test-Driven Development (curso gratuito en español disponible), donde las "preguntas" están formuladas como tests, que el aprendiz debe implementar y pasar. La diferencia con TDD tradicional es que el test principal ya está escrito (lo que no significa que no podamos agregar más).

Lo primero a ejecutar en los Ruby Koans es (desde la línea de comandos):

$ ruby path_to_enlightenment.rb

y el resultado es algo como:

AboutAsserts#test_assert_truth has damaged your karma.

The Master says:
  You have not yet reached enlightenment.
  Do not lose hope.

The answers you seek...
  Failed assertion, no message given.

Please meditate on the following code:
  /Users/ . . . /koans/about_asserts.rb:10:in `test_assert_truth'

mountains are merely mountains
your path thus far [X_________________________________________________] 0/274

El mensaje juega con el estereotipo del Maestro Zen y el estilo de los consejos, pero más allá de eso, nos da un indicio: nos dice que meditemos en el método test_assert_truth dentro del archivo about_asserts.rb. Si abrimos este archivo y lo miramos, encontramos este test donde el motivo de la falla es más que obvio:

  # We shall contemplate truth by testing reality, via asserts.
  def test_assert_truth
    assert false                # This should be true
  end

Al cambiar a assert true y ejecutar de nuevo, obtenemos un mensaje similar sobre el siguiente test que falla, y otra frase Zen diferente para inspirarnos. Por supuesto, a medida que avanzamos la respuesta es menos evidente que cambiar un false a true. El primer ejercicio solamente sirve para que entendamos el procedimiento.

En varios casos, la manera de resolver el test no es evidente y tenemos que buscar más información en libros o en la web, pero esto es lo que buscan los Koans: forzarnos a aprender algo, pero siguiendo baby steps.

Curso Certified ScrumDeveloper (CSD) Track - Verano 2011

Hoy dedico el post a un pequeño aviso, porque se que hay mucha gente interesada en capacitación sobre Scrum, y en particular estos cursos tienen que ver con un área que me parece muy importante y no siempre bien cubierta, que es la parte técnica o de ingeniería que se requiere para poder mantener la calidad iteración tras iteración.

Esta serie de cursos que organiza Kleer (la única empresa en Argentina certificada por la Scrum Alliance para dar estos cursos), tiene el siguiente temario:

* Los conceptos básicos, valores y principios de la agilidad y Scrum 
* Técnicas de análisis de procesos e identificación de historias de usuario 
* Técnicas de estimación y planificación con Scrum 
* La creación de historias de usuario que den lugar a desarrollos evolutivos 
* La identificación y automatización de sus pruebas de aceptación 
* La comunicación con el equipo mediante integración continua 
* Técnicas de diseño y desarrollo dirigido por pruebas (TDD) 
* La utilización de taskboards y métricas ágiles 

El track está orientado a: 



* Gerentes de Proyecto con formación en gestión 
* Gerentes de Proyecto con background técnico 
* Gerentes de Desarrollo 
* Líderes Técnico 
* Arquitectos de Sistemas 
* Desarrollador de Software

 

El programa completo incluye tres cursos independientes:

Curso de Introducción a Scrum

Duración: 8hs.

Fecha de Dictado: 21 de Febrero de 9 a 18hs

Lugar: Microcentro, Buenos Aires

Curso de Estimación y Planificación con Scrum

Duración: 8hs.

Fecha de Dictado: 22 de Febrero de 9 a 18hs

Lugar: Microcentro, Buenos Aires

Curso de Desarrollo Ágil de Software en Scrum

Duración: 24hs.

Fecha de Dictado: Del 23 al 25 de Febrero de 9 a 18hs

Lugar: Microcentro, Buenos Aires

Para consultas: entrenamos@kleer.la

También se puede ver  el calendario completo de Kleer o ver las fotos de los cursos anteriores en su página de Facebook.

 

Videos de TDD en acción

Recién descubro esta excelente serie de videos de James Shore, autor del libro "The Art of Agile".

En la serie, James captura 10 o 15 minutos de sesiones de una aplicación que construye utilizando TDD en Java, sobre Eclipse. Los videos están narrados en inglés, pero más allá de la explicación, puede verse cómo va escribiendo el código y son muy ilustrativos, incluso cuando podemos no compartir algunos de los criterios que toma en determinado momento.

Comparto aquí el primer video de la serie, pero no dejen de ver la lista completa, que ya lleva 55 episodios, y últimamente involucra además a algunos invitados con lo que se puede ver no solo el ejercicio de TDD sino también el de programar de a pares.

Comparación de TDD entre entornos estáticos y dinámicos

Hernán Wilkinson, uno de los integrantes de 10pines, publicó recientemente en su blog estos interesantes videos (que republicamos) comparando la práctica de TDD en Java y Smalltalk.

Más allá de algunas objeciones que se han hecho a la comparación, como estilos en uno u otro lenguaje, el ejercicio es interesante. En líneas generales se puede coincidir en que los lenguajes dinámicos tienen algunas ventajas a nivel de ejecución para este tipo de prácticas.

De paso, también es un ejemplo interesante para ver un brevísimo ejercicio de TDD y de Smalltalk para quienes no están familiarizados con ellos.

Gracias a Hernán por contribuir a la comunidad con este contenido.