Real world experiences: Programmers love writing tests… well, not in this town.

The main idea behind unit testing is validate that every module or class is working properly; the procedure is to write test cases (yes, code it) for all methods so that whenever a change causes a regression, it can be quickly identified and fixed…
Well this sounds great! But sometimes it just doesn’t work too easy in a real web development scenario: real sites with billion pages views and with business requirement changing 5 times daily for only one coded class.

If we search for testing best practices we will quickly find the different testing types: Integration, Function, Unit, Acceptance and Regression.
Every web developer or web project manager knows that we should to apply some of these practices to get a successful project (in terms of QA, integration and functionality), and of course, we will need a combination of them to achieve our success, lets take an example to clarify this: we wont be happy with a bunch of classes working well separately (maybe programmers will be happy) because what we need is the whole puzzle finished (business requirements), if one piece is missed or its broken we (as Web Project Manager) will fail.

So, if you will face a real web project be prepared to apply and integrate many testing methods with an opened minded approach. You should know that the key will be to accept the change in a constantly changing environment, with or without unit testing.

Ruby decorator pattern

Is any kind of ruby decorator pattern out-of-the-box there?
so far i didn't find any pure decorator pattern in ruby, instead of this all i have found is the ruby-way of decorating.

(Updated June 2006)
So.. times goes by ... and I found this implementation by Jason Arhart using module.

class Foo
def initialize(s)
@s = s
end
def to_s
@s
end
end

module SingleQuoted
def to_s
"'" + super + "'"
end
end

module DoubleQuoted
def to_s
'"' + super + '"'
end
end

foo = Foo.new('foo')
puts "#{foo.id} - #{foo}"
foo.extend(SingleQuoted)
puts "#{foo.id} - #{foo}"
foo.extend(DoubleQuoted)
puts "#{foo.id} - #{foo}"

Ruby Composite Pattern

I have found this intresting implementation of the composite pattern based on the missing_method ruby structure...

class Quelindo
def method_missing(method_id, *args)
puts "Hee hola, no hay ningun metodo que se llame #{method_id}"
end
end

# implementemos esto para ver como va...
c=Quelindo.new
c.sarasa

class Leaf
def scale(factor)
end

def addChild(kid)
# do nothing or raise an exception
end

def getKid( index)
# do nothing or raise an exception
nil
end
end

class Composite
def initialize
@kids = []
end
def method_missing(method_id, *args)
@kids.each do kid
kid.send(method_id, *args)
end
end
def addChild( kid)
@kids <<>

# heee bueno esta es la implementacion
c = Composite.new
c.addChild("Hola")
c.addChild(Composite.new)
a = Leaf.new
c.addChild(a)
puts c.getChild(1)

5 steps to apply design patterns successfully

Weeks ago I’ve published a composite pattern implementation in Ruby I’ve found surfing the net. Since that day many ideas are growing in my mind, so I went for a journey into the darkness of the deepest abstraction levels and finally I have arrived to this conclusion:

We could think in a pattern as:

“A set of rules which can be used to make or to generate things or parts of a
thing, especially if the things that are generated have enough in common for the
underlying pattern to be inferred or discerned, in which case the things are
said to exhibit the pattern”

Years ago when the great design patterns book was published “Design Patterns: Elements of Reusable Object-Oriented Software” the world could understand how to use a well-tested solutions instead of create a new solution for every daily problem.
But time goes by, new languages emerged and day by day a lot of programmers were trying to fit that tested solutions (patterns) in their preferred languages.
Some times they’re making a big complex solution only for this reason: they want to use a pattern because it’s a tested solution, but they forgot that this is a well tested DESIGN solution. What we have here is a pattern adaptation that has changed the design pattern structure itself (not only the code, but the design too), hence they maybe could solve the same problem at lower cost without applying that pattern.


So my recipe to designers/coders is:
1 - Prepare your class diagram, with the candidates almost selected.
2 - Read the pattern definition (not the intent only!)
2 - Learn how to use it.
3 - Apply them to your class diagram when it’s possible
4 - Before coding: search well-tested implementations in your selected language
5 - Finally, face the real trade-off: to be (a new pattern inventor) or not to be, when the coding begins.

I hope this recipe works for you since it works for me and my colleagues here, by the way: I’m anxious to read your comments! What is your thought on this?

Type Object Pattern

(updated version in spanish here)

Desacopla instancias de sus clases para que estas puedan ser implementadas como una instancia de una clase. Type Object permite crear nuevas clases dinámicamente en tiempo de ejecución porque estas son instancias, y también permite al sistema crear instancias de esas class-like instancias.
A veces una clase no solo requiere un numero desconocido de instancias, sino que tambien una cantidad desconocida de subclases, Un objecto puede crear nuevas instancias, pero usualmente no puede crear nuevas clases sin tener que recompilar.

Cuando usar este patron?
-Las instancias de una clase necesitan estar agrupadas para implementar el comportamiento o los atributos del grupo.
-La clase necesita una subclase por cada grupo para implementar los atributos/comportamientos del grupo.
-La clase requiere una gran cantidad de subclases y/o la variedad total de subclases que quizas se requieren se desconoce
-Se necesita poder crear nuevas agrupaciones en tiempo de ejecucion que quizas no se predijeron durante el diseño.
-Se necesita poder cambiar una subclase de un objeto despues de que se instancio sin tener que mutar a una nueva clase.
-Se necesita jerarquizar los grupos recursivamente de modo que ese grupo sea a su vez un item de otro grupo.

Object Design (Wirts-Brock/McKean) – Capitulo 2

El Responsability-Driven es un metodo informal y la herramienta principal es el poder de abstracción. Responsabilidad describe que es lo que nuestro software debe hacer para cumplir su proposito.Vamos desde los requerimientos iniciales a las primeras descripciones y modelos, desde este punto a unas descripciones y modelos mas detallados de los objetos , de los objetos candidatos y los modelos detallados de sus responsabilidades, con patrones y collaboration.

Project definition and planning.
Aunque nuestro proyecto sea pequeño siempre debemos realizar la declaracion del projecto(statement) incluyendo un proposito, una vista general, la definición del alcance y los beneficions. El Project plan describe lo siguiente:
- Como se va a desarollar el soft.
- Los valores importantes para el proyecto y la gente involucrada.
- Los recursos y sus roles, los procesos y los ingresos esperados.
- Los entregables.
- Early description.
El analisis incluye la definición del sistema, la descripción y el analisis de las actividades de los objetos.Requerimientos del usuario, administrador, o cliente pueden ser:Uso, performance, configuración, autenticación, concurrencia, escalabilidad, seguridad, confiabilidad.
No importa cuanto trates, nunca vas a identificar todos los requerimientos.

Diseño.
En diseño construimos un modelo de cómo va a funcionar nuestro sistema. Dividiendo esta etapa en 2 subfases.
-Crear un diseño inicial
-Crear una solucion mas comprensiva.
Esta etapa se divide porque la mayoria de las aplicaciones son demasiado complejas para llegar a un correcto diseño la primera vez.

Viendo desde multiples perspectivas.
Cada sponsor de nuestro proyecto tiene distintas necesidades. Los diseñadores de objetos tenemos dos desafios:Interpretar correctamente los requerimientos y concerns (preocupaciones) de nuestros stakeholders.Presentar nuestro trabajo de diseño de modo que sea bien entendido por una basta audiencia.

Analisis description
Transformamos vagas ideas en especificaciones de lo que queremos construir.
Los errores en la especificación del producto son los mas costosos porque afectan a todas las siguientes actividades.Uno de nuestros objetivos es dejar en claro lo que es ambiguo.colectar y describir de manera uniforme de que es responsable nuestro software.Nos esforzamos por entender donde termina nuestro software, donde comienza el entorno y que funciones debe realizar.

Usage descriptions.
UML Define a un Actor como algo o alguien fuera del sistema que interactua con el. Estos tienden a estar agrupados en tres diferentes campos:
-Usuarios
-Administradores
-Proframadores externos y devices
Y tienen dos caracteristicas comunes:
-Son externos a la aplicación
-Ellos interactuan con nuestro sistema.

Se utilizan 3 formas de casos de uso: Textos simples narrativos, escenarios con pasos numerados y conversaciones que enfatizan el dialogo entre el usuario y el sistema.Las conversaciones describen la interaccion entre el usuario y el software como un dialogo.

Conceptual Objects
A medida que realizamos actividades de diseño mas detalladas, nuestros objetos van a ir teniendo caracteristicas mas relacionadas con computers y apareceran mas extraterrestres para los demas.Core del software:Nuestro soft necesita un núcleo solido. Esto puede entenderse de varias formas:Objetos, conceptos y procesos clave.Objetos que implementan algoritmos complejosInfraestructura tecnica.Objetos que administran tareas de la aplicaciónObjetos de interface de usuario.

CRC Cards
Las ideas principales sobre los objetos candidatos se guardan en CRC Cards.donde podemos definir datos acerca de nuestros objetos, como son chicas y no estan en la computadora se pueden ordenar fácilmente sobre una mesa y ver de distintas forma pero al mismo tiempo.

Object Design (Wirts-Brock/McKean) – Capitulo 3

Las abstracciones que se elijen afectan en gran medida a todo el diseño.
Concebir objetos es una actividad altamente creativa.Encontrar buenos objetos quiere decir identificar abstracciones que son parte del dominio de la aplicación y su maquinaria de ejecución.Para inspirarse al momento de diseñar se puede utilizar el conocimiento del dominio de la aplicación, las nociones acerca de las necesidades de la maquinaria de la aplicación, las lecciones aprendidas y las experiencias del pasado.
Los primeros candidatos a encontrar deben representar cosas importantes, conceptos y mecanismos.Típicamente estos son inteligentes: hacen cosas.
Las abstracciones vienen luego cuando se entiende las relaciones con otros objetos.Primero identificar objetos que tienen roles claros, luego decidir que candidatos deben saber y hacer sus responsabilidades y con cuales deben trabajar (sus colaboradores),Cuando se realiza la transición de candidatos a clases e interfaces, se puede emplear herencia, abstracción, interfaces y colaborations para construir un buen y flexible diseño.Se sugiere tratar de contar una historia acerca del sistema para entenderlo rapidamente.

--Los candidatos generalmente representan:
-El trabajo que el sistema realiza.
-Cosas directamente afectadas por la aplicación o algo conectado a la misma
-Información que fluye a traves del sistema
-Actividades de toma de desiciones, control y coordinación.
-Estructuras y grupos de objetos.
-Representaciones de cosas del mundo real de las cuales la aplicación necesita tener info.

What`s in a Name?
-Elegir los nombres cuidadosamente.Cuando el nombre de un objeto es escuchado, los diseñadores infieren algo acerca de de sus roles y responsabilidades.
-Incluir solo las cosas mas importantes en un nombre.
-Elegir un nombre que no limite el comportamiento.
-Elegir un nombre que dure toda la vida del objeto.
-Elegir un nombre que se adapte al contexto del diseño actual.
-No sobrecargue los nombres
-Eliminar los conflictos en nombres utilizando adjetivos

Describing Candidates
Escribe la definición del objeto en una CRC Card.Agregar hechos especificos de la aplicación a la definición generica.Distinguir candidatos por como se comportan en la aplicaciónCharacterizing Candidates
Podemos caracterizar candidatos de acuerdo a sus:Habitos de trabajo
-Relaciones con otros
-Obligaciones Comunes
-Ubicación en la arquitectura de la aplicación
-Nivel de Abstracción.

Para explorar los habitos preguntamos:”que hace y como encaja?”.

Connecting Candidates
Por su limitado espacio, solo se puede contar con un resumen en las tarjetas CRC. Pero estas son mucho mas que un espacio compacto para guardar ideas de diseño. Son reales y tangibles. Se puede elegir una y hablar acerca de ella como el objeto en si mismo. Pero como se relacionan, que objetos hacen cosas similares? Una forma util de agrupar candidatos es la siguiente:
-Por la capa de aplicación
-Por casos de uso
-Por el role estereotipado
-Por el vecindario
-Por el nivel de abstracción
-Por el tema de la aplicación
-No hay una forma estándar de completar las CRC cards, se debe encontrar la mejor para uno mismo.

En conclusión, quedarse con un candidato cuando se puede:
-Ponerle un buen nombre
-Definirlo
-Estereotiparlo
-Ver que se puede usar para soportar un caso de uso en particular
-Ver que es un elemento importante de la arquitectura
-Asignarle una o dos responsabilidades iniciales
-Entender como los otros objetos lo ven
-Ver que es importante
-Diferenciarlo de los otros candidatos similares

Descartar un candidato cuando:
Tiene responsabilidades que se superponen con otros candidatos que gustan mas.
Parecen vagos
Parecen estar afuera de los limites del sistema
NO agregan valor
Parecen insignificantes, muy inteligentes o demasiado para lo que se necesita realizar