2009-04-27 12 views
13

Estoy haciendo un trabajo preliminar para investigar cómo DVCS (como Git, Hg, Bazar) puede ayudar en el proceso de programación científica, especialmente para estudiantes de posgrado. Creo que estoy en una posición bastante buena para esto, ya que he estado programando durante bastantes años y actualmente estoy comenzando un programa de maestría en ciencias naturales. El objetivo es tener una breve presentación sobre esto en un mes o dos.¿Cómo puede DVCS ayudar a la programación científica?

Por lo que veo, aparte de la ventaja obvia de control de código fuente, DVCS ofrece actualmente las siguientes mejoras en la vida diaria de un estudiante graduado:

  1. ramificación:

    Esta es la gran uno. A partir de la observación de las prácticas DVCS, está claro que la ramificación barata fomenta principalmente la experimentación de nuevas características. La programación científica es TODO acerca de la experimentación. Se pueden crear diferentes ramas para ajustar parámetros o algoritmos. Esto es especialmente importante porque la mayoría del código científico no ha visto una aota de refactorización a lo largo de su vida (la mayoría de los estudiantes de posgrado ni siquiera sabrá qué es), por lo que la posibilidad de ir a diferentes ramas traerá algún método a la locura típica. Compromisos rápidos también podría significar el uso de comentarios de compromiso como un sustituto para los cuadernos de laboratorio. Los resultados computacionales se pueden etiquetar a códigos hash de confirmación específicos para la investigación reproducible.

  2. Empujar a los servidores:

    Dado que la mayoría del código científica hoy en día se ejecute en una especie de un clúster, DVCS puede ser utilizado como una especie de Rsync más avanzada, que muchos ya lo están utilizando para impulsar la "producción" codificar a los clústeres de HPC. Esto se combina con ramificación para funcionar fácilmente múltiples versiones de código sin salir

  3. Colaboración de papeles:

    Necesito decir más? Los documentos que tienen varios autores se ejecutan exactamente como pequeños proyectos de código abierto. La colaboración en los artículos debe ser una coincidencia natural cuando todos los autores escriben en LaTex, con complicaciones adicionales si la escritura se hace en algo como Word. Aquí es donde los comentarios de compromiso podrían desempeñar un papel más importante.

Mi pregunta es, ¿qué crees que DVCS puede aportar para los programadores científicos? Veo muchas conversaciones para pasar al control de fuentes en la comunidad, pero la mayoría todavía está investigando a Subversion. De mis notas superficiales, parece que DVCS debería ser el paradigma de flujo de trabajo perfecto para los nuevos estudiantes de posgrado. ¿Está mi pensamiento defectuoso? ¿O la codificación científica simplemente está demasiado rezagada para que incluso haya escuchado de las herramientas DVCS?


relacionadas:

+0

en realidad no relacionado con la programación, más acerca de cómo las personas pueden colaborar en la redacción de documentos? –

+1

¿Qué es la programación científica? ¿Programación hecha por científicos, o programación en clusters grandes? He realizado una gran cantidad de programación científica en varios laboratorios, y la mayor parte no se realiza de forma colaborativa o en clusters. – mmr

+1

@mmr: Me gustaría ir con "programación para simular experimentos y/o analizar conjuntos de datos", y su colaboración y clusteridad varían enormemente. (En mi disciplina, básicamente, cada proyecto involucra algún código desarrollado colaborativamente, y el análisis principal generalmente se ejecuta en un clúster). – dmckee

Respuesta

1

Un gran problema con DVCS para la programación científica son datos binarios. A menudo ocurre que la programación científica requiere entrada/salida de archivos gigantescos, y eso mata las actuaciones muy rápidamente en cada DVCS que conozco (bzr, hg, git). Esa es un área donde svn es mucho mejor actualmente.

Creo que DVCS también puede ser muy útil para documentos, pero eso significa que su colaborador también conoce el DVCS.

+0

¿Quién va a poner los datos bajo control de versión? Eso mataría a un RCS tradicional igual de rápido ... En la física de partículas usualmente utilizamos arreglos de almacenamiento separados para los datos. – dmckee

+1

dependiendo de los datos, tiene mucho sentido ponerlos bajo control de revisión, o no. Ciertamente me he encontrado con muchos investigadores haciendo exactamente eso. Y con DVCS, es fundamentalmente diferente de, por ejemplo, svn, porque mientras que svn rastrea cada archivo individualmente, la mayoría de los DVCS que conozco rastrean todo el árbol. No se puede hacer un pago parcial con git, bzr o hg (por parcial, quiero decir solo un subárbol, no un subconjunto del historial), así que una vez que agregas un archivo de un Gb, tienes que cargar la carga asociada para siempre después . –

+0

Con Git al menos puedes evitar esto con submódulos, pero obviamente eso complica aún más todo. Una cosa que personalmente hago cuando trato con resultados que son demasiado grandes para ser controlados por la revisión, es etiquetarlos con la identificación de confirmación que generó el resultado. En 'svn' este es el número de rev, mientras que en cosas como' git' sería la suma sha-1. –

2

con respecto a sus principales puntos:

  • "ventaja obvia de DVCS": vale la pena repetir que, especialmente en un entorno académico con potencialmente estricta que rige para no que permite la conexión externa, el DVCS permite trabajar con un repositorio local. Eso significa que no tiene que estar "conectado" a un repositorio central para acceder a la historia completa de un proyecto, y que allí podría ser la principal contribución de DVCS a los programadores científicos.

Pero eso también significa que debe tener algún tipo de política para permitir que un trabajo determinado "se una" y se consolide en un repositorio, lo que no significa que habrá una sola base "central": uno podría imaginar varios repositorios centrales para varios proyectos grandes. Aún así, requiere administración (no debe subestimarse).

Y ese proceso de "consolidación" puede ser muy difícil debido a que su principal primer punto:

  • ramificación: el estudiante tiene que branch carefully (ya que es tan fácil). Vi mi parte de la rama llamada 'toto', 'Monday', 'myName', ...: una vez publicada en otro repositorio (más central), ¿qué se supone que hagamos con eso? Si se van a fusionar más de 20 sucursales para finalizar un código común, ... el proceso puede volverse propenso a errores muy rápidamente.

comentarios rápido en los otros puntos:

  • despliegue (lo que se llama "empujando al servidor"): sí DVCS se pueden utilizar para algún tipo de despliegue, pero eso significa que ha organizado su Repo para incluir algún tipo de "release component" (el conjunto de archivos que desea insertar en el servidor) y los ha versionado. Y la gestión de versiones incluye muchos otros pasos que no se pueden memorizar completamente en DVCS, como por ejemplo el proceso de des-variabilización donde se reemplazan variables dentro de archivos de configuración con valores reales adaptados al servidor de destino (números de puerto, rutas locales, ...) . Puede intentar administrar esos archivos de configuración directamente valorados a través de sucursales, pero en mi experiencia se vuelve rápidamente demasiado complejo para seguir.

  • colaboración: eso no está reservado para DVCS. (VCS también los ofrece). Tenga en cuenta que para algún formato (Documento de Word), su sistema de revisión interno podría ser más eficiente.

4

La formación es una preocupación real. Conozco bastantes físicos de partículas (grandes científicos con grandes proyectos de programación) cuyo conocimiento total de la fuente de control es cómo ejecutar las versiones ingenuas de cvs checkout, cvs update y cvs commit.

Sí, CVS. Conozco a un líder de un grupo de software que pospuso la mudanza a Subversion debido a esta gente.

En el siguiente nivel de habilidad también conocen los comandos diff y stat y cómo especificar ramas o etiquetas, pero pueden evitar la creación o fusión de ramas.

Si está planeando presentar un DVCS, planifique un programa de capacitación y apoyo intensivo y continuo.Los científicos (o al menos los físicos) suelen tener poca capacitación formal en informática, y pueden tener solo la más vaga concepción del proceso de software.

Cuestiones relacionadas