Weblog de Fco. José Mulero

Just another blog ;)

Talend Open Studio y Log4j (II) febrero 17, 2016

Filed under: Sin categoría — fjmulero @ 10:22 pm

Tras un par desemanillas trabajando con Talend, he sufrido un par de problemas con respecto al logado de información que merece la pena compartir.

El primero, reside en que muchos componentes escriben directamente por la salida estándar o por la salida de error . ¿Qué problema ocasiona esto? pues que a la hora de trazar la ejecución de un job tienes que estar revisando tanto la salida estandar (el catalina.out en caso de estar corriendo los jobs como web services en tomcat) como los ficheros de logs que hayas configurado en el componente tInitLog4j. Para subsanar esto bastaría con un incluir un “proxy” en cada una de las salidas de modo que escriban la información que se envíen a ellas a los loggers pertinetes con su correspondiente nivel de log:

/**
* Con esta función pretendemos crear un objeto PrintStream que ademas de escribir en el flujo original deje registro en los ficheros de log
* @param originalStream Stream que estamso observando
* @param errorLog se trata de mensajes de error o estándares
* @return el nuevo PrintStream
*/
public static PrintStream logProxy(final PrintStream originalStream, final boolean errorLog) {
return new PrintStream(originalStream) {
public void print(final String message) {
// Seguimos enviando el texto al Stream original
originalStream.print(message);
if (errorLog) {
logger.error(message);
} else {
logger.info(message);
}
}
};
}

Para insertar el “proxy”:

System.setOut(logProxy(System.out, false));
System.setErr(logProxy(System.err, true));

Esta mejora se la he reportado en bcourtine para que la incluya en próximas versiones de tInitLog4j

El segundo problema al que me enfrenté fue el de sustituir todos los tLogRow que utilizábamos por tLog4j, dado que el componente tLogRow en la versión Open Studio no utiliza log4j para emitir los datos que por él pasan. El componente tLog4j no tiene el mismo “contrato” que tLogRow, básicamente no permite la utilización de esquemas complejos, y te obliga a escribir continuamente en el mensaje de log la concatenación de cada variable que quieras logar.

tLog4j

Para evitar esta ardua tarea decidí implementar mi propia versión de tLogRow de modo que pudiera sustituir todos los tLogRow por este nuevo componente sin necesidad de reescribir código. De ahí nació tLog4JRow, ya está disponible en Talend Exchange. Su uso es muy simple y tiene opciones muy similares a las de tLogRow, así que la transición de un componente a otro es inmediata

tLog4jRow

 

Y con esto y un bizcocho… doy por terminado este post

 

Talend Open Studio y Log4j febrero 7, 2016

Filed under: Sin categoría — fjmulero @ 9:00 pm

Disponer de un log detallado y ordenado es de vital importancia para el diagnostico y resolución de incidencias, sobre todo si hablamos de herramientas capaces de procesar datos de forma masiva como es el caso de un ETL. En este aspecto las versiones “Libres” de Talend dejan mucho de desear, dado que sólo dan soporte de manera oficial a herramientas como Log4j en las versiones empresariales o de suscripción [1]. Con respecto a esto, la comunidad [2] ha desarrollado algunos componentes para facilitar el uso de log4j, en su versión 1.2. Entre estos componentes destacan los desarrollados por Benoît Courtine [3], que permiten establecer el fichero de configuración de log4j, escribir mensajes, permitiendo elegir los distintos niveles de log, y añadir listeners para la captura de errores. En el proyecto-tutorial que proporciona [4], se pueden apreciar las distintas funcionalidades y casos de uso que ofrecen los componentes desarrollados.
Basándonos en las herramientas antes citadas y atendiendo un poco al sentido común, se detallan algunas buenas prácticas referidas a las políticas de logging en Talend:

  1. Utilizar sólo un tInitLog4j en el job principal y marcar la opción de bloqueo de configuración. La configuración de Log4j se realiza a nivel global del proceso Java y con esto evitaremos sobreescrituras por error de la configuración.
    init_log
  2. Incluir tLogCatcher y tStatCatcher en cada Job para capturar posibles excepciones y los tiempos de respuesta de cada componente. Es importante establecer los distintos niveles de log en cada uno de los componentes, por ejemplo, en tStatCatcher el nivel de log puede ser un debug o info, dado que esos datos son meramente informativos. Sin embargo en el caso del componente tLogCatcher interesa establecer un nivel de log más restrictivo como error o warning.
    log_catcher
  3. En el caso de utilizar Joblets, no será necesario establecer “catchers” dentro del joblet, si el job que lo invoca lo tiene ya definido. El código de los joblets es incrustado dentro de los Jobs que lo invocan y por tanto heredan determinados comportamientos. Cuando se utilizan invocaciones a subjobs, realmente se está invocando a otro job distinto y entre ambos no comparten código.
  4. Utilizar los componentes tWarn con los niveles de log correctos.  Los componentes tLog4j permiten una configuración bastante más “fina” de los mensajes de log , permitiendo incluso establecer los loggers a los que dirigir los mensajes

Enlaces de Interés
[1] https://www.talendforge.org/forum/viewtopic.php?id=44156
[2] https://www.talendforge.org/
[3] https://github.com/bcourtine/Composants-Talend-Open-Studio/tree/master/Logging
[4] https://exchange.talend.com/#marketplaceproductoverview:gallery=marketplace%252F1&pi=marketplace%252F1%252Fproducts%252F342%252Fitems%252F479

 

 

Diseñando Aplicaciones para BlackBerry mayo 6, 2012

Filed under: Sin categoría — fjmulero @ 6:02 pm

Después de haber abandonado el blog durante demasiado tiempo, volvemos abarcando nuevas inquietudes y objetivos. Este primer post tras el exilio, espero que sea el primero de una larga serie dedicada al desarrollo móvil, haciendo especial hincapié en el mundo BlackBerry.

Este primer post, intenta resumir los puntos más importantes a tener en cuenta a la hora de diseñar una aplicación en movilidad, a prioiri puntos bastante simples y lógicos, pero que desgraciadamente en muchas ocasiones se pasan por alto:

  1. Experiencia de usuario: Vital para el éxito o fracaso de nuestra aplicación. Aunque hagamos un desarrollo digno de la NASA, en cuanto a complejidad del desarrollo, podemos tener un estrepitoso fracaso, si hemos llegado a realizar una aplicación tan complicada, que hasta a nosotros mismos nos resulta difícil de utilizar. A continuación se desglosan algunos detalles a tener en cuenta:

    1. Debemos familiarizarnos con la plataforma: Los usuarios de un determinado tipo de terminal están habituados a las vistas, menús y acciones que ofrece de forma nativa dicha plataforma. Cosas tan simples como cambiar de sitio de un menú, o no permitir que al visualizar un número de teléfono se pueda realizar una llamada, tan solo sirven para empeorar la experiencia de usuario.
    2. Interfaz intuitiva y usable: Las pantallas deben invitar a usar la aplicación y facilitar su uso. Antes de empezar a “picar” una pantalla, debemos preguntarnos, qué podemos hacer para facilitarle el trabajo al usuario y trabajar en dicho aspecto.
    3. Control total para el usuario: El usuario debe tener el control de la aplicación el mayor tiempo posible y si no lo tiene, se le debe informar. Las acciones que invocan los usuarios se deben ejecutar, siempre que se pueda, en segundo plano sin bloquear el uso de la aplicación y si no hay más remedio, se deberá informar al usuario con un mensaje de cargando o similar.
    4. Control y notificación de errores: El usuario sólo debe ser consciente de aquellos errores que pueda subsanar o de aquellos que le impidan trabajar normalmente con la aplicación. Además si el usuario es capaz de subsanar un determinado error (por ejemplo un dato mal introducido en un formulario) se le debe facilitar dicha tarea en la medida de lo posible.
  2. Uso de APIs Nativas: Las APIs nativas de las distintas plataformas móviles suelen tener soluciones para los problemas más comunes que además van a estar mucho más testeados que cualquier desarrollo a medida. Por lo tanto que antes de empezar a desarrollar, siempre es bueno comprobar si las APIs ofrecen ya una solución a nuestro problema.
  3. Componentes nativos de interfaz: Debemos evitar en la medida de lo posible definir nuestros propios componentes. Los componentes por defectos ya suelen tener implementados los comportamientos nativos de la plataforma y son visualmente coherentes con el resto de aplicaciones.
  4. Dispositivos a soportar: De partida tenemos que tener claro los dispositivos y características sobre los que vamos a dar soporte. Las características más importantes a tener en cuenta son: versión de SO mínima compatible, resoluciones de pantalla, tipo de pantalla (táctil o no), teclado físico o virtual y tipo trackpad.
  5. I18N: La internacionalización siempre hay que tenerla en cuenta, sobre todo si queremos publicar nuestra aplicación en algún Market Place, por lo que cualquier usuario del planeta puede ser un cliente potencial.
  6. Patrones de diseño:Nunca hay que olvidarlos, siempre serán nuestros fieles compañeros en este mundillo. Los patrones más extendidos en movilidad suelen ser:
    • MVC: Patrón arquitectónico bastante extendido, que permite diferenciar cada parte de nuestra aplicación en función de su responsabilidad.
    • Command: Permite independizar el tiempo de petición y el de ejecución, y soluciona tareas muy comunes como los famosos Deshacer y Rehacer.
    • Observer: Permite implementar listeners de eventos, como por ejemplo capturar determinadas pulsaciones de teclado
 

Exitos y fracasos diciembre 9, 2010

Filed under: Miscelanea — fjmulero @ 11:03 pm

No hace mucho, un compañero de trabajo hacía hincapié en la necesidad de analizar cada uno de nuestros éxitos o fracasos con el objetivo de comprender cómo se ha llegado a una determinada situación, para intentar reproducirla o evitarla en un futuro. Tiene toda la lógica del mundo ¿verdad? Pues resulta curioso ver cómo volvemos a equivocarnos, una y otra vez en los mismos problemas…

Os invito a analizar el porqué de las distintas situaciones y cómo habéis llegado hasta ellas, intentad verlas desde otra perspectiva y veréis mucho más de lo que inicialmente visteis, os daréis cuenta de detalles que despreciasteis, y sobre todo, ganaréis experiencia y no dejéis que esta sea sólo un número en vuestro currículum.

 

El gestor de proyectos. Parte 1 diciembre 7, 2010

Filed under: Gestión — fjmulero @ 11:22 pm

Muchos nos aventuraríamos a dar una definición basada en los objetivos propios de la gestión  de proyectos y las responsabilidades que recaerían sobre este rol, pero a mi parecer es bastante más didáctico comenzar diciendo que NO debería ser un gestor proyecto.

Pues eso, un gestor de proyectos NO debería:

  • Ser un despachador de correo (o un brown dispatcher) Alguien que se ocupa simplemente de reenviar las peticiones del cliente al equipo de trabajo sin ningún tipo de intervención.
  • Ser un generador de problemas. Una persona que no identifica las prioridades del proyecto o que no detecta los problemas o riesgos reales del proyecto o que aporta problemas de su propia cosecha.
  • Ser un filtro paso de baja. O alguien que oculta información, ya sea al cliente o al resto del equipo de proyecto.
  • Utilizar las herramientas como un fin en sí mismas. Dedicar su trabajo a generar informes, gráficas y documentos sin preocuparse del fin o el contenido de los mismos.
  • Acaparar todas las responsabilidades o funciones dentro del proyecto. ¿O a caso el arquitecto, diseña edificios, pone ladrillos, encofra, echa perlita, te pone la grifería y gestiona la calidad de sus propios trabajos?
  • Asentir las peticiones de los clientes sin cuestionarlas ni valorarlas.

Estos son sólo algunos ejemplos, seguramente podréis enumerar muchas más cualidades de un mal gestor, pero como no es mi objetivo hurgar más en la yaga, y  además resulta ser un buen momento para hacer un descanso. Próximamente la secuela…

 

Indicadores… noviembre 23, 2010

Filed under: Gestión — fjmulero @ 4:21 pm

Después de haber revisado hoy una serie de indicadores referentes al soporte de una aplicación y haber tenido una reunión sobre la utilidad de los mismos, uno se da cuenta de cómo el ser humano tiene el don de reiventar la rueda una y otra vez y de tropezar con la misma piedra varias veces.

Los indicadores no son más que una herramienta que nos ayuda a conocer de forma simplificada el estado de algo y  que consecuentemente nos facilita la  toma de decisiones. Esto es algo muy estudiado desde antiguo, por ejemplo, los mercaderes fenicios en el siglo V a.C. tenían claramente definidos sus indicadores de interés: número de mercancias, tiempo que necesitaban para reponerlas, precios de venta al público, costes, etc. Teniendo en cuenta este hecho, la primera disciplina que probablemente haya hecho uso indicadores haya sido la contabilidad.

La contabilidad es la disciplina que más ha madurado el uso de indicadores para la gestión, y por lo tanto utilizaremos los objetivo propios de la contabilidad y los intentaremos extrapolar, uno a uno, al mundo de los servicios  y sus indicadores.

Objetivos generales de la contabilidad:

  1. Ayudar a la toma de decisiones económicas
  2. Ayudar a conocer datos financieros que evalúen la recuperación de las inversiones.
  3. Ayudar al conocimiento de los activos y pasivos de una empresa y de los cambios en los mismos.

Objetivos generales de los indicadores de un servicio de soporte:

  1. Ayudar a la toma de decisiones. Sin lugar a dudas.
  2. Ayudar a las partes interesadas a conocer el estado del servicio. Nótese que “parte interesada” no tiene porqué ser sólo el cliente del servicio, los propios proveedores del servicio son los primeros interesados en conocer el estado de los servicios ofertados, si su servicio no es bueno, no habrá clientes que lo soliciten.
  3. Ayudar a conocer los elementos que componen el servicio (personas, herramientas, proveedores, etc) y cómo los cambios en los mismos afectan a la prestación del servicio.

A continuación se exponen los objetivos cualitativos de la contabilidad. Estos son directamente  aplicables a los indicadores referentes a la prestación de un servicio:

  1. Relevancia. Información útil al mayor número de usuarios posible. Hay que dedicar esfuerzo a aquellos indicadores que realmente nos aporte información útil, para ello habrá que analizar los requerimientos de información de las partes interesadas.
  2. Objetividad. Que no induzca a la toma de decisiones sesgadas. Los indicadores deben mostrar la realidad y no lo que nosotros queremos ver o lo que queremos hacer que otros vean.
  3. Comparabilidad. Los resultados de un informe deben ser comparables con otros anteriores del mismo servicio o con informes de servicios similares. En definitivas cuentas, los métodos de cálculo de los indicadores deben estar claramente definidos y deben sufrir las mínimas variaciones posibles a lo largo del servicio, de nada sirve disponer de 5 informes de cumplimiento de SLA cuando en cada informe los tiempos de respuesta se han calculado con criterios distintos.
  4. Claridad. Los indicadores deben ser comprensibles por las partes interesadas y han de estar claramente definidos.
  5. Periodicidad. Un servicio ha de ser evaluado contínuamente, por lo que los indicadores han de ser calculados con una periodicidad definida.

Para conseguir estos resultados la contabilidad propone los siguientes pasos a seguir:

  1. Seleccionar los indicadores de interés para todas las partes interesadas. Por ejemplo, para un servicio de soporte, necesitamos conocer los tiempos de respuesta y cómo los vamos a calcular.
  2. Interpretar o definir los posibles resultados de los indicadores. Por ejemplo, interpretaremos como bueno o muy bueno un tiempo de respuesta inferior a la hora para incidencias catalogadas como graves.
  3. Registro de información. Una vez que se conoce qué queremos medir y cuál es el objetivo, necesitamos guardar esos datos. Esta fase, aunque parezca automática y trivial, es bastante importante dado que va a condicionar los sucesivos puntos y consecuentemente las personas involucradas deben ser conscientes de su importancia y deben conocer perfectamente sus tareas y responsabilidades.
  4. Interpretación de los  resultados concretos. Por ejemplo, los tiempos de respuesta exceden los límites establecidos en el punto 2, debido a la complejidad del software utilizado para la gestión y notificación de incidencias.
  5. Toma de decisiones. Basándonos en el ejemplo del punto anterior, una decisión posible podría ser:
    1. Invertir en formación sobre la herramienta utilizada
    2. Mientras se adquiere el conocimiento oportuno, se utilizará el teléfono para reportar y tratar incidencias.

Resumiendo y a modo de conclusión, porque creo que ya me he explayado los suficiente, simplemente recordar  esa frase del principio “el ser humano tiene el don de reiventar la rueda una y otra vez y de tropezar con la misma piedra varias veces”. La gestión ya ha sido muy estudiada y precisamente los ingenieros o los informáticos no somos los primeros en descubrirla, hay muchas disciplinas como la contabilidad o las finanzas que por su definición, nacieron para gestionar, sería un error desperdiciar u obviar ese conocimiento tan ampliamente desarrollado.

 

Notifica 1.0.1 marzo 11, 2010

Filed under: Software Libre — fjmulero @ 11:07 pm

Notifica es un producto para el gestor de contenidos Plone, que nació tiempo atrás para satisfacer las necesidades de notificación de contenidos por email que requería el portal del Ayuntamiento de Lepe, con el objetivo de informar a todos aquellos ciudadanos que lo deseen de las últimas novedades de su ciudad. Gracias a aquel proyecto, también se liberó otro producto para Plone, Meteo, que permite incluir información meteorológica en un portal web consultando la web de la Agencia Estatal de Meteorología.

Esta nueva versión de Notifica incluye la resolución de algunos bugs asociados a la internacionalización del producto y se han incluido traducciones a los siguientes idiomas:

  • Inglés
  • Español
  • Francés
  • Holandés

PD: Thanks Fabrice for your contribution, this version could not be released without your collaboration.

 

 
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.