{ Programando }

Administración de log en Alfresco Community II

2011-09-13T13:30:00.000-07:00

En el anterior post hable sobre LogRefresher un proyecto que incluye la posibilidad de administrar las trazas de log en Alfresco Community.

En este post explicare como se realiza la magia de refrescar la configuración de log4j en momento de ejecución, para hacer esto utilizamos el sistema de carga de recursos de Spring y siguiendo la documentación de Alfresco de como realiza la lectura de la configuración de log4j. El refresco de las trazas de log se implementa en la clase

“es.binovo.ag.utils.LoggerManagerImpl”, en el contexto Spring de Alfresco Explorer se declara la instancia con el id “log.alfresco.managerLogger” y “log.share.managerLogger” en Alfresco Share.

Por lo que si queréis cambiar la manera como se recargan las configuraciones de log solo tenéis que sobrescribir los beans ;)

Administración de log en Alfresco Community

2011-09-02T04:56:00.000-07:00

Bueno tengo mucho tiempo sin escribir, estos últimos meses he estado muy ocupado, pero este no es el tema de este post.
Llevo un tiempo trabajando con Alfresco community, para los que no lo conozcan es un ECM open source, existen dos versiones del producto, la versión community y la enterprise, la diferencia entre las dos, es que la versión enterprise posee soporte técnico, administración por MBean y otras cosas que la versión community no tiene.
Una de las cosas que echaba mucho falta en la versión community, es la administración por JMX, sobre todo el poder cambiar el nivel de log en momento de ejecución sin tener que reiniciar el contenedor de aplicaciones, parece una tontería pero cuando las cosas no van como quieres y NO puedes reiniciar el contenedor, el poder hacer esto en caliente se agradece y mucho, en la empresa donde trabajo (Binovo IT Human Project) hemos tenido este problema, por eso hemos querido invertir unas horas en crear una herramienta que permita realizar esto en la versión community y lo mejor de todo es que la hemos liberado a la comunidad de Alfresco.
El proyecto se llama LogRefresher y esta alojada en la forja de alfresco, allí podéis descargar los amp's de instalación y el código fuente, en un próximo post explicare mas sobre el proyecto.

iCalendar (II)

2010-11-16T13:25:00.000-08:00

En la entrada anterior sobre iCalendar, trate de explicar los principales elementos de un archivo iCalendar, en esta entrada explicare como describir eventos periódicos.

Eventos periódicos

Los eventos periódicos son eventos que no poseen una fecha de inicio o final concreta, si no una regla descriptiva. Este tipo de eventos la mayoría de las veces son explicados de formas como “este evento se repite el tercer sábado de cada mes”, “el evento X se repite cada 4 días 10 veces” o “el eventos se repite el ultimo día de la semana de cada mes”. Si desea ver un ejemplo mas claro de esto, trate de crear un evento periódico en Google Calendar (aqui tiene una explicación de como hacerlo) y si desea ver muchas mas opciones (pero no todas) de iCalendar le recomiendo que lo haga en MS Outlook.

Este tipo de eventos se declaran en iCalendar con la propiedad RRULE del componente VEVENT, a esta propiedad se le debe añadir la información de frecuencia de la regla, en función de la frecuencia deberemos suministrar días, meses, intervalos, etc. Veamos uno ejemplo para poder entenderlo mejor

RRULE:FREQ=DAILY;COUNT=10;INTERVAL=4

Con esta regla estamos indicando que este evento posee una frecuencia diaria (FREQ), con intervalo (INTERVAL) de 4 días (note que el intervalo esta en función del tipo de frecuencia, el valor por defecto es 1) y se repetirá 10 veces (note la propiedad COUNT).

Veamos otro ejemplo esta vez crearemos una repetición de tipo semanal

DTSTART:19970902T090000
RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

En esta regla estamos indicando una frecuencia semanal que inicia el 02/09/1997 09:00 y termina el (UNTIL) 24/12/1997 00:00

Esta regla se ejecutara los días:

2, 9, 16, 23 y 30 de septiembre

7,14, 21 y 28 de octubre

4, 11, 18 y 25 de noviembre

2,9,16 y 23 de diciembre

Los tipos de frecuencia que se puede indicar en la propiedad RRULE son:

SECONDLY: Utilizado para repeticiones con intervalos de segundos
MINUTELY: Utilizado para repeticiones con intervalos de minutos
HOURLY: Utilizado para repeticiones con intervalos de horas
DAILY: Utilizado para repeticiones con intervalos de días
WEEKLY: Utilizado para repeticiones con intervalos semanales
MONTHLY: Utilizado para repeticiones con intervalos mensuales
YEARLY: Utilizado para repeticiones con intervalos anuales

Según la frecuencia que indique tendrá que suministrar una información u otra, por lo que si desea profundizar en este tema lea la sección 4.3.10 del RFC 2445.

Modificaciones de instancias en eventos periódicos

En el apartado anterior explicamos como declarar eventos periódicos en un iCalendar, este tipo de eventos a pesar de declarar un solo evento generan varios eventos (instancias de eventos) que pertenecen a la definición de la periodicidad, dichas instancias pueden sufrir modificaciones en sus propiedades, cuando esto ocurre debemos indicar las propiedades que se modifican y sobre que instancia o instancias de eventos se deben aplicar.

Tomemos la ultima periodicidad de ejemplo:

DTSTART:19970902T090000
RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

Recodemos que esta periodicidad generaba las siguientes instancias de eventos:

2, 9, 16, 23 y 30 de septiembre

7,14, 21 y 28 de octubre

4, 11, 18 y 25 de noviembre

2,9,16 y 23 de diciembre

Ahora imagine que el usuario desea pasar la instancia de evento que se ejecuta el 16 de septiembre al 15 de septiembre del mismo año, en nuestro archivo iCalendar debemos especificar ese cambio creando una nueva definición de evento (un componente VEVENT) indicando que instancia de la periodicidad sustituye. Veamos un ejemplo:

BEGIN:VEVENT

...

UID:

SEQUENCE:

DTSTART:19970902T090000

RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

END:VEVENT

(Definimos la periodicidad)

BEGIN:VEVENT

...

UID:

SEQUENCE:

RECURRENCE-ID:19970916T090000//Fecha de la instancia que se modifica

DTSTART:19970915T090000 //La nueva fecha de la instancia

END:VEVENT

(Declaramos la modificación de una instancia)

En este ejemplo el primer evento declara la periodicidad, con la regla de repetición que se debe aplicar y en la segunda definición de evento se indica, que el evento sustituye a la instancia con fecha 16/09/1997 de la periodicidad que posee el identificador y numero de revisión indicados por las propiedades UID y SEQUENCE respectivamente.

Eliminar instancias en eventos periódicos

Para eliminar una o varias instancias de un evento periódico, solo tenemos que indicar las fechas separadas por comas en la propiedad EXDATE del componente VEVENT donde declaramos la definición de la repetición.

Volvamos a tomar el ejemplo anterior, pero esta vez no modificaremos la instancia de fecha 16 de septiembre sino que la eliminaremos.

BEGIN:VEVENT

...

UID:

SEQUENCE:

DTSTART:19970902T090000

RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

EXDATE:19970915T090000

END:VEVENT

iCalendar (I)

2010-11-09T12:44:00.000-08:00

iCalendar es un estándar para el intercambio de información de eventos, tareas y reuniones de calendarios, el estándar está descrito en el RFC 2445 y se complementa con el RFC 2446.

En el RFC2445 se detalla la manera cómo se debe plasmar la información de eventos, tareas y reuniones para que puedan ser interpretados por igual en distintos clientes de calendarios; gracias a esto, Google Calendar puede interpretar los calendarios de iCal y viceversa.

Como se pueden imaginar, analizar de manera detallada estos documentos en un blog es una locura, por eso, en esta serie de artículos sólo hablaré sobre el RFC2445.

Antes de empezar, me gustaría aclarar la diferencia de 2 conceptos que aparecen mucho en el RFC2445: “componente” y “propiedades; Las diferencias entre estos dos conceptos son muy simples:

Un componente puede anidar otros componentes.
Un componente puede contener propiedades.
Los componentes inician con el prefijo BEGIN y terminan con el prefijo END

ejemplo:

BEGIN:

...

END:

Bueno, comencemos con el componente raíz de un iCalendar.

Componente VCALENDAR

Es el elemento raíz de un iCalendar. En él, se describen las características de un calendario como pueden ser la zona horaria, la versión del estándar iCalendar utilizado, el identificador del productor (PRODID), etc..

Los propiedades más importantes son:

PROID : Especifica el ID del programa que ha producido el iCalendar, el formato de esta propiedad suele ser “-//NOMBRE_EMPRESA/IDENTIFICADOR_APP//EN”, si desea una mejor explicación y esta dispuesto a pagar por ella lea la ISO _9070.
VERSION: Especifica la versión de iCalendar utilizada, el valor “2.0” es el valor utilizado por el RFC2445.
CALSCALE : Indica el tipo de calendario, “GREGORIAN” es el valor por defecto e indica que el calendario es de tipo gregoriano.
X-WR-CALNAME: No es una propiedad estándar (las propiedades y componentes no estándar empiezan con el prefijo “X-”) pero es utilizada por MS Outlook y Google Calendar para indicar el nombre del calendario.

De los componentes de iCalendar, el componente VCALENDAR es uno de los mas sencillos, con dar valor a estas propiedades ud ya ha suministrado la información mínima para que un cliente iCalendar pueda entender la información de los eventos, tareas y reuniones que puede contener un componente VCALENDAR.

Ejemplo:

BEGIN:VCALENDAR

PRODID:-//Acme company//Acme Calendar x.y.z//EN

VERSION:2.0

CALSCALE:GREGORIAN

X-WR-CALNAME:Nombre de calendario

...

END:VCALENDAR

NOTA: Existen iniciativas que utilizan el estándar iCalendar para realizar otras operaciones distintas al intercambios de eventos, por ejemplo, tzurl .org utiliza el componente VCALENDAR para suministrar información actualizada sobre las zonas horarias mundo.

Componente VEVENT

Es un componente contenido dentro de un VCALENDAR, la finalidad de este componente es suministrar información de un evento, como pude ser el lugar, la fecha y hora de inicio y final, lógica de repetición, etc...

Las propiedades mas importantes:

SUMMARY: Descripción corta del evento (esta información es suministrada por el usuario en una aplicación de calendario).
UID: Identificador único del evento dentro del calendario
TZID: Identificador de la zona horaria.
CREATED: Fecha en la que fue creado el evento (no confundir con la fecha del evento)
LAST-MODIFIED:Fecha de la ultima molificación de este evento.
DESCRIPTION: Descripción del evento (esta información es suministrada por el usuario en una aplicación de calendario).
DTSTART: Fecha/Hora en la que se produce el evento, por defecto se debe suministrar el valor de fecha/hora en el formato UTC que se describe en el ISO 8601
DTEND:Fecha/Hora o en la que se produce el evento, por defecto se debe suministrar el valor de fecha/hora en el formato UTC que se describe en el ISO 8601
SEQUENCE: Numero de revisión del evento, es un secuencial que describe las modificaciones que se realizan sobre el evento

Ejemplo de un evento simple:

BEGIN:VEVENT

SUMMARY:Evento simple

UID:ACME-02882072aecb5d3012aeccadYYYYYYY

SEQUENCE:0

TZID:Europe/Madrid

CREATED:20100831T220000Z

LAST-MODIFIED:20100831T220000Z

DESCRIPTION:Comentario del evento

LOCATION:Lugar

DTSTART:20100901T172200

DTEND:20100901T185200

END:VEVENT

En este ejemplo se define un evento con zona horaria “Europe/Madrid” y el evento inicia el 01/09/2010 17:22 y termina el 01/09/2010 18:52

Eventos de todo el día

Los eventos de todo el día se debe indicar solo la fecha de inicio (DTSTART) con un valor de fecha, con un ejemplo se entiende mejor

BEGIN:VEVENT

DTSTAMP:20100907T152733Z

SUMMARY:Evento todo el dia

UID:ACME-402882072aecb5d3012aeccf00XXXXX

SEQUENCE:0

TZID:Europe/Madrid

CREATED:20100906T220000Z

LAST-MODIFIED:20100906T220000Z

DESCRIPTION:Todo el dia ocupado

DTSTART;VALUE=DATE:20100907

END:VEVENT

Este es un ejemplo de un evento marcado como todo el día, la diferencia con el ejemplo anterior es muy sutil, este tipo de eventos no posee fecha de finalización (DTEND) y en su fecha de inicio (DTSTART) solo se indica la fecha de la forma DTSTART;VALUE=DATE:yyyymmdd.

Polimorfismo y rendimiento de JVM

2010-07-08T06:44:00.000-07:00

Estoy un poco aturdido con la información que acabo de leer, en http://www.javaspecialists.eu/archive/Issue157.html, en este articulo demuestran como el polimorfismo puede afectar al rendimiento de las aplicaciones, yo sabia que existía diferencias entre código que utiliza polimorfismo y el que no, pero nunca que pensé que la diferencia sería tan grande.
Tengo que admitir que a mí me ha impacto un poco leer esto, por que Java es un lenguaje OO y si quieres sacar el máximo provecho de ello se debe utilizar los conceptos de la POO (http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos) , tal vez soy un poco catastrófico pero la verdad me ha impactado mucho esto.

Nostalgia

2010-06-30T12:56:00.000-07:00

La semana pasada tuve un momento de nostalgia al encontrar esta aplicación para Android, es un emulador de la calculadora HP 48G, los que estudiamos ingeniería tenemos muchos recuerdos con esta calculadora, hay que decir que es un emulador muy bien logrado permite hacer todas las operaciones que se pueden hacer la calculadora o por lo menos las que probe.
Lo único negativo es el teclado que es muy incomodo como para usarlo como calculadora.

Editar horas en Flex

2009-08-20T05:24:00.001-07:00

Flex es un framework que facilita mucho el crear aplicación RIA con Flash, posee componentes muy personalizables y muy vistos, sin embargo no existe un componente para editar horas.

Pues buscando algo que facilite esto, me tope con esto (http://internetdeveloping.blogspot.com/2008/09/selector-de-hora-componente.html), es un venezolano que tiene este blog sobre desarrollo en internet muy bueno.

El infierno de CR4E.

2008-07-27T08:07:00.000-07:00

Hace un año en la compañía donde trabajo, se mi pidió que integrara la generación de reportes de nuestro producto con reportes de Crystal Reports XI, como yo había leído muchas veces que Crystal Reports era la mejor herramienta de reporting que existía, asumí que la integración seria algo sencillo y sin complicaciones, que equivocado estaba.

Mi primera sorpresa fue, el descubrir las diferencias que existen al ejecutar un reporte con el diseñador de Crystal Reports y con el API Java que suministran (CR4E). Una de las primeras diferencias que me encontré, era que cuando se ejecutaba un reporte con el API en java, todos los valores de la base de datos eran trimeados (se borraban los espacios en blanco de los extremos), esto trae como problema que si querías comparar valores entre tablas en alguna formula hecha en el reporte, se debía aplicar la función “Trim” sobre los valores a comparar. Muchos de Uds. Dirán que esto no es un problema serio, pues yo les digo que si lo es, la diferencia de ejecución de un reporte de Crystal Reports aplicando “Trim” a campos con otro que no lo haga es muy grande. Al parecer debido a las etapas de ejecución que se aplican antes de crear un reporte en Crystal Reports, al aplicar una función de tipo “Trim” en un campo hace que casi se duplique el tiempo de ejecución de un repote.

La segunda sorpresa fue el saber que si se definían dos subreportes con el mismo nombre, pero diferenciado por el “case” (cosa que no te limita hacer el diseñador de reportes) de una letra (ejemplo “Reporte”, “reporte”), en el diseñador de Crystal Reports funcionaba perfectamente, sin embargo cuando se ejecutaba con el API de Crystal Reports en java (CR4E) el reporte fallaba con un mensaje de error poco explicativo (“Report error”).

Mi tercera sorpresa y la más grande de todas fue, el tener que esperar casi un año (exactamente 10 meses) para que el equipo de soporte de “Bussines Objects” solventara este problema en su API de java.

Ahora se preguntaran ¿todo va bien?, pues no, ya salio la ultima versión de Crystal Reports, pero sorprendentemente el API de Cristal Reports para Java no soporta las ultimas novedades de la nueva versión…
En un mail que escribe a un responsable de Business Objects en España, en el que le comentaba todos los problemas que habíamos descubierto en el API de Cristal Reports en Java y además aproveche para preguntarle sobre el desarrollo del API en Java, este no supo contestar a mi última pregunta. Por lo que pensamos que este producto va a morir dentro de poco…

Conclusión

Debido a la diferencias al momento de ejecutar un reporte de Crystal Reports con el API de Windows y el API en Java, NO recomiendo que ningún desarrollo en java tome como solución de reporting al producto de Crystal Reports. Basándome en la respuesta obtenida por personal de Business Objects en España “creo” (no tengo información certera) que el desarrollo del API en Java será abandonado.