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.

Create your own Groovy type conversion

Type conversion the standard way

Type conversion or casting is a programming language method for changing an object’s data type into another.

I’m sure you are familiar with this code that converts a String to an Integer.

def number = (Integer)'1'
def number = '1'.toInteger()
def number = '1' as Integer

If I want to convert the type of my own objects, I need to create a method to achieve this goal. I copy object properties to another object in a generic way; if a property exists on target object, I copy it from the source object.

class User {
    String name
    String city
    Integer age

    def toAdminUser() {
        def adminUser = new AdminUser()
        copyProperties(this, adminUser)
        return adminUser
    }

    def copyProperties(source, target) {
        source.properties.each { key, value ->
            if (target.hasProperty(key) && !(key in ['class', 'metaClass'])) {
                target[key] = value
            }
        }
    }
}

class AdminUser {
    String name
    String city
    Integer age
}

Now I can do something like this:

adminUser = user.toAdminUser() 

Type conversion the fancy way

Great, but I want to use this fancy way to coerce one type to another:

adminUser = user as AdminUser 

Simple, Groovy supports operator overloading and creating your own type conversion is really easy: we can override the asType() method.

class User {
    String name
    String city
    Integer age

    Object asType(Class clazz) {
        if (clazz == AdminUser) {
            def adminUser = new AdminUser()
            copyProperties(this, adminUser)
            return adminUser
        }
        else {
            super.asType(clazz)
        }
    }

    def copyProperties(source, target) {
        source.properties.each { key, value ->
            if (target.hasProperty(key) && !(key in ['class', 'metaClass'])) {
                target[key] = value
            }
        }
    }
}

Asynchronous tests with GPars (Osoco test gallery, part 4)

If you wrote multithreaded code in Groovy/Grails, I’m sure you stumbled upon the GPars library. It simplifies parallel processing – sometimes it’s as easy as wrapping a code fragment with a GPars closure, changing the iteration method (in our example from each to eachParallel) and passing the closure to a GPars pool. The library implementation handles the executor pool creation and adds new methods to collections.

Whenever I deliberately add multithreading, I always separate responsibilities (processing logic and concurrency handling). I wrap the single-threaded class with a new one, handing the parallel execution (creating a pool, managing threads, handling cancellation, etc.):

class MultithreadedProcessorService {
    ProcessorService processorService
    def threadPoolSize = ConfigurationHolder.config.threadPool.size

    void processMultithreaded(batches) {
        GParsPool.withPool(threadPoolSize) {
            batches.eachParallel { batch ->
                processorService.process(batch)
            }
        }
    }
}

class ProcessorService {
    void process(batch) {
        // some processing
    }
}

To test the multithreaded class you can you use Spock interactions. As opposed to Groovy and Grails mocks, they are thread-safe and you won’t get any weird and unstable results:

class MultithreadedProcessorServiceSpec extends UnitSpec {
    private MultithreadedProcessorService multithreadedProcessorService
    // Using Spock mocks because they are thread-safe
    private ProcessorService processorService = Mock(ProcessorService)

    def setup() {
        mockConfig('threadPool.size=2')
        multithreadedProcessorService = new MultithreadedProcessorService(
            processorService: processorService
        )
    }

    def 'processes batches using multiple threads'() {
        given:
        def batches = [[0, 1], [2, 3, 4], [5]]
        def processedBatches = markedAsNotProcessed(batches)

        when:
        multithreadedProcessorService.processMultithreaded(batches)

        then:
        batches.size() * processorService.process({ batch ->
            processedBatches[batch] = true
            batch in batches
        })
        assertAllProcessed(processedBatches)

    }

    private markedAsNotProcessed(batches) {
        batches.inject([:]) { processed, batch ->
            processed[batch] = false
            processed
        }
    }

    private void assertAllProcessed(batches) {
        assert batches*.value == [true] * batches.size()
    }
}

This post series present the best of Osoco tests – tests that were tricky or we are just proud of. You can find a runnable source code for this test and more in the Grails Test Gallery project shared on GitHub.

Grails base persistence specification (Osoco test gallery, part 3)

In our projects we include at least one integration test per domain class. We want to assure us that the GORM mapping is correct and the class is persistable in the target database. The test plan is simple:

  • create a valid persistable sample of the domain object
  • save it
  • clear Hibernate first level cache (i.e. flush and clear current session)
  • retrieve the object once again and compare it with the previously saved object. They must be equal as by equals() but be different object references

We put the steps above in a base abstract specification. In concrete specifications we implement merely the factory method spawning a persistable object instance.

abstract class PersistenceSpec extends IntegrationSpec {
    SessionFactory sessionFactory

    protected abstract createPersistableDomainObject()

    def 'persistable domain object should be able to be saved and retrieved'() {
        given:
        def persistableDomainObject = createPersistableDomainObject()

        when:
        def savedDomainObject = persistableDomainObject.save()

        then:
        savedDomainObject.id != null

        when:
        clearFirstLevelCache()

        def retrievedDomainObject = persistableDomainObject.class.get(savedDomainObject.id)

        then:
        savedDomainObject == retrievedDomainObject
        !savedDomainObject.is(retrievedDomainObject)
    }

    private clearFirstLevelCache() {
        sessionFactory.currentSession.flush()
        sessionFactory.currentSession.clear()
    }
}

This post series present the best of Osoco tests – tests that were tricky or we are just proud of. You can find a runnable source code for this test and more in the Grails Test Gallery project shared on GitHub.

Grails equals and hashCode testing (Osoco test gallery, part 2)

If you work with GORM and your objects are held in collections, you should implement equals and hashCode methods. As everything, they should be thouroughly tested if they obey equals-hashCode contract. At Osoco we created a equals-hashcode-test Grails plugin that provides a base Spock specification for that. In your equals and hashCode tests you simply have to extend the EqualsHashCodeSpec and provide at least two methods:

  • a factory method createDomainObjectToCompare that will create a fresh object for the comparison
  • a map of modified properties included in equals and hashCode
  • optionally a map of modified properties ignored in both methods

Additionally in case of inheritance, we check whether the equals method complies with the symmetry rule. We do it in an extra feature method added to the spec:

def 'equals relation must be symmetric with inheritance'() {
    given:
    def content = new Content()

    and:
    def book = new Book()

    expect:
    (content == book) == (book == content)
}

You may say, in Grails 2.0 and Groovy 1.8 there are @Equals and @HashCode AST transformations and you don’t need to write tests of them. I agree to some point. I think you can trust Groovy developers and you don’t have to test the methods for reflexivity, symmetry, transivity, consistency, and ‘non-nullity’. Anyway, you have to test the annotation configuration if it includes the properties that actually account for the logical equality between objects.

In the future releases of the plugin we will surely simplify the base specification and remove some checks but we will surely continue testing both methods (with our plugin it’s dirt-cheap!)


This post series present the best of Osoco tests – tests that were tricky or we are just proud of. You can find a runnable source code for this test and more in the Grails Test Gallery project shared on GitHub.

Magic in Software Development

My opinion about magic in software development coincides with these great posts:

Do You Believe In Magic?

Magic in software development

I extract some fragments of them that I would like to highlight.

Bad word: Magic

I often find that people talk about magic when referring to programming languages and frameworks.

The concept that some particular language features are more magical than others is insane. None of it involves fairy dust or anything particularly complicated; it’s all just programming.

There is absolutely no logic in calling language features magical. It implies that certain programming techniques are inherently fantastic and strange. That’s only the case if you don’t understand the language.

The correct response is not calling arbitrary features magic. The correct response is to keep learning how to write code and overcome your ignorance.

Magic rocks!!

Ultimately, you can continue using magic, but what’s magic? I’d define it as anything below your current level of abstraction that you don’t understand.

Any sufficiently advanced technology is indistinguishable from magic.

Arthur C. Clarke

Magic is a good idea, we don’t understand exactly how quantum physics works but we accept that it does and make good use of it.

Now, if you don’t understand some feature of your favorite framework or how it works behind the scenes, don’t worry. Do not be intimidated, just learn and enjoy without worrying about every detail.

Functional Programming with Groovy

The diversity of languages and programming paradigms allow us to solve existing problems by thinking solutions from very different approaches.

But why a Groovy developer should learn functional programming?

As I learned about functional programming, I found good ideas but I also found that it brought new clarity to my thinking about the design of class and methods. It also allowed me to write more concise code and how to make it better for reuse.

A few weeks ago, I spoke about functional programming with Groovy at Greach 2011. I presented basic concepts of functional programming paradigm and then focus on how to apply them to improve the code that we write with Groovy.