Month: September 2006

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.

Como mencionaba hace un par de post, me toco estar como speaker en el SG ’06, por parte de la Comunidad Java de México. El día lo tuve muy apretado, estuve revisando varias cosas y ademas algunas reuniones un tanto difíciles de afrontar, me refiero a que me costo algo de trabajo poderme comunicar adecuadamente, en fin. Me fui temprano de la oficina, de hecho sali con el tiempo justo para llegar al WTC de la Ciudad de México.

La charla estaba programada para iniciar a las 18:00, llegue y me registre como a las 17:55, con el tiempo justo me fui corriendo a la sala, pero nada, estaba cerrada y no nadie me podía decir que pex. A los cuates de SG, les fallo ahí un poco la organización. Por suerte mi cuate el Juanelo llego a buena hora, según el no iba a poder llegar a la reunión.

Estuvimos platicando un rato y se nos acerco un cuate que trabaja en Praxis, posiblemente Praxis en el futuro se interese en patrocinarnos una reunión. Al margen de esta platica entre Juanelo, el cuate de Praxis y yo, se nos unió una chava, de un tecnológico en Morelos, a esta chava le interesa que vayamos a su tecnológico a dar unas charlas sobre Java, ademas de que posiblemente se habrá un capitulo de javaUp en dicho tecnológico.

En fin, le estuve llamando al buen Enrique Montes para ver que onda, a que hora podía comenzar, así que como a eso de las 18:45 puede empezar la charla. Me presento Juanelo y me arranque de mi ronco pecho, y es que si estaba ronco. En fin, empece la charla y entre los asistentes me encontré con el buen Gustavo Arellano.

Por sus gestos parece que no le gusto mucho lo que dije en la charla, sobre todo la parte de que no implementes tu propio framework y que no uses EntityBeans. Al final de la charla nos invitaron a un casino que Software Guru puso para los invitados.

Ahí se me acerco Gustavo y estuvimos un rato charlando, sobre todo de los entity beans, el me cuenta que hizo algunas clases base de las cuales heredan todos sus entity beans y sus session beans, ademas de que el hizo su propio Struts.

No se, bueno a el lo conozco desde hace tiempo y de hecho el me enseño mucho a través de los seminarios que dada, cuando estaba en Siga, pero el que hagas tu propio framework web, no se. El es muy capaz, pero no creo que sea “mejor” que Struts, bueno eso de mejor es muy subjetivo, si al le funciona para el es mejor que Struts. Me gustaría tener una charla con Gustavo para debatir sobre el uso de EntityBeans contra algún otro mecanismo de persistencia como Hibernate, iBatis, incluso la capa de abstracción de JDBC de Spring. Le mandare un mail para ver como se pone esto.

Yo jamas en la vida vuelvo a hacer algún framework, reutilizare alguno mas, como el caso de Spring, ese si es un gran framework, muy fregon y con mucho futuro.

Y tu, ¿desarrollas tu propio framework?

Nota:
Cada una de mis menciones de Entity Beans de este post es sobre la especificación 2.1 e inferior. La 3.0 esta muy chida.