Global Day of Coderetreat 2015

Como en ediciones anteriores, este año no podíamos dejar de celebrar el Global Day of Coderetreat. En esta ocasión, algunos osokers nos reuniremos en nuestras oficinas el sábado 14 de noviembre para participar de este evento global.

Si quieres unirte a nosotros para pasar un día programando junto con otros desarrolladores con los que compartir y aprender, estaremos encantados. Eso sí, por favor, no olvides confirmar tu asistencia con antelación para poder controlar el aforo.

Pero, ¿qué es el Global Day of Coderetreat?

El Día Global del Coderetreat es un evento que se celebra simultáneamente en varias ciudades del mundo y que consiste en la práctica del desarrollo de software durante un día entero empleando el formato de coderetreat. El lema de la iniciativa es:

A day to celebrate passion and software craftsmanship

El año pasado participaron más de 5.000 personas en más de 170 ciudades alrededor del mundo.

Puedes encontrar más información sobre este evento en la web oficial de Global Day of Coderetreat, así como en el anuncio del evento para 2015.

Si tienes curiosidad, puedes consultar todos los eventos planificados para el GDCR 2015.

¿Qué es un Coderetreat?

Un coderetreat es un tipo de evento de un día de duración en el que un grupo de programadores mejoran sus capacidades en el diseño y desarrollo de software realizando diversas prácticas, sin la presión de tener que entregar “cosas funcionando”.

Consiste en la práctica repetida de una misma kata, normalmente el Juego de la Vida (Game of Life) de J. H. Conway, con diferentes parejas y restricciones en cada iteración. Tras cada una de las iteraciones, se realiza una breve retrospectiva en la que todos comparten lo aprendido durante esa sesión.

Este formato ha demostrado ser un mecanismo eficaz para mejorar las capacidades de diseño y desarrollo de software de sus participantes.

Si quieres entender mejor la filosofía que hay detrás de un coderetreat, en el siguiente vídeo Corey Haines, uno de los creadores e impulsores de este tipo de eventos, introduce una sesión de coderetreat en Cleveland:

¿Dónde?

Cuartel general de OSOCO en Móstoles (Madrid). Puedes encontrar los datos de contacto en nuestra página.

¿Cuándo?

El GDCR 2015 se celebra el sábado 14 de noviembre a lo largo de toda la jornada. Desde las 9:00 hasta las 18:00, con tiempos para tomar café y salir a comer algo para retomar energías.

¿Qué tengo que llevar?

El día del evento sólo necesitas traer un portátil con tu entorno de programación preferido configurado y tu cerebro. El WiFi, bebida y comida corren a cargo de OSOCO.

Este evento es independiente de un lenguaje de programación en particular, de hecho, algo interesante es poder practicar la kata usando un lenguaje de programación nuevo para ti, formando pareja con un desarrollador que te pueda introducir en ese nuevo entorno.

Lightning talk: Spring’s annotations: Proxy

A diario desarrollando nos encontramos con problemas bastante comunes, que en primer lugar nos pueden desquiciar un poco pero que indagando un poco más nos resultan interesantes.

¿Por qué este método no es transaccional si está anotado como tal? ¿Por qué no se está cacheando si he puesto la anotación correctamente? Spring, concretamente el proxy que crea, tiene la respuesta.

 


 

 

Módulo de Puppet para Grails

Nota: esta entrada también la publiqué en inglés en mi blog.

Sobre el módule

El siguiente módulo de Puppet del que quería hablar es el módulo de Puppet para Grails. Igual que los anteriores módulos para Puppet, está publicado en la cuenta Github de OSOCO, y es uno de los más sencillos, pero también de los que más hemos usado en nuestra infraestructura, por razones obvias 😀 .

Este módulo permite instalar múltiples versiones de Grails en un nodo de Puppet. El uso no podría ser más simple, como puedes ver en el siguiente código de ejemplo:

class jenkins {
    ...
    grails { "grails-1.3.5":
        version => '1.3.5',
        destination => '/opt'
    }

    grails { "grails-1.3.9":
        version => '1.3.9',
        destination => '/opt'
    }

    grails { "grails-2.0.0":
        version => '2.0.0',
        destination => '/opt'
    }

    grails { "grails-2.0.1":
        version => '2.0.1',
        destination => '/opt'
    }
    ...
}

En este ejemplo, una clase jenkins declara múltiples instalaciones de Grails (para poder lanzar las baterías de tests de cada proyecto con la versión apropiada de Grails), para lo que añade varios recursos de tipo grails parametrizados por la versión y el directorio destino. El módulo de Grails resuelve la URL de descarga (la cual, desde la versión 1.3.6 ha de apuntar a Amazon S3, mientras que anteriormente se resolvía a una URL propia) y descargará y desempaquetará el ZIP sólo en caso necesario (es decir, si la versión dada no existe ya en el directorio de destino especificado).

Dependencias

El módulo depende del módulo de Puppet para WGet de OSOCO, por lo que debes tener una copia de ambos módulos en tu directorio de módulos. O, si usas puppet-librarian, puedes símplemente añadir lo siguiente a tu fichero Puppetfile:

mod "wget",
   :git => "git://github.com/osoco/puppet-wget.git"
mod "grails",
   :git => "git://github.com/osoco/puppet-grails.git"

Android GCM Sender

Esta entrada es una traducción al español de la que publiqué en mi blog, que está en inglés.

Motivación

Imagina que estás desarrollando una aplicación Android que necesita recibir notificaciones push. La aplicación encargada de enviar esos mensajes a GCM está siendo desarrollado por otro equipo, y no sólo no está terminada todavía, sino que además el equipo está en otro departamento de la empresa. No, de hecho está en otra empresa :-) . Quieres estar seguro de que tu aplicación cumple las especificaciones (es decir, reacciona de cierta manera cuando recibe cierta notificación), pero no quieres depender de ese otro equipo (y por supuesto, tampoco quieres desarrollar una aplicación que envíe notificaciones 😀 ):

Solución

Esa necesidad de una aplicación de envío de mensajes configurables a GCM es el segundo artefacto que Adrian Santalla y yo desarrollamos en los dos primeros hacker fridays de OSOCO, al que hemos llamado Android GCM Sender (siendo el primero el plugin de Android GCM para Grails).

Suscribe tus dispositivos usando la URL proporcionada y añade tu identificador de proyecto

Empezó siendo la aplicación de prueba para dicho plugin, pero nos dimos cuenta que sería fácil evolucionarla hasta el punto de ser útil para cualquiera: sólo necesitábamos parametrizar el identificador de proyecto (que puedes obtener creando un proyecto tipo Google API) y crear una acción que permitiese la suscripción de dispositivos Android. Puedes usar Android GCM Sender en la siguiente URL: http://grails-android-gcm-sender.herokuapp.com/.

Uso

El primer paso sería suscribir tus identificadores de dispositivo Android usando la URL http://grails-android-gcm-sender.herokuapp.com/device/subscribe?deviceToken=yourDeviceToken&projectId=yourProjectId. No olvides sustituir substitute yourDeviceToken y yourProjectId con tu identificador de proyecto e identificador de dispositivo Android, y recuerda que esta URL está pensaba para ser invocada con algún tipo de HTTPBuilder dentro de una aplicación Android – opr eso no produce ninguna salida :-). Pero si quieres usarla directamente en tu navegador, también funcionará 😀 .

Compón tu mensaje, envíalo a los dispositivos seleccionados y observa el resultado del envío

Después de eso, escribe tu identificador de proyecto en la página de inicio de Android GCM Sender y dale al botón de actulizar. Verás un formulario que te permite enviar mensajes (simples o compuestos) a uno o varios dispositivos Android. Ten en cuenta que siempre tendrás disponibles dos dispositivos falsos para el caso en que quieras hacer algún tipo de prueba con ellos. Después de rellenar el formulario. puedes darle al botón Send y verás el resultado del envío. Y si tus identificadores de dispositivo y proyecto son válidos, deberías recibir una notificación push con el mensaje que compusiste en la vista anterior 😀 .

Ten en cuenta que para mantener los datos en un volumen pequeño, tus identificadores de dispositivo y proyecto sólo se guardan durante 24 horas – piensa que en realidad es una feature y no un bug 😀 ya que así no te tienes que preocupar de des-suscribir tus dispositivos o similar. De hecho, la base de datos está en memoria, por lo que nosotros no tenemos acceso a ella.

Código fuente

Android GCM sender corre en Heroku, pero su código fuente está disponible en la cuenta Github de OSOCO, por lo que puedes alojarlo tú mismo si quieres. La aplicación ha sido desarrollada usando Grails, y a la UI se le ha añadido un poco de picante con Ajaxify.