Todos los artículos escritos en este blog. No olvides comentarlos.
18 October 2013, 14:33
Espero tus comentarios... [2]
Emigrar para trabajar al Reino Unido no es algo sencillo y con la experiencia de haberlo hecho ya dos veces en el último año, me siento en condiciones de escribir un artículo que pueda ayudar a otras personas a hacer ese proceso más sencillo.
11 September 2013, 22:35
Espero tus comentarios...
Ayer mismo salió la nueva versión de Grails, la 2.3.0 que destaca, entre otros aspectos por las mejoras en el soporte a los servicios REST y el aumento de la seguridad para evitar ataques XSS.
Esta misma mañana he intentado actualizar una aplicación que estoy desarrollando y de la que por el momento no puedo hablar y me he encontrado con el problema de que se desaconseja el uso el típico comando grails upgrade puesto que está en estado de deprecated. A partir de ahora debemos utilizar el comando
25 June 2013, 14:51
Espero tus comentarios...
Si hace 8 meses escribía un post para anunciar que dejaba la Universidad de Alicante para empezar a trabajar para Secret Escapes en Londres, ahora es el momento de escribir un nuevo post para decir que dejo Londres, para volver a Alicante y empezar una nueva aventura como programador freelance.
24 December 2012, 13:11
Espero tus comentarios... [4]
Después de más de dos meses en mi nuevo puesto de trabajo y casi diría yo en mi nueva vida lo único que puedo decir es que no nos hemos equivocado en la decisión tomada. Hablo en plural porque esta decisión ha sido conjunta entre mi mujer y yo y aunque ella todavía está en España, en breve me acompañará en esta aventura.
Pero vamos a lo que quería os contar en este post. El título de mi puesto de trabajo es Senior Software Developer en Secret Escapes, una start-up con base en Londres que se dedica al mercado de los viajes de lujo con grandes descuentos.
Os cuento un poco la estructura actual del departamento técnico de la empresa. A la cabeza está el CTO de la compañía que dirije a 4 programadores, dos de ellos seniors, y dos diseñadores gráficos.
Las teorías ágiles están al orden del día en nuestro departamento y todas las mañanas tenemos nuestra reunión stand-up en la que todos los miembros del equipo cuentan brevemente que hicieron el día anterior y que tienen previsto para ese día. Por supuesto, en esta reunión nada de estar sentados y suele durar unos 10-15 minutos.
Para organizarnos las tareas y saber que está haciendo cada uno de nosotros utilizamos Trello, el típico tablero Scrum con las diferentes fases por las que pasan las tareas antes de ser desplegadas ( backlog, doing, done, staged y deployed). Para tareas complejas utilizamos un único tablero para esa tarea y así fragmentar mejor la misma.
Una vez ya sabemos que tenemos que hacer ese día, es hora de programar y en muchas ocasiones no lo hacemos solos sino que hacemos pair programming bastante a menudo. Es la primera vez que practico esta técnica y la verdad es que todos son ventajas, en primer lugar porque es una forma de involucrar a todos los miembros del equipo en el desarrollo de todas las tareas y que luego no aparezca la típica frase de “es que eso sólo lo sabe hacer Pepito”.
En todo momento la empresa y su CTO aboga por seguir la metodología TDD (Test Driven Dvelopment), que también era la primera vez que lo utilizaba y de nuevo, tiene muchas ventajas aunque el programador debe cambiar su manera de afrontar los problemas y la verdad es que al principio me ha costado un poco (Recomendar libro) y en más de una ocasión me han cogido algún trozo de código nuevo y me lo han borrado por completo porque no había hecho primero los test. Al principio jode, pero luego te das cuenta de lo importante que son los test en un entorno tan cambiante como es una start-up.
Esto ya no sé si se enmarca dentro de las meotodologías ágiles pero una hora y media antes de terminar la jornada de trabajo, debemos cortar de forma bastante radical lo que estamos haciendo para hacer cualquier otra tarea que aparezca en el tablero Scrum. En ocasiones no te gusta cuando estás con un tarea y no puedes terminarla porque toca cambiar, pero en la mayoría de las veces, ese cambio supone un descanso en una tarea en la que muchas veces estás atascado para pasar a otra y refrescar la mente al mismo tiempo que ir sacando pequeñas tareas pendientes y que casi nunca hay tiempo para desarrollar.
Para analizar como ha ido el día a día, cada dos semanas, los viernes a última hora de la tarde, en un ambiente muy relajado, tenemos lo que llamamos las reuniones retrospectivas en la que cada miembro del equipo expone brevemente y por medio de post-its 5 aspectos (start, stop, more, less, continue) en el que se definen que ideas se deben empezar, parar, ampliar, relajar o continuar en la próxima iteración. Con todas estas ideas puestas en un tablero, cada miembro escoje 3 de esas ideas y posteriormente el CTO las recopila para extraer las 3 más importantes.
Ya en la parte menos relativa al agilismo, comentaros que como gestor de repositorios del código fuente utilizamos git y nos ayudamos de git-flow para gestionar las features, los hotfixes y las releases.
Y ya por último el ambiente en el departamento técnico es increíble y prácticamente todo los días comemos juntos y los viernes tras el trabajo solemos ir a tomar algo junto. Así que lo que decía al principio, estoy muy satisfecho con la decisión tomada.
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.
