Plugin de análisis de redes en gvSIG 1.x

Una pregunta habitual en las listas de correo de gvSIG es si hay alguna herramienta para realizar análisis de redes. En Cartolab hemos estado buscando enlaces a algunos recursos del plugin llamado «piloto de redes» que es el más empleado para estos análisis para poder compartirlos.

El plugin de piloto de redes (a veces también se lo llama «network extension«, «análisis de redes» o «extGraph«) es mantenido por Scolab y dispone de una página web en la forja de join-up, pero parece desactualizada.

 

Instalación

La última versión de este plugin es compatible con la versión 1.12 de gvSIG, y se puede instalar desde el administrador de complementos.

Herramientas -> Administrador de complementos -> Seleccionamos org.gvsig.graph y seguimos las instrucciones.

Resumen de uso

  1. Se carga una capa de líneas con los líneas conectadas, sin repetir y digitalizadas en el sentido de la circulación.
  2. Si queremos un análisis mas acertado deberíamos como mínimo un atributo donde esté definido el coste y otro en el que esté definido el sentido. El coste representa cuanto cuesta recorrer ese tramo en las unidades que nosotros queramos, distancia, tiempo,… En el campo sentido Asignamos un valor al sentido que se puede seguir por esa línea (el de la digitalización, ambos sentidos, contrario a la digitalización)
  3. A continuación vamos a Red->calcular topología de red que nos generará un fichero .net en el mismo direcotorio que la capa original con esa red. Aquí podemos decidir asignar cierta tolerancia a nuestra capa, por si los nodos no están perfectamente conectados,…
  4. En la siguiente pantalla, emparejamos los campos que nos solicitan. No es necesario rellenarlos todos. Si escogemos sentido le diremos que valor corresponde a de cada sentido posible.
  5. Cuando se carga la red nos preguntará por el campo que tiene un identificador para las geometrías, por ejemplo los nombres de las calles.
  6. Con la red cargada tenemos las opciones de introducir paradas, barreras o realizar los análisis. Las paradas se pueden administrar desde Red->Gestión de paradas. Son puntos de inicio, fin o de paso intermedio obligatorio de un cálculo de rutas. También se comportan como puntos a partir del cual determinar el equipamiento más cercano,… Las barreras son puntos por los que se impide el paso.
  7. Entre cálculo y cálculo recordar Red -> Borrar -> «Eliminar lo que nos interese»

Videotutoriales

  • Una serie de cuatro vídeos (unos 10, 15 minutos en total) con lo más básico del la extensión de redes para calcular rutas óptimas. Emplea la versión 1.1.2 de gvSIG pero permite ver lo más importante.
  • Vídeo de 6 minutos, demostrativo de varias de las funcionalidades de la extensión. . Cálculo de rutas. Matriz de distanticas y tiempos. Punto más cercano. Árbol de recubrimiento mínimo. Área de servicio. Está bien para de un vistazo saber todo lo que hace.

Manuales

Otros recursos

 

Libro: Mr Neighborly’s humble little ruby book

Estos días he estado leyendo el libro sobre ruby Mr Neighborly’s humble little ruby book. Aprovecho para hacer una pequeña reseña.

La razón de escoger este, es que es la primera referencia que aparece en la guía de inicio rápido de ruby on rails, y no quería invertir tiempo en buscar otra referencia. El libro se puede consultar de manera gratuita en html y pdf, aunque tiene una sección de donaciones. Está escrito en 2006 y usa ruby 1.8.5 con lo que algunas cosas pueden estar un poco desactualizadas. El pdf tiene 147 páginas pero de texto efectivo andará por las 130. Si te pasa como a mi, que algunos capítulos no te interesan mucho, se puede leer en unas 6 u 8 horas. El libro tiene un estilo desenfadado, con (malos) guiños cómicos al lector de tanto en tanto.

Entra de forma bastante rápida y práctica en temas de interés, sin perder demasiado tiempo en introducciones o aspectos muy básicos de oop o programación, habituales en este tipo de tutoriales. Desde luego es insuficiente para alguien sin experiencia previa, pero si conoces algún otro lenguaje dinámico como python, enseguida te ayuda a ver las mayores diferencias. De hecho a menudo hace comparaciones con otros lenguajes.

En el capítulo 4 hay una sección entera dedicada a la API de Windows, que para mi no tenía mayor interés, y otra sobre threads, que por ahora me llega con ojear.

El capítulo 5 está dedicado a lo que podríamos llamar networking (sockets, http, ftp, web services) y algo de base de datos. Si lo que buscas es conocimientos básicos de ruby para luego aprender rails, se puede saltar. Es mejor coger estos conceptos directamente a través de rails.

En el último capítulo habla un poco de testing lo cual está muy bien, porque tampoco es algo muy habitual.

Los dos anexos tampoco son de especial interés, y algunos de los enlaces que aparecen en ellos no funcionan.

En definitiva:

  • Se lee relativamente rápido
  • Si vienes de python te permite entender las mayores diferencias del lenguaje sin mucho problema
  • Seguramente hay cosas mejores por ahí

VII Jornadas de SIG Libre de Girona

Este año gracias a Cartolab he tenido la oportunidad de asistir de nuevo a las Jornadas de SIG Libre de Girona.

Como en años anteriores, el ambiente y la organización fueron magníficos. A pesar de que no había tanta gente como hace dos años, el compromiso de la comunidad geo con estas jornadas y el buen hacer del sigte hace que siempre merezca la pena ir.

Este año, desde cartolab, siguiendo la línea que tenemos para las jornadas de presentar contenidos formativos, análisis y cooperación para el desarrollo llevamos una comunicación sobre el Curso Online de SIG para Cooperación al Desarrollo , que ayudamos a elaborar el año pasado junto a Ingeniería Sin Fronteras, la empresa iCarto y el laboratorio de la USC, Laborate.

El eje de la presentación consistía en tratar de mostrar, como si bien las necesidades pueden ser iguales en los distintos territorios, las problemáticas que se daban en unos y en otros eran distintas. Por ejemplo la necesidad para la elaboración de un plan de ordenación territorial es igual en Galicia, que en Jinotega (Nicaragua), pero los problemas en Jinotega, donde sólo el 40% de las familias tiene una escritura de propiedad de la tierra, y sólo el 25% de las personas tiene algún tipo de ingreso , son distintos a los que nos encontraremos en Galicia. La presentación es algo minimalista pero si queréis más podéis anotaros al curso.

Mover un torrent de transmission a otro ordenador

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

 

Evidencias científicas sobre gestión pública o privada en sanidad

En Nada Es Gratis, han publicado una serie de artículos que tratan de informar sobre las evidencias científicas existentes a la hora de decidir entre modelos de gestión pública o privada para la sanidad.

Los artículos en cuestión son:

Trato de resumir dejando ideología aparte algunos de los temas que se mencionan en los artículos y extraigo algunos párrafos:

En españa no hay estudios que examinen esta problemática desde el ámbito científico.

Llegados a este punto, el lector avezado se preguntará qué modelo ha demostrado ser más ventajoso y en base a qué variables presupuestarias y de calidad asistencial (el balance coste-efectividad) se ha evaluado la bondad de los modelos o, cuando menos, cuáles son las fortalezas y la debilidades detectadas en cada uno de ellos. La respuesta, como el lector tristemente imagina, es que no se han evaluado

Los estudios que se han realizado en otros países no permiten llegar a conclusiones sobre que es más eficiente. Existiendo un montón de fórmulas distintas y de factores que pueden influír.

Resulta amargo constatar que para obtener algún conocimiento sobre la cuestión debemos recurrir a la literatura internacional. La principal conclusión de la reciente experiencia británica, bandera en experimentos de colaboración público privada, es que la gestión privada de los servicios sanitarios no es necesariamente mejor que la gestión pública…ni al contrario. Factores tales como el entorno administrativo e institucional, la cultura de los centros, las condiciones de los contratos y la adecuada supervisión por parte del financiador de la calidad del servicio prestado son los elementos a tener en cuenta cuando se analizan estos casos

El fomento de la competitividad entre los centros suele tener resultados positivos.

No se trata ni de competir en precios (sacrificando las calidades que el usuario no percibe) ni de realizar experimentos a prueba de fallos, por el interés del promotor político en que luzcan bien, sino de ir introduciendo la idea de que los recursos que una organización sanitaria reciba dependerán, de entrada en una mínima parte, de la calidad que ofrezca en relación a sus comparables.

Son necesarias reformas en el sistema de salud, sobre todo para fomentar la transparencia y la rendición de cuentas.

Algunos de los aspectos más indeseables del actual gobierno sanitario (escasa rendición de cuentas, opacidad de funcionamiento y formas peculiares de participación) pueden rastrearse en los orígenes totalitarios de la génesis de nuestro sistema de salud; otros, aunque comparten origen, parecen haberse exacerbado durante la andadura constitucional, especialmente desde la culminación del proceso transferencial en el año 2002.

Las soluciones sobre el papel están al alcance de cualquier persona informada. Su implantación requiere el abordaje conjunto de todos los déficits, no solo los presupuestarios o los exteriores, sino también los de legitimidad y transparencia. España tiene un problema con su gestión pública. Y la mejor literatura sobre desarrollo lo corrobora: Será muy difícil mejorar la gestión pública o introducir reformas sanitarias que mejoren de forma apreciable nuestra productividad sin una mejor calidad de la política y de las instituciones que la están condicionando. Esto se facilita con un fomento de la transparencia y el acceso público a las bases de datos de la administración. La Central de Resultados en Cataluña marca un buen precedente.

La fórmula de PFI (financiación privada de la infraestructura a cambio de concesiones) no está funcionando

Se dispone de cierta evidencia empírica en relación al uso de fórmulas PFI en el Reino Unido y en Italia. Una primera conclusión es que estas formas de colaboración suponen a la postre un coste total superior al que resultaría de recurrir al endeudamiento público directo para construir la nueva infraestructura sanitaria, debido, principalmente, a los mayores costes financieros a los que se enfrentan los concesionarios privados y al margen de beneficio de estos.

La evidencia disponible acerca de las fórmulas de concesión de obra pública (PFI) a escala internacional sugiere que estas fórmulas pueden dar lugar a problemas financieros motivados por unos mayores costes de financiación (Reino Unido), así como a disfunciones asociadas a restricciones en la competencia en el mercado y subsiguientes efectos sobre la equidad (Italia). La escasa información que para el caso español trasciende a los medios de comunicación no es más alentadora, por lo que no parece que se justifique el recurso a esta modalidad de concesión más que con el fin de sacar fuera del cómputo del déficit público los costes ocasionados por las nuevas infraestructuras sanitarias (o, en la coyuntura actual, por la voluntad de construir centros hospitalarios cuya financiación no puede abordarse a través de una vía prácticamente vedada como es la del endeudamiento público).

El modelo de concesión para la gestión integral (modelo Alzira) tampoco parece estar funcionando.

Integrando las correcciones de extCAD en OpenCADTools

He estado trabajando en integrar todas las correcciones que se hicieron en la extensión oficial de CAD para gvSIG, desde el nacimiento de  OpenCADTools en las propias opencadtools. Este artículo describe:

  • Como se realizó el proceso de integración para ver de donde pueden venir errores futuros y la extraña apariencia que tiene el repositorio actual.
  • Contar el método seguido en sí por si resulta útil a gente que tenga que hacer algo parecido.

Debo agradecer al Cartolab el que me haya cedido horas de mi trabajo diario para poder escribir este artículo y realizar la integración en si misma. Además, debo agradecer a los organizadores del codesprint de Münich por financiar mi estancia allí y a los participantes por las aportaciones recibidas.

El problema

Tenemos tres repositorios svn con código parecido pero no igual:

  • gvSIG. Contiene entre otras muchas cosas el proyecto extCAD. Se trata del código base con commits desde 2005 hasta la actualidad
  • gisEIEL. A partir del año 2006 la Universidade da Coruña, a través de un convenio con la Diputación de A Coruña, realizó un fork de las herramientas de CAD de la versión 0.x de gvSIG. Este desarrollo fue asignado al Laboratorio de Bases de Datos de dicha universidad. En su repositorio actual sólo está el resultado final del fork, no los commits intermedios, porque lo que no se pueden comparar los logs para hacer una integración de código más ordenada.
  • OpenCADTools. A partir de 2009, con financiación de la Diputación de Pontevedra y en el marco de los trabajos de desarollo de gvSIG-EIEL Cartolab hizo una integración del código de gisEIEL con el de gvSIG adaptando todo ello primero a la versión 1.1.2 de gvSIG y luego a la 1.9. Se dispone de todo el historial desde el principio hasta la actualidad. Posteriormente Cartolab continuo el desarrollo de las OpenCADTools como un proyecto propio.

Lo que queremos ahora es:

  1. Obtener las mejoras realizadas en los tres proyectos desde que evolucionaron por separado para obtener una extensión de CAD mucho más potente. Nos concentraremos en el código de gvSIG y el de OpenCADTools por ser los que más desarrollo han tenido y estar ambos adaptados a la rama 1.9 de gvSIG, mientras que gisEIEL continua en versiones más antiguas. Emplearemos el proyecto de gisEIEL sólo para consultar dudas de autoría o Copyright.
  2. Es fundamental respetar lo máximo posible la historia de commits. Debemos saber cuando se integró un cambio, por qué, y quien lo hizo. Esto nos permitirá prevenir errores futuros.
  3. Es fundamental respetar lo máximo posible la autoría y el copyright de todas las modificaciones.
  4. Nuestra meta final es además que el código resultante pueda ser integrado en el proyecto gvSIG, por tanto nuestra base debe ser el código de extCAD, y las mejoras de OpenCADTools deben poder ser introducidas en forma de parches sobre extCAD.

Para ello necesitamos poder comparar de forma sencilla estos tres repositorios. Dada la cantidad de commits que ha habido y la divergencia existente resulta muy complicado comparar los logs o encontrar un punto común. Haremos por tanto un análisis inicial clase a clase que nos permita ver el grueso de las diferencias y tomar decisiones.

Análisis clase a clase

  • Montamos un repositorio local de git que contenga en ramas separadas el código de cada proyecto.
  • Obtenemos un fichero de texto all_files.txt con todas los ficheros que hay (sin repetir) estén en una rama u otra. Haremos el listado de ficheros de cada rama mediante tree, y compararemos los ficheros con meld para incluír rapidamente los ficheros que están en una y no en otra en el fichero all_files.txt

    git checkout heads/extcad
    tree -fi --noreport > extcad_files.txt
    git checkout heads/opencadtools
    tree -fi --noreport > opencadtools_files.txt
    cp opencadtools_files.txt all_files.txt
  • Hacemos un script muy sencillo que mete un carácter = antes de cada línea de un fichero checked_files.txt para todos aquellos ficheros que no hayan variado.
  • Sobre el fichero checked_files.txt marcamos con una x aquellos ficheros que sabemos que no es necesario que comprobemos, por ejemplo el directorio install de OpenCADTools que con el nuevo sistema de paquetes de gvSIG está obsoleta. Algunos de estos ficheros serán eliminados a posteriori
  • Los ficheros distintos los revisaremos uno a uno con algo como esto:

    fileToCheck=./src/com/iver/cit/gvsig/CADExtension.java
    git diff master:$fileToCheck refs/heads/opencadtools:$fileToCheck

    La variable fileToCheck la rellenamos con un copy&paste desde checked_files.txt. Y vamos marcando en el fichero de checked_files.txt con una m aquellos en las que la «versión más correcta» sea la del trunk de gvSIG. A veces el cambio es simplemente una cabecera, indentado, …

Este proceso aunque algo tedioso nos permite hacernos una imagen mental del estado de los repositorios lo que aumentará nuestra capacidad para tomar decisiones.

Primera fase de la de integración

En el caso de OpenCADTools fue sencillo encontrar el punto en que se completo la migración de las herramientas desde la versión 1.1.2 de gvSIG a la 1.9. Perder el histórico de la migración no era grave y nos permitía simplificar el proceso, así que lo que se decidió fue escoger el commit en que esa migración se consideraba finalizaday volcar todo el repo de OpenCADTools en ese punto sobre el de extCAD.


# En un repo con sólo OpenCADTools, hacemos
$ git checkout -b ultimoMigracion
# 0f517d66 = commit de interés, del 14 de Septiembre con mensaje "Updated StartEditing from gvSIG 1.9"
$ git reset --hard 0f517d66
# y sobre nuestro repo de trabajo:
cp -r $repoOpenCadTools .

A continuación vamos descartando todos los ficheros en los que sepamos que el contenido del master es más válido, los marcados como m en la fase anterior:

git checkout -- los_ficheros_donde_prefiramos_el_master

Nuestros lectores más hábiles en el uso de git se habrán dado cuenta, de que podríamos hacer el análisis de los ficheros tipo m directamente en este paso, pero como ya comentamos, hacerlo del otro modo nos permite afianzar nuestro conocimiento de los repositorios.

Segunda fase de la integración

Ahora tendremos en nuestro repo ficheros nuevos y ficheros modificados.

Los ficheros nuevos son todos ellos nuevas herramientas cuyas clases pueden ser agrupadas. Así que vamos comiteándolos aprovechando para revisar las cabeceras y las autorías. Resulta sencillo identificar si una de estas nuevas clases fue desarrollada inicialmente por el Laboratorio de Bases de Datos y adaptada con posterioridad por Cartolab, o fue creada directamente por Cartolab. Basta comprobar si existe o no en el repositorio de gisEIEL. En general los autores concretos de cada clase o quienes la adaptaron están también idendificados en el código fuente, cuando esto no es así lo que se ha hecho ha sido poner de forma genérica «Laboratorio de Bases de Datos» y/o «Cartolab». La autoría se ha reflejado mediante anotaciones @author en el código fuente de las clases

De este modo vamos haciendo commits para las herramientas y dado que es git empleamos la opción –author para reflejar quien hizo el commit original en el repo de OpenCADTools (al menos de forma aproximada)

Los ficheros modificados en este caso son pocos, por lo que permite tomar decisiones de forma individual.

Tercera fase de la integración

Probablemete la fase más complicada. Nos toca integrar los 143 commits que hubo en OpenCADTools desde el que tomamos como referencia hasta el último commit previo a la integración.

Tras varias pruebas y sin encontrar una forma rápida y segura de integrar esos commits se optó por generar parches e ir integrándolos uno. En algunos casos hubo que retocar los parches o los ficheros a mano puesto que no se integraban correctamente.

Cuarta fase de la integración

Toca limar algunas aspectos, por ejemplo:

  • El nombre de los commiters, para lo que se emplea este script
  • Comprobar que podemos exportar lo que tenemos a un repositorio vacio de git (pasos 7 a 9)

Además se hace testeo funcional de las herramientas de CAD para encontrar posibles problemas en la integración y resolver los bugs que se deriven de ella.

Conclusiones

Dada la disparidad de la evolución de los repositorios el proceso fue tedioso. Pero ahora tenemos un repositorio git actualizado a los últimos cambios de las herramientas por defecto de gvSIG y de las opencadtools. Esto nos permite trazar el origen de algunos bugs, y realizar integración de parches en ambos sentidos, así que merece la pena.

Science fiction has always been about the present, not the future

No os perdais la interpretación que hace Andrés del libro Bobedas de Acero.

Ayer mismo un par de noticias inconexas hacían que yo recordara La era del diamante, y es que, en palabras de Pat Cadigan.

Science fiction has always been about the present, not the future, It’s a reflection of what we think about our time.

 

La era del diamante ¿Ciencia Ficción?

Para aquellos a los que La era de diamante les parecía simplemente un libro más de ciencia ficción un par de enlaces de estos días. A los que no lo hayan leido puede que les falte un poco de contexto, pero los enlaces siguen siendo interesantes…

El manual ilustrado para jovencitas

Las ideas del propio Stephenson, Asimov o Robinson comienzan a materializarse, tanto en software como en hardware

Formas de autoaprendizaje masivas…

…o la revolución de los mooc.

La toma…

…o como imprimirte tus muebles en casa.

Canciones de Karaoke a partir de vídeos del Youtube

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.

Relacionando las inmersiones por Duncan Green con los PCR de ISF

Acabo de leer un artículo de Duncan Green hablando de la importancia de las «inmersiones» (pasar periodos de tiempo conviviendo directamente con los beneficiarios) en Cooperación para el Desarrollo.

Estoy de acuerdo con las líneas generales del artículo, pero me gustaría hacer algunos comentarios, a partir de la experiencia de Ingeniería Sin Fronteras con los Programas de Conocimiento de la Realidad y los propios comentarios al artículo original.

Los tiempos propuestos, de alrededor de una semana, son escasos. De hecho una de las críticas que se hacen a las inmersiones es la de creerse que por estar un par de días (o semanas) viviendo con gente empobrecida vas a conocer realmente sus necesidades. La contracrítica pasa por dos puntos:

  • Aumentar el tiempo de estancia. ISF fija el programa en dos meses, con aproximadamente una semana de convivencia directa. Un periodo de tiempo que tal vez debería ser revisado, siempre teniendo mucho cuidado en no sobrecargar a la familia de acogida, o quizás aumentándolo a dos semanas con dos familias distintas.
  • Fortalecer la formación y las herramientas para comprender el peligro de una sóla historia. Sea la de la televisión, o la de la familia con la que convives.

Otra de las críticas al artículo es que las inmersiones no dan voz a quien lo necesita, o más bien, el objetivo debería ser how we can build long-term partnerships with people in poverty. La contrapropuesta pasaría por no contemplar la inmersión como un fin en si mismo, si no como una actividad importante dentro de una estrategía más global. Este punto da para un par de nuevos artículos, pero en resumen se trataría de como conseguir que, beneficiarios, socios locales, voluntarios, donantes y decisores políticos llegaran a relacionarse entre sí como stakeholders (perdón por el palabro) y no mediante las relaciones jerárquicas más habituales. En esta lína ISF lleva a cabo varias acciones:

  • Acercar a la gente que conoces durante el PCR, mediante entrevistas, vídeos, … Por ahora se está haciendo de forma poco organizada, pero podría incluirse dentro de la estrategia de comunicación.
  • Se empiezan a realizar skypes periódicos de los grupos de voluntarios con los socios locales, con los beneficiarios es más complicado, ara aumentar las relaciones de confianza.
  • Los PCR cuando están en terreno, su fuente de contacto principal son los socios locales y no la persona expatriada de la asociación.

¿Cómo hacer que sea realmente provechosa para el individuo?. ¿Cómo hacer que sea provechosa para la organización?. Para que sea provechosa para la persona, como se dijo antes, el proceso de selección y formación de la persona escogida para participar en una inmersión debe ser riguroso. Para que sea beneficioso para la organización deben establecerse mecanismos formales que permitan reaprovechar lo que la persona aprende. Esta posiblemente es una de las partes menos trabajadas en ISF, por ahora se queda en un compromiso del PCR de colaborar por un periodo de tiempo con la organización tras su estancia.