Hoy es un buen día para empezar (y acabar) mi trabajo de fin de carrera o en otras palabras "Mi Tesis", el tema, como ya le comenté a algunos, es sobre BPM y será el punto sobre el cual muy probablemente hable en esta bitácora.

Después de un largo tiempo de descanso o más bien de relajo escribo algo sobre una tecnología que hasta el momento había esquivado pero por motivos de trabajo tuve que usar y creo que fue una buena excusa para darme cuenta de todo lo que me estaba perdiendo. Pues como dice el titulo esa tecnología es Maven, no voy a hablar mucho de los conceptos que giran alrededor pero si voy a dar alguna de sus características:

• Maneja las dependencias que tienes en la aplicación, viendo si es que una es requerida dentro del empaquetado final o si es requerida solo para compilación o si solo se necesita al momento de hacer pruebas.
• Es agnóstico del IDE así que cada miembro del equipo podría trabajar en diferentes entornos siempre y cuando respete la estructura de directorios que provee Maven.
• Al manejar un ciclo de vida para cada aplicación nos vemos obligados a realizar ciertas actividades que antes no hacíamos tales como las pruebas unitarias. Obviamente aun podemos hacerle "la jugada" pero no es recomendable.

Obviamente vamos a tener muchas mas características pero para mi son las que me atrajeron. Por otro lado tenemos que realizar una "instalación" lo cual en linux (Ubuntu en mi caso) lo traducimos en los siguientes pasos:

1. Descargar maven y descomprimir en alguna ruta en mi caso usaré /home/jlmanrique/maven, si al momento de descargar lo hacen usando el formato tar.bz2 deberan ejecutar el siguiente comando:

   $tar -jxvf archivo-descargado.tar.bz2

2. Una vez ubicado en esa ruta tenemos que poner en el path de nuestra linea de comandos, la idea es que al momento de poner mvn este llame al .jar de Maven y se realice el comando que pedimos. Para eso modificamos el archivo .bashrc el cual se encuentra en la ruta $HOME que en mi caso es /home/jlmanrique .
3. Una vez abierto el archivo ubicamos al final de este las siguientes lineas

   export M2_HOME=/home/jlmanrique/maven
   export M2=$M2_HOME/bin
   export PATH=$M2:$PATH
   export JAVA_HOME=/usr/lib/jvm/java-6-sun
   

   Estas son usadas para agregar al path la carpeta donde descomprimimos Maven y la ultima linea es para setear la variable JAVA_HOME que usaremos para trabajar con maven.
4. Finalmente solo nos queda abrir una nueva linea de comandos y ejecutar:

   $mvn -version

   Y así obtenemos

   Apache Maven 2.1.0 (r755702; 2009-03-18 14:10:27-0500)
   Java version: 1.6.0_03
   Java home: /usr/lib/jvm/java-6-sun-1.6.0.03/jre
   Default locale: es_PE, platform encoding: UTF-8
   OS name: "linux" version: "2.6.22-16-generic" arch: "i386" Family: "unix"
   

   O algo similar para el hardware que estén usando.

Con esos 4 pasos tendríamos nuestra configuración de Maven lista para ser usada, cualquier duda o comentario no duden en hacérmela llegar.

Todos los días de trabajo tengo una necesidad nueva, esta vez mi problema gira entorno a armar una imagen (.iso) para un DVD/CD este lo voy a montar en el file system y luego a ejecutarlo. Para realizar esta tarea voy a utilizar el comando mkisofs (el nombre suena como "make iso from file system" el nombre correcto creo yo) y ya que el objetivo es muy puntual solo queda ejecutar el siguiente comando:

$mkisofs -D -o miarchivo.iso /home/jlmanrique/DVD

Donde -D es para decir que se va a incluir directorios largos, -o indica que se va a ingresar el nombre del archivo, miarchivo.iso es el nombre del archivo a generar y /home/jlmanrique/DVD es la raíz desde donde se copiaran todos los archivos. Tener en cuenta que para un .iso podemos agregar mas rutas simplemente las tenemos que separar por un espacio. Finalmente esperamos unos momentos y tenemos nuestro archivo iso. Espero les sea de utilidad tanto como a mi.

Segundo domingo de mayo, las calles llenas, las tiendas con muchas ofertas y por donde vaya encontraré muchos "Feliz Día Mamá". Las personas compran cosas para sus abuelas, madres, esposas, hermanas, hijas, etc, buscan el mejor peluche, un buen perfume, ropa elegante, casual, sport cualquier cosa que le pueda ser útil o simplemente que en algún momento lo pueda usar. Lo cierto es que muchos recapacitamos este día acerca de la persona que tenemos (o tuvieron) a nuestro lado, recordamos las veces que le hicimos pasar una mala noche esperando a que lleguemos a casa o cuando se preocupa por que no llevamos comida o cuando en el trabajo nos quedamos hasta tarde. Los motivos para preocuparse sobran algunas lo hacen notar otras no pero siempre hay ese sentimiento. A todo esto aprovecho el momento para decir lo siguiente:

"Mamá no seré el mejor hijo del mundo, te hice (y seguiré) renegar muchas veces se que también no siempre compartimos las mismas opiniones pero a pesar de todo te quiero mucho y no cambiaría por nada todos los momentos que vivimos. Muchas gracias por todo."

La foto es de la graduación de primaria de mi hermana menor

La verdad es que a primera vista parece que eso no fuera cierto y para los usuarios de M$ Window$ hacer esto quiza requiera el uso de algún programa extra (si el propio SO lo tiene haganmelo saber) pero en un Unix común y corriente que posee el programa mount se puede hacer esta tarea.
La primera acción que debemos realizar es la creación de una carpeta donde iniciara el punto de montado eso lo hacemos ejecutando el siguiente comando:

$mkdir /home/jlmanrique/ISO_DVD

Seguido procedemos a realizar el respectivo montado, para eso ejecutamos el siguiente comando:

$sudo mount -o loop {nombre de imagen}.iso /home/jlmanrique/ISO_DVD

Para verificar que hemos realizado exitosamente el montado verificamos con un ls el contenido de la carpeta /home/jlmanrique/ISO_DVD . De esa forma realizamos el montado de un .iso en nuestro filesystem, ahora para que podría ser útil:

• Se te acabaron los cds y requieres levantar una imagen.
• Requieres copiar algunos archivos de una imagen (o todo el contenido).
• O como en mi caso, requieras hacer un appliance, descargaste el instalador (.iso) y como tu lectora de dvd no es quemadora se tu puede aguar la fiesta ya que requieres usar todos los archivos de la imagen.
• Simple gusto.

Si encuentras otro uso no dudes en dármelo a conocer.

Cuando uno ve la estructura de directorios de un Unix por primera vez puede apreciar que existe una raíz y a diferencia de M$ Window$ que tiene varias unidades y al comienzo pueden confundirlo a uno pero la verdad es que detras de todo esto hay una idea muy simple pero muy potente.
A fin de que tengan una pequeña idea de cuales son las carpetas que debemos de tener en cuenta al momento de ver un Unix les dejo el siguiente enlace el cual describe cada una de las carpetas mas importantes en un entorno de las X. En lo personal me sirvió mucho y quiza encuentren algunas diferencias sobre el tipo de Unix que estén usando pero la idea se mantiene, espero el enlace les sea de utilidad tanto como lo fue para mi.

Casi al finalizar el día de trabajo se presento una pregunta muy peculiar entre uno de mis compañeros de trabajo esta era sobre el uso del log4j en una aplicación. Para comentar un poco los hechos esto fue lo que realmente paso:

1. Me encontraba muy tranquilamente esperando a que el SuSE 10 en una máquina virtual y vi a un compañero programar unas cuantas lineas usando el system.out.println(), cuando lo revise le dije que seria mejor que use el logger para que pueda revisar lo que imprime su aplicación al momento de arrojar errores.
2. Lo siguiente fue una duda por como configurar esto a lo cual simplemente el dije que habia que agregar un nuevo appender (org.apache.log4j.ConsoleAppender) que se encargara de imprimir en la consola, una vez realizado esto procedimos cambiar el código para que utilizara el logger en modo ERROR ya que se pintaba un Exception (en este caso un java.lang.NullPointerException).
3. Luego de mostrarle algunos tips para utilizar el logger (el clasico logger.isDebugEnable y logger.isInfoEnable) le dije que utilizar el system.out.println() era para "Salvajes" haciendo referencia a que esa era una practica muy antigua (casi de la época de las cavernas).
4. Seguido de esto otra persona me dijo por que decía eso de utilizar el sysout ya que ambos cumplían con el mismo objetivo y que le parecía mas fácil el uso del sysout. Mi respuesta fue como diría un amigo "muy hábil" puesto que en ese momento se me ocurrió decir que era por una cuestión de performance.
5. Si esta persona se sentó creyendo que esta era una respuesta adecuada (al menos eso parecía) no tarde en darme cuenta de la tremenda tontería que había dicho (por lo cual pido las disculpas del caso) ya que la verdad es que al ser log4j un framework este agrega un determinado tiempo de llamada a los métodos para el pintado en un archivo, consola, etc y el formateo de los mismos dependiendo del patrón que estemos escogiendo. Todo este tiempo claro esta no es generado por el sysout y por ende a este lo hace "mas veloz" si se trata de escribir claro esta en el sysout.

Por un momento esto nos lleva a pensar cuales podrían ser los motivos que nos llevan a usar un framework para el manejo de logs y si realmente valen la pena usarlos ya que tendríamos mas tiempo de procesamiento para pintar en las diferentes salidas que necesitemos. La verdad es que a pesar de consumir mas tiempo del procesador si es muy necesario el uso de un framework para esta funcionalidad por eso voy a listar los motivos por los cuales uso el log4j para manejar mis archivos de log.

1. Todo framework tiene como objetivo el facilitarnos las tareas de algún campo en especifico y log4j no es la excepción a la regla puesto que su principal objetivo es ayudarnos con el manejo de los logs de nuestra aplicación ofreciéndonos una gran variedad de configuraciones que nos permitirán concentrarnos en nuestro problema real: Desarrollar una aplicación y no en desarrollar un buen manejo de logs.
2. Para realizar una buena configuración de log4j no se requiere tener conocimientos extremos de como abrir y cerrar un flujo y si lo estamos haciendo de la forma correcta o no, simplemente tenemos que utilizar los appenders que estan definidos como parte del framework dentro de los cuales tenemos el ConsoleAppender para escribir en la salida estándar, el DayliRollingFileAppender si deseamos que se cree un archivo de log cada dia que pasa, el RollingFileAppender el cual escribe de manera circular cada vez que el archivo llega a un determinado tamaño, el AsyncAppender para escribir de manera asíncrona en el archivo entre otros. En caso ninguno sea de nuestro agrado se puede extender (tomarlo como heredar de la clase o basarse en ella) cualquiera de estos a fin de obtener el manejo esperado.
3. Otra de las funcionalidades que tenemos es el formateo del mensaje a escribir esto lo hacemos usando plantillas que se llaman Layout, cada uno de estos describe el formato en el cual se escribirán nuestros mensajes, dentro de estos tenemos al HTMLLayout el cual ingresa cada uno de los logs como una linea de una tabla, el PatternLayout (el que mas uso) el cual escribe el log en base a un patrón ingresado en el archivo de configuración, el SimpleLayout el cual solamente describe el nivel del log y el mensaje, entre otros. Al igual que los Appender si ningún Layout es de nuestro agrado podemos crear el propio que cumpla con nuestro requerimiento, personalmente no he tenido la oportunidad de realizar dicha tarea puesto que con el PatternLayout realizo todas mis tareas.
4. Otra de las características que me agrada de este framework es el manejo de varios niveles del mensaje los cuales son: TRACE, DEBUG, INFO, WARN, ERROR y FATAL. El como manejarlos puede depender de cada uno, mi sugerencia es manejar cada mensaje informativo entre el TRACE, DEBUG e INFO el uso de cada uno deberá ser en el grado de importancia que se desee tener, para el caso de los mensajes en WARN lo utilizo para mostrar algún evento en el sistema que no es un error pero que si seria bueno documentarlo a fin de mostrar una advertencia en el log, el uso del ERROR es para mostrar errores del sistema y el FATAL es cuando queremos pintar algún mensaje antes de detener el servicio totalmente. Esta es la "formula" que hasta el momento me ha servido para manejar los niveles de mis mensajes.
5. El manejo de diferentes fuentes de impresión del log dependerá de la cantidad de Appenders que nosotros registremos en nuestra configuración, para el programador el escribir en una fuente o en cinco es transparente el solo tiene que decir que tipo de mensaje quiere imprimir y el framework se encargará de realizar las impresiones necesarias. En el caso de utilizar el sysout uno debe de indicar manualmente donde realiza la impresión y si se quiere quitar una fuente se deberla de volver a compilar la aplicación a fin de efectuar el cambio.
6. Regresando a los niveles de log el utilizar un nivel u otro y mostrar o algunos mensajes o no es tan trivial como modificar un archivo de configuración (properties o xml) el desarrollador no tiene que modificar código fuente para realizar el cambio y mucho menos tiene que recompilar la aplicación para realizar estos cambios, lo cual lo pone un paso adelante del manejo del sysout.
7. Finalmente la mejor opción por la cual usuaria el log4j en vez del sysout es por que si realizo un buen uso de los niveles de mensajes en el código no requiero iniciar la aplicación en modo debug lo cual nos ahorra tiempo al momento de depurar errores puesto que todos estos se encuentran debidamente documentados en un archivo, consola, base de datos, etc.

Si a pesar de todo esto aun no quieres usar el log4j o algún otro framework pues solo me queda decirte que mas adelante tendrás muchos problemas o acabarás creando tu propio framework para pintar tus eventos. Para que reinventar la rueda si esta funciona y muy bien, espero este post sea de su agrado.

El dia de hoy tuve un gran problema al momento de utilizar una herramienta llamada mmtools de IBM esta me pedía utilizar un DVD que tuviera el instalador del sistema operativo pero yo solo contaba con los CDs. Luego de buscar en google un rato encontré una herramienta llamada makeSUSEdvd que justamente hacia lo que requería. La instalación de esta herramienta es muy simple, se descarga el rpm del site y se procede a ejecutar el siguiente comando:

$sudo rpm -i makeSUSEdvd-0.45.1-1.44.noarch.rpm --nodeps

El parámetro nodeps es para que al momento de la instalación del rpm este no verifique las dependencias. Una vez realizado esto procedemos a ejecutar la herramienta pero en modo interactivo el cual simula un wizard a medida que va avanzando va haciendo preguntas acerca de información posees, para realizar esto usamos el siguiente comando:

$sudo makeSUSEdvd -I

En mi caso ingrese la siguiente información:

• Requiero crear una carpeta.
• El directorio de la carpeta sera: /home/jlmanrique/SUSE_DVD.
• No requiero rpms adicionales.
• Para la creación estoy usando cds.
• El punto de montado de los cds sera: /home/jlmanrique/SUSE_CD

Es muy probable que te preguntes como hago para cambiar el punto de montado de mi lectora de cd ya que por lo general estos se configuran solos en /media/XXXX (en mi caso fue en /media/SLES10_00X donde X es el numero de disco), pues para realizar esto deberás primero ubicar el archivo al cual hace referencia tu lectora esto lo revisas usando el comando df. Una vez ejecutado este comando podrás ver otros dispositivos como tus discos duros, en mi caso la lectora se encuentra en la ruta /dev/sr0 . Ya con el dispositivo ubicado se procede a realizar el desmontado y montado de la lectora, esto lo realizamos con los siguientes comandos:

$#Desmontado del dispositivo
$sudo umount /dev/sr0 #cambiar por el dispositivo
$#Montado del dispositivo
$sudo mount /dev/sr0 /home/jlmanrique/SUSE_CD #carpeta indicada antes

Regresando a la creación del DVD una vez ingresada toda la información que pide la herramienta, esta nos requerirá que se ingresen uno a uno los cds para esto debemos de realizar el procedimiento para realizar el desmontado y montado en una carpeta diferente. A medida que vamos ingresando la herramienta unira estos cds en una sola imagen. Para finalizar la creación se deberá presionar cualquier tecla diferente a ENTER y a disfrutar del DVD de instalación de SuSE.

Hace poco tuve que realizar una instalación de cvs en un servidor que tenia SuSE 10 Enterprise Edition. La configuración de este servicio ya la había realizando antes en Ubuntu así que procedí a realizar los mismos pasos, los cuales son:

1. Creación del grupo y usuario para la ejecución del servicio.
2. Creación de las carpetas.
3. Verificación de los paquetes cvs y xinetd.
4. Inicialización del repositorio.
5. Configuración del servicio en xinedt.

Para realizar todas estas actividades requerimos tener acceso al usuario root del servidor, por lo tanto nuestra primera accion sera:

$su root

Una vez ingresada la contraseña, procedemos a la creación del grupo y usuario, para esto utilizamos los comandos "useradd" y "groupadd" los cuales son usados para crear usuarios y grupos respectivamente. Estos comandos los ejecutamos de la siguiente forma:

$groupadd cvs
$useradd -d /home/admincvs -g cvs -m admincvs

Como pueden apreciar en la ultima linea se creó un usuario pero en ningún momento le asignamos una contraseña, para realizar esta tarea utilizamos el comando "passwd" para esto utilizamos la siguientes linea:

$echo {ingresar password} > pw
$cat pw | passwd --stdin admincvs 

Con el usuario listo para ser usado procedemos a crear la carpeta donde vamos a ubicar nuestro repositorio, para esto ejecutamos la siguiente linea:

$mkdir -p /var/repositorios/proyecto

Utilizamos la opción "-p" para que se fuerze a la creación de las carpetas que no estén creadas. Una vez finalizado procedemos a revisar si los paquetes cvs y xinetd se encuentran instalados para eso verificamos en el yast que estos programas se encuentren instalados de no estarlo procedemos a buscarlos e instalarlos. En la figura se muestra una pantalla del yast2 (manejador de paquetes) en la cual se va a agregar el xinetd. El siguiente paso es inicializar nuestro repositorio por lo cual creamos una variable de entorno en la cual vamos a almacenar la ruta de nuestro repositorio (solo para la consola que se esta usando) llamada CVSROOT ejecutando el siguiente comando:

$export CVSROOT=/var/repositorios/proyecto

Seguido de eso ejecutamos el comando de inicialización y cambiamos el usuario de los archivos creados por el proceso anterior:

$cvs init
$chown -R admincvs:cvs /var/repositorios/proyecto

El programa "cvs" tomará la variable CVSROOT y procederá a iniciar el repositorio creando una carpeta con el mismo nombre dentro de la ruta indicada. Dentro de esta carpeta se deberá crear un archivo llamado passwd que contendrá todos los usuarios que usarán en repositorio, estos deben ser ingresados de la siguiente forma {usuario}:{password_encriptado}:{usuario_sistema} donde usuario_sistema es le usuario que creamos anteriormente, todos los archivos que se van a crear en el repositorio serán usando este usuario. Como se puede apreciar el password ingresado debe estar cifrado para realizar la encriptación del mismo se debe de ejecutar el siguiente script (en Perl):

#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}\n";

Este se encargará de cifrar la contraseña para ejecutarlo correctamente el archivo en el cual se almacene debe tener permisos de ejecución y lectura (como mínimo) y pasar como argumento el valor a encriptar. Como último paso de nuestra configuración se deberá configurar el xinetd para que nuestro repositorio pueda ser visible para los demás. Para esto creamos el archivo "cvspserver" en la ruta /etc/xinetd.d/ y le ponemos el siguiente contenido:

#Inicio de configuracion cvspserver
service cvspserver{
       port           = 2401
       socket_type    = stream
       protocol       = tcp
       wait           = no
       user           = admincvs #El usuario que creamos
       passenv        = PATH
       server         = /usr/bin/cvs #Ubicacion del programa
       server_args    = -f --allow-root=/var/repositorios/proyecto pserver
}
#Fin de configuracion cvspserver

Finalmente reiniciamos el servicio del xinetd utilizando el siguiente comando:

$/etc/rc.d/xinetd.d/xinetd reload

Y tenemos listo nuestro repositorio con todo lo necesario para que varios usuario se puedan conectar subir sus versiones y descargar las de los demás.

Hace unos pocos dias me enteré, gracias a Bruno, que la empresa JoeDayz esta organizando un evento denominado Spring Live Perú 2009, el cual tiene como objetivo el difundir el uso de framework Spring. Ya que Spring es algo que yo veo desde hace ya un año y he usado muchos de sus módulos me animé a participar. Hasta el momento se tienen confirmados los siguientes expositores:

• Spring Framework (José Díaz - JoeDayz)
• Domain Driven Design Aplicado (Juan Carlos Vergara - AgileWorks)
• Desarrollando Aplicaciones con Flex y Spring (Ricardo Avila - BSE)
• Persistencia con Hibernate (Christian Komiya - JoeDayz)
• Desarrollo de Aplicaciones Web Enriquecidas con Spring (Susan Inga - JoeDayz)
• Spring .Net essentials (Christian Palomares Peralta - SSS)
• Desarrollo de Aplicaciones Web con ExtJs (Mayer Horna - Freelance)
• Aspect Oriented Programming (Jose Luis Manrique Cabana - Freelance)

El evento tendrá lugar en el Aula Magna de la Facultad de Ing. de Sistemas de la Universidad Nacional Mayor de San Marcos. Los horarios de las exposiciones aun no están confirmados espero no me toque cerrar la conferencia pero de serlo habría que preparar algo mas interesante. Como nota curiosa dentro de los expositores tengo a dos amigos Susan Inga y Christian Palomares, los dos son de mi casa de estudios y he llevado algunos cursos con ellos, desde ya les puedo decir que sus ponencias serán muy buenas. Para tener las ultimas noticias del evento les recomiendo suscribirse a la pagina de JoeDayz: http://www.joedayz.org . Spring Live Perú 2009, here I go!!!!

Recordar es volver a vivir y en este caso lo que voy a recordar es un juego que me mantuvo horas de horas entretenido el cual es Heretic. Este esta basado en el motor de juegos de Doom (otro juego genial) y su tematica es sobre una especie de edad media llena de magos, demonios y demás. Originalmente este juego solo estaba disponible para Windows pero luego liberaron las fuentes y ya se pudo tener una versión para Linux. Durante un par de horas estuve viendo cual seria la mejor opción para instalarlo en mi PC, habían dos posibilidades:

1. Utilizar el instalador en RPM del juego.
2. Usar un simulador de DOS e instalar el juego desde ahi.

Siendo sinceros probé las dos opciones, en el primer caso como la distribución que uso es Ubuntu tuve que instalar el programa alien de la siguiente forma:

$sudo apt-get install alien

Una vez realizado esto procedí a transformar cada uno de los .rpm a .deb de la siguiente forma:

$sudo alien xxxxx.rpm

Y finalmente instalé todos los rpm, el resultado no me fue el esperado puesto que iniciando nomas se caia el juego y obviamente no podía seguir. Luego de ver como fallaba la primera opción (que se veía mejor) decidí poner en práctica la segunda opción que era utilizar un simulador de DOS, en este caso utilicé el DOSBox el cual ya habia visto hace tiempo y lo use en Windows XP con buenos resultados. Para realizar la instalación se pone el siguiente comando:

$sudo apt-get install dosbox

Ejecutamos el dosbox:

$dosbox

Y montamos una carpeta de nuestro filesystem para que la tome como un driver de Windows (C, D, E, F, etc), para eso ejecutamos lo siguiente:

Z:/mount D /home/jlmanrique/D_dosbox

En esa linea simplemente le indicamos al DOSBox que vamos a montar la ruta de /home/jlmanrique/D_dosbox como el driver D. Luego procedemos a copiar los instaladores y finalmente a ejecutarlos. Tenemos el siguiente resultado: Pantalla de Inicio: Ubicación en los directorios: Pantalla final del juego: Espero les haya gustado y si lo llegan a instalar diviertanse.

En la anterior entrega tocamos el tema del manejo de la configuración en el portal ,las estrategias para utilizar efectivamente cada una de las facilidades de los Portlets y los motivos por los cuales usar uno u otro.

En este post trataremos un tema muy delicado el cual es el manejo de la sesión de nuestra aplicación sin mas preámbulos empiezo a detallar cada una de las buenas practicas al respecto.

• Limitar el uso de la sesión del portlet. La recomendación es muy explicita para este caso no se debe de abusar del uso de la sesión, no cualquier dato debe ser almacenado en esa área. En este punto tenemos dos ejemplos el primero es el almacenar un objeto que es muy costoso en ser construido/obtenido en este caso si recomiendo que sea almacenado en sesión para que no se incurra en el costo de tener que crear un nuevo objeto por cada request (render y/o action) y el segundo caso es de un objeto que puede ser generado en cualquier momento y no implica mucho costo para el sistema (un listado de tipos de documentos) estos no tendrían por que ser almacenados en la sesión puesto que aun se puede asumir el costo de su construcción. Si eres de los que le gusta usar la sesión para todo pues es momento que analices que debe de ir o no dentro de tal forma que evitas los famosos java.lang.OutOfMemoryError.
  
• Evitar el uso de la sesión si es que el portlet puede ser accedido por anónimos. Tiene mucho sentido puesto que la sesión debe ser usada justamente cuando el usuario se ha conectado a la aplicación previa validación de usuario y contraseña. Si el portlet esta disponible para cualquier usuario eso quiere decir que la información que se muestra no es sensible por lo tanto algunos datos se podrían manejar usando campos ocultos (inputs hidden dentro del formulario). Por el momento no me ha tocado crear un portlet para usuarios anónimos pero es mas que seguro que tendré en cuenta esta recomendación para futuros desarrollos.
• Siempre usar PortletRequest.getPortletSession() para obtener una sesión valida. Hasta el momento no se como obtener una nueva sesión que no sea de esa forma pero si la hay no debería usarse puesto que se podría estar obteniendo un valor invalido.

Finalmente podemos llegar a la conclusión que el uso de la sesión debe de realizarse con mucho cuidado y siempre teniendo en cuenta algunas consideraciones previas.

Para la siguiente entrega se tocará el tema de la internacionalización el cual tiene como objetivo mostrarnos algunas sugerencias para hacer que nuestro portlet muestre contenido dependiendo del idioma del cliente.

En el anterior post tocamos el manejo de los paquetes y utilitarios (falto poner el buen diseño de los Portlets) ahora nos toca hablar del manejo de la configuración en nuestra aplicación de portal.

Para empezar tenemos tres posibles lugares donde podemos almacenar nuestra configuración estos son: la configuración de portlet, los datos del portlet y la configuración del servlet.

A continuación detallaré cada uno de estos y cuando debe ser usado:

1. Configuración del portlet, este tipo debe ser usado cuando se desea almacenar algún parámetro propio del portlet y este no depende del usuario que se encuentra utilizando la aplicación. Este tipo de configuración se realiza por medio del archivo portlet.xml o también usando el modo config del portlet. Ahora cuando usar este tipo, por ejemplo el cambiar el origen de datos de un portlet para una determinada pagina.
2. Datos del portlet, este tipo debe ser usado cuando se desea almacenar algún parámetro propio del portlet pero dependiente del usuario que se encuentra utilizando la aplicación. Esta forma de configuración puede sobreescribir los datos manejados en el primer caso y la forma de administrar estos valores es usando el modo edit del portlet. Un buen ejemplo del uso de este parámetro podría ser la personalización del tamaño de paginación en un listado por parte del usuario.
   
3. Configuración del servlet, usamos esta forma de manejo de los parametros cuando queremos incluir valores que sabemos que no van a cambiar durante todo el ciclo de vida de la aplicación dentro del contenedor. El mas claro ejemplo seria utilizar esta forma para almacenar las rutas de donde se leerán los archivos de configuración (properties, xml, imagenes, etc), para esto utilizamos el archivo web.xml .

Como podemos apreciar para configurar nuestra aplicación tenemos tres formas cada una orientada a una situación en particular lo cual podría complicar al desarrollador, claro esta siempre y cuando no se tenga en cuenta cual es el objetivo de cada una de estas formas.
El próximo post tratará sobre el manejo de la sesión este tema deberá de tocarse muy a detalle por que muchos desarrolladores abusan de su uso y al final generan los famosos "Memory Leak".

En la segunda parte de las buenas practicas para el desarrollo de portlets hablamos sobre las consideraciones a tener en cuenta sobre los jsps en esta entrega trataremos el tema de los paquetes y utilitarios como poder distribuirlos y algunas sugerencias al respecto. Debido a que el articulo solo toca dos puntos no usaré los marcadores.

Empaquetar las funcionalidades comunes a los Portlets. Suena un poco raro al momento de leerlo en ingles pero quizá esta sea una traducción adecuada ya que el objetivo del mismo el de separar las funcionalidades comunes en un jar de tal manera que pueda ser reutilizable. Ahora supongamos que tenemos dos casos (los cuales detallaré) en los que nos podemos encontrar:

1. Se tiene una aplicación en portal y se tienen componentes de la capa de acceso a datos (en adelante DAO), estos componentes son compartidos por varios portlets dentro de la misma aplicación, la pregunta es ¿Será necesario separar el DAO en un jar aparte? La respuesta es NO, si ten encuentras en esta situación deberías de pensar en el patrón KISS (y no es el grupo) ya que la casuística no posee mucha complejidad y no requiere una separación.
2. Supongamos que tienes un caso un tanto similar al anterior solo que ese componente es usado por varios Portlets de muchas otras aplicaciones, pues el escenario cambia y en este caso para tener componentes reutilizables se debería crear un jar que posea este bloque de funcionalidades y simplemente durante el desplegado solo se haga referencia al mismo. Pero repetir el jar en todas nuestras aplicaciones con toda la funcionalidad incluida no seria muy útil por que nunca falta alguien que muy hábilmente modifique el jar y lo use inadecuadamente, para este caso el portal como framework nos ofrece la facilidad de exponer servicios propios. En el contenedor de WebSphere se utiliza la interfaz PortletService la cual indica que esa implementación forma parte de un servicio del portal.

La ultima consideración es sobre la reutilización del portlet, la idea gira alrededor de combinar múltiples funcionalidades dentro de un portlet único pero usando diferente configuración. Para comprender mejor la recomendación veamos algunos casos:

1. Tenemos un portlet que debe realizar una tarea administrativa sobre alguna tabla/archivo maestro esta labor incluye la búsqueda, creación, edición y eliminación de registros. Una solución propuesta para este caso es la de tener un portlet que solo muestre el listado, otro que se encargue de la modificación y creación de los registros, y finalmente un portlet que sirva para eliminar registros; esta solución propuesta se baso en que los permisos para cada una de las acciones van a depender del perfil que posea el usuario. Es muy probable que desarrollando esto aprendamos mucho sobre el manejo de wiring, la paginación de los listados, el ciclo de vida de los portlets, etc pero esta solución no es la mas adecuada ya que se están creando tres Portlets para una funcionalidad que puede ser hecha por uno solo. Ahora como se podría desarrollar, muy simple ya que las funcionalidades se deben mostrar o no dependiendo del perfil por medio del servicio de manejo de usuarios del portal obtenemos el perfil y validamos si es que se le debe o no de mostrar la funcionalidad, en caso se muestre como parte de la navegación del portal mostramos otra página y listo no tuvimos que crear mas Portlets sino que diseñamos bien uno solo que tiene todas las funcionalidades que necesitamos.
2. Nuestro segundo caso podría ser una aplicación portlet que dependiendo de la página en la que se encuentre muestre información de una fuente de datos determinada y si esta en alguna otra página se vaya a la fuente por defecto. Para este caso podríamos crear un portlet (dentro de la misma aplicación) por cada una de las fuentes de datos , si bien la solución es muy práctica no es la mas adecuada debido a que si aumentan las fuentes de datos tendríamos que crear mas Portlets lo cual nos causaría un mayor costo en cuanto a tiempo y obviamente en dinero. Una posible solución que podríamos ofrecer es la de tener un portlet que implemente el modo config y dentro de este haya un parámetro que indique la fuente de datos de origen con la cual se quiera configurar (por defecto mostrará un valor); este parámetro se va a encontrar como parte de los parámetros del contexto del portal por lo cual cada instancia del portlet puede ser configurada al antojo del administrador del portal.
3. Otro caso que podríamos encontrar es la de tener una aplicación que se encargue de buscar a los clientes de una empresa y también que muestre la información del mismo, la particularidad de este desarrollo es que la búsqueda sera usada por otras aplicaciones las cuales no necesariamente requieran el mostrar la información del cliente. Para este caso un tanto especial si se podría separar la funcionalidad puesto que la búsqueda debe mantenerse agnóstica de quien la llamo. Otro punto por el cual estas funcionalidades no deben de formar parte del mismo portlet es por que el buscador será utilizado en otro contexto en el cual no necesariamente se requiera mostrar la información del cliente.
   

Si bien este post contiene pocas buenas prácticas posee varios ejemplos en los cuales se puede aplicar o no la recomendación. El siguiente post tocará el tema del manejo de la configuración en el portal, punto al que hicimos referencia en el tercer ejemplo de la segunda recomendación.

En el post anterior se toco el tema de manejo del código al momento de desarrollar aplicaciones para portal usando el contenedor de WebSphere.

En esta oportunidad tocará hablar acerca de las recomendaciones sobre la creación, diseño y documentación de nuestros jsps. De igual forma que el post anterior listaré cada una de las buenas prácticas y también algunos comentarios sobre mi experiencia con los mismos.

• Los jsp solo deben de contener fragmentos de código html. Si no las mas importante es una de ellas y debemos de tener muy en cuenta que la vista de los Portlets son fragmentos de código html por lo tanto agregar etiquetas como html, head o body pueden causarnos problemas puesto que estas son usadas para determinar documentos completos. En un proyecto que revisé hace un tiempo el desarrollador (que era de otra empresa) había agregado las etiquetas que menciono antes y si bien mostraba algo en el IE6 en Firefox no tenia el mismo éxito lo cual nos hace pensar cual de los dos navegadores sigue las convenciones.
• Diseñar las vistas para que puedan trabajar con otros Portlets. Esta sugerencia aplica para el caso de Portlets que van a interactuar en distintas formas de diseño en una pagina de portal (una columna, dos columnas, etc) y lo que se quiere es mantener la presentación del mismo. Ahora también se debe considerar la resolución de la maquina donde se visualiza el Portlet puesto que el cliente puede pedir que la aplicación se muestre en todo el largo de la pantalla o solo en un fragmento de ella. Todo esto nos lleva a la conclusión de que el aplicar o no esta recomendación depende del requerimiento que se nos entregue y así no gastar tiempo en características que no son necesarias.
• Usar los comentarios al estilo java en vez de los html. La idea entorno a esto es que si se va a realizar algún comentario sobre alguna etiqueta o comportamiento (condicional bucle) del jsp este se haga usando la convención de comentarios para java (<% // Este es un comentario %>) y no los comentarios de html/xml (< !-- -- >). Ahora por que debemos de seguir la sugerencia es por qué el comentario estilo java no se muestra dentro del html resultado y por qué no deberíamos mostrarlo quizá por que ahí tengamos algún mensaje que solo debe ir orientado para el desarrollador y no para aquel usuario curioso que revise el código html generado.
  
• Usar las hoja de estilos del portal en vez de una especifica. La recomendación es muy clara en este caso, uno debe de utilizar el tema por defecto del portal en conjunto con su hoja de estilos y no repetir el estilo cada vez que tenga que crear un Portlet. Para utilizar esta recomendación debemos utilizar las clases css del portal por ejemplo si tenemos que poner el estilo a una etiqueta del tipo input deberíamos usar la clase wpsButtonText asi nos aseguramos que nuestros Portlets cambiaran de apariencia cuando modifiquemos el tema del portal.
• Las urls y formularios deben ser codificados con el espacio de nombres. El uso es muy practico todas las direcciones y formularios deben der ser codificadas utilizando el tag <> esta etiqueta nos brinda la funcionalidad de codificar nuestra url de tal forma que el contenedor pueda entenderla. En el caso de los formularios se debe usar el espacio de nombres (name space) del portlet para que no sea confundido con algún otro formulario.
  
• Procurar no usar pop-ups (aunque el texto decia no usarlos). El objetivo de esta recomendación es mas que todo tener cuidado con el uso de pop-ups ya que estas llamadas salen fuera del contexto del Portlet. Ahora si nuestro enlace es para una nueva ventana tener en cuenta que el atributo target debe hacer referencia a una nueva ventana.
• Utilizar los taglibs. Considero que la mayor parte de las acciones en un jsp se pueden hacer con los taglibs quizá en un caso extremo se podría usar un scriptlet, eso dependería del requerimiento.
• Tener cuidado con el uso de IFRAMEs. Ya que esta es una forma simple de agregar contenido externo al portal debemos tener en cuenta que no todos los navegadores tienen un buen manejo de los IFRAME y si el contenido es mas grande que la sección asignada este va a mostrar un scroll vertical y/u horizontal lo cual podria generar problemas con la navegación. Hazta el momento no he tenido la necesidad de mostrar IFRAMEs pero el mismo portal tiene una opción de mostrar paginas que contienen marcos ahora no se si lo que se muestra es un IFRAME o un simple FRAME.

Como se puede apreciar varias de las recomendaciones son propias de la programación en web y otras son especiales por el simple hecho de trabajar con un portal.

En el siguiente post estaré comentando acerca de dos buenas practicas sobre el empaquetado de nuestra solución.

Parte del material de lectura que me va a servir como preparación para el examen de certificación del post anterior se encuentra disponible un articulo llamado "Portlet Development Best Practices". En este escrito se podrán ver algunas buenas prácticas al momento de desarrollar con Portlets dentro del contenedor de WebSphere.

El autor resalta doce categorías en las cuales debemos mantener buenas prácticas al momento de desarrollar Portlets, a modo de revisar estos puntos haré un resumen de cada uno de ellos indicando algunas prácticas y comentarios sobre mi experiencia con estos. Con el objetivo de mostrar el mejor detalle posible haré un articulo por cada categoría de recomendaciones.

La primera categoría es sobre algunas guías al momento de codificar usando Portlets, cosas que debemos evitar y algunas en las que debemos de poner énfasis al momento del desarrollo. En esta sección podemos encontrar las siguientes consideraciones:

• Para pasar datos al jsp se debe usar un bean que este contenido en el objeto del request. Es muy importante tener en cuenta esta recomendación puesto que de esa forma estructuramos los campos que vamos a pintar dentro de nuestro jsp. Actualmente las librerías como jstl y frameworks como jsf, spring MVC, struts proveen formas de acceso a estos campos que forman parte del objeto usando declaraciones como ${formulario.descripcion} con las cuales nuestra codificación es más comprensible y elegante.
  
• Usar las facilidades de logging del portal. Si pensaban que el portal es solamente un contenedor de aplicaciones pues se equivocan también es un framework y como tal ofrece ciertas facilidades para realizar actividades muy comunes que en este caso es el logging. Particularmente prefiero usar un framework como Log4j, al final se llega al mismo objetivo: Documentar la actividad de la aplicación dentro de una bitácora.
• Adoptar buenos hábitos de documentación. Esto no solo es para aplicaciones en portal sino para cualquier tipo de aplicación y para cualquier lenguaje. Tengo que aceptarlo que por desarrollar rápido se me olvida de la documentación y siempre hago mención que el nombre método explica su funcionalidad pero por mas que parezca redundante se debe de documentar, en el caso de java usando el javadoc, ya que no todos los integrantes del proyecto pueden tener claro el objetivo de esa función, clase o interfaz.
• Usar la caché del portal. Esta recomendación busca que se aproveche el servicio de caché ofrecido por el portal en el caso de datos que sean muy complejos de obtener o de procesar. Se recomienda el no uso de la sesión pero este punto puede ser discutible pues hay datos a los cuales es mas práctico ubicarlos en la sesión, el uso o no de la misma va a depender de la situación en la que nos encontremos.
• De trabajar con struts seguir las buenas practicas del framework y aplicarlas en el desarrollo de portlets. Nunca he trabajado con Struts y creo que por el momento no lo haré. Esta sugerencia apunta a que las mismas buenas practicas usadas en la programación web con struts deben ser usadas en el desarrollo de portlets.

Como se puede apreciar en esta sección varias de las buenas prácticas para el desarrollo de aplicaciones web con java son tomadas en para el desarrollo de portlets además de agregar algunas propias del uso de un contenedor que en este caso es WebSphere Portal.

El siguiente post tendrá como objetivo mostrar algunas recomendaciones al momento de crear nuestras presentaciones (jsp), el manejo de comentarios dentro de las mismas, entre otros.

Hoy inicio la preparación para mi primer examen de certificación el cual es el "IBM WebSphere Portal 6 Application Development", si bien ya llevo trabajando con WebSphere Portal 6/6.1 desde hace dos años siempre hay cosas que aprendo en el día a día en el trabajo. En lo posible publicaré algún concepto nuevo que voy aprendiendo en estos días de preparación.

Hace poco instale a mi PC un software llamado Wine, el objetivo del mismo era de poder instalar algunas aplicaciones que le servirían a mis hermanas para realizar sus tareas escolares. Quizá me digan ¿Por qué no buscaste una alternativa libre? y la verdad es que me hubiera gustado proponerla pero el colegio exigía el uso de esas herramientas y es mas el curso de computación estaba orientado a ellas.

Como no tuve opción pues instalé el software en este caso el Macromedia DreamWeaver y el FireWorks. Para eso le pedí a mi hermana que se consiga los instaladores y procedi a utilizar la linea de comandos de la siguiente forma:

$ cd /media/cdrom/Macromedia\ 8/ # Ubicación de los instaladores 

Seleccione uno a uno los instaladores utilizando el siguiente comando:

$wine Dreamweaver \8.exe

Y luego de unas cuantas pantallas de instalación ya tenia en mi pc todo el software necesario.

En la empresa en la que trabajo manejamos muchos proyectos y cada proyecto con diversas personas las cuales agregan funcionalidades al sistema o reparan errores del mismo.
Desde ese punto de vista el control del código fuente debe ser manejado por algún sistema el cual sea capaz de administrarlo y ayudarnos a controlar el cambio de nuestro producto. Es ahí donde entran los sistemas de control de versiones. Es por medio de estos que podemos tener un mayor control de nuestro código, saber cual es la ultima versión en desarrollo, quien fue el que hizo los cambios, ver las diferencias entre versiones, etc.
Si buscamos en la web podemos encontrar mucho software para el manejo de código solo por resaltar algunos tenemos:

• CVS
• SVN
• Git
• Mercurial
• ClearCase
  

Para no entrar a mucho detalle que puede ser innecesario voy a comentar un poco sobre cada uno de los sistemas.

La primera vez que use uno de estos sistemas fue cuando aun era practicante y no tenia ni la mas mínima idea de como programar en J2EE(si aun se usaba eso) a pesar de todo eso usé el Clear Case es mas aun recuerdo cuando hice mi primer check out del repositorio, lo que recuerdo es que tenia una muy buena integración con la suite office puesto que uno podia ver las diferencias de los documentos de word o excel a nivel de edición. Ahora si quisera usar este software tendría que irme por dos caminos el comprar la versión para linux o buscar en rapidshare a ver si alguien dejo el instalador. Un punto menos para esta herramienta puesto que actualmente no puedo costearme dicho software.

Viendo las otras opciones tenemos al CVS que también nos ayuda a manejar nuestro código, dentro de sus principales ventajas es que posee una implementación de codigo abierto y gratuito lo cual busco. Ahora ya que cumple uno de mis principales requisitos vemos otras de sus características, entre una de ellas tenemos el manejo de versiones de archivos de texto, uso de ramas, agregar comentarios, etc pero también tenemos sus desventajas entre ellas tenemos que es lento para realizar commits, no trabaja de muy buena forma los archivos binarios y no posee un muy buen manejo de las ramas lo cual puede ser critico en el caso de que hayan varias versiones en paralelo. Si bien se acerco mucho a lo que requiero no llena por completo mis necesidades.

Continuando con la revisión tenemos al SVN o Subversión el cual vendría a ser una versión mejorada del CVS (aunque prefiero decir una evolución natural) este usa como motor de almacenamiento una base de datos Berkeley este puede guardar historia no solo de los archivos sino también de las carpetas cosa que no posee el CVS, además posee un buen manejo de las ramificaciones y en cuanto a la velocidad del commit es mucho mas rápido. Aparentemente este puede ser el candidato adecuado.
Ya para cerrar esta discusión hablaré un poco sobre GIT, una de sus mejores características es que esta mejorado para el desarrollo de aplicaciones donde los programadores se encuentran en diferentes ubicaciones geográficas. Este sistema es usado para el manejo del código del Kernel de Linux entre otros. Tiene un manejo del código y binarios mejor desarrollado que el SVN y las ramificaciones son mejor trabajadas. Este sistema puede tener todo lo que necesito pero hay un factor muy importante a tomar en cuenta al momento de escoger un sistema es que este se acomode a tus necesidades y por el momento no tengo los suficientes argumentos para usar GIT y si lo llegara a usar no aprovecharía al máximo sus características.

Ya habiendo analizado las posibilidades y de acuerdo a mis necesidades voy a usar SVN pues combina el manejo de ramificaciones (branchs), el versionamiento de carpetas y un manejo adecuado las versiones de los binarios.

En la siguiente entrega mostraré como instalar y configurar el SVN, hacer unos commits y check outs usando Eclipse.

Hace algún tiempo cambié de sistema operativo de Windows XP SP2 a Ubuntu GNU/Linux, en cuanto al uso de sistemas unix no soy nuevo ya venia conociéndolos desde hace mucho tiempo (apartir del 2006) asi que la instalación y configuración del mismo no me fue muy complicado. En este entrono tengo casi de todo para realizar mis trabajos los cuales vengo realizando sin ningún problema.
El inconveniente viene cuando mis hermanas quieren realizar sus trabajos escolares el colegio les pide utilizar software privativo solo por hacer referencia a algunos: Corel Draw, Adobe Photoshop, Adobe Flash, etc. Pues ahi tenemos un problema un tanto grande y salieron tres soluciones:

1. Instalar Windows en una partición y de ahí las demás herramientas.
2. Dejar que mis hermanas vayan al colegio para hacer sus trabajos (mi opción preferida).
3. Installar sobre Linux el software requerido.

De estas posibilidades la segunda era mi mejor opción pero no les gusto mucho la idea a las pequeñas asi que me quedaba instalar Windows o sobre Linux ejecutar dichas aplicaciones. Como ya no quiero volver a usar Windows lo que hize fue buscar una forma de instalar las aplicaciones en el Ubuntu.
Luego de recordar un poco algunas conversaciones con algunos amigos me vino a la mente usar Wine. Este proyecto tiene como objetivo el uso de aplicaciones para M$Windows desde un entorno GNU/Linux, debido a que esa era mi necesidad procedí a instalarlo usando el famoso apt-get:

sudo apt-get install wine

Una vez instalado procedi a hacer algunas pequeñas configuraciones y listo ahora empezaré a instalar el Corel y el Photoshop.

PD. Se que usar aplicaciones privativas en un ambiente libre no es la mejor solución de eso no tengo dudas, el uso de una u otra alternativa esta limitado a la necesidad que tengo hasta el momento.

Y con un modesto post empieza este pequeño blog que documentará algunas de mis actividades a lo largo del tiempo. Tocaré temas diversos tanto de mi vida profesional como personal.