Y, sin embargo, lo es. El modo en el que Glassfish trabaja con logs es peculiar y guarda algún oscuro secreto.  Sólo te pido dos cosas:

1. 1. Cinco minutos de tu tiempo para que juzgues si lo he conseguido.
   2. Que, para vivir una experiencia completa, escuches la canción ‘Old Souls‘ de la banda sonora de Origen mientras lees el artículo.

Lo peor que te puede pasar es que salgas de aquí aprendiendo algo nuevo y, por supuesto, siempre puedes tirarme tomates virtuales en los comentarios del artículo.  ¿Te animas?

EL MISTERIO DE LAS TRAZAS INEXPLICABLES

Como parte de mi asedio y conquista al entorno de trabajo de STORETTO, comencé a estudiar nuestro sistema de traza y la configuración del mismo. Parecía algo relativamente sencillo (una configuración típica de log4j) Sin embargo, algo no encajaba. Ni las trazas aparecían por donde debían ni tenían el formato que queríamos. Nada se parecía ni remotamente a lo que teníamos configurado.

Tampoco entendía por qué el equipo de STORETTO había configurado el sistema de log4j habitual de la compañía mediante una variable de sistema, en vez de colocar el fichero de configuración en el classpath de la aplicación.

¿Qué estaba pasando? ¿Era todo esto real o era un sueño? ¿Estaba soñando dentro de un sueño? ¿Cómo distinguir la realidad del sueño?

Como en el anterior caso de las JSPX desestructuradas, yo tenía un poco más de tiempo disponible que el equipo para comprender qué estábamos haciendo y por qué lo estábamos haciendo. Lo que averigüé fue SORPRENDENTE.

FRAMEWORK DE LOGGING DE GLASSFISH

Antes de nada, era importante conocer qué sistema de registro de trazas utiliza Glassfish y cómo funciona el mismo.

He resumido todo lo que se necesita saber en un par de párrafos:

Glassfish utiliza para su sistema de trazas la implementación por defecto de la especificación JSR-047, una API de logging, y recomienda el uso de la misma, aunque permite el uso de otras como Apache Commons Logging o log4j.

El uso de la API de logging del JDK implica varias cosas a tener en cuenta:

1. Se basa en un sistema de Handlers, clases que heredan de java.util.logging.Handler y que son los que encapsulan tanto la lógica de publicación de trazas como la configuración de las mismas.
2. Estableciendo un level o nivel por Handler podemos establecer el nivel mínimo de traza que queremos que recoja el HANDLER. Estableciendo un nivel determinado se recogerán todas las trazas de ese nivel y de los niveles superiores jerárquicamente (para conocer más sobre los nieles de traza, pinchar aquí). También se puede establecer el nivel mínimo de traza por paquete de clases, independientemente del nivel implementado por paquete (se usará la configuración más restrictiva)
3. Además del nivel, se puede establecer un control secundario y opcional sobre lo que se registra o no, mediante la asignación de un filtro o Filter (clase que hereda de java.util.logging.Filter) a un Handler. Un Filter, básicamente, implementa un método isLoggeable que devuelve un booleano que indica si un log se debe trazar o no.
4. Si se quiere formatear las trazas generadas con alguna estructura especifica, se debe implementar un Formatter (clase que herede java.util.logging.Formatter) y asignarlo al Handler deseado.
5. Toda esta configuración se hace a través de un fichero denominado logging.properties

La primera diferencia que chocará a todos los que venimos de usar log4j es que todo se configura programándolo. Es decir, no tienes una manera de poder configurar de forma flexible el formato de tus trazas. Si quieres un Formatter que saque el patrón de tu traza de un fichero de propiedades, vas a tener que programártelo.

TRABAJANDO CON LOG4J

¿Son mis logs reales o sólo un sueño?

Para trabajar con log4j en Glassfish v2 se recomendaba configurar la librería de traza como librería del sistema para evitar problemas con el classloading pero esto ya no puede hacerse con Glassfish v3 así que la solución pasa por indicar al servidor la ruta del fichero de configuración de log4j.

En log4j se configuran Appender (el equivalente de los Handler en JSR-047) El Appender típico que todo el mundo utiliza al desarrollar es el org.apache.log4j.ConsoleAppender, que publica los logs en la salida por defecto de System.out.

El problema es que las trazas no salen por la consola habitual que esperamos todos los programadores sino en un fichero server.log que se encuentra en la ruta /midominio/logs/.

Eso es bastante fácil de explicar porque  ese fichero es la salida por defecto del servidor, así que, ésa es su consola.

Lo que no tiene ni pies ni cabeza es que nuestras trazas salgan con el formato de las trazas de la API de logging de JDK o, más exactamente, envueltas por su formato, puesto que nuestro traza aparece… pero sólo como parte del mensaje de la traza de logging del JDK.

Bueno… podemos pensar que, de alguna manera, el sistema está ignorando nuestra configuración de log4j. Sin embargo, si configuramos cualquier otro Appender, por ejemplo uno que publique en un fichero inception.log, log4j funciona PERFECTAMENTE.

¿Entonces? ¿Qué está pasando? ¿Por qué salen todas mis trazas rodeadas de almohadillas ‘#’  y con un retorno de carro cuando las publico por consola?

LA SOLUCIÓN AL MISTERIO

No, no estamos soñando. Nuestras trazas son reales y nuestra configuración también. No estamos haciendo nada mal. Simplemente, alguien ha estado jugando con nosotros. Alguien ha estado haciendo trampas.

Glassfish, utiliza una implementación propia y sobrescrita del objeto System cuyo método out devuelve un PrintWriter que redirige todas las salidas al sistema de logging del servidor. Probadlo, hacer un System.out.println en una clase desplegada en Glassfish. No sólo aparecerá en la salida por defecto -server.log- sino que, además, aparecerá con el formato específico del sistema de logging.

Lo más grave de todo esto es que System es una clase final. Es decir, que no puede ser extendida, precisamente para evitar lo que Glassfish ha conseguido: que nuestro código tenga un comportamiento extraño y nos desconcierte. Que nos tengamos que frotar los ojos para comprobar que no estamos soñando.

De acuerdo, Glassfish nos ha engañado pero ahora, después de leer este artículo sabemos cómo vencerlo:

• ¿Queremos modificar el formato de las trazas del servidor? Implementaremos nuestro propio Formatter y se lo asignaremos al ConsoleHandler del fichero logging.properties
• ¿Queremos que nuestras propias trazas no se mezclen con las del servidor? Nos olvidaremos de utilizar el ConsoleAppender
• ¿Queremos que sólo nuestras trazas de error salgan en la salida por defecto del servidor? Podremos utilizar un ConsoleAppender y configurarlo en nuestro log4j.properties para que sólo registre trazas de nivel ERROR o superiores (recordad que sea cual sea el nivel de traza de log4j, la salida se publicará en System.out y el logging de JAVA las publicará por defecto como trazas de nivel INFO)

Glassfish ha luchado contra nosotros y ha perdido, por lo menos a nivel de logging. Nosotros le dominamos. No él, a nosotros. Y, desde luego, no estamos soñando… ¿o sí?

BONILINKS:

• Gente despotricando sobre el tweaking de System de Glassfish
• Gente flipando con el comportamiento de System.out
• La fuente del UniformLogFormatter (o el origen del formato de traza infernal de Glassfish)
• Información Oficial de Glassfish sobre configuración de logging, donde se les olvida comentar lo del asuntillo del System.out…
• Información para entender lo básico de la API Java Logging

Artículos relacionados:

1. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

Todos los que hemos trabajado con páginas y aplicaciones web conocemos la entidad   o, al menos, creemos conocerla… Pero, sorprendentemente, la mayoría de nosotros no sabemos qué es exactamente y eso hace que aparezcan problemas en la transición desde HTML hacia XTHML.

¿Queréis enteraros de qué es eso de   en apenas cinco minutos, mientras leéis una apasionante historia de intriga y misterio? Entonces, no lo dudéis y seguid leyendo…

EL MISTERIO DE LA JSPX DESESTRUCTURADA

Hace poco que empecé a sacar algo de tiempo libre para aportar al desarrollo  puro y duro de STORETTO. Al instalar el entorno de trabajo en Eclipse,  casi me caigo de la silla golpeado por un error rojo y horrible que señalaba a una JSPX traidora y maligna donde, según el IDE, había errores en la estructura del XML, la etiqueta de cerrado ‘</h:form>‘ no se correspondía con ninguna etiqueta de apertura.

Cuando les pregunté a los desarrolladores por qué daba el error, me dijeron que era un error de Eclipse porque la estructura XML de la página estaba bien, funcionaba y la famosa etiqueta ‘ </h:form>‘ tenía su correspondiente etiqueta de apertura.

¡Tenían razón! Entonces… ¿Qué estaba ocurriendo? ¿Qué era lo que estaba rompiendo el Chi del Eclipse? Era un claro caso para Bonilla Holmes…

LO MALO DE UN ECLIPSE, ES QUE NO TE DEJA VER

Cuando oficialmente eres Jefe de Equipo, Project Manager o Code Leader, te puedes permitir ciertas licencias, como pararte a ver porqué algo falla aunque el error no sea crítico, que casi compensa el horrible título con el que definen tu puesto.

Así que me enfrenté al error con valentía y decisión. Era evidente que el el Eclipse fallaba a la hora de analizar la estructura de la página, la pregunta era: ¿Por qué?.

Al principio pensé que era por un código comentado que incluía la etiqueta en cuestión, pero lo borré y el error seguía. La cosa se ponía difícil, pero, entonces, observé un montón de errorcillos (perdonad por mi léxico, no soy un experto en Eclipse, yo soy más de IDEA) provocados por el uso de la extraña combinación de caracteres ‘&amp;amp;nbsp;‘.

¿Para qué diantres estábamos escapando el carácter & para, a su vez, escapar el carácter espacio? No tenía sentido. Cuando lo cambié a &amp;nbsp; sin más, el error de estructura en Eclipse dejó de aparecer, pero la página daba un error al cargarse. No un error de maquetación, sino en la compilación en servidor.

Raro, raro, raro…

Cuando volví a preguntar a los desarrolladores si tenían idea alguna de por qué podía fallar la carga de la página web, me dijeron que no tenían ni idea pero que, por algún motivo, JSF -el framework que utilizamos- no se comía directamente el &amp;nbsp; y, por eso, teníamos que escapar el carácter & utilizando &amp;amp;.

ELEMENTAL, QUERIDO WATSON

No tenía sentido. Una cosa es que al tocar la página web descoyuntara la maquetación y otra cosa es que  rompiera el código del servidor. No comprendía muy bien qué tenía que ver JSF con los caracteres de escape del código HTML, así que le pedí al tío que más sabe de JSF a este lado del Pecos, César Vivero, que mirara conmigo las trazas de servidor.

No nos hizo falta más de 10 segundos para localizar el error -”The entity “nbsp” was referenced, but not declared.“- e, inmediatamente, mi mente de viejo rockero sufrió un espectacular flashback peliculero cuando recordé que había tenido el mismo problema al trabajar con hojas de estilo XSLT que producían HTML.

Miré a mi compañero y le dije “Lo tenemos César. Ya sé quién mató a Laura Palmer“.

EL HTML NO ES XML, Y XHTML TAMPOCO

El error en servidor no lo daba el uso de JSF en sí, sino el validador del XML de la página web. Sí, amigos, porque nuestras páginas son JSPX, lo cual quiere decir que utilizan XML y XHTML como lenguaje de marcas, no HTML… y ahí estaba el problema.

&amp;nbsp; es una entidad usada para representar el carácter espacio en HTML, pero no en XML. Aunque a veces se nos olvide y haya cierta confusión al respecto porque algunas de las entidades, como la utilizada para representar el carácter ‘&‘ -&amp;amp;- sean idénticas, las entidades de caracteres en XML y HTML no son iguales.

Así, lo que está cantando el validador de XML es, traducido al cristiano, “no sé qué me estás contando, brother“. Y eso es así porque &amp;nbsp; para XML no es absolutamente NADA. El carácter espacio en XML es &amp;nbsp; o, lo que es lo mismo, el carácter 160 de UNICODE.

Este error trivial es relativamente normal ya que, muchas veces, los desarrolladores trabajan directamente con una maqueta en HTML proporcionada directamente por un diseñador y la adaptan al lenguaje de plantillas correspondiente para que en java acabe siendo una JSP -con HTML incrustado- o una JSPX con XHTML.

UNA SOLUCIÓN QUIERO…

Para poder solucionar este problema tenemos dos posibilidades:

1. Utilizar el DOCTYPE al comienzo de nuestra página XHTML para que identifique la entidad &amp;nbsp; tal y como se especifica en este enlace:

Por ejemplo, para una página XHTML cuyo nodo raíz es jsp:root, escribiríamos:

<!DOCTYPE jsp:root [
<!ENTITY nbsp "&amp;nbsp;">
]>

2. Haciendo una sustitución masiva de la entidad &amp;nbsp; por la entidad &amp;#160 que sí es una entidad reconocida en XML.

Lo que nunca descubrimos fue por qué Eclipse se volvía loco, pero el chi de los programadores ahora descansa tranquilo porque la pestaña de avisos y errores ya no muestra ninguna inquietante aspa roja. El misterio de la JSPX desestructurada había sido resuelto.

]]> http://sixservix.com/blog/david/2010/08/18/nbsp-en-xhtml/feed/ 17 http://sixservix.com/blog/david/2010/07/23/lenguajes-herramientas/ http://sixservix.com/blog/david/2010/07/23/lenguajes-herramientas/#comments Fri, 23 Jul 2010 04:50:31 +0000 David Bonilla http://sixservix.com/blog/david/?p=3537 Si los lenguajes de programación fueran herramientas de desarrollo, podrían verse de la siguiente forma… o al menos eso es lo que piensan los chicos de 9gag.

Una más de esas clasificaciones estúpidas del tipo “Como ven los Sistemas Operativos los fans de Haskell”. Eso si, si Python es una sierra mecánica, ya estoy tardando en aprenderlo. Mataría por que me regalaran una por mi cumple… ;)

RT @9gag

Vamos a echarle un poco de chile picante a nuestra salsa de tomate. Hoy hablaremos sobre como practicar la Técnica Pomodoro Extrema.

1. PROTÉGETE DE TI MISMO Y BLINDA TUS POMODOROS

Seamos sinceros. Si fuéramos capaces de concentrarnos como Kasparov batallando contra Deep Blue no estaríamos leyendo este artículo. Si utilizamos la Técnica Pomodoro es porque hemos llegado a la conclusión de que queremos y PODEMOS ser más productivos concentrándonos en una única tarea, evitando distracciones externas y, sobre todo, internas.

Dejemonos de eufemismos ¿Qué es eso de ‘distracciones internas‘? Fácil: Twitter, Facebook, Spotify, navegar por Internet sin rumbo definido, correos electrónicos corporativos, correos electrónicos personales (véase Gmail o Hotmail), lectores de noticias y, la peor de todas: este adictivo blog.

¿Qué tienen en común todas estas actividades? Que se realizan frente al ordenador y, por lo tanto, son disimulables en un entorno laboral y que… requieren Internet.

Localizado el problema, encontrada la solución. En el mundo Apple, existe la killer-app con la que siempre soñaste: Concentrate (no, no me he olvidado el acento, se pronuncia consentreit). Concentrate te permite bloquear, durante un tiempo determinado, aplicaciones, páginas webs, específicas, cambiar el estado del iChat poniendote como ‘No Disponible’ y hasta lanzar scripts de AppleScript, lo que te permite hacer prácticamente lo que te de la gana (imaginaros las posibilidades para, por ejemplo, registrar tu histórico de pomodoros reales). Por supuesto, también te permite configurar cualquier tipo de alarmas y sonidos para ayudarte a concentrarte; y hasta finalizar con un “¡Eres un figura!“  con el que premiar tu esfuerzo.

En el mundo Windows no sé si existe algo tan glamouroso (por favor, si existe, hacedmelo saber) pero, siempre puedes tirar del cable de red y quedarte a solas con tu IDE, tu Tomcat y tu base de datos en local durante 25 minutos.

2. COMPARTE TUS TO-DO TODAY

Hemos dicho que la Técnica Pomodoro es una técnica de productividad personal. No intentes gestionar un equipo utilizando artefactos de la misma como los To-Do Today o el Active Inventory. No funciona.

Pero SI funciona -y bastante bien, por cierto- en combinación con otras técnicas ágiles de gestión de equipos o proyectos como, por ejemplo, Scrum. Y una de las máximas de Scrum es la TRANSPARENCIA. El razonamiento es: “… si estoy haciendo las cosas bien. Si estoy haciendo las cosas lo mejor que puedo ¿Por qué tendría que ocultar algo?“. Desde hace algún tiempo, lo primero que hago al llegar al trabajo por las mañanas es escanear mi hoja de tareas del dia anterior y copiarla en un directorio compartido de mi ordenador.

Poniéndole un poco de picante a nuestros Pomodoros... La Técnica Pomodoro extrema

Cualquiera puede verlas, cualquiera puede ver lo que he hecho y cuanto tiempo teórico me ha costado. Algunos pensaréis que es algo redundante con otros artefactos de Scrum como el Scrum Daily pero, yo no lo veo así, sino como algo complementario. Mientras que en el Scrum Daily se responden a tres preguntas básicas ¿Que hice ayer? ¿Que voy a hacer hoy? ¿Que me impide ser más productivo?, en mi hoja de tareas se puede ver, si he conseguido completar pomodoros, el trabajo que dediqué a una tarea u a otra y, en el caso de que no lo haya conseguido, el nivel de taladramiento exterior o ensoñación interior que he sufrido (recordar que en la Técnica Pomodoro se registran de forma distinta las interrupciones internas y las externas).

Mi responsable no me pidió que lo hiciera, la gente de la que soy responsable tampoco. Lo he hecho de forma voluntaria y me ha ayudado a ser más constante en la aplicación de la Técnica y del registro de pomodoros, interrupciones y eventos inesperados en mi hoja diaria de tareas.

3. PLANIFICA CON POMODOROS

Yo suelo planificar todas mis tareas diarias en base a la duración en pomodoros de las mismas. Se que es difícil que pueda hacer más de 12 pomodoros al día. No es una buena ni una mala marca (recordar, esto no es una competición), es mi ritmo de trabajo habitual adaptado a la realidad de mi día a día.

Al principio se hace un poco raro pero, poco a poco, te vas acostumbrando. Dos pomodoros son 50 minutos de trabajo puro y, si crees que algo va a durar menos de un pomodoro, lo agrupas. Al final, te encuentras con agrupaciones de 3 llamadas de teléfono de esas que “no puedes dejar de hacer” o con pomodoros destinados a “contestar correo“. Una vez más, todo destinado a incrementar tu productividad.

La propia Técnica Pomodoro te sugiere que planifiques la duración de tus tareas en pomodoros y habla de un supuesto Record Sheet para poder comprobar las diferencias entre tus estimaciones y la realidad. No encontré ningún Record Sheet por ningún lado, así que creé el mio para poder registrar las diferencias de planificación.

Si Scrum ayuda al equipo a saber planificarse mejor en iteraciones de cierta duración, la Técnica Pomodoro puede ayudarte a planificar con más exactitud de la que creias posible el trabajo de tu dia a dia.

4. DOMINA LA TÉCNICA POMODORO, NO DEJES QUE TE DOMINE A TI

Un comentario del gran Xavi Gost me hizo ver lo dogmático que puedo sonar pero, no soy un talibán de la estricta observancia de la Técnica Pomodoro por el contrario, creo que cada uno puede y debe adaptarla a si mismo y su forma de trabajo. El manual donde Francesco Cirillo está muy bien y ¡es gratis! pero no es la Biblia. Francesco se limita a describir los conceptos básicos de su técnica y como aplicarlos.

En el momento de redacción de este artículo, la última versión disponible era la 1.3, publicada el 15 de junio de 2007 o, lo que es lo mismo, hace más de tres años.

El libro tiene algunas lagunas como la del Record Sheet que antes os he mencionado y, por otro lado, al ser un manual, muchas veces se limita a describir reglas sin explicar en profundidad el espíritu de las mismas lo que puede llevar a confusiones.

En cualquier caso, la Técnica Pomodoro es una técnica de productividad personal y, por tanto, debe y puede adaptarse a las circunstancias personales de cada uno para alcanzar su objetivo principal: que seamos más productivos. El manual es el inicio, no un fin en si mismo.

Si por vuestra forma de trabajar os viene mejor hacer pomodoros de 47 minutos o intercaláis el trabajo entre dos tareas porque con una sola os aburrís y os funciona… ¡Genial! Lo importante es que consigáis más del tiempo que destinéis al trabajo.

…

Estos son sólo algunos consejos y buenas prácticas que a mi me han funcionado. Espero que podáis aplicarlos y, si os dan resultado, destinar algún pomodoro para dejar un comentario y contármelo. Os lo agradeceré de corazón. Muchas gracias por leerme.

Artículos relacionados:

1. No sabes nada de la Técnica Pomodoro ¿Conoces la Técnica Pomodoro? ¿CREES que conoces la Técnica Pomodoro?...
2. La Técnica Pomodoro Voy a intentar explicar de una forma divertida y amena...

Afirmar que se conoce la técnica por saber que “es eso de trabajar 25 minutos y descansar 5” es la misma tontería que decir que se conoce la gastronomía española por haber comido paella y sangría en un chiringuito de Ibiza… o decir que se domina scrum por tener un papel que dice que uno es Certified Scrum Master.

Puede que algunos halláis ido aún más allá y leyerais todo el manual de Francesco Cirillo en perfecto inglés pero, creedme, si no habéis trabajado en la práctica con la Técnica Pomodoro, no tenéis ni idea de que va todo esto.

En este artículo aclararé algunos conceptos para los que acaban de descubrir  horrorizados que no se han enterado muy bien de que va todo esto e intentaré  evitaros algunos errores de concepto que corregí después de meses de pegarme con la Técnica Pomodoro.

1. ¡ESTO NO ES UNA COMPETICIÓN, ESTÚPIDO!

Al principio, cuando comienzas a trabajar con la Técnica Pomodoro, crees que el hecho de hacer más o menos pomodoros indica lo mucho o poco que has trabajado. Eso es más falso que un billete de 7 euros.

El objetivo de la Técnica Pomodoro no es que hagas todos los pomodoros que puedas sino todas las tareas que puedas,  utilizando conceptos de otras metodologías de trabajo como el Getting Things Done y su lista de tareas o el Work In Progress y su apuesta por reducir al mínimo el trabajo en paralelo con varias tareas. Los pomodoros, porciones de tiempo de 25 minutos reservados en exclusiva a una tarea, son una herramienta para conseguirlo, no el fin en sí mismo. Aunque parezca increíble, la gente se olvida de esto.

Al final del día, puedes haber concluido todas tus tareas sin haber conseguido finalizar ni un solo pomodoro. De la misma forma, puedes haber cerrado 28 pomodoros y no haber finalizado ni una sola de tus tareas.

2. ESTO ES IMPOSIBLE

“Sí, eso de la Técnica Pomodoro suena muy bien pero, en mi puesto de trabajo, es IMPOSIBLE de aplicar. ¿25 minutos sin coger el teléfono? No funcionaría“. Frases como la anterior son habituales cuando hablas con gente sobre la Técnica Pomodoro. Aunque hay entornos laborales verdaderamente hostiles al empleo de la técnica como, por ejemplo, el de una recepcionista… o el de un tornero fresador, la Técnica Pomodoro puede aplicarse  (bien) en muchos más entornos de los que la gente cree.

¿Te resulta imposible no coger el teléfono durante 25 minutos? Pues no lo hagas. Cógelo todas las veces que te haga falta, aunque claro… eso significará que romperás tus pomodoros y que tendrás que comenzar de nuevo ¿y? No pasa nada. Sigues con tu lista de tareas y vas marcando las que concluyas, los pomodoros que completes y las interrupciones que sufras.

3. LA TÉCNICA POMODORO ES MUY DURA

Uno de los mitos de la Técnica Pomodoro es que hace que la gente trabaje menos y se tome más descansos que un funcionario público. Craso error.

“Espera, espera, espera… pero, si rompo mis pomodoros, entonces… no puedo tomarme los cinco minutitos de descanso ¿no?” Pues no, amiguete. Quiero decir, puedes tomarte cinco o cincuenta pero, no estarías cumpliendo la Técnica Pomodoro.

Seguir la Técnica Pomodoro es MUY duro y, creedme, si conseguís concluir un pomodoro, necesitaréis esos cinco minutos de descanso, para ir al baño, para contestar algún correo o tomaros una café.

Cuando llevas 23 minutos dándolo todo, te quedan 2 minutos para ganarte tu descanso y te llega alguien con una pregunta estúpida, en seguida comprendes el concepto de “protege tu pomodoro“. Ya te digo si lo proteges ¡con uñas y dientes!.

Si consigo concluir cuatro pomodoros y me tomo ese descanso de quince a veinticinco minutos, creedme, lo hago sin ningún tipo de remordimiento. Sé que estoy siendo rentable, muy rentable para la empresa.

Seguir (bien) la Técnica Pomodoro es tan duro y requiere tal disciplina que hay días que directamente no la aplico y me la salto. Cuando trabajo haciendo pomodoros suelo acabar tremendamente agotado pero, también, tremendamente satisfecho porque sé que he dado todo lo que tengo dentro, que me he vaciado y que no he perdido el tiempo.

…

Me dejo cosas en el tintero, pero no quería que este artículo fuera uno de mis ladrillos interminables. También estoy preparando un artículo sobre Técnica Pomodoro Extrema para ayudar a llegar al límite a aquellos de vosotros que la practiquéis. Incluso la gente de Okuri Spaces me han comentado la posibilidad de dar alguna charla o curso en sus instalaciones sobre la Técnica Pomodoro por lo que, si estáis interesados en saber más, por favor hacédmelo saber a través de los comentarios o del formulario de contacto de esta web. Muchas Gracias.

Artículos relacionados:

1. Técnica Pomodoro Extrema Como utilizar la Técnica Pomodoro para llegar donde nadie ha...
2. Técnica Pomodoro: Record Sheet Cada vez somos más los que seguimos la Técnica Pomodoro...
3. La Técnica Pomodoro Voy a intentar explicar de una forma divertida y amena...

Todo esta introducción, sólo es una excusa para presentaros el mejor vídeo sobre java que se ha hecho nunca. Cuando digo nunca es NUNCA. Simplemente, IMPRESCINDIBLE. Disfrutadlo…

Pinche aquí para ver el vídeo

Es el impresionante trailer que ha creado la gente de JavaZone, una conferencia de desarrolladores celebrada en Escandinavia con más de 2300 entradas vendidas.

Dedicado a la gente de AltNetHispano -que tan bien lo están haciendo- en general y a Amalia Hernandez en particular.

(Visto en Meneame, donde los comentarios demuestran que, desgraciadamente, aún hay gente que cree que hay lenguajes buenos y malos, no buenos o malos programadores…)

PEDAZO DE DISCLAIMER:

Este vídeo me llegó el fin de semana pasada e inmediatamente redacté este post como boniartículo humorístico para el siguiente viernes. Cuando vi que ya lo habían publicado en su cuenta de twitter gente como Dani Latorre, Erick Camacho o Sergi Almar también lo hice en la mía pero, mantuve la publicación del artículo para el siguiente viernes.

Después vi que el vídeo había corrido como la espuma por Internet y que hasta Abraham había hecho referencia al mismo en javaHispano. Aún así, lo mantuve. Primero porque soy un cabezón :) y, segundo, porque quiero creer -ayudado por las estadísticas de Google Analytics- que no todo el mundo que me lee viene de jH  (“sólo” un 14,16%…).

Hoy, al repasar el artículo por última vez, me he alegrado profundamente de haber esperado hasta el viernes para publicarlo porque, lo que se dice modula completamente el “polémico” artículo del miércoles y me ha animado a escribir este disclaimer.

Aún así, puede haber algún bocachancla que diga que este artículo es oportunista y se ha escrito posteriormente. Lo estoy esperando. Menos mal que el bendito sistema de gestión de Wordpress guarda un histórico de cambios con hora y fecha…

Un saludo a todos y que viva .NET, Java, Ruby y Fortran. Como he dicho muchas veces, tenemos la profesión más bonita del mundo. Da igual el lenguaje que utilicemos…

PS: Una última mención de agradecimiento a Jorge Rubira que encontró una versión alternativa del vídeo después de que lo hubieran retirado de YouTube.

He de reconocer que, hasta hace poco, era un relativo fanboy de java pero, cada día soy más agnóstico respecto al lenguaje y me interesa más el producto; lo que, traducido a cristiano, significa que me da igual como esté hecho algo, lo importante es las funcionalidades que implemente y, por supuesto, que esté bien hecho.

Y en este estado de las cosas, ha caído en mis manos una maravillosa presentación de Jeffrey Zhao titulada “Porque Java apesta y C# mola”. El texto es imprescindible, lo mires por donde lo mires. No sólo porque supone una comparativa técnica y científica que rebosa calidad por todos los lados, sino porque detrás de un título de apariencia troll, se esconde una reflexión realista y desapasionada en la que no se aprecia fanatismo alguno.

Pero lo más importante de todo es que Jeffrey Zhao SE MOJA. Es de agradecer que alguien tome posición, la argumente y sea lo suficientemente valiente como para hacerla pública y, a lo torero, pedir réplica a la misma con la frase “contacta conmigo, muéstrame tu idea… y pruébala” proporcionando su blog, correo y cuenta de twitter. Ahí es nada.

Por si fuera poco, las diapositivas están salpicadas de frases memorables y un fino humor que es difícil de encontrar en un texto técnico. Me ha encantado la reflexión “si la JVM es la máquina, los byte codes son el código máquina y programar en Java… es como programar en ensamblador ¿De verdad quieres programar en ensamblador?”. Sencillamente, brillante.

El texto finaliza con una reflexión: ni siquiera nos pide que cambiemos de plataforma, entendiendo como plataforma la JVM, sino que pregunta ¿Por qué no utilizar otros lenguajes más poderosos a nivel de sintaxis y que se pueden utilizar dentro de la JVM como Scala, Ruby (JRuby) o Python (Jhyton)?

Qué grande es Jeffrey Zhao y qué grande es esta presentación. Tengo el orgullo de presentárosla aquí:

La conclusión a la que llego después de haber leído la presentación es que Jeffrey, como tantos otros, no nos está pidiendo a los que venimos del mundo Java que abandonemos la JVM ni la potencia de todo el mundo de librerías que hay detrás de ella, sino que probemos otros lenguajes que se pueden ejecutar en la misma.

¿Realmente merece la pena hacerlo cuando desgraciadamente hay un alto porcentaje de programadores a los que les suena a chino la mayoría de las cosas de las que habla Jeffrey? Bueno… depende. Si formas parte de una maligna megacorporación, puede que no, pero, si eres miembro de un pequeño y altamente productivo equipo de desarrollo…, a lo mejor el hecho de utilizar un lenguaje donde poder ordenar un array pasando la lógica de ordenación como parámetro, en vez de implementando una clase Comparator, marca la diferencia.

Voy a echarle un vistazo a Scala…

Artículos relacionados:

1. Gestión de memoria en Java Hace poco me llegó un correo de un compañero del...

Mientras que en la primera entrega dejamos configurado el servidor y en la segunda configuramos el proyecto en Netbeans, en esta estudiaremos directamente el código que nos permitirá trabajar con transacciones y bloqueos.

Nuestro proyecto web va a ser más simple que el asa de un cubo. Constará de un servlet escrito “a pelo Capello” denominado RenombraServlet, un EJB Stateless llamado ActualizaCliente , dos EJBs de sesión tan míseros que no merecen ni ser mencionados, aunque nos ayudaran a probar como conseguir transacciones y bloqueos pesimistas, y optimistas con EJB3.1; y, por último, dos EJBs de entidad – Customer y Order- que facilitan el mapeo entre la base de datos y nuestra aplicación.

¿Qué hace nuestra aplicación? Sencillo. Cuando se invoque el servlet se buscará al cliente con ID = 1. Si no existe, nos crearemos un cliente llamado “José María Arranz”, si existe, lo renombraremos dos veces por código aunque podremos comprobar que, en el mejor de los casos, sólo se modificará el nombre del cliente una única vez.

Una vez descritos de forma genérica la aplicación y su funcionamiento, os presentaré las clases una a una y, finalmente, os explicaré cómo se consiguen transacciones y bloqueos con las mismas.

1. EL SERVLET Y EL EJB RENOMBRADOR

La clase RenombraServlet.java es el punto de acceso de la aplicación. Por obra y gracia de la especificación 3.0 de servlets se autoconfigura con una ruta de acceso /RenombraServlet, así que ya sabéis, para acceder a la aplicación vía el servletcito:  http://tuhost:tupuerto/tucontexto/RenombraServlet

Una cosa importante a tener en cuenta es que se puede invocar al método con un parámetro opcional lock que te permitirá hacer renombrados con distintos bloqueos y que os explicaré más adelante.

Así, por ejemplo, si invocáis al servlet con el parámetro lock con valor 1 (http://tuhost:tupuerto/tucontexto/RenombraServlet?lock=1), estaréis renombrando al cliente “José María Arranz” con un bloqueo pesimista con un NOWAIT como una casa de grande.

Básicamente, es un servlet corriente y moliente que escribe HTML directamente en  la HttpServletResponse para ir mostrando los resultados del renombrado o de los errores del mismo por navegador y facilitar la comprobación  del correcto funcionamiento de la aplicación.

Llama a un EJB llamado Renombrador.java que es una clase absurda. lamentable y claramente prescindible pero, que he creado para que veáis que un EJB puede ser cualquier cosa a la que le claves la anotación correspondiente. Renombrador se limitará a devolver un nuevo nombre para el cliente que estará compuesto con los milisegundos de la fecha del sistema (sí, lo di todo por destacar al menos en originalidad).

Una vez que haya obtenido el nuevo nombre para el cliente, se invocará el método renombra del EJB ActualizaCliente.java que, sorprenderos, actualizará el nombre del cliente.

package com.six.test;

import java.io.IOException;
import java.io.PrintWriter;
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet de todo a 100 que sirve como ruinosa fachada para nuestros EJBs
 * @author McGyver
 */
@WebServlet(name = "RenombraServlet", urlPatterns = {"/RenombraServlet"})
public class RenombraServlet extends HttpServlet {

    @EJB
    private Renombrador bean;
    @EJB
    private ActualizaCliente session;

    /** 
     * Procesa peticiones HTTP de tipo <code>GET</code> y <code>POST</code>.
     * @param request Servlet request
     * @param response Servlet response
     * @throws ServletException si existe algún error en el funcionamiento del Servlet
     * @throws IOException si existe algún error de escritura/lectura
     */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        try {
            String nuevo_nombre = bean.renombra();
            
            // Este operador ternario esta dedicado, con amor, a Xavi Gost (@XaV1uzz)
            int tipoBloqueo =
                    esUnNumero(request.getParameter("lock")) ?
                        Integer.parseInt(request.getParameter("lock")) : 0;

            out.println("<html>");
            out.println("<head>");
            out.println("<title>Renombrando a un Cliente</title>");
            out.println("</head>");
            out.println("<body>");
            out.println("<h1>Servlet " + request.getContextPath() + "/RenombraServlet - " + nuevo_nombre + "</h1>");
            out.println("<br/>");
            try {
                session.renombra(nuevo_nombre, tipoBloqueo);
                out.println("<p>Renombrado correcto</p>");
            } catch (Throwable e) {
                out.println("<p>Upps !!!: " + e + "</p>");
                out.println("<p>");
                e.printStackTrace(out);
                out.println("</p>");
            }
            out.println("</body>");
            out.println("</html>");

        } finally {
            out.close();
        }
    }

    /**
     * Metodo estupido que he creado para no tener que importar ni una
     * libreria de Commons de Apache. Reinventing the rueda !!!
     * @param texto la cadena de texto de la que queremos averiguar si es un número
     * @return true si el texto expresa un número
     */
    private boolean esUnNumero(String texto) {
        boolean respuesta = false;
        try {
            if (texto != null) {
                Integer.parseInt(texto);
                respuesta = true;
            }

        } catch (NumberFormatException ex) {
            // Este catch vacio se vende como espacio patrocinado
            // Anunciante, si quiere exponer sus productos aquí
            // contacte con david@sixservix.com
        }
        return respuesta;
    }

    // <editor-fold defaultstate="collapsed" desc="HttpServlet methods. Click on the + sign on the left to edit the code.">
    /** 
     * Handles the HTTP <code>GET</code> method.
     * @param request servlet request
     * @param response servlet response
     * @throws ServletException if a servlet-specific error occurs
     * @throws IOException if an I/O error occurs
     */
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    /** 
     * Handles the HTTP <code>POST</code> method.
     * @param request servlet request
     * @param response servlet response
     * @throws ServletException if a servlet-specific error occurs
     * @throws IOException if an I/O error occurs
     */
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    /** 
     * Returns a short description of the servlet.
     * @return a String containing servlet description
     */
    @Override
    public String getServletInfo() {
        return "Short description";
    }// </editor-fold>
}

El sofisticadísimo renombrador:

package com.six.test;

import javax.ejb.Stateless;

/**
 * Esta clase es tan tonta que me da verguenza
 * @author david
 */
@Stateless
public class Renombrador {
    public String renombra(){
        return "Nuevo nombre del Cliente: " + System.currentTimeMillis();
    }
}

2. EL EJB ACTUALIZADOR: BLOQUEOS

El EJB ActualizaCliente.java contiene todo lo que necesitáis saber para crear bloqueos optimistas, pesimistas con NOWAIT y pesimistas con un WAIT determinado.

El método principal es renombra(String nombre, int tipoBloqueo) y, a partir de ahí, podéis ver todo el proceso.

Lo primero que se hace en el método es invocar al método secundario getQuery(int tipoBloqueo) que devolverá una Query con el tipo de bloqueo seleccionado:

• Si habéis invocado a RenombraServlet.java sin parámetros o con el parámetro lock con valor 0, estaréis creando una Query con bloqueos optimistas (te deja consultar una tupla de una tabla de base de datos y sólo te provocará error si actualizas esa tupla después de que haya sido actualizada previamente por otra transacción entre el momento en el que consultaste la tupla y actualizaste -error en em.flush()-)
• Si habéis invocado a RenombraServlet.java con el parámetro lock con valor 1, estaréis creando una Query con bloqueos pesimistas NO WAIT o “sin espera” (sólo permite que una transacción consulte una tupla determinada de una tabla de base de datos y lanzará error si intentas consultar la misma tupla antes de que acabe la primera transacción -error en q.getSingleResult()-)
• Si habéis invocado a RenombraServlet.java con el parámetro lock con valor 2, estaréis creando una Query con bloqueos pesimistas WAIT o “con espera” (sólo permite que una transacción consulte una tupla determinada de una tabla de base de datos y lanzará error si intentas consultar la misma tupla antes de que acabe la primera transacción y en  n segundos no finaliza la misma -error en q.getSingleResult()-). En esta aplicación, la espera o WAIT está configurada para durar dos segundos.

Podéis probar los bloqueos depurando la aplicación y accediendo a la misma desde dos navegadores. Si ponéis un punto de interrupción justo en la línea donde se invoca q.getSingleResult(), con un primer hilo invocáis el método y pausáis la aplicación, cuando hagáis lo mismo con el segundo hilo veréis como la aplicación lanza un error si habéis utilizado un bloqueo pesimista -inmediatamente si es de tipo NOWAIT y después de n segundos en el caso del WAIT- y como continúa en el caso de que utilicéis los bloqueos optimistas.

Poned otro punto de interrupción en la línea em.flush(), veréis que el hilo de bloqueo pesimista que consiga llegar hasta dicho punto lo superará sin problemas. Por el contrario, en el caso de los bloqueos optimistas, el primer hilo que invoque el método, persistirá sin problemas y el segundo lanzará un OptimisticLockException que os dejará sentados en la silla con cara de asno esloveno.

package com.six.test;

import javax.persistence.EntityManager;
import javax.persistence.Query;

import com.six.model.entity.*;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.persistence.NoResultException;
import javax.persistence.PersistenceContext;
import org.eclipse.persistence.config.PessimisticLock;
import org.eclipse.persistence.config.QueryHints;

/**
 * @author Spiderman
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class ActualizaCliente {
    
    private static final int CUSTOMER_ID = 1;
    private static final int SECONDS_WAIT = 2;
    
    @PersistenceContext
    private EntityManager em;

    @EJB
    private NOActualizaCliente sc2;

    public ActualizaCliente() {        
    }

    public void renombra(String nombre, int tipoBloqueo) throws Throwable {
        

        try {
            Query q = getQuery(tipoBloqueo);
            Customer c = (Customer) q.getSingleResult();
            System.out.println("El nombre del Cliente es: " + c.getName());

            if (c == null) {
                // Crea un nuevo Cliente
                Customer customer0 = new Customer();
                customer0.setId(CUSTOMER_ID);
                customer0.setName("Jose María Arranz");

                // Persiste el cliente
                em.persist(customer0);

                // Crea 2 nuevas ordenes
                Order order1 = new Order();
                order1.setId(100);
                order1.setAddress("C/ACDC 14. Leganes, España");

                Order order2 = new Order();
                order2.setId(200);
                order2.setAddress("129 James Gosling Ave. San Francisco, USA");


                /**
                 * Asociación de las ordenes con el cliente. La asociación
                 * debe estar configurada en ambos lados de la relación: en
                 * la parte del Cliente para que las ordenes se persistan
                 * cuando la transaccion se comitee, y en el lado de las
                 * ordenes para configurar la relación.
                 */
                customer0.getOrders().add(order1);
                order1.setCustomer(customer0);

                customer0.getOrders().add(order2);
                order2.setCustomer(customer0);
            } else {
                sc2.renombra(c);
                c.setName(nombre);
                em.flush();
                System.out.println("El nombre del Cliente es: " + c.getName());
            }

        } catch (Throwable e) {
            System.out.println("ERROR: " + e.getMessage());
            throw e;
        }

    }

    private Query getQuery(int tipoBloqueo) {
        
        // Por defecto, se utiliza el bloqueo optimista.
        // Si se actualiza despues de otra actualización OptimisticLock Exception
        Query q = em.createNamedQuery("Customer.findById");
        q.setParameter("id", CUSTOMER_ID);
        switch(tipoBloqueo) {
            case 1:
                // Bloqueo pesimista con no wait
                q.setHint(QueryHints.PESSIMISTIC_LOCK, PessimisticLock.LockNoWait);
                System.out.println("Bloqueos Pesimistas con NOWAIT !!!");
                break;
            case 2:
                 //Bloqueo pesimista con wait de 2 segundos
                q.setHint(QueryHints.PESSIMISTIC_LOCK, PessimisticLock.Lock);
                q.setHint(QueryHints.JDBC_TIMEOUT, SECONDS_WAIT);
                System.out.println("Bloqueos Pesimistas con WAIT de " + SECONDS_WAIT + " segundos !!!");
                break;
            default:
                System.out.println("Bloqueos Optimistas !!!");
                break;
        }               
        return q;
    }

    private Customer findCustomer(Integer id) {
        Customer customer = null;
        Query q = em.createQuery("select c from Customer c where c.id = :id");
        q.setParameter("id", id);
        try {
            customer = (Customer) q.getSingleResult();
        } catch (NoResultException e) {
        }
        System.out.println(customer == null ? "Customer nulo " : "Customer " + customer.getName());
        return customer;

    }

}

3. EL EJB NO ACTUALIZADOR: TRANSACCIONES

Si con la clase ActualizaCliente.java hemos aprendido como se utilizan bloqueos de todo tipo con EJB3.1 y el comportamiento de cada uno de los mismos, con el EJB NOActualizaCliente.java comprenderemos cómo se manejan transacciones a través de invocaciones e invocaciones de EJBs.

Los EJBs nos proporcionan una transaccionalidad inmediata en cada uno de sus métodos, sin embargo, puede que tengamos lógica de negocio que necesite ser invocada con transaccionalidad dispersada por varias clases y métodos. ¿Cómo podemos conservar nuestras preciosas transacciones ACID a través de toda la maraña de invocaciones?

La sencillez de gestión de transacciones con JPA es inversamente proporcional a la corrección con que la gente las utiliza.

La clase NOActualizaCliente.java se llama así porque realmente jamás actualizará la base de datos. ¿Por qué, si se modifica un objeto mapeado directamente con una tupla en una tabla, y se persiste mediante em.persist() y em.flush()? Pues muy sencillo: por la configuración de transacciones dentro de la clase.

Si os fijáis bien, la clase se declara con una configuración global de transacciones:

@TransactionAttribute(TransactionAttributeType.REQUIRED)

Esta configuración se aplica a TODOS los métodos de la clase y, básicamente implica dos cosas:

• Si el método se invoca dentro de una transacción, se utiliza dicha transacción
• Si el método no se invoca dentro de una transacción, se crea una que se cerrará con la finalización del mismo

Sin embargo, puede que queramos que nuestro método tenga una configuración de transaccionalidad especifica y diferente del resto de los métodos de la clase ¿Cómo podemos conseguirlo? Proporcionando dicha configuración especifica mediante la misma anotación, pero a nivel de método:

 @TransactionAttribute(TransactionAttributeType.MANDATORY)

La configuración de transaccionalidad MANDATORY es ligeramente distinta a la de REQUIRED porque esta configuración implica que el método debe ser invocado dentro de una transacción y, si no es así, se lanza un error.  Si intentaramos invocar este método directamente desde nuestro Servlet, el error que obtendrías sería de proporciones bíblicas.

¿Quiere decir esto que no podremos invocarlo jamás desde un servlet? Pues… no. Podemos crear transacciones de forma manual, aunque seguro, seguro, seguro que el contenedor las gestiona mejor que nosotros… o al menos que yo.

Al utilizar la configuración MANDATORY me he asegurado que la lógica de este método siempre sea invocada dentro de una transacción. Como el método renombra() de NOActualizaCliente.java se invoca desde el método renombra() de la clase ActualizaCliente.java e, inmediatamente después, se vuelve a actualizar desde ese método el objeto actualizado por el primero, la actualización de la clase NOActualizaCliente.java jamás se hará efectiva en la base de datos.

¿Por qué? Porque estamos dentro de una transacción y, hasta que la misma no finalice, no se harán efectivos ninguno de los cambios realizados a nivel de código. La finalización del método renombra() de NOActualizaCliente.java no implica la finalización de ninguna transacción y, por tanto, no implica persistencia de los datos.

package com.six.test;

import javax.persistence.EntityManager;

import com.six.model.entity.*;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.persistence.PersistenceContext;


/**
 * @author Hulk
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class NOActualizaCliente {
    
    @PersistenceContext
    private EntityManager em;

    public NOActualizaCliente() {        
    }

    /**
     * Este método sirve para comprobar que las transacciones 
     * funcionan con llamadas a varios métodos puesto que hasta que el método
     * que la invoca no hace el flush, los cambios no llegan a Base de Datos
     * @param c un Cliente de toda la vida
     */
    @TransactionAttribute(TransactionAttributeType.MANDATORY)
    public void renombra(Customer c) {

        try {
            c.setName("Esto JAMÁS deberia ir a base de datos");
            em.persist(c);
            em.flush();
            System.out.println("El nombre del Cliente es: " + c.getName());
        } catch (Throwable e) {
            System.out.println("ERROR: " + e.getMessage());
        }

    }
 
}

Para finalizar, os copio los EJBs de tipo Entity que soportan el mapeo entre los objetos de la aplicación y la base de datos.

Customer:

package com.six.model.entity;

import java.io.Serializable;
import javax.persistence.*;
import static javax.persistence.CascadeType.*;

import java.util.Collection;
import java.util.ArrayList;


@Entity
@NamedQueries({
    @NamedQuery(name = "Customer.findById", query = "SELECT u FROM Customer u WHERE u.id = :id")})
public class Customer implements Serializable {

    private int id;
    private String name;
    private Collection<Order> orders = new ArrayList<Order>();
    private int version;

    @Id
    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @OneToMany(cascade=ALL, mappedBy="customer")
    public Collection<Order> getOrders() {
        return orders;
    }

    public void setOrders(Collection<Order> newValue) {
        this.orders = newValue;
    }

    @Version
    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }

}

Order:

package com.six.model.entity;

import javax.persistence.*;

@Entity
@Table(name="ORDER_TABLE")
public class Order {

    private int id;
    private String address;
    private Customer customer;

    @Id
    @Column(name="ORDER_ID")
    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    @Column(name="SHIPPING_ADDRESS")
    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    @ManyToOne()
    @JoinColumn(name="CUSTOMER_ID")
    public Customer getCustomer() {
        return customer;
    }

    public void setCustomer(Customer customer) {
        this.customer = customer;
    }
}

Espero que después de este tutorial de todo a cien, al menos tengáis claro que SE PUEDEN conseguir bloqueos de todo tipo y transacciones ACID con EJB3.1 y JPA2 (recordar, JPA1 sólo soportaba las optimistas). Ahora tenéis el poder suficiente para hacer lo que os dé la gana con vuestras transacciones y bloqueos; y, como decía el filósofo más importante del siglo XX, el Tío Ben de Peter Parker/Spiderman “un gran poder implica una gran responsabilidad”. Espero que todo esto os sea útil y os haya ahorrado algunas horas de I+D.

Peter, no la cagues con las transacciones…

Pinche aquí para ver el vídeo

DISCLAIMER:

• Ningún gatito resultó herido en la realización de este tutorial
• Debo agradecer a Alberto Peña (aka @plagelao) el conocimiento, uso y disfrute de los Gist de de GitHub con los que se comparte el código de este ejemplo.
• Si quieres el código de esta aplicación y todos sus ficheros de configuración, mándame un correo y por un módico precio llegaremos a un acuerdo. Si lo pides por favor, puede que te salga gratis (gracias a Sixservix)

Artículos relacionados:

1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

Continuo con mi proyecto de mega-artículo-tutorial-taladro sobre transacciones y bloqueos con JPA2 y EJB 3.1 en Glassfish v3.

En el artículo anterior, aprendimos a configurar base de datos y servidor para poder llevar a cabo este tutorial. En esta nueva entrega, aprenderemos a configurar nuestra aplicación para que pueda trabajar con estas tecnologías.

3. CREANDO NUESTRO PROYECTO EN EL IDE

Yo he utilizado Netbeans 6.8 como IDE para crear este ejemplo. No porque crea que sea el mejor entorno de trabajo, ni porque sea un fan de los productos de Oracle/SUN, sino porque es el que mejor integración nativa trae de serie con Glassfish v3. Bajo mi modesta experiencia -y llevo unos cuantos años en esto- el Servidor de Aplicaciones elegido puede condicionar totalmente vuestra arquitectura; y la integración, gestión y depuración del mismo, la elección de un IDE u otro. Podéis seguir este tutorial aunque utilicéis otro IDE, sólo tenéis que adaptar lo que se vaya haciendo a las peculiaridades de vuestro entorno de trabajo.

Para crear nuestro proyecto utilizaremos el wizard que se lanza desde la siguiente ruta de menú:

File >> New Project >> Java Web >> Web Application.

Se desplegará una primera interfaz donde se indicará el nombre del proyecto:

Interfaz de creación de proyecto (pulsa sobre la imagen para verla grandota)

La siguiente interfaz sirve para especificar el servidor con el que trabajará el proyecto, la versión de java utilizada y el contexto web que lo lanzará. Si sois unos vagos -como yo- habréis utilizado el Glassfish v3 que instala NetBeans para configurarlo como explique en el anterior artículo. Si, por el contrario, os dado por innovar, coleccionais todas las versiones del servidor o, en definitiva, os gusta hacer las cosas bien, puede que tengáis que añadir otro contexto de servidor mediante el botón “Add”. Aquí tenéis mi configuración:

Configurando sel servidor, versión de java y contexto

La siguiente y última interfaz nos interrogará para saber si queremos incluir algún framework de trabajo como, por ejemplo, JSF en nuestro proyecto. Le diremos que “de momento, no gracias“. Bastante tenemos con nuestras transacciones (vamos por dos artículos… y lo que nos queda).

Una vez apretemos el botón de ‘Finish‘ habremos creado un esqueleto de proyecto donde se incluyen las librerías del JDK 1.6, de Glassfih v3 y, para pruebas, JUnit y el contexto embebido de Glassfsh.

4. CREANDO UNA UNIDAD DE PERSISTENCIA

Creado el proyecto, aparecerá en el explorador de la izquierda del interfaz un icono muy pituco que representa una bola del mundo (o algo así). Si pulsáis sobre el mismo con el botón derecho del ratón y seguís la siguiente ruta de menú New >> Persistence Unit, accederéis a un nuevo mundo de poder y sabiduría… y al wizard de creación de unidades de persistencia.

El wizard de creación de Unidades de Persistencia

Aquí tenemos que pararnos durante un rato y explicar que es cada cosa y porque se elige una opción u otra. Al menos, si queremos enterarnos minimamente de que es cada cosa en vez de seguir el tutorial cual robots.

¿Sabemos lo que es una Unidad de Persistencia? Si, la respuesta es “si”, podéis pasar al siguiente párrafo. En caso contrario, os diré que el concepto de unidad de persistencia o persistence unit fue introducido por JPA1 y sirve para definir el conjunto de clases de entidad -que representan entidades de una base de datos- que serán gestionadas por nuestro contexto de persistencia o, lo que es lo mismo, los polvos mágicos que conseguirán que, al crear un objeto de tipo com.six.Boniato y persistirlo, se cree un nuevo registro en la tabla Boniato de nuestra Base de Datos. Además, contiene un  conjunto de metadatos que configuran el trabajo con dichos datos. Esos metadatos pueden incluir desde el nivel de traza con el que deseamos tracear el trabajo del motor de persistencia hasta los datos necesarios para crear una conexión directa a la base de datos y hacer que nuestra aplicación no dependa del registro de un datasource en el servidor de aplicaciones.

Las unidades de persistencia y sus atributos se definen en el fichero persistence.xml. Puede que hayais oído que este fichero se coloca en el directorio /META-INF de nuestra aplicación. Bueno, pues si pero no. No está de más leernos lo que nos dice la propia SUN sobre el tema. Son cuatro reglas, pero nos puede evitar numerosas y crípticas com.boni.CascotazoException con trazas similares al comportamiento de Matrix.

Lo primero que pide el wizard es un nombre con el que identificar a nuestra unidad de persistencia. Si sólo tenemos configurada una única unidad de persistencia, se seleccionará la misma como unidad por defecto. Si tenemos más de una -por ejemplo, una para desarrollo y otro para pruebas en un entorno de integración- podremos utilizar una u otra identificándolas a partir de su nombre.

Lo siguiente que pide el wizard es el proveedor de persistencia o Persistence Provider. Básicamente, la implementación de la API de JPA que deseamos utilizar. NetBeans incluye varias implementaciones pero, si queréis utilizar JPA2, la única opción que podéis elegir es EclipseLink.

El tercer dato que pide el wizard es la fuente de datos o Data Source con el que va a trabajar la Unidad de Persistencia. Podéis dejar vacío este campo y crear la unidad de persistencia sin Data Source asociado pero yo no os lo recomiendo. Eso obligaría a registrar en el fichero persistence.xml todas las propiedades -especificas para cada proveedor de persistencia- necesarias para crear localmente el Data Source y, lo que es peor, el tipo de transacciones siempre debería ser RESOURCE_LOCAL, no JTA. ¿Es eso malo? No tiene porque serlo, pero ¿por que restringir vuestra libertad de opción?.

Si aún así, queréis hacerlo, aquí tenéis dos buenos ejemplos de como hacerlo.

En el caso de que me hagáis caso y decidáis utilizar un Data Source, recordad que vais a desarrollar una aplicación para desplegar en el Glassfish v3 que configurasteis en el artículo anterior. El Data Source de JPA se corresponde con el Recurso JDBC de Glassfish. Yo configuré mi recurso con el nombre global JNDI jdbc/states, así que este es el nombre con el que voy a registrar mi Data Source en mi unidad de persistencia. Cuando despliegue la aplicación en Glassfish, el acceso a datos estará configurado automáticamente.

También podéis recrear el Data Source en NetBeans ¿Para qué? Para poder crear clases de entidad a partir de tablas, mediante wizards del IDE; validar que vuestro modelo se ajuste a vuestras clases, etc. Tener el Data Source de vuestro servidor de aplicaciones configurado en el IDE es guayabero, guayabero y, encima, bastante sencillo de implementar hasta bajo nivel, la conexión física. Os dejo una ruta gráfica:

Como configurar un Data Source en NetBeans

Una vez creado (o no) el Data Source de la Unidad de Persistencia, encontramos en el wizard un checkbox que permite indicar si se desea trabajar con o sin JTA, o lo que es lo mismo, si queremos que el contenedor gestione las transacciones por nosotros o queremos meter mano y configurarlas a pelo Capello. La elección es vuestra pero, personalmente, me fio bastante mas del contenedor que de mi mismo. De hecho, me fio bastante mas de que el Atleti gane 10 años seguidos la Champions League de que yo no me deje alguna transaccion abierta donde no deba.

La gestión local de transacciones sólo se recomienda en casos muy específicos, donde se desea tener control de transaccionalidad intra-método de EJB.

Dependiendo de vuestra elección, se creará un jta-data-source, para trabajar con Data Sources gestionados con JTA, o un  non-jta-data-source, para los Data Sources que no trabajen con JTA.

La última opción que presenta el wizard es la estrategia de creación de tablas. Dependiendo de la estrategia seleccionada, el IDE intentará o no crear las tablas en vuestra base de datos si no las encuentra.

Finalmente, la configuración de mi wizard queda tal que así:

El New Persistence Unit wizard

Una vez creada la Unidad de Persistencia, estamos preparados para crear código con JPA2, JTA, transacciones, bloqueos y hasta tirabuzones triples… pero eso lo veremos en la siguiente entrega.

De nuevo, nos hemos ido hasta cerca de las 1500 palabras, sobrepasando con mucho el máximo deseable para un artículo en un blog. Así pues, os emplazo a una tercera y espero que definitiva entrega… si aún os siguen quedando ganas de trabajar con EJB3.1 y JPA2 :)

DISCLAIMER

No tengo mucho feedback sobre esta serie de artículos, exceptuando las del ya mítico Dr. Arranz y mis secuaces tuiteros. Una sensación de tostón técnico invade todo mi ser, así que, si tienes algún consejo o sugerencia para mejorar la tercera entrega, no dudes en hacérmelo saber.

Artículos relacionados:

1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

No me gusta tener que partir los artículos pero, la verdad es que está quedando francamente largo y corría el riesgo de convertirse en un ladrillo infumable.

La teoría dice que el código proporcionado en este tutorial debería funcionar en cualquier servidor de aplicaciones compatible con Java EE6 y con cualquier implementación de JPA2, pero la teoría también decía que en Irak había armas de destrucción masiva… y aún las están buscando.

Glassfish v3 y Netbeans 6.8 -el IDE mejor integrado con este servidor de aplicaciones- tienen soporte nativo de EclipseLink, la implementación de referencia de JPA2 y vástago hipermineralizado y supervitaminado de Oracle Toplink.

Hay otras implementaciones de JPA2, como la de Hibernate 3.5 -lanzada el 31 de marzo de este año- o la de openJPA 2 -lanzada el 22 de abril-, pero como habéis podido comprobar son versiones muy recientes, no maduras y que pueden funcionar como los pimientos de Padrón: a veces si y a veces non.

1. CREANDO NUESTRA BASE DE DATOS DE PRUEBAS

Lo primero que debemos hacer es montar una pequeña base de datos con la que trabajará nuestro prototipo. Vamos a crear una típica estructura cabecera-lineas, donde un cliente puede tener de 0 a n pedidos asociados, teniendo en cuenta que un pedido puede crearse sin asociar a ningún cliente:

¿Que porqué le he puesto esos nombroncios a las tablas? Pues porque así los debí encontrar en alguno de las decenas de ejemplos que he visto para destilar este tutorial y así se quedaron.

En cualquier caso, en este enlace tenéis el script SQL necesario para crear las tablas, tal y como yo las he creado. He generado el script haciendo ingeniera inversa con nuestra base de datos -una vez más, vaguería pura- pero debe funcionar as-is, o con pequeños cambios, en cualquier base de datos.

2. INSTALANDO Y CONFIGURANDO GLASSFISH

No voy a perder ni un instante en explicaros como instalar Glassfish. Primero, porque es más sencillo que el asa de un cubo y, segundo; porque si yo he sido capaz de leer y comprender este pequeño ladrillete de 32 páginas, cualquiera podéis hacerlo.

Una vez instalado el Glassfish v3 y creada nuestra base de datos, tenemos que configurar un Data Source o fuente de datos que nos permita acceder y modificar la estructura creada en el punto anterior, siguiendo los siguientes pasos:

• Cargar la librería JDBC de acceso a nuestra base de datos en el classpath de Glassfish: Para hacerlo, debemos copiar el jar de la librería en la siguiente ruta /instalación de glassfish/domains/dominio que vayamos a utilizar (normalmente, domain1)/lib. En mi caso en concreto, con Glassfish instalado en Windows, la ruta es “c:\Archivos de programa\sges-v3\glassfish\domains\domain1\lib\” y ahi he copiado la librería JDBC especifica para bases de datos Oracle:  ojdbc14_g.jar.
• Crear un nuevo conjunto de conexiones o Connection Pool en el servidor: a través de la dirección http://localhost:4848 podréis acceder a la consola de administración de Glassfish. Si navegáis por el árbol de opciones hasta Recursos >> JDBC >> Conjunto de Conexiones, veréis algunos creados por defecto en el servidor y podréis crear uno mediante el botón ‘Nuevo’. Al crear un nuevo conjunto de conexiones, nos preguntará por la Base de Datos con la que vamos a trabajar, básicamente, para que no tengamos que configurar a manubrio la clase de implementación de la interfaz java.sql.Driver. También nos pedirá que indiquemos el tipo de recurso JDBC que deseamos crear. En el segundo paso de la creación, se indica la configuración propiamente dicha, desde el número de conexiones a el host, usuario y password de la base de datos en si. Pero lo realmente importante, es la configuración de la transaccionalidad del DataSource. Para no eternizarnos explicando parámetro a parámetro lo que hay que poner, os pongo una copia de mi DataSource, configurada para una base de datos Oracle, que está en un host denominado NEDWARD (por NED FLANDERS)

Pulsa sobre la imagen para verla grandota

Pulsa en la imagen para que se vea grandota

• Por último, tendréis que crear un Recurso JDBC que no es, ni mas ni menos, que un envoltorio que pondrá Glassfish sobre vuestro conjunto de conexiones y al que daréis un nombre JNDI con el que lo identificareis en vuestras aplicaciones. Os muestro, de nuevo, mi interfaz de configuración, donde he creado un Recurso JDBC con el nombre JNDI jdbc/states.

Pulsa en la imagen para que se vea grande como Australia

Con esto hemos acabado toda la configuración de Glassfish que necesitamos para ejecutar este ejemplo. A partir de ahora, es cuando viene el caviar… :)

Permaneced atentos a la segunda parte del artículo.

Artículos relacionados:

1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...

RT @abstrusegoose

Existen muchas dudas sobre el contenido y valía de esta certificación. En algunos casos, porque hay gente que no sabe (o no sabe BIEN) qué es eso de scrum; y, en otros casos, porque los que sí conocen scrum no entienden qué valor puede aportar una certificación sobre la materia.

No voy a escribir otro artículo sobre qué es scrum -hay mucha y buena literatura sobre la materia- pero si os voy a contar mi opinión y sensaciones sobre el curso en concreto.

La primera pregunta que debo responder es: ¿Mereció la pena asistir al curso? Sí, sin duda. Es uno de los mejores cursos a los que he asistido. No sólo por el contenido del mismo, sino por la forma de estructurar y enfocar la materia que practicaron los dos profesores.

Durante dos días, no vimos ni una sola diapositiva ni encendimos un ordenador. El planteamiento, desde luego, fue algo refrescante para aquellos que provenimos del mundo de la informática. A través de actividades y juegos como “El hipnotizador Colombiano” o “El vampiro de Hamburgo”, aprendí aspectos del comportamiento humano sobre los que asienta scrum su pragmatismo.

Que había que demostrar la resolución de sistemas complejos mediante empirismo, pues nos ponían a dibujar triángulos isósceles trotando por un plano que era la clase y donde los vértices éramos nosotros mismos. Que había que poner en práctica scrum y ver cómo lo practicábamos (mal), pues a jugar al famoso “Juego del Pajarraco“, inventando por Alan.

Creedme, ver a 20 adultos tirados en el suelo, construyendo un pajarraco con piezas de Lego, estresados ante la presión del tiempo y un montón de requisitos cambiantes, es algo digno de ver. Y muy muy pedagógico.

Ariel y Alan no se limitan a dictarte las reglas de scrum que cualquiera puede encontrar en Internet. No te enseñan scrum, te hacen VIVIR scrum.

El sello de Certified Scrum Master. Para molar.

Por otro lado, asistir al curso te da derecho a hacer el examen de Scrum Master certificado por la Scrum Alliance (CSM). Lo que en la práctica supone certificarte automáticamente, puesto que el examen sólo es una mera prueba de auto-evaluación: no se puede suspender.

Realmente, la certificación como Scrum Master significa que asististe durante dos días a un curso impartido por un pedagogo reconocido por la Scrum Alliance. Ni más ni menos. ¡Ah, sí! Y que puedes adornar tu blog y tu curriculum con este logo tan chulo de aquí a la derecha. Es naranja, tiene círculos y una cresta… y se parece sospechosamente a un logro de videojuego de la 360.

Eso si, tener el CSM es uno de los requisitos que se exigen para convertirte en Certified Scrum Professional o CSP, el siguiente paso que debes dar si quieres dedicarte a enseñar scrum al resto del mundo con el respaldo de la Scrum Alliance.

Como conclusión: sí, recomiendo el curso de Certified Scrum Master, pero lo que de verdad os recomiendo es el curso de Certified Scrum Master impartido por Alan y Ariel que es el que yo viví y disfruté. En mi caso, ellos y la fantástica dinámica de grupo creada junto a todos mis compañeros fueron los que hicieron especiales y mágicos esos dos días.

¿EPÍLOGO… O PRÓLOGO?

El lunes llegué al trabajo y comencé a explicar scrum de una manera natural a un equipo que no lo conocía. No sólo tenía los conocimientos, los había interiorizado. Conceptualizábamos, priorizábamos y planificábamos nuestro primer ‘proyecto’ scrum: un curso de formación para nuevos usuarios de nuestra aplicación de almacenes.

Por supuesto, tuve que afrontar las preguntas más o menos inquisitorias de los más escépticos con el marco de trabajo. Algunas eran de libro. Otras, sin embargo, las pude responder improvisando con las técnicas y conocimientos que me habían enseñado la semana pasada. Me sentí bien. Me sentí seguro. No era un mero robot que repetia las cuatro normas del marco de trabajo. Era un Scrum Master (novato) que utilizaba la visión y los valores de scrum para responder a las dudas y preguntas del equipo. Alan y Ariel me habían preparado bien.

No debí hacerlo del todo mal porque un compañero me felicitó por la charla durante la hora de la comida “Me gusta scrum. Encaja. Parece que tiene respuestas para todo“.

No estoy seguro de que scrum tenga respuestas para todo, pero sí sé que quiero ir contestando las preguntas poco a poco. Como mis profesores dicen: el curso no es más que el primer paso en un largo, larguísimo camino.

Nuestro primer taskboard

]]> http://sixservix.com/blog/david/2010/04/27/scrum-master/feed/ 4 http://sixservix.com/blog/david/2010/03/03/tagging/ http://sixservix.com/blog/david/2010/03/03/tagging/#comments Wed, 03 Mar 2010 05:50:31 +0000 David Bonilla http://sixservix.com/blog/david/?p=1726 Tradicionalmente, los informáticos hemos categorizado la información para estructurarla y facilitar el trabajo con ella. Sin embargo, parece que el trabajo con categorías ha quedado desfasado tras la irrupción del mundo web 2.0. Han llegado las tags, las etiquetas y, con éstas, toda una revolución de la forma en la que gestionamos nuestra información. ¿Han muerto las categorías? ¿Qué son exactamente eso de las tags? Si debes diseñar una aplicación, es importante que conozcas las diferencias entre unas y otras.

Una etiqueta o tag es un término no jerárquico asociado a una porción de información determinada, que funciona como un metadato que contribuye a la descripción de la información en sí y permite que dicha información sea recuperada en búsquedas posteriores.

Lo importante, lo único realmente importante del ‘frasón‘ anterior y lo que distingue una categoría de una etiqueta es que esta última no es jerárquica.

Mientras que es posible definir una categoría como un elemento estructurado que permite facilitar la navegación por la misma, una etiqueta puede usarse libremente sin jerarquía alguna. Así, por ejemplo, cuando visitamos un artículo perteneciente a la categoría ‘deportes’ podemos navegar por las categorías inferiores ‘fútbol‘ o ‘ciclismo‘; o navegar por la categoría superior ‘hobbies‘. En cambio, si utilizamos tags, el artículo tendrá un conjunto de etiquetas, como ‘fútbol‘ ‘Atlético de Madrid‘ o ‘Cristiano Ronaldo‘, sin ninguna relación entre sí más que la propia asociación con dicho artículo.

VENTAJAS Y DESVENTAJAS DEL USO DE CATEGORÍAS Y ETIQUETAS

La principal ventaja de las categorías es que permiten estructurar la información y, si se usan adecuadamente, no tienen un número muy elevado. Esto permite que las búsquedas de información mediante la navegación por las categorías sea cómoda y sencilla.

El inconveniente de las categorías viene precisamente de su número limitado y su rigidez. Son creadas por administradores y es posible que no cumplan todas las necesidades de categorización de los usuarios o que estos usuarios no sepan cómo utilizarlas correctamente.

Las etiquetas tienen la ventaja de que no están predefinidas. El propio usuario las crea y las usa. No existe el problema de elegir la categoría apropiada para una información; se crean y se asocian las etiquetas  que mejor representen el contenido.

El problema de las etiquetas es que la creación y el uso de las mismas implica la aparición de homónimos (etiquetas que se usan con diferentes significados) y sinónimos (múltiples etiquetas con el mismo significado), lo que puede dificultar la búsqueda de la información etiquetada.

CUÁNDO UTILIZAR CATEGORÍAS Y CUÁNDO UTILIZAR ETIQUETAS

Una vez comprendidos los pros y contras de categorías y etiquetas, podemos decidir cuándo es adecuado utilizar categorías, tags o ambos conceptos para catalogar nuestra información. Aunque parece que se pueden extraer dos conceptos claros:

• Si la creación de información depende de procesos propios de nuestra aplicación y dicha información puede ser validada y catalogada de forma más o menos automática, entonces el uso de categorías parece lo más adecuado.
• Si la información tiene múltiples orígenes con criterios de creación heterogéneos, parece más adecuado el uso de etiquetas.

El uso de tags se ha extendido exponencialmente desde el comienzo de la web 2.0 y la web semántica, debido a que la información es creada de forma directa por los propios usuarios de las aplicaciones, en vez de por los administradores de las mismas. Si tienes un sitio como YouTube, parece que no tiene mucho sentido que crees unas categorías predefinidas para los vídeos, seguro que tus usuarios acabarán sorprendiéndote.

Sin embargo, sería absurdo que limitáramos el uso de las tags o etiquetas a las aplicaciones de web 2.0. Se pueden utilizar perfectamente en cualquier tipo de aplicaciones informáticas. En mi caso, por ejemplo, en algo ’supuestamente’ tan alejado como la gestión de pedidos de STORETTO.

Al enfrentarse a los pedidos de mercancía por parte de clientes, los usuarios de la aplicación se han encontrado con que la categorización de las salidas (simples, a punto de entrega, recogida, devolución, etc.) y los atributos de las mismas no podrían cubrir la infinita casuística que supone la distribución de bebidas y alimentación. Así, fue natural que solicitaran el uso de etiquetas para los pedidos… aún cuando ni siquiera conocían el concepto de tagging.

Ahora, los usuarios de storetto pueden trabajar con pedidos de tipo simple o a punto de entrega y varios más (cada uno con su propia y especifica lógica de negocio) Además, pueden etiquetarlos con términos de lo más pintoresco: ‘mercancía peligrosa‘, ‘para la ruta de Xirivella‘, ‘miércoles‘, ‘trailer‘, ‘Carlos‘ o ‘pagado‘, por poner algunos ejemplos.

No es que seamos unos pioneros, ya se puede ver el uso de tagging en los ámbitos más diversos, desde la gestión de ficheros de Güindous, los marcadores de Firefox o en aplicaciones web tan conocidas como JIRA.

Los desarrolladores tendemos a autoformarnos en tecnología pura y dura. Como mucho, invertimos tiempo en aprender y memorizar como mandriles patrones de diseño, sin darnos cuenta de que repetimos  muchos de estos patrones sin plantearnos si hay otras opciones más optimas. Espero que este artículo haya abierto los ojos a más de un diseñador de aplicaciones, como yo los abrí en su momento. Sin caer en la tentación de meter etiquetas con calzador en cualquier rincón de nuestra aplicación, hay que considerar el tagging o etiquetado como un recurso de diseño que no debemos despreciar.

BIBLIOGRAFÍA Y ENLACES

• Tag como metadato (Wikipedia)
• Knowledge Tag (Wikipedia)
• Categories vs. Tags (Haacked.com)
• Categories vs. Tags in blogs (Duncan McKenzie)
• Categories vs. Tags (Usabilitypost.com)

Afortunadamente, cuando se trabaja con java no se utilizan estos ficheros de configuración externos. Se pueden guardar y utilizar las adenas de conexión y usarlas directamente con el driver JDBC de tipo 4 de Oracle, pero  siguen siendo necesarios para usar cualquier cliente o programa que utilice el driver nativo de la base de datos como el PL/SQL Developer o el Toad.

La teoría dice que la variable de entorno TNS_ADMIN es la que configura la ruta donde se encuentra el fichero de configuración tnsnames.ora, pero la cosa se empieza a complicar cuando también se involucra a la variable de entorno PATH.

Cualquier instalación de un producto de Oracle -desde Weblogic a Discoverer- suele manipular la variable de entorno PATH, lo que puede provocar, desde el sorpresivo cambio de la versión de JDK de java que se esta utilizando… hasta el cambio de tnsnames.ora que configura el acceso a base de datos Oracle del sistema.

Para acabar de rematar la faena, Oracle utiliza una búsqueda jerárquica de ficheros de configuración y, además, esta jerarquía es distinta según el sistema operativo utilizado. Hasta puede llegar a utilizar configuración guardada en otra fichero de configuración: sqlnet.ora, lo que puede volver loco al programador mas duro.

Hay un truco para solucionar este problema y averiguar el fichero que configura las conexiones a Oracle: el comando tnsping.

El comando tnsping sirve, originalmente, para hacer un ping que compruebe la conexión a una base de datos remota mediante la siguiente sintaxis:

tnsping alias_de_base_de_datos

Pero, además, tnsping indica la ruta física del fichero de configuración y la propia instalación de Oracle hace que este disponible en el path del sistema, así, se puede utilizar para averiguar donde esta el fichero de configuración de las cadenas de conexión de nuestro sistema, haciendo ping a una base de datos existente o ficticia:

Artículos relacionados:

1. Compartiendo mesa y mantel con Oracle Ayer acudí a un encuentro de bloggers organizado por Oracle...

• ID: Identificador de la historia de usuario
• TÍTULO: Título descriptivo de la historia de usuario
• DESCRIPCIÓN: Descripción sintetizada de la historia de usuario
• ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al comienzo del proyecto)
• PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW:
  • M – Must, se debe completar este requerimiento para finalizar el proyecto
  • S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.
  • C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.
  • W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)
• DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las que depende una tarea

El ciclo de vida de la tarjeta se compone de tres fases, conocidas como “Las 3 C” por sus iniciales en inglés (Card, Conversation, Confirmation):

• TARJETA (Card), la creación de la tarjeta en sí, con la estructura definida anteriormente y que sirve para determinar QUÉ se debe hacer y cómo planificarlo.
• CONVERSACION (Conversation), representado por pequeños documentos y anotaciones que sirven para aportar detalles y refinar los datos sobre las características del requerimiento.
• CONFIRMACIÓN (Confirmation), o pruebas de aceptación. Pruebas consensuadas entre el cliente y el desarrollador y que el código debe superar para dar como finalizada la implementación del requerimiento.

(Gracias a Vicenç y Jasosa por el ejemplo incluido en la tarjeta)

Artículos relacionados:

1. Historias de Usuario vs. Casos de Uso Escribiendo documentación sobre metodologías ágiles en general y ‘buenas prácticas’...