Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Archivos en la Categoría: Development

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 :-)

Anuncios

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.

ComboBox en Sencha ExtJS 4. Carga asíncrona

La clase  Ext.form.field.ComboBox en ExtJS es realmente potente, permitiendo desde paginación hasta la posibilidad de definir mediante Ext.XTemplate el contenido de cada línea del combo. Pero su comportamiento asíncrono puede convertirse en un problema cuando la conexión con el lado del servidor es lenta. En klicap usamos ExtJS desde hace casi dos años, y nos hemos encontrado con este comportamiento recurrentemente, ya era hora de solucionarlo :-)

Para situarnos. Todo componente de ExtJS que actúa como contenedor de datos tiene asociado un Store (Ext.data.Store) el cual define una serie de parámetros que afectan a la relación entre el contenedor y los datos:

  • Estructura de datos. Haciendo uso de Ext.data.Model (se establece una relación entre la fuente de datos y los objetos javascript que los mapean).
  • Características de la fuente. La fuente de datos puede encontrarse en memoria (un array que contiene los datos) o puede ser remota (lo cual implica el uso de AJAX). En este último caso se ha de definir el formato de los datos recibidos (JSON o XML).
  • Comportamiento. Se indica si el Store se cargará automáticamente al crear el objeto, o requiere una llamada a load().

Un ejemplo de definición de un combo (de timezone) con fuente de datos remota, JSON y carga automática (el combo se encuentra dentro de un formulario y este asu vez dentro de una ventana):

Ext.define('User', {
    extend: 'Ext.window.Window',
    initComponent: function() {
        this.items = [{
            xtype: 'form',
            border: false,
            fieldDefaults: {
                labelWidth: 100
            },
            items: [{
                xtype: 'fieldset',
                anchor: '100%',
                title: 'User data',
                items: [{
                    layout: 'anchor',
                    items: [{
                        xtype: 'combo',
                        fieldLabel: 'Timezone',
                        name: 'timezone',
                        width: 300,
                        queryMode: 'local',
                        triggerAction: 'all',
                        valueField: 'id',
                        displayField: 'timezone'
                        store: Ext.create('Ext.data.Store', {
                            model: 'Timezone',
                            proxy: {
                                type: 'ajax',
                                url: 'api/timezone',
                                reader: {
                                    type: 'json',
                                    root: 'timezones'
                                }
                            },
                            autoLoad: true
                        })
                    }]
                }]
            }]
        }];
        this.callParent(arguments);
    },
    modal: true,
    width: 430,
    height: 350,
    layout: 'fit',
    title: 'User'
});

Durante el proceso de carga de datos en el formulario ExtJS hace el mapping de los valores que vienen en el JSON en los campos del formulario (usando la propiedad name del campo). Por tanto la carga del formulario sería tan simple como:

var userForm = Ext.create('User');
userForm.getComponent(0).getForm().load({
    url: 'api/user/12',
    method: 'GET',
    success: function (form, action) {
        userForm.show();
    }
});

En este fragmento de código se realizarán dos peticiones HTTP GET al servidor: una para la carga de combo (GET ‘/api/timezone’ debido a la propiedad autoload: true del combo) y otra para la carga de los datos del usuario (GET ‘/api/user/12’).

Como he comentado antes ExtJS realiza llamadas internas a Ext.form.field.Base.setValue() para setear el valor de cada campo del formulario (como parte de la llamada a load). Pero ¿qué sucede cuando se intenta setear el valor del combo antes de que el listado de valores haya sido cargado?, es decir, la llamada a ‘/api/user/12’ termina antes que ‘/api/timezone’. El resultado es que el valor no se fija y el combo se queda vacío, y eso es un #FAIL.

Para evitarlo es necesario esperar a que la carga del listado de valores de combo haya terminado y sólo despues hacer el setValue(). La siguiente extensión se encarga precisamente de esto de una forma bastante simple:

Ext.define('AsyncSafeComboBox', {
    extend: 'Ext.form.field.ComboBox',
    alias: 'widget.safecombo',
    setValue: function(value, doSelect) {
        if(this.store.loading){
            this.store.on('load', Ext.bind(this.setValue, this, arguments));
            return;
        }
        this.callParent(arguments);
    }
});

La clave está en la propiedad ‘loading’ de Ext.data.Store que indica si el store asociado al combo está aún cargando sus datos. Si la llamada a setValue se realiza durante la carga del store, entonces se retrasa hasta que el store indique que ya ha acabado (evento ‘load’).

Sólo habría que cambiar el xtype de nuestro combo a ‘safecombo’ y siempre se realizará la carga de forma correcta.