Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

( Ver mi nota sobre LenguajeDeDominioEspecífico para una rápida introducción a este tema y a la terminología.)
Actualizado:David Laribee ha escrito un post contrastando lo que él llama interfaces fluidos ordenados o interfaces fluidos desordenados. La distinción es que los interfaces fluidos ordenados fuerzan a un flujo particular sobre cómo se compone una sentencia DSL. Él proporciona un ejemplo donde usa múltiples interfaces sobre un único ExpressionBuilder- la misma técnica que se usa por JMock.

Anders Noras ha escrito dos artículos interesantes sobre la escritura de DSLs internos en C#. El primer artículo da un ejemplo del DSL y una discusión contra la cínica lista de comprobación de Chromatic. El segundo artículo entra en detalles sobre su implementación.
Piers Cawley hacen incapié en que una característica clave de DSLs es su estrecha focalización en un dominio

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..

La nueva versión de JUnit se encuentra disponible ya en sourceforge .
En las notas de la nueva versión, los autores comentan:

JUnit is designed to efficiently capture developers' intentions about their code, and quickly check their code matches those intentions. Over the last year, we've been talking about what things developers would like to say about their code that have been difficult in the past, and how we can make them easier.

Entre los cambios de esta versión, se incluye una nueva sintaxis para las aserciones. Se puede consultar más detalle sobre esto en el blog de Joe Walnes.

Escrito por Martin Fowler
Traducido por Rafael Vacas

Si te importa lo que haces, te interesas en hacerlo cada vez mejor. Esto implica reflejar como haces las cosas y probar nuevas técnicas para ver si te hacen mejorar. Aunque otros recomienden nuevas técnicas, la única forma de saber si funcionan para ti es probándolas tú mismo y comprobar si mejoran tu rendimiento.

El problema es que la mejora, particularmente con nuevas técnicas no es lineal. A menudo hay una brecha que se abre cando intentas una nueva estrategia. La mejor ilustración que recuerdo de esto es del excelente libro de Gerald Weinberg Convertirse en un Líder Técnico. Viene de su hábito de jugar al pinball.

A medida que iba mejorando lentamente en mi nivel, empecé a sospechar que se me estaba pasando algo. Aunque mi puntuación subía rápidamente cuando tenía tres bolas en juego, de repente, al intentar mantener las tres bolas en juego, perdía las tres de golpe. Sólo pasaba una de cada cuatro veces, pero eso significaba que había perdido uno de tres preciosos turnos.

Me preguntaba que pasaría si dejaba de intentar mantener las 3 bolas en juego y me concentraba en su lugar en asegurar que una de las tres bolas se mantuviera en el campo de juego. Cuando probé esta nueva estrategia, mi puntuación cayó, inmediatamente, en el abismo. De hecho, estaba jugando contra un chiquillo al mismo tiempo, y empezó ganándome. Incapaz de afrontar la derrota, volví a mi antigua estrategia y lo puse en su lugar.

Más tarde, sin embargo, sin público observando, probé la nueva estrategia de nuevo. Y de nuevo mi puntuación bajó, pero me di cuenta de que no estaba perdiendo turno con tanta frecuencia, quizá sólo una de cada cinco veces que jugaba con tres bolas al mismo tiempo. Perseverando, con la práctica, mejoré mi habilidad para ignorar las otras dos bolas y mantener al menos una en el campo. No puntuaba mucho cuando las tres bolas estaban en juego, pero mi puntuación total aumentó. También conseguí jugar más tiempo en mi turno, lo cual es uno de los principales objetivos del juego.

Escrito por Martin Fowler
Traducido por Rafael Vacas

Uno de los más largos debates en los círculos orientados a objetos es el debate entre HerenciaAbierta y HerenciaDiseñada. Josh Block ha sido probablemente quien mejor ha resumido el principio de la herencia diseñada: “Diseña y documenta para herencia o si no prohíbela”. Con este planteamiento te preocupas de decidir qué métodos pueden ser heredados y proteges los otros para evitar que sean sobrescritos.

El argumento más común para la herencia diseñada es que dado que la herencia supone una relación muy estrecha (y rompe la encapsulación) es fácil que las subclases efectivamente rompan las superclases por ejemplo, omitiendo comportamientos necesarios cuando sus métodos son invocados.

Muchos programadores, particularmente aquellos con una ActitudPermisiva, no están muy convencidos por este estilo de argumento. Otro argumento que encuentro más apetecible es el de Elliote Rusty Harold al discutir los principios de diseño de XOM. La cuestión aquí es que “las API son escritas por expertos para no expertos”. El creador de librerías debería estar debidamente versado en la tecnología con la que trabaja la librería. Deberían trabajar para simplificar esta tecnología a los usuarios de la librería. La encapsulación consiste en esconder secretos, por tanto una buena librería debería esconder toda clase de complicaciones y puntos peligrosos a los usuarios de la librería, ya usen la librería mediante invocaciones o herencia. Por tanto, con XOM puedo sobrescribir de forma segura las clases de la librería para hacer lo que quiera ya que la librería garantiza que aún así producirá XML bien formado, sin que tenga que preocupar a mi fea cabecita con todas las cosas que de otra forma podrían ir mal.