Bienvenido a frangarcia.net. Mi nombre es Fran García y soy un Ingeniero en Informática por la Universidad de Alicante que actualmente trabaja como Director de Ingeniería en Cheetah Digital. En esta web encontrarás sobre todo noticias relacionadas con las nuevas tecnologías, Internet, programación y de vez en cuando soltaré algo sobre mi vida privada, aunque no esperes que esto sea un blog demasiado íntimo.
Espero que lo que veas y leas aquí, sea de tu interés.
16 October 2012, 14:57
Espero tus comentarios... [13]
Este próximo 2 de Noviembre iba a cumplir ya 8 años en el Laboratorio de Idiomas de la Universidad de Alicante, el lugar donde me he desarrollado como profesional y donde he descubierto que el mundo del funcionariado, quizás no sea todo lo bonito que muchos lo pintan, más aún con los últimos acontecimientos acaecidos en España.
12 August 2012, 12:35
Espero tus comentarios...
Actualmente estoy trabajando en un proyecto del que en breve esperamos tener una primera release y del que todavía no puedo comentar nada. En este proyecto, he tenido que realizar una serie de modificaciones a un plugin que siempre utilizo en cualquier proyecto de Grails que requiera de autenticación mediante usuario y contraseña. Este plugin es Spring Security Core.
Este plugin permite fácilmente implementar todo un sistema de seguridad en una aplicación desarrollada en Grails mediante nombre de usuario y contraseña. En este proyecto necesitaba ampliar este plugin para que en además de poder identificarse mediante nombre de usuario también se pudiera hacer mediante el correo electrónico.
Para poder implementar estos cambios, lo primero que debemos hacer es ampliar la clase relativa a los usuarios del plugin Spring Security Core. Habitualmente esta clase se llama User y quedaría algo así:
Posteriormente, debemos crear una clase en el directorio src/groovy para extender la clase GrailsUser que a su vez extiende a la clase User.
Por último, debemos crear un servicio de Grails donde modificaremos el comportamiento de la autenticación en Grails para que en lugar de comprobar únicamente por el nombre de usuario, lo haga también con el email que acabamos de añadir.
Con estos cambios, ya podremos identificar a los usuarios de nuestra aplicación tanto con el nombre de usuario como por el correo electrónico. Incluso vamos a poder utilizar la etiqueta loggedInUserInfo para mostrar el correo electrónico del usuario identificado en el sistema.
Podéis encontrar más información al respecto en la documentación del plugin Spring Security Core y en el blog de Omar Marji.
14 May 2012, 15:44
Espero tus comentarios...
Actualmente estoy desarrollando un par de aplicaciones en que las estadísticas son fundamentales para la correcta realización de las mismas. En primer lugar, aconsejaros que utilicéis Google Chart para pintar todo tipo de gráficas de una forma muy sencilla.
En una de las gráficas necesitaba obtener una gráfica para saber el trabajo de los usuario registrados en la misma en un espacio de tiempo. Concretamente necesitaba saber cuantas entradas había insertado cada usuario en cada mes. Para ello me decidí a utilizar una namedQueries y por lo tanto utilizar criteria. Este sería el código para realizar esta consulta agrupada tanto por usuario como por mes y año.
Es importante tener en cuenta que en la parte de sqlGroupProjection se hace referencia a la columna creada en la base de datos.
23 November 2011, 16:39
¿Qué te parecen estas características nuevas de Grails 2.0?
Tras el primer artículo que escribí sobre las nuevas características de Grails 2.0 en las que comentaba básicamente aquellas nuevas características que ayudaban al desarrollador a ser más productivo todavía si cabe, en este nuevo artículo comentaré otros aspectos novedosos en la nueva versión de Grails como son la introducción de HTML5 y otras mejoras relativas a la generación del contenido de nuestras aplicaciones así como de otras mejoras en lo relativo a GORM.
Quizás el aspecto que más llama la atención cuando generamos una aplicación en Grails 2.0 utilizando su scaffolding es el cambio de interfaz que ha habido en relación a versiones anteriores. Este cambio es debido principalmente a que en esta nueva versión se ha empezado a utilizar HTML5. Este scaffolding es mucho mejor que en versiones anteriores y representa lo que se conocen como buenas prácticas a la hora de diseñar aplicaciones web.
En la nueva versión de Grails también se facilita la creación de páginas para por ejemplo ser envíadas a través de emails (tipo newsletter) a través del API de la clase PageRenderer. Esta generación de emails se hacía complicada en versiones anteriores debido a la falta de una petición HTTP en la que basarse.
Del mismo, si en estos emails queremos generar enlaces dinámicos hacía partes de nuestras aplicaciones, podemos utilizar el API de la clase LinkGenerator.
Por otro lado, el plugin resources ha sido integrado en el nucleo de Grails 2.0. Este plugin permite declarar recursos estáticos en nuestras páginas de forma sencilla y además, optimizando incluso las llamadas a los mismos para no repetir peticiones a un mismo recurso.
Todo esto en lo relativo a la parte web de nuestras aplicaciones en Grails 2.0. Pasemos a ver ahora las nuevas características en lo relativo a la gestión de los datos de nuestras aplicaciones.
La características más importante es que GORM ya no se basa únicamente en Hibernate sino que puede ser utilizada con otros entornos como Mongo DB, Redis, Riak, Amazon SimpleDB, Neo4j o Cassandra.
Se ha creado para GORM lo que se conoce como las Where queries que no es más que un DSL para realizar consultas a nuestras clases de dominio.
def query = Person.where {
firstName == “Fran”
}
def fran = query.find()
Este tipo de consultas se comprueban en tiempo de compilación lo que nos adelanta posibles problemas de nuestras consultas. Además, te habrás dado cuenta de que incluso podemos utilizar caracteres como ==, >=, <=, <, >, != en estas consultas que posteriormente serán traducidas al lenguaje SQL correspondiente.
Además, también vamos a poder utilizar funciones agregadas como avg(), sum(), max(), min(), etc. En la siguiente consulta obtendremos aquellas personas cuya edad sea superior a la media.
def query = Person.where{
age > avg(age)
}
También podemos definir varias fuentes de datos de nuestra aplicación que como siempre definiremos en el archivo de configuración DataSource.groovy. Además, en Grails 2.0 también vamos a poder hacer ingeniería inversa a partir de un esquema de base de datos para ahorrarnos tener crear a mano todas las clases de dominio de la aplicación.
Por último, se han creado dos nuevas funciones de GORM que son findOrCreateWhere() y findOrSaveWhere() que como su propio nombre indica, en primer lugar buscar en las clases de dominio un registro que cumpla las condiciones pasadas en el método y en caso de que no exista lo crea o lo modifica en función del método utilizado.
10 November 2011, 10:41
¿Has utilizado algunas características?
Ayer estuve viendo un screencast presentado por Peter Ledbrook en el que presentaba las nuevas características que vendrán con la nueva versión de Grails 2.0, así que me he decidido a escribir unos pequeños artículos en los que comentaré esas nuevas características.
En este artículo veremos algunas características introducidas en el entorno de desarrollo de Grails. En primer lugar hay que comentar que se ha mejorado la interfaz de la consola en el modo interactivo en la cual podremos ejecutar cualquier comando de Grails y ayudarnos al mismo tiempo de su autocompletado. Llama la atención que incluso vamos a poder ejecutar comandos externos a Grails como si estuviéramos en el shell de Linux.
Se han mejorado también las plantillas que muestran los resultados de los tests para que sea más intuitivo saber que ha sucedido en la última ejecución de dichos tests. Siguiendo con las plantillas utilizadas en el proyecto Grails, desde la versión 1.3 la documentación seguía una estructura muy sencilla de consultar (IMHO). Pues bien, desde la versión 2.0 vamos a poder utilizar estas plantillas para realizar la documentación de nuestras aplicaciones en Grails.
Algo que nos ayudará a ser incluso más productivos es la mejora que se ha introducido en Grails 2.0 en el mostrado de los errores por pantalla. En esta versión se mostrará no sólo la línea en la que se produce un error en el controler sino que también se mostrará el error producido en el servicio en caso de que el controlador invoque a un servicio con lo que encontrar el error será una tarea mucho más sencilla.
Por otro lado, en Grails 2.0 se cambia la base de datos que viene por defecto para desarrollo, que hasta ahora era HSQLDB por H2. Pues bien, desde la versión Grails 2.0 vamos a poder consultar el esquema de base de datos creado automáticamente a partir de las clases de dominio accediendo a la URL http://localhost:8080/app/dbconsole y así hacernos una idea de lo que está creando Grails por detrás de las cortinas. Lo bueno de esto es que no sólo está disponible para una base de H2, sino que podremos hacerlo con cualquier base de datos que se pueda conectar mediante JDBC.
Algo que también me gusta mucho y que ayudará a saber que plugins son los mejores en cada categoría es que a partir de ahora se hará un seguimiento del uso de los plugins en proyectos reales, por supuesto, siempre y cuando demos permiso para esto. Con lo que ahora además de la propia valoración de los plugins podremos ver el uso que se está haciendo del mismo en otros proyectos.
Por supuesto, Grails 2.0 viene con las librerías actualizadas de los paquetes utilizados como son Groovy 1.8, Spring 3.1 y Hibernate cuyas versiones irán desde la 3.3 hasta la 3.6. Además, el plugin de Tomcat funcionará con la versión 7.
Los desarrolladores de Grails ya sabéis que en la mayoría de los casos no hace falta reiniciar la aplicación cada vez que introducimos un caso, pero esto no sucede en ocasiones y toca parar la aplicación. Pues bien, en Grails 2.0 no es necesario para la aplicación cada vez que hagamos referencia a un servicio desde un controlador, modifiquemos una clase de dominio o cambiemos una clase de los directorios src/groovy o src/java, ya no será necesario reiniciar la aplicación en desarrollo con lo que también ahorraremos tiempo. Además, también tenemos la posibilidad de añadir el parámetro -reloading en cualquier comando Grails.
Por último, si queremos desarrollar un plugin, hasta el momento no había más remedio que publicarlo en formato zip e incluir los archivos fuente de dicho plugin. Lo bueno que tiene esto es que si un plugin no hace exactamente lo que queremos podemos modificarlo a nuestro gusto y lo malo, es que nadie que quiera proteger su desarrollo, iba a subirlo como un plugin, con lo que muchas empresas no se implicaban en el desarrollo de estos plugins. Esto puede hacer que estas empresas terminen desarrollando plugins, aunque también será muy probable que terminemos pagando por ellos. Aunque como dicen por ahí, Nada es gratis y si algo nos soluciona un problema o nos ahorra horas de trabajo, es normal que tengamos que pagar por ello, ¿no?
La próxima semana veremos algunas mejoras introducidas en la parte web y GORM de Grails 2.0.
22 June 2011, 13:45
Espero tus comentarios...
En muchas ocasiones, el éxito de una idea reside en la rapidez con la que sepas llevarla a cabo y si esta idea además requiere de una aplicación, debes saber elegir que tecnologías y metodologías utilizar. Si por si fuera poco, el presupuesto inicial con el que cuentas es prácticamente nulo, debes acudir a soluciones gratuitas no significando esto que sean malas.
En este artículo voy a explicar como podemos utilizar CloudBees para desplegar nuestras aplicaciones en Grails utilizando como repositorio BitBucket y desplegando automáticamente las nuevas versiones de la aplicación a partir de los cambios subidos a nuestro repositorio.
Comencemos por BitBucket. BitBucket es un repositorio gratuito y privado (esto es muy importante ya que la mayoría no nos ofrecen esta privacidad) basado en Mercurial. Sí, ya sé que Mercurial no es de los sistemas de control de versiones más extendidos, pero si queremos esta privacidad y este precio (gratis), tenemos que conformarnos con esto.
BitBucket ofrece incluso colaboración entre usuarios hasta cinco de forma gratuita. Repito, pocos servicios ofrecen esto gratis. También puedes utilizar un wiki para generar documentación del proyecto e incluso tienen sistema de tickets integrado.
Pasemos al siguiente elemento de nuestro stack de aplicaciones que es “CloudBees”. CloudBees no es más que un servicio que te permite desplegar aplicaciones Java (o Grails en nuestro caso) en un servidor en producción. Esto se conoce como el RUN@Cloud. En la cuenta gratuita te permiten hasta 5 aplicaciones diferentes. Además de las aplicaciones, CloudBees también te ofrece la posibilidad de utilizar sus servidores de base de datos MySQL, también hasta 5 como máximo. Aquí es donde viene un problema con CloudBees y es que el tamaño máximo de estas bases de datos es únicamente 5 MB en la versión gratuita y el paso a la versión de pago la verdad es que me parece un poco cara (25$/mes por 1 GB). Ahí, no hay término medio.
La primera aplicación que desplegué en CloudBees fue el ManagerT1, esa aplicación que te permite jugar a la Fórmula1 con tu cuenta de Twitter y que la verdad es que no ha tenido mucho éxito, aunque ahí seguimos jugando un grupo de amigos (hasta que no regale un coche al ganador, creo que no voy a conseguir repercusión ;=)) y en ese momento, todavía no había nada de Integración Continua.
Sin embargo, recientemente y a raiz del artículo de Marco Vermeulen en el que hablaba de Integración Continua en CloudBees con Grails, me decidí a utilizarlo en las dos últimas aplicaciones que estoy realizando en la Universidad de Alicante (que por privacidad, no voy a poner aquí).
La integración continua de CloudBees se basa principalmente en una instancia de Jenkins (nuevamente gratuita) a la que puede agregarle tantas tareas quieras. Es lo que se conoce en CloudBees como el DEV@Cloud. Nosotros vamos crear una tarea, de tal forma que cada vez que se detecte un cambio en nuestro repositorio, se genere un nuevo archivo WAR y automáticamente se despliegue en nuestro servidor en producción. Por el momento no nos vamos a meter pruebas de cobertura, para no complicar demasiado el tema.
Pero antes de continuar, necesitamos instalar el plugin de cloudbees en nuestra aplicación Grails para facilitar el despliegue de la misma en nuestro servidor en producción. Para ello, simplemente ejecutamos en nuestro proyecto Grails el comando grails install-plugin cloud-bees que nos permitirá una serie de nuevos comandos en nuestra aplicación. Posteriormente a instalar el plugin, debemos también añadir unas entradas a nuestro conf/Config.groovy con unos datos que nos ofrece cloudbees en la página privada https://grandcentral.cloudbees.com/user/keys
cloudbees.api.url='https://api.cloudbees.com/api'
cloudbees.api.key='CLOUD_BEES_API_KEY'
cloudbees.api.secret='CLOUD_BEES_API_SECRET'
Básicamente, vamos a crear una tarea en Jenkins y la configuraremos de la siguiente forma (sólo especificaré aquellos campos donde debemos introducir información, el resto quedarán en blanco por defecto):
Con esta configuración le estamos diciendo a Jenkins que cada 5 minutos compruebe si se ha producido algún cambio en el repositorio y en caso afirmativo realizará todas las operaciones especificadas en el target que terminarán por desplegar la nueva versión de nuestra aplicación, siempre y cuando todos los tests se pasen correctamente, esperando por supuesto que un maravilloso sol se pose sobre vuestra tarea en Jenkins lo que indicará que el despliegue ha ido perfectamente y que podéis seguir con el desarrollo de vuestra aplicación.
9 May 2011, 13:33
Espero tus comentarios... [2]
Este fin de semana se ha disputado (y disfrutado también diría yo) el concurso AbreDatos, que pretende fomentar la apertura de datos por parte de las administraciones públicas para un mejor aprovechamiento de los mismos.
Junto con unos amigos (@alejandro_such, @crico_aven y @perex) hemos desarrollado para dicho concurso la aplicación Dónde aparco que informa de las plazas de aparcamiento en parkings públicos en la ciudad de Alicante.
Por el momento nos hemos centrado en la ciudad de Alicante aunque ya tenemos en el horno otras ciudades como Pamplona o Reus cuyos ayuntamientos también disponen de esas información pública.
18 January 2011, 23:10
Espero tus comentarios... [4]
Finalmente, ya ha salido a la luz el curso Desarrollo rápido de aplicaciones con Groovy&Grails que impartiré para el CEFIRE específico de la familia de Informática y Comunicaciones.
El curso se impartira de forma online y en él recorreremos las benevolencias tanto del lenguaje de programación Groovy como del framework para el desarrollo rápido de aplicaciones Grails.
El inicio de la inscripción es el próximo 4 de marzo y finalizará el 22 del mismo mes y está abierto a todos los profesores de secundaria y FP de la familia de Informática y Comunicaciones.
Si tienes cualquier duda con respecto al curso, no dudes en ponerte conmigo dejando un comentario en este mismo post.
1 October 2010, 11:43
Espero tus comentarios...
Yo creo que nunca en ningún entorno de desarrollo fue tan sencillo proteger las llamadas AJAX que realizas en tus aplicaciones web. Imaginemos el caso que tenemos una aplicación con la típica navegación por pestañas y que todo se carga en la parte inferior de esas pestañas.
Esta característica de nuestra aplicación la vamos a implementar con una etiqueta en Grails que se llama remoteLink y que permite especificarle, entre otros parámetros, un controlador, una acción y un elemento del DOM del HTML para que lo actualice con la información correspondiente que le venga de la llamada a la acción del controlador invocado.
Por ejemplo, imagina la típica pestaña de usuarios que nos permite listarlos. Podríamos tener algo así.
Es importante recordar que para poder utilizar la llamada a la etiqueta remoteLink debemos importar por ejemplo la librería de scriptaculous.
De esta forma, cada vez que el usuario haga click en cualquiera de las opciones, la información se cargará automáticamente en el div con identificador contenido y no tenemos que recargar la página por completo. Pero, ¿que pasa si alguien intenta acceder a la URL que carga ese contenido AJAX, por ejemplo, http://localhost:8080/miapp/ajax/listarusuarios? Pues que se vería el contenido de la llamada pero totalmente fuera del contexto que nosotros queremos, lo que podría provocar algún que otro problema en nuestra aplicación.
¿Cómo podríamos evitar esto? Pues muy sencillo. En Grails tenemos el concepto de filtros que nos permiten ejecutar antes y después de llamar acciones en los controladores e incluso después de que la vista de nuestra aplicación sea generada. Estos filtros son clases normales en Groovy que se deben alojar en el directorio de configuración de nuestra aplicación y cuyo nombre debe terminar por la palabra Filters. Nosotros crearíamos un filtro llamado SeguridadFilters.groovy en el directorio grails-app/conf con el siguiente contenido:
Aunque el código es bastante sencillo de entender, voy a tratar de explicarlo un poco. En primer lugar, le estamos indicando al filtro que cualquier llamada a una acción del controlador AjaxController me la capture y me permite realizar una serie de llamadas de comprobaciones. Esa comprobación consiste en saber si la cabecera X-Requested-With de nuestra petición coincide con la cabecera que se añade en las llamadas Ajax que es XMLHttpRequest y en caso de que no coincida, redirijo al usuario a una página de error.
Sencillo, ¿no crees? Creo que he tardado más en explicarlo que en hacerlo en la aplicación en la que estoy trabajando actualmente, que en cuanto la termine os podré contar más cosas interesantes sobre ella y sobre su forma de trabajo. Sólo adelanto que trabajamos con metodologías ágiles y con gente muy dispersa geográficamente hablando.
13 September 2010, 21:39
Espero tus comentarios...
El pasado 9 de Septiembre estuve en Cheste (Valencia) en unas jornadas impartidas a profesores de formación profesional de la familia de informática y comunicaciones#.
En la presentación presenté las benevolencias de la pareja formada por Groovy&Grails y como podría mejorar la productividad de las personas que se decidan a utilizarlo. La charla anterior a la mia la realizó Lorenzo Gascón y en ella estuvo hablando sobre las pruebas unitarias y la integración continua e intenté aprovechar esta presentación para indicar que Grails es el framework perfecto para poder centrarnos en este tipo de pruebas y que el programador pueda olvidarse de determinados aspectos de configuración.
Aquí os dejo la presentación que llevé a cabo.
