sábado, 19 de junio de 2010

Miniguía: compilando ConkyWizard

Gracias a este artículo, me entero sobre el proyecto ConkyWizard. Es un asistente para configurar visualmente al fantástico Conky. Normalmente se configura a mano usando un archivo de configuración bastante "oscuro", y muchos usuarios después comparten sus configuraciones en sitios como gnome-look.org, aunque no deja de ser bastante complicado de usar para la mayoría de la gente.
Aquí es donde ConkyWizard viene al rescate. Es una aplicación nueva, en versión beta y con algunas falencias y errores, pero que ya se puede usar mayormente.
Al ir a la página del proyecto, solo hay dos binarios: uno para Ubuntu Lucid Lynx 32-bit y otro para 64-bit. Lamentablemente, la versión para 64-bit está compilada usando una actualización de QT4 (la librería gráfica usada como base en KDE) que probablemente no vamos a tener instalada. Como uso la edición de 64-bit, decidí compilarlo a mano, y como no pude encontrar ninguna documentación de cómo hacerlo, aquí comparto el paso a paso del proceso:
svn checkout http://conkywizard.googlecode.com/svn/trunk/ conkywizard-read-only
cd conkywizard-read-only/ConkyWizard/
sudo apt-get install tmake libqt4-dev
tmake ConkyWizard.pro -o Makefile
cd resources/
rm translations
ln -s ../translations
cd ..
qmake-qt4
make
cd ../Application/
./ConkyWizard

Ojalá les sirva como a mi. Hasta pronto.

jueves, 11 de marzo de 2010

Proyecto WAR con Seam 2.2 en JBoss AS 5.1

Quiero compartir la solución a un problemita bajo una configuración particular, resultando en que las entidades mapeadas del WAR no eran encontradas por Hibernate.

Estoy armando un proyecto de prueba usando SEAM 2.2 y JBoss AS 5.1, para probar algunas novedades y cambios de las últimas versiones por un lado, y por otro, para experimentar con ciertos características.

El entorno de desarrollo es Eclipse 3.5 con JBoss Tools 3. Aquí no utilicé seam-gen, y creé directamente el proyecto desde el IDE. Usé una base de datos MySQL 5.1 y todo el conjunto corre sobre Ubuntu Karmic Koala (9.10).

El problema y la solución es la indicada en JBSEAM-3821, aunque el problema estaría solucionado usando el seam-gen desde SEAM 2.1.2.CR1, parece el mismo también sucede al crear proyectos con JBoss Tools 3.

The comments in the components.xml and persistence.xml files of the JPA Example generated for JBoss 5 show the correct way to handle this. Although it would be nice if SeamGen handled this correctly.

En el último comentario del reporte del bug, está la solución (o su workaround). Los datos claves son:

  • en el components.xml, agregar en la etiqueta <persistence:entity-manager-factory/> el atributo installed="false", y en la etiqueta <persistence:managed-persistence-context/> agregar el atributo persistence-unit-jndi-name="java:/bookingEntityManagerFactory".
  • en el persistence.xml, la propiedad <property name="jboss.entity.manager.factory.jndi.name" value="java:/bookingEntityManagerFactory"/>
Salvando este detalle, ya podemos trabajar normalmente. De todas formas, recomiendo usar el seam-gen, que es muy interesante y útil, pero en caso de no usarlo, ya saben :)

jueves, 4 de febrero de 2010

Oracle/Sun: pensamientos y divagaciones

A continuación, algunos pensamientos y divagaciones sobre Sun, Oracle, MySQL, Java y temas relacionados a la post-compra de Sun. Escribí este texto durante una conversación con colegas, que todo inició como un debate sobre el artículo que publicó Oracle por la finalización de la adquisición de Sun. Mi preguntaron si podían compartirlo, y aquí está.
Advierto que si deciden seguir leyendo, lo hacen baja su propia responsabilidad. Y como siempre, la casa se reserva el derecho de moderar cualquier comentario desubicado ;)


...
Creo que el único fuerte que salva a MySQL es que es universalmente usada en los ISPs y se incluye hasta en los planes de hosting más baratos, lo que no es poco. Pero se queda corta comparada con cualquier base de datos relacional seria, y también en el entorno embebido cuando se quiere algo rápido y eficiente (donde SQLite es el líder lejos, y cada vez más usada). Para mi, MySQL es una base de datos de compromiso y nada más ;)

PostgreSQL es "LA" base de datos libre. Es muy parecida a Oracle en muchos sentidos. Y ahora que a MySQL le nació MariaDB... más vale que Oracle no descuide a la criatura... o se habrán gastado una pasta al dope xD y creo que con MySQL ya van camino a perder todo su control, apenas MariaDB reemplace a MySQL como la favorecida por las distros Linux, lo que ya se está discutiendo.

Lo que ahora controla Oracle de Java... lo puede perder en un instante si empieza a alienar a la comunidad y al resto de las empresas del sector. Y si pasa eso, se van a disparar en su propio pie, no creo que lo hagan, pero es posible. Me acuerdo lo que pasó con el consorcio que manejaba X11 y lo que pasó al hacer cambios en su licencia y decisiones que lo gustó nadie: rápidamente se conformo un nuevo consorcio (X.org) que lo reemplazó de hecho, y encima se ganó mucha apertura, innovación y velocidad de mejoras en el proceso. A veces, una revolución es positiva.

¡Hay laburo asegurado en Java hasta para nuestros nietos! Incluso si se volviera obsoleto o irrelevante, la inversión en software crítico que existe es impresionante, y habrá que convivir con él y darle mantenimiento y soporte por varias décadas, como sigue pasando con COBOL y FORTRAN hasta nuestros días.

Se puede perder interés en Java en algún momento: pasará eventualmente, y no depende solo de Oracle/Sun. Ya hay muchos lenguajes pidiendo cancha en la JVM: Groovy (c/Grails), Ruby (RoR), Scala, Clousure, Jython/Python, etc. que si Java (el lenguaje) no se mantiene al día, cualquiera de estas u otras opciones serán cada vez más interesantes, dentro o fuera de la JVM.

Y Apache con Harmony sigue ahí a la espera. Sun no les dejaba certificarse y llamarse "JAVA", y Apache en protesta votaba en negativo en cada votación de JCP. Android ya usa partes de Harmony y está claro que no es Java. Dicen que Harmony está programado tan pero tan bien, que es todo un ejemplo de cómo debe programarse algo, y que está limpio y programado desde cero, bien documentado, bien diseñado. Encima, al estar bajo licencia Apache (digamos burdamente "hacé lo quieras"), se hace muy tentador a empresas como este caso de Google con el Android.

En resumen: Oracle no puede hacerse mucho "el loco", o le quitarán el control. Y si no abren el JCP, si no lo transforman en un organización per-se, se les puede complicar. A favor, Oracle era una de las empresas que votaba para abrir el JCP, vamos a ver si ahora que está en sus manos se "acuerda" de sus propios reclamos ;)

Todo lo que ya es software libre, como en la Evolución, irá encontrando su camino, aunque a veces sea difícil verlo de antemano :)