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.

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

Posted: noviembre 28th, 2011 | Author: | Filed under: General | Tags: , , , , | 1 Comment »

El jueves por la tarde en las Jornadas de gvSIG, Gonzalo y yo estaremos por parte de Cartolab impartiendo el taller sobre gvSIG-EIEL.

El taller está pensado para que los que acudan puedan seguir los ejemplos con su portátil. Dado que gvSIG-EIEL hace uso de una base de datos PostGIS para funcionar vamos a explicar dos formas distintas de poder seguir el taller.

La primera de ellas es que instaleis directamente en vuestro portátil la base de datos. Desde Ubuntu es tan sencillo como hacer:

1
sudo apt-get install postgresql-8.4-postgis pgadmin3

Y luego crear un template para postgis.

1
2
3
4
5
su postgres
createdb postgistemplate
createlang plpgsql postgistemplate
psql -d postgistemplate -f /usr/share/postgis/lwpostgis.sql
psql -d postgistemplate -f /usr/share/postgis/spatial_ref_sys.sql

Y en windows bajándose este pack y acordándose de seleccionar en el momento adecuado que también instale postgis.

Con motivo del taller vamos a proporcionar un nuevo set de datos que os podéis descargar desde este enlace. Aunque con los publicados en la página web es suficiente para hacer la mayoría de los ejemplos.

Desde la interfaz de pgAdmin3 se crea una nueva base de datos usando como template “template_postgis” y luego se emplea el set de datos que proporcionamos sobre la base de datos que acabamos de crear. En caso de que hayamos llamado gvsig-eiel a la base de datos hariamos:

1
psql -U postgres -p 5432 -h localhost -f gvsig-eiel.sql -d gvsig-eiel

En caso de duda este artículo puede ayudaros. Si tenéis alguna duda dejad un comentario en el blog o escribidme a fpuga ARROBA cartolab.es. Es importante que si vais a seguir el taller de forma activa traigais todo configurado.

gvSIG-EIEL podéis descargarlo de la propia página. Con motivo del taller hemos dispuesto un servidor alternativo por si hubiera problemas.

Mañana publicaré el segundo método. Vamos a distribuir un fichero que podreis volcar a un USB (mínimo 4GB y se perderán los datos que tuvierais en ellos) que actuará como sistema operativo completo con todo instalado que podéis ejecutar directamente desde el USB sin necesidad de tocar nada en el ordenador (aunque funciona considerablemente más lento)


Jornadas de Economía Social

Posted: noviembre 15th, 2011 | Author: | Filed under: General | Tags: , , , , | 1 Comment »

La semana pasada participé en unas Jornadas sobre Economía Social organizadas por la Oficina de Cooperación y Voluntariado de la Universidad de A Coruña. Mi charla tiene el título, seguramente no muy acertado por mi parte, de “Cultura Libre”. Lo que conté es más o menos lo siguiente.

Lo primero, fijar el marco de la discusión

Cada vez es más habitual escuchar términos como Democracia Económica, Economía/Empresa Social, Responsabilidad Social Corporativa o CopyLeft. Al escuchar en boca de alquien alguna de estas palabras debemos tomar dos precauciones.

  • La primera, es que tienden a usarse muy libremente y cada autor aplica una semántica distinta al mismo término, por lo que antes de continuar la discusión debemos ponernos de acuerdo en que concepto se encuentra bajo ese término
  • La segunda, es que desde mi punto de vista, no deben entenderse como objetivo a alcanzar si no como herramientas para algo mayor: el Desarrollo Humano Sostenible.

Dado que el concepto de Desarrollo también ha variado (y seguirá variando) a lo largo del tiempo, es importante definirlo. En mi caso cuando hablo de Desarrollo aplico la aproximación basada en capacidades de Amartya Sen. Saber como se entiende el Desarrollo nos ayudará a comprender que se entiende también por Economía Social.

Explica bien esto David de Ugarte en este vídeo [0:35 – 4:00], donde también se menciona que una de las patas básicas para el Desarrollo es la generación sostenible de riqueza a través del acceso y el éxito en los mercados. Y para ello debe empoderarse a las personas que trabajan en ello, invirtiendo en cultura, sanidad, tecnología, …

€ != Riqueza (pero importan)

Si bien como queda claro en el apartado anterior la obtención de euros, es distinta a la generación de riqueza, en general sin dinero tampoco se puede obtener riqueza. Por ello el segundo bloque de la charla se basa en explicar cuales son las actividades que generan mayor valor añadido.

La dinámica del iPod (gracias Andrés) consiste en darles dos tablas en blanco, una con las distintas fases del proceso de producción del iPod y otra con los países que intervienen en estas fases, para que los participantes rellenen los porcentajes que creen que ocupa cada parte. De este modo ellos mismos se fijan la imagen mental de que las actividades económicas de mayor valor añadido son aquellas ligadas al conocimiento.

Se puede llegar más alla en este razonamiento, incluso en los países empobrecidos cuya fuente de riqueza se asocia de forma tópica a actividades como la agricultura tradicional, los intangibles suponen el mayor porcentaje de fuente de riqueza

Es importante aclarar, que por conocimiento no entendemos sólo aquello que afecta a la alta tecnología sino que abarca a nuevas formas de organización y gestión o a incrementos de producción ligados al sector primario.

Modelos cerrados

Fijado el objetivo, el Desarollo Humano Sostenible. Fijado el como, generando Riqueza. Y asumiendo que la forma más factible de generar riqueza es mediante el conocimiento (y el empoderamiento personal) podemos contraponer los dos modelos existentes de organización y producción, el cerrado y el abierto (¿o libre?)

Para no entrar en el complicado debate de distinguir entre patentes, copyright y propiedad intelectual asumamos que podemos usarlos como sinónimos.

La premisa básica del modelo cerrado dice que “en ausencia de patentes, no habría incentivos para la innovación”. Argumenta que dados los elevados costes que tiene la investigación y la innovación es necesario que el estado conceda patentes, es decir, un monopolio temporal para la explotación de una invención.

Destaco estado y monopolio. Monopolio, porque excepto en este caso, siempre se otorga a los monopolios cualidades negativas.

Y Estado, porque la propiedad intelectual no es algo que exista de por sí (un derecho natural podríamos decir) si no que es algo que la legislación concede porque entiende que es positivo para los ciudadanos (fomenta el desarrollo). Por supuesto tomamos como hipótesis que la legislación esta realizada de forma que se alinee con nuestro objetivo de busqueda del beneficio social.

Si bien los argumentos son claros, estos presentan problemas, el primero de ellos, es que si al principio deciamos que para fomentar la generación de riqueza había que invertir en cultura y tecnología, el coste de acceso se ve incrementado por el copyright y las patentes. Aún suponiendo que las patentes fueran necesarias para la innovación, si tomamos el caso del modelo cerrado por excelencia, la industria farmaceútica, encontramos numerosos casos, donde no existe beneficio social, por ejemplo en los altos costes de acceso a medicamentos para combatir el SIDA que hace que un 80% de la población mundial que los necesita no pueda comprarlos, cuando los genéricos equivalentes podrían llegar a costar 10 veces menos (el anticancerigeno Glivec cuesta 2000€ frente a su genérico que cuesta 150€)

Y aún siguiendo la suposición de que las patentes son necesarias, podemos encontrar muchos ejemplos de malas prácticas, siendo usadas como barrera de entrada nuevos competidores al mercado o como defensa ante otros.

Si nos cuestionamos la necesidad de las patentes es cuando entramos en un terreno más interesante, habitualmente se cifra en unos 900 millones la cantidad necesaria para sacar al mercado un nuevo medicamento. En el año 2006 Novartis facturo 2554 millones por el Glivec.

Modelos abiertos

A pesar de que hemos encontrado problemas en el modelo cerrado pudiera ser que fueran males necesarios por no existir otras alternativas mejores. Existen abundantes argumentaciones teóricas sobre la no necesidad de la propiedad intelectual tal y como la entendemos; pero lo mejor es fijarnos en ejemplos en los que se haya producido verdadera innovación en ausencia de patentes.

El más claro de ellos es el modelo del Software Libre. Queda para otro artículo el meterse a fondo en este punto.

Incluso en las farmaceúticas se ven movimientos en esa dirección. La misma Novartis que fabrica el Glivec, tiene una iniciativa en la que se comparten los datos de la diabetes tipo 2. Si hace esto no es por amor al arte, si no que no cuenta con los recursos necesarios para llegar a resultados por si misma, y liberándolos, conseguirá que otros “investiguen gratis” sin perder Novartis su posición de aventajada con respecto a sus competidores al ser quien mejor conoce esos datos y quien más trabaja en ellos.

En las transparencias hay algunos otros ejemplos que no eran los más apropiados a la hora de hablar de modelos abiertos, como por ejemplo el de grupos como radiohead que distribuyen su música de forma gratuita (pero no libre) o ejemplos de crowdfounding. A pesar de no ser correctos creo que es interesante mencionarlos porque nos dan pistas de los nuevos modelos que están emergiendo y que se aproximan cada vez más a ese mundo sin patentes que algunos deseamos y que van llegando a los medios más generalistas.

Sólo mencionar que en la presentación van los logos de las tres organizaciones en las que trabajo/colaboro sin las que seguramente no habría podido hacerla

View more presentations from Francisco Puga

Trabaja upstream y facilita que los demás también lo hagan

Posted: octubre 18th, 2011 | Author: | Filed under: General | Tags: , | 2 Comments »

No os perdáis los artículos enlazados por Andrés sobre los costes de no trabajar upstream. En resumen:

La mayoría de desarrollos basados en software libre se mantienen en “local”. Para satisfacer las necesidades de un cliente puede llegar un momento en que sea necesario parches una aplicación. Si estos parches no son integrados en la rama principal de un proyecto en la mayoría de las ocasiones nos veremos en la necesidad de actualizar nuestro código con el del repositorio principal. Bien porque hayan corregido errores que nuestro cliente reporta, porque queramos mantener nuestro código actualizado …

Cada vez que actualicemos nuestro código tendremos que comprobar que nuestros parches siguen correctamente integrados, independientemente del tamaño del proyecto esto acaba volviéndose un verdadero quebradero de cabeza. Tendremos que sacar nuestros propios ejecutables de la aplicación …
Si nuestros parches se encuentran upstream son otros los que se encargan de todo este trabajo.

Trabajar upstream tampoco es gratis. Es probable que otros desarrolladores hagan comentarios a tu código y pidan otra aproximación, el mantenedor exigirá un formato de código determinado etc … Además la realidad es que los mantenedores serán menos propensos a incluir tus cambios cuanta menos participación tengas en el proyecto.

Se debe por tanto trabajar upstream. En general si. Si tu código difiere mucho es importante hacerlo porque te ahorrará horas de mantenimiento que compensarán el integrar tus parches.
Si tus parches son pequeños a veces lleva más tiempo integrarlos que manterlos en local. Pero subirlos incrementará tu reputación en el proyecto de modo que cuando necesites integrar porciones más grandes de código o incluso ayuda para desarrollar alguna característica el resto de la comunidad estará predispuesto a ayudarte.

Integrar código en upstream es también una forma de decirle a tus (posibles) clientes, ey, yo puedo hacer eso que pedís y mantenerlo.


gvSIG-EIEL 1.0 RC2 Published

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

Last week, Cartolab, the university lab where i work, released a new version of gvSIG-EIEL.

gvSIG-EIEL is a portable version of gvSIG bundled with some new extensions and some changes in the image designs. The application is focused to accomplish the requirements of the EIEL, an infrastructure inventory that some spanish public administration should do.

Some of this extensions like eye candy forms to introduce the data, or tools to verify that the data follow the established rules are specific for the eiel but others can be useful for any gvSIG’s user. As i think that the tools developed by Cartolab for gvSIG-EIEL (OpenCADTools, …) are already known i want to talk a bit of a new extension and the work done on Sextante.

The new extension is MapSheets developed by prodevelop in coordination with the gvSIG Association and ourselves to allow release it as a official gvSIG extension. MapSheets allows create map series in a really easy way. For those who comes from ESRI software it is something like MapBook but free and with some new features.

Under the umbrella of gvSIG-EIEL, Victor Olalla develops some new algorithms like the line properties that obtains some statistics for line shapefiles and can get the slope between two points of the line if a DEM is present. Also a useful improvement of the use of Sextante in gvSIG-EIEL is that it comes with two buttons to open the toolbox. The algorithms that appears in the second toolbox are easily configured editing the file alglist.txt that is in the sextante folder (es.unex.sextante) inside the gvSIG extensions folder. Just write in that file the names of the algorithms that you want to see in that file. If you only work with a subset of the algorithms this helps you to localize and use it.

MapSheet and the work on Sextante have been funded by the Spanish public administrations Deputación de Pontevedra and Dirección Xeral de Sostibilidade e Paisaxe de la Consellería de Medio Ambiente, Transporte e Infraestruturas de la Xunta de Galicia


BLOGUZZ-0a2dbc2d7d

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

Título raro pero es que acabo de darme de alta en bloguzz, una empresa que pone en contacto a blogers y marcas de forma que los bloguers reciben productos y servicios para postear sobre ellos.

La verdad es que todavía no tengo muy claro como funciona. Por lo que he entendido tienes que dar de alta tu blog y validarlo. Para validarlo puedes escribir un post con un título determinado o bien acciones menos intrusivas como poner una determinada etiqueta de forma temporal en el código html de la página principal.

Una vez has sido validado tienes acceso a las promociones de las empresas. Bloguzz proporciona un rss con las promociones que las empresas quieren ofrecer, tu te anotas a las que te interesen y si la empresa te selecciona te envia el producto/servicio a cambio de que escribas un artículo sobre ello.

La verdad es que en principio dudo bastante de este tipo de modelos y en un blog de temática variada como el mio va a ser difícil que sea seleccionado para nada pero ya contaré…


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, …


Python Scripting for Students of Remote Sensing

Posted: octubre 2nd, 2011 | Author: | Filed under: General | Tags: , , , | No Comments »

Python Scripting for Students of Remote Sensing es un manual de python orientado a la teledetección. Si no sabes nada de python es mejor empezar por otro manual y luego saltar directamente al capítulo 5, “Plottin”. La parte de python en sí es muy básica y no está muy bien explicada. Del capítulo 5 al 10 se muestran algunas librerías interesantes de python para mostrar gráficos (matplotlib), para estadística y calculos científicos (numpy), para procesado de raster (gdal), o ejemplos sencillos de trabajo con datos lidar en ficheros ascii. La información que dan es bastante escueta, pero si ya conoces python en un par de horas puedes leerlo para hacerte una idea de que posibilidades hay en estos campos.

En la misma página se pueden encontrar otros manuales interesantes sobre teledetección.

Descubrí el curso gracias al comentario de José Guerrero.

 

 

 


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

1
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

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

1
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

Quien tiene la culpa de la crisis

Posted: julio 25th, 2011 | Author: | Filed under: General | Tags: , | 2 Comments »

Aviso antes de que sigas leyendo: Este artículo contine cierta dosis de demagogia, pero a veces hace falta llegar al extremo para saber donde está el centro.

Andrés publico hace poco un artículo, titulado los culpables de la deuda que dió pie a algo de debate en los comentarios de su blog y que hace que revisite algunas lecturas y descubra otras.

Gracias a esta pequeña investigación he descubierto que la culpa la tienen los gobiernos, ya sean los del psoe, o los del pp; los bancos, los endeudados, el capitalismo, … O en resumen, la culpa la tenemos todos. Queda a juício del lector que porcentaje de responsabilidad corresponde a cada cual, aunque yo creo que lo tengo más o menos claro.

Aunque lo que en realidad me preocupa no es quien tiene la culpa, si no quien la va a pagar.

Si debo escoger entre que la pague una familia que se queda en la calle o los responsables de la política económica de la entidad que hizo el prestamo, escogeré a quien tenga que vender el chalet de la playa para pagar su irresponsabilidad.

Si hay que decidir entre recortar la ayuda al desarrollo o suprimir el >presentar máquinas destinadas a matar como espectáculo para niños la decisión también la tengo clara…