Selenium IDE
A la hora de testear aplicaciones web, sin importar la tecnología que usemos, es deseable tener un buen aliado. Selenium, Windmill, HttpUnit son frameworks que permiten realizar un testeo vertical de la aplicacion web simulando ser un cliente HTTP. HttpUnit es mi favorito pero los tests se codifican en Java usando una API especifica por lo que no es apto para todos los entornos.
Selenium es un framework permite desarrollar testeos de forma declarativa y ejecutarlos tantas veces como se nos antoje. Selenium IDE simplifica la tarea de creación de los tests mediante una interfaz bastante intuitiva que se integra como plugin en Firefox.
Fluent Interfaces
¿No es extraño que los setters no devuelvan nada? En estos tiempos que corren me parece que nos estamos perdiendo algo, estamos desperdiciando algo tan valioso como el retorno de un metodo. Por lo menos así lo cree Eric Evans y Martin Fowler quienes nos proponen algo llamado Fluent Interfaces.
Si creamos un objeto de clase Perro lo mas sensato es inicializar su estado de alguna forma, podemos inicializarlo mediante el constructor o bien con los setters de sus propiedades.
Perro perro = new Perro();
perro.setNombre("Otto");
perro.setRaza("BassetHound");
perro.setFechaDeNacimiento("20/07/2003");
Fluent Interfaces nos propone esto:
perro.setNombre("Otto").setRaza("BassetHound").setFechaDeNacimiento("20/07/2003");
En un contexto cargado con muchos objetos del mismo tipo la sentencia anterior se vuelve más clara que sus predecesoras y con algo tan trivial como hacer que los setters en lugar de devolver void devuelvan una referencia al objeto actual.
public Perro setNombre(String nombre) {
this.nombre = nombre;
return this;
}
public Perro setRaza(String raza) {
this.raza = raza;
return this;
}
//and so on...
[Patrones] Observer
El patrón Observer es tan simple y elegante como efectivo. Es utilizado cuando uno o más objetos (Observers) necesitan saber sobre los cambios de estados u ocurrencia de eventos producidos en un objeto Subject. La implementación más corriente se da en la arquitectura Model-View-Controller donde la vista necesita saber cuando actualizarse debido a cambios en el modelo. Observer elimina las ineficientes “esperas activas” usando un mecanismo de callback o inversión de control.
El modelo consiste en una clase Subject con referencias a todos los Observers, objetos interesados en el subject, y un metodo notifyObservers() que invoca un metodo notify() implementado por cada uno de los Observers. De esta forma cuando el Subject sufre un cambio de estado o ante un evento avisa a los Observers y mediante el callback de una funcion notify que implementa cada Observer estos reaccionan al evento.
Java proporciona una clase java.util.Observable con el comportamiento de la clase Subject y una interface java.util.Observer que describe un método update() con la logica a ejecutar ante un cambio de estado. La forma de uso deberia explicarse sola: Tenemos un objeto Perro que cumple años y un Observador que avisa que el perro cumplio años 
class Perro extends Observable {
private int edad;
public void cumplirAños() {
this.edad++;
this.setChanged(); // se marca el objeto indicando que ha cambiado su estado.
this.notifyObservers(); // avisa a sus observadores sobre el cambio
// de estado del objeto o del evento ocurrido
}
}
El observador implementa el metodo update() que se ejecutará cuando el Perro notifique de su cambio de estado. El Perro cuenta, ademas, con un metodo addObserver(Observer o) que inserta un Observer dentro de los objetos a los que notificar los cambios o eventos.
class Observador implements Observer {
public void update(Observable perro, Object args) {
System.out.println("El perro cumplio años!");
}
}
En lugar de Perros que cumplen años y Observadores que hacen regalos el escenario tipico para utilizar este patrón se presenta cuando el Observador es un elemento de una GUI (un JTextField por ejemplo) que debe actualizarse de acuerdo a los cambios que sufre el modelo de datos.
Esto es Lazy Loading!
Lazy Loading es una técnica que implica no cargar un componente hasta que es usado. Esta técnica evita inicializar todo el grafo de dependencias de un objeto distribuyendo la creacion de las dependencias a medida que se necesitan. Si bien puede implementarse de muchas formas (la más usada es con un Virtual Proxy) un simple proof-of-concept es el siguiente:
class Ventana {
private Widget componente;
public Widget getComponente() {
if(this.componente==null) {
this.componente = new Widget();
}
return this.componente;
}
}
El componente es creado la primera vez que se usa en lugar de inicializarse dentro del constructor de la clase. Si miramos detenidamente el código vemos que no es Thread-safe ya que más de un hilo podria volver a inicializar el componente provocando efectos impredecibles. Por ejemplo con la siguiente secuencia:
Thread 1: llamado a getComponente()
Thread 1: if( this.componente == null ) <- Componente es null entonces entra en el bloque del if
Thread 2: llamado a getComponente()
Thread 2: if( this.componente == null) <- Componente es null entonces entra en el bloque del if
Thread 2: this.componente = new Widget();
Thread 2: this.componente.value = “Soy un componente perezoso”;
Thread 1: this.componente = new Widget();
OMFG!
Tampoco es negocio sincronizar el metodo getComponente() porque lo que ganamos implementando Lazy Loading lo perdemos en las sucesivas llamadas por el costo que tiene invocar un metodo sincronizado. Una solución es usar un mecanismo llamado Double Check modificando el código anterior de esta manera.
class Ventana {
private Widget componente;
public Widget getComponente() {
if(this.componente==null) {
synchronized(this) {
if(this.component==null) {
this.componente = new Widget();
}
}
}
return this.componente;
}
}
Lo que parece una redundancia grande como una casa en realidad es un hack maravilloso, con double check la condición se evalua dos veces: una vez sin sincronizar y otra vez sincronizada. Al repetir este proceso se gana en velocidad ya que en el peor de los casos solo se ejecuta el bloque sincronizado tantas veces como threads esten utilizando el objeto en lugar de ejecutarlo tras cada llamada a getComponente. Hay que tener en cuenta que esta tecnica, si bien es un hack maravilloso, puede tener problemas con las optimizaciones que hace la JVM Hotspot, más especificamente con el reordenamiento de instrucciones que hace el compilador.
Lazy Loading en realidad abarca más conceptos, como la carga perezosa de clases, y lo que se vio recien es conocido como Lazy Instantiation. Más alla de eso me parecio bueno comentar un poco sobre el tema tras el cambio de nombre que sufrio este blog 
Ya soy SCJP
Espero que me sirva más que la tarjeta de YPF o el carnet del Club
