viernes, 25 de enero de 2008

Schema Update en Hibernate

Una de las funcionalidades que extrañaría mas si dejara de usar Hibernate es la capacidad de impactar el esquema de la base de datos en forma incremental y automática. Afortunadamente, nos podemos centrar en crear las entidades de negocio como POJOS, con sus atributos y relaciones sin tener la necesidad de crear manualmente las tablas, todo ésto mediante la tarea Ant SchemaUpdate.

Por ejemplo cuando agregamos una nueva entidad al hibernate.cfg.xml o nuevos atributos/relaciones a una entidad existente, al ejecutar la tarea se realiza una comparación entre el esquema de la base de datos actual y el que se deduce a partir de los mappings de Hibernate con las modificaciones. Tomando en cuenta las diferencias, se ejecutan las sentencias SQL necesarias para sincronizar el modelo (básicamente CREATE TABLE ... y ALTER TABLE ...).

Debemos incluir en el build.xml el siguiente target:

<target name="schema.update" description="Update Schema" depends="build">
<taskdef name="schemaupdate" classname="org.hibernate.tool.hbm2ddl.SchemaUpdateTask"
classpathref="class.path">
<schemaupdate config="${conf.dir}/hibernate.cfg.xml"
quiet="no"
text="no">
</schemaupdate>
</taskdef>
</target>

Es importante aclarar que ésta herramienta no borra estructuras ya creadas, es decir no hace DROPS de tablas ni campos que hayan quedado sin usar, tampoco crea índices definidos por el programador (las restricciones de integridad referencial si las crea). La gente de Hibernate no lo considera un bug, según la documentación oficial, el SchemaUpdate está pensado para usarse en ambiente de desarrollo, se basa en la metadata que brinda el API JDBC, el cual no es consistente en todos los drivers. Como comentario, yo lo vengo usando desde hace tiempo sin problemas con MySQL, solo tengo en cuenta la restricción de los índices, los cuales creo manualmente.

Además de la tarea Ant, también es muy útil la opción para que el esquema se actualice automáticamente en el start up de la aplicación. En el hibernate.cfg.xml, mediante el property:
<property name="hbm2ddl.auto">update</property>

indicamos que la primera vez que se use la SessionFactory, ejecute las modificaciones a la base de datos, al igual que lo haría la tarea Ant. Ésta opción la uso mucho para las instalaciones en producción, en desarrollo uso Ant para no enlentecer los deploys.

Hasta el próximo post!

domingo, 20 de enero de 2008

Mucho más que solo programadores

El rol del programador se ha vuelto fundamental en el resultado final de las soluciones de software, muchas veces marca el rumbo seleccionando metodologías y tecnologías de desarrollo, sus responsabilidades no se limitan a "picar código", por eso su cotización está en alza.

Generalizando, podríamos identificar dos perfiles de programadores muy distintos:

Los que en cada proyecto intentan cambiar el esquema de desarrollo por las últimas novedades o frameworks mas allá de la relación costo/beneficio, además consideran la innovación como un fin en si mismo, no como herramienta para lograr la solución que el cliente necesita. Pueden quedar atrapados en la carrera de ratas.

Por otro lado están los que siguen haciendo las cosas como hace diez años y no les preocupa para nada las tendencias del mercado, consideran de que si el cliente no solicita la evolución es porque no lo necesita, hay una actitud pasiva que provoca un estancamiento tecnológico.

No se si es un tema de edad, pero me da la impresión de que cuando nos iniciamos laboralmente estamos mas cerca de la primera posición, queremos usar cuanta tecnología y "chiche" nuevo sale al mercado y nos desmotivamos si alguien no está de acuerdo.

Luego con los años empezamos a ser mas selectivos, tratamos de enfocarnos en implementar la lógica de negocio porque la mayoría de los desafíos técnicos ya están resueltos, se incorporan nuevas tecnologías solo si agregan valor, no por modas pasajeras. Aquí está el punto de inflexión, podemos permanecer en ésta posición de equilibrio o mutar al otro extremo, donde nos quedamos estancados tecnológicamente.

Un caso muy común es el de los programadores Cobol, luego de permanecer durante muchos años en la misma plataforma, se encuentran en la situación de que las empresas en dónde trabajan comienzan a migrar sus sistemas hacia otras arquitecturas menos costosas. Reciclar a esos profesionales es muy difícil, pasar del esquema procedural monolítico al mundo dinámico de la orientación a objetos y de las tecnologías web requiere un cambio de cabeza importante.

Por eso mas allá de los conocimientos técnicos sobre una determinada tecnología, creo que lo mas importante es que podamos adaptarnos a las distintas situaciones sobre la marcha y además evitar quedar presos en el fanatismo tecnológico.

Hasta el próximo post!

martes, 15 de enero de 2008

Isolation Level en Hibernate

El isolation level o nivel de aislamiento es una de las configuraciones a nivel de base de datos que en ocasiones olvidamos establecer.
Podríamos decir que determina la forma en que los datos son "lockeados" o aislados de otros procesos mientras son accedidos, es decir, define como y cuando los cambios realizados por una transacción son visibles por otras operaciones concurrentes, influyendo en las siguientes anomalías:

Dirty Reads: Ocurre cuando una transacción lee datos modificados por otros procesos concurrentes que aún no han realizado commit, por eso se la denomina lectura sucia.

Nonrepeatable Reads: Ocurre cuando dentro de una transacción se lee el mismo registro mas de una vez y los datos obtenidos son diferentes, seguramente porque otro proceso concurrente los actualizó.

Phantom Reads: Ocurre cuando en una transacción ejecutamos el mismo query mas de una vez y obtenemos distintos resultados, por ejemplo si otra transacción agregó nuevos registros que satisfacen el criterio de búsqueda de la consulta.

El estándar ANSI/ISO SQL define cuatro niveles de aislamiento:

READ UNCOMMITTED: Permite que se produzcan Dirty Reads, Nonrepeatable Reads y PhantomReads. Es la opción menos restrictiva, recomendable si se manejan datos de solo lectura o muy pocas actualizaciones.

READ COMMITTED: Evita Dirty Reads, pero permite que se produzcan Nonrepeatable Reads y Phantom Reads.

REPEATABLE READ: Solo permite que se produzcan Phantom Reads.

SERIALIZABLE: Evita todos los casos anteriores, es la opción mas restrictiva.

Cada manejador de base de datos tiene su forma de configurar el isolation level a través de un administrador gráfico o por línea de comandos, por otro lado también es bueno aclarar que los productos difieren en los valores por defecto, por ejemplo en MySQL el default es REPEATABLE READ, en cambio en Oracle y SQL Server es READ COMMITTED.

Si usamos Hibernate como framework de persistencia podemos usar el property "hibernate.connection.isolation" en el hibernate.cfg.xml. Por ejemplo, para establecer la estrategia READ COMMITTED usaríamos:

<property name="hibernate.connection.isolation">2</property>

Los valores posibles son los mismos que define la interface java.sql.Connection:

1: READ UNCOMMITTED
2: READ COMMITTED
4: REPEATABLE READ
8: SERIALIZABLE

Tener en cuenta la aclaración de la documentación oficial : "... note that most databases do not support all isolation levels". Ante la duda siempre lo mejor es hacer una prueba ejecutando dos transacciones en paralelo para verificar que tenemos el comportamiento esperado.

Hasta el próximo post!

viernes, 11 de enero de 2008

Identificación de entregables en Java

Es importante que los aplicativos en producción desplieguen en algún lugar visible su número de versión, de ésta forma cuando los usuarios reportan incidentes, podemos solicitar que incluyan el "Program-Version" para intentar reproducir el problema en nuestro ambiente de desarrollo.

Por ejemplo, en las aplicaciones web desarrolladas en Java siempre trato de incluir en el war (el componente que se instala en el servidor), un timestamp que sirva como clave de identificación de la versión y a la vez permita saber en que fecha fue generado.
Ésto lo resuelvo en la tarea ANT que empaqueta el war:


<tstamp><format property="hoy" pattern="yyyyMMddHHmmss" locale="en"/></tstamp>
<target name="make.war" depends="build">
<jar destfile="aplicacion.war" >
<manifest>
<attribute name="Manifest-Version" value="1.0"/>
<attribute name="Program-Version" value="${hoy}"/>
</manifest>
<fileset dir="${webapp.dir}"/>
</jar>
</target>

Como resultado, el war queda con un archivo llamado MANIFEST.MF con un formato clave=valor (Program-Version=20071218112500, si lo generé el 18 de diciembre de 2007 a las 11:25 de la mañana) dentro del directorio META-INF. Luego podré leerlo y mantenerlo en memoria desde un servlet, por ejemplo:

URL manifestURL = this.getServletContext().getResource("/META-INF/MANIFEST.MF");
Manifest mf = new Manifest(manifestURL.openStream());
Attributes attr = mf.getMainAttributes();
String programVersion = attr.getValue("Program-Version");
this.getServletContext().setAttribute("programVersion", programVersion);

y desde una página JSP podré desplegarlo simplemente usando un tag JSTL, por ejemplo:

<c:out value='${programVersion}'/>

Espero que les sea de utilidad, hasta el próximo post!

miércoles, 9 de enero de 2008

Publicidad Invasiva

Si bien la mayoría de los medios de comunicación han entendido que la publicidad invasiva no da resultados positivos, sino todo lo contrario, hay ocasiones que recurren a la misma.

Por ejemplo en las transmisiones de fútbol, se colocan avisos con audio que cubren casi la mitad de la pantalla y llegan a interrumpir jugadas de gol, lo único que logran es ganar el insulto de los televidentes.

Lo mismo está sucediendo con un canal de televisión local, en el medio de cualquier programa o película, colocan una promoción de varios segundos con sonido mas alto que el audio original, interrumpiendo el "clima" y la atención del momento. No se qué agencia les pudo haber recomendado esa estrategia publicitaria.

Otra cosa diferente es usar avisos contextuales, por ejemplo éste blog tiene incorporado el programa de Google llamado AdSense, que coloca anuncios de forma discreta y en lo posible relacionados con el contenido del texto. Es el mismo sistema que usa el diario El País y el Observador.

En mi opinión los medios de comunicación deberían evitar el uso de técnicas de publicidad invasiva, está demostrado que son contraproducentes, por algo empresas como Google van por otro camino.

Hasta el próximo post!

domingo, 6 de enero de 2008

La Viveza Criolla Rioplatense

No se bien donde y cuando nació el término, lo cierto es que la viveza criolla está enquistada en el Río de la Plata, léase Argentina y Uruguay.
Para los que desconocen el término, se refiere a una mezcla de picardía e ingenio para buscar el beneficio propio aprovechándose de los demás, siguiendo la línea del menor esfuerzo. Se la podría considerar una especie de "delincuencia intelectual".

Lo malo es que para muchos esa forma de proceder es una virtud o cualidad, hay una tendencia popular hacia la admiración de la viveza criolla, yo creo todo lo contrario, es un yunque que tenemos atado y no nos ha permitido crecer.

Borges la definió de la siguiente manera: "El argentino suele carecer de conducta moral, pero no intelectual; pasar por un inmoral le importa menos que pasar por un zonzo. La deshonestidad, según se sabe, goza de la veneración general y se llama viveza criolla"

Para citar un ejemplo local, hace un tiempo escuché a un productor rural que intentaba exportar carne de cordero a mercados muy exigentes como el coreano, el cual fue perjudicado por otro colega inescrupuloso que envió cortes de ovejas viejas intentando engañar a los compradores. Por algo seguimos estando lejos de los precios de exportación que logran Australia y Nueva Zelanda.
Afortunadamente en Uruguay son la minoría, pero esos casos aislados pueden cerrarnos muchas puertas.

También sucede en la informática, he escuchado casos de gente que tuvo problemas con su PC y al llamar al service, la única solución que propone el técnico es formatear el disco duro y reinstalar el sistema operativo, por lo que pasa un presupuesto totalmente desubicado aprovechándose del desconocimiento del cliente.

Por otro lado, para cerrar positivamente, quiero destacar la actitud de un artesano uruguayo que cuando un turista norteamericano le fue a pagar la compra, el primero le devolvió el dinero y le dijo algo así como: "It's 100 uruguayan pesos, not 100 dollars", en ese momento 1 dólar equivalía a 30 pesos uruguayos.

Ese es el tipo de comportamiento que deberíamos destacar e imitar, no a los que intentan usar el ingenio para estafar o sacar provecho de situaciones de poder.

Hasta el próximo post!

jueves, 3 de enero de 2008

Informáticos por vocación

Desde hace un par de años se está promoviendo al rubro informático como una opción de empleo seguro en el Uruguay, usando slogans como "desempleo cero".
Si bien los que nos desempeñamos laboralmente en las tecnologías de la información no nos podemos quejar y hay espacio para seguir creciendo, no me parece del todo acertado tratar de "venderle" a los jóvenes que estudiar informática es la salvación.

No quiero decir que no se deba estimular, me refiero a que no es bueno crear falsas expectativas, o al menos desmesuradas.
Además cuando elegimos una profesión hay que tener en cuenta otras cosas además de lo económico, por ejemplo: ¿estamos preparados para pasar 10 horas encerrados en una oficina frente a un monitor, programando sin parar porque no llegamos a la próxima entrega?

En mi trabajo anterior viví de cerca una experiencia que puede servir para ejemplificar. Como consecuencia de que no se conseguía la cantidad necesaria de personal calificado, se decidió tomar profesionales universitarios recién recibidos de otras áreas como ciencias económicas, comunicación y psicología para capacitarlos en tecnologías de desarrollo de software.

Mas allá de que algunos absorbieron los nuevos conocimientos rápidamente, muchos no se adaptaron a la exigencia que implica trabajar en una software factory y optaron por volver a su vocación inicial. Los programadores sabemos que por momentos se vive mucho estrés debido a que generalmente los clientes exigen tiempos de entrega muy ajustados.

Por eso me parece que sería bueno que aquellos que estén pensando en estudiar informática, tengan en cuenta que si bien las remuneraciones están por encima de la media y es muy probable que consigan trabajo aún antes de recibirse, hay que conocer la parte negativa, que pocas veces se publicita.

Evaluación de Sitios Web

Buscando material sobre aspectos a considerar en la evaluación de soluciones de software, encontré que el gobierno de Chile en el marco de un plan de gobierno electrónico, tiene publicada una guía para el desarrollo de sitios web.

En la misma incluye aspectos de usabilidad, accesibilidad y seguridad, entre otros.
Además de la guía, desarrollaron una serie de checklists muy prácticos que permiten verificar de manera ágil los elementos más importantes que debe cumplir un sitio web ante determinados estándares o exigencias.

Esperemos que Uruguay pueda empezar a dar pasos en ésta dirección para que haya un criterio uniforme en todas las reparticiones del estado.

Feliz año y hasta el próximo post!