Gorm4Ebean

Hace un par de semanas hemos liberado nuestro primer proyecto bajo licencia de código abierto: Gorm4Ebean.
Se trata de una librería, muy sencilla, que permite utilizar el API EBean ORM de forma muy similar al API de Grails: GORM.

Personalmente, tengo la mala costumbre de desarrollar muchas (demasiadas) herramientas. Soy de los que se pasan mas tiempo afilando el hacha que cortando, pero es así, que le vamos a hacer. Me parece horrible retorcer una aplicación para encajarla con determinados componentes cuando se puede desarrollar una capa intermedia que abstraiga de toda la fontanería... debe ser deformación de cuando estuve con el Framework PA. Aunque ahora, "lo que mas se lleva" son los DSLs. Tenemos DSL para cualquier cosa: configuración del componente A, scripting, persistencia, configuración del componente B (otro DSL distinto del de A, porque como el dominio es distinto, pues lenguaje distinto...), etc. Algunos son interpretados, otros compilados. La verdad, demasiados... aunque con Groovy se hacen como churros.

Ahora con la crisis, cada vez estamos mas concienciados con el reciclaje y la productividad y zurcir los calcetines y hacer sopa con el cocido de ayer y todas estas cosas....y me he dado cuenta de la pila de herramientas y utilidades que hemos desarrollado durante años y nunca han visto la luz. La mayoría estaban demasiado acopladas a los proyectos (o directamente eran basura), pero otras no...otras se podían haber publicado o reciclado.
Pensándolo detenidamente, nuestro negocio no pasa por comercializar este tipo de herramientas (para el que tenga interés en saber a que nos dedicamos de verdad, nuestra web es www.nortia-in.es ) y la alternativa a publicarlas es dejarlas cogiendo polvo en un cajón.

En el caso de la librería Gorm4Ebean (que lleva un DSL incluido, faltaría mas) la verdad que fue una cosa fortuita: Aplicación Swing con Griffon ... Nos rompemos los cuernos para conseguir sacar GORM de Grails y utilizarlo en un entorno Swing, solamente para darnos cuenta de que la gestión de sesiones de Hibernate no es compatible (o mejor dicho, "duramente compatible") con el modelo de hilos de Swing.

Así que, buscando por internet (bendito StackOverflow) nos topamos con la librería eBean, que es una especie de Hibernate pero "sessionless".  La verdad que no es muy conocida. Los proyectos conocidos que la usan son: Play! (un framework web que no conozco muy bien), el famosisimo juego indie Minecraft y ...luego ya debemos de ser nosotros los siguientes.

Pero bueno, funciona bastante bien! El problema es que con GORM tenemos una arquitectura basada en Domain Objects: ya sabes, con la lógica de negocio y los datos todos juntos y revueltos, métodos save(), list(), delete(), etc., nada anemico...
En cambio, eBean a priori parece que encaja mejor en una arquitectura de capas tradicional: VOs anémicos, capa de negocio, capa de DAOs, etc.

Entonces ¿que hacemos? ¿Tiramos todo y rehacemos la aplicación con la arquitectura de capas? ¿O hacemos algo con eBean para que encaje con todo el código que ya teníamos hecho?

Obviamente, hemos elegido la segunda opción y de ahí sale la librería gorm4ebean.

Arquitectura Efímera.

Tenía en mente empezar esta entrada haciendo referencia al disco de Fangoria que se llama igual que esta entrada: "Arquitectura Efímera". Referencia, ahora que lo pienso, un poco tonta que pensaba aprovechar para hacer un guiño a algunos colegas que seguramente serían los únicos a los que les podría hacer un poco de gracia.

El caso es que buscando por Google imágenes o vídeos para ilustrar la tontería, me he enterado de que existe de verdad una disciplina de la Arquitectura que se llama así: Arquitectura Efímera, y que se centra en el diseño de construcciones que no tienen propósito de perdurar en el tiempo. Por ejemplo: decorados, ferias, stands, etc.

Y ahora que ya tengo la entradilla destrozada, voy al grano ...

Acabo de terminar de leer el libro "97 cosas que todo programador debería saber", de la editorial O'Reilly. Es un libro que, como su propio título aventura, se divide en 97 capítulos, cada uno escrito por un gurú de la programación.
No obstante, se subtitula como: "Conocimiento colectivo de los expertos" (¿como lo viste?).

En realidad, se nota que a muchos de los expertos lo pilló la editorial "a salto de mata"  y los comprometieron a traición para colaborar en el libro. Algunos expertos se vengaron malamente escribiendo cosas como "Algo mágico ocurre cuando testers y programadores trabajan juntos." (sic). O algún que otro capítulo que es una fumada en toda regla de principio a fin.

De todas formas, la mayoría son consejos muy útiles e interesantes para cualquier programador que quiera mejorar.
Uno de los consejos que mas me ha llamado la atención de todos; me ha llamado tanto la atención como para escribir una entrada en este blog que lleva tres años abandonado, es el que escribe Yuriy Zubareb, a la sazón, arquitecto en la consultora ThoughtWorks (donde trabajan gurús como Martin Fowler o Rebecca Parsons), en que habla justamente de lo efímero que es el código, o mejor dicho, que no es.

Bueno, en realidad su consejo no es ese. Su consejo es: "Escribe código como si fueras a mantenerlo el resto de tus días". Que, a la postre, termina siendo un alegato en pro de la mantenibilidad y la extensibilidad del código, ponerse en la piel de compañero que lo va a mantener, etc.

Al terminar su capítulo deja la siguiente frase (aviso, traducción mía que puede ser mas o menos chapucera):

Si te paras a pensarlo, el código que escribiste hace muchos años sigue influyendo en tu carrera, quieras o no. Sin querer, vas dejando una rastro de tus conocimientos, actitud, tenacidad, profesionalidad, nivel de compromiso y grado de diversión (N. del T: degree of enjoyment, que no se traducir mejor.) en cada método, clase y módulo que has diseñado y escrito. La gente se formará opiniones sobre tí basándose en el código que vean. Si estas opiniones son negativas, sacarás menos rendimiento a tu carrera de lo que esperas.

Puede parecer una obviedad pero estoy convencido de que muy poca gente que se dedica (o que nos dedicamos, me incluyo) a programar lo habíamos pensado así. No somos conscientes del rastro que estamos dejando detrás de nosotros. El software que construimos es menos efímero de lo que creemos en un principio y, si lo pensamos da hasta vértigo (al que lo tenga claro, que hay alguno que le da todo absolutamente igual. Eso sí, luego se quejan...)
En mi caso, haciendo memoria, creo que la mayoría de lo que he escrito en los últimos 9 años sigue rondando por ahí...aunque con los recortes y la crisis ya no estoy del todo seguro de que aún quede alguien por ahí, cagándose en todo al utilizar el FWPA.

Ah, y por cierto....

Classloader problem with diRMI and Grails

When trying to expose DiRMI services from a Grails-based web application, a fatal ClassNotFound exception may rise.

I have found the next caveat:

Extending DiRMI ClassResolver and Environment class.


class ClasspathResolver implements ClassResolver {

public Class resolveClass(String name)
throws ClassNotFoundException {
return Thread.currentThread().contextClassLoader.loadClass(name)
}

}

class GEnvironment extends Environment {

public Session newSession(ChannelBroker broker) throws IOException {
def session = super.newSession(broker)
session.classResolver = new ClasspathResolver()
return session
}

}


And that's all folks! It works!

Grails SortedSet composition ClassCastException

Grails domain objects stored in SortedSet (or related with others using a SortedSet) must implement Comparable. Otherwise a weird ClassCastException (with no Stacktrace at all) will be thrown

Peer Unverified Exception accessing secure web sites with HttpClient

When trying to access to secure web sites (https protocol) using apache HttpClient library, sometimes you can get the following error:

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:129)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:326)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:129)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:164)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:119)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:349)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)

This exception occurs when page is sending a non trusted certificate. So, the solution to this exception is to import the certificate into your trusted certificates database.

• Step 1. Export web page authenticate.
  

Use a browser to access the web site you want to access with HttpClient. Go to "privacity->certificates" options in the browser and export it to a ".cert" file

• Step 2. Create truststore file.

Import the ".cert" file in a truststore database. Use the following command:

keytool -import -v -trustcacerts -alias certAlias -keypass changeme -file thefile.cert -keystore truststore -storepass changeme

• Step 3. Copy "truststore" file to your project.
• Step 4. Add the following code (in Groovy):
  

def keyStore = java.security.KeyStore.getInstance( KeyStore.defaultType )
      
def store =getClass().getResourceAsStream( "/cert/truststore" )
keyStore.load( store, "thepassword".toCharArray() )
client.connectionManager.schemeRegistry.register(
                       new Scheme("https", new SSLSocketFactory(keyStore), 443) )

Where "client" is the HttpClient instance.

• IMPROTANT NOTE. "truststore" file mus be generated with JKS format. OpenJDK uses GKR format by default wich is not compatible. Sun JDK uses JKS format by default.
  

Stupid half an hour problem starting Griffon

When i was trying to launch any Griffon app I ever got a rare ClassNotFoundException with GriffonStarter class.

Half an hour later I realized that my griffon path was: /griffon-0.2. I changed it to /griffon and voilá: it works

Problem with POI-Excel Fonts solved!

Today suddenly i get the following error opening a POI-generated file with Microsoft Excel:

"Excel cannot complete this task with available resources. Choose less data or close other applications."

More info in: http://markmail.org/message/bzy5wv2bziodqeoi

The solution was:

1.- Reuse evey Font object you can...
Someting like this:

for (row in rows) {
   font = workbook.createFont()
   //Do whatever with font
}

Have to be refactored to something like this:

font = workbook.createFont()
for (row in rows) {   
   //Do whatever with font
}

2.- Update to 3.5-FINAL version. 3.2-FINAL version is buggy and exhausts all Excel resources with anything you do.

NOTE: With OpenOffice everything worked ok.