agile-spain.com blogs

LecturasDSL

Thu, 26 Jul 2007 09:48:24 +0000

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

ErroresDeConceptoDeLaProgramaciónPorParejas

Tue, 24 Jul 2007 13:19:14 +0000

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..

Liberado JUnit 4.4

Mon, 23 Jul 2007 13:31:33 +0000

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.

AbismoParaLaMejora

Mon, 23 Jul 2007 08:20:47 +0000

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.

HerenciaDiseñada

Mon, 23 Jul 2007 08:07:10 +0000

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.

Diseño planificado y Evolutivo

Thu, 12 Jul 2007 15:23:44 +0000

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

Para este artículo voy a describir dos estilos de cómo se hace el diseño en el desarrollo de software. Quizás el más común es el diseño evolutivo. Esencialmente, el diseño evolutivo quiere decir que el diseño del sistema crece mientras se implemente el sistema. El diseño es parte de los procesos de programación y según el programa se desarrolla el diseño cambia.

En su uso habitual, el diseño evolutivo es un desastre. El diseño termina siendo la agregación de un manojo de decisiones tácticas tomadas en el momento, cada una de las cuales hace el código más difícil de cambiar. Se podría argumentar de muchas formas que esto no es diseño, de hecho esto por lo general conduce a un diseño pobre. Como Kent dijo, el diseño está ahí para permitir cambiar el software fácilmente a largo plazo. Como el diseño se deteriora, entonces se necesita la capacidad de hacer cambios con eficacia. Se tiene el estado de entropía de software, con el tiempo el diseño se pone de mal en peor.

No sólo hace esto el software más difícil de cambiar, esto también hace los errores más fácil de reproducirse y a la vez más difícil encontrar y seguramente para resolver. Esto es la pesadilla “codificar y arreglar”, donde los errores se hacen exponencialmente más caros de arreglar según el proyecto avanza.

HypótesisDeResistenciaAlDiseño

Wed, 11 Jul 2007 12:15:06 +0000

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

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

Desarrollo de Balas Trazadoras

Fri, 23 Feb 2007 21:07:45 +0000

Seguro que habeis oido de la practica militar de disparar con balas trazadoras cuando es de noche para poder apuntar mejor. Basicamente se basa en el hecho de que apuntar con una ametralladora es muy dificil, sobretodo por la noche. Por ese motivo se utilizan balas trazadoras que estan bañadas en fosforo y al ser disparadas dejan una estela de luz con la que el artillero se puede guiar y apuntar mejor.

El Desarollo con Balas Trazadoras (o TBD) hace exactamente lo mismo en un proyecto de software. Basicamente te deja ver a la dirección tomada dejandote apuntar continuamente mucho antes de que este terminado el proyecto.

Hoy en dia hay muchos procesos y metodologias (prefiero llamarlos ecosystemas ya que suelen fallar por eventos sociales) de las que nos podemos nutrir para sacar nuestro proyecto adelante. La mayoria de estas suelen ser o demasiado burocraticas o frustrantes. Sobretodo si vemos el espectro de ecosystemas (desde RUP a XP) todos nos imponen una serie de practicas que segun los creadores son el mejor camino a seguir y si no se practican todas ellas no estamos siguiendo su metodología. En esto estoy de acuerdo, o todo o nada (al menos si quiero decir que estoy en un equipo XP por ejemplo), ya que las metodologías suelen basar sus valores y practicas en las interrelaciones de estas.

Con DBT es diferente. El TDB no te dice como tienes que trabajar sino que mas bien complementa tu forma de trabajar. No te dice si tienes que hacer TDD (Test Driven Development) o escribir historias de usuario. Basicamente se implanta con coste cero y da unos resultados asombrosos. De hecho es posible ir añadiendo practicas al proceso ya que es un proceso muy ligero (comparable los procesos Crystal de Cockburn).

AdoptandoPropiedadDelCodigo

Thu, 08 Jun 2006 08:02:30 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

En la reciente entrada de mi bliki Propiedad de código (CodeOwnership), describí mi modo de ver diversos asuntos relacionados con quien es responsable del código. Muchos de mis amigos son practicantes de Extreme Programming (XP) y tienden a favorecer la propiedad colectiva del código. Sin embargo este tipo de prácticas no son absolutas y siempre deben ser tenidas en cuenta por las consideraciones del momento y lugar. Un de mis colegas me envió hoy una nota con la siguiente historia que he pensado que era un buen indicador de cuándo debes cambiar tus prácticas, incluso aunque seas un fan de XP. (Como este colega habla de su propio equipo, prefiere permanecer anónimo):

Yo cambié nuestro equipo de un modelo 'colectivo' a un modelo de propiedad 'débil' del código para contrarrestar la programación indisciplinada de un par de desarrolladores. Combinada con un poco de realimentación imparcial, el resultado fue una mejora de la velocidad dado que los desarrolladores que ahora “poseen” nuestras partes clave del código no están constantemente rehaciendo código de baja calidad, mientras que los que solían hacerlo se dedican a asuntos como búsqueda de defectos o cambios de código con poco riesgo – lo que libera tiempo del resto.

PropiedadDelCódigo

Thu, 08 Jun 2006 08:10:04 +0000

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Existen varios enfoques para afrontar la propiedad del código que se escribe. Yo las organizo en tres grandes categorías:

• Propiedad fuerte del código:divide el código fuente en módulos (clases, funciones, ficheros) y asigna cada módulo a un desarrollador. Estos sólo tienen permiso para realizar cambios en sus módulos. Si necesitan hacer un cambio en el módulo de otro desarrollador deben hablar con él para que lo realice. Este proceso puede acelerarse escribiendo un parche para el otro módulo y enviándoselo al desarrollador propietario.

• Propiedad débil del código: es similar al anterior en el sentido de que los módulos también son asignados a desarrolladores concretos, pero diferente en que también se permite que otros desarrolladores realicen cambios. Los propietarios de cada módulo deben tomar responsabilidad de los mismos revisando los cambios que otros realizan en ellos. Si un desarrollador quiere realizar un cambio sustancial en un módulo que no le ha sido asignado se considera conveniente hablar con el propietario antes de llevarlo a cabo.

• Propiedad colectiva de código:abandona por completo la noción de propiedad individual de los módulos. El código fuente es propiedad del equipo entero y todos pueden realizar cambios en cualquier parte. Puede considerarse este enfoque igual a no tener ningún tipo de propiedad de código, pero sus defensores prefieren poner el énfasis en la noción de propiedad por parte de un equipo en contraposición a propiedad por parte de un individuo. (El término propiedad colectiva del código, Collective Code Ownership en inglés, viene de Extreme Programming, aunque en su segunda edición se ha renombrado como Código compartido o Shared Code en inglés)

EvaluandoRuby

Thu, 25 May 2006 14:02:38 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Jorge Ferrer

Si estás leyendo esto, asumo que estás enterado de que ha habido una gran agitación entorno al lenguaje de programación Ruby y en particular de Rails, el framework para el desarrollo de aplicaciones Web. Algunos lo ven como el futuro de la programación, otros como una diversión peligrosa.

Empecé con Ruby hace algunos años. Los
Programadores Pragmáticos lograron captar mi atención y pronto se convirtió en mi lenguaje de script preferido. Con el tiempo he llegado a usarlo en gran parte de la producción de este sitio Web, en particular de este bliki. Me encanta este lenguaje.

Hay que distinguir entre mi gusto personal y si es algo que deban utilizar nuestros clientes. Podemos determinar su conveniencia en función de las características de los proyectos de estos clientes – y esto nos lleva a muchos argumentos sobre los pros y contras de la definición dinámica de tipos, convención sobre configuración, procesos versus threads (hilos) y otros. Tales discusiones son útiles, pero sigo siendo cauteloso con ellas. Hay demasiados asuntos que son difíciles de juzgar de esta forma y al final acabamos desperdiciando el tiempo en proyectos que son ralentizados por usar una tecnología que sonaba bien durante un partido de golf. Yo prefiero realizar estos juicios basándome en la experiencia – encontrar gente con experiencia exitosa en proyectos y que hayan usado Ruby.

Pruebas unitarias y de persistencia en Ruby on Rails

Wed, 26 Apr 2006 20:05:52 +0000

Uno de los aspectos que me ha sorprendido más gratamente de Ruby on Rails es la facilidad para hacer pruebas de una aplicación web a todos los niveles.

En el entorno J2EE no he acabado de encontrar herramientas de pruebas que cubrieran todas las necesidades del desarrollo de aplicaciones web. Para pruebas unitarias JUnit o sus competidores están muy bien, pero cuando te sales de ese terreno las cosas no están tan claras. En particular los entornos para llevar a cabo pruebas funcionales provocan que estas supongan un coste considerable.

En Rails tenemos el equivalente a JUnit+dbUnit+HttpUnit+Cactus+Jameleon y todo ello perfectamente integrado. Así da gusto :) El único pero que le pongo son los nombres que han dado a los distintos tipos de pruebas y que resultan bastante engañosos.

En esta entrada del blog comienzo explicando las pruebas que Rails denomina unitarias y que incluyen tanto a las realmente unitarias como a las pruebas de las clases de modelo Active Record. Estas últimas no son puramente unitarias, dado que dependen de que esté disponible una base de datos con determinada información en ella.

Pruebas de presistencia con Fixtures

Las primeras no tienen ningún misterio para las que hayan usado JUnit así que centrémonos en las segundas. Para ellas, Rails proporciona el sistema de Fixtures que permite definir los datos que deben estar presentes en la base de datos antes de la ejecución de la prueba. La forma de definir estos datos es mediante un fichero con formato YAML por cada clase del modelo. Todos estos ficheros se almacenan en el directorio tests/fixtures. Por ejemplo en SprintTracker los ficheros tests/fixtures/sprints.yml contiene:

La hora de la verdad con Ruby on Rails

Mon, 10 Apr 2006 21:51:05 +0000

La versión 0.1 de SprintTracker contenía únicamente funcionalidades típicas de los artículos de Rails. La hora de la verdad ha llegado al proponerme implementar las funcionalidades que había sugerido para la versión 0.2 y 0.3. Las más importantes son:

Gráficas Burndown de los sprints
Reordenación jerárquica de las páginas de administración de proyectos, sprints y tareas. Esto ha permitido mejorar mucho la usabilidad de SprintTracker
Páginas de edición rápida para añadir todas las reestimaciones de un día concreto o para una tarea concreta. Esto es fundamental si, como estoy haciendo yo últimamente, usas una hoja excel para llevar el seguimiento del proyecto
Otras mejoras menores: borrado en cascada de proyectos, sprints y tareas, validación a medida de reestimaciones (no puede haber dos para la misma tarea y día), etc.

En la captura de pantalla se muestra la vista de un sprint en la que se aprecian varias de estas funcionalidades.

Tras implementar estas funconalidades he liberado SprintTracker v0.3 y creo que ya empieza a ser una aplicación lista para ser usada. Para ellas no había ningún artículo que me guiara y ello me ha obligado a aprender mucho más sobre Rails y sobre todo a manejarme con las referencias online imprescindibles para todo desarrollador de Rails:

Peculiaridades de Ruby para desarrolladores Java (parte 2)

Tue, 04 Apr 2006 12:09:27 +0000

Continuando con la entrada anterior sigo explorando los aspectos de Ruby mas peculiares para un programador que viene del mundo Java.

Closures

En los artículos de autores relacionados con el mundo de los métodos ágiles es habitual oir hablar de lenguajes que soportan closures. Pues bien, tengo que reconocer que aunque creía haber entendido bien el concepto lo cierto es que al menos no lo había asimilado. Usandolo con Rails por fin lo he conseguido, así que ahí va mi intento de explicar lo que son:

Un closure puede verse como un bloque de código que se sitúa en paralelo al del método y al que éste puede pasarle el control cuando crea conveniente usando el método yield()

Un ejemplo típico de uso podría ser un método que itera por un árbol y realiza una acción con cada nodo. En Ruby es posible pasar al método (al que llamaremos iterateTree) un fragmento de código que será el que realice la operación sobre el nodo. Por ejemplo, la invocación del método para imprimir cada nodo podría ser:

  tree.iterateTree do |node|
     puts "Iterating node: " + node
  end

El fragmento de código entre do y end recibe el nombre de closure. El método iterateTree invocará el closure usando el método especial yield:

Peculiaridades de Ruby para desarrolladores Java

Sun, 02 Apr 2006 16:22:31 +0000

Durante estos días en que he estado aprendiendo Ruby y Rails para desarrollar SprintTracker 0.1 me he ido encontrando diferentes elementos de sintaxis que me han sorprendido, confundido o incluso disgustado (al menos inicialmente). He pensado que podía ser buen idea revisarlos porque creo que conociéndolos resulta mucho más fácil entender los fragmentos de código presentados en la mayoría de artículos sobre el tema. Como son bastantes cosas lo voy a dividir en dos entradas del blog.

Llaves y paréntesis opcionales

En Ruby los paréntesis y las llaves (() y {}) pueden omitirse cuando son obvios. Por ello en Rails es habitual encontrar invocaciones a métodos de la forma:

  nombre_método parametro

Que es equivalente a :

  nombre_metodo(parametro)

Cuando un mapa (hash) es el último parámetro de un método las llaves pueden ignorarse, así que uniendo esto a lo anterior es habitual encontrarse llamadas a métodos de la forma:

  nombre_metodo primer_parametro, :clave1 => "valor1", :clave2 => "valor2"

Que es equivalente a:

  nombre_metodo(primer_parametro, {:clave1 => "valor1", :clave2 => "valor2"})

Y que un programador Java escribiría como:

  Map segundoParametro = new HashMap();
  segundoParametro("clave1", "valor1");
  segundoParametro("clave2", "valor2");
  nombreMetodo(primerMarametro, segundoParametro);