Archive for the '12114' Category

TDD y Baby Steps

Thursday, January 31st, 2013

Ya saben que TDD (Test-Driven Development) es uno de mis temas favoritos. Y no sólo porque me gusta, sino porque creo que es uno de los temas a difundir para mejorar la calidad de nuestro trabajo, tanto en el código entregado como en la calidad de vida de nuestro día laboral. Soy un convencido de que el código de producción escrito SIN TDD debería estar prohibido, directamente. Y si insisto con el tema, es porque no veo que se aplique y entienda TDD, por lo menos en estos lares, Buenos Aires y Argentina. Por ejemplo, escucho por ahí:

– “TDD es más lento”, no lo veo así, es un caso de “vísteme despacio que estoy apurado”.

– “TDD no es para los programadores junior”, no, cuanto más inexperto es el programador, más va a aprender y mejorar haciendo TDD y usando el cerebro, claro 😉 TDD no produce mejores programadores, pero los hace pensar en lo que están haciendo.

– “TDD es hacer test y code coverage”, por favor, no me presenten a una persona que piense así. O que piense que TDD es aprender a hacer test unitarios, sea lo que sea que “unitario” signifique.

– “TDD es aburrido”, para mí es como un juego, cada test en verde es como superar un nivel de juego.

Una de las actividades que me nacen naturalmente cuando hago TDD, es que lo que escribo va creciendo de a poco, de a “baby steps”, de a pasos de bebé. En vez de hacer un gran salto en la implementación, si uno realmente programa con TDD va agregando poco código en cada test que se agrega. Y no se agrega código que no nazca, que no tenga una traza que lo remita a la necesidad de un test. Esto consiga que el software que vamos creando, crezca como si fuera un organismo vivo, desarrollándose de a poco. Esto trae varias consecuencias:

– Cada código agregado tiene su función específica: hacer que un test pase a verde

– No aparece código “por las dudas” o por casos de uso todavía no implementados.

– No pensamos “por adelantado”, poniendo código que todavía no necesitamos (evitamos romper YAGNI).

– No se adopta tecnología o soluciones (librerías, frameworks, base de datos, etc… ) hasta el momento en el que REALMENTE se necesitan.

Y algo menos evidente:

– El código que vamos armando es pasible de refactorización en cualquier momento

– Y aún puede haber más que refactorización, sino también cambiar algo de nuestro diseño, sin grandes “dolores”

Ahora les advierto: no se puede aplicar todo esto con TDD, si parte del código QUE ESCRIBIMOS NOSOTROS no lo hacemos con TDD. Porque entonces vamos a "sufrir" cuando lleguemos un día a necesitar refactorizar, o rediseñar, y entonces la parte del código que habíamos escrito SIN TDD nos va a pesar y nos va a complicar ese paso de refactor o de rediseño.

Me gustaría mostrarles un ejemplo, pueden ver los posts y series:

TDD Paso a Paso

Escribiendo una aplicación con TDD

Escribiendo un Intérprete en .NET

VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD

con video en Desarrollando una aplicación con TDD desde cero con código en https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp

y mis posts de TDD.

Pero cada día, en mi cuenta de GitHub, voy haciendo commits por test, así que pueden entrar a algún proyecto y ver cómo va evolucionando. Por ejemplo, hoy voy a empezar a codificar SimpleKeeper (una especie de ZooKeeper pero en Node.js). Pueden en cualquier momento entrar a ver la lista de commits e ir revisando si cumplo o no cumplo con TDD y “baby steps”.

Algo muy interesante, y relacionado con este post, es:

Kent Beck’s Four Hats

Controlling the size of your checkout is a valuable coding skill. You should be able to take small, baby steps, and check-in at any time. There are a number of benefits. If you check-in frequently the merge to source control becomes trivial. Your colleagues won’t get annoyed, because that change which they need is never far away. Most importantly you are in control of your work.

Vean ahí los cuatro sombreros de Kent Beck.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Los Principios de la Buena Programación

Wednesday, August 17th, 2011

Encuentro en estos días el post The Principles of Good Programming, de Christopher Diggins.

Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O’Reilly. Christopher can be reached through his home page at www.cdiggins.com.

Me gustaría transcribir en mis palabras la lista de principios de ese post. Veamos:

DRY – Don’t repeat yourself – No repetirse a sí mismo. Podría remontarme a Ada Lovelace y su idea de rutinas para encontrar el germen de este principio. Funciones, métodos, clases son todos artefactos que fueron apareciendo en la historia de la programación para evitar la repetición. Ver http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle – Principio de Abstracción. Es una forma de llegar al DRY de arriba. “Cada pieza de funcionalidad significativa en un programa debe ser implementada en un sólo lugar del código fuente”. Ver http://en.wikipedia.org/wiki/Abstraction_principle_(programming 

KISS (Keep it simple, stupid) – Manténgalo simple, estúpido! Tal vez mi principio preferido. Ante tanta complejidad accidental, temas de tecnologías, frameworks y librerías, la mejor solución a un problema es la más simple. Menos código, menos bugs. Ver http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) – Evitar crear algo que no vamos a necesitar. Es común tratar de ver el futuro y comenzar a crear abstracciones que todavía no estamos usando. Una de las razones por las que prefiero trabajar con TDD (Test-Driven Development) es que nos permite alcanzar éste y otros principios (como el KISS y los que siguen abajo) de una forma natural. Muchas veces digo: “No hay que cruzar al puente antes de llegar al puente”. Ver http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work – Haga lo más simple que funcione. Siempre hay que preguntarse ¿qué es lo más simple que tengo que escribir para que esto funcione? De nuevo, TDD me lleva a este principio. Al no introducir complejidad a cada paso, vamos manteniéndonos en el camino de la simplicidada. Ver http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think – No me haga pensar. Hay un libro de Steve Krug con este título (Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition) Así como la interfaz tiene que ser algo que no nos haga pensar ¿y ahora, cómo lo hago? el código que escribamos tiene que ser consumible de la misma forma: evitar lo “tricky”, los nombres de las funciones deben declarar claramente lo que hacen, etc. Por ejemplo, a veces veo código Fluent que hay que hacer un curso en la NASA para ver qué hacen, de tanto lambda que aparece en los parámetros ;-). Pero tengo que reconocer que pueden ser útiles una vez uno entiende el concepto.

Open/Closed Principle – Principio Abierto/Cerrado. Uno de los principios S.O.L.I.D. (ver http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29) Entidades de software (clases, módulos, funciones) deben estar abiertas a la extensión, pero cerradas a la modificación. Hay que escribir clases, no para que otros las modifiquen, sino para que otras las usen y extiendan.

Write Code for the Maintainer – Escriba código para el que va a mantenerlo. Yo diría: escriba código para sí mismo dentro de seis meses. Otro punto donde TDD me ayuda. No hay que escribir código “cool”, hay que escribir código claro que haga cosas “cool”. Muchas veces veo código brillante, pero inmantenible. Tomemos nuestro tiempo, y pongamos “algo de amor” en el código ;-). Dice el post que comento: “Escriba el código como si el que tuviera que mantenerlo fuera un sicópata asesino que conoce donde vives” Ver http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment – Principio del menor asombro. Se aplica en general a la interfaz de usuario, pero también se puede aplicar al código. El texto del código no debe provocar sorpresa. Ejemplo: el nombre de una función debería corresponder con lo que hace. Hasta la indentación del código y las convenciones ayudan. Ver http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsability Principle – Principio de Responsabilidad Unica. Un componente de código (clase, función) debe ejecutar una única y bien definida tarea. Otro de los principios S.O.L.I.D. Ver http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling – Minimizar el acoplamiento. Cada componente (bloque de código, clase, función, etc.) debe minimizar las dependendencias de otros componentes. Por ejemplo, usar lo menos posible variables en común. Cuando un componente A tiene que usar el componente B, debe tratar de conocer lo menos posible de B: por ejemplo, sólo consumir lo necesario de su funcionalidad, y no entrar en temas como crear a B (de ahí el uso de inyección de dependencias). No hacer cosas como B.propiedad.propiedad2.metodo() (un caso de la ley de Demeter de más abajo). El minimizar el acoplamiento trabaja junto con el maximizar la cohesión. Ver http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

Maximize Cohesion – Maximizar Cohesión. Un componente debe tener funcionalidad altamente relacionado. Evitar implementar en un componente dos funcionalidades que no están relacionadas, cumpliendo tareas que no tienen relación. Ver http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

Hide Implementation Details – Ocultar Detalles de Implementación. Ejemplo, no exponer variables de estado interno: preferir propiedades controladas o mejor, directamente métodos. Concentrarse en exponer lo que los demás van a consumir, antes que los detalles de cómo cumplimos con nuestra tarea. Esto permite llegar a cambiar la implementación sin afectar al resto del sistema. En lenguajes tipados como C# y Java, se puede llegar a algo de esto consumiendo interfaces definidas. http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter – Ley de Demeter. Los componentes de código deben comunicarse con los directamente relacionados. Usar B si se referencia desde A, pero evitar usar B.C.D.metodoE(). A se relaciona directamente con B si lo recibe en su constructor, o como parámetro de un método. También se puede tomar como “directo” la funcionalidad heredada de una superclase. Ver http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization – Evitar la Optimización Prematura. Otro caso de “no hay que cruzar el puente hasta llegar al puente”. Hay que evitar pensar en optimizar código, si apenas lo estamos armando. Ir armando el código de tal forma que podamos refactorizarlo, cambiar implementación, concentrar los cambios en pocos lados (todo esto ayudado por los otros principios, y TDD) para cuando llegue el tiempo de optimizar (si es que llega). Para optimizar, hay que medir, no intuir. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" – Donald Knuth. http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good – El Reúso de Código es Bueno. Aprovechar código ya escrito, si es buen código (esperamos que cumpla los otros principios). Mejora el tiempo de desarrollo, y si es código ya usado y probado, mejora el resultado. Ver http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns – Separación de Preocupaciones. Un componente no debe ocuparse de dos o más tareas, especialmente si tienen poca relación no accidental entre sí. Por ejemplo, el manejo de la autorización a ejecutar un método debería quedar, en lo posible, fuera del código de ese método. Ver http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change – Abraza el cambio. El cambio es una constante en el desarrollo de software: cambio en los requerimientos, la funcionalidad, la tecnología, la evolución de un sistema exitoso. No hay que luchar contra el cambio, sino trabajar para estar preparado para él. Programación ágil, TDD, integración continua, Scrum, iteraciones cortas, revisión en cada iteración, son todas prácticas que soportan este principio. Ver Extreme Programming Explained: Embrace Change (2nd Edition)

Alguno más? Comentarios? Supongo que puedo escribir algún post de cada uno, con algún ejemplo. Veremos! 😉

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Otro Code Retreat en Buenos Aires

Thursday, September 9th, 2010

Ya había escrito sobre una actividad anterior en:

Code Retreat en Buenos Aires

(si no conocen el término, ahí recomendaba

http://www.coderetreat.com/how-it-works.html

What Is Code Retreat

The idea for code retreat was spawned at the January, 2009, Codemash Conference by Patrick Welsh, Nayan Hajratwala and me, Corey Haines. The idea was to develop a repeatable, day-long event that was focused on practicing the fundamentals of software development. The first event was held in Ann Arbor, MI, not long after the conference.

Más información en:

http://www.coderetreat.com/
http://coderetreat.ning.com/

)

Ayer jueves me entero, por un tweet del bueno de @MartinSalias, que vuelve la actividad, mañana viernes 10 de septiembre. Se anuncia en

Segundo Code Retreat

Ahí leo:

La idea de un Code Retreat es que un grupo de programadores nos juntemos, programemos , discutamos y aprendamos unos de otros. 
Esta es la segunda realización en Buenos Aires (y Argentina por lo que sabemos!)

Cuándo: 10 de Septiembre, 14:30 a 20:00 hs

Dónde: MUG – Rivadavia 1479 Piso 1 Of. A.

Como recibimos algunas consultas, aclaramos que el evento no tiene costo para los participantes.

¡Inscribirte!

La mecánica es la siguiente: vamos a trabajar haciendo Pair Programming y TDD. Todos los pares van a atacar el mismo problema en sesiones de 40 minutos. Una vez terminada la sesión haremos una retrospectiva de unos 10-15 minutos para reflexionar sobre los problemas que encontramos. Luego de la retrospectiva, se cambian los pares, se borra el código escrito en la sesión anterior y se arranca una sesión nueva con el mismo problema que la anterior.
La idea es hacer 4 o 5 sesiones por la tarde, una retrospectiva final y, para los que se prendan, podemos terminar con alguna cerveza o agua mineral en algun bar cercano.

Los lenguajes que elegimos para este Retreat son Java y C#. Generalmente se usa un solo lenguaje por retreat, pero son lenguajes muy parecidos y nos pareció que abría un poco más la convocatoria usar los dos. 
Durante el retreat vamos a trabajar los siguientes conceptos:

– es bueno ser capaces de tirar el codigo y empezar de nuevo

– pequeños pasos en TDD, muy pequeños

– foco en el tercer paso del ciclo de TDD: calidad del codigo y refactoring

No es necesario tener experiencia en TDD ni en Pair programming.
Vamos a necesitar que todos los que puedan lleven laptops con Eclipse/Visual Studio instalados

 

Muy bueno que vuelva a realizarse, y que sea en el MUG (Microsoft User Group de Argentina). Si alguien asiste, que deje post! 😉

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Code Retreat en Buenos Aires

Thursday, April 15th, 2010

Siguen organizándose actividades para desarrolladores de software, por estos lares. Es interesante ver cómo algunas prácticas se van difundiendo (TDD, refactoring, SOLID y demás), y si bien una práctica tiene su fundamento y teoría, es necesario, justamente practicarla para ponerse “proficient” en la misma. Una forma de practicar es en grupo. Esa es la idea de los Code Retreat. Pueden leer en:

http://www.coderetreat.com/how-it-works.html

What Is Code Retreat

The idea for code retreat was spawned at the January, 2009, Codemash Conference by Patrick Welsh, Nayan Hajratwala and me, Corey Haines. The idea was to develop a repeatable, day-long event that was focused on practicing the fundamentals of software development. The first event was held in Ann Arbor, MI, not long after the conference.

Más información en:

http://www.coderetreat.com/
http://coderetreat.ning.com/

Ahora, gracias a la organización de la gente de Prama, tendremos un Code Retreat en Buenos Aires:

http://sites.google.com/site/comunidadagiles/argentina/code-retreat

Leo ahí:

La idea de un Code Retreat es que un grupo de programadores nos juntemos, programemos , discutamos y aprendamos unos de otros.

Cuándo: 24 de Abril, 8:30 a las 17:30

Dónde: El evento va tener lugar en las oficinas de Pragma (que es el sponsor) y va a durar desde la 8:30 a las 17:30. Después está la idea de compartir un par de cervezas con aquellos que puedan. La dirección es San Martín 575 Piso 1 (San Martín y Tucumán).

Como recibimos algunas consultas, aclaramos que el evento no tiene costo para los participantes.

Tienen en esa página el enlace para inscribirse.

Es un evento de gran parte del día, es un día sábado, para que puedan concurrir sin estorbar tanto el día laboral. Y una excusa para pasar el sábado con otros desarrolladores de software. Leo en la página:

La mecánica es la siguiente: vamos a trabajar haciendo Pair Programming y TDD. Todos los pares van a atacar el mismo problema en sesiones de 40 minutos. Una vez terminada la sesión haremos una retrospectiva de unos 10-15 minutos para reflexionar sobre los problemas que encontramos. Luego de la retrospectiva, se cambian los pares, se borra el código escrito en la sesión anterior y se arranca una sesión nueva con el mismo problema que la anterior.
La idea es hacer unas tres sesiones a la mañana, almorzar juntos y hacer un par más de sesiones a la tarde. Como evento final del Retreat vamos a hacer alguna actividad relacionada pero distinta a las sesiones.
Los lenguajes que elegimos para este Retreat son Java y C#. Generalmente se usa un solo lenguaje por retreat, pero son lenguajes muy parecidos y nos pareció que abría un poco más la convocatoria usar los dos.
Durante el retreat vamos a trabajar los siguientes conceptos:

– es bueno ser capaces de tirar el codigo y empezar de nuevo

– pequeños pasos en TDD, muy pequeños

– foco en el tercer paso del ciclo de TDD: calidad del codigo y refactoring

No es necesario tener experiencia en TDD ni en Pair programming.
Vamos a necesitar que todos los que puedan lleven laptops con Eclipse/Visual Studio instalados.

Como se va a trabajar con Pair Programming, pueden concurrir sin laptop, pero cuantos más lleven, mejores parejas se podrán formar.

Bienvenida la iniciativa!

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Más allá de hablar de buenas prácticas

Sunday, April 4th, 2010

Esta semana pasada, Hari Hariri (@hhariri) escribió un interesante post:

Loved the show but I have toget back to the real world now

Hariri comenta sobre su experiencia en dos conferencias, en dos charlas que dio, para desarrolladores. Escribió:

As usual, to set the context, I asked a series of questions regarding unit tests:

“How many of you know what a Unit Test is” – 80% put up their hand.

“How many of you do Unit Testing?” – 10% put up their hand.

“How many of you think Unit Testing is valuable?” – 80% put up their hand

La primera charla fue enfrente de desarrolladores PHP. Pienso que los desarrolladores PHP todavía trabajan un poco diferente de los demás desarrolladores, pero esto en base a mis recuerdos de programación PHP intensiva. Puede ser que hoy tengan más herramientas a su alcance para su trabajo. Pero la segunda chara de Hari fue en frente de 200 personas interesados en arquitectura de software.

Recientemente, en una charla interna en una compañía de software, @MartinSalias hizo preguntas parecidas, y el resultado fue similar al de Hariri. No tomé notas, pero en una de mis charlas los resultados tenían el mismo bias: a una gran mayoría les gusta y algo conocen de mejores prácticas, disciplinas XP, etc… Pero pocos las implementan.

Entonces, ¿dónde está el problema? Hariri escribe:

“A is good. I like A. I should do A. But I won’t do A”.

People identify themselves with the issues we talk about. They see the value writing automated tests and complying with design principles adds. They get excited, yet they don’t do it. Why?

I usually ask this question too, and the typical responses are:

1. Tight Schedules.

2. Decrease in Productivity. Drag and Drop is more productive

3. Customers want deliverables. Tests are not deliverables

and my all time favorite

4. “I’m paid to write code, not tests”.

Bueno, hay muchas razones, cada desarrollador de software y su equipo pueden tener varias razones para no aplicar TDD, pruebas automáticas, revisión de código, programación de a pares, etc…

Tomemos un tópico, para ser más concretos y avanzar en el tema: TDD. ¿Por qué la gente no está usando más TDD en su trabajo diario? Mis razones candidatas:

– Conocen qué es TDD, pero nunca lo practicaron o practicaron poco, y tienen muchas dudas

– Si trabajan en un equipo, no todos los miembros del equipo están al tanto de lo que es TDD, y la persona que conoce algo no tiene la experiencia como para transmitirla a los demás.

(claro, también puede ser por la impresión de que lleva más tiempo (posición discutible) y que el “management” lo ve como un trabajo adicional sin valor)

¿Qué necesitan? Pienso que necesitan estos puntos:

– Conocer el “rationale”, el fundamento que sustenta a TDD (en general, se aprende en charlas, conferencias, libros…)

– Practicar TDD

– Tener un mentor para preguntar dudas, resolver problemas, revisar patrones

Cuando tuve que realmente comenzar a aprehender (más que aprender) TDD, el segundo punto lo resolví aplicándolo en mis proyectos personales. Y el tercer punto, lo encaré preguntando a otros programadores, usando foros web (poco), leyendo ejemplos, más libros, y principalmente, revisando código abierto; todavía sigo trabajando en los tres puntos. Pero veo que no todos los desarrolladores de software tienen el tiempo disponible para mejorar en sus habilidades, más allá del trabajo diario. Yo promuevo el “auto-aprendizaje”, pero la realidad es que no todos los desarrlladores tienen el tiempo (y la voluntad) de tomar ese camino. Y es un camino no exento de riesgos: al auto-aprender, podemos aprender mal algo sin tener una retroalimentación; sin tener un mentor, es dificultoso aprender temas que abarcan tantos puntos y detalles, como TDD.

Estoy trabajando en equipo en el Proyecto Hogwarts para solver esos puntos: darle a la gente el soporte para aprender TDD, IoC, principios SOLID, y más. No sólo con ejemplos, sino también con fundamentos. No sólo teoría, sino también práctica. No solo práctica, sino evaluación, soporte posterior, detección de puntos débiles, acciones correctivas. En el caso de este proyecto, el cliente final ya compró la idea de las mejores práctica: no tenemos que convencer a un “management” escéptico. Estamos todavía en una etapa temprana del proyecto: los primeros entregables estén en beta, distribuidos internamente. Siguiendo lo ágil, producimos algo y lo entregamos, para conseguir revisión, en vez de esperar a tener todo armado. Espero que cuando el proyecto gane más momento, más material y también la experiencia ganada en el proceso, será publicada y compartida con la comunidad.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

ALT.NET Hispano VAN (reunión virtual): FitNesse + Acceptance Testing + Selenium

Tuesday, January 12th, 2010

El próximo sábado 16 de Enero, tendremos nueva VAN a las 18 GMT, 3 de la tarda acá en Buenos Aires, organizada por la comunidad ALT.NET Hispano. El presentador del tema, Diego Jancic, explica:

Para los interesados, les comento que la idea es hablar en torno a FitNesse y Acceptance Testing, y que la conversacion guie los detalles y los intereses, para profundizar sobre cualquier tema; basicamente es mantener el espiritu Agile de reuniones.
De cualquier forma, estoy preparando todo como para que haya una base de temas interesante para guiar la VAN.
Resumen:
La herramienta FitNesse, incluyendo todo lo necesario para comenzar y llegar a integrarla con .NET. Adicionalmente, se incluiran otros 2 temas que son claves para aprovechar FitNesse al maximo. Primero, será indispensable hablar de Acceptance Testing, para entender su importancia y utilidad en el desarrollo de software; y luego, Selenium, una herramienta que permite probar aplicaciones web. Ésta ultima será simplemente un ejemplo de aplicacion, ya que FitNesse no esta limitado a aplicaciones Web, cualquier tipo de extension y aplicacion esta permitida.
Objetivo:
Permtir a cualquier persona con conocimientos de programacion, configurar un ambiente de pruebas automatizadas y orientadas al cliente. De forma que alguien sin conocimientos de sistemas, pueda integrarse rapidamente a un ambiente de desarrollo, definiendo pruebas de cualquier tipo.
Indice de Temas (tentativo):
* Acceptance Testing: Breve introduccion.
* Selenium IDE: Introduccion, demo y problemas.
* FitNesse
** FitNesse en solitario: Instalacion, introduccion, arquitectura, formato de la Wiki, ejemplos incluidos
** Extensibilidad con .net
** Integracion con Selenium RC
* Versionado de las pruebas
* Integracion de FitNesse con NAnt y CruiseControl.NET

Pueden leer más sobre los temas en:

http://www.fitnesse.org/
http://seleniumhq.org/
http://en.wikipedia.org/wiki/Selenium_(software)
http://seleniumhq.org/projects/ide/
http://en.wikipedia.org/wiki/Acceptance_testing
http://www.extremeprogramming.org/rules/functionaltests.html
http://www.extremeprogramming.org/rules/userstories.html

Más información sobre cómo asistir a la reunión virtual, software necesario, enlaces: http://altnet-hispano.pbworks.com/Descripcion-de-Reuniones

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Aventuras de Programación Extrema en C#

Monday, November 2nd, 2009

El viernes pasado estuve visitando las oficinas del Microsoft User Group de Argentina, acá en Buenos Aires. Tenía que dictar un curso de .NET, pero hubo un corte de luz (al parecer frecuente en estos días de alta temperatura; Buenos Aires está sufriendo cortes de luz, mucha carga en los aires acondicionados creo). Ni lerdo ni perezoso, me entretuve unas horas aprovechándome de la biblioteca del MUG, sobre la que tendría que postear más. Los socios del MUG tienen acceso a los volúmenes de la biblioteca, y hay libros de temas como Windows Server, programación .NET, Test Driven Development, programación en general, desarrollo web y más.

Así que, no teniendo más deberes de los que ocuparme ni más preocupaciones en el alma (como Descartes ante la estufa… :-), me dediqué a la lectura. Estuve leyendo un libro de ASP.NET 3.5 (no tengo el autor acá), estuve hojeando el clásico “Práctica de la Programación” de Kernighan y  y estaba por encarar el Sistemas Operativos de Tanenbaum (al que sigo desde las primeros avisos en la Dr.Dobbs, al principio de los ochenta, sobre compiladores multilenguajes). Pero un libro me llamó la atención, había sido devuelto a la biblioteca el jueves, por el bueno de @lmpetek: el Extreme Programming Adventures in C#

Excelente libro, escrito por Ron Jeffries, acreditado XPer, uno de los tres “fundadores” de XP (Extreme Programming), junto con Ken Beck y Ward Cunningham. Pueden seguirlo en Twitter por @RonJeffries. Leo en la página del libro en Microsoft Press:

See how eXtreme Programming (XP) works—and learn Microsoft .NET and C# programming in the process!
See eXtreme Programming (XP) in action at the hands of an XP master—and learn Microsoft .NET and C# programming in the process! In this fast-paced, hands-on exposition, Ron Jeffries—one of the leading voices and practitioners in the XP community—demonstrates that you can write well-designed, resilient code incrementally and safely, while minimizing your investment in speculative up-front design. As Jeffries builds his sample application, you get firsthand insights into what successful XP development looks like, complete with real-world challenges such as the eleventh-hour change order. For further practice and study, you can download all the author’s code—including the missteps—so you can see XP and agile concepts in action and assess how they fit into your own work.Pair program with an XP master, discovering how to:

  • Streamline and simplify the software development process
  • Work more effectively as part of an XP development team
  • Reduce missteps by designing, testing, and refining code in increments
  • Receive clearer specifications and feedback from customers
  • Write cleaner, more expressive code—and weed out more bugs
  • Conserve resources by planning and reassessing progress as you go
  • Maintain a sustainable work pace—and avoid burnout
  • Step up delivery dates, shipping the most crucial features first
  • Improve customer satisfaction!

    Jeffries va explicando, cómo un equipo de dos personas (uno es él mismo) van aprendiendo sobre C#, .NET, mientras desarrollan el software XMLNotepad. Es muy interesante de leer, porque explica paso a paso lo que van haciendo: cómo hacen spikes, pequeñas exploraciones, luego vuelven a tests, avanzan poco a poco, escriben y se ponen de acuerdo con los tests de aceptación, las historias de usuario, cómo generan un modelo testeable, mockean parte de la interfaz de usuario, etc. Si Uds. tienen dudas sobre cómo es el desarrollo con Programación Extrema, si quiere conocer los detalles de un caso concreto, éste es el libro. Pueden aprovecharlo, sepan o no C#: la parte técnica no es la más importante, es la explicación detallada la que hace de este libro, un excelente recurso.

    Hmm… ya va siendo hora de tener un sistema de biblioteca para el MUG, no? Podríamos armarlo usando XP… 🙂

    Nos leemos!

    Angel “Java” Lopez
    http://www.ajlopez.com
    http://twitter.com/ajlopez