Arragonán

Dejo aquí la presentación que hice en Greach 2011 sobre optimización de webs con Grails.

Y también el video

Desde CachiruloValley estamos colaborando en un track de la Libre Software World Conference, bajo el nombre de Cachirulo Tech Talks, que se celebra los días 9 y 10 de noviembre en Zaragoza (con un aforo de 600 personas, y completo!).

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 .

El día 4 de Noviembre, se celebra en Madrid (Universidad San Pablo CEU) la conferencia española de Groovy: Greach.

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”

Artículo publicado hace un par de años en debug_mode=on y recuperado a mi blog depués del último tuit de la cuenta oficial y de Belmonte. Aunque no sea (ni de muy lejos) el mejor contenido que me haya trabajado, me hace duelo pensar en perderlo, por eso lo reproduzco aquí:

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.

Una de las muchas novedades que vinieron con Groovy 1.8 fue el soporte nativo para generar y leer JSON.

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.

Como (supongo) casi todo programador web que ha hecho desarrollos para internet, he tocado en múltiples ocasiones partes del API de google maps.

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.

Como supongo que algunos sabréis, ando trabajando con UniversalPlaces desde hace unos meses. Pues resulta que ahora andamos buscando a una persona para ser el/la primer/a programador/a en plantilla, para trabajar en el mismo centro de Zaragoza.

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

Por fin he sacado un rato para escribir sobre nuestra participación en el Desafío AbreDatos 2011 con elDisparate.

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.

Hacía un par de meses que tenía medio terminado un plugin de grails llamado localizable, y al fin he limpiado un poco las dependencias para que cumpla unos mínimos antes de hacerlo público.

Es una pequeña utilidad para facilitar la integración con el API del servicio de Geocoding de Google Maps para los proyectos desarrollados con grails.

Se puede obtener la latitud y longitud a raíz de una dirección, o las direcciones a partir de la latitud y longitud.

Para instalarlo:
grails install-plugin localizable

Tras haberlo instalado, tendremos a nuestra disposición un servicio de grails(geocodingService) que nos facilitará el trabajo de geolocalización a partir de un puñado de métodos:

findLatLngsByAddress(address) //Devuelve un array con las posiciones encontradas a partir de una posición.

findLatLngByAddress(address) //Devuelve sólo la primera posición encontrada a raíz de una posición.

findAddressesByLatLng(lat, lng) //Devuelve un array con las diferentes direcciones coincidentes con una latitud y longitud.

findAddressByLatLng(lat, lng) //Devuelve la dirección más completa que coincida con la latitud y longitud.

findPointsByAddress(address) //Devuelve un array de JSONObject que representan los puntos coincidentes con la dirección.

findPointsByLatLng(lat, lng) //Devuelve un array de JSONObject que representan los puntos coincidentes con la latitud y longitud.


Podéis ver un pequeño ejemplo de uso en el código que utilizamos para un taller de hace unas semanas con primerviernes

Próximos pasos: Preparar la documentación de uso del plugin en inglés, espero que me cueste menos tiempo .

No entra en mis planes añadirle más funcionalidades, pero por supuesto que estoy abierto a sugerencias y/o contribuciones.

Ando metido en un proyecto muy chulo llamado UniversalPlaces, TorresBurriel ya publicó un post hablando sobre el lanzamiento inicial y el equipo(equipazo!).

UniversalPlaces es una web donde se pueden reservar estancias en hoteles. A día de hoy todavía en fases iniciales de lo que se pretende que llegue a ser, pero seguro que en los próximos meses dará mucho que hablar

Si indagáis un poco, veréis que el equipo es de todo menos convencional. Y no me refiero a que el equipo esté por encima de la media(que lo está!), si no a que es un equipo “a medida” para el proyecto. Cada miembro del equipo trabajamos independientemente a los demás, y aunque alguna vez hayamos podido/podemos/podamos coincidir, tenemos otros jaleos . Una apuesta diferente a la habitual por parte de Javier Mcallan, para entrar a competir en un sector tan duro como es el del turismo en internet.

Mi rol dentro del equipo ha resultado ser programador y algo así como el responsable(o irresponsable ) de la parte técnica. Nuestro objetivo desde la parte técnica, es que la tecnología existente resulte la menor limitación posible para ofrecer una mejor experiencia de usuario, y os aseguro que está siendo todo un reto!

Bueno, y cómo imagino que no esperaríais otra cosa de mi, os voy a contar un poco acerca de que tecnologías estamos utilizando(por ahora nada excesivamente especial):

• Es una aplicación web hecha con Grails. Es el framework que más domino a día de hoy, y para este proyecto encaja perfectamente. Como se puede suponer, también hay un trabajo muy importante de integración, y la plataforma Java tiene multitud de herramientas para ello.
• Corre sobre un Apache Tomcat 6 en producción.
• Usamos MySQL y MongoDB para las bases de datos. La primera para guardar lo relacionado con reservas, clientes… Y la segunda a día de hoy es poco más que una caché de búsquedas de estancias, para lo que podríamos estar utilizando otras muchas herramientas tipo clave/valor, pero mientras ganamos experiencia para experimentar con algunas características de Mongo que pueden encajar muy bien con funcionalidades que están en el roadmap.
• El servidor es un dedicado bastante resultón, que ahora mismo va bastante sobrado.
• También estamos utilizando Amazon S3 para servir las imágenes y Postmark para mandar por email la confirmación de las reservas. Son servicios que hemos externalizado desde ya.

Y como curiosidad una métrica, a día de hoy, con la funcionalidad que se puede ver, tenemos poco más de 2200 líneas de código groovy y java.