Mostrando entradas con la etiqueta tdd. Mostrar todas las entradas
Mostrando entradas con la etiqueta tdd. Mostrar todas las entradas

miércoles, 18 de enero de 2017

Desarrollo ágil de Software - stack Python

Soy uno de los facilitadores del curso Desarrollo Ágil de Software (DAS) de Kleer.
Lo solemos hacer con Ruby (alguna vez lo hemos dado en Java y C#).

Afortunadamente, hace poco lo hicimos en Telefonica I+D Chile y nos pidieron hacerlo con Python ¡Gracias!

Le comento mi experiencia y les dejo la referencia del ambiente https://github.com/jgabardini/csdpy, lo pueden reproducir en Linux (o la virtual de DAS con Mint)

Resumen de Stacks

En el ambiente Ruby, las herramientas son: bundle, rspec, cucumber, webrat/capybara, sinatra con erb.

En el ambiente Python: virtualenv y pip, behave, splinter, flask con jinja2. Además, usé un plugin de Jenkins: ShinningPanda.

Python

No hubo problemas porque la mayoría ya programaba en Python (había dos o tres personas sin conocimiento, pero que se sumaron rápido).
Algunos prefirieron usar sus ambientes, por los editores (sin usar la virtual). La virtual tiene Gedit, ellos usaban Visual Studio Code, vim, ....
Usé Python 3.4 (en vez de 2.7 que es el default en la virtual de DAS).
Para manejar versiones y ambientes use virtualenv y pip.

Unittests

Usé nosetests como test runner. Extrañé la sintaxis BDD (de rspec), pero ellos no 😉
Para el próximo (que por suerte es la semana que viene), daré instrucciones concretas sobre la estructura de directorios. Los desarrolladores Python NO tienen el mantra Convention over configuration, cada uno lo hace distinto si los dejas libres 🙌. Y explicaré las reglas de descubrimiento de pruebas de nosetests, eso hubiera ayudado (tests/xxx_test.py).

Flask

El código mínimo es un poco más largo que el de Sinatra y, como yo no tengo tanta práctica, no lo escribí de cero. Usé el código del repo csdpy desde el inicio.
Cuando falla el routing u otro error, no es tan amistoso como Sinatra, no muestra una página 500 con información de que falta.
Usar annotation para definir el routing, obliga a tener funciones por cada mapeo, y es natural que la misma función cubra varios métodos HTTP. Cometí muchos errores de nombre método duplicado, acostumbrado a los bloques de Ruby.
Los asistentes no tuvieron mucho problemas (o los resolvieron).
Nuevamente, Flask es menos prescriptivo que Sinatra. Yo propuse una estructura de directorios. 
El motor de templates, Jinja2, lo usé simplificado. Sin layout, bloques ni herencia. Es el motor usado en  Django.

Behave

Sigue bastante la idea de Cucumber, excepto que los pasos son distintos para cada palabra clave (Given/When/Then). En Cucumber, un paso está definido solo por el texto. En Behave los pasos se definen por la combinación palabra clave + texto. Tuve el mismo problemas con nombres de métodos repetidos que en routing de Flask.
No propone pasos con regex  "automáticas". Uno debe agregar los parámetros a mano.

Splinter

Usé Splinter que equivale a webrat/capybara. Pinta muy bien. Tiene una API muy parecida a WebDriver y puede usar los driver de WebDriver, o flask (me parece que inprocess, pero no lo encontré la documentación).


Configuración de Jenkins

Para correr tareas que requieren virtualenv, use un plugin ShinningPanda. Todas las tareas configuradas como shell.
Para que corra el behave tuve que agregar un package: behave-jenkins.

Conclusiones

Hacer la migración de Ruby a Python me llevó un día neto de trabajo. Bien sencillo.
Luego de 3 años de programar principalmente con Ruby, me sentí raro en Python. Me falta práctica. Por suerte, la semana que viene volvieron a pedirme, esta vez en Córdoba, que hagamos el curso en Python 😎


viernes, 30 de octubre de 2015

Intro a TDD en formato autoaprendizaje

Les comparto un material que he usado un par de veces para difudir TDD en forma de autoaprendizaje o con relativamente poco soporte por parte del facilitador.

Motivación

Hace un tiempo facilitamos con Pablo Tortorella un Hackathon en el Instituto ORT de Almagro. Durante el diseño del evento (con gente de ORT como Damian Rosenfeld, Alejandro Jait y otros), surgió el interés que los asistentes, en su mayoría alumnos del Instituto, pudieran aprender algo nuevo, si no les entusiasmaba ninguno de los proyectos, o como una forma de alternar el foco.
Para eso requeríamos un material de aprendizaje autónomo.

Material

El material que contruimos es un poster en tamaño A3 que incluye una descripción de un ejercicio a realizar, un gráfico de el ciclo de TDD, y algunas consideraciones del por qué del TDD.
También referenciamos a videos cortos (de 5 min) en los que Martín Salias explica como hacer un 'hola mundo' de TDD en Java, .Net, y Python.




Feedback!

Si lo usas y encotras algo para mejorar, por favor me comentas.


domingo, 11 de noviembre de 2012

Herramientas de Desarrollo en PHP

En los últimos tiempos estoy trabajando con varios clientes que utilizan PHP para sus desarrollos.
Hemos hablado entre varios de los involucrados, tanto de Kleer (Martín Salias, Nicolás Paez, Ignacio 'Code' Raguet) como de los clientes y nos parece que, por razones históricas, la comunidad de PHP  tiene poco incorporadas prácticas que ya están muy difundidas en las comunidades de otros lenguajes. Prácticas como análisis estático de código, criterios de calidad de código, prueba automatizada, frameworks web sencillos y potentes, y varios más. Está característica de la comunidad se reflejaba en la falta o inmadurez de las herramientas que soportan esas prácticas. Parece que esto está cambiando. 
Mi anterior post sobre PHP es viejo y  mucho a cambiado desde entonces.

Van entonces algunas herramientas y comentarios, principalmente tomado de Martín Salias, Nicolás Paez, Ignacio 'Code' Raguet y Pablo Morales. Verán que algunas cosas se repiten desde 2008, otras son nuevas.

Análisis de código 

¡Gracias Martín por la data!
  • Source Code Search Engine te permite hacer queries sobre bases de código muy grandes, con más inteligencia que un grep común, entendiendo el lenguaje (soporta PHP entre muchos otros). Esto puede servir para encontrar usos de ciertos elementos, y es más un complemento que otra cosa.
    http://www.semanticdesigns.com/Products/SearchEngine/

Pruebas automatizadas 

Frameworks


viernes, 12 de octubre de 2012

Scrum en Asunción - Paraguay

Hace uno mes (31 de Agosto) hice mi primera visita laboral a Paraguay. 
El Centro de Calidad de Software organizó un curso de "Gestión ágil de proyectos de software", de 16hs, que dimos en dos días (viernes y sábado).
Aprovechando la visita también organizamos, junto con AgilePy lo que creo fue el primer Coding Dojo de Paraguay.

Paso a contar cada actividad, no sin antes agradecer al Centro de Calidad, y en particular a Marcelo De Filippis, por la organización, el empuje y soporte en todo momento y a Cristhian Cardozo que además de dar soporte durante el curso, sacó fotos y se quedó al Dojo para recibir a los asistentes.

Gestión ágil de proyectos de software

En lo que entiendo fue el primer curso abierto de Scrum en Paraguay, asistieron 18 personas, haciendo un gran esfuerzo, ya que lo hicimos un viernes a partir del mediodía, y el sábado. Hacer 16hs de curso en esas condiciones fue cansador, pero terminamos contentos.

Sigo con mi intensión de dar los cursos con soportes visuales en afiches, y ejercitando mi capacidad de transmitir ideas visualmente. Esto fue muy valorado por los asistentes, y genera un efecto ¡WOW!, ya que es muy distinto a lo que están acostumbrados. 


También el uso de técnicas de Training from the Back of the room (ver resumen) hacen el aprendizaje es más divertido y profundo. 




 La asistencia fue variada, lo que enriqueció las discuciones. Había profesores universitarios, personas que trabajan en empresas grandes y chicas, emprendedores, programadores y personas de testing y calidad.
¡Muchas gracias a todos, y espero que volvamos a vernos!

Yoseki Coding Dojo


Este dojo fue claramente inmoral, y hasta diría inhumano. Lo organizamos el sábado, de 19 a 21hs. ¡Había que tener muchas ganas para estar! Doble puntaje para los asistentes :D
Hicimos el kata del Juego de la Vida, con Python. Los asistentes eran programadores de Action Script y PHP, no tenían conocimiento previo de Python, pero no fue un problema. Comentamos TDD, Integración Continua, algunos de los principios de SOLID y mocking.



Pasamos un buen rato, para la próxima, ¡vale traer cerveza!





lunes, 26 de septiembre de 2011

Pruebas con fechas


En los últimos días me encontré dos veces conversando sobre pruebas que incluyen fechas: en el curso sobre Fitnesse, con pruebas funcionales, y con mis compañeros en UTI SIS con TDD.
Ambas conversaciones me hicieron repensar este tema, y aprovecho para volcar mi visión actual.

¿Por qué es especial la prueba que involucra a fechas?

Hay otras razones, pero en este post me centraré en la dependencia con la fecha del sistema. Esta dependencia puede darse en dos situaciones:
  • crear la entidad o realizar una acción sobre la misma (emitir un documento legal, como un cheque o una factura), que asigna la fecha del sistema a algún campo de una entidad u objeto de la aplicación.
  • consultar a la entidad u objeto, siendo el resultado de la consulta dependiente de la fecha (posiblemente la fecha actual).
Ejemplos:
  • Un cheque se emite al día de hoy (fecha de emisión), y vence en 30 días.
  • Quiero consultar si puedo depositar el cheque (no debe estar vencido).
Si hacemos pruebas que tengan dependencias sobre un elemento que no podemos controlar (en este caso el paso del tiempo), nuestras pruebas van a ser poco robustas (como pruebas unitarias).
Si quiero probar el sistema completo, me puede interesar explicitar el uso de las fechas de diferentes servidores. Estaría haciendo prueba de integración en vez de prueba unitaria.

¿Que alternativas tengo?

  1. Usar los datos de la prueba de manera que el estado o condición a probar sea válida al día de hoy.
    • En el caso del cheque, es fácil probar si el cheque puede depositarse (no está vencido), ya que si creamos un cheque hoy, seguro está dentro del período.
    • Probar el caso de cheque vencido es más complejo: quizás puedo modificar la fecha en la base de datos.
    • Se puede tener una generación automática de datos de prueba de manera que se cumplan las condiciones deseadas.
  1. Disponer de una manera de modificar la fecha que toma el sistema como fecha actual.
    • Se puede tener los datos con fechas fijas y lo que se cambia es la fecha simulada del sistema. Se requiere cambiar al sistema, para probarlo.
  1. Ampliar la funcionalidad de manera de recibir la fecha de referencia (en vez de tomarla del sistema)
    • Es conflictivo si el cliente no siente esto como necesario, parece ser complejidad adicional, sólo algo para facilitar las pruebas.
    • Generalmente sirve para el caso de las consultas, no de la generación.
  1. Realizar pruebas relativas.
    • No usar valores absolutos de fechas u horas. Esto tiene el inconveniente que (similar al caso 1), que no se puede acelerar el paso del tiempo: por ejemplo, si mi datos tiene precisión de días, y quiero probar el próximo día.

Ejemplos

Alternativa 1

TDD

El siguiente ejemplo, en PHP, muestra como se preparan los datos para las pruebas relacionadas con cursos, en la que hay 4 fechas (inicio y fin de la inscripción, inicio y fin del curso). Los primeros 4 números 'datos' son días relativos al día de hoy.
La función __creaCurso traduce entre valores relativos de las fechas y los valores absolutos con que se quiere probar.

function testCursosActuales() {
$pruebas = array(
array('datos' => array( 1, 1, 3, 3,false,false), 'actual' => False),
array('datos' => array( 1, 1, 3, 3,true,false), 'actual' => True),
array('datos' => array( 0, 0, 2, 2,true,false), 'actual' => True),
array('datos' => array(-1,-1, 1, 1,true,false), 'actual' => True),
array('datos' => array(-1,-1, 1, 1,true,true), 'actual' => True),
array('datos' => array(-2,-2, 0, 0,true,true), 'actual' => True),
array('datos' => array(-3,-3,-1,-1,true,true), 'actual' => False),
array('datos' => array(-5,-3,-1,-1,false,true), 'actual' => False)
);
foreach($pruebas as $prueba) {
$id = $this->__creaCurso($prueba['datos']);
…
$this->assertEqual($prueba['actual'], $resultado);
}

Fitnesse

Dentro de una página se puede usar !today, que se reemplaza por la fecha / hora actual. También se pueden poner fechas relativas (!today -1).

Alternativa 2

En este caso, la forma de cubrir esto es la Inversión de Control / Inyección de Dependencias. Se debe utilizar el servicio de obtención de día y hora actual a traves de una capa de abstración, de manera de poder reemplazarlo por una implementación controlada por las pruebas. Un ejemplo de esto se muestra en el capítulo 15 del libro FIT for Developing Software.
El SUT debe estar preparado (o debemos poder modificarlo para) para recibir la referencia al servicio.

Alternativa 3

En muchos casos el usuario pide funcionalidad que depende de la fecha actual, pero esa funcionalidad podría generalizarse para una fecha abitraria, con valor de negocio. Por ejemplo, cheque a depositar. Tiene sentido con fecha de hoy, pero si puedo poner fechas futuras, ayuda a la planificación.
Se puede evitar el aumento de la complejidad para el caso más usado con valores por defecto apropiados.

Alternativa 4

Puedo probar que un evento esté en intervalos temporales. Por ejemplo si quiero probar que un registro de auditoría es correcto, puedo almacenar el horario previo y posterior a la operación, y verificar que el registro esté dentro de ese intervalo.

viernes, 12 de agosto de 2011

Relación entre la frecuencia de entrega y los procesos

Recientemente vi un video de Kent Beck, Software G Forces: The Effects of Acceleration, comentado por Mary Poppendieck en How Cadence Predicts Process.

Kent analiza como cambian los procesos y buenas prácticas según aumenta la frecuencia de entregas (Anual, Trimestral, Mensual, Semanal, Diaria, Horas). Comenta como algunas prácticas son buenas con cierta frecuencia de entrega y son malas en otras.
Plantea la relevancia de este análisis debido a que, según su percepción, la frecuencia de entrega de los equipos de software tiene a acelerarse.

Mi intensión es hacer un resumen, pero recomiendo ver el video que, aunque dura 90 min, es mucho más rico que este post.

Entregas anuales → trimestrales

Prácticas que se agregan: Test de aceptación automatizados, refactoring, Integración continua
Justificación: No se puede solo reducir los tiempos, hay que cambiar los procesos. No puedo tener un mes de integración y corrección de bug, con una o dos semanas de pruebas manuales para hacer regresiones. Entonces aparece Integración continua, y Pruebas de Aceptación Automatizada. No puedo tener uno o dos meses de diseño, aparece la necesidad de avanzar aún sin tener todo el diseño hecho o cerrado. Estoy seguro que tendré que cambiar el diseño, por lo tanto, tengo la necesidad de refactoring.

Cambios en el negocio: Suscripción.
Justificación: No se pueden vender 4 versiones por año. Necesito bajar el costo de transacción (tanto para la empresa como para los clientes).

Entregas trimestrales → mensuales

Prácticas que se agregan: prueba por parte de los desarrolladores, reuniones diarias, tarjetas en las paredes.
Prácticas que se quitan: Departamente de QA, soporte a múltiples versiones, Documento de diseño, Control de cabios, equipo de análisis, equipo de build.
Justificación: no hay tiempo para el ida y vuelta con un grupo separado de QA. La mayoría del testing y la reducción del defectos deben ser hechos por el mismo grupo, y probablemente por la misma personas (testers en el equipo y pruebas por los programadores), en el plazo de horas, no de días. La comunicación debe ser mucho más rápida, no podemos sincronizarnos y detectar problemas una vez por semana o mensualmente. Tenemos que estar al tanto cada día, solo tenemos 20 días para entregar (reuniones diarias), tenemos que planificar y re-planificar en forma barata y rápida (tarjetas en las paredes, dejar de usar control de cambios formales). No podemos dedicar mucho tiempo para escribir las decisiones detalladas de diseño antes de usarlas (Documentos de diseño).
Al aumenta la cantidad de entregas, el costo de soporte de muchas versiones se vuelve prohibitivo, y debemos mantener una o pocas versiones del producto (soporte de múltiples versiones). Necesitamos iniciar el diseño y el desarrollo, no podemos esperar una fase de análisis o el ida y vuelta en paralelo con un grupo de análisis (mismo problema que con QA).

Cambios en el negocio: Pagar por el uso.
Justificación: la suscripción no nos da suficiente feedback. Con pagar por el uso, sabemos realmente que funcionalidad que estamos desarrollando les interesa a los clientes.

Entregas mensual → semanales

Prácticas que se agregan: migración de datos en vivo, cero defecto, ramas temporarias, dovela clave (keystoning), kanban.
Prácticas que se quitan: equipos de test, migración en un sólo sentido, ramas de release, parches, diseño de usabilidad al inicio, venture capitals
Justificación: para poder cambiar las estructuras de datos en sitios con grandes volúmenes de datos y cantidad de usuarios, se debe hacer procesos de migración en dos o tres fases, de manera de cambiar la estructura sin nunca dejar de dar el servicio (migración de datos en vivo).
Como los tiempos son cortos, algunas funcionalidades se comienzan a agregar sin hacerlas visibles. Solo cuando está todo dispobible, se agrega la última parte (como la dovela clave de un arco de medio punto), y queda dispobible para los usuarios. Siendo que las entregas son tan rápidas, cualquier cambio, por más urgente que sea, puede incluirse en la próxima entrega. Se elimina la necesidad de procesos de emergencia (parches).

Cambios en el negocio: Bootstrap financing.
Justificación: La financiación de Venture Capitals necesita mayor predecibilidad en los planes, e impone restricciones a desarrollo de productos (a esta velocidad).

Entregas semanal → diarias

Prácticas que se agregan: inmunización, A/B testing
Prácticas que se quitan: staging, equipo de operaciones, reuniones diarias.
Justificación: algunos de los releases van a ser malos. Tenemos que tener formas muy sencillas de volver atrás o formas muy rápidas de corregir y continuar. No hay mucho tiempo para discusciones sobre diseño de interfase, se pude simplemente dar las alternativas y ver como lo usan los usuarios (A/B testing). Para hacer entregas rápidas, no podemos pasar por tantos pasos (ambientes) intermedios. Simplemente no hay tiempo para usarlos (staging), lo que se puede hacer es hacer instalaciones en distintos servidores de producción, que se va midiendo y obteniendo feedback. Todo esto lleva a que la operación debe ser parte de la responsabilidad del equipo (equipo de operaciones). La comunicación en el grupo tiene que ser tan continua y rápida, que no tiene mucho sentido para las reuniones diarias.

Mis conclusiones

Esta visión me hizo repensar mis ideas sobre La mejor manera de probar, reinterpretando parte de mis observaciones desde esta nueva perspectiva. La corelación entre ambas visiones es muy fuerte, pero no completa. Es interesante que la visión de Kent está muy asociada a situaciones en las que el software es el componente principal de los productos.

miércoles, 18 de noviembre de 2009

Revistas gratuitas sobre Testing y otras yerbas

Hace unas semanas estuve hablando con Rodrigo Guzman sobre la profesionalización de los testers, y surgió la necesidad de leer y aprender contínuamente.
Derivamos en que, además de los libros y foros, en las publicaciones periódicas, normalemnte todas con registración, pero gratuitas.
Que lo disfruten (¡y sepan manejar el exceso de información!)

lunes, 21 de septiembre de 2009

Intro al testing de software en Rosario

El pasado viernes y sábado di un curso en Rosario, organizado por el Centro de Calidad e Innovación del Polo Tecnológico de Rosario, similar al que había dado hace unos meses en SADIO.
Con Fabián Longhitano estuvimos trabajando para armar el curso, balanceando horario, duración, costo y contenido, hasta lograr un producto que tuvo buena aceptación. Asistieron 26 personas.
¿Cuáles fueron los cambios? Lo más importante desde el punto de vista de contenido es que redujimos la duración a 10 hs, para que sea fuera de horario laboral. Esto implicó muchos cambios al contenido (originalmente el curso es de 16hs)
  • Decidí mantener el material (tiene cambios menores con respecto al anterior), para que pueda servir de guía sobre como ampliar los temas.
  • Cambié el ejercicio del Pajarraco ya que requiere al menos 90 min. Es una gran pérdida, porque este juego es muy bueno para entender el manejo de requerimientos y aceptación en ambientes ágiles, así como la dinámica de grupo y el desarrollo incrementar.
  • Sumé el juego de los 99 globos, que también es muy bueno para ver temas de aceptación, y también conceptos de calidad desde el punto de vista de Lean, y tiene la ventaja que puede ser realizado en 30 min (aunque no es una analogía tan buena de Scrum y XP, que tuve que explicarlos, pero no practicarlos).
  • Hicimos también el Origami (igual que los 99 globos, lo estuve haciendo últimamente en varios entornos). Usé principal mente para explicar el pair programing y como sirve para que los testers participen en sesiones de TDD.
  • Quité la mayoría de los recorridos por herramientas, solamente las nombré y mostré Fitnesse. No hice una mini sesion de TDD con jUnit, ni mostré Findbugs, Hudson, SVN/Tortoise, FIT, Selenium y Marathon como hice en el curso anterior.
Aún no tengo el resultado de las encuestas, pero creo que a la gente le resultó útil.

Veremos como seguimos!

miércoles, 8 de julio de 2009

Intro al testing en SADIO

A mediados del mes pasado di un curso sobre Introducción al Testing en SADIO.
Como siempre me pasa la primera vez que organizo cursos con alguna entidad, y a pesar de todas las experiencias previas (SADIO nos ayudó mucho en la organización de Ágiles 2008), antes del curso tenía cierta ansiedad por ver la convocatoria, que tipo de gente participa, cómo es la organización y logística del evento, etc.
Por suerte, la organización estuvo muy bien, y la convocatoria fue muy buena. Encontré a algunos comocidos, pero a muchos desconocidos, lo que es bueno! Todos muy entusiastas y comprometidos. Gente de Gral. Pico, de Córdoba, de La Plata, y por supuesto de la Cdad. de Buenos Aires. Muchos testers, algunos desarrolladores. Una pena que la gente de Córdoba no conocía al Lab de Calidad del INTI, y los cursos que dan sobre testing. Una muestra (y van ...) que los testers no tenemos una comunidad. Los pocos cursos que se dan los conocen pocas personas.

En lineas generales, el experimento salió bien. Pueden ver las transparencias y el código.
En cuanto a contenido, creo que debería haber recortado cantidad, en favor de más ejercicios. Dos días con mucha presentación se vuelve aburrido. Aún así, tuve que saltear contenido.
El códido está con NetBeans, junit, emma, y Marathon. Es el caso ultra simple de los triángulos, que usamos para hacer un brevísimo TDD (junit), mostrar cobertura (emma) y realizar pruebas automatizadas desde GUI (Marathon).

Hicimos el juego del Pajarraco, y como siempre, sirvió a su cometido: ser una referencia para todo lo que vimos después.

No me quedé conforme con la presentación de los temas de cobertura. Quedó como una presentación teórica, dada a las apuradas. No logré lo que buscaba: una herramienta y demostración sobre el valor adicional que podemos dar los testers.

Tampoco dió el tiempo para hacer prácticas sobre pruebas exploratorias, algo que me hubiera gustado.

Veremos si cambio un poco para Rosario (Agosto). Y después vienen los cursos de Automatización, en FIUBA (si logro organizarlos) y en Rosario, también con el Lab de Calidad del Polo.

jueves, 11 de diciembre de 2008

Herramientas para testing en PHP

Cuando organizamos el curso de Testing con Lucas Campos, una de las dudas que teníamos era si un curso corto e introductorio serviría. Con muchos temas por tratar, debíamos restringir el número de herramientas tratadas, y necesariamente muchas serían sólo nombradas.

Nos pareció que quizás esto era un valor en sí mismo. Dar una visión de muy alto nivel de lo que considerábamos podría ser un entorno de trabajo infectado por la calidad y el testing.

Con alegría vemos que a varios de los asistentes este enfoque les sirvió para
elegir qué batallas pelear, en dónde hacer hincapié como primer experimento de mejora.

¡Pero Gabriel Maffia y Norberto Bezi, de HRSmart, dieron algunos pasos más!
En paralelo con el curso, fueron investigando, probando e implementando estas herramientas, que no fueron tratadas en el curso (Gabriel hablando):

  • Continuous Integration: phpUnderControl que es básicamente un wrapper para CruiseControl que cambia el Look & Feel y te permite administrar los proyectos que tengas en el servidor de integración continua (agregar un proyecto, quitarlo, habilitar/deshabilitar tareas) con una serie de scripts.
  • Unit Testing: PHPUnit implementa el framework de xUnit en PHP (no es el único, pero es el mejor y se integra con phpUnderControl). Hace también toda la parte de Coverage y Project Mess Detection (PMD).
  • Análisis de Código: Usamos PHPCodeSniffer para revisar que se cumplan las coding guidelines.
  • Documentación: Usamos Doxygen para hacer la documentación. Existe también PHPDoc pero no es tan completo como Doxygen, que genera diagramas de clase, colaboración y llamadas.
  • Otra herramienta que todavía no probamos (y no doy fe que funcione :) ), pero que vale la pena investigar para Análisis de Dependencias: PHP_Depend
  • Hay dos herramientas que si bien nosotros no las usamos esta bueno nombrar: Xinc es un servidor de integración continua escrito integramente en PHP y Phing que es un project builder como ant, pero escrito en PHP (es el que usa Xinc para correr sus tareas).

Por no mencionar que Norberto está trabajando en FIT para PHP...

martes, 25 de noviembre de 2008

Randori con Python

Ayer facilité mi primer Randori, que fue con Python. Éramos un grupo de 7 personas con una máquina, proyector y pizarrón, en la Facultad de Ingeniería de la UBA.

Seguimos en forma aproximada las reglas de Coding Dojo

La diferencia fue que cambiamos de par cada vez que el par cumplía un ciclo: nuevo test, código, refactorear, commit
En las reglas originales, se disponen de 5 min timeboxed.

Esto les dio más tiempo a las personas que por alguna causa tardaban más (desconocimiento del lenguaje o las herramientas) pero se complicó cuando empezamos a tener suficiente cantidad de código como para que el refactoring no sea trivial. En ese caso, las discusiones sobre diseños, al no tener timebox, se eternizaron.

Otro problema que se presentó es con los casos de personas que vienen del mismo lugar, se conocen bien y están acostumbradas a trabajar de a pares entre ellos. La tendencia es a hablar entre ellos y olvidarse del resto de la audiencia. Un tema a mejorar.

Repetimos la semana que viene y les comento como sale.