Archivo de la etiqueta: ciencia

Mis reglas para un mejor software científico

Hace tiempo que no escribo sobre mis reglas ser más eficiente y qué mejor excusa que este artículo sobre reglas para un software científico más robusto que me ha pasado mi hermano para aprovechar y contar un poco cómo me apaño yo, simple investigadora sin conocimientos de informática, para gestionar todo el código que tengo que escribir y usar.

No, no sé programar

Os va a parecer muy loco pero yo, al igual que muchos otros científicos e investigadores, programo en mi día a día sin tener ningún tipo de formación en ello. No tengo ningún conocimiento sobre cómo programar, sobre tests o sobre buscar bugs. Cero patatero. Y eso que yo soy muy poco convencional y uso la terminal y tengo mi código bajo control del versiones.

De hecho, este es mi sexto año currando en una universidad, es la cuarta en la que estoy (contando también en la que estudié) y no es nada común, al menos en mi campo (¡la ingeniería mecánica!), que la gente sepa usar el ordenador y ya ni hablemos de programar con cierto sentido. ¡Pero mucha de esta gente programa, yo incluida! ¿Cómo lo hacéis? os preguntaréis. Pues fácil: a lo salvaje, con un código repetitivo, lleno de basuras e imposible de leer para cualquiera que no sea su creador en los siguientes 15 minutos de haberlo escrito.

Lo peor de esto es que ese código ineficiente y chapucero viaja por ahí en emails y pendrives y miles de millones de versiones diferentes de él circulan por ahí a cada cual más desastrosa… No exagero nada cuando digo que he llegado a escribir programas (programas complejos) desde cero porque no era capaz de entender lo que me habían pasado, es decir, una carpeta llena de funciones sin la más mínima documentación.

Como comprenderéis, esto es frustrante y una pérdida de tiempo tanto para el que escribe como para el que usa el programa y además retrasa el avance de la ciencia, ya que no permite que se creen soluciones serias para atacar los problemas sino que cada cual se hace su herramienta cutre para salvar su culo.

En fin, después de este desahogo me centro ya en lo que estábamos: unos criterios para que el código que escribimos los que no sabemos programar sea un poco más usable. Estas son las reglas que yo misma intento seguir para mi código, las considero una buenas prácticas que harán la vida de Ondiz del futuro más simple ya que no tendrá que retrotraerse a aquella vez que le pasaron 5 gigas de datos que tenía que tratar en una semana porque tenía una reunión. Estas reglas son, además, perfectamente adaptables a la producción de textos científicos y veréis como tienen mucho en común con mi proceso de escritura LaTeXiano.

Lo último que tenéis que saber antes de leerlas es que he adaptado la información que he leído con mi experiencia personal y por eso están escritas en plan bronca hacia mí misma. ¡Vayamos a ellas!

Cinco reglas simples y un bonus

Primera regla: usa control de versiones

¡Nunca me cansaré de repetir esto! Ponte ya mismo a aprender a utilizar un sistema de control de versiones, me da igual cuál. Yo uso git cuyas funcionalidades básicas se aprenden en un rato y que tiene múltiples GUIs disponibles si te da miedito la terminal, pero puedes elegir el sistema que te parezca siempre que empieces a usar uno ahora.


No me pruebes por amor de Dios una nueva funcionalidad y destruyas todo lo hecho hasta ahora porque tu único salvavidas es el botón de deshacer y el archivo aquel que se llama versión_corregida_final_57.

Corolario: usa texto plano

Para que el sistema de control de versiones sea útil de verdad lo mejor es que te pases al texto plano. Podrás ver las modificaciones introducidas con una facilidad pasmosa (¡diff!), no te tirarás de los pelos cuando la versión del software cambie y serás más feliz en tu vida en general.

Segundo corolario: usa un editor decente

Con editor decente me refiero a uno que te ayude en tu trabajo, no uno que luche en tu contra (¡hola, Word!). Un editor que maneje texto plano y facilite tareas como buscar o escribir una tabla te hará ahorrar horas de trabajo. Si este editor es configurable y puedes adaptarlo a tu gusto ya ni te cuento.

¿He oído Emacs por ahí? ¿Vim dicen aquellos otros? Me vale cualquiera que no se cuelgue al abrir un csv de 100MB.

Segunda regla: documenta el código

Ahora te parece que esa función que ensambla matrices dispersas y que has escrito en una línea con variables que se llaman a, b y c se explica por sí misma, pero cuando vuelvas el lunes te darás cuenta de que no es así1. Cuando te aparezcan errores crípticos y hayas tenido que reescribir lo que hiciste ayer porque no te acuerdas de cómo lo implementaste te lamentarás de no haber documentado tu proceso.

Tampoco te pido que pongas todos los detalles, con una línea diciendo qué hace la función, cuáles son sus entradas y salidas y un ejemplo de uso es más que suficiente. Si quieres tener algo más decente, puedes investigar el sistema de documentación específico de tu lenguaje, por ejemplo, en Matlab se pueden hacer cosas chulas en HTML.

Corolario: escribe para las personas no para el ordenador

No me sirve de nada que generes código como churros si luego nadie (¡ni siquiera tú mismo!) es capaz de usarlo. Ten en mente a la persona a la que le tocará añadir un nuevo módulo a tu programa cuando escribas y explica por qué has tomado una decisión y no otra.

Tercera regla: añade un README

Una situación bastante típica si eres investigadora es que te pasen una carpeta llena de scripts sin ton ni son y te digan que ese es el trabajo hecho hasta el momento y que le añadas la opción X. Con el simple hecho de que en esa carpeta haya un README en el que se resuma el objetivo final de todos esos archivos sueltos y qué hace cada uno, la persona que la reciba pasará de estar un par de semanas tirándose de los pelos a solo un par de horas.


Si en ese README hay además una descripción de las herramientas necesarias (con sus correspondientes versiones) para poder usar ese código y una microexplicación de cómo se usa, la persona que reciba tu trabajo te amará por siempre jamás. Si está escrito en Markdown o en Org para que mi editor decente me lo muestre con colorinchis para que sea más fácil de leer yo también te amaré.

Cuarta regla: proporciona un ejemplo de uso

Siguiendo con la regla anterior, lo mejor que puedes hacer por las que usarán tu trabajo en el futuro (y recuerda que puedes ser tú mismo) es proporcionar un ejemplo. Puede estar en el propio README o que haya un caso mínimo incluido en la carpeta con las cosas donde se muestre el funcionamiento de tu programa, como tú veas, pero por dios, hazlo. Es la mejor manera de que yo sepa que tu programa funciona.

Quinta regla: no des por hecho nada

No asumas que los archivos estarán en un lugar concreto y no me escribas rutas absolutas que solo funcionan en tu ordenador. Si tu programa usa herramientas externas, búscalas o dime dónde situarlas en el README, pero que no tenga que estar como Colombo intentando localizar el origen de un error.

Regla del opensource: si publicas tu código hazlo en condiciones

Esta última regla la digo más que nada como usuaria de programas y paquetes de diferentes repositorios. Por favor, etiqueta las versiones, avisa de las dependencias, usa un proceso de instalación típico, añade una licencia y especifica qué falta por hacer. A ti te lleva muy poco tiempo hacer estas cosas pero a mí me libras de muchas horas de frustración. Hazlo por mí.

Recapitulación

Vas a tener que programar aunque no sepas así que ten en mente dos cosas: usa las herramientas adecuadas y pónselo fácil a las personas. Piensa que solo con cambiar a un editor más potente aumentarás tu productividad de manera loca y que un simple README de tres líneas hará tu programa mucho más usable para todo el mundo, ¡especialmente a tu futuro tú!

Referencias

Ten simple rules for making research software more robust

Ten recommendations for creating usable bioinformatics command line software

Best practices for scientific computing (pdf)

Your step-by-step guide to more effective documentation


¡Música!


  1. Esto es un caso real de cuando calculaba los modos de una viga con elementos finitos en Matlab. 
Anuncios

Explicando la resonancia

El señor que explicaba la semana pasada que el agua suena diferente según esté caliente o fría me enamoró y me puse a ver vídeos de su canal como una loca. ¿Qué encontré? ¡Una explicación sobre la resonancia! Hace tiempo hice unos números sobre ello pero su versión con fuego (todo es mejor con fuego) es mucho más chachi:

Ben Goldacre habla de mala ciencia

Estoy leyendo ahora mismo Mala Farma de Ben Goldacre, un psiquiatra inglés que se dedica a denunciar las malas prácticas de la industria farmacéutica, los médicos y demás personajes de la ciencia médica. En esta charla cuenta con su particular humor algunos ejemplos de lo que ha visto, os dejo con él:

Por cierto, el Dr Goldacre y yo tenemos dos cosas en común: nos gusta trolear a los trolls y hablamos ultrarápido 😀

Un estudio dice que

Un estudio dice que es bueno tomar un vaso de cerveza después de hacer ejercicio. Otro que el chocolate adelgaza. Resulta que han descubierto vida fuera del Sistema Solar. Y que se pierde la mayor parte del calor por la cabeza. Las típicas cosas que se oyen por ahí, que comenzaron siendo un titular que decía un estudio dice que y que han ido derivando. Pero, ¿fue eso que circula por ahí alguna vez verdad? En esta charlilla nos hablan de esas cosas, del publish or perish, de los programas gubernamentales y del papel de los medios en todo el asunto.

Tenemos que ser más escépticos, hermanos.

Más

Ni la cerveza cura ni el vino adelgaza en El Comidista

Jamás deberías usar cerveza en vez de paracetamol para calmar el dolor en Naukas

Polémica con los ‘pulpitos’ en las UCI por la transmisión de bacterias en Redacción Médica

Scientists debunk the myth that you lose most heat through your head en The Guardian

Cochrane. Trusted evidence. Informed decisions. Better health

Curso no convencional de LaTeX: un documento científico

Vamos a hablar del caso en el que LaTeX da lo mejor de sí mismo: un documento científico. Con esto me refiero a libros técnicos, tesis, artículos… ya me entendéis. No tienen por qué hablar necesariamente de ciencia, si me centro más en ellos es porque es mi campo.

La característica esencial de un documento científico es su formato rígido que en muchas ocasiones nos viene impuesto, ya sea por una revista o universidad o por las propias costumbres de nuestra disciplina. Por ejemplo, una tesis suele estar dividida en capítulos, debe tener referencias bibliográficas con un estilo determinado y se inicia con un índice general, uno de tablas y otro de figuras así como con un glosario de términos. También suele llevar un resumen del contenido al principio y se separa el trabajo adicional en apéndices. Todo esto implica diferentes formatos para las partes (numeración de las páginas y secciones, estilo de los encabezados…) y cierta planificación. Sin planificar se puede uno volver completamente tarumba, lo digo conocimiento de causa, el control de versiones me salvó más de una vez de romper la tesis sin remedio.

Es por ello que primero veremos cómo organizar el documento en cuestión y luego haremos un índice, un glosario y hasta unas lista de referencias.

Seguir leyendo →

Mi artículo científico

Con el tema de la tesis escribí un artículo científico que me han publicado finalmente en Mechanical Systems and Signal Processing. Ya sabéis de sobra que yo soy bastante crítica con el funcionamiento de las revistas, así que a pesar de que no me ha quedado otra que mandar mi trabajo a una, voy a aprovechar todas las opciones de compartir el artículo que me dan:

  • Hasta el 17 de febrero podéis acceder a la versión definitiva aquí, en el link de compartir que me han mandado los de la revista por ser yo el autor number one.

  • Inserto el accepted manuscript aquí debajo

  • Si alguien me respalda subo el accepted manuscript a arXiv

Si se os ocurre alguna manera más de compartirlo que cumpla los requisitos de Elsevier me decís y la miro. Espero que os guste mi curro, lo he hecho con mucho cariño 😉