Se ve a la legua

Cuando algo está mal hecho se ve a la legua, en todos los ámbitos, y especialmente en el desarrollo de software.

Gran parte de nuestro trabajo en Clinker ha sido de integración, lo cual nos ha llevado a adentrarnos muy a fondo (os lo aseguro, muy a fondo) en todas y cada una de las herramientas que lo componen. Hemos desarrollado plugins para (casi) todas, y en un entorno Open Source, desarrollar un plugin te permite empaparte de gran parte del código fuente de la herramienta. Sin embargo, mucho antes de mirar el código fuente ya puedes suponer lo que te vas a encontrar, hay una serie de indicadores que no fallan:

• ¿Se puede compilar (o empaquetar, si no se compila) facilmente? ¿O es necesario desplazarse a la casa de desarrollador, con su familia, para ello?
• ¿La organización de los fuentes es comprensible? ¿O hay directorios esparcidos como en un mercadillo de domingo?
• ¿El repositorio (SCM) está limpito, organizado y sigue un criterio de publicación de versiones? ¿O se usa como alternativa a Dropbox?

Sólo con estas tres preguntas (a la legua) podemos suponer lo que habrá dentro.

Pero, por supuesto, cuando algo está bien hecho también se ve a la legua. Por suerte para los que intentamos hacer las cosas (lo intentamos, al menos) correctamente, lo bien hecho se ve mucho más facilmente. Cuando nos enfrentamos a un proyecto software desarrollado por otro/s, lo hacemos con cierto prejuicio – «a ver qué ha hecho este tío aqui» – Eso hace que si en dos minutos no encontramos una cagada, probablemente estemos ante algo bien hecho.

Un análisis más concienzudo puede que nos muestre secretos inconfesables del producto software que tenemos delante, pero si has tenido que esforzarte para encontrar un WTF… a todos se nos escapa algo de vez en cuando :-)

OpenSpaceSevilla – Inspección continua

El pasado fin de semana estuve hablando sobre Inspección Continua en el Open Space Sevilla. Dejo por aquí las slides que use, aunque sé que no son  autocontenidas, pero puede que sean de interés.

No quiero dejar pasar este post sin expresar mi opinión sobre el evento.

En primer lugar (y como comenté en un post anterior) me gustaría dar las gracias a la organización por dedicar su tiempo desinteresadamente. En segundo lugar destacar el excelente ambiente que se vivió en el evento, las charlas (todas) fueron muy participativas, de forma que en una sola charla podías conocer el punto de vista de muchas personas, lo cual potencia la riqueza de ideas y variedad en todos los temas que se trataron. Y por último, me quedo con la gente nueva a la que he conocido, que seguro nos vemos pronto en otros eventos.

Sólo un punto negativo, y no es al evento en sí, sino a la gente que no se quedó hasta el final (a la retrospectiva) que fue muy enriquecedora. Si queremos eventos de este tipo en Sevilla también tenemos que estar en el momento en que se pueden proponer mejoras y destacar aspectos positivos.

Dicho esto, ahí dejo las slides, sin speaker, claro :-) pero si tienes cualquier pregunta deja un comentario.

Open Space Sevilla

Mañana y pasado tendrá lugar el Open Space Sevilla.

Siempre nos quejamos (es plural mayestático) de que en Sevilla no hay eventos técnicos sobre desarrollo (web o de cualquier otro tipo), por eso es de agradecer que haya personas que, de forma altruista, se preocupen de organizar un evento como el Open Space Sevilla. Y como quejarse no sirve de nada si no se acompaña de acciones (reales, tangibles), me he propuesto apoyar, contribuir y potenciar (en la medida de mis  posibilidades) cualquier evento técnico sobre desarrollo de software que se celebre en Sevilla.

En esta ocasión voy a proponer un tema a ser tratado en el Open Space, Inspección Continua (… o sobre cómo desarrollar mejor software). Además, desde klicap hemos patrocinado el evento.

Si vas a asistir al evento, allí nos vemos!

Análisis de un proyecto web Java y Javascript en Sonar

Actualmente existen plugins de Sonar para analizar código Javascript en Sonar, pero hay una limitación, y es que los proyectos en Sonar tienen un lenguaje determinado, por ejemplo, no podemos analizar un proyecto Java y Javascript al mismo tiempo. La única solución (hasta que Sonar permita el análisis de proyectos multi-lenguaje) es crear dos proyectos en Sonar usando el concepto de branch, y configurando dos análisis, uno para el código Java y otro para el código Javascript.

Si el proyecto está modelado con Maven podemos hacer uso de perfiles para definir las dos tareas. Para ello crearemos el siguiente perfil (suponiendo que el código Javascript se encuentre en src/main/webapp/ui):

<profile>
    <id>js</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src/main/webapp/ui</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

Y lanzaremos dos análisis en Sonar, uno para analizar el código Java:

mvn clean install sonar:sonar -Dsonar.branch=Java

Y otro para analizar el código Javascript:

mvn clean install sonar:sonar -Pjs -Dsonar.branch=Javascript -Dsonar.language=js -Dsonar.dynamicAnalysis=false

Previamente es necesario instalar el plugin de análisis de código Javascript en Sonar (es cuestión de minutos usando el update center). El resultado serán dos proyectos en Sonar. Lo ideal sería un sólo proyecto, pero hasta que Sonar soporte proyectos multi-lenguaje es la única solución.

En la instancia de Clinker que usamos en klicap puedes ver un ejemplo de proyecto Javascript en Sonar.

Carga lo que necesitas y cuando lo necesitas con Ext.Loader

Cuando se usa ExtJS en aplicaciones relativamente grandes se tiende a tener una gran cantidad de ficheros javascript, la descarga de todos esos ficheros puede suponer un lastre muy importante durante la inicialización de la aplicación. Hasta ahora en klicap hemos usado la solución tradicional, que durante mucho tiempo ha sido el uso de compresión y ofuscado (minify), pero ExtJS 4 ofrece otra posibilidad, el uso de un cargador (Ext.Loader) que descarga los ficheros javascript necesarios en el momento necesario.

Para usar Ext.Loader es necesario seguir algunas normas y convenciones, que por otro lado vienen bien para que el proyecto esté ordenado. El primer paso es incluir sólamente el core de ExtJS, lo cual supone el primer beneficio, en lugar de 1,1MB (ext-all.js) sólo hay que descargar 175KB (ext.js):

<head>
    <script type="text/javascript" src="ext/ext-debug.js"></script>
</head>

 

Ext.Loader.setPath({
    'MyApp': 'ui/app'
});

Esta configuración indica al loader que las clases con namespace MyApp debe buscarlas en ui/app. Por ejemplo, la clase MyApp.view.User debe estar contenida en el fichero ui/app/view/User.js.

El uso de Ext.Loader implica la separación de clases en ficheros independientes, práctica muy común en otros lenguajes de programación, pero no obligatoria en Javascript.
El resultado (y el objetivo) de Ext.Loader es que el fichero User.js sea descargado y evaluado sólo cuando sea necesario, es decir, cuando se llame a Ext.create(‘MyApp.view.User’).

En este sentido hay dos opciones, el uso de requires o no en la definición de las clases Javascript:

Ext.define('MyApp.view.User', {
    extend: 'Ext.panel.Panel',
    requires: [
        'MyApp.view.UsersGrid'
    ],
    initComponent: function() {
        var grid = Ext.create('MyApp.view.UsersGrid');
        ...
        this.callParent(arguments);
    }
});

En este caso, la carga de MyApp.view.UsersGrid (fichero ui/app/view/UsersGrid.js) se realizará en el momento de la definición de la clase MyApp.view.User, por tanto la descarga de UsersGrid.js se producirá siempre que se cargue User.js. Si se elimina el uso de requires, la carga de UsersGrid.js se realizará en el momento en que se llame a initComponent en User, es decir, cuando se llame a Ext.create(‘MyApp.view.User’), si esta llamada no se produce entonces nunca se descargará UsersGrid.js.