Vendrán Días…

Después de asistir el pasado fin de semana en Cáceres a TheEvnt, uno de los últimos eventos más importantes sobre tecnologías web, voy a explicar brevemente cuáles han sido mis impresiones.

En primer lugar dar las gracias y la enhorabuena a los organizadores por el evento. En líneas generales todo ha estado muy bien:

• El lugar elegido, Complejo Cultural San Francisco, muy bonito, con buenas instalaciones, relativamente cerca del centro y con buena accesibilidad. Además, el entorno de la ciudad de Cáceres es estupendo y también pudimos disfrutar de la feria gastronómica que coincidía con el evento.
• Los pequeños detalles como el catering del Networking, la invitación a una copa en El Corral de las Cigüeñas en la fiesta del viernes (de esto último no me enteré muy bien, aunque tampoco hubiera podido ir por el cansancio del madrugón del viernes (6:00 am)) y por supuesto el mago entre charla y charla que hacía que la gente se mantuviera despierta incluso después de comer (aunque al final me tocara participar en uno de los trucos :s)
• La temática de las charlas y los ponentes invitados suscitaban mucho interés. También a ellos, dar las gracias y la enhorabuena.
• …

Antes de empezar a analizar algunas charlas comentar que yo iba con muchísimas ganas y mucha ilusión ya que se trataba de un evento muy importante que se organizaba en Extremadura, de donde soy, y que es una Comunidad a veces olvidada pero que sin embargo hace una apuesta importante por las nuevas tecnologías y el software libre.

Pasemos ahora a hablar sobre las charlas. Anotar que no fui a todas, a algunas porque no pude y ya otras porque en principio no tenía intención. A parte de los talleres, había charlas de dos tipos, de negocios y técnicas. Puesto que soy desarrolladora me interesaban más las últimas: Test de usuarios, usabilidad, javascript, html5 y css3 y la mesa redonda sobre qué framework elegir, donde tenía puestas muchas expectativas.

Test de usuarios de guerrilla: Mientras Daniel Torres Burriel hablaba sobre este tema, yo iba en el tren de camino a Cáceres. Una pena, pero me he leído las críticas que son bastante positivas y las transparencias de la charla para poder hacer mi propio juicio y he de decir que la presentación está muy bien explicada, es clara y sencilla, la información muy organizada. Se entiende a la perfección lo que  se pretende explicar. Seguro que la charla fue genial.

Javascript y los pequeños detalles: Yo esperaba encontrar una charla sobre jquery. En un principio el título era “¿Javascript a pelo? ¡Usa Jquery!” o algo así. Desde hace poco tiempo estoy usando esta librería de javascript y me está resultando muy útil además de facilitarme ciertas tareas. También la he complementado con el framework jqueryUi que ofrece muchas posibilidades como widgets, events, themes… Entonces, como en un principio la charla tenía pinta de que los tiros iban por ahí, pues yo esperaba una charla en la que contaran trucos, peculiaridades, ventajas…y quizá sí, buenas prácticas, que fue de lo que trató la charla, pero con jquery. Pero aun así felicitar al ponente Manuel Muñoz Solera, porque nunca está de más que alguien con experiencia te hable sobre buenas prácticas y como mejorar tu código y tus aplicaciones cuidando los “pequeños detalles“. Fue interesante y entretenida.

Biowallet: SeedRocket 2009: Charla impartida por José Luis Huertas, co-fundador de Biowallet, proyecto finalista del OpenBBVA Talent y ganador del SeedRocket 2009. En esta charla, Jose Luis Huertas nos habló de su proyecto, de cómo encontraron su “océano azul” y de cómo, partiendo desde cero, con una idea original, muchas ganas y entusiasmo pero poco presupuesto, consiguieron sacar el proyecto adelante. Muy importante destacar que todo lo han hecho desde Extremadura, donde, aunque parezca que hay pocos recursos, se pueden conseguir cosas importantes echándole ganas. También nos habló de Campus de emprendedores como SeedRocked y de lo importante que puede ser participar en uno de ellos con una idea original para conseguir un poquito de presupuesto, publicidad y fuerza. Muy muy interesante.

Diseño de Experiencias de Usuario: Sobre todo, una charla muy divertida, con buenos ejemplos. Juan Leal fue el encargado de dicha charla.

HTML5 & CSS3: Para mi, la mejor, sin duda, y creo que también para muchos. No sólo por cómo se desarrollo, ya que Jose Florido hizo una presentación de HTML5 y CSS3 genial, si no por el contenido. Había leído algo, pero no tenía muy claro si ya podíamos empezar a utilizar ambos, si los navegadores ya lo soportaban, ni tampoco tenía muy claro todas sus ventajas, pero él se encargo de aclarar todas las dudas y poner buenos ejemplos. Es un ejemplo más, de que cada vez avanzamos más hacia herramientas, frameworks, lenguajes, tecnologías… que nos hacen la vida más fácil a los desarrolladores. Y que luego haya a quién se le ocurra comparar la construcción de un puente con el desarrollo de una aplicación…

Ypor último…la mesa redonda sobre ¿Qué framework escoger? (Ruby on Rails, J2EE, Symphony…) Ahí es donde yo iba con más expectativas y con ganas de participar para hablar de Grails, ya que es otro framework que a mi modo de ver es muy importante y también debería haber estado expuesto. Pero siento decir que salí de allí decepcionada. Los tres integrantes de la mesa redonda expusieron sus argumentos, cada uno en defensa de uno de los frameworks, y se hicieron críticas entre ellos, pero en cuanto “el público” empezó a tomar la palabra, rápidamente el tema de discusión se fue por otros derroteros: que si hay que darle importancia o no al lenguaje, que si es necesario o no un framework, que si en España se desarrollan buenas aplicaciones, que si en la informática hay intrusismo laboral… en fin. Creo que era un tema muy interesante del que se podían haber sacado muchas conclusiones. A mi modo de ver, la elección de un framework depende en muchas ocasiones de las necesidades del proyecto, del entorno de desarrollo, del perfil de los desarrolladores… por eso me hubiese gustado participar y hablar de Grails, ya que se adapta muy bien casi a cualquier entorno de desarrollo y sobre todo a entornos Java (pero eso ya lo expliqué en mi post anterior y no lo voy a repetir aquí otra vez ). También es una buena elección si empezamos desde cero. Que conste que no participé porque nadie me lo impidiera, ni mucho menos, sino que como rápidamente, se perdió la línea del debate, me parecía que mi exposición ya estaba fuera de contexto. Otra vez será.

Conclusiones

Para un desarrollador, ya sea con mucha experiencia o menos como es mi caso, siempre es muy enriquecedor asistir a eventos de este tipo, no sólo porque se aprende mucho de grandes expertos en diversas materias relacionadas con el desarrollo de software empresarial, si no porque se aprende a escuchar, a cómo expresarse, a tomar notas, a comparar, a tener nuestro propio criterio, se nos brinda la oportunidad de conocer gente nueva, como por ejemplo la que seguimos en Twitter y, por supuesto, darnos cuenta que siempre hay mucho que aprender.

Espero que pronto haya una próxima y si vuelve a ser en Extremadura, mucho mejor

Desde hace un año y desde Salenda, tengo el placer de desarrollar aplicaciones Grails para una institución pública en la que se trabaja en un entorno de desarrollo mayoritariamente Java. Mi intención con este post es explicar, desde mi humilde experiencia, como se puede introducir poco a poco este framework en un entorno de desarrollo de estas características sin ningún tipo de problema y con resultados satisfactorios. Hay ejemplos mucho más importantes como el de http://www.escueladegroovy.com/ y el ayuntamiento de Vitoria-Gasteiz, pero yo voy a aportar mi granito de arena. En este caso, la introducción de Grails se está haciendo poco a poco y, de momento es Grails quien se tiene que adaptar a los recursos del entorno de desarrollo al contrario de lo que ocurre en el Ayuntamiento de Vitoria-Gasteiz

Primero voy a explicar de qué recursos partimos:

• Servidores Tomcat y GlassFish
• Bases de datos Oracle e Ingres
• “Mega-Api’s” Java que son mapeos JPA de las anteriores bases de datos con sus Dao’s y las implementaciones de éstos.
• Escepticismo ante Grails
• …

Con este panorama, me plantean desarrollar la primera aplicación utilizando Groovy y Grails. Sólo especificaron qué querían tener y para cuándo, el cómo era cosa mía, eso sí, adaptándome a los recursos que existen. Si el resultado era satisfactorio se seguiría esa línea con otras aplicaciones.

Posibles problemas que nos podíamos encontrar o nos encontramos:

• Tiempo dedicado al aprendizaje de Groovy y Grails: mmmmmm…. ¿O minutos? En mi caso, ya había hecho cosas antes con Groovy y Grails pero cuando empecé, yo sólo había programado en Java y aprendí Groovy sobre la marcha: al principio empiezas sólo quitando “;” y con el tiempo vas descubriendo las capacidades de Groovy y Grails (los “finders” dinámicos, los “createCriteria”, los bucles, la definición de tipos y objetos en tiempo de ejecución, el manejo de listas, GORM, el uso de plugins…y así, un lago etc.) Sobre Grails…pues sabiendo J2EE no hay mucho más que aprender. Sigue una arquitectura Modelo-Vista-Controlador, y está construido sobre Spring e Hibernate pero nosotros no tenemos que preocuparnos de ficheros de configuración ni nada por el estilo. Realmente ahorramos tiempo.

• Sevidores: que queremos desplegar en Tomcat, pues añadimos el fichero context.xml para definir el datasource por JNDI y listo. Que queremos desplegar en GlassFish y también necesitamos definir el datasource por jndi pues no hay que hacer nada.

• Bases de datos: ningún problema, incluimos el .jar correspondiente y ya está.

• La aplicación utiliza dos bases de datos distintas – hay que definir dos datasources: pues uno en el datasources.groovy y el otro en el resources.xml, dentro del directorio de spring, ya sea especificando los datos de la conexión o por jndi

• Uno interesante: La aplicación no puede mapear directamente sobre la base de datos, las clases de dominio deben ser clases java de una de las “mega-api’s” y hay que utilizar sus Dao’s. Se me cayó el mundo encima de pensar que no podía utilizar GORM!! Pero bueno, vayamos por partes:

• • ¿Por qué esta restricción? “Porque esto ya estaba hecho“, “porque se ha invertido mucho tiempo en desarrollar las api’s“, “porque así está todo más organizado“, “porque así todas las aplicaciones acceden a la base de datos de la misma manera“…
  • Hacer que las clases de dominio sean clases de un api externo java: ningún problema, se tira del fichero hibernate.cfg.xml (en el directorio hibernate de la aplicación). En este fichero se dice cuáles son las clases del api que van a ser clases de dominio de la aplicación y a partir de ahí trabajamos normalmente.
  • ¿Cómo los convenzo de utilizar GORM? Cayó por su propio peso: Era mucho más rápido hacer consultas (que en esta aplicación había muchas y por bastantes criterios) con “finders” dinámicos y “createCriteria” que hacerlas sin GORM o en el propio api, ya que en un api genérico para varias aplicaciones no se van a definir consultas específicas de una aplicación. Además, así podíamos valernos del plugin “grails-ui” y de sus “datatables” así como de su paginación y ordenación automáticas.
  • Y yo fui feliz

• No se quieren incluir jar’s en directorio “lib” del proyecto, se quieren instalar dependencias. Pues se instalan:

install-dependency mysql:mysql-connector-java:5.1.5 –repository=http://download.java.net/maven/2

Conclusiones:

• Éxito en la integración
• Podíamos ver partes de la aplicación funcionando a corto plazo.
• Se llegó a los plazos, con tiempo de sobra.
• Con el uso de algunos plugins hemos ahorrado tiempo al tener que desarrollar ciertas funcionalidades.
• Se han podido empaquetar aspectos comunes a las aplicaciones en un plugin para así no tener que desarrollar/configurar éstas n-veces ( DRY – Don’t Repeat Yourself xD )
• Hemos conseguido convencer a la gente!
• ¡Ya hay varias aplicaciones Grails en marcha!

¡Si se quiere… se puede!

Una se pone a buscar información sobre como desplegar una aplicación grails que usa oracle 10g en glassfish  y no encuentra casi nada, y mucho menos si hablamos de algo referente a Ingres. Así que después de pegarme con esto unos días y con un resultado satisfactorio voy a aportar mi granito de arena con este post.

Una vez desarrollada mi aplicación en Grails (que pronto saldrá a la luz), la tengo que desplegar en Glassfish v2.1. Pronto empiezan a aparecer los primeros problemas, que explicaré junto con algunas particularidades de mi aplicación:

• Mis tablas están en una base de datos de Oracle 10g y en un esquema determinado.
• Además, mi aplicación depende de otras tablas de esa misma base de datos pero que están en otro esquema. A la información de estas tablas accedo a través de un Api, cuyo dataSource será el mismo que el de mi aplicación.
• Pero hay más: mi aplicación depende de otra tabla, de una base de datos de Ingres, a la cual también accedo a través de otro Api con un dataSource distinto (evidentemente).
• Para solucionar todo esto, tiro de Spring y del fichero “resources.xml” de la siguiente manera:
  • Para el problema del Api que usa el mismo dataSource que mi aplicación sólo tengo que importar su “applicationContext.xml”

<beans>
    <import resource="classpath:applicationContext.xml" />
</beans>

• Para el problema del Api que usa un dataSource distinto al de mi aplicación sólo tengo que definir un nuevo dataSource, pasándole los datos de la conexión a la base de datos y un bean de la clase que gestiona el Api. A este último le paso el dataSource:

<beans>

<bean id="dataSourceIngres" class="org.apache.commons.dbcp.BasicDataSource">

    <property name="driverClassName" value="com.ingres.jdbc.IngresDriver" />

    <property name="url" value="jdbc:ingres://url/bbdd;cursor_mode=readonly" />

    <property name="username" value="username" />

    <property name="password" value="******" />

</bean>

<bean id="nameBean" class="beanClass" factory-method="getInstance">

    <property name="dataSource"><ref local="dataSourceIngres"/></property>

</bean>

</beans>

• Todo esto, como ya he dicho, dentro de “myApp/grails-app/conf/spring/resources.xml“. Una vez hecho esto, podemos acceder a la información de todas las tablas sin ningún problema.

• Cambio de tercio: La versión con la que empecé a desarrollar mi aplicación fue la 1.1.1 (stable release) y el plugin grails-ui 1.1-SNAPSHOT, este último porque uso gui-dataTables en mis listados. Con esta versión del plugin tenía problemas en la ordenación de las columnas de forma que cuando salió la release 1.1 me actualicé para comprobar que estos problemas estaban resueltos, pero a su vez me obligaba a actualizarme a la versión de grails 1.2-M2. Como mis problemas se  resolvieron y todo iba bien, así se quedó la cosa. Salieron nuevas “milestones” pero no iba a estar cambiando la versión de grails constantemente sin necesitarlo.
• El gran problema llega a la hora de desplegar la aplicación. El GRAN PROBLEMA realmente son dos:
  • Por un lado, definiendo el datasource en producción utilizando jndiName = “jdbc/myDatasource”, no accedía  la base de datos.
  • Por otro lado, aunque definiese el datasource en producción pasándole los datos de la conexión (que así si accedía a base de datos) Glassfish se quedaba colgado continuamente, no se podían desplegar otras aplicaciones, no se podía hacer “undeploy”….
  • Después de probar varias cosas e ir de un lado para otro decidimos volver a la versión 1.1.2 que es la última estable y el GRAN PROBLEMA se resolvió. También probé con la última versión “milestone” de grails, la 1.2-M4 y tampoco hay ningún problema, pero prefiero dejar mi aplicación en producción con una versión estable ya que todo funciona a la perfección.

Conclusión: hemos dado muchas vueltas, cuando, en definitiva, la solución era una tontería. Elegimos el camino equivocado pensando en que el problema estaba en la definición de los datasources y en Oracle, en parte porque hemos encontrado poca información al respecto. Por eso, insisto, escribo esta laaaaaarga entrada en mi blog, para que a alguien le pueda servir, al menos, para ahorrarse un poquito de tiempo.

Estos días me he encontrado con la necesidad de inyectar un datasource a un Dao de una librería externa a mi aplicación, siendo éste, un datasource distinto al de mi aplicacion y a través del cuál se establece una conexión a una base de datos de INGRES. De primeras…suena mal pero luego resulta ser muy sencillo.

Respecto a que sea INGRES y no otro gestor de BBDD más común como ORACLE o MySQL … ningún problema. Ni siquiera si este va a ser el gestor de la  BBDD de la aplicación. En su día me encontré con este caso y tampoco tuve problemas, tan sólo alguna incompatibilidad con algún tipo de datos pero nada importante.

Sobre a que haya que utilizar otro datasource distinto al de mi aplicación, ningún problema tampoco, se le llama de otra forma y listo. Y finalmente, ¿Cómo o dónde inyectarlo? Pues he echado mano del resources.xml y ahí me he definido el datasource y el bean que hace referencia al Dao:

resources.xml

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean id="dataSourceIngres">

<property name="driverClassName" value="ca.ingres.jdbc.IngresDriver" />

<property name="url" value="jdbc:ingres://DATABASE" />

<property name="username" value="USERNAME" />

<property name="password" value="PASSWORD" />

</bean>

<bean id="ingresDao" factory-method="getInstance">

<property name="dataSource"><ref local="dataSourceIngres"/></property>

</bean>

</beans>

y por último se hace un getInstance() del Dao y se llama al método que corresponda pasándole los argumentos que sean necesarios

Siendo sincera, hasta que no me he visto en la necesidad no me he puesto a utilizar jquery aunque si me lo había planteado.

El motivo ha sido una incompatibilidad que hay entre la librería prototype.js y Grails-UI 1.1-SNAPSHOT y es que estaba intentando hacer un formulario de búsqueda con selects encadenados o dependientes unos de otros y que a su vez, se mostrara el resultado en un gui:datatable. Necesitaba prototype porque estaba realizando una llamada en el “onchange” del “select” utilizando “${remoteFunction(…)}” El problema es que la tabla no se carga y sólo salía “Loading…” además del siguiente error javascript:

too much recursion } else if (isArray(input)) {  //grailsui.js (line 48)  (ver error)

Total, que después de dar vueltas por google y de consultar en la lista de correo llegué a la siguiente conclusión:

1- Usar jquery

2-Volver a Grails-UI 1.0.4 (en esta versión no existe el problema)

Y como no iba a volver atrás en el tiempo pues decidí utilizar jquery y este es el resultado:

searchForm.gsp

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="layout" content="main" />
<g:javascript library="jquery-1.3.2" />
<script>
$(document).ready(function() {
$("#personSelect").change(function() {
$.ajax({
url: "/persons/search/loadAddress",
data: "id=" + this.value,
cache: false,
success: function(html) {
$("#addressSelect").html(html)
}
});
});
});
</script>
</head>
<body>
>[...]
<g:form>
<div>
<table>
[...]
<td valign="top" class="value ${hasErrors(bean:person,field:'userRealName','errors')}">
<g:select
id="personSelect"
optionKey="id"
from="${Person.list()}"
name="personSelect" value="">
</g:select>
</td>
><td valign="top" class="name">
<label for="address">Address:</label>
</td>
<td valign="top" class="value ${hasErrors(bean:address,field:'description','errors')}">
<div id="addressSelect">
<g:select noSelection="${['null':'Select One...']}"
optionKey="id"
from=""
name="addressSelect" value="">
</g:select>
</div>
</td>
[...]
</table>
</div>
</g:form>
<div>
<gui:datatable> [...] </gui:datatable>
</div>
</body>

</html>

searchController.groovy

def loadAddress = {

def address = []//Address.findByPerson(params.id)

if(address.size()==0){

render """<select id="addressSelect" name="addressSelect"><option value="-1">- Select One -</option></select>"""

}else{

render g.select( optionKey:'id', from: address, id: 'addressSelect', name: "addressSelect")

}

}

y esto es todo.

Seguiré indagando en jquery