Sincronizando datos: rsync (1)

Hace bien poco he conseguido algo que tenía ganas de hacer desde hace bastante tiempo: sincronizar fácilmente mi ordenador de trabajo con un servidor que monté en el curro para diversas cosas (página web, bases de datos varias, archivo de bibliografía). ¿El secreto? Un pequeño programa llamado rsync.

Un requisito era que el sistema tenía que ser sencillo, no comercial, libre e incluido en los sistemas UNIX con los que trabajo: MacOS X y Linux (Ubuntu). Rsync está también disponible para Windows, por supuesto.

La situación es ésta: la máquina con Linux es el servidor del que hablaba. Tiene un directorio llamado biblioteca con varios subdirectorios, donde mantengo una selección de documentos (casi todos PDF) a disposición del grupo de investigación: Congresos y simposios (copias de proceedings, abstracts sueltos, etc.), Libros y Tesis (eso mismo), Separatas (artículos científicos procedentes de revistas, casi todas peer-reviewed) y Otros (patentes, legislación y miscelánea). A propósito, directorio es más conocido como carpeta, así que utilizaré esa denominación.

Hasta ahora, mantenía todo esto organizado a mi gusto en mi ordenador personal, pero la necesidad de compartirlo con el resto del grupo me llevó a tener que resolver un problema: ¿cómo actualizar la copia del servidor cada vez que actualizaba mi copia personal? Desde luego, replicar los cambios era imposible (son más de 7 GB, con más de 20000 PDF y otros tantos ítems diversos). Copiar los 7 GB completos, posible con un disco duro portátil, demasiado lento por red. Obviamente, conociendo las posibilidades de hacer una sincronización que transmitiese sólo aquellos elementos nuevos o modificados, me puse a buscar la manera. Tardé poco, ya que ya había hecho algo similar en el pasado para realizar copias de seguridad de otro servidor (aunque esa vez, a un disco duro externo conectado por USB). Rsync sería mi elección.

Hay varias páginas donde se puede obtener información sobre rsync (ejemplo), posiblemente mucho mejor explicado que aquí. Yo voy a describir cómo lo hice, por si alguien quiere hacer algo similar.

En primer lugar, rsync en su modo más básico simplemente compara un grupo de archivos con otro, y copia sólo aquello que ha cambiado. Haciendo una comparación con el "arrastrar para copiar" entre ventanas, es básicamente lo que ocurre cuando arrastramos un grupo de archivos de una carpeta a otra y el sistema copia aquellos que no existen en el destino, preguntando si debe sobreescribir aquellos que tienen el mismo nombre. En esa situación, nosotros miraríamos si la fecha de modificación de los archivos y su tamaño son distintos, y, sólo en ese caso, aceptaríamos la copia. Eso es lo que hace Rsync, sólo que automáticamente, si escribimos algo como:

rsync /myuser/mydata/ /myuser/mydata_copy

Rsyinc compara los archivos de la carpeta mydata con los de mydata_copy y copia los archivos de mydata que no existen en mydata_copy, y aquellos que sí existen pero que tienen distinta fecha de modificación o distinto tamaño. Aquellos archivos que no cumplan esas condiciones no se tocan, por lo que el proceso es muchísimo más rápido que una simple copia, especialmente si hay muchos archivos y se modifican raramente.

Sin embargo, rsync tal cual es muy limitado. Por ejemplo, si un archivo ha sido borrado de mydata, no desaparece de mydata_copy (se supone que quiero sincronizar, es decir, al final ambas capetas deben tener la misma información). Si hay subcarpetas, resulta que sus contenidos no se tienen en cuenta (si creo una subcarpeta en mydata y la lleno con archivos, en mydata_copy aparecerá esa subcarpeta... vacía). Además, las fechas y horas de modificación de los archivos sincronizados cambian a la hora en la que se realizó esa sincronización (igual que otros parámetros del archivo). Obviamente, rsync "tal cual" no me vale para mi propósito, hay que darle algunas órdenes, pero lo dejo para otra entrada.

Os dejo algunos enlaces por si queréis irlo descubriendo vosotros mismos:
rsync web pages
Página de manual de rsync
rsync en la Wikipedia
Algunos ejemplos del uso de rsync

CVN: Only output

Hoy he echado otro vistazo a la página sobre el CV normalizado (CVN). ¡Esto marcha! En breve, parece que tendremos por fin un CV que podremos compartir con cuantas administraciones públicas y tal vez con alguna privada. El "secreto" está en el uso de XML para compartir los datos, lo cual lleva tiempo usándose con gran éxito, por cierto.

Claro, que en la lista de partipantes no están todos los que deberían estar, ni mucho menos. Parece ser que sólo los que utilizan SICA, liderados por la Junta de Andalucía. De universidades, sólo un puñado (las andaluzas, bien por ellos). No está la de León, con su Universitas XXI tan poco amigable y con paradas para mantenimiento cada dos por tres (en la UCLM teníamos otro sistema bastante cutre, pero por lo menos era sencillo, espartano, efectivo y nunca lo vi caído). Pero, al menos, parece que la U. de León tiene una opción para importar un CVN procedente de SICA. Afortunados los que lo puedan usar.

La gran sorpresa es que en la lista de instituciones aparecen todas como con capacidad para exportar el CVN... pero ninguna con capacidad para importarlo. ¿Alguien me lo explica?

En fin, esperemos que cunda el ejemplo y que todos los sistemas de gestión de la investigación que nos toca sufrir lo incorporen pero ya mismo. Es difícil entender cómo se puede pretender que la gente introduzca los ítems de su CV a base de formularios, cuando cada ítem comprende por lo general más de una docena de elementos, y un buen CV incluye decenas, cuando no cientos de ítems. Uno sólo tiene que mirar en la web para encontrar sitios que te permiten subir tu CV automáticamente (reconocimiento de campos) o buscar directamente en sitios como Pubmed, importando todos los datos de publicaciones y elementos similares. La tecnología está ahí, ¿por qué no se usa?

A propósito, no veo ni en Universitas, ni en SICA, ni en el Portal de Investigación de la UCLM que haya software libre por ningún lado. Siendo algo promovido y pagado por lo público, bien podría tener esa condición. Estoy seguro de que un montón de desarrolladores estarían felices de desarrollar un sistema libre de gestión de la investigación. A propósito, ¿es el CVN libre?

Pego aquí la lista, con su misterioso Importa: NO.

Instituciones adaptadas al estándar CVN

El siguiente listado muestra las instituciones que ya permiten a sus investigadores disponer de un currículum en formato CVN-XML.

Institución o entidad	Sistema	Exporta	Importa
JUNTA DE ANDALUCÍA	SICA	SI	NO
UNIVERSIDAD DE SEVILLA	SICA	SI	NO
UNIVERSIDAD DE GRANADA	SICA	SI	NO
UNIVERSIDAD DE CÓRDOBA	SICA	SI	NO
UNIVERSIDAD PABLO DE OLAVIDE	SICA	SI	NO
UNIVERSIDAD DE CÁDIZ	SICA	SI	NO
UNIVERSIDAD DE HUELVA	SICA	SI	NO
UNIVERSIDAD DE JAÉN	SICA	SI	NO
UNIVERSIDAD DE ALMERÍA	SICA	SI	NO
UNIVERSIDAD DE MÁLAGA	SICA	SI	NO
UNIVERSIDAD INTERNACIONAL DE ANDALUCIA	SICA	SI	NO
SERVICIO ANDALUZ DE SALUD	SICA	SI	NO
FUNDACIÓN HOSPITAL REINA SOFÍA-CAJASUR	SICA	SI	NO
ASOCIACIÓN SANITARIA VIRGEN MACARENA	SICA	SI	NO
EMPRESA PÚBLICA HOSPITAL DE LA COSTA DEL SOL	SICA	SI	NO
ESCUELA ANDALUZA DE SALUD PÚBLICA	SICA	SI	NO
INSTITUTO ANDALUZ DE CIENCIAS DE LA TIERRA (IACT)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE PARASITOLOGIA Y BIOMEDICINA LOPEZ NEYRA (IPBLN)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE MICROELECTRONICA DE SEVILLA (IMS-CNM)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE LA GRASA (IG)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE ESTUDIOS SOCIALES AVANZADOS DE ANDALUCIA (IESAA)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE CIENCIAS MARINAS DE ANDALUCIA (ICMAN)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE RECURSOS NATURALES Y AGROBIOLOGIA SEVILLA (IRNAS)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
CENTRO ANDALUZ DE BIOLOGIA DEL DESARROLLO (CABD)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
CENTRO DE INVESTIGACIONES CIENTIFICAS ISLA DE LA CARTUJA (Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
ESCUELA DE ESTUDIOS ARABES (EEA)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
ESCUELA DE ESTUDIOS HISPANO-AMERICANOS (EEHA)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
ESTACION BIOLOGICA DE DOÑANA (EBD)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
ESTACION EXPERIMENTAL DE ZONAS ARIDAS (EEZA)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
ESTACION EXPERIMENTAL DEL ZAIDIN (EEZ)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE AGRICULTURA SOSTENIBLE (IAS)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
ESTACION EXPERIMENTAL LA MAYORA (EELM)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTO DE ASTROFISICA DE ANDALUCIA (IAA)(Delegación del C.S.I.C.en Andalucía)	SICA	SI	NO
INSTITUTOS Y CENTROS DE INVESTIGACIÓN Y CULTURA	SICA	SI	NO
INSTITUTO DE INVESTIGACIÓN Y FORMACIÓN AGRARIA, PESQUERA, ALIMENTARIA Y DE LA PRODUCCIÓN ECOLÓGICA	SICA	SI	NO
INSTITUTO ESPAÑOL DE OCEANOGRAFÍA	SICA	SI	NO
FUNDACIÓN CENTRO DE ESTUDIOS ANDALUCES	SICA	SI	NO
FUNDACIÓN HOSPITAL CARLOS HAYA	SICA	SI	NO
FUNDACION INSTITUTO MEDITERRÁNEO PARA EL AVANCE DE LA TECNOLOGÍA Y LA INVESTIGACIÓN SANITARIA	SICA	SI	NO
FUNDACIÓN NEFROLÓGICA	SICA	SI	NO
FUNDACIÓN PARA LA INVESTIGACIÓN PUERTA DEL MAR	SICA	SI	NO
FUNDACIÓN REINA MERCEDES PARA INVESTIGACIÓN SANITARIA	SICA	SI	NO
FUNDACIÓN VALME	SICA	SI	NO
FUNDACIÓN VÍRGEN DE LAS NIEVES	SICA	SI	NO
ASOCIACIÓN PROFESIONAL DE ATENCIÓN PRIMARIA PARA ACTIVIDADES CIENTÍFICAS	SICA	SI	NO

Totalmente out

Abandonado tengo el blog. Entre la escritura/corrección/revisión de manuscritos, el diseño de nuevos experimentos, la dirección de doctorandos, los cursos de perfeccionamiento docente, mis aventuras precarias y una estudiante de biología experimentando sus primeros pasos en la investigación, estoy más que ocupado.

Espero poderme organizar un poco en breve, que hay muchas cosas sobre las que me gustaría escribir.

Un truco para Gmail (acceso POP3)

Este es un truco que he encontrado para resolver un problema con el acceso POP a las cuentas de Gmail (es decir, para descargar los correos en un cliente como Thunderbird). Este servicio funciona bastante bien, pero tiene el pequeño inconveniente de que los mensajes enviados a uno mismo no se descargan, aunque aparecen en Recibidos al acceder vía web en la cuenta de Gmail.

Esto se debe a que Gmail considera como un único mensaje a la copia enviada (que permanece en la carpeta Enviados) y a la que se recibe. Por tanto, no descarga el mensaje recibido. Este mecanismo sirve para evitar la descarga duplicada de algunos mensajes, pero interfiere en ciertos casos en los que esa descarga sería deseable.

El caso más importante es cuando se utiliza la cuenta de Gmail para participar en listas de distribución de correos. Si bien la gestión de hilos de Gmail es muy eficaz, prefiero descargar los mensajes en Thunderbird y utilizar su sistema de visualización de hilos. En este caso, es deseable que los mensajes que uno envía a la lista de correo se descarguen y aparezcan en los hilos. Sin embargo, no sucede así.

Hay varias soluciones poco satisfactorias. Thunderbird permite realizar una copia automática cuando se responde a un mensaje, que aparece en la misma carpeta del mensaje al que se responde. Sin embargo, no sucede esto cuando se escribe un mensaje directamente a la lista, abriendo un nuevo hilo. También se puede solucionar accediendo a la cuenta mendiante IMAP y clasificando los mensajes mediante etiquetas en la misma cuenta de Gmail. Sin embargo, muchas veces IMAP plantea muchos problemas (lentitud de acceso, al eliminar o mover mensajes), sobre todo si se accede a varias listas de correo y se reciben muchos mensajes, siendo preferible usar POP. Esta es una cuestión que depende de preferencias individuales. En mi caso, accedo a mi cuenta general mediante IMAP, pero las listas de correo las gestiono mediante otra cuenta, a la que accedo mediante POP. He probado a gestionar todo mediante IMAP, pero este sistema ha resultado ser el más eficaz para mis necesidades.

Finalmente, encontré una manera para, usando POP, poder descargar también los mensajes dirigidos a la misma cuenta desde donde se envían, gracias a un hilo que encontré en los foros de ayuda de Gmail. Se basa en activar el llamado "modo reciente" en la configuración de la cuenta en el cliente de correo. Este modo está pensado para acceder al correo mediante distintos clientes, especialmente en dispositivos móviles, de manera que los mensajes puedan descargarse en todos los clientes. De otro modo, los mensajes quedarían marcados tras la primera descarga, y no estarían disponibles para subsiguientes descargas en otros clientes. Curiosamente, en este modo todos los mensajes pueden ser descargados, incluso aquellos mensajes mandados a uno mismo.

Para activar este modo, basta con preceder el nombre de usuario en la configuración POP por recent:. Así, en vez de:
pepito.grillo@gmail.com
pondremos:
recent:pepito.grillo@gmail.com

Un efecto secundario es que la próxima vez que descarguemos los mensajes, se bajarán todos aquellos recibidos en los últimos 30 días, incluso aunque los hayamos bajado ya anteriormente. Esto ocurrirá sólo una vez para cada cliente de e-mail. En Thunderbird podemos solucionarlo, por ejemplo, haciendo una búsqueda con la condición "Estado-no es-Leído", y borrando los mensajes encontrados (suponiendo que los mensajes anteriores figuren como leídos). Sin embargo, una vez solucionado este problema, los mensajes enviados a uno mismo se descargarán correctamente.

Resulta aconsejable activar la opción del cliente para dejar los mensajes en el servidor (en vez de borrarlos una vez descargados). Aunque esto no sería imprescindible si descargamos el correo en un único cliente, resulta muy conveniente, ya que permite tener todos los mensajes disponibles al acceder por web a Gmail. Teniendo en cuenta el límite de cuenta de Gmail, no es ningún problema tener un montón de mensajes almacenados en el servidor.

A disfrutar de la combinación Gmail-POP-listas de correo sin problemas.

Google Docs en la investigación

¿Cómo aprovechar las oportunidades de la Web 2.0 en el trabajo diario de un grupo de investigación? Aquí voy a tratar de las aplicaciones ofimáticas web, poniendo como ejemplo Google Docs. Por citar otra gente que ya a realizado este experimento, enlazo a un par de artículos de Roke, que me queda a mano. He aquí un buen ejemplo práctico de uso de Google Docs en docencia, y una estupenda idea, que desafortunadamente Roke no pudo llevar a cabo (¿todo se andará?). Primero voy a describir rápidamente lo que se puede hacer con Google Docs, y luego pondré algunos ejemplos de su uso en un grupo de investigación. Por si os interesa ahondar en las posibilidades de estas aplicaciones, siempre podéis echar un vistazo al blog de Google Docs.

Google Docs (a partir de ahora, GDocs) es una suite ofimática gratuíta que permite producir documentos de texto, hojas de cálculo y presentaciones. La particularidad de estas aplicaciones es que se ejecutan vía web, en el navegador del usuario. Los documentos se guardan realmente en los servidores de Google, no en el ordenador del usuario (pero... ver más abajo). Como no me voy a dedicar a describir sus funcionalidades al detalle, os dejo un enlace a un breve tutorial. Hay otras suites ofimáticas gratuítas con funcionalidades similares (en algunos casos más avanzadas), como Zoho o ThinkFree, y que se podrían utilizar con los mismos fines, pero, de momento, prefiero GDocs por su rapidez y simplicidad. Os enlazo a una de las muchas comparativas sobre este tipo de aplicaciones, donde se describen algunos pros y contras de cada uno.

¿Qué puede aportar un sistema como GDocs a un grupo de investigación? Si bien cada usuario puede tener sus propias aplicaciones ofimáticas en su ordenador (eh, ¿ya has echado un vistazo a OpenOffice?), los distintos miembros pueden realizar parte del trabajo en GDocs, aprovechando las ventajas colaborativas que ofrece.

La primera ventaja de GDocs es su universalidad. Cualquiera puede crearse una cuenta gratuita en GDocs, con sólo tener una cuenta de e-mail. De hecho, si tienes una cuenta de Gmail puedes acceder sin más a GDocs. Una vez activada la cuenta, el único requisito para usar las aplicaciones es tener un navegador web compatible, siendo independiente del sistema operativo o aplicaciones instaladas en el ordenador. GDocs permite exportar los documentos en numerosos formatos (PDF, MS Office, el estándar ISO OpenDocument).

La segunda razón para usarlo es su simplicidad. Las aplicaciones de GDocs son relativamente simples si las comparamos con las aplicaciones ofimáticas típicas, y no permiten crear documentos complejos. Sin embargo, esto es una ventaja, ya que permite un aprendizaje relativamente rápido y facilita el concentrarse en el contenido, y no tanto en el formato. Además, esto se traduce en que, en general, GDocs vaya bastante ligero. Una vez acabado el trabajo, lo podemos descargar en nuestro ordenador y formatearlo a nuestro gusto.

Sin embargo, el auténtico poder de las aplicaciones web reside en las posibilidades de colaboración entre miembros de un grupo. Todo documento puede compartirse con otros usuarios de GDocs. Esto supone que varios usuarios puedan editar un documento sin tener que mandárselo unos a otros. Se acabó el lío de versiones, de e-mails sin adjunto, o con el adjunto equivocado. Los documentos corregidos por distintos revisores, en los que hay que casar las revisiones de cada uno... no hay problema, el documento se comparte y la edición múltiple o la edición y revisión simultáneas se hacen realidad. Una vez compartido un documento, los colegas lo verán aparecer en su listado de documentos de GDocs, junto con una lista de los usuarios con los que están compartiéndolo. Cualquier cambio realizado al documento se verá inmediatamente reflejado en las cuentas de los otros usuarios, y si entramos en un documento que está siendo utilizado por otro, veremos un aviso informándonos qué usuarios están realizando cambios en él.

Además, cada documento cuenta con un historial de revisiones. Cada vez que se guarda un documento (lo cual ocurre automáticamente cada pocos minutos), se crea una entrada en este historial, permitiendo saber el momento y quién lo editó. Se puede volver a una versión anterior, así como comparar dos versiones (los cambios de cada editor aparecen con colores distintos).


Por supuesto, GDocs permite también enviar el documento por e-mail (directamente desde el navegador), o mandar mensajes a los colaboradores, todo con un par de clicks. Se echa de menos alguna característica más, como un chat integrado en el documento (para discutir con los colaboradores mientras se edita), pero siempre se puede echar mano de otras herramientas (y no olvidemos que Gmail permite chatear con otros usuarios via web).

Recientemente, GDocs se integró con Google Gears, un proyecto que permite que las aplicaciones web interaccionen con el ordenador en el que se están ejecutando. Esto ha dotado a GDocs de un modo offline, de tal manera que una copia de los documentos queda guardada localmente, en el ordenador del usuario. Esto puede ayudar a mucha gente a sentirse más segura trabajando con este sistema, sabiendo que sus documentos están en su propio ordenador. No obstante, se trata de un cambio de mentalidad, ya que lo más seguro es almacenar los documento en varios servidores remotos, lo cual los pone a salvo incluso de catástrofes naturales (y esto es lo que hace automáticamente GDocs).

Como se ve, la mayor ventaja de este sistema es la posibilidad de compartir documentos y editarlos, reflejándose los cambios en las cuentas de los otros usuarios sin necesidad de enviar los documentos activamente. Se acabó el que varias personas estén trabajando en el mismo documento y que unos tengan que esperar a que otros acaben para contribuir al documento. Además, el control de versiones se hace mucho más eficaz. Por supuesto, esta no es una solución universal para los grupos de investigación, que podrían requerir herramientas más potentes. Sin embargo, para muchas aplicaciones podría ser más que suficiente.

Por ejemplo, en mi caso yo lo utilizo para crear protocolos experimentales. Al crear un nuevo protocolo, ya compartido con mis compañeros de grupo, generalmente hago una copia de otro ya creado e indico que quiero copiar los colaboradores. De esta manera, mis colegas encuentran un nuevo protocolo en sus cuentas, y pueden empezar a colaborar inmediatamente.

El resultado es que los protocolos utilizados por el grupo (incluyendo formularios, notas técnicas, etc.) están disponibles para todos por igual. Se acabó el que medio grupo esté utilizando un protocolo desfasado creyendo que es la copia buena. Además, los protocolos y los diseños experimentales pueden prepararse realmente entre todos: alguien puede estar preparando un protocolo muy lejos del laboratorio y no saber el número de catálogo de un reactivo, pero entonces un compañero puede entrar en GDocs y añadir esa información, o corregir un error, ¡y el primero recibe los cambios inmediatamente!

A propósito, una cosa que facilita mucho el trabajo es tener una cuenta de Gmail asociada, y aprovechar su libreta de contactos para almacenar los e-mails de la gente con la que colaboramos. Como se pueden crear grupos con esos e-mails, yo aprovecho para tener varios grupos, uno con todos los miembros de mi grupo de investigación, y otros los voy creando dependiendo de los temas en los que me voy metiendo (un contacto se puede meter en varios grupos). Al iniciar un nuevo documento, lo que hago es seleccionar el grupo pertinente desde la libreta de contactos, en vez de añadir los colaboradores uno a uno.

Otra aplicación que le estoy dando a GDocs es la redacción de artículos científicos entre varios miembros del equipo. En estos momentos estamos realizando una revisión sobre uno de los temas que estamos estudiando, y yo soy el coordinador. He asignado distintas tareas a cada colaborador, creando un documento para cada sección de la revisión, de manera que sólo haya que ir añadiendo contenido, y manteniendo la parte de formato al mínimo. He compartido todas las secciones con todos los colaboradores, para que quien quiera pueda aportar o revisar otras secciones que no sean las asignadas. Una vez terminadas todas las secciones, mi intención es copiar el contenido a un documento LaTeX, donde me ocuparé de la maquetación final y el formato (casi automático). Para la bibliografía, me basta con que cada cual me indique con formato autor-año dónde irá cada cita y que me la peguen al final de cada sección (una ligera edición por mi parte, y BibTeX y natbib se ocupan de todo lo demás).

Desgraciadamente, el éxito ha sido sólo parcial: casi nadie ha sido capaz de aprovechar la ventaja de GDocs para compartir la edición de documentos. El método estándar ha sido escribir el texto en un procesador de textos y, como mucho, copiarlo posteriormente en GDocs, con lo cual la descoordinación (varias personas trabajando sobre la misma sección pero en documentos distintos, escribiendo sobre lo mismo más la tarea extra de fusionar los textos) ha sido la de siempre. Y no me he librado de otros autores mandando los documentos por e-mail, en vez de subirlos a GDocs. Pero esto nos metería en una reflexión sobre la brecha digital.

Cambiando de aplicación, la capacidad de GDocs para manejar hojas de cálculo de, Google Spreadsheets, puede ser muy útil en la recogida de datos, especialmente cuando hay varios colegas implicados. Spreadsheets tiene una buena selección de fórmulas, con lo cual se pueden preparar plantillas para resolver problemas comunes en el laboratorio (desde diluciones sencillas hasta la lista completa de pesos y volúmenes a utilizar en un experimento, teniendo sólo en cuenta el número de replicados ha realizar). Y estas plantillas siempre estarán actualizadas para todos los que accedan a ellas desde GDocs, no más "ups, he utilizado la plantilla versión 3, cuando estamos usando el protocolo versión 4, porque se me olvidó copiarla a mi ordenador".

Lo dicho no quita que otros encuentren GDocs inapropiado, como he dicho antes, y prefieran otras tecnologías Web 2.0, como los wikis (una buena opción para el caso de los protocolos). Sin embargo, el parecido de GDocs con las típicas aplicaciones ofimáticas y su asociación con Google y Gmail podrían facilitar su uso a usuarios con poca experiencia y conocimientos en la Web 2.0. En el futuro, espero ahondar en otras herramientas que me han sido útiles (por ejemplo, el uso de Google Calendar para coordinar las actividades del grupo de investigación).

Calidad y exigencia en los congresos científicos

Vuelvo de un congreso en Utrecht (Países Bajos). Un poco decepcionado por las comunicaciones presentadas como pósters. Si bien es cierto que suele haber buen nivel, sí que es verdad que, en muchos casos, la calidad es muy deficiente.

Conclusiones que no se desprenden de los resultados, falta de controles adecuados, experimentos ya realizados, con conclusiones ya conocidas, trabajos financiados por empresas y que sospechosamente concluyen el buen funcionamiento de sus productos, etc. ¿Quién diría que una correlación con r menor de 0,5 (Pearson) es un buen resultado, por muy significativo que sea? Pues eso lo vi en un póster, con la conclusión de que, apoyándose únicamente en tal correlación, un nuevo aparato era tan efectivo como la metodología estándar.

El problema es que este congreso utiliza un sistema de peer review para revisar los abstracts, y que estos acaban publicados en una revista internacional indexada en el SCI (más Pubmed, etc.). Aunque no fuese así, como científicos, deberíamos tener más exigencia en la selección de los trabajos que van a congresos. Sin contar con el abandono total que sufren algunos pósters. Los "responsables" los cuelgan y se van a hacer turismo (o los cuelgan colegas que les han hecho el favor de llevarlos).

En muchos congresos se penaliza a los participantes que no llevan su trabajo al congreso (generalmente, no se admiten trabajos de ese grupo en las siguientes dos convocatorias). Yo no sólo estoy completamente de acuerdo con esta medida, sino que sería más estricto con las presentaciones. Si uno quiere darse una vuelta para ver otros pósters, siempre puede dejar un aviso al lado del póster, dejar sobres para sugerencias, preguntas, tarjetas, etc.

Necesitamos más calidad y más exigencia en los congresos. Por mi parte, a menudo me llegan peticiones para revisar artículos enviados a revistas, y algún proyecto de cuando en cuando. Tomo nota de los "descuidados" (son recurrentes), y, hasta que no vea más calidad, doy menos importancia a las contribuciones a ciertos congresos. Se siente.

Cambiando ligeramente de tema, he asistido también al análisis de la situación de una revista. Resulta que el índice de impacto ha bajado en los dos últimos años, y se atribuye al aumento de artículos sin una correspondiente subida de citas. La conclusión del comité editorial es que los usuarios de la revista deberían citar más... no estoy de acuerdo. De nuevo, tal vez se debería aumentar la exigencia. Conozco la revista, y he de decir que hay artículos que escapan a la mera consideración de ser "flojos": son directamente nefastos, con fallos graves en el diseño experimental y, principalmente, en el tratamiento estadístico (ya hablaré del "missuse" de las correlaciones para comparar métodos).

Pero realmente me preocupa que se tomen decisiones fijándose en el índice de impacto. La calidad y prestigio de una revista son cuestiones multidimensionales, y no las podemos reducir a un solo número. No digo que no se use el índice de impacto, y muchos de los que lo critican no lo hacen porque estén preocupados por la calidad o la fiabilidad de las evaluaciones (ejem). Lo fundamental es buscar la calidad. Si eso se consigue, el índice de impacto lo seguirá, pero no al revés.

Una reforma legal interesante

Se está preparando un borrador de proyecto legislativo para la Ley de la Ciencia y la Tecnología, como renovación de la vieja y bastante anacrónica (aunque un avance en sus tiempos) Ley de la Ciencia de 1986. Lo curioso es la forma que se ha elegido para realizarla, de una manera bastante abierta y participativa (en cierto sentido, democrática).

Este borrador está siendo preparado por veinticinco expertos, pero no a puerta cerrada. De momento, se han organizado unas Jornadas con asistencia y participación públicas. Mejor aún, la información sobre las jornadas y el contenido de cada bloque de charlas (correspondientes a otras tantas subcomisiones para la preparación del borrador) se ha organizado en un blog, públicamente abierto a comentarios y sugerencias (y que permite usar un agregador RSS). Y, al parecer, la redacción del borrador se está realizando con un Wiki.

Desgraciadamente, no he podido asistir a las charlas de las jornadas, pero ya se están colgando las presentaciones y vídeos, enlazándolos desde el blog. Vale la pena leer sobre la impresión que han dejado en Roke (al que enlazo, ya que está más al tanto que yo).

Para ser la primera vez que veo algo así (una administración pública recurriendo a la Web 2.0 en el proceso legislativo), he de decir que me llena de satisfacción, y que no está nada mal. Aunque se nota cierta bisoñez (comparando con blogs "experimentados"), la web es bastante agradable, el manejo de comentarios equilibrado, y algunos balbuceos iniciales se han ido corrigiendo. Lo mejor, sin duda, ha sido la gran cantidad de comentarios que se han enviado. Espero que se tomen en cuenta (si tengo tiempo, comentaré algunos aspectos de los distintos bloques con los que estoy muy de acuerdo o en desacuerdo), y, la verdad, soy optimista al respecto, viendo cómo se ha desarrollado este proceso y el nivel de muchos comentarios.

Como se ha indicado en otros sitios, esta iniciativa apenas ha tenido repercusión mediática. Una pena (y espero que se remedie, y que desde el Ministerio saquen más partido a esto). Esperemos que otras administraciones tomen nota y cunda el ejemplo. A mí me parece una magnífica (y no demasiado complicada) manera de organizar un trabajo colaborativo cuando hay múltiples sectores implicados e informados.

Se me ocurre una posible mejora. Entre el grupo de expertos y el público podría establecerse un nivel intermedio, donde estarían algunos representantes de diversas asociaciones y grupos interesados. Por ejemplo, se podría invitar a ese grupo a la Conferencia de Rectores, la Asociación de Parques Científicos y Tecnológicos de España (su coordinadora ha escrito varios comentarios en el blog de la LCyT), FJI/Precarios, la Asociación para el Avance de la Ciencia y la Tecnología en España, etc. Este grupo tendría privilegios "especiales" (acceso a borradores, comentarios "directos" al grupo de expertos, metacomentarios a los comentarios generales, etc.).

Lo fundamental es que la Web ha llegado a un nivel de desarrollo (y sigue avanzando) tal, que permite con una pasmosa facilidad organizar sistemas colaborativos sumamente eficaces. Esto supone un cambio de paradigma que se puede aplicar a casi todos los ámbitos, aunque aún no es muy visible y no todos están dispuestos a aceptarlo (cambiar cuesta, a veces cuesta mucho). Recomiendo leer a Juan Freire sobre este tema.

Actualización: acabo de ver que el software recomendado para la visualización de los vídeos es VLC, un excelente reproductor que es además software libre y disponible para multitud de plataformas. El que se piense en tecnologías abiertas y universales es una muy buena señal.