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.

 


 

 

Lightning talk: Proactive monitoring with Monit

Tras el verano, en OSOCO estamos retomando la vieja y buena costumbre de organizar breves charlas internas, o no tan breves, con el fin de compartir entre todos nuestros equipos nuevas herramientas, técnicas y en general, cualquier conocimiento de interés.

En esta ocasión, hemos tratado la monitorización de sistemas de una forma sencilla, eficaz y económica usando Monit. Una herramienta open source muy versátil, que no sólo facilita la labor de monitorización, sino que además, permite corregir proactivamente situaciones de error.


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.

Módulo de Puppet para MySQL

Nota: esta entrada también la publiqué en inglés en mi blog. If you are an english reader, you may want to check it.

Continuando con los móldulos de Puppet que hemos publicado en la cuenta de GitHub de OSOCO, hoy hablaré del módulo de Puppet para MySQL, que me ha parecido uno de los más útiles cuando hemos creado nuestras infraestructuras :-) .

Hay cantidad de módulos MySQL ya publicados, pero los que probé antes de crear el nuestro eran muy potentes, y por lo tanto complejos y con muchas dependencias. En este caso, quería intentar conseguir justo lo contrario: un módulo sencillo que símplemente funcionase a la hora de hacer las tareas más comunes relacionadas con MySQL: instalarlo, establecer la password de root, crear bases de datos y permitir el acceso de usuarios a las mismas.

Para usar el módulo símplemente debes añadirlo a tus módulos (en nuestro caso usamos Puppet Librarian para la gestión de dependencias) y declarar los recursos que necesitas. El siguiente ejemplo muestra nuestra configuración de MySQL para el nodo que es responsable de hospedar a Jenkins:

class ci_mysql {

    mysql::database { 'someProjectTestDB': }
    mysql::database { 'anotherProjectTestDB': }

    $test_user_name = 'test'
    $test_user_pwd = 'test'

    mysql::user { 'someProjectTestDB-test-user':
        user => "$test_user_name",
        password => "$test_user_pwd",
        database => 'someProjectTestDB',
        host => '%'
    }

    mysql::user { 'anotherProjectTestDB-test-user':
        user => "$test_user_name",
        password => "$test_user_pwd",
        database => 'anotherProjectTestDB',
        host => '%'
    }

    mysql::user { 'anotherProjectTestDB-readonly-user':
        user => 'readonlyuser',
        password => 'readonlyuser',
        database => 'anotherProjectTestDB',
        privileges => 'SELECT'
    }
}

Sólo con eso se instalará el servidor de MySQL y será lanzado como un servicio. Además se crearán dos bases de datos (someProjectTestDB y anotherProjectTestDB) con un usuario con todos los permisos de acceso (de nombre test). Finalmente, el usuario readonlyuser tendrá acceso a la base de datos anotherProjectTestDB, pero sólo podrá hacer consultas de tipo select. Directo y sencillo :) .

La clase también puede ser configurada con los siguientes parámetros opcionales:

class ci_mysql {
   class { "mysql::install":
      version => "5.1.61-0+squeeze1",
      root_pwd => "myFancyRootPassword",
      data_dir => "/mnt/mysql/datadir",
   }   
   ...
}

De esa manera puedes especificar la versión de MySQL, la contraseña del root, y el directorio de datos que usará MySQL para guardar las bases de datos. Por último, añadir que este módulo lo hemos probado tanto en Debian como en Gentoo (por lo que debería funcionar bien en Ubuntu).

Grails Android GCM Plugin

Nota: esta entrada también está publicada en mi blog en inglés. If you are an english reader, you might want to read that version.

Como resultado de los dos primeros hacker fridays de OSOCO, Adrian Santalla y yo publicamos el plugin de Grails para Android GCM (entre otras cosas 😀 ), cuyo código fuente está disponible en Github.

Este pequeño plugin proporciona a tu aplicación Grails acceso a Android GCM (el servicio que Googe usa para las notificaciones push de Android) a través de un servicio que es injectado en los artefactos de tu aplicación.

El plugin está publicado en el repositorio oficial de plugins de Grails, así que instalarlo es tan fácil como invocar la orden install-plugin, tras lo cual cualquier servicio, controlador, etc, de tu aplicación podrá usar el servcio androidGCMService. El siguiente ejemplo ilustra el caso de uso más básico:

$ grails create-app AwesomeApp 
$ cd AwesomeApp
$ grails install-plugin android-gcm
$ grails create-controller Cool
$ cat > grails-app/controllers/awesomeapp/CoolController.groovy << EOF
package awesomeapp

class CoolController {

    def androidGcmService

    def index() {  
        render androidGcmService.sendMessage(
            [ 
                aMessageKey : 'The message value for the key aMessageKey', 
                anotherMessageKey : 'The message value for the key anotherMessageKey' 
            ],
            ['anAndroidDeviceToken', 'anotherAndroidDeviceToken'],
            'youShallCollapseThisMessage', 'yourGCMAPIKeyProvidedByGoogle'      
        )          
    }
}
EOF
$ grails run-app
$ $ wget -O - http://localhost:8080/AwesomeApp/cool/index 2> /dev/null
MulticastResult(multicast_id=8596196938900195177,total=2,success=0,failure=2,canonical_ids=0,results: [[ errorCode=InvalidRegistration ], [ errorCode=InvalidRegistration ]])

Como se ve, el controlador intenta enviar un mensaje (el cual, por su parte, está compuesto por dos mensajes, cada uno con su clave y valor) a dos dispositivos Android, marcando el mensaje como de tipo collapse, y pasando la clave de acceso al API de GCM porporcionada por Google. Cuando el resultado es renderizado, se muestra un objeto de clase MulticastResult (dado que hemos intentado enviar el mensaje a múltiples dispositivos) con el resultado del envío del mensaje (que en este caso es un error de tipo InvalidRegistration para ambos dispositivos, ya que estamos inventándonos su identificador de registro 😀 ). Ten en cuenta que si quieres probar este ejemplo tendrás que sustituir yourGCMAPIKeyProvidedByGoogle con un identificador de API válido, si no lo haces el API de Android al que el plugin invoca fallará con una bonita excepción de tipo null pointer :-( .

Puedes ver una lista completa de los métodos proporcionados por el servido y de las opciones de configuración disponibles en el README del proyecto en Github.

Módulos de Puppet para Git y Subversión

Nota: esta entrada también está publicada en inglés en mi blog. If you are an english reader you may want to check out the english version :-) .

Puppet

Durante este último año hemos estado usando puppet, una herramienta de configuración que permite automatizar el despligue y configuración de software usando un DSL (en vez de, por ejemplo, scripts caseros de dudosa portabilidad). Durante este tiempo hemos escribo algunos módulos agnósticos de OSOCO, que hemos publicado en nuestra cuenta de Github, así que he pensado en hacerles algo de publicidad :-D. Empezaré con dos de los más sencillos, puppet-git y puppet-svn, que te permiten hacer checkouts y actualizar repositorios de estos dos populares SCM’s

Puppet Git

Puedes encontrar el código fuente de este módulo en su repositorio de Github. Permite hacer un checkout de un repositorio o mantener actualizada una copia ya existente. Un caso de uso de ejemplo podría ser un servidor que necesita instalar una serie de herramientas cuando arranca, y se puede ver en otro módulo Puppet que tenemos publicado, el de aws-tools, cuyo código relevante puedes ver a continuación:

class my_awesome_puppet_class {
    include git
    $path = "/my/existing/aws-tools/path"
    git::clone { "aws-tools-clone":
        url => "https://github.com/osoco/aws-tools.git",
        path => "$path/aws-tools",
        username => "",
        password => "",
    }
    git::pull { "aws-tools-pull":
        path => "$path/aws-tools",
    }
}

Como se puede ver, definimos un par de recursos de tipo clone y pull, los cuales son lo suficientemente inteligentes para ejecutar su operación asociada sólo cuando tiene sentido: la operación de clone sólo se ejecutará cuando el directorio de destino no exista, mientras que la operación pull sólo lo hará cuando si exista :-) . Esto mantendrá la copia de las maravillosas aws-tools 😀 disponible y actualizada.

Puppet Subversion

Prácticamente lo mismo, pero usando el viejo y bueno Subversion (para aquellos que os lo estéis preguntando – si, todavía puedes usar subversion y ser guay 😀 ). Nuevamente, el código fuente está disponible en Github y proporciona básicamente las mismas opearaciones. En este caso, el ejemplo muestra un servidor web que al arrancar ha de obtener una copia de la web que sirve, así como mantenerla siempre actualizada:

class awesome_website_configuration {
    include svn
    $document_root = "/var/www/awesome_website"
    svn::checkout { "awesome-website-checkout":
        username => "my-readonly-svn-user",
        password => "someSecretPassword", 
        url => "https://svn.somecompany.org/svn/awesome_web/trunk",
        path => $document_root,
    }
    svn::update { "awesome-website-update":
        username => "my-readonly-svn-user",
        password => "someSecretPassword", 
        path => $document_root,
    }
}

Y eso es todo. Probablemente no son los módulos más extraordinarios que encontrarás, pero son útiles :-) .

Hacker Fridays o catalizadores de la innovación

Con el objetivo de mejorar nuestra capacidad de innovación acabamos de poner en marcha (el viernes pasado) una iniciativa que hemos bautizado como Hacker Fridays.

El Glider. Emblema de la cultura hacker.

Además, hemos pensado en compartir toda la información posible sobre esta iniciativa, que en realidad no deja de ser un experimento, ya que puede resultar de utilidad para otros que se estén planteando lanzar iniciativas similares y necesiten referencias y para quienes estén pensando en OSOCO como proyecto de trabajo y quieran conocer más sobre nuestra visión y las actividades en las que nos embarcamos.

En esta primera entrada describiré las motivaciones de la iniciativa y cómo hemos pensado articularla inicialmente, pero periódicamente nuestro insigne compañero Arturo Herrero publicará entradas sobre el progreso de la iniciativa, incluyendo los proyectos en los que trabajemos, los problemas encontrados, lo que funciona y lo que no tanto, etc. Permaneced atentos a las entradas publicadas con el tag hacker-fridays.

Sobre la innovación en OSOCO

Un objetivo fundacional en OSOCO es mantenernos en una relativa vanguardia tecnológica respecto al conocimiento y experiencia que puedan acumular los equipos de desarrollo de nuestros potenciales clientes e idealmente, también de nuestros potenciales competidores. Pensamos, y el tiempo así nos lo ha demostrado, que de este modo estaremos en mucho mejor disposición para ofrecer servicios profesionales atractivos para nuestros clientes.

Por ejemplo, cuando el statu quo en la mayoría de nuestros clientes consistía (en el mejor de los casos) en Java 1.4, Struts 1.x, Ant e iBatis, nosotros ofrecíamos conocimientos y experiencia en Java 5, Struts 2, Maven y Hibernate. Del mismo modo, ahora que observamos un interés creciente en algunos clientes por la computación en nube, nuestro equipo está en disposición, no sólo de ofrecer experiencia real en computación en nube, sino también en gestión de la configuración y otras prácticas DevOps.

Hasta el momento nuestra estrategia de innovación se ha basado en acciones muy sencillas, tanto que creo que nunca las hemos puesto por escrito. Quiero pensar que están implícitas en la cultura empresarial que hemos creado en OSOCO. Si tuviera que describir nuestra estrategia de innovación la sintetizaría en los siguientes principios:

  1. Cada proyecto supone un reto doble: hacia el exterior, es decir, con nuestro cliente, y hacia el interior, con nuestro propio equipo. Si bien lo principal es satisfacer (y a ser posible superar) las expectativas del cliente en sus diferentes dimensiones: coste, plazo y funcionalidad. Un proyecto sólo se considerará realmente exitoso cuando además aporta un valor interno a OSOCO en forma de  contribuciones que mejoren el conocimiento-experiencia común que atesoramos como empresa.
  2. Cada nuevo proyecto, por trivial que pudiera parecer, se tomará como una oportunidad para generar valor. Este valor puede tomar distintas formas: evaluar una nueva tecnología, incorporar una herramienta nueva a la caja de herramientas habitual, mejorar alguno de los procesos existentes o cualquier otra.
  3. Nunca se antepone la innovación al éxito externo del proyecto; es decir, desde el punto de vista del cliente. En consecuencia, las innovaciones propuestas siempre deben mejorar, o al menos no hacer peligrar, el resultado del proyecto percibido por el cliente.

Esta estrategia nos ha permitido innovar los últimos años incorporando temas como Groovy, Grails, Activiti, Spock, Concordion, Amazon Web Services, Google App Engine, Puppet, etc. a nuestro bagaje. Sin embargo, el ritmo de innovación no es demasiado alto, ya que por la aplicación del Principio 3, siempre primamos el éxito del proyecto sobre el grado de innovación alcanzado.

Hacker Fridays

¿En qué consisten los Hacker Fridays?

En dedicar parte de nuestro tiempo en OSOCO a trabajar en pequeños proyectos propuestos, aprobados y también supervisados por el propio equipo de desarrollo.

¿Cuánto tiempo dedicaremos?

Dedicaremos dos viernes al mes a esta iniciativa, lo que supone un 7,5% del tiempo de trabajo en OSOCO. Hemos pensado que puede ser más productivo que estos viernes sean consecutivos, con lo que, dedicaremos el último y primer viernes de cada mes.

¿Cuánto durará la iniciativa?

Estamos convencidos de que lejos de ser un experimento extravagante, esta iniciativa mejorará OSOCO de múltiples maneras. Sin embargo, conviene verificar que realmente estamos en lo cierto, así que hemos establecido un periodo de prueba de 6 meses de duración.

Teniendo en cuenta la granularidad ideal de los proyectos en los que estamos pensando, 6 meses será tiempo más que suficiente para comprobar cómo funciona la iniciativa y si obtenemos los efectos beneficiosos que esperamos.

¿Por qué los viernes?

En OSOCO tenemos la política de que los viernes todo el mundo trabaje desde nuestras oficinas, incluídos aquellos que temporalmente trabajan en un proyecto que se desarrolla principalmente en la oficina de algún cliente. Así pues, el viernes es el día perfecto para favorecer la formación de equipos y el trabajo colaborativo.

Uno de los objetivos de esta iniciativa es precisamente crear oportunidades de colaboración entre desarrolladores que no hayan tenido la oportunidad de hacerlo y mejorar la interrelación entre todo el equipo en general.

Por otro lado, como los viernes sólo trabajamos por la mañana, siempre cabe la posibilidad de que si te “enganchas” con lo que estás haciendo te puedas quedar por la tarde todo el tiempo que quieras. Dispondremos de un presupuesto para comida y bebida para quienes decidan alargar el hacking el viernes por la tarde.

¿Qué esperamos conseguir?

Los objetivos de la iniciativa son diversos:

Mejorar nuestra capacidad de innovación

Esperamos mejorar el ritmo al que evaluamos e incorporamos novedades a nuestro repertorio de tecnologías en OSOCO.

Mejorar nuestros proyectos cotidianos

¿Cuántas veces nos quedamos con ganas de extraer una funcionalidad como un plugin de Grails o JQuery, o hemos pensado en automatizar una tarea, pero las exigencias del proyecto no nos lo permiten en ese momento? Este es el tipo de proyectos que esperamos abordar con esta iniciativa.

Los resultados serán relativamente modestos, pero al presentarse siempre a todo el equipo, se irán incorporando a nuestra caja de herramientas común y podremos aprovecharlos en futuros proyectos para ser más productivos.

Conseguir un entorno estimulante para nuestros cerebros de obra [1]

El equipo de OSOCO está integrado por programadores apasionados por su trabajo y por lo que hacen. Este tipo de programador, a diferencia del que entiende la profesión como “un trabajo más”, necesita encontrarse en un entorno que le plantee nuevos desafíos constantemente.

Si alguien empieza a percibir su trabajo como monótono y repetitivo, los hacker fridays pueden ser la oportunidad de resolver los problemas recurrentes con los que nos enfrentamos en los proyectos desde un punto de vista original y de compartir la solución con el resto del equipo.

No se trata de que los proyectos cotidianos sean aburridos y los viernes sirvan de vía de escape, sino de encontrar mejores formas de trabajar en nuestro día a día con los resultados que vayamos obteniendo de esta iniciativa.

Contribuir a la comunidad de software libre

En OSOCO siempre hemos basado nuestros proyectos en software libre: lenguajes de programación, marcos de trabajo, bases de datos, librerías de desarrollo, editores, sistemas operativos, etc.

Con los resultados que obtengamos en esta iniciativa contribuiremos, aunque sea modestamente, a este movimiento.

Fortalecer el equipo

Esperamos que se establezcan equipos de trabajo entre desarrolladores que no trabajan juntos habitualmente. Trabajar para obtener un resultado útil en un ambiente divertido y relajado puede ayudar a reforzar los vínculos de amistad y compañerismo entre nosotros.

Aprendizaje cruzado

Trabajar con otras personas y estar expuesto a sus diferentes puntos de vista siempre es enriquecedor y se puede aprender mucho de cada uno de los buenos profesionales con que contamos en OSOCO. Además, aunque no se participe directamente en un proyecto, puesto que los resultados se expondrán al resto del equipo, todos nos beneficiaremos de las lecciones aprendidas.

¿Cuál es la visión de la iniciativa? ¿Qué es y qué no es?

Para que la iniciativa sirva para alcanzar los objetivos que nos hemos propuesto y que acabamos de describir, creemos que es importante centrarse en pequeños desarrollos, especialmente al principio, que nos permitan obtener resultados tangibles sin esperar semanas para ello. De esta manera ganaremos en confianza y podremos ir pensando en objetivos un poco más ambiciosos con el tiempo.

Idealmente, los primeros proyectos deberían poder finalizarse en 1 o 2 viernes como mucho. El tipo de desarrollos en los que estamos pensando son aquellos que podamos empezar a utilizar en nuestros proyectos del día a día casi de manera inmediata: plugins de Grails, plugins de JQuery, automatización de tareas (configuración, despliegues, etc.), contribuciones a proyectos de software libre que utilizamos (Groovy, Grails, Spock, CodeNarc, etc.) en forma de bugs resueltos, mejoras en la documentación, etc.

La visión de la iniciativa es obtener contribuciones útiles tanto para OSOCO como para la comunidad de software libre de manera frecuente.

Por tanto, no se trata de hacer un laboratorio de startup, ni de proponer ideas de negocio, ni de aprovechar la oportunidad para desarrollar los proyectos personales. Se trata simplemente de abordar pequeños desarrollos con una finalidad muy concreta: facilitarnos el día a día en OSOCO y contribuirlos a la comunidad.

Tampoco está pensado para que se use de excusa para aprender tal o cual nuevo lenguaje super cool con el que me apetece jugar. Para esto están los fines de semana.

Resumiendo, no se trata de una iniciativa como la del 20% de Google, sino más bien como la de los Hackergarten.

¿Cómo lo organizamos? ¿Qué reglas seguiremos?

Nuestra intención es definir el menor número posible de reglas y ver qué tal somos capaces de organizarnos así y cuáles son los resultados que conseguimos.

Dispondremos de un tablón de proyectos compartido, en el que cualquiera podrá añadir sus propuestas de proyectos. No se aceptarán ideas que no se hayan madurado lo suficiente. Es decir, las ideas tienen que ser concretas y habrá que especificar unos datos mínimos como: los resultados que se espera obtener, el equipo deseable para su realización, los plazos estimados, por qué es de utilidad para nuestros proyectos en OSOCO, etc.

El objetivo lo defines tú, pero tienes que ser capaz de describirlo. Al final tiene que poderse establecer claramente si un proyecto ha sido exitoso o no. Con esto no queremos decir que no sea aceptable que un proyecto fracase. El objetivo es aprender y para eso hay que arriesgarse a fracasar, siendo capaces de aprender de los errores. Igualmente valioso puede ser que un equipo nos cuente lo que les ha funcionado, como lo que no les ha funcionado ya que es preferible darse cuenta en estos pequeños desarrollos que fracasar estrepitosamente en un proyecto real.

No existen restricciones respecto a las tecnologías a emplear (siempre que no se convierta en mero onanismo tecnológico), excepto que se debe usar software libre y el resultado también deberá ser liberado con una licencia de software libre.

¿Cómo se eligen los proyectos?

Como ya se ha explicado, uno de los objetivos de esta idea es crear equipo, para ello hemos pensado que no se pueda trabajar individualmente en los proyectos y que al menos deberán trabajar dos personas en cada proyecto.

Por lo tanto, un primer paso para elegir un proyecto es conseguir crear el equipo de trabajo. Puedes exponer tu idea en el tablón de proyectos y aprovechar alguna ocasión, como durante el desayuno o la comida, para hacer campaña a favor de tu proyecto, con el fin de poder formar el equipo necesario. Si expones una idea y no logras encontrar compañero de aventuras, tendrás que descartarla o intentar defenderla mejor.

¿Cómo haremos el seguimiento de los proyectos?

Para evitar que un proyecto se pueda bloquear y consumir demasiado tiempo, de vez en cuando el equipo deberá resumir el estado del proyecto al resto de desarrolladores. De esta manera, si los demás piensan que se está enfocándolo mal o que se ha llegado a un callejón sin salida, podrán hacérselo ver.

Al finalizar el proyecto se realizará una breve presentación de los resultados al resto del equipo, haciéndose hincapié en aquellos resultados obtenidos que sean susceptibles de utilizarse en los proyectos de OSOCO y en las lecciones aprendidas, ya sean positivas o negativas.

¿Cuánto costará?

Obviamente, este experimento no es gratis. Estimamos que estos primeros seis meses tendrán un coste de unos 30K euros, sin valorar otro tipo de efectos, como la repercusión que tendrá en los plazos de entrega del resto de proyectos.

Referencias

[1] Gestionando Cerebros de Obra. Beatriz Muñoz-Seca: http://www.youtube.com/watch?v=K5ttuDbNC98

Polyglot Programming

Polyglot Programming

How many programming languages do you know?

Most programmers know several languages. We, as web developers, work on a daily basis with Groovy, SQL, Bash Scripting, HTML, CSS, JavaScript…

Learning different languages allows us to solve problems with the most appropriate language and to explore new paths of thinking about computational problems.

Neal Ford coined the term polyglot programming, to refer about this topic.

I think it’s important in this day and age of polyglot programming to understand a variety of different languages, as they are the design tools we use to craft software. Just like regular engineers must understand the physical properties of different materials, we should understand the capabilities, strengths, and weaknesses of different languages. And when to apply them.

Neal Ford

Polyglot JVM and Polyglot Grails

Java has long been known simply as a programming language. Today, when thinking in Java we refer also a robust and mature development platform. Currently, the Java Virtual Machine (JVM) supports over 200 different programming languages.

These days we have been exploring different languages on the JVM: Java, Groovy, Scala, Clojure, JRuby… and how to incorporate them into a Grails project. We shared our experiences with others developers at Spring I/O 2012 and Codemotion 2012.

Hope you enjoy the slides.