Lidiando con ingenieros hiperkinéticos

Cierta clase de ingenieros que se encuentran en puestos de management tienen una necesidad kinética irrefrenable que algunas veces puede dificultar tus tareas mas nobles. Presento aquí una lista de técnicas basadas en un estudio realizado por un grupo de desarrolladores de Santiago del Estero. De aquí en adelante, favoreciendo la brevedad, utilizaré la palabra ingenieros para referirme al grupo de ingenieros hiperkinéticos.

• No cierres tu messenger - nunca cierres tu ventana del messenger mientras el ingeniero este conectado. Si lo haces, el recibirá una notificación de que lo haz hecho y repasará su lista mental de tareas para darte o te contactará para hacerte consultas del estado de tus tareas.

• Reporta tu progreso - cuando te encuentres realizando una tarea inútil o tediosa, comienza cualquier consulta del ingeniero diciéndole que ya estás con dicha tarea. Aunque él no sepa muy bien de lo que le hablas es probable que te reasigne alguna otra.

• Retén tu reporte diario - si te ves en la desgracia de tener que enviar un reporte al final del día, no lo envíes hasta estar seguro de que tienes todo preparado para retirarte de la oficina. En general, los ingenieros suelen refrescar sus páginas web de management y cuentas de correo con una frecuencia que va de los treinta segundos a los cinco minutos. No querrás estar aún en la oficina para el próximo refresh.

• usa un wallpaper adecuado - Una actividad lúdica de consecuencias serias y muy practicada por los ingenieros es el avistaje de entorno de desarrollo. Considera la posibilidad de utilizar un wallpaper que muestre el debugger abierto, con un par de ventantas complicadas y algún breakpoint. Usa ésta técnica solo si los avistajes ocurren desde distancias superiores a los 3 metros.

• recuerda a tus colegas (new) - Puedes lograr cierto anonimato respecto a tus archivos, dejándolos en una carpeta de un antiguo compañero de trabajo que haya abandonado la empresa en busca de ambientes mas prósperos o generosos(ej. "escritorio/P.Lobato").

• dale un touch a ese header (para C y C++) (new) - Si el sistema del que te ocupas posee un buen nivel de acomplamiento, puedes conseguir un tiempo de introspección metiéndote con ese header del que todos dependen.
  

beans inmutables

Usualmente, para modelar clases inmutables suele darse un conjunto de constructores públicos que toman de argumento el estado en el que debe quedar la instancia inmutable. Una desventaja que trae esta técnica es que no se lleva bien con otro consejo conocido: prefierase una lista de argumentos breve siempre que sea posible. Un ejemplo típico de una clase inmutable podría ser la siguiente:

/**
* Modela un punto en un espacio bidimensional
*
* Esta clase es inmutable
*/
final class Point {
private final int x,y;

public Point(int x,int y) {
this.x=x;
this.y=y;
}

public int getX() {
return x;
}

public int getY() {
return y;
}
}

El hecho de tener una lista compleja de argumentos trae varias desventajas:

• El orden de los argumentos es artificial, por lo general no hay ninguna relación entre la posición de un argumento y lo que este representa. Por ejemplo, sería igualmente aceptable tomar como primer argumento un valor de una fila en una matríz y como segundo, un valor de una columna o viceversa.

• El usuario debe conocer exactamente que representa cada argumento, aún cuando podría estar interesado solo en algunos de ellos.

• Construir un nuevo objeto inmutable a partir de otro implica reconstruir el estado para poder pasarlo en la lista de argumentos (lo cual implica un conocimiento muy preciso del estado de la clase).

• La extensión de la clase probablemente implique una modificación de los constructores, esto rompe el código cliente.

Una solución a este problema sería implementar algo parecido a un bean de java con la propiedad de inmutabilidad (un bean inmutable). Puede resultar interesante mirar String e Integer de la API de java ya que tienen este enfoque. Las condiciones que estos beans que debería cumplir son:

El objeto construido es inmutable

• El objeto posee un constructor por defecto razonable
• se puede obtener información sobre el objeto utilizando un conjunto de métodos getters
• se puede obtener un nuevo objeto con alguna modificación en su estado respecto a otro objeto usando un conjunto de metodos setters

Un ejemplo de estos beans inmutables:

/**
* Modela un punto en un espacio bidimensional
*
* Esta clase es inmutable
*/
final class Point {
private final int x;
private final int y;

public static final Point Zero=new Point(0,0);

private Point(int x,int y) {
this.x=x;
this.y=y;
}

public int x() {
return x;
}

public int y() {
return y;
}

public Point x(int x) {
return new Point(x,this.y);
}

public Point y(int y) {
return new Point(this.x,y);
}
}

Basta revisar la lista de problemas presentados originalmente y comprobar que no se mantiene
ninguno de ellos.

claves: inmutable, beans, java beans, patterns

El problema del jugador falsificador

Cierto falsificador, con un gusto desmedido por el juego, se dirige a un casino en el que encuentra infinita su capacidad para obtener crédito por medios un tanto reprochables pero eficaces. Hecho esto, se acerca a una mesa de ruleta y se instala comodamente frente al croupier y apuesta al negro con la determinación de quedarse apostando hasta ganar.

-- indica si el color c sale o no en la ruleta

saleEnRuleta: Color -> Boolean
saleEnRuleta = c == dameUno ( {Rojo} U {Negro} )

-- retorna cuando la apuesta a negro resulta ganadora

apostarHastaGanar : Color -> Boolean
apostarHastaGanar (c) =
if (not sale(c)) then
apostarHastaGanar(c)
else
True
fi

La pregunta que surge de este modesto fuego de artificio que requiere de un croupier y un jugador de vida eterna es la siguiente:

¿Existe la garantía de que el jugador se retire de la mesa de juego una vez comenzada su apuesta?

La sospechosa respuesta a este interrogante estará por aquí en unos cuantos días, apenas encuentre una manera de disimular su imprecisión.

El tedio se apodera de vos a minutos de comenzado el controller

El modelo estaba listo, unas plantillas para la interfaz de usuario también, solo faltaba darle vida. Solo faltaba ...

Mucho

Jorge de Software Críptico confiesa durante su almuerzo: "Hoy, un tipo de otro sector me preguntó en que estoy trabajando -no sabía que decirle- hace tres meses que estoy con los actions de struts, le conté que estuve toda la mañana para escribir cuatro de esos, pero él quería que le dijera algo concreto, algo que tuviera que ver con el sistema. No hubo caso, al segundo o tercer concepto fingió saludar a un conocido y desapareció".

Cada listener, action, delegate (remplace aqui por el termino predilecto de su framework) ha de tener que convertir los datos que requiera de la vista a los tipos correctos del modelo, validar aquello que encuentre en ella y enviar los mensajes adecuados al modelo. ¿pero, siempre es esto necesario?

palabras claves: MVC, model, view, controller, patterns

Acerca del uso de polymorphic factories

Algo que me fastidia de utilizar fábricas polimórficas es el hecho de tener que complicar mi clase con una inicialización estática que registra la fábrica correspondiente. Por otra parte, me pregunto hasta que punto es esto una buena idea. Por ejemplo, Supongamos que diseñamos un modelo para que sea reutilizable: el hecho de que sus clases requieran o no el uso de fábricas no está determinado por el modelo sino por el uso que se requiera de éste. Al decidir que un modelo reutilizable contiene fábricas para sus clases, se está asumiendo que todos los usuarios del modelo están interesados en ellas. Sin embargo, me atrevo a pensar que para muchas aplicaciones sencillas estas fábricas están de mas, aun cuando el modelo usado encaja perfectamente. ¿Sería posible aislar el soporte de factories en una librería o package optativo? ¿Sería esto una buena idea?