domingo, 27 de abril de 2008

Escribí tu currículum vitae en XML

La problemática

A lo mejor a alguno de ustedes le pasa como a mi, que odio escribir un CV en Word/Writer o cualquier otro procesador de textos que ande por ahí.

Así que la primera vez que tuve que escribir un CV, lo hice en HTML puro y estático. Esto mezclaba contenido con presentación, pero era bien simple y quedaba tal cual yo quería. El problema con los procesadores de texto es que uno nunca termina de saber exactamente qué es lo que pone internamente para darle el formato y a veces es difícil lograr el formato deseado.

XML al rescate

Cuando trabajaba en Zauber me mostraron el xmlresume, que permitía escribir el CV en un archivo xml y luego procesarlo para presentarlo en formato HTML o PDF según se requiriera.

Como xmlresume parece no tener más soporte desde hace tiempo, decidí cambiarme a otro y es así como actualmente utilizo hr-xsl.

Cual de los dos utilizar es realmente una cuestión de gustos, porque hr-xsl tampoco parece estar muy activo hoy en día, pero bueno, ya me amoldé a este último y les quiero compartir la forma en que yo lo utilizo.

Cómo uso hr-xsl

Tengo todo el programa para generar el CV en un repositorio de Subversion propio con la siguiente jerarquía de carpetas (y algunos comentarios):
.
|-- bin // aca está el soft de hr-xsl
| |-- HRXML
| | `-- HRXML200704
| | `-- HR-XML-2_5
| `-- hr-xsl
| `-- hr-xsl-0.11
|-- releases
| |-- 1.0.0-pre-xml // esto era en HTML
| | |-- 2005-03-31
| | |-- 2005-12-21
| | |-- 2007-03-20
| | `-- 2007-04-03
| |-- 2.0.0-xmlresume-zauber // esto era xmlresume
| | `-- 2007-05-07
| `-- 3.0.0-hr-xsl // este es el actual, hr-xsl
| |-- 2007-09-04
| |-- 2008-01-14
| `-- 2008-04-16
`-- trunk
|-- .project // proyecto de eclipse (lo edito con eclipse)
|-- generator-en // scripts de ant para construir el CV en ingles
| |-- build.xml
| `-- parameters.xsl
|-- generator-es // scripts de ant para construir el CV en español
| |-- build.xml
| `-- parameters.xsl
`-- src
|-- currVitae.htm // html con frames que encuadra la presentacion
|-- epereda-en.html // autogenerado html en inglés
|-- epereda-en.pdf // autogenerado pdf en inglés
|-- epereda-en.txt // autogenerado texto en inglés
|-- epereda-en.xml // codigo fuente del cv en inglés
|-- epereda-es.html // autogenerado html en español
|-- epereda-es.pdf // autogenerado pdf en español
|-- epereda-es.txt // autogenerado texto en español
|-- epereda-es.xml // codigo fuente del cv en español
|-- style.css // hoja de estilos para el html
`-- top.html // frame superior con links a las diferentes versiones


La idea es que edito lo que está en la carpeta trunk/src usando Eclipse (obviamente se puede editar con lo que quieran, pero yo estoy acostumbrado a usar Eclipse). Luego corro los scripts de ant localizados en trunk/generator-en y trunk/generator-es y cuando estoy contento con el resultado de los archivos generados hago una copia a la carpeta de releases/3.0.0-hr-xs con la fecha actual.

Requerimentos de hr-xsl

Los requerimentos de hr-xsl están detallados en la documentación del sitio oficial, pero se resumen en lo siguiente:

  • Java 5.0 o superior

  • Ant 1.6 o superior

  • Lynx: sólo si se quiere generar archivo .txt



Decargar fuentes

Pueden descargar mi código fuente desde acá. Es posible que sea lento porque la conexión de internet de ese server no es muy buena.

La idea de brindarles el código fuente es que a lo mejor les es útil basarse en él para hacer su propio CV.

Resultado final

El producto terminado puede verse acá: epere4.com.ar/cv

domingo, 20 de abril de 2008

¿Cómo funciona synchronized en Java?

Mucha gente que usa Java no tiene claro cómo funciona realmente la palabra clave synchronized. Voy a intentar explicarlo acá porque es realmente muy fácil si se tienen en cuenta algunas cosas.

En primer lugar, usar synchronized en un método de instancia es lo mismo que poner un bloque de synchronized(this){} que contenga todo el código del método. Es decir,
public synchronized void metodo() {
   // codigo del metodo aca
}
es lo mismo que
public void metodo() {
   synchronized(this) {
      // codigo del metodo aca
   }
}
Si el método es de clase entonces es lo mismo pero el bloque de synchronized se aplica a la clase. Ejemplo, si el método está en la clase MiClase entonces esto
public static synchronized void metodo() {
   // codigo del metodo aca
}
es lo mismo que
public static void metodo() {
   synchronized(MiClase.class) {
      // codigo del metodo aca
   }
}


Habiendo dicho esto, el problema se reduce a entender cómo funciona el synchronized de un bloque porque, como vimos, el synchronized en métodos de instancia o de clase son simplemente casos especiales de esto.

El bloque synchronized lleva entre paréntesis la referencia a un objeto. Cada vez que un thread intenta acceder a un bloque sincronizado le pregunta a ese objeto si no hay algún otro thread que ya tenga el lock para ese objecto. En otras palabras, le pregunta si no hay otro thread ejecutando algun bloque sincronizado con ese objeto (y recalco que es ese objeto porque en eso radica la clave para entender el funcionamiento)
Si el lock está tomado por otro thread, entonces el thread actual es suspendido y puesto en espera hasta que el lock se libere. Si el lock está libre, entonces el thread actual toma el lock del objeto y entra a ejecutar el bloque. Al tomar el lock, cuando venga el proximo thread a intentar ejecutar un bloque sincronizado con ese objeto, será puesto en espera.
¿Cuándo se libera el lock? Se libera cuando el thread que lo tiene tomado sale del bloque por cualquier razón: termina la ejecución del bloque normalmente, ejecuta un return o lanza una excepción.

Es importante notar una vez más que el lock es sobre un objeto en particular. Si hay dos bloques synchronized que hacen referencia a distintos objetos (por más que ambos utilicen el mismo nombre de variable), la ejecución de estos bloques no será mutuamente excluyente.

Conclusiones:

De todo esto se puede concluir que un método synchronized de instancia puede ser ejecutado al mismo tiempo que uno de clase.
Además, dos threads pueden ejecutar el mismo método de instancia al mismo tiempo aunque este sea synchronized si la invocación se hace a dos objetos diferentes.
Por último, todos los métodos synchronized de instancia son mutuamente excluyentes entre sí. Es decir que, dado un objeto compartido por más de un thread, sólo uno de ellos puede acceder en un determinado momento a uno de esos métodos de instancia. Los otros threads deberán esperar aunque hayan querido acceder a otro de los métodos (porque todos están synchronizados con el mismo this).

Puede encontrarse mucho más info del tema en este tutorial de sun (en inglés).