Archivo de la categoría: Opinión

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

Y por mí también

Como sabréis, este 8 de marzo está convocada una huelga de mujeres. En Euskadi en concreto nos movilizaremos bajo la frase Emakumeok planto!, y digo nos porque este 8 de marzo yo paro. Paro por muchos motivos, listo aquí unos pocos:

  • Por la doble jornada, la carga mental y tener que aguantarnos porque nos ayudan en casa.

  • Por las mujeres deportistas a las que no consideran profesionales porque su deporte no es rentable.

  • Por la segregación vertical y la horizontal, por el techo de cristal y los estereotipos de género.

  • Por las investigadoras que cuando se organiza un congreso su tarea es llevar los cafés, porque a ellas se les da mejor.

  • Por todas a las que nos tratan como objetos incapaces de pensar por nosotras mismas.

  • Por las histéricas, mandonas y exageradas que si no fueran mujeres serían grandes líderes.

  • Por todas a las que un amigo a intentado besar o abrazar a pesar de decirle claramente que no están interesadas.

  • Por las mujeres a las que un médico hombre cis les ha dicho que no sean quejicas que eso de la regla no es para tanto.

  • Por la comisión que toma decisiones sobre la natalidad sin contar con nosotras.

  • Por el acoso en las calles y en las redes.

  • Por las niñas que quieren ser ingenieras, físicas o informáticas y tienen un camino el doble de difícil.

  • Por aquellas a las que les han negado un ascenso o la renovación del contrato al quedarse embarazadas.

  • Por las que no se callaron, no se callan y no se callarán.

  • Por todas a los que nos han llamado marimachos, bolleras y feminazis por pedir que se nos trate como personas.

Porque el feminismo solo es eso, que se nos reconozca como seres humanos, una idea tan radical por la que nos insultan, machacan, humillan, golpean, violan y matan en todas las partes del mundo.

Por eso paro, por todas estas razones y más que no he escrito, pero paro sobre todo por mí, por mi derecho a ser tratada con justicia y en igualdad de condiciones, por que mi género no condicione ningún aspecto de mi vida.

Nos vemos en la manifa.

Review: Elogio de la ociosidad

He leído por fin el Elogio de la ociosidad de Bertrand Russell, un alegato a favor de una jornada laboral reducida gracias a los avances técnicos. El texto se escribió en los años 30 pero es perfecto para hoy en día que el mundo laboral está en casi en las condiciones previas a la Internacional.

Según Russell la felicidad viene por reducir el trabajo, algo perfectamente posible gracias a la técnica moderna. El problema es que cuando se inventa un sistema que permite duplicar la productividad, en lugar de trabajar la mitad (por el mismo dinero) se reduce la plantilla a la mitad. De esta manera la mitad de la población acaba en el paro mientras la otra mitad trabaja demasiadas horas, convirtiendo el ocio en una fuente de infelicidad. ¿No os suena esto?

Seguir leyendo →

El porqué del curso de LaTeX

Hoy os voy a contar un poco del trasfondo del Curso no convencional de LaTeX, por qué empecé a escribirlo y qué supone para mí. No os preocupéis que pronto llegará la siguiente entrada, no todo va a ser hablar sobre mi vida.

Publiqué la idea de escribir un cursete de LaTeX el 13 de noviembre del año pasado, un mes después de terminar de escribir la tesis y un mes antes de defenderla. Fue un tiempo muy raro ese, estaba preparando la presentación, el ambiente en el trabajo era horrible y no sabía qué iba a hacer con mi vida. Es fácil entender que muy motivada no estaba.

Seguir leyendo →

¿Cuesta tanto aprender?

Vi el otro día esta charla TED que trata sobre el tiempo que requiere adquirir una nueva habilidad, algo que como persona que aprendió a ganchillar (entre otras cosas) en una tarde y con un par de vídeos me pilla de cerca.

Después de haber aprendido muchas muchas cosas, he desarrollado una especie de proceso de aprendizaje, que si bien tiene muchas cosas en común con el que propone el señor del vídeo, difiere en otras. He pensado en compartirlo aquí con vosotros por si os resulta útil. Así ya no me tenéis que preguntar cómo me lo monto para hacer tantas cosas 😉

Me ayudó a crear un proceso el libro Apprentice Patterns, que aunque originalmente es un libro para programadores (y yo no lo soy), sus consejos son útiles para cualquiera. El proceso tiene 5 partes, ahí van, con su apartado en el libro que os decía cuando corresponda.

1. Dividir

Consiste en partir la actividad en trocitos pequeños para ver lo mínimo que necesitamos. Se aplica tanto al material como a los conocimientos. En lo que respecta a los conocimientos, cuanto mejor definamos qué necesitamos más fácilmente encontraremos un libro, artículo o persona que nos pueda ayudar.

Por ejemplo, cuando aprendí a hacer punto, localicé unos vídeos para principiantes y los estuve viendo antes de comprar nada. De ahí averigüé que lo básico del punto es hacer punto del derecho y punto del revés, con eso (y aprendiendo a montar los puntos, claro) ya puedes hacer cualquier cosa rectangular. Parece poco, pero con un rectángulo se pueden hacer bufandas, gorros y hasta chaquetas. Luego busqué una tienda en la que pudiera comprar material y en la que me pudieran aconsejar. Sí, soy el tipo de persona que va a los sitios y fríe a preguntas a la pobre gente a la que le toca atenderme. Compré solo unas agujas relativamente gordas para que fuera más sencillo aprender, y lana barata para que si me salía mal me importase menos.

Conozco la sensación de voy a aprender a hacer X, así que voy a comprarme 8 libros y gastarme 200€ en cosas que parece ser que necesito. Luego lo que pasa es que, o bien eres supermetódico (que yo no lo soy) o has gastado inútilmente un montón de pasta y tienes la casa llena de cosas que nunca más vas a utilizar. Mi truco del almendruco me vale para ir enganchándome a mi nueva obsesión poco a poco de tal manera que o se vuelve parte de mi vida, o la odio y entonces me he gastado lo mínimo para probar y se lo puedo regalar a otro que quiera empezar también.

Pumpkin Pie & Light Bulb por Greatist via Attribution Engine. Licencia CC BY-NC-SA.

Seguir leyendo →

Las locas aventuras de Ondiz pidiendo el paro. El desenlace.

Después de que la tía de Lanbide me dijera que me correspondía otra oficina, les escribí un correo a los de dicha oficina para ver si era cierto y preguntar si necesitaba cita. Solo me dijeron que no, no necesitaba cita e ignoraron mi otra pregunta. Por lo tanto, llamé a la centralita de Lanbide para que me aclarara el asunto. La chica que con la que hablé me dijo que en realidad me tenían que atender en cualquier oficina, pero que como algunas ponían pegas era preferible ir a la correspondiente según el código postal del domicilio que aparece en el DNI (o llevar el empadronamiento). Me resigné por lo tanto, a hacer la ruta turística e ir a una oficina de Lanbide a pedir el paro en el SEPE y transportarme a una segunda ofina de Lanbide (con SEPE también, curiosamente) a que me hicieran el CV.

Esta vez no había ningún problema (excepto que en la base de datos ponía que era un hombre…) y por fin me han apuntado para que cobre. Después de perder 3 mañanas, ni tan mal. He descubierto algo muy curioso y es que si te pones a currar puedes avisar por teléfono, pero si te vas al extranjero (aunque solo sea un día) tienes que avisar cuando vas y cuando vuelves en persona. Pidiendo La Cita, claro. He aprendido también más cosas sobre lo que pasa con el paro si vas al extranjero, mirad:

  • Si vas menos de 15 días naturales al año no pasa nada, avisas y ya está, pero cobras igual.

  • Si vas más de 15 días pero menos de 90, se te suspende el paro pero se reanuda a la vuelta.

  • Si vas más de 90 días pero menos de un año y lo puedes justificar (has ido a un curso…) es como el caso anterior, si no lo puedes justificar, lo pierdes.

  • Si vas más de un año pierdes el paro.

Muy interesante.

A continuación fui a la oficina de Lanbide a llevar los títulos para que me actualizasen el CV. Tiene su cosa esto, porque tú no puedes tocar tu CV y todo lo que te ponen lo tienes que demostrar. ¿Cuál es el problema? Que no aparece ninguno de los programas de ingeniería que yo uso y tampoco puedo añadir ninguna técnica experimental. De hecho, según el CV yo estoy buscando trabajo de ingeniera porque no existe una opción para poner investigador o algo semejante. Que ya tenía yo claro que Lanbide no me iba a encontrar curro y solo he ido porque es obligatorio, pero no me parece justo que a un sector de la población se nos niegue un servicio público. Es como si me dijeran tú como has estudiado te buscas la vida solita, pero vienes aquí a perder tiempo de vida porque me apetece, aunque no te vaya a ayudar en nada.

La parte buena del asunto es que la señora, muy maja ella, me ha dicho que me tenían que haber atendido en la otra oficina y que ella pondría una queja, que ese comportamiento es inadmisible. ¡Tenía  yo razón!

Pero como todo no va ser ganar, al llegar a casa he descubierto que tengo que presentar la queja en papel, ¡así que tengo que volver! Es una fiesta 🙂

Review: Cómo hacer la revolución de Srdja Popović

Como ya sabéis en este blog voy escribiendo todo lo que me apetece compartir con vosotros, ya sea un vídeo o un tutorial sobre la terminal. Esta vez vengo a hablaros de un libro: Cómo hacer la revolución de Srdja Popović, editado en España por Malpaso, lo que es ya garantía de calidad.

Descubrí el libro por casualidad dando vueltas aleatoriamente por la biblioteca, en la zona de ciencias sociales y política. Últimamente leo bastante no ficción, supongo que será la edad. Me conveció por dos motivos: por hablar de métodos revolucionarios no violentos y porque el autor fue uno de los fundadores del movimiento que derrocó a Milošević, Otpor!.

El libro habla de la importancia del humor en cualquier movimiento revolucionario (lo llama risactivismo),  explica cómo reconocer y hacer tambalear los pilares de poder de un régimen abusivo y hace especial hincapié en que un movimiento que pretenda cambiar las cosas debe hacer partícipe al mayor porcentaje de la población posible. Todo ello de manera rigurosa pero manteniendo siempre un tono cercano y humorístico.

Popović trabaja actualmente en CANVAS, una organización que forma activistas no violentos en todo el mundo, así que además de hablarnos de su experiencia en Serbia, cita casos de Birmania, Irán, Egipto, la islas Maldivas o Ucrania. Mi anécdota favorita es cómo los disidentes al régimen de Pinochet convencieron a los taxistas para que circularan despacio para mostrar su desacuerdo. Esto consiguió que finalmente todos los contrarios al régimen condujeran (e incluso anduvieran) despacio. De esta manera era posible saber que uno no estaba solo en la lucha contra la dictadura sin que nadie se jugara la vida. Evidentemente, este es un paso muy pequeño pero ayuda a mantener la moral. Popović nos cuenta como seguir avanzando ganando pequeñas batallas hasta el punto de forzar la salida del tirano, todo ello sin derramamiento de sangre.

De todos los conceptos del libro me quedo con la planificación secuencial inversa, que consiste en imaginarse con todo lujo de detalles a uno mismo cuando ha conseguido su objetivo e ir viendo los pasos que ha ido dando hasta llegar hasta allí. Esto permite definir mejor el objetivo final y, por lo tanto, que los pasos a dar para alcanzarlo sean más claros. Es una técnica, además, que puede aplicarse en todos los órdenes de la vida.

Por si fuera poco, el autor es un friki de El señor de los anillos y utiliza sus personajes para ilustrar algunos ejemplos. Es genial. 

La verdad es que el libro me ha gustado mucho y me ha dado más ganas de dominar el mundo 🙂

Aquí tenéis el primer capítulo en la web de Malpaso por si queréis echarle un ojo. Ya me contaréis qué tal.