Sobre la mezquindad y la ignorancia en los consultores “Pro”.

Hace un rato estábamos en la oficina viendo la manera de solucionar un conflicto que se presenta entre la herramienta de ensamblaje y el producto de seguridad que usamos, usamos Maven y ALES respectivamente.

El conflicto tiene que ver son que Maven al generar el binario del ensamblado, le pone como sufijo en el nombre del archivo la versión del artefacto, no voy a contar a detalle el conflicto, pero esta acción de Maven desencadeno un comentario sin sentido y sin razón de ser expresado. El comentario fue del experto del producto de seguridad: “Por eso no uso Maven”. A decir verdad me molesto el comentario, porque como mencionaba, ese comentario no tenia que ver en la charla, el objetivo de la charla no era discutir si usar Maven o no, simplemente se usa, estamos convencidos de sus beneficios, ademas somos los clientes y te friegas experto. El objetivo era solucionar el conflicto, no poner en duda el uso de Maven.

Dejando atrás el berrinche del comentario, y tratando de entender al experto, pensaba como trabajaba antes de usar Maven. Debo mencionar que usaba Ant para el ciclo de vida de mis binarios y de su ensamblaje. Lo que hacia era poner una carpeta llamada lib y ahí metía todas los archivos jar de las librerías que usaba. Esa carpeta la versionaba en el CVS. Cada vez que había una versión nueva o una actualización, tenia que actualizar el archivo de la librería. Bueno funcionaba, de hecho mucha gente sigue trabajando así. El problema con este enfoque es que se debe manejar de forma manual las dependencias de tus aplicaciones, y no solo de tus aplicaciones, si no también de las dependencias de las dependencias de tus aplicaciones. Que complicado.

Ahora las dependencias en un ambiente moderno de desarrollo con Ant, se usa Ivy. El cual se encarga de administrar las dependencias de las librerías, lo que en la mayoría de los casos minimiza muchos riesgos, sobre todo para la administración de la configuración de las aplicaciones. Maven administra muy bien las dependencias y un poco mas, al no tener que escribir todas las fases del ciclo de vida del ensamblaje de tu aplicación. Simplemente aplica DRY “Don’t Repeat Yourself” y convención sobre configuración, al mas estilo RubyOnRails.
Pensando un poco mas, y teniendo como referencia otras experiencias con expertos y arquitectillos, y considerando que la mayoría de las veces estos tipos no programan, y si programan lo hacen pésimo, no conocen frameworks y son meramente teóricos, lo único que conocen y atesoran con ahínco son lo que saben de las especificaciones y lo que leen en internet, lo que hacen lo sobre documentan, son expertos que actúan siempre de manera muy “Pro”, o eso creen ellos.

En fin, regresando a lo que hace Maven con los binarios generados, la critica y comentario de oportunidad de mejora del experto para Maven, simplemente no aplican, ya que el experto considera adecuado que la versión del binario no este en el nombre del archivo, si no mas bien en el archivo MANIFEST.MF del binario. El problema con esto es que para ver la versión de un binario, debes abrir el archivo y leer la versión del archivo MANIFEST. Si la versión se guardara ahí, simplemente seria muy complicado tener un repositorio de jars como los que hay de Maven en diversos lugares en internet. La critica del experto denota su ignorancia y sobre todo la mezquindad a aprender algo nuevo.

Al final del día, me agrado mucho no hacerme llamar “Consultor Pro”, o peor aún “Enterprise Architect”, soy feliz siendo Desarrollador de Software.