Upgrade to Pro — share decks privately, control downloads, hide ads and more …

07 Tu Implementación

xihh87
June 15, 2020
55

07 Tu Implementación

Séptimo módulo de la primera edición del curso «Bioinformática Aplicada a Tu Proyecto».

xihh87

June 15, 2020
Tweet

Transcript

  1. Has explorado varios de los problemas que puedes encontrar al

    analizar tus datos y aprendido a: • Enfocar el trabajo. 3
  2. Has explorado varios de los problemas que puedes encontrar al

    analizar tus datos y aprendido a: • Enfocar el trabajo. • Automatizar tu flujo de trabajo. 3
  3. Has explorado varios de los problemas que puedes encontrar al

    analizar tus datos y aprendido a: • Verificar el análisis. 4
  4. Has explorado varios de los problemas que puedes encontrar al

    analizar tus datos y aprendido a: • Verificar el análisis. • Evaluar el poder estadístico. 4
  5. Con lo que has aprendido, puedes evitar: • Análisis sin

    rumbo. • Autopsias en vez de resultados. 5
  6. Con lo que has aprendido, puedes evitar: • Análisis sin

    rumbo. • Autopsias en vez de resultados. • Ilusión de saber. 5
  7. Además sabes cómo puedes: • Cambiar tu análisis cuando lo

    pida el revisor 2. • Revisar el historial de tu trabajo (bitácora). 6
  8. Además sabes cómo puedes: • Cambiar tu análisis cuando lo

    pida el revisor 2. • Revisar el historial de tu trabajo (bitácora). • Ofrecer evidencia de que tu flujo de trabajo es correcto (controles). 6
  9. La manera más sencilla de programar cuando eres principiante y

    hacer programas legibles cuando eres avanzado, sin escribir código.
  10. Cuanto más esfuerzo invertimos en nuestro trabajo, más nos enamoramos

    de él, incluyendo sus fallas. • A veces al enfrentarnos a un nuevo problema no sabemos por dónde empezar. 7
  11. Cuanto más esfuerzo invertimos en nuestro trabajo, más nos enamoramos

    de él, incluyendo sus fallas. • A veces al enfrentarnos a un nuevo problema no sabemos por dónde empezar. • Muchas veces empezamos a programar sin pensar y avanzamos hasta que sentimos que funciona. 7
  12. Cuanto más esfuerzo invertimos en nuestro trabajo, más nos enamoramos

    de él, incluyendo sus fallas. • A veces al enfrentarnos a un nuevo problema no sabemos por dónde empezar. • Muchas veces empezamos a programar sin pensar y avanzamos hasta que sentimos que funciona. • También es fácil ponernos a trabajar en detalles que no abonan a resolver el problema. 7
  13. El principal riesgo de un proyecto es no tener claro

    el objetivo (Project Management Institute 2017; Spolsky 2000) • Por eso documentamos el objetivo en primer lugar. 8
  14. El principal riesgo de un proyecto es no tener claro

    el objetivo (Project Management Institute 2017; Spolsky 2000) • Por eso documentamos el objetivo en primer lugar. • Los buenos programadores son 10 a 20 veces mejores que los programadores promedio (McConnell 2004) 8
  15. El principal riesgo de un proyecto es no tener claro

    el objetivo (Project Management Institute 2017; Spolsky 2000) • Por eso documentamos el objetivo en primer lugar. • Los buenos programadores son 10 a 20 veces mejores que los programadores promedio (McConnell 2004) • La principal diferencia entre los mejores programadores y los peores son los hábitos. 8
  16. Esta leyenda de la computación explica cómo funciona el método

    que vamos a usar (Knuth 1984) Todo el software tiene errores, con la posible excepción de las cosas escritas por Daniel J. Bernstein y Donald Knuth. Manual de CouchDB 9
  17. Es más sencillo pensar en lenguaje humano que en lenguaje

    de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. 10
  18. Es más sencillo pensar en lenguaje humano que en lenguaje

    de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. 10
  19. Es más sencillo pensar en lenguaje humano que en lenguaje

    de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. • Especificar hasta que se pueda escribir directamente en código. 10
  20. Es más sencillo pensar en lenguaje humano que en lenguaje

    de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. • Especificar hasta que se pueda escribir directamente en código. • Escribir código. 10
  21. Es más sencillo pensar en lenguaje humano que en lenguaje

    de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. • Especificar hasta que se pueda escribir directamente en código. • Escribir código. • Borrar comentarios redundantes. 10
  22. Las computadoras sólo entienden instrucciones numéricas de la forma “Instrucción

    17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… 11
  23. Las computadoras sólo entienden instrucciones numéricas de la forma “Instrucción

    17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… • intérprete (Python, R, awk, …) 11
  24. Las computadoras sólo entienden instrucciones numéricas de la forma “Instrucción

    17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… • intérprete (Python, R, awk, …) • compilador (C, Java, Rust, …) 11
  25. Las computadoras sólo entienden instrucciones numéricas de la forma “Instrucción

    17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… • intérprete (Python, R, awk, …) • compilador (C, Java, Rust, …) • A veces conviene usar lenguajes diseñados para una tarea particular (DSL, p.e. awk, CWL, yaml, …) 11
  26. Podemos decirle las etapas del análisis como pasos de mk

    • Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. 12
  27. Podemos decirle las etapas del análisis como pasos de mk

    • Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. 12
  28. Podemos decirle las etapas del análisis como pasos de mk

    • Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. 12
  29. Podemos decirle las etapas del análisis como pasos de mk

    • Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. • La forma más sencilla de hacer los controles es hacer una especie de examen para nuestro flujo de trabajo: 12
  30. Podemos decirle las etapas del análisis como pasos de mk

    • Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. • La forma más sencilla de hacer los controles es hacer una especie de examen para nuestro flujo de trabajo: • Tenemos cierta información en la entrada. 12
  31. Podemos decirle las etapas del análisis como pasos de mk

    • Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. • La forma más sencilla de hacer los controles es hacer una especie de examen para nuestro flujo de trabajo: • Tenemos cierta información en la entrada. • Sabemos que esa información debe dar un resultado. 12
  32. Cuando usas una nueva herramienta, el primer objetivo es saber

    que funciona. Siguiendo las reglas del desarrollo guiado por pruebas (TDD): • Primero haz que funcione. 13
  33. Cuando usas una nueva herramienta, el primer objetivo es saber

    que funciona. Siguiendo las reglas del desarrollo guiado por pruebas (TDD): • Primero haz que funcione. • Luego hazlo bien. 13
  34. Cuando usas una nueva herramienta, el primer objetivo es saber

    que funciona. Siguiendo las reglas del desarrollo guiado por pruebas (TDD): • Primero haz que funcione. • Luego hazlo bien. • Después hazlo rápido. 13
  35. Actividad 1: Hacer que mk haga la primera etapa de

    mi análisis. git clone https://gitlab.com/bioinfo…/[mi-repo] [aquí] cd [aquí] $EDITOR mkfile mk analisis/mi-archivo git push -u origin 14
  36. Para resolver un problema lo más importante es identificar la

    causa (Litt 1996) • Identificar el problema es el 80% de la solución. 15
  37. Para resolver un problema lo más importante es identificar la

    causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. 15
  38. Para resolver un problema lo más importante es identificar la

    causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. • Saltarse pasos puede agregar horas de trabajo. 15
  39. Para resolver un problema lo más importante es identificar la

    causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. • Saltarse pasos puede agregar horas de trabajo. • Git nos puede ayudar a identificar dónde está el problema si hiciste muchos cambios juntos. 15
  40. Para resolver un problema lo más importante es identificar la

    causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. • Saltarse pasos puede agregar horas de trabajo. • Git nos puede ayudar a identificar dónde está el problema si hiciste muchos cambios juntos. • Los controles nos pueden ayudar a identificar cuándo ocurre el problema. 15
  41. No hay alternativas a saber cómo funcionan los sistemas (Spolsky

    2002) Algunos problemas muy comunes que nos podemos encontrar: • No encuentra el archivo. 16
  42. No hay alternativas a saber cómo funcionan los sistemas (Spolsky

    2002) Algunos problemas muy comunes que nos podemos encontrar: • No encuentra el archivo. • No tiene permisos (lectura, escritura, ejecución). 16
  43. No hay alternativas a saber cómo funcionan los sistemas (Spolsky

    2002) Algunos problemas muy comunes que nos podemos encontrar: • No encuentra el archivo. • No tiene permisos (lectura, escritura, ejecución). • Configuración incorrecta. 16
  44. El material de este módulo está basado en: Knuth, D.

    E. 1984. “Literate Programming.” The Computer Journal 27 (2): 97–111. https://doi.org/10.1093/comjnl/27.2.97. Litt, Steve. 1996. “The Universal Troubleshooting Guide.” 1996. http://troubleshooters.com/ustep6.htm. McConnell, Steve. 2004. Code Complete. 2nd ed. Redmond, Wash: Microsoft Press. Project Management Institute, ed. 2017. A Guide to the Project Management Body of Knowledge / Project Management Institute. Sixth edition. PMBOK Guide. Newtown Square, PA: Project Management Institute. Spolsky, Joel. 2000. “Painless Functional Specifications – Part 1: Why Bother?” Joel on Software. October 2, 2000. https://www.joelonsoftware.com/2000/10/02/painless-functional- specifications-part-1-why-bother/. 22