-
Notifications
You must be signed in to change notification settings - Fork 3
/
08-flujo.Rmd
238 lines (182 loc) · 10.5 KB
/
08-flujo.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
# Flujo de trabajo para Data Science
En esta parte hablaremos de flujos de trabajo
para análisis de datos. Recordemos el diagrama del flujo de un análisis de datos:
Quizá añadiendo que en este flujo una parte importante del trabajo
es *comunicar* los resultados y hallazgos de este ciclo.
El *flujo de trabajo* son las operaciones que hacemos para obtener
los resultados intermedios y finales de nuestro análisis (datos limpios, ajuste de un modelo, gráficas, reportes, etc.) Ningún flujo de trabajo es perfecto, pero quisiéramos promover aspectos como:
- **Reproducibilidad**: es posible reproducir las salidas de nuestro análisis de manera relativamente simple.
- **Eficiencia**: buscamos que nuestro flujo promueva pensar más
en nuestro análisis que en detalles y complicaciones de cómo producimos ese análisis.
- **Colaboración**: es relativamente fácil que varias personas
colaboren en un proyecto.
## Proyectos {-}
Como se explica en @advr, usuarios nuevos de R a veces
consideran como "real" el ambiente de trabajo y los objetos
que están ahí. Por eso muchas veces intentan preservar el
estado del ambiente en R, guardando los objetos que están en
memoria en un punto dado para recrear salidas o análisis.
Pero a la larga, es mejor pensar que lo que es "real" en nuestro
análisis son los *scripts* que producen esos objetos y salidas.
En términos de reproducibilidad y colaboración, guardar
colecciones grandes de objectos que son salidas no es
muy buena idea. Es difícil colaborar y reproducir resultados
compartiendo objectos grandes
que no sabemos exactamente cómo se crearon y que no tienen historial
de cambios, o peor aún, que su construcción requiere de
algunos comandos que no incluímos en scripts.
Es mejor pensar que **lo "real" son los scripts (el código)** que
generan las salidas. Esto es lo que queremos preservar, compartir,
y dar seguimiento conforme nuestro análisis avanza.
**Tip**: en las preferencias de RStudio, cambia si es
necesario a *nunca* guardar el ambiente de trabajo en .RData,
y *nunca* cargar al inicio
archivos .RData (en el menú Tools -> Global Options).
Todos el código de nuestro proyecto generalmente lo organizamos
bajo una misma carpeta, y comenzamos a trabajar en cada proyecto
poniendo nuestro **directorio de trabajo** en esa carpeta. Las referencias a nuestros archivos se hacen a partir de ese directorio
de trabajo.
#### Discusión {-}
En R existen `getwd()`y `setwd()` para leer y cambiar el directorio de trabajo (working directory). Podemos hacer:
```{r}
getwd()
```
Y también podríamos hacer
```{r, eval = FALSE}
setwd('/MiCompu/Documentos/trabajo/proyectos_divertidos/proyecto_z/')
```
Pero veremos que típicamente no necesitamos usar estos comandos.
La siguiente cita es tomada de [esta explicación](https://www.tidyverse.org/articles/2017/12/workflow-vs-script/)
> If the first line of your R script is
setwd("C:\\Users\\jenny\\path\\that\\only\\I\\have")
I will come into your office and SET YOUR COMPUTER ON FIRE 🔥. --Jenny Bryan
## Proyectos de RStudio {-}
Una alternativa que nos guía a buenas prácticas es usar los proyectos
de RStudio.
#### Ejercicio: crear un proyecto desde cero {-}
1. Crea un nuevo proyecto en R (en File -> New Project). Asegúrate de
ponerlo bajo control de versiones de *git*. Crea dos carpetas
nuevas dentro de tu proyecto, por ejemplo *salidas* y *graficas*.
Crea un script *1_graficar.R*. En el script haz una gráfica
con ggplot de algunos datos que estén disponibles en R, y que guarde la
gráfica en *graficas* y guarda los datos que usaste en la carpeta
*salidas* en formato csv. Haz también, en la consola *View* de tus
datos.
2. Crea otro proyecto en RStudio. Nota que la sesión comienza en blanco.
3. Ahora regresa a tu proyecto anterior (puedes usar el menú File,
o también el navegador de archivos y hacer click en el archivo *miproyecto.Rproj*. ¿Qué notas al regresar a tu proyecto
anterior?
4. Haz git commit de tu archivo *1_graficar.R*. ¿Qué piensas de poner
bajo control de versiones el contenido de *salidas* y *graficas*?
#### Ejercicio: crear un proyecto a partir de un repositorio {-}
1. Crea un nuevo proyecto en R, pero esta vez escoge crear a partir
de un repositorio. Utiliza esta liga de github, por ejemplo: https://github.com/tereom/quickcountmx.git. Este es un paquete de R,
por lo que tiene una estructura especial.
2. Examina el código en la
carpeta R. Haz un cambio en el archivo TODO y haz commit de tu nuevo archivo.
Examina el historial de cambios para este repositorio.
3. Cambia a tu proyecto original.
---
El flujo básico de trabajo cuando trabajamos con proyectos es:
- Empezamos con un ambiente limpio en R. Nótese que con la configuración de arriba, cada vez que abrimos un projecto comenzamos con un ambiente limpio en R
- Escribimos código (en unidades chicas), lo probamos. Si todo sale bien hacemos
commit.
- Conforme trabajamos, es buena idea reiniciar la sesión de R (Session->Restart R) y correr nuestros scripts completos -quizá utilizando resultados intermedios
para cómputos que toman mucho tiempo. De esta forma sabemos que los resultados
no dependen de algún comando o manipulación que hayamos hecho de manera interactiva.
- La idea siempre trabajar desde la carpeta raíz del proyecto (no es necesario cambiar directorios para correr distintas cosas).
- Cuando usamos proyectos de esta forma, todas nuestras rutas son siempre relativas a la raíz de nuestro proyecto. Por ejemplo, para cargar los datos que guardamos en el csv hacemos:
```{r, eval = FALSE}
read.csv('salidas/archivo.csv')
```
## Guías de estilo {-}
Las guías de estilo para escribir código tienen como propósito:
- Facilitar leer y escribir código: hay claras malas prácticas que dificultan
el trabajo y deben ser evitadas.
- Reducir la carga mental al colaborar en proyectos: mayor consistencia implica una cosa menos en la que tenemos que pensar.
Hay varias buenas opciones. Lo importante para un equipo es acordar un estilo. Dos predominantes son:
- [Guía de estilo del tidyverse](http://style.tidyverse.org/index.html)
- [Guía de estilo de Google](https://google.github.io/styleguide/Rguide.xml)
## Recomendaciones generales {-}
En [Good enough practices in scientific computing](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005510) se detallan recomendaciones generales para flujos de trabajo en análisis de datos:
1. Administración de datos
- Guarda los datos originales crudos.
- Crea los datos que quisieras ver en el mundo.
- Crea datos amigables para hacer análisis.
- Registra todos los pasos usados para procesar los datos.
- Anticipa el uso de múltiples tablas, creando identificadores
2. Software
- Comenta explicando el funcionamiento de scripts y funciones.
- Descompón problemas grandes en funciones.
- Elimina duplicación
- Busca paquetes/librerías que estén bien mantenidas
- Prueba paquetes/librerías antes de confiar en ellos
- Usa nombres con significado para funciones y variables
- Haz explícitas dependencias y requisitos para tu código.
- Evita comentar/descomentar secciones de código para controlar su funcionamiento.
- Crea ejemplos simples o datos para hacer pruebas
3. Colaboración
- Usa TODOs compartidos para el projecto.
- Decide en estrategias de comunicación.
4. Organización del proyecto
- Pon cada projecto en su propio directorio
- Agrega documentos de texto a un directorio de docs dentro el proyecto.
- Pon datos crudos y metadatos en un directorio de datos y archivos
generados en carpetas de resultados.
- Usa carpetas como lib o bin apra scripts externos o programas compilados
- Nombra archivos para que reflejen su contenido o función.
5. Control de cambios
- Respalda prácticamente todo lo que se creó por una persona en cuanto fue creado.
- Mantén chicos los cambios
- Comparte frecuentemente los cambios
- Crea y matén un checklist para colaborar en el proyecto.
- Usa control de versiones
6. Manuscritos
- Crea manuscritos con herramientas que se puedan usar online, control de cambios, control de formato y administración de referencias.
- Crea manuscritos en texto plano para permitir control de cambios.
## Cuadernos y Reportes {-}
R Markdown es un *framework* para producir documentos y reportes
dinámicos con facilidad y buena calidad.
Hay dos formas de trabajar con R Markdown:
- Cuadernos: similar a jupyter, están diseñados para correr de manera
interactiva.
- Reportes: diseñados para compilar completos y producir reportes
dinámicos.
## Reportes {-}
Crea un nuevo documento de RMarkdown (File -> New File -> R Markdown) y guárdalo
con el nombre que quieras en la carpeta *reports*. Presiona el
botón *Knit*. También puedes ir a la carpeta reports y ver la salida,
que es un archivo *html* que puedes abrir con tu navegador.
---
Nota en primer lugar que el documento tienen tres tipos de bloques:
1. El bloque inicial (donde están *title* y *output*). Estos son los
metadatos que indican cómo producir el reporte
2. Bloques de texto. Este es texto markdown (ver [markdown](https://pandoc.org/MANUAL.html#pandocs-markdown),
[filosofía y básicos](https://daringfireball.net/projects/markdown/)), que texto usual más
un lenguaje
para dar formatos básicos al texto, incluir listas, ligas, tablas,
imágenes entre otras cosas.
3. Bloques de código (se llaman **chunks**), que están rodeados de triples comas inversas. Su encabezado puede contener parámetros que definen cómo se evalúan y muestran
los resultados.
#### Ejercicio {-}
1. Agrega algún código adicional
como `cor(cars)` al primer chunk, por ejemplo.
Vuelve a hacer *knit* y examina los
resultados.
2. Sustituye la gráfica por una de ggplot2 (tienes que cargar el paquete
ggplot2).
## Cuadernos {-}
Los cuadernos usan la misma estructura de archivo que los reportes,
pero están hechos para trabajar de manera interactiva.
Crea un nuevo documento de RMarkdown (File -> New File -> R Notebook) y guárdalo
en la carpeta reports. Muévete al primer chunk y selecciona Run -> Run Current
Chunk (o presionado Cmd+Shift+Enter). Sustituye la gráfica por una de ggplot
y vuelve a correr el chunk.
En este caso, nota que se crea un archivo .nb.hmtl, que incluye tanto el Rmd
como la salida en html. Cuando abrimos un Rmd con formato de cuaderno,
utiliza las salidas en el html para mostrar las salidas en la misma ventana
del editor.
Otros recursos para aprender Rmarkdown:
- [R Markdown: The Definitive Guide](https://bookdown.org/yihui/rmarkdown/)
- [Guía para notebooks](https://rmarkdown.rstudio.com/r_notebooks)