Por qué Perl?

De vez en cuando en este blog toca escribir sobre Perl, uno de los lenguajes que usamos en nuestro trabajo, en mi caso el que más uso la verdad.

Voy a traducir y resumir https://two-wrongs.com/why-perl , porque creo que plasma mi experiencia bastante bien [en negrita mis comentarios]:

"A veces me preguntan porqué uso tanto el Perl. No soy acaso fan de los lenguajes fuertemente tipados? Sí. Pídeme que escriba algo que sepa a ciencia cierta que se convertirá en un gran sistema y elegiré un lenguaje fuertemente tipado sin duda [...]. Pero la mayor parte de lo que escribo nunca se convertirá en un gran sistema. Esto es lo que Perl hace bien:

1. Está instalado por defecto en todas partes y no necesito ser superusuario para ejecutarlo.
   
2. Con mucha disciplina, los scripts Perl pueden escalar hasta construir sistemas grandes y complejos.
3. Sé que un script Perl que escriba hoy funcionará sin cambios en 10 años, sobre todo si me limito a importar módulos core.
4. Perl puede reemplazar en la práctica a cualquier lenguaje shell, aunque combina muy bien con bucles bash.
   
5. Perl tiene una sintaxis core relativamente pequeña, flexible y extensible. 

Estos requerimientos están ordenados por prioridad, siendo el primero el más importante. Cuando quiero hacer un prototipo rápidamente no quiero que mi primera tarea sea 'Primero instala el ambiente ...'. Como los prototipos suelen usarse más allá de lo que inicialmente pensamos, es importante que sea posible escribir software en ese lenguaje que se pueda mantener y que funcione mientras haya personas interesadas en usarlo.

Perl es único en cuanto a estas condiciones. La siguiente tabla resume otras alternativas que he probado al menos un mes, donde los asteriscos marcan condiciones que se cumplen de manera incompleta:

"
 

En general estoy bastante de acuerdo con esta carta de presentación del lenguaje. Creo que el principal problema de Perl es que su extrema flexibilidad permite escribir programas que pueden ser difíciles de leer por otros, queda en tu mano documentar y estructurar bien el código para que eso no ocurra,

Bruno

 

beneficios de la evaluación doble ciega por pares

La publicación de resultados en ciencia se hace normalmente por medio de artículos en revistas científicas. El proceso empieza (i) cuando los autores envían un borrador a los editores de una revista, a menudo con una carta de presentación del trabajo. Ésto se hace generalmente en inglés, la lengua franca de la ciencia. A continuación (ii) los editores deciden si el tema y los resultados son potencialmente interesantes para la revista. Si no lo son, el artículo es rechazado sin revisión (desk rejection). En caso contrario (iii), los editores buscarán a varias personas supuestamente expertas en el tema (revisores o pares), que no tengan conflictos de interés con los autores, y les pedirán una evaluación crítica del artículo, algo que puede tardar del orden de semanas. Finalmente, con las evaluaciones (reviews) en la mano, el editor decide (iv) si solicitar modificaciones a los autores, como nuevos experimentos, interpretaciones o ediciones del inglés, rechazar el trabajo o aceptarlo en su primera revisión (nunca me ha pasado).

Fuente: https://fourwaves.com/blog/single-double-blind-peer-review

En nuestro campo de la biología computacional y la genómica este proceso normalmente es ciego, es decir, los autores no conocen la identidad de los revisores, pero éstos sí pueden ver las identidades y afiliaciones de los primeros. 

Un estudio iniciado en 2019 y publicado en la revista Functional Ecology  en 2023 aporta datos convincentes para que cambiemos a un sistema doble ciego, donde tampoco los revisores puedan poner nombre a los autores. El estudio hizo un seguimiento a 1837 y 1852 artículos evaluados por el sistema ciego y doble ciego respectivamente y concluye que la evaluación doble ciega:

1) hace que las revisiones sean más exigentes.

2) iguala las evaluaciones de artículos liderados por mujeres, por personas cuya lengua materna no es el inglés o de científicos de países con menores índices de desarrollo humano.

Copio aquí una de las figuras del estudio:

Fuente: https://doi.org/10.1111/1365-2435.14259

Como dicen aquí, harán falta más estudios como este para confirmar los hallazgos, pero son resultados muy importantes que alertan de los sesgos en los que incurrimos al evaluar el trabajo de los demás,

hasta pronto,

Bruno

instalación de slurm en servidor multi-core Debian

Hola,

hace un tiempo explicaba aquí cómo montar grid-engine en Debian para gestionar trabajos paralelos en un servidor multicore. Como he tenido algunos problemas he probado slurm, que está activamente desarrollado y documentado. 

 

En concreto lo he hecho sobre un servidor Debian 11. Si vienes de otros sistemas, como LSF, tendrás que convertir tus comandos con tablas como ésta. Los pasos que he seguido los he adaptado de aquí:

sudo apt install slurmd slurmctld -y
sudo chmod 777 /etc/slurm

# creo fichero de configuración /etc/slurm/slurm.conf,
# tendrás que adaptar CPUs= y RealMemory= al final ,
# en mi caso he definido "16 nodos"

sudo cat << EOF > /etc/slurm/slurm.conf
# See the slurm.conf man page for more information.
#
ClusterName=localcluster
SlurmctldHost=localhost
MpiDefault=none
ProctrackType=proctrack/linuxproc
ReturnToService=2
SlurmctldPidFile=/var/run/slurmctld.pid
SlurmctldPort=6817
SlurmdPidFile=/var/run/slurmd.pid
SlurmdPort=6818
SlurmdSpoolDir=/var/lib/slurm/slurmd
SlurmUser=slurm
StateSaveLocation=/var/lib/slurm/slurmctld
SwitchType=switch/none
TaskPlugin=task/none
#
# TIMERS
InactiveLimit=0
KillWait=30
MinJobAge=300
SlurmctldTimeout=120
SlurmdTimeout=300
Waittime=0
# SCHEDULING
SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core
#
#AccountingStoragePort=
AccountingStorageType=accounting_storage/none
JobCompType=jobcomp/none
JobAcctGatherFrequency=30
JobAcctGatherType=jobacct_gather/none
SlurmctldDebug=info
SlurmctldLogFile=/var/log/slurm/slurmctld.log
SlurmdDebug=info
SlurmdLogFile=/var/log/slurm/slurmd.log
#
# COMPUTE NODES
NodeName=localhost CPUs=16 RealMemory=200 State=UNKNOWN
PartitionName=LocalQ Nodes=ALL Default=YES MaxTime=INFINITE State=UP
EOF

# iniciamos el gestor
sudo chmod 755 /etc/slurm
sudo systemctl start slurmctld
sudo systemctl start slurmd

# probamos el cluster
sinfo
sbatch --wrap=date
cat slurm-1.out 

PD Para ver las propiedades de tu nuevo "cluster" puedes probar:

scontrol show node

Hasta pronto, 

Bruno

footprintDB moved to a new server

Dear all,

shortly after the changes reported on Twitter, our server footprintDB, first published in 2014, has moved to a new server.

The new URL is https://footprintdb.eead.csic.es and accesses to the old site [http://floresta.eead.csic.es/footprintdb] will be redirected here. 

Here's a summary of updates:

• A new release of the EEADannot collection was produced.
  
• Downloadable data are now CC-BY-NC-SA license, leaving out RegulonDB.
• The new server supports certbot HTTPS, runs mariadb instead of mysql, and deprecates the SOAP Web Services interface, and its client (https://github.com/eead-csic-compbio/footprintDBclient).
• The plant contents currently include 1233 transcription factors and 2252 DNA motifs.
  

Motif of BIL1/BZR1, https://footprintdb.eead.csic.es/index.php?db:EEADannot&motif=BZR1.

 

Have a nice week,

Bruno