Organizar los ficheros de routes en nodejs – expressjs

Posted: marzo 30th, 2014 | Author: | Filed under: Sin categoría | Tags: , , , , , , , , , | No Comments »

Una de las tecnologías que estamos probando en Cartolab para aplicaciones web es nodejs con express como framework. Hay un montón de tutoriales de como empezar a usarlos, pero a poco que escribas empiezas a preguntarte como organizar el código, y ahí empiezan los problemas. express es un framework no opinativo, es decir proporciona un montón de utilidades pero da liberar total al usuario sobre como mezclarlas, así que se van desarrollando distintos modos de hacerlo.

La primera pregunta en mi casa sobre organizar el código fue acerca de los ficheros bajo el directorio routes. Podemos entender las routes de express como el equivalente al controlador en ese patrón llamado MVC que cada framework implementa como quiere, o viéndolo de otro modo como el mapeo entre una url y una función.

Vamos a ver cuatro estrategias distintas, cada una con sus ventajas e incovenientes.

Todo en app.js

La versión que se suele emplear en los tutoriales de iniciación. Escribimos en un único fichero todo el código de la aplicación.

  • Poco código boilerplate
  • Añadir una nueva url implica tocar un sólo fichero
  • Nada reusable
  • Sólo válido para proyectos pequeños

Es tan sencillo como escribir el mapeo antes de crear el servidor y usar funciones anónimas para la lógica

app.get('/', function(){res.send('root page'});

Mapear en app y la lógica en ficheros distintos

Este es el segundo ejemplo más habitual. Las url se definen en el fichero principal y las funcionalidades se agrupan en distintos ficheros bajo el directorio routes.

  • Añadir una nueva url implica tocar como mínimo dos ficheros
  • Favorece la reutilización, pero siempre debemos colocar las url a mano
  • Implica escribir más código que en el anterior y perder legibilidad

A pesar de que es muy habitual ver esto no me gusta porque no ganamos demasiado, y tener que hacer cambios en dos ficheros acaba introduciendo errores.

// app.js
var routes = require('./routes');  // Coje el fichero ./routes/index.js por defecto
var user = require('./routes/user');

app.get('/', routes.index);
app.get('/users', user.list);
// routes/user.js
exports.list = function(req, res){
res.send("respond with a resource");
};
// routes/index.js
exports.index = function(req, res){
res.send("root page");
};

Hacer el objeto app global y derivar todo hacia los ficheros de routes

Evitamos declarar app como variable local, para poder usarla en el resto de ficheros sin tener que preocuparnos de pasar parámetros. El código queda muy limpio pero se dificulta el testing y se pueden introducir bugs difíciles de detectar.

A mi me gusta esta aproximación cuando tenemos poco código y queremos hacer algo rápido, pero hay que ser consciente de los problemas que tiene.

  • No es una muy buena práctica hacer app global, en el siguiente punto vemos una mejora. Pero al hacerlo así obtenemos código más legible
  • Es bastante modular (excepto por hacer app global)
  • Es bastante legible
  • Hay separación de conceptos, cada fichero se encarga de unas determinadas url y funcionalidades

Referencias

Veamos como quedaría la implementación

// app.js
app = express(); //IMPORTANT! define the global app variable prior to requiring routes!
require('./routes');
// routes/index.js
require('./main');
require('./users');
// routes/main.js
app.get('/', function(req, res) {
res.send("root page");
});
// routes/users.js. list() could be an anonymous function, this is only for showing it in another way.

function list(req, res) {
res.send("user list");
};

app.get("/users", list);

Inyectar app en los ficheros de routes

Es similar al ejemplo anterior, pero el objeto principal es inyectado en los controladores en lugar de usarlo como una variable global. Sacrificamos un poco de legibilidad (hay que meter bastante código “inútil”) pero a cambio ganamos en modularidad y testabilidad.

Veamos una posible implementación, teniendo en cuenta que este código no lo he visto en ningún sitio, lo he escrito a partir del artículo de dailyjs y podría tener algún otro problema.

A mi esta es la aproximación que más me gusta, cuando el código aumenta y no nos queremos ir a soluciones más complicadas.

// app.js
var app = express();
// ...
app.use(express.json());
require('./routes')(app); // Must be called after app.use(express.json()) and urlencoded;
// routes/index.js
module.exports = function(app) {
require('./main')(app);
require('./users')(app);
};
// routes/main.js
module.exports = function(app) {
function index(req, res) {
res.send("root page");
};
app.get('/', index);
};

Otras estrategias

Hay estrategias más complejas, que por ahora no me ha hecho falta probar.


Montar un firefox independiente para desarrollo web

Posted: marzo 13th, 2014 | Author: | Filed under: Sin categoría | Tags: , , , , , , | No Comments »

Firefox_ScreenshotEn Cartolab llevamos ya una temporada investigando en uso de tecnologías web en el ámbito de la ingeniería cvil.

Una de las cosas que me incomodaron durante los primeros experimentos, era no tener un entorno de desarrollo específico. Al margen del IDE, en desarrollo web son fundamentales las herramientas que proporciona el navegador que usas para el testeo. En este caso, me molesta el mezclar plugins de desarrollo, con plugins normales que uso para la navegación. Tengo la sensación que se me descontrola el entorno de trabajo.

La solución es configurar un navegador específico para desarrollo. Lo cual, al menos en el caso de firefox, es más sencillo de lo que parece:

  1. Le echamos un ojo a las instrucciones de mozilla de como instalar firefox a mano. En resumen: descargar y descomprimir. Yo lo descargue en
    /usr/local/development
  2. Si ahora simplemente ejecutamos el fichero binario
    firefox

    veremos que no hemos ganado nada, aún tendremos nuestros marcadores, plugins, etc… Esto es porque firefox, guarda esta información en perfiles y usa por defecto el perfil indicado en el fichero

    $HOME/.mozilla/firefox/profiles.ini
  3. Debemos por tanto crear un nuevo perfil, pero antes haremos una copia de
    profiles.ini
  4. Creamos el perfil como recomiendan desde mozilla, ejecutando
    firefox -P

    . Yo cree el perfil dentro de la propia carpeta del firefox descargado a mano, para poder tener un sistema autocontenido.

  5. El paso anterior habrá modificado el fichero profiles.ini, añadiendo el nuevo. Pero lo que nosotros queremos es tener el modo desarrollo lo más aislado posible así que restauramos la copia que hicimos anteriormente
  6. Creamos un miniscript en nuestro PATH o donde queramos que ejecute nuestro firefox de desarrollo y le pase el parámetro
    -profile

    y el path al perfil de desarrollo que creamos. Yo cree un script ffdev en /usr/local/bin con el siguiente contenido

    #!/bin/sh
    cd /usr/local/development/firefox
    ./firefox -profile development-profile

Los menos puristas habrán observado, que en realidad, no es necesario complicarse tanto la vida bajando un firefox aparte. Llegaría con:

Crear un perfil nuevo en la carpeta por defecto, marcar el antiguo perfil como el que hay que usar por defecto y crear un script que arranque el nuevo perfil

firefox -P "Nombre del Nuevo Perfil"

Si hemos optado por la primera altenativa y finalmente decidimos pasar a la segunda, un sólo firefox en el sistema que se actualice al ritmo que marca nuestra distribución, el cambio es tan sencillo, como copiar la carpeta de perfil de desarrollo a una nueva ubicación (el
directorio por defecto de perfiles sería lo lógico) y modificar el script para indicarle la nueva ruta del perfil y que firefox tiene que
usar. Si quisieramos poder abrirlo desde el Gestor de Perfiles o con la opción -P en lugar de -profile deberemos añadirlo a profiles.ini

¿Creéis que es útil configurar un perfil para desarrollo o no hace falta? ¿Cual de los dos métodos preferís?


Qué es Twitter Bootstrap y cómo aprender a usarlo

Posted: febrero 23rd, 2014 | Author: | Filed under: Sin categoría | Tags: , , , , , | No Comments »

Generar una plantilla básica sobre la que empezar un proyecto web que tenga en cuenta los distintos navegadores y tamaños de dispositivos consume mucho más tiempo del que debería. Para minimizar este problema durante los últimos dos o tres años han surgido varios frameworks de diseño web. Si te dedicas a esto y no has estado debajo de una piedra este tiempo, sin duda habrás oído hablar de twitter-bootstrap, que es el que se ha hecho más popular.

¿Qué es bootstrap?

Bootstrap o twitter-bootstrap es un framework creado originalmente por dos desarrolladores/diseñadores de twitter para acelerar el diseño de nuevas aplicaciones web.

El framework proporciona clases css y código javascript para definir el layout de la página, crear componentes que respondan a eventos y estilizar los elementos html más habituales. Estos ejemplos están hechos con la versión 2, pero valen para hacerse una idea.

Podemos decir que los principios en los que se basa la última versión (la 3) son:

  • Responsive Design: Que según mi definición particular consiste en que la página trata de “hacer lo correcto” al ser visualizada independientemente del dispositivo y tamaño de la pantalla. El término fue acuñado por Ethan Marcotte en 2010.
  • Mobile first: Al contrario que en la versión 2, en la 3, el diseño responsivo es la opción por defecto al trabajar con bootstrap
  • Cross Browser: Trata de ser compatible con la mayoría de navegadores.
  • Integración con jQuery: Está muy integrado con jquery para el que define nuevos plugins
  • Buenas prácticas: Trata de emplear algunas de las prácticas más extendidas en cuanto a usabilidad, uso de css3/html5, organización del código, …

¿Qué me aporta bootstrap?

Si eres desarrollador con poca experiencia en diseño te proporciona una forma muy rápida de crear un layout responsivo básico de la página en la que empezar a meter tu código.

Si eres diseñador, obtienes una enorme cantidad de clases CSS que personalizar a tu gusto, sin tener que partir de cero.

Si quieres aprender a hacer las cosas mejor, es un compendio de buenas prácticas.

Aprendiendo a usar bootstrap

La documentación de la página de bootstrap debería ser tu principal fuente de información, sobre todo porque el resto de documentación tiende a quedar más desactualizada, aún así, hay una serie de tutoriales que a mi me han resultado más útiles para empezar, sobre todo porque te permiten coger ideas más generales de lo que permite hacer.

Los enlazo en el orden que creo que merece la pena seguirlos:

  1. Tutorial de w3resource: Hay partes del tutorial que están con la versión 2, pero cubre muchos aspectos
  2. Understanding twitter bootstrap 3. También se le escapa alguna etiqueta de la v2 como el container-fluid, pero en general te permite aprender a diseñar un ejemplo básico.
  3. Una introducción a los componentes que proporciona bootstrap como el scrollspy o las ventanas modales
  4. Bootstrap 3 Tutorial – An Introductory Course | Udemy. Una serie de videotutoriales muy chulos donde emplean unas cuantas clases que no he visto en otros sitios

Otros recursos

Desde que nació bootstrap han ido apareciendo un montón de recursos que sacan partido a este framework

Conclusiones

En un par de días puedes revisar los enlaces que se proporcionan en este artículo, y refactorizar alguna web sencilla que tengas para que use bootstrap. Será un tiempo bien empleado que recuperarás con creces.

No he probado otros frameworks del estilo, pero supongo que serán parecidos, cada uno con sus fortalezas y debilidades. Si le tienes manía a bootstrap, escoge otro, pero desde luego es una herramienta a meter en tu caja si eres desarrollador web.


Mover un torrent de transmission a otro ordenador

Posted: marzo 24th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , , | 1 Comment »

Una nota rápida para explicar como mover una descarga (completa o incompleta) de transmission a otro ordenador.

El escenario es sencillo, tengo los torrents divididos entre dos ordenadores, y se dió el caso de que quería mover uno de los torrents de uno de los ordenadores al otro. Mover toda la información de transmission de un ordenador a otro es sencillo, basta mover los ficheros descargados a la misma ruta en el otro ordenador, y copiar la carpeta ~/.config/transmission. Mover sólo uno es parecido, simplemente hay que ser un pelín más cuidadoso.

  1. Copiar del ordenador 1 a un almacenamiento temporal o similar los ficheros relacionados con nuestro torrent:
    • El fichero .resume en ~/config/transmission/resume
    • El .torrent en ~/config/transmission/torrent
    • El propio fichero descargado, si está incompleto da igual, reanudará la descarga desde el punto correcto.
    • Anotar la cantidad de datos descargados y enviados para ese fichero
  2. Abrir transmission en el ordenador 2 y abrir el .torrent del ordenador 1. Preferiblemente agregarlo en modo pausa para que no comience la descarga automáticamente
  3. Copiar a la ubicación del ordenador 2 donde se descargará el fichero, el fichero del ordenador 1
  4. En transmission, botón derecho sobre el torrent pausado, y “Verificar datos locales“.

Con esto estaría listo, pero si somos un poco más quisquillosos con las estadísticas y las opciones tenemos que efecutar un par de pasos más.

  1. Cerrar transmission en el ordenador 2
  2. Copiar el .resume del ordenador 1 al directorio adecuado en el ordenador 2
  3. Abrir con un editor de texto el fichero ~/config/transmission/stats.json y actualizar los valores de downloaded-bytes y uploaded-bytes

stats.json guarda las estadísticas de ejecución del programa, para actualizar los valores de interes simplemente multiplicaremos las megas descargadas/subidas por 1048576 (1024×1024) para pasar de megas y bytes y lo sumaremos a los valores que ya tenían.

Si es sólo para mover un fichero este procedimiento está bien, si es para mover más habría que hacer un script.

Referencias

 


Canciones de Karaoke a partir de vídeos del Youtube

Posted: diciembre 24th, 2012 | Author: | Filed under: Sin categoría | Tags: , , , , , , | No Comments »

Llegan las fechas navideñas, lo que implica fiestas hogareñas y con ello, los amantes del Karaoke se vuelven más exigentes. Como hacer para quitar la voz a uno de esos vídeos de Youtube creados en plan Karaoke. Hagamos un ejemplo con En El mundo genial de las cosas que dices de Maldita Nerea. Si te gusta el disco y lo compras a través de este enlace
yo me llevo un porcentaje que motiva a seguir escribiendo ;).

El primer paso es buscar en youtube o similar un vídeo donde alguien se haya molestado en añadir la letra a la canción. Buscando en el propio youtube el título de la canción + karaoke se encuentran muchos, por ejemplo este.

A continuación descargaremos el vídeo, hay muchas formas de hacerlo, pero una de las más sencillas es a través de keepvid. Llega con poner la dirección del vídeo que queremos descargar, y aceptar la ejecución del applet de java. Pasado un ratillo nos dará la opción de descargar el vídeo en varios formatos. Cualquiera de los formatos es válido, en este ejemplo usaremos MP4.

Para quedarnos con el audio de la canción usaremos la línea de comandos por ser lo más sencillo. Aunque también se puede hacer de forma gráfica.

ffmpeg -i fichero_original.mp4 -acodec copy audio.aac

Para tratar de eliminar la voz del cantante de la parte instrumental del canción usaremos Audacity. Hay varios tutoriales por ahí, tanto usando el efecto vocal removal como un poco más manual. Como este proceso es muy rápido y sencillo, prueba los dos procedimientos y quedate con el que tenga más calidad. La voz no es completamente eliminada pero si se reduce bastante. Podemos exportar el audio al formato que queramos, ya que el original estaba en AAC, lo exportaremos a este.

Para recombinar audio y vídeo, volvemos a usar la línea de comandos. Con la siguiente orden le estamos diciendo que coja el audio del fichero audio_sin_voz.aac, lo mezcle con el vídeo del fichero original (el audio original será descartado automáticamente) y producirá un nuevo vídeo de salida respetando los codecs originales.

ffmpeg -i audio_sin_voz.aac -i fichero_original.mp4 -vcodec copy -acodec copy Maldita_Nerea-El_mundo_genial_de_las_cosas_que_dices.mp4

Puedes ver como queda en mi youtube.


Actualizar la versión de Antroid de un HTC Tattoo (II parte)

Posted: marzo 18th, 2012 | Author: | Filed under: Sin categoría | Tags: , , , , , | 2 Comments »

Las consideraciones generales sobre como actualizar las puedes leer en la primera parte de este artículo.

Las principales instrucciones que yo he seguido han sido la de los propios desarrolladores de la ROM que he instalado. Lo cuento un poco más detallado. Deberías seguir las instrucciones de esa guía, lo que aquí escribo son más bien posibles problemas y es complementario a lo que allí pone.

Los pasos a seguir

  1. Instalar jdk y android sdk. El único componente que hace falta es “SDK Platform tools” que es lo que contiene el comando adb.
  2. Enciende el GPS. A veces no lo detecta si lo tienes apagado y deja de funcionar. Y recuerda que las operaciones que hagamos a partir de ahora con el teléfono deben hacerse con la opción “depuración” activada (En tu teléfono, ajustes -> aplicaciones -> desarrollo)
  3. Rootear el dispositivo. Con el sistema proporcionado con Cyanogenmod yo conseguí acceso de Root (es cuando el prompt se convierte en #) pero no conseguí instalar el comando “su” para poder convertirse en root de forma sencilla. Así que cada vez que necesitaba acceso de root (cuando en los tutoriales se menciona usar “su“, tenía que ejecutar los comandos que se indican en el punto 5 y 6  de la parte de rooting). Un par de avisos:
    • Si parece que se queda colgado pulsa intro para ver si aparece el prompt
    • Si no consegues hacerlo, habilita la opción de instalar software desde fuentes no fiables y prueba a instalar alguna aplicación como UniversalAndroot. Recuerda que puedes instalar aplicaciones con adb usando adb install aplicación.apk
  4. Haz copia de seguridad con una aplicación como Titanium Backup o Mybackup … instalables desde el Market.
  5. Instala el recovery. A mi la versión de ClockModRecovery que está enlazada en las instrucciones me dió problemas. Descargué otra versión distinta de algún sitio que no recuerdo, y al que llegué buscando el error que me daba al intentar instalarlo.
  6. Apaga el teléfono y vuelve a encenderlo en modo recovery: botón de encendido + botón teléfono (verde/descolgar) + botón casa (home)
  7. Ve a la opción de “backup and restore” y haz un backup. Dejará en un directorio de la SD clockwordmod/backup/fecha una copia de seguridad de tu ROM actual y tus datos. Enciende el teléfono en modo normal y copia esa carpeta al pc.
  8. Llegamos al punto de no retorno. Si todavía quieres segir, enciende en modo Recovery y ejecuta las siguientes acciones:
    • Wipe de datos
    • Wipe de caché
    • Wipe de Dalvik Caché (en “Advanced”)
    • Format / System (en “mounts and storage)
    • Factory Reset
  9. Sube al teléfono la ROM y las google apps. Como ROM yo emplee un nightly build con buenas críticas en los foros. Recuerda que puedes subirlas a la SD del teléfono con adb push <nombre_de_fichero> /sdcard.
  10. Enciende en modo recovery y en instalar zip escoge primero la rom y luego las google apps. Escoge reboot y cruza los dedos.

La primera vez a mi me tardó en arrancar unos 3 o 4 minutos así que paciencia. Comprueba que todo funciona, GPS, Wifi, llamar etc … y listo. Acuerdate de configurar la red preferida, el punto de acceso, …

En caso de problemas con la batería

Espera a haber hecho un par de recargas completas. Si tras eso sigue habiendo problemas:

  1. Cargala al 100% y déjala todavía un rato más
  2. Sin desconectar el teléfono se enciende en modo recovery
  3. Se hace un wipe de la batería
  4. Apágalo y desconectalo
  5. Enciende el teléfono, y no lo apagues ni lo reinicies hasta que la batería se descargue totalmente por si sóla

Por otro lado, la ROM de Cyanogen viene con un launcher llamado ADW Launcher. Alguna gente opina que el que menos batería gasta es “Launcher Pro”. Pero esto parece ser más bien para gustos.

Y una cosa que no me ha quedado clara es si la ROM de Cyanogen por defecto hace overclock del procesador, es decir como si hiciera girar más rápido al reloj que marca al ritmo que debe funcionar el procesado (que no tiene nada que ver con la hora). Esto gasta batería y puede controlarse con una aplicación llamada SetUP. Si bajas la frecuencia el teléfono será menos responsivo pero disminuirá el consumo de batería.

El resultado


Actualizar la versión de Antroid de un HTC Tattoo (I parte)

Posted: febrero 26th, 2012 | Author: | Filed under: Sin categoría | Tags: , , , , , | 2 Comments »

Hay muchos foros y tutoriales explicando como actualizar la versión de Android de un teléfono HTC Tattoo. Este es (la primera parte de) el mio. Aunque antes de continuar leyendo deberías saber que todo lo escrito aquí proviene de lo aprendendido en apenas un fin de semana así que puede ser incorrecto.

Los HTC Tattoo vienen con una de las primeras versiones de Android que salió al mercado, la 1.6. Esto impide usar alguna de las aplicaciones actuales más conocidas (leáse Whatsapp), tiene problemillas con el bluetooth, …

El principal desarrollador de Android es Google. Los fabricantes de teléfonos colaboran en el desarrollo de Android y además hacen algunas adaptaciones propias para sus propios teléfonos. Las compañías de servicio telefónico, tampoco acostumbran a quedar tranquilas con la versión que desarrolla el fabricante y empaquetan su propio software en el teléfono, a veces es simplemente cambiar la pantalla de inicio, a veces cambios más profundos como substituír el Market de Google por uno propio.

En el caso del Tatto ni el fabricante del teléfono ni la compañía que lo distribuye están interesados en sacar una actualización a versiones más modernas de Android; y aquí es donde entra en juego la scene. Como Android es (semi) libre hay equipos de programadores que lo modifican y adaptan para sus propias necesidades y publican esas modificaciones de forma gratuita. Entre estas modificaciones está el reescribir los drivers necesarios para que teléfonos antiguos puedan ejecutar versiones de Android modernas. Estos programadores acostumbran a especializarse en modelos o marcas específicas de teléfonos. También es habitual que haya quien re-empaquete el código que desarrollan equipos más o menos consagrados. Los de cyanogenmod por ejemplo tienen el código en github y hay quien se dedica a publicar snapshots de los binarios de ese código y a hacer modificiones

Yendo a lo que nos ocupa que es actualizar el Tattoo hay que tener claros varios conceptos:

  • Versión de Android que queremos actualizar. Recomendable la 2.3 por ser la más en uso en estos momentos
  • Se denomina ROM al paquete de software binario que contiene el sistema operativo que vamos a instalar. Por problemas de copyright las ROM no vienen con las aplicaciones de Google (Market, sincronización de contactos, …) que deben ser instaladas a parte. El desarrollador de la ROM suele recomendar cuales son las gapps (google applications) que funcionan sobre su ROM.
  • Para instalar la ROM (flashear el teléfono) es necesario un sistema intermedio, al que se denomina recovery. El recovery es una especie de sistema operativo muy básico que nos permite hacer un borrado (wipe) de distintas partes del teléfono, instalar la ROM, hacer copia de seguridad de nuestra ROM y datos actuales, … Por supuesto hay un montón de recovery distintos, y en función de la ROM que queramos instalar usaremos uno u otro, generalmente el desarrollador de la ROM recomienda uno.
  • GoldCard. Debo decir que no he acabado de entender para que vale esto. Recomiendan hacerlo, porque permite recuperar un teléfono que se queda en modo ladrillo (brick), pero yo sigo sin verlo claro. Por lo que he visto me da la impresión de que la goldcard no tiene nada que ver con el teléfono, si no con la SD.
  • Rootear el teléfono. Android es un sistema operativo basado en linux. Tiene por tanto particiones (algunas de las cuales se montan por defecto en sólo lectura), permisos, … A conseguir acceso de root, se lo llama rootear el teléfono.
  • Android SDK. Google proporciona lo que se llama un SDK (Software Development Kit). Son un conjunto de aplicaciones que ayudan en las tareas de desarrollo y depuración de software para teléfonos Android. En este caso lo que más nos interesará es el comando “adb” que permite desde el pc abrir una shell (tipo ssh) en el teléfono, subir archivos al teléfono, …

Como siempre hay un montón de tutoriales distintos de como actualizar el teléfono, y como siempre, no te valdrá con seguir ninguno de ellos al pie de la letra, si no que siempre pasará algo y tendrás que acabar combnándolos. Dejo aquí los que yo he leido:

En la segunda parte, voy al grano de como lo hice yo.


Taller de gvSIG-EIEL en Valencia. Método 2

Posted: noviembre 29th, 2011 | Author: | Filed under: General | Tags: , , , , | 5 Comments »

Como comentábamos en la anterior entrada hemos creado un fichero .iso que podéis “quemar” en un pendrive de al menos 4GB para seguir el taller de gvSIG-EIEL. Podéis descargar el .iso desde este enlace.

Tras quemarla podréis arrancar vuestro ordenador desde el PC configurando en la BIOS que arranque en primer lugar desde ahí. Se trata de una versión de ubuntu con gvSIG-EIEL y una base de datos PostGIS con datos de prueba, todo preinstalado.

Para quemar el pendrive podéis seguir estas instrucciones. para linux o para windows.

El usuario por defecto es “custom” sin clave. Para conectar a la base de datos usaremos:

  • servidor: localhost
  • usuario: user
  • clave: user
  • puerto: 5432
  • esquema: eiel_map_municipal
El fichero .iso también debería poder ser ejecutado desde una máquina virtual.
Si tenéis algún problema dejad un comentario o comentádnoslo antes del taller. Estaremos todos los días por las jornadas.

Maquetación de múltiples ficheros de texto usando LibreOffice

Posted: octubre 6th, 2011 | Author: | Filed under: General | Tags: , , , , | No Comments »

Cartolab está colaborando con Ingeniería Sin Fronteras en un proyecto financiado por la Xunta de Galicia para la elaboración de materiales para un curso de Sistemas de Información Geográfica y Cooperación al Desarrollo. En la elaboración del curso tenemos la suerte de colaborar también con iCarto y con el Laborate. Además el SIGTE se encarga de revisar el trabajo y poner la plataforma de teleformación. Gracias a todos ellos por hacer posible este artículo.

Maquetar múltiples ficheros con LibreOffice

Uno de los puntos que defendemos en el curso es de la importancia del uso de software libre en los proyectos de cooperación, y por coherencia, tratamos en la medida de los posible de emplear unicamente herramientas libres para elaborar los contenidos. Nos encontramos por tanto con un equipo de alrededor de 9 personas en varias instituciones distintas editando cerca de 20 ficheros de texto distintos con LibreOffice, lo cual entre otras cosas genera el problema de obtener al final una maquetación coherente. Está claro que existen soluciones más imaginativas por ejemplo usar latex con git como repositorio de información pero en ciertos contextos esto es simplemente imposible.

Cuando queremos que un documento de texto tenga un formato consistente empleamos estilos, cuando necesitamos un formato consistente en múltiples ficheros empleamos plantillas.

Que es una plantilla y como se crea

Apurando la definición se podría decir que una plantilla no es más que un documento de texto de LibreOffice con extensión .ott en lugar de .odt en el que se han definido los estilos del documento, las cabeceras, ciertos textos, … El truco está en que cuando creamos un nuevo documento a partir de una plantilla este documento se queda en cierta manera vinculado a la plantilla. Por tanto cuando modifiquemos la plantilla se modificarán los documentos asociados.

Al menos esa es la teoría en realidad hay algunos handicaps:
- No todo lo modificado en la plantilla se actualiza en los documentos. Los estilos si que son actualizados pero textos que podamos tener por las páginas por ejemplo una portada no se actualizan. Aunque hay una extensión que lo arregla.
- La actualización no es automática. Cuando abrimos el documento vinculado, si la plantilla ha cambiado nos pregunta si queremos actualizar los estilos, no se actualizan por si mismos.
- Las plantillas pueden ser compartidas pero no es lo más cómodo del mundo.
- Una precaución que habría que tener es que en general no debemos modificar el estilo en el documento. Debemos: Cerrar el documento, modificar la plantilla y volver a abrir el documento para que se actualicen.

A pesar de estos handicaps el disponer de plantillas para los documentos corporativos de tu empresa puede acabar ahorrándote mucho tiempo.

  • Para crear una plantilla lo más fácil es crear un nuevo documento de texto y luego Archivo -> Plantilla -> Guardar.
  • Para crear un documento a partir de una plantilla Archivo -> Nuevo -> Plantillas de documentos.
  • Para editar una plantilla, desde cualquier documento, Archivo -> Plantilla -> Administrar, seleccionamos la que nos interese y en botón desplegable llamado Comandos le damos a editar. Para guardarla usamos el mismo procedimiento que para crear una nueva (Archivo -> Plantilla -> Guardar) pero seleccionando la ya existente para que la sobreescriba.

Compartir la plantilla

Compartir la plantilla no es del todo necesario. Si una persona tiene la plantilla en su ordenador y maqueta todos los documentos, aunque el resto no tengan la plantilla cada documento individual si que conservará los atributos de los estilos. Por tanto se puede continuar editando el documento usando los estilos predefinidos. Pero no podrá crear nuevos estilos o modificarlos porque creará inconsistencias. Tendrá que solicitar a quien tiene la plantilla que la modifique y abra todos los documentos para que estos se actualicen.

Si no disponemos de la plantilla en nuestro ordenador tampoco podremos crear nuevos documentos a partir de la plantilla. Una solución por supuesto es mandarla por correo-e cada vez que haya un cambio, pero existe un método algo más sofisticado.

En nuestro caso concreto empleamos DropBox (nadie es perfecto) para compartir los materiales del curso, de modo que podemos dejar la propia plantilla en una carpeta compartida. La persona que crea la plantilla la exporta (Archivo -> Plantilla -> Administrar, seleccionamos la que queremos y en el botón de Comandos->Exportar).

LibreOffice nos da la oportunidad de importar plantillas (misma secuencia de menus que para exportar) pero si hacemos esto creará una copia local de la plantilla y las modificaciones en el original no se verán reflejadas. Lo que debemos hacer es decirle que consideré la carpeta que nosotros queramos como una carpeta válida de plantillas. Para ello:

Herramientas -> Opciones -> Rutas -> Marcamos plantillas, le damos a editar, agregamos como ruta nueva la de nuestra carpeta compartida y la seleccionamos.

Por desgracia, la cosa no iba a ser tan fácil, las plantillas que pueda haber en esa carpeta no son reconocidas automáticamente y ni no vale con importalas así que hay que hacer un pequeño truco.

  1. Configuramos la ruta a la carpeta compartida si no lo hemos hecho todavía
  2. Cortamos y pegamos en otro sitio la plantilla que está en la carpeta compartida. Es importante por tanto que no haya en en la carpeta de plantillas una que ya tenga el nombre que vamos a usar, si no LibreOffice le asignará otro distinto y el fichero compartido tendrá un nombre distinto por tanto.
  3. Abrimos mediante doble click el fichero que contiene la plantilla y guardamos la plantilla a partir de él (Archivo -> plantilla -> guardar). De nombre le pondremos el que hayamos acordado con el resto de gente respetando mayúsculas etc … Muy importante respetar escrupulosamente el nombre
  4. Con eso estaría listo. Ya tendriamos esa plantilla disponible en nuestro sistema y cada vez que la modificáramos estaríamos tocando el fichero compartido de modo que se le actualizaría a los demás.

En próximos artículos seguiremos contando algunos trucos de los estilos que podemos usar a la hora de hacer la plantilla el uso de campos, …


Como carga gvSIG las extensiones

Posted: septiembre 2nd, 2011 | Author: | Filed under: General | Tags: , , , | 4 Comments »

En la línea abierta por Andrés de “Como gvSIG hace xxx” os presento un artículo que explica como se gestiona la carga de las extensiones en gvSIG. Antes de nada debo agradecer a Cartolab cederme tiempo para poder escribirlo.

Lo que sucede cuando lanzamos gvSIG es que la máquina virtual de java ejecuta el método main() de la clase Launcher de andami, el framework que sostiene el sistema de ventanas y plugins de gvSIG.

A efectos de este artículo sobre la carga de extensiones podemos decir que ese método main() es el responsable de lo siguiente:

  1. Procesar los parámetros que se le pasan por línea de comandos
  2. Cargar los plugins
  3. Cargar las clases de los plugins
  4. Recuperar la configuración persistida de los plugins
  5. Inicializar las extensiones
  6. Cargar menus y toolbars
  7. Hacer la postinicialización de las extensiones

1.- Procesar los parámetros que se le pasan por línea de comandos

Lo más habitual es que la orden que ejecute el sistema operativo (quitando los parametros que se pasan a la jvm) sea algo parecido a:

$ java com.iver.andami.Launcher gvSIG gvSIG/extensiones “$@”

donde la parte en negrita serían los parámetros que pasamos al main(). En concreto ese segundo parámetro gvSIG/extensiones es el que está definiendo donde está la carpeta de plugins de gvSIG, como ruta relativa desde donde se encuentra el fichero andami.jar.

Es decir, que si bien el directorio de extensiones suele estar en un punto predefinido nosotros podriamos escoger otra ubicación.

2.- Carga de los plugins

Procesados los parámetros de entrada la aplicación recorre todos los directorios contenidos en la carpeta de plugins. Si dentro del directorio existe un fichero de nombre “config.xml” lo parsea y en caso de ser correcto añade el par ["nombre del directorio", objeto PluginConfig] al campo de la clase Launcher

private static HashMap pluginsConfig = new HashMap();

Donde PluginConfig es una clase que se encarga de mantener toda la información que aportan los ficheros config.xml.

Lo más interesante de esta fase es entender que el orden en que se recorren los directorios, y por tanto el orden en que luego se inicializarán las extensiones, es aleatorio, o en realidad es el orden que devuelve el método lisFiles() de la clase File de Java, que especifica en su documentación que el orden en se devuelven los ficheros no está asegurado y supongo, dependerá de la implementación concreta de la máquina virtual y del sistema operativo que se emplee.

Hay que aclarar que en este contexto, un plugin, es igual a un directorio contenido dentro del directorio de extensiones/plugins definido como parámetro.

3.- Carga de las clases de los plugins

Lo siguiente que intenta hacer es indexar todas las clases de todos los plugins. Para ello recorre pluginsConfig, solicitando el valor de la etiqueta del config <libraries library-dir=”VALOR” />. Lo más habitual es que ese VALOR sea “./”, es decir el propio directorio del plugin. Para cada plugin mantiene un objeto PluginClassLoader que basicamente contiene un índice de todos ficheros .class que están dentro de los ficheros .zip o .jar que están en ese library-dir.

Para cada plugin se crea un objeto PluginServices que a su vez mantiene la instancia del PluginClassLoader que le corresponde. Esos PluginServices se almacenan en el campo

private static HashMap pluginsServices= new HashMap();

de la clase Launcher.

Hay que tener en cuenta que a la hora de cargar las clases de un plugin, si en el config se ha definido que depende de otro mediante una etiquetacarga la clases de la dependencia (de forma recursiva) antes que el nuestro. Por tanto, en pluginsServices los plugins se reordenan respecto a pluginsConfig poniendo los plugins de los que se depende antes. Se mantiene también una variable pluginsOrdered con el nombre de los plugins en el mismo orden que pluginsServices

4.- Persistencia de los plugins

Se actualiza el andamiConfig que contiene una lista (el fichero andami-config.xml habitualmente) que persiste con todos los plugins presentes el directorio de plugins.

Luego se recupera de disco la configuración persistida de los plugins en el fichero plugins-persistance.xml, y se setea esa configuración en el PluginServices asociado a cada plugin.

5.- Inicialización de las Extensiones

Es en esta fase cuando salen por consola los mensajes de:

Initializing extensions from “Nombre_del_plugin” (para cada plugin)

y

Initializing “Nombre_de_la_Extension” … (para cada extensión)

Se recorre pluginsOrdered, y para cada plugin se crea una instancia de cada extensión (en el orden que se define en el config del plugin) y se llama a su método initialize(). Además se almacena esas instancia en el campo de Launcher:

private static ArrayList extensions=new ArrayList();

Por el medio crea también un objeto ExtensionDecorator que nos da un control adicional sobre las extensiones pero esto no nos interesa a los efectos de este artículo.

6.- Menus y Toolbars

Se cargarn los menus y los toolbars definidos por los plugins a través de los métodos installPluginsMenus() y installPluginsControls().

7.- Post-inicialización de las extensiones

Se va llamando al método postInitialize de cada extensión en el orden en que aparecen en el array extensions. Con este paso finalizaría el proceso de carga.

Una cosa que no he investigado a fondo pero que intuyo que es así, es que en algún momento de este proceso se asocian las instancias del array extensions a los menús y botones del toolbar. De este modo las extensiones (clases que heredan de extension y aparecen en los config) se comportan como una especie de singleton, porque gvSIG siempre la recupera de ese array de extensiones, y cuando el desarrollador externo llama a PluginServices.getExtension(Class) la está recuperando de ahí también (del ExtensionDecorator del que hablamos antes en realidad, pero la idea es la misma)

Esto explica también porque cuando recompilamos nuestro código, si cambiamos algo en la clase de la extensión debemos cerrar y abrir gvSIG. La instancia de la extensión se crea durante la carga de gvSIG y se mantiene hasta que cerramos gvSIG, y por tanto no es “recargada” de los nuevos .class

Me quedan un par de dudas que quedan para estudiar para próximos posts o para quien se anime a escribir más artículos de la serie de “Como hace gvSIG XXX”:

  • Al parecer existe una extension del tipo ExclusiveUIExtension a la que se hace referencia en Launcher.initializeExclusiveUIExtension() que no tengo muy claro como funciona
  • Estaría bien explicar en detalle el comportamiento de los ExtensionDecorator
  • Estaría bien explicar detalladamente el proceso de creación y ubicación de los menús y toolbars
  • Algunas partes del código son un poco liosas. Tengo algunas ideas de como refactorizarlo así que si alguien se anima que pregunte