Archive for mayo, 2010

  • I Code Kata de Agile-CyL

    2
    Día: 29/05/2010
    Hora: 10:00 - 13:30
    Lugar: Sala 24, Centro Cívico Zona Sur, Plaza Juan de Austria - Valladolid
    Objetivo: pasar un buen rato mejorando nuestras técnicas de desarrollo de software, buscando resolver un problema a partir de TDD y Pair Programming.
    NO es necesario encontrar la solución, sino discutir los caminos que nos encontremos buscando mejores soluciones.
    El lenguaje de programación no es importante.
    Requisitos: Quien tenga portátil preparado para desarrollar y con xUnit será bienvenido ( no es una sala de informática, necesitamos equipos)
    Ganas de pasarlo muy bien.
    Procedimiento:
    1. Organizarnos por parejas
    2. Trabajar en base a Pomodoros de 25 minutos, con 5 de descanso y retrospectiva
    3. Cambio de pareja para siguiente pomodoro
    Asistentes:
    1. Jorge Jiménez Pérez
    2. Amalia Hernández García
    3. José Luis Balmaseda Franco
    4. Alvaro Garcia Loaisa
    5. Javier Acero Guerra
    6. Francisco Pascual
    7. Eduardo Ferrández

    KATA: STRING CALCULATOR

    El problema a resolver es el siguiente: se parte de una cadena formada por número que están separados por comas o por nuevas
    líneas (\n). Se trata de ir haciendo la suma de los números recibidos y devolver el valor total.
    Dos cosas a tener en cuenta:

    • Si la primera línea de la cadena es de la forma “//”, entonces es posible encontrar el delimitador *. Esto es válido para cualquier cadena.
    • No se admiten números negativos.

    Esta información está en la página:

    http://blog.extracheese.org/2010/01/string-calculator-kata-in-python.html

    Pero es que además la página de Osherove nos da toda una serie de pasos para ir desarrollando
    la Kata (http://osherove.com/tdd-kata-1)

    1. Crear una calculadora sencilla con un método int Add (números de serie)
      1. El método puede tener 0, 1 ó 2 números, y devolverá su suma (para una cadena vacía devolverá 0) por ejemplo ” ” ó “1″ ó ” 1,2 “
      2. Comience con el caso más simple de prueba de una cadena vacía y luego  pasar a 1 y 2 números
      3. Debes resolver las cosas de la manera mas sencilla posible, para forzarte a escribir los test que no habías pensado
      4. Hay que refactorizar después de pasar los test.
    2. Permitir que el metodo Add trabaje con una cantidad desconocida de números
    3. Permitir que  el método Add trate con el carácter nueva línea, situado entre los números (en lugar de comas).
      1. la siguiente entrada está bien: “1 \ n2, 3″ (será igual a 6)
      2. la siguiente entrada NO se acepta: “1, \ n”
      3. Asegurar la prueba para las entradas correctas. No hay necesidad de probar para las entradas incorrectas.
    4. Permitir el método Add trabaje un delimitador diferente:
      1. Para cambiar un delimitador, el comienzo de la cadena contendrá una línea independiente que tiene este aspecto: ”/ / [delimitador] \ n [números ...]” por ejemplo “/ /; \ n1; 2″ debe devolver tres cuando el delimitadorpor defecto es ‘;’.
      2. La primera línea es opcional. Todos los escenarios deben estar soportados.
    5. Las llamadas al método Add con un número negativo deben lanzar una  excepción “Números negativos no admitidos” - y mostrar  el numero negativo. Si existen múltiples negativos, se muestran todas en el mensaje de excepción.

      Hasta aquí, si eres un novato. Continúa si puede terminar los siguientes pasos  en menos de 30 minutos.


    6. Los números superiores a 1000 deben ser ignorados. La suma 2 + 1001 = 2
    7. Los delimitadores pueden ser de cualquier longitud con el siguiente formato: “/ / [delimitador] \ n”, por ejemplo: “//*** \ n1 *** 2 *** 3 “debe devolver 6
    8. Se pueden permitir  delimitadores múltiples de esta manera: “/ / [delim1] [delim2] \ n”, por ejemplo “//[*][%] \ n1 * 2% 3 “debe devolver 6.
    9. Se pueden tratar delimitadores múltiples con una longitud superior a un char.

    RESUMEN

    El sábado 29 de Mayo de 2010, 7 valientes acudimos a realizar la I Kata del grupo Agile-CyL practicando TDD y Pair Programming ( en algún caso se practicaron trios, pero esa es otra historia), donde pudimos ejercitar nuestras habilidades (skills).
    En las refactorizaciones y en los descansos de los Pomodoros se discutió sobre el diseño que emergía a través del TDD y Edu nos abrió los ojos hacia el destino de la Kata: refactorizar y hacer test sobre los diferentes SUT( Subject Under Test) que aparecían ante nuestros ojos: la calculadora y el separador de números  (Calculator y Splitter, respectivamente).
    Y de prueba unas fotos que atestiguan lo bien que lo pasamos. De las cañas no hya pruebas gráficas pero las gambas estaban muy buenas: foto 1 y foto 2

  • REUNION 25/05/2010

    0

    LUGAR DE ENCUENTRO

    Ciudad: Valladolid

    Hora: Desde 19:30 a 21:00
    Punto de encuentro: Cafetería Púrpura (en la parte de arriba)

    Ver mapa

    • C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

    OBJETIVOS

    • Conocer Extreme Programming.
    • Técnicas de trabajo en XP.
    • Actualizar la lista de temas a tratar.

    REFERENCIAS

    Extreme Programming: A Gentle Introduction.

    Extreme Programming explained de Kent Beck

    Extreme Programming en la Wikipedia

    Texto en español sobre XP

    AGENDA

    1. Presentaciones individuales
    2. Presentación de XP (promovido por Edu Ferrández)
    3. Retrospectiva de la reunión.
    4. Actualización de Backlog de temas para los encuentros
    ASISTENTES
    1. Jorge Jiménez Pérez
    2. Isidro Merayo Castellano
    3. José Luis Balmaseda Franco
    4. Amalia Hernández García
    5. Javier Acero Guerra
    6. Eduardo Ferrández
    7. Pencho Herrero
    8. Alberto Sáenz
    9. Alvaro García Loaisa
    10. Julio César Arenas
    11. Olivier Salmon

    RESUMEN

    Edu nos dio las primeras pistas sobre lo que es XP, eXtreme Programming.

    Valores de XP:

    ·         Comunicación

    ·         Simplicidad

    ·         FeedBack

    ·         Coraje (Hard Work)

    Practicas para llevar a cabo  XP:

    ·         Planificación:  user-stories que desembocan en tareas

    ·         Versiones pequeñas

    ·         Sistema metafórico:  nombrando código

    ·         Diseño simple

    ·         Testeo continuo

    ·         Refactoring

    ·         Pair Programming: dos personas sobre el mismo ordenador, creando código para otros. Es una técnica apropiada para equipos maduros, donde la persona que no teclea conserva una visión global del problema y puede aleccionar al otro. Recodar que Peer Programming no es lo mismo. Álvaro comento que él suele juntar a parejas de distintos ámbitos como Informática y Telecomunicaciones. Y estas parejas le dan buen resultado cuando el informático escribe el código y el teleco es el que tiene la capacidad para afrontar la visión del problema.  Olivier comentó el tema productividad a corto plazo frente a productividad a largo plazo. Pair Programming permite aumentar la concentración.

    ¿Cuándo realizar el cambio de parejas? Depende de la tarea que se esté realizando.

    Pair Programming es una buena técnica para enseñar aprendizaje a alguien nuevo, acerca de la forma de trabajo

    Pair Programming es ideal aplicarlo sobre nuevos procesos, sobre tareas complejas.

    ·         TDD:  Desarrollo Dirigido por Pruebas. Diseñas el código por prueba, partiendo de algo sencillo y con el mínimo código, recordad que los programadores tendemos a escribir mas código del necesario. Ventajas: una mayor fiabilidad. TDD no es aplicable en todos los proyectos.

    ·         Propiedad Colectiva del código

    ·         Integración Continua

    ·         Semanas de 40 horas de trabajo

    ·         Cliente/Usuario cercano

    ·         Estándares de Codificación