Arragonán

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.

Soy aficionado a hacer deporte, me gusta practicarlo y sigo algunos. Y el que más me gusta es el fútbol (soy un tipo raro, lo sé ), seguidor/simpatizante del Zaragoza y el Huesca. Pero aunque sufro y disfruto de esos equipos, no soy un forofo y mucho menos un gran consumidor de prensa deportiva.

Pero para mi el fútbol y derivados, son deportes que ha tenido siempre un lado romántico para mi, juego en ligas de amigos a fútbol sala y fútbol 7; y en su día jugué en el equipo de fútbol de mi pueblo, en la 2ª regional aragonesa por muchos campos de los pueblos de la provincia de Huesca. Esto me ha permitido conocer gente, hacer amigos, descubrir algunos pueblos o conocer un poco mejor la ciudad en la que vivo.

Y seguramente os preguntaréis porqué escribo esto en un blog que suele ser de temática técnica o profesional. Pues porque he participado en el desarrollo de la web de la revista Panenka: un desarrollo donde nos hemos repartido el trabajo con Guillermo, el tío que entre otras cosas más y mejor desarrolla con wordpress que conozco; donde yo me he encargado principalmente del trabajo con PayPal haciendo alguna cosita con php.

Los que conocéis el tipo de proyectos en los que participo como programador freelance quizás os sorprenda que haya trabajado en un proyecto de estas características, porque a nivel técnico NO es de los que yo suela participar. Pero el que para mi el fútbol tenga ese punto romántico, que la revista trata el fútbol desde un punto de vista principalmente cultural y con quienes hay detrás de la revista hizo que me gustara mucho el proyecto y me apeteciera mucho participar.

Aunque como en todo desarrollo de un proyecto web, ha tenido momentos críticos, es un proyecto en el que me ha gustado mucho participar y sólo puedo animaros a que compréis el número 0 de la revista en pdf o en papel, si os gusta el fútbol, claro .

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

Este viernes 17 y sábado 18 de junio se celebró en Pamplona el Agile Open Space 2011, evento organizado por voluntarios de la asociación Agile Spain. Es el segundo año que he podido asistir, definitivamente me gusta este evento y me ha vuelto a saber a poco; el sarao, y por supuesto el post-sarao para poder hablar más con la gente.

Viernes

El viernes, mientras arrancaba el AOS se iban sucediendo los saludos entre los habituales, se explicó como funciona el formato de open space por si habían dudas, se hizo un pequeño ejercicio para tratar de conocer gente nueva (creo que se comentó en la retrospectiva ya que hubiera estado bien hacer alguna cosa más en este sentido) y los asistentes empezaron a proponer temas.

Posteriormente pasamos a las votaciones y se distribuyeron las sesiones en las 6 salas que habían disponibles en el CEIN. El resultado puede verse en la siguiente foto.

No tuve suerte y varias de las sesiones que voté coincidieron en horarios. De todas formas, con todo lo que había para elegir y la regla de los dos pies, no había problema .

A la noche, hubieron cañas y pintxos ágiles, al parecer en varios grupos… Y un pequeño reducto de valientes formado por parte del Comando Muyayo y el que os escribe, nos quedamos tomando unos copazos ágiles por las calles del casco, pero me consta que no fuimos los que más trasnochamos .

Sábado

El sábado, con el cansancio acumulado de una semana dura y el agilismo nocturno, me desperté con una dura resaca en cascada . Lo que me hizo estar poco participativo durante gran parte de las sesiones, limitándome a escuchar y analizar lo que se hablaba o debatía.

La primera sesión deambulé un poco, entré tarde a la sesión sobre stubs, spies y mocks que facilitó Rubén Bernández, la única de puramente código a la que asistí. Al final de la sesión dejé la sala al ver que el debate que surgió se fue a volver a hablar de terminologías del tipo de dobles para tests, lo que no me iba a aportar gran cosa y además necesitaba que me diera el aire XD.

Posteriormente entré a la que propuso Miguel Ángel sobre contratos ágiles. Me interesaba conocer el tipo de acuerdos a los que llega otra gente con sus clientes para poder trabajar de forma ágil, y sobre todo como eso se traducía en la forma de facturarles. Surgieron fórmulas de por valor entregado, por historias de usuario, por dedicación… me pareció que cada uno dentro de su entorno hacía lo que podía.

En esta sesión surgió debate alrededor de si en la realidad, el mundo real, etc. es posible hacer o no algunas cosas. Es algo sobre lo que un día me gustaría escribir, pero como es muy posible que no lo haga, solo diré que cada vez que oigo cosas como “… pero en el mundo real …” yo ya escucho “… pero en mi contexto…”. Y sí, seguro que lo puedes cambiar; y no, seguro que el camino del cambio no será fácil, posiblemente sea durísimo.

Después me metí en la de identificar, atraer y mantener gente con talento a una empresa con Israel Alcázar y Raquel Laina… tenía intención de sólo estar un rato y moverme a otras salas, pero como me pareció interesante el debate me la tragué entera. Personalmente el método de búsqueda de gente buena que más me gustó fue con diferencia la que se comentó de github: montar saraos en sus oficinas para poder ir conociendo a gente potencialmente interesante, y eso acompañarlo de cervezas .

La siguiente para mi fue Agile UX, donde Artiz Suescun habló un poco sobre el estado del arte de integrar a gente de UX en el mundo ágil y sus dificultades. En la poca experiencia que tengo yo de trabajar con metodologías ágiles (o supuestamente ágiles, que a veces no tengo claro del todo lo que es o no agile ) con gente de UX, no he notado tantos problemas como los que se expusieron, supongo que simplemente por una cuestión de profesionalidad y compromiso de equipo. Lo que parece estar más o menos claro es que aún no hay métodos de trabajar agilmente con la gente de UX que estén consideradas buenas para muchos escenarios.

Después de comer entré a la que facilitaba Alberto Peña, donde se hizo un poco de brainstorming sobre el aprendizaje continuo que llevamos y que técnicas utilizaba cada uno para seguir mejorando en nuestro tiempo libre. Llevo ya varios meses un poco paradillo y fuera de cosas que necesito en mi día a día aprendo poco, aparte que con esto de ser freelance llevo bastante confusión entre horarios de trabajo y libre

Para terminar, estuve en la sesión de inceptions, donde se hizo una pequeña introducción de lo que es. Posteriormente Jorge Jiménez explicó su experiencia recibiendo una con wiseri y Miguel Ángel explicó algunos detalles de como lo hacen en BeCode.

Personalmente me interesaba bastante, ya que estoy planteándome dar consultoría de conceptualización de productos y servicios tecnológicos, creo que combinarlo con algunas de las prácticas que se hacen en esas inceptions pueden ayudar en eso.

Después se hizo retrospectiva del evento, donde surgieron cosas que gustaron y que no gustaron. Tras ellos se habló de la siguiente edición, donde Teresa Oliver y Yeray Darias propusieron Zaragoza y Canarias como sedes para la del 2012.

Al final foto de familia, despedida de parte de la gente y directamente de vuelta a Zaragoza.

Desde luego, me quedo con la sensación de que la comunidad ha madurado durante este año, y que el formato de evento en la que no hay ponentes propiamente dichos ayuda a mezclarse bastante. Por otro lado este año he conocido mucha menos gente nueva, quizás porque hay un grueso de gente que empezamos a ser habituales en estos saraos y eso hace que algunos sintamos un poco que siempre somos los mismos, aunque en realidad no sea así.

Las instalaciones de navarra factori, muy chulas. Mucho espacio y sitios donde juntarte con alguien a tener charlas de pasillo… incluso zonas tipo siéstodromos, que aunque el cuerpo me pidió aprovechar, conseguí no hacerlo

También llegó a mis oídos (o más bien a mi timeline de twitter), que se me echó de menos en el post-evento nocturno… tranquilos, para el año que viene despejaré mi agenda de puestas en producción, y lo daré todo

En fin, que el año que viene más, y por o que he leído por ahí parece que Zaragoza tiene casi todos los números y tocará pringar

Con mucho retraso os dejo aquí las dos presentaciones que hice en theEvnt 2011.

La de Open Data y DNDzgz:

Y la de Jobsket:

La verdad que el evento me gustó mucho, nos trataron genial y tuve la oportunidad de tener muchas conversaciones interesantes con ponentes y asistentes. Me quedaron unas ideas en mente que espero ordenar en algún momento, para poder desarrollarlas y escribir sobre ello.

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.

Cuando escucho el clásico De cacería, del Club de los Poetas Violentos, siempre me quedo a la espera de la parte de Kamikaze del final. Cuando lo escucho me viene algún tipo de gente de esa que “trabaja” en IT/internet… y del mamoneo en general, claro.

A ver, entonces partimos de la base de que voy con una peña, mi peña,
y que cada uno hacemos movidas
y nos salimos haciendo movidas,
nos juntamos para hacer movidas y nos salimos incluso más,
así que ¿con quién estoy? ¿con quién voy?, ¿con quién me vas viendo?,
con mi peña, mi gente, mi mogollón
que mañana será con los que yo estaré, según lo que vaya sucediendo,
y toda esa peñita que no conozco y mientras de buen rollo, ¿mañana qué?
supongo que eso no depende de cómo este yendo, sino de lo que siga vendiendo,
así que me la sudáis,
yo seguiré cumpliendo conmigo mismo, y con los que cumplen conmigo,
y me importa una mierda lo que vais diciendo,
las tonterías que estáis escribiendo,
yo defiendo lo mío, defiendo los míos, defiendo lo de los míos,
buen rollete sí hombre, que no os hagáis líos anda,
que ya sabemos por dónde van los tiros,
que ya no estamos pa tonterías, que la peña ya ha madurado,
y junto a los imbéciles los frutos están cayendo,
haced lo que os da la gana y dejadnos con nuestras vidas,
dejadnos con nuestras movidas,
que ya nos tenemos los unos a los otros pa lo bueno y pa lo malo,
y siempre haremos lo que el corazón nos pida,
si somos unos buscavidas y tiraremos palante digas lo que digas,
y cuidadito con destruirnos el camino,
que no estamos pa hostias
¿¿Sabes??