Gracias a los plugins de grails liberados a la comunidad, podemos aprovechar el esfuerzo hecho por otros desarrolladores y reutilizar el trabajo que han hecho. El sistema de plugins de grails da múltiples puntos de extensión para la plataforma: permite añadir comandos nuevos a la CLI, servicios, clases de dominio, extender dinámicamente algunos comportamientos… En el taller sacaremos partido del sistema de plugins de grails para reutilizar trabajo entre distintas de nuestras aplicaciones, veremos algunos ejemplos y desarrollaremos un plugin a modo de ejemplo.

Básicamente, mostraremos de forma práctica como reutilizar código en nuestros proyectos del día a día, más allá de liberar plugins que sólo tengan sentido ser liberados para el resto de la comunidad.

Este año volverán a ser 2 días de charlas y talleres, un eventazo a un precio de risa. Como podéis ver en la agenda, hay buena cantidad y calidad de ponentes, incluida alguna rockstar internacional entre ellos.

Cualquiera que trabaje o le interesen tecnologías alrededor de los ecosistemas Spring, Grails o Groovy debería asistir a este evento; o también a quienes les interesan cosas relacionadas con Mongodb, Scala, ElasticSearch, RabbitMQ o incluso temas de cloud computing.

Pero seguro que lo mejor está por los pasillos, durante los cafés y las comidas… o, por descontado, en la fiestaca del jueves .

Nos vemos en el Spring I/O!

Fue un desarrollo exprés, ya que tenía otros compromisos que no podía dejar de lado. Fueron unas 6 o 7 horas de trabajo a tope ese mismo fin de semana, pero me apetecía colaborar por fin con algún medio, aunque fuera tan pequeñito como lo es arredol .

Herramientas utilizadas:

• El API que puso a disposición El País. Que básicamente hizo el trabajo que según los que defendemos el OpenData debería ser responsabilidad del Ministerio del Interior, poner a disposición de cualquier persona o entidad esos datos de forma estructurada para poder procesarlos.
• El API de Google Charts para las representaciones gráficas. No pude adaptar los colores por partido por las limitaciones que tiene, o al menos no logré dar con la solución.
• En el lado del servidor PHP y simplexml para procesar la información de El País. Básicamente por que el hosting de arredol sólo soporta php, no por otra cosa en especial.

Como podréis comprender, por haber sido un pequeño desarrollo hecho a toda prisa, el código en general es muy mejorable; pero el resultado cara al usuario creo que no está del todo mal.

Seguramente fuera una solución muy alejada de las herramientas de visualización de algunos grandes medios de comunicación, con una posibilidad de interacción mucho mayor. Pero en Aragón quizás fuera de lo mejor, cosa que casi me entristece.

No vi que tuviera mucho que envidiar a lo que vi que hicieron por ejemplo en la web de Heraldo, y no digamos de El Periódico de Aragón donde no vi nada especial para la ocasión… Supongo que no dedicarían muchos esfuerzos…

Y también el video

Este Miércoles, 9 de noviembre a las 16:00 yo estaré hablando de Grails: Aumenta tu productividad en tus aplicaciones web Java, lo que vendrá siendo una charla donde me gustaría introducir un poco el mundillo de groovy y grails, y donde procuraré mostrar todo el código posible para que los asistentes se puedan llevar una idea aproximada de lo que les puede aportar.

La verdad que es impresionante la variedad de sesiones que se han organizado, yo espero asistir a bastantes, veremos a las que el trabajo me permite.

Nos vemos por el Seminario .

Pues resulta que andaré por ahí para hablar de optimización de webs Grails, sobre buenas prácticas de desarrollo web y como llevarlas a cabo en proyectos Grails.

Cuando desarrollamos una web podemos seguir algunas buenas prácticas para que estas resulten más rápidas, lo que que repercute en una mejora en la experiencia de usuario, escalabilidad o incluso en el posicionamiento en buscadores.

En esta charla se tratarán esas buenas prácticas, como podemos llevarlas a cabo con Grails y el uso de algunos plugins que nos facilitan el trabajo.

Esta pedazo de agenda es principalmente gracias a Alberto Vilches, que es el que se lo ha estado y está currando.

* La idea del video viene por los “hola conferencia rails”

Introducción:

Grails es un framework web open source para la plataforma Java, que sigue los principios Don’t Repeat Your Self(No te repitas) y Convention over Configuration(Convención sobre configuración). Grails se inspiró de incio en Ruby on Rails, llegándose a llamar de inicio Groovy on Rails con el que además de estos principios comparten otras similitudes como: scaffolding, layouts, taglibs(en rails helpers), sistema de plugins…

Grails es algo más que un framework MVC, también nos ofrece capa de persistencia, capa de servicio, contenedor de servlets y gestor de bases de datos. Se sustenta sobre varios frameworks y librerías Java muy conocidas y probadas como son Spring Framework, Hibernate, Sitemesh, Log4j, Jetty, Hsqldb… y del lenguaje de programación Groovy.

Instalación:

Para instalar Grails debemos descargarnos la última versión(en éste momento 1.0.3) en http://www.grails.org/Downloady extraer el contenido del archivo comprimido.
Crear la variable de entorno GRAILSHOME apuntando hacia el directorio que hemos extraído y añadir el GRAILHOME/bin en la variable de entorno PATH.
Tras esto ejecutamos en una consola el comando grails help y con el que nos debería salir el listado de comandos de grails.

¡Ya podemos crear nuestra primera aplicación!

La aplicación:

Veremos una aplicación de ejemplo que se compondrá tan sólo de una clase de dominio para una gestión de un catálogo de productos.

Creamos la aplicación con:

grails create-app catalog

Una vez ejecutado entramos al directorio de nuestra aplicación:

cd catalog

Aquí podemos ver la estructura de directorios que se ha generado:

• grails-app: Artefactos de Grails(controllers, vistas, clases de dominio, taglibs, configuraciones…)
• lib: Librerías para nuestro proyecto (que no traiga Grails de serie, claro)
• plugins: Plugins instalados
• scripts: Scripts Gant
• src: Clases java o groovy que no sean artefactos de Grails
• test: Tests de nuestra aplicación
• web-app: css, imágenes, ficheros html estáticos…

Tras ésto creamos la clase de dominio:

grails create-domain-class product

Vemos que en grails-app/domain se ha creado Product.groovy(además en los tests ProductTest.groovy), que abriremos y añadiremos los atributos a la clase(por ejemplo: name, description y provider)

class Product{
String name
String description
String provider
int quantity
}

Y con ésto hemos terminado de definirlo, al ser un POGO no son necesarios getters y setters, ya que Groovy es quien se encargará de generarlos en tiempo de ejecución.
Tras esto utilizaremos el scaffolding, que nos creará un controller con las acciones básicas y susrespectivas vistas:

grails generate-all product

Veremos que en grails-app/controllers tendremos un ProductController.groovy y en grails-app/views/product los .gsp que son las respectivas vistas de las acciones de ProductController.

Tras ésto, podemos arrancar el servidor embebido que trae Grails y una vez arrancado podemos ver el resultado enhttp://localhost:8080/catalog/:

grails run-app

Con esto tenemos generado el esqueleto de nuestra aplicación sin crear un war, sin ir a crear tablas en la base de datos, sin configurar nada…

Con esto no hemos hecho más que empezar, como ejercicio es recomendable mirar el código que se ha generado en el controller y en las vistas, modificar algo, tratar de añadir alguna acción nueva como podría ser una acción para sumar 1 a la cantidad de un producto. Y cómo no, no dejar de seguir la guía de referencia

Ojalá aparezca alguien con capacidad y motivación suficiente para reflotar y mantener debugmodeon.

Llevo un par de días estando trabajando con este soporte JSON para reunir datos importados de distintas fuentes, y luego poder mantener los datos resultantes en un formato estructurado. Principalmente porque no todos son necesarios a día de hoy, pero a futuras se puede echar mano de ellos.

Después de hacer todo lo necesario unificar todos los datos en un map en memoria, para persistir el JSON, he hecho uso de JsonBuilder.

Sería algo así:

def builder = new groovy.json.JsonBuilder()
builder.data(){
  for (item in items){
    "${item['name']}"() {
      zone(item['zone'])
      position(item['position'])
      ....
      ....
    }
  }
}

Esto lo que generaría es algo de una estructura como:

{"data":
  {"name1": { "zone" : "zone1", "position": "position1", ... }}
  {"name2": { "zone" : "zone2", "position": "position2", ... }}
  ...
  ...
}

Después tan sólo debía escribirlo en un fichero:

new File("path/to/file.json").write(builder.toString())

Y listo.

Hace unos pocos días nos encontramos uno de esos problemas curiososos. Resulta que teníamos varios mapas en una misma página, dentro de la que habían mapas en capas ocultas usando css. La curiosidad en cuestión es que al hacer visibles esas capas no se pintaban correctamente los mapas.

Buscando un poco que podría estar pasando, resulta que cuando creas el mapa google maps coge los estilos que hay en ese momento, y al pasar de oculto a visible el API no es consciente que ha cambiado la visibilidad del elemento que lo contiene y donde se pinta.

Esto en la V2 del API se solucionaba usando checkResize, pero resulta que para V3 no está disponible ese método para notificar al mapa que se redimensione.

La necesidad de un checkResize está reportado como bug de la versión 3. Pero por suerte en los mismos comentarios aparecen algunas soluciones que me han venido como anillo al dedo para ir trasteando y terminar implementando una solución un poco más a mi gusto, añadiendo a la clase de google.maps.Map un comportamiento equivalente:


google.maps.Map.prototype.checkResize = function() {
   var center = this.getCenter();
   google.maps.event.trigger(this, 'resize')
   this.setCenter(center);
}


Y así ya puedo utilizar el checkResize en los mapas del mismo modo que en la versión 2.

La oferta con todos los detalles está en jobsket: Aprendiz de programador web.

Aprendiz según la RAE:

aprendiz, za.
1. m. y f. Persona que aprende algún arte u oficio.
2. m. y f. Persona que, a efectos laborales, se halla en el primer grado de una profesión manual, antes de pasar a oficial.

Otros más refinados le llamarían programador junior, pero creo que en muchos otros oficios le llaman acertadamente aprendiz. Otra opción era buscar directamente un padawan, pero los del lado oscuro somos disimulados

PD: Sí, dentro de trabajar en equipo entra irse de cañas de vez en cuando con el resto del equipo XD

* Foto de pasukaru76

El equipo y la idea:

Hice equipo con Mamen Pradel (diseño), Toño García (ilustración y animación) y Agustín Raluy (márketing); vamos, que arriesgamos en cuanto a la formación del equipo, descargando importancia a la parte de programación y dándosela a la de diseño/presentación. Y no, no hubo muchas discusiones en cuanto al código XD.

Como altoaragonés, tenía ganas de participar con un equipo desde la provincia de Huesca, que hay que intentar descentralizar un poco el foco que tiene Zaragoza en cuanto a temas tecnológicos y repartirlo por el resto de Aragón. Por eso nos fuimos a nuestros respectivos pueblos (“secuestrando” a Mamen de tierras mañas ), y montamos el cuartel general el fin de semana en las oficinas de Integral Stand en Barbastro.

El origen de la idea es un poco de rebote, un día “tuiteé” un post (en aragonés) de @purnas: Gaddafi bombardeya con armas zaragozanas (A historia d’Instalaza), y @dcabo me remitió al foro de AbreDatos por si me interesaba el tema de la exportación de armas.

Tras el beersotrimng pre-abredatos de cachirulovalley dejamos cerrada la temática y casi el equipo con Mamen y Agustín. Hubo otro programador oscense que estuvo a punto de formar parte el equipo, pero que finalmente no podía participar ese fin de semana. Por lo que surgió la idea de convencer a Toño y darle un enfoque completamente de visualización de información.

En cuanto a lo que íbamos a implementar, fueron Mamen y Toño quienes estuvieron conceptualizándolo. Yo sabía que iba a tener que pellear con la web de aduanas, y sólo me iba a tener que preocupar como sacar la información.

El desarrollo:

Tenía bastante claro que iba a desarrollar la web con Grails, aunque el front iba a ser muy sencillo y podría haber utilizado frameworks más minimalistas, fui a asegurar con el framework web que mejor conozco y más productivo puedo ser.

Tengo que confesar que iba muy confiado con la extracción de datos, había unos ficheros con formato “tipo CSV” que podía scrapear desde la web para descargarlos, y así poder procesar y cargar esos datos a la web en Grails.

Para el scarpping pretendía utilizar python y BeautifulSoup, una librería que ya conozco del año pasado y que facilita mucho trabajar en extraer información de HTML.

Pero la web de aduanas tenía una curiosidad, al hacer la primera petición a la web, esta te devolvía un documento HTML con sólo un código javascript para redirigir a la home. Supongo que ahí deben escribir alguna cookie en el navegador con alguna finalidad que mi cerebro no ha sabido suponer, y entonces ya permite navegar libremente.

Estuve probando con herramientas tipo mechanize para python y ruby. Pero con la presión del tiempo, al ver que no conseguía que me funcionaran y me cansé de ver como pasaban las horas inútilmente.

Finalmente tomamos la decisión de descargar los datos a mano (limitándonos sólo a exportaciones de 2009 y sin poder entrar a detallar el tipo de armas). Ya traía aprendido del año pasado que es mejor acotar el alcance en caso de problemas.

En cuanto la aplicación Grails, me centré exclusivamente en terminar, olvidad ver soluciones sofisticadas y elegantes en mi código:

• La base de datos es la HSQLDB embebida de Grails, pero cargada en memoria para que resulte más rápido.
• Cada vez que se arranca la aplicación se cargan todos los datos, que realmente están persistidos en ficheros de texto.
• No hay tests y el código en general tiene bastante margen de mejora.

El despliegue:

Tenía ganas de probar cloudfoundry por fin, que hacía unas semanas que me habían dado acceso a la beta. Cuál fue nuestra sorpresa cuando ya desplegamos la primera versión, que no había manera de apuntar el dominio a cloudfoundry, que aún lo no soporta (Y hasta que no lo soporte no me planteo utilizarlo).

Entonces pensé en Amazon Beanstalk y en CloudBees como PaaS alternativas para webs en Java, ya que evidentemente no había mucho tiempo de preparar una máquina desde 0. Y tras algunas gestiones en paralelo para ver donde desplegábamos, terminé desplegando en CloudBees y el dominio pasó a apuntar allí.

Os dejo unas fotos para que veais lo mucho que sufrimos y lo mal que lo pasamos

Comimos genial, haciendo parrilladas en Monzón y Barbastro, no faltaron la cerveza, las risas y tampoco las tensiones de última hora .

Por cierto, que resulta que hemos entrado entre los 8 finalistas del AbreDatos. Quien quiera puede valorarnos a nosotros y al resto de participantes en la web de votaciones de AbreDatos.