Open Scrum
En el Pentaho Community Newsletter de enero aparecio un articulo bastante interesante de una nueva vieja metodología de desarrollo denominada OpenScrum. Vieja porque es basicamente el Scrum común y corriente pero con algunas modificaciones para adaptarlo a la gran entropía que suelen presentar los proyectos open source.
Como bien se sabe ningún proyecto open source del tipo “community-driven ™” va a quedar bajo el paragüas del CMM ya que el desarrollo tiende a ser bastante caótico. OpenScrum aparece para proporcionar una metodología agil a quien quiera utilizarla.
No me voy a poner a describir Open Scrum, en la wiki de Pentaho hay información de sobra, pero quiero compartir una imagen que resume el ciclo de desarrollo y acotar un par de reflexiones.
A simple vista sigue pareciendo un simple Scrum, de hecho lo es, pero hay que destacar un par de cosas.
- La Comunidad aparece como un Stackholder más, lo cual esta bueno porque se hizo común entre los proyectos grandes (Fedora, MySQL, Pentaho, etc) que la comunidad sea un gran beta tester o un arma parches.
- El tiempo de cada sprint aumenta hasta 12 semanas con lo que tenemos una duracion de iteracion enorme. Terminamos haciendo RUP pero sin documentación.
- Aparece la figura de “Fix & Acceptance” de tiempo indeterminado, la escencia ágil de la metodología se termina perdiendo.
- Es obra de Pentaho así que hay que darle una oportunidad
Habrá que ver cuantos proyectos están en condiciones de tomar esta metodología, y cuantos quieren hacerlo, el tiempo dirá si es implementable.
Identificadores Unicode en Java
Hablando de Unicode recorde algo que a veces pasa inadvertido pero puede ser beneficioso.
Como los colegas rusos saben ДОМ o Привет son identificadores válidos en cualquier compilador Java. Java admite cualquier letra unicode como identificador. Ojo que dije letra y no caracter, para ver que diablos es una letra y que no lo es dentro de la interminable tabla Unicode tenemos dos metodos más que utiles:
boolean Character.isJavaIdentifierStart(char c)
y
boolean Character.isJavaIdentifierPart(char c)
Ambos devuelven true si el caracter que se le paso como parametro puede utilizarse al comienzo de un identificador o como parte de este respectivamente.
Por lo tanto podriamos declarar tranquilamente una
public class Murciélago
Lo cual puede llegar a ser medio molesto para andar tipeando los acentos pero esta caracteristica, a veces olvidada, llega como un regalo del cielo cuando hay que hacer una
public class Ñandu
Ahora no hay más excusas para el horrendo
private int anio;
en lugar de año 
UTF-8
Si hay algo que da problemas en j2ee es el encoding. Se tienen que poner de acuerdo 3 o más capas y hablar todos el mismo idioma, o mejor dicho, escribir en el mismo alfabeto. El siguiente link muestra como poner un filter que se encargue de forzar el encoding en los parametros de los POST o GET, a menudo la parte que esta más escondida para cambiar el encoding.
NOTA: Hay que tener en cuenta que el encoding del request solo se puede cambiar ANTES de leer cualquier parameter, asi que si tenemos otros filters lo mejor es poner este al principio para asegurarnos que ningun otro haya hecho nada raro con el request.
http://ianpurton.com/struts-utf-8-and-form-submissions/
“Tengo un alfabeto, aun para los ciegos, que quiero escribir en todas las paredes.”
F. Nietzsche
Jugando con Reflection
Uno de los mejores inventos del siglo pasado es sin dudas la API Reflection de Java, extrañamente me veo rodeado a menudo de gente que, o bien no la conoce, o bien le da miedo. A los primeros solo puedo darles el consejo de que lean el capitulo 9 del libro Hardcore Java para que se enteren de que va, a los segundos solo puedo darles la razón…La API Reflection es como un martillo, lo podemos usar para construir una iglesia o para romperle la cabeza a alguien, despues no sirve para nada. Así, usar esta API permite que nuestros programas interactuen con clases de las cuales no conoce absolutamente nada (nos podemos olvidar de implementar interfaces!) ó bien podemos hacer un “bypass” de los modificadores de acceso haciendo inservible a cualquier objeto. Dominar la API Reflection para no caer en las incontables tentaciones que nos ofrece es una disciplina de autocontrol digna de un arte marcial.
Para los que no se avisparon todavia de que va la API Reflection la idea es basicamente manipular “metainformación” de las clases en tiempo de ejecucion para poder conocer los metodos, propiedades ó constructores de clases que quiza ni sabiamos que existian. A continuacion dejo un pedazo de codigo que muestra las virtudes, a veces peligrosas, de esta API.
public class Perro {
private void ladrar() {
System.out.println(“GUAU!”); //un metodo privado para ladrar.
}
}
public class PruebaReflection {
public static void main(String[] args) {
Perro p = new Perro(); //Nada del otro Mundo.
Class clase = p.getClass(); //A no confundir Class con class. El
// metodo getClass() devuelve un objeto
//de clase Class con la “metadata” de la
// clase Perro :S
Method metodo = clase.getDeclaredMethod(“ladrar”) //Method es a los
//metodos lo que Class
// es a las clases
metodo.setAccesible(true) //wow.. le decimos que ignore los
// modificadores de acceso del metodo.
metodo.invoke(p); //el metodo invoke de la clase Method permite
// invocar a un metodo sobre un objeto en
//particular, en este caso sobre nuestro Perro p.
}
}
Si ejecutamos el codigo aparecera en la pantalla GUAU! que a priori no podriamos haber accedido por ser privado de la clase Perro ¿Aterrador verdad?. En el otro extremo imaginense la tarea de armar la GUI de un CRUD (create, read, update, delete…) para nuestro modelo. No es negocio hacer a mano una ventana para cada clase que participa en nuestro modelo, en cambio podemos aprovechar la API Reflection para que en tiempo de ejecucion arme dinamicamente las ventanas de acuerdo a las propiedades que encuentre en las clases que les indicamos. ¿Nos ahorraria bastante tiempo, no?
Caminar una colección
Mucho ojo al tratar de caminar una colección:
ConcurrentModificationException This exception may be thrown by methods that have detected concurrent
modification of an object when such modification is not permissible.
…
Note that this exception does not always indicate that an object has
been concurrently modified by a /different/ thread. If a single thread
issues a sequence of method invocations that violates the contract of an
object, the object may throw this exception. For example, if a thread
modifies a collection directly while it is iterating over the collection
with a fail-fast iterator, the iterator will thow this exception.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ConcurrentModificationException.html
Esto es culpa del Iterator a traves del cual recorremos la clase (por mas que usemos un “enhanced for” en el fondo sigue habiendo un iterator) y hay que recordar que no se puede modificar una lista, agregando o eliminando objetos, mientras la estamos recorriendo con un iterator.
