├── .gitignore ├── Como_escribir_funciones_en_R ├── Cómo escribir funciones en R.rmd ├── Cómo-escribir-funciones-en-R.docx ├── Ecosistemas_template.docx ├── ecosistemas.csl ├── knitcitations.bib └── references.bib ├── Git-GitHub_Astigarraga_CruzAlonso ├── 2318-Texto del artículo-10878-1-2-20211118.docx ├── Rmd │ ├── .gitignore │ ├── Ecosistemas_template.docx │ ├── ecosistemas.csl │ ├── git_github.Rmd │ ├── images │ │ ├── arboles.jpg │ │ ├── arboles.png │ │ ├── conexiones.png │ │ ├── git.png │ │ ├── merge.png │ │ └── workflow_git_github.png │ └── references.bib └── git_github_ver_rev.docx ├── GitHub_para_Ecologos ├── imagenes │ ├── Procastination_poem.png │ ├── diff.png │ └── history_commits.png ├── ms_JGP.Rmd ├── ms_JGP.docx ├── ms_JGP.html └── references.bib ├── README.md ├── VegX ├── VegX_Nota_Ecosistemas.docx ├── VegX_Nota_Ecosistemas_FRS.docx └── vegX ├── WhyBayesian └── NotaEcosistemas_09may.docx ├── cienciometria └── cienciometria.docx ├── consejos_mejor_codigo ├── consejos_mejor_codigo.Rmd ├── consejos_mejor_codigo.docx └── consejos_mejor_codigo.pdf ├── crear_paquetes_R ├── ecosistemas.csl ├── notaAEET_crear_paquetes_R.rmd └── references.bib ├── directrices_revisores.MD ├── estadistica_circular ├── .gitignore ├── README.md ├── ecosistemas.csl ├── knitcitations_estadistica_circular.bib ├── manuscript_estadistica_circular.Rmd ├── manuscript_estadistica_circular.docx ├── manuscript_estadistica_circular_enviado.docx └── references_estadistica_circular.bib ├── interpretacion-modelos-lineales ├── linear models & p-values.docx ├── linear models & p-values_FRS.docx ├── linear models & p-values_V2.docx ├── linear models & p-values_V2_FRS.docx └── linear models & p-values_V3.docx ├── markup ├── Ecoinf.Rmd ├── Ecoinf.docx ├── Ecoinf2.docx ├── Ecoinf2_FRS.docx ├── Ecosistemas_template.docx ├── ecosistemas.csl ├── references.bib └── ~$Ecoinf.docx ├── multimodel_inference ├── fig_1.pdf ├── fig_1.pptx └── multimodel_inference.docx ├── ropensci ├── Ecosistemas_template.docx ├── ecosistemas.csl ├── knitcitations.bib ├── ropensci.Rmd └── ropensci.docx └── template ├── .gitignore ├── Ecosistemas_template.docx ├── ecosistemas.csl ├── plantilla_NotaEcoinf.Rmd ├── plantilla_NotaEcoinf.qmd └── references.bib /.gitignore: -------------------------------------------------------------------------------- 1 | .Rproj.user 2 | .Rhistory 3 | .RData 4 | .Ruserdata 5 | Notas_Ecosistemas.Rproj 6 | .DS_Store 7 | -------------------------------------------------------------------------------- /Como_escribir_funciones_en_R/Cómo escribir funciones en R.rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Cómo escribir funciones en R \n" 3 | 4 | author: Marcelino de la Cruz Rot^1^ 5 | 6 | output: 7 | word_document: 8 | fig_caption: yes 9 | fig_height: 6 10 | fig_width: 7.5 11 | highlight: null 12 | reference_docx: Ecosistemas_template.docx 13 | 14 | csl: ecosistemas.csl 15 | bibliography: 16 | - references.bib 17 | - knitcitations.bib 18 | --- 19 | 20 | 21 | > (1) Departmento de Biología y Geología, Física y Química Inorgánica. ESCET. Universidad Rey Juan Carlos. Móstoles. 22 | 23 | > Autor para correspondencia: Marcelino de la Cruz Rot [marcelino.delacruz@urjc.es] 24 | 25 | 26 | # Palabras clave 27 | 28 | > Doble estandarización; métodos S3; ordenación Bray-Curtis; ordenación polar. 29 | 30 | 31 | # Keywords 32 | 33 | > Bray-Curtis ordination; double standardization; Polar ordination; S3 methods. 34 | 35 | 36 | ```{r knitcitations, echo=FALSE, cache = FALSE} 37 | library(knitcitations) 38 | cleanbib() 39 | cite_options(citation_format = "pandoc") 40 | ``` 41 | 42 | 43 | 44 | # Por qué es útil escribir funciones en R. 45 | 46 | La respuesta más sencilla es porque todo en R `r citep(citation())` se basa en funciones. Las funciones permiten repetir de forma sencilla (escribiendo menos código) y fiable (evitando errores, consecuencia de lo anterior) los mismos cálculos sobre diferentes conjuntos de datos. Imaginemos que queremos poner a punto en R el clásico método de la ordenación polar [@Bray_1957] para estudiar [Falta dar contexto al lector brevemente sobre para que sirve esto](). Como didácticamente resumen Gauch y Scruggs [-@Gauch_1980], los pasos a seguir serían: 47 | 48 | 1) Realizar una estandarización doble de la matriz de inventarios. 49 | 2) Calcular la disimilitud entre inventarios. 50 | 3) Proyectar los inventarios sobre el eje de ordenación. 51 | 52 | Para este ejemplo, usaremos la comunidad de pastizales de dunas que vienen con el paquete `vegan` [@Oksanen_2019]. 53 | 54 | ```{r, echo=FALSE} 55 | library(vegan) 56 | data(dune) 57 | ``` 58 | 59 | ```{r, eval=F} 60 | library(vegan) 61 | data(dune) 62 | head(dune) 63 | ``` 64 | 65 | La denominada "doble estandarización" consiste en realidad en realizar dos normalizaciones consecutivas de la matriz de datos: la primera, dividiendo los valores de las columnas por el valor máximo de cada una y la segunda, dividiendo las filas por la suma total de cada una. Si no sabemos crear funciones, cada vez que necesitemos estandarizar deberemos escribir dos bucles `for()` 66 | 67 | ```{r} 68 | dune.s1<- NULL #creamos un objeto vacio para guardar calculos intermedios 69 | dune.s2 <- NULL #creamos un objeto vacio para guardar valores finales 70 | for( i in 1: ncol(dune)) dune.s1 <- cbind(dune.s1, dune[,i]/max(dune[,i])) 71 | for(j in 1:nrow(dune.s1)) dune.s2 <- rbind(dune.s2, dune.s1[j,]/sum(dune.s1[j,])) 72 | ``` 73 | Seguramente habremos leído en alguna parte que la función `apply()` posibilita una manera más elegante de trabajar con matrices y `data.frame`s evitando los engorrosos bucles. Claro, que para ello es necesario disponer de una **función** que *aplicar* a las filas o columnas. 74 | 75 | 76 | # Definiendo funciones en R 77 | 78 | Una función en R se crea usando la función `function()`. Los requisitos necesarios para crearla son: 1) darle nombre, 2) definir su(s) argumento(s) y 3) escribir el código de la función. Por ejemplo, una función para normalizar un vector por su máximo valor la podríamos definir como 79 | ```{r} 80 | standmax <- function(x) x/max(x) 81 | ``` 82 | Aquí, `standmax` sería el nombre de la función, `x` sería el argumento (la representación simbólica del objeto que vamos a manipular con el código de nuestra función) y `x/max(x)` constituiría todo el código de la misma. A la hora de dar nombre a nuestra función o a sus argumentos tenemos casi total libertad, la misma que al crear cualquier nuevo objeto en R. 83 | 84 | Siguiendo el mismo proceso, otra función para normalizar por la suma total sería: 85 | ```{r} 86 | standtot <- function(x) x/sum(x) 87 | ``` 88 | Y con estas dos funciones podríamos realizar la "doble estandarización" de forma más sencilla que con el engorroso bucle: 89 | ```{r} 90 | dune.s1 <- apply(dune, 2, standmax) 91 | dune.s2 <- t(apply(dune.s1, 1, standtot)) #COMMENT IB: Quizas es mejor usar MARGIN=2, para evitar perder a gente con t(). Además, nombrar todas los parametros seria importante X = , FUN = ... por claridad. 92 | ``` 93 | Alternativamente, en vez de dos funciones, podríamos hacer una que realice varios tipos de normalización, por ejemplo: 94 | 95 | ```{r} 96 | stand <- function(x, type="max") if(type=="max") x/max(x) else x/sum(x) 97 | ``` 98 | En este caso, además del argumento `x`, que representa la tabla de datos, incluimos el argumento `type`, que por defecto dejamos inicializado en `"max"`. Sólo habrá que modificarlo si queremos realizar la normalización por la suma. Por lo tanto, la doble estandarización la realizaríamos así: 99 | 100 | ```{r} 101 | dune.s1 <- apply(dune, 2, stand) 102 | dune.s2 <- t(apply(dune.s1, 1, stand, type="tot")) 103 | ``` 104 | 105 | Claro que, ya puestos, podríamos crear una función que realice todo el proceso, por ejemplo: 106 | ```{r} 107 | doblestand <- function(x){ 108 | x.s1 <- apply(x, 2, standmax) 109 | x.s2 <- t(apply(x.s1, 1, standtot)) 110 | return(x.s2) 111 | } 112 | ``` 113 | Nótese que en este caso, como la función consta de varios pasos, encerramos el código entre llaves (`{}`). Además, como durante el proceso creamos varios objetos, pero sólo el último (`x.s2`) es el que contiene el resultado que nos interesa, especificamos su devolución con la función `return()`. Por último, es conveniente emplear identación o sangrado al escribir el código dentro de la función para mejorar su legilibilidad (aunque no es obligatorio). 114 | 115 | Con la nueva función, nuestros análisis serían mucho más simples: 116 | 117 | ```{r, eval=FALSE} 118 | doblestand(dune) 119 | ``` 120 | 121 | # Una función más compleja. 122 | De las 36 variantes existentes de ordenación polar [@Gauch_1980], la que más nos conviene para este ejemplo sustituye el cálculo del porcentaje en disimilaridad (en el paso 2) por el cálculo de la distancia euclídea entre inventarios [@Orl_ci_1974]. En el paso final (3), la opción mas sencilla consistiría en colocar los inventarios sobre el eje representado por la distancia entre los más alejados ($A$ y $B$) mediante una proyección pitagórica, en base a la ecuación: 123 | $$X_i = \frac{D_{A,B}^2+D_{A,i}^2-D_{i,B}^2}{2D_{A,B}},$$ 124 | donde $X_{i}$ es la posición del inventario $i$ en el eje de ordenación, $D_{A,B}$ es la distancia entre los inventarios extremos $A$ y $B$, y $D_{A,i}$ y $D_{i,B}$ son las distancias del inventario $i$ a ambos extremos. 125 | 126 | ```{r} 127 | opolar<- function(x){ 128 | 129 | # doble estandarización 130 | x.s<- doblestand(x) 131 | 132 | # matriz de distancia ecuclidea 133 | D <- as.matrix(dist(x.s)) 134 | 135 | # proyección 136 | DAB <- max(D) 137 | AB <- which(!is.na(apply(D,1,function(x) 138 | ifelse(DAB%in%x, which(x==DAB), NA)))) 139 | A <-AB[1] 140 | B<- AB[2] 141 | X<- sapply((1:nrow(D)), function(i) ((D[A,i]^2) 142 | -(D[B,i]^2)+(DAB^2))/(2*DAB)) 143 | 144 | # prepara y devuelve el resultado 145 | name.x <- deparse(substitute(x)) 146 | result <- list(A=A, B=B, X=X, namex= name.x) 147 | class(result) <- c("miopolar", class(result)) 148 | return(result) 149 | } 150 | ``` 151 | En esta función hemos incluído ya los tres pasos de la ordenación polar. Es importante notar que, excepto el tercero, cada paso está codificado en una función independiente: esto otorga **modularidad** a nuestro código, lo que facilita su actualización y corrección si fuese necesario, además de mejorar su legibilidad y comprensión. Para esto último es conveniente también incluir comentarios (precedidos por el símbolo **#**), explicando lo que hace cada bloque (o en su caso línea) de código. Como resultado de la ordenación polar tenemos varios objetos: el número de los inventarios extremos (`A` y `B`), la posición de los inventarios en el eje de ordenación (`X`) y el nombre de la tabla de datos original (`name.x`). La forma más conveniente de devolver varios objetos es dentro de una lista (a la que denominamos `resultado`). Y como queremos facilitarnos la vida, a dicha lista (que es un objeto de clase `list`) le asignamos una nueva clase (`miopolar`), completamente inventada, lo que nos permitirá desarrollar métodos específicos para presentar los resultados de nuestra función de manera cómoda. 152 | 153 | La simplicidad que aporta una función de R queda aparente en la siguiente frase 154 | 155 | ```{r} 156 | dune.o <- opolar(dune) 157 | ``` 158 | 159 | # Funciones especiales: métodos `S3`. 160 | A muchos usuarios de R novatos les parece mágico cómo, usando la misma función `plot()`, R dibuja el gráfico adecuado para cada tipo de datos. Lo que ocurre es que no hay una sino muchas funciones `plot()` (en realidad, muchos *métodos*: teclear en la consola `methods(plot)`). De la misma manera, existen numerosos métodos `print`, que controlan la información que se presenta en pantalla cuando escribimos el nombre de cualquier objeto de R. Podemos crear fácilmente métodos (`print`, `plot`, `summary`, etc) para objetos creados con nuestra función combinando el nombre del método con el de la clase del objeto devuelto por la función. Por ejemplo, un método `print` que nos describa nuestra ordenación sería algo así: 161 | 162 | ```{r} 163 | print.miopolar <- function(x,...){ 164 | cat("Ordenación polar de", x$name, "a lo largo de un gradiente de longitud", max(X), "\n") 165 | } 166 | ``` 167 | El método `print` no es necesario invocarlo explícitamente. Una vez que lo hayamos creado, cada vez que escribamos el nombre de un objeto de la clase nos escribirá en pantalla la descripción. 168 | ```{r} 169 | dune.o 170 | ``` 171 | Un método `plot` lo podemos definir así: 172 | ```{r} 173 | plot.miopolar <- function(x, ...){ 174 | X<- x$X 175 | Y <- rep(0, length(X)) 176 | borde <- max(X)/10 177 | plot(cbind(c(-borde, max(X)+borde), c(-1,1)), type="n", 178 | main="ordenación", xlab="", ylab="") 179 | segments(0,0,max(X),0) 180 | points(cbind(X,Y), ...) 181 | text(cbind(X,jitter(Y, amount=1/7)), labels=1:length(X),cex=0.7) 182 | } 183 | ``` 184 | En los métodos `S3` es muy frecuente incluir los puntos suspensivos (*dots*, `...`) en el campo de argumentos (aunque se pueden incluir en cualquier función). Se emplean para pasar argumentos adicionales a alguna función interna del método. En este ejemplo, cualquier argumento adicional que incluyamos, se traspasará directamente a la función `points()`, que es donde vuelven a aparecer los `...`. Por lo tanto deberán ser argumentos aceptados por dicha función. Es el caso de la Figura 1. Nótese que no es necesario escribir el nombre completo de la function (plot.miopar) sino simplemente el método que codifica. 185 | ```{r, eval=FALSE} 186 | plot(dune.o) 187 | plot(dune.o, pch=19, col=2) 188 | ``` 189 | 190 | # Mejorando las funciones. 191 | Entre las posibles mejoras que podríamos aplicar a nuestra función estarían compactar el paso 3 (proyección) en una función independendiente e implementar la extracción de ejes de ordenación complementarios [@Bray_1957] para que pudiésemos representar los típicos diagramas de ordenación basados en dos ejes, como en un PCA o en un NMDS [@Borcard_2018]. Lógicamente, deberíamos modificar también el método `plot.miopolar()`. Para un lector de la revista Ecosistemas con interés por la ecoinfomática esto no debería resultar muy complicado. Y dado que estamos creando muchas funciones complementarias, podríamos ir pensando en crear un paquete de R para distribuirlas conjuntamente. 192 | 193 | 194 | 195 | # Agradecimientos 196 | 197 | REMEDINAL TE-CM (S2018/EMT-4338). 198 | 199 | 200 | 201 | 202 | 203 | ###### REFERENCIAS 204 | 205 | ```{r write_citations, cache=FALSE, include=FALSE} 206 | write.bibtex(file = "knitcitations.bib") 207 | #write.bibtex(file = "references.bib") 208 | ``` 209 | 210 |
211 | 212 | 213 | 214 | ###### PIES DE FIGURA 215 | 216 | **Figura 1**. Representación gráfica de la ordenación polar de dune. 217 | 218 | 219 | 220 | ###### FIGURE LEGENDS 221 | 222 | **Figure 1**. Graphical representation of the polar ordination of the 'dune' data. 223 | 224 | 225 | ###### FIGURA 1 226 | 227 | ```{r Fig1, echo=FALSE, fig.cap="Figura 1. Representación gráfica de la ordenación polar de los datos 'dune'", cache=FALSE} 228 | plot(dune.o, pch=19, col=2) 229 | ``` 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | -------------------------------------------------------------------------------- /Como_escribir_funciones_en_R/Cómo-escribir-funciones-en-R.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Como_escribir_funciones_en_R/Cómo-escribir-funciones-en-R.docx -------------------------------------------------------------------------------- /Como_escribir_funciones_en_R/Ecosistemas_template.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Como_escribir_funciones_en_R/Ecosistemas_template.docx -------------------------------------------------------------------------------- /Como_escribir_funciones_en_R/ecosistemas.csl: -------------------------------------------------------------------------------- 1 | 2 | 186 | -------------------------------------------------------------------------------- /Como_escribir_funciones_en_R/knitcitations.bib: -------------------------------------------------------------------------------- 1 | @Manual{R_Core_Team_2019, 2 | title = {R: A Language and Environment for Statistical Computing}, 3 | author = {{R Core Team}}, 4 | organization = {R Foundation for Statistical Computing}, 5 | address = {Vienna, Austria}, 6 | year = {2019}, 7 | url = {https://www.R-project.org/}, 8 | } 9 | -------------------------------------------------------------------------------- /Como_escribir_funciones_en_R/references.bib: -------------------------------------------------------------------------------- 1 | % Encoding: UTF-8 2 | @Book{Borcard_2018, 3 | doi = {10.1007/978-3-319-71404-2}, 4 | url = {https://doi.org/10.1007/978-3-319-71404-2}, 5 | year = {2018}, 6 | publisher = {Springer International Publishing}, 7 | author = {Daniel Borcard and Fran{\c c}ois Gillet and Pierre Legendre}, 8 | title = {Numerical Ecology with R}, 9 | } 10 | 11 | @Article{Bray_1957, 12 | doi = {10.2307/1942268}, 13 | url = {https://doi.org/10.2307/1942268}, 14 | year = {1957}, 15 | month = {feb}, 16 | publisher = {Wiley}, 17 | volume = {27}, 18 | number = {4}, 19 | pages = {325--349}, 20 | author = {J. Roger Bray and J. T. Curtis}, 21 | title = {An Ordination of the Upland Forest Communities of Southern Wisconsin}, 22 | journal = {Ecological Monographs}, 23 | } 24 | 25 | @Article{Gauch_1980, 26 | author = {H.G. Gauch and W.M. Scruggs}, 27 | title = {Variants of polar ordination}, 28 | journal = {Vegetatio}, 29 | year = {1980}, 30 | volume = {40}, 31 | number = {3}, 32 | pages = {147--153}, 33 | month = {feb}, 34 | doi = {10.1007/bf00228478}, 35 | publisher = {Springer Nature}, 36 | url = {https://doi.org/10.1007/bf00228478}, 37 | } 38 | 39 | @Manual{Oksanen_2019, 40 | title = {vegan: Community Ecology Package}, 41 | author = {Jari Oksanen and F. Guillaume Blanchet and Michael Friendly and Roeland Kindt and Pierre Legendre and Dan McGlinn and Peter R. Minchin and R. B. O'Hara and Gavin L. Simpson and Peter Solymos and M. Henry H. Stevens and Eduard Szoecs and Helene Wagner}, 42 | year = {2019}, 43 | note = {R package version 2.5-5}, 44 | url = {https://CRAN.R-project.org/package=vegan}, 45 | } 46 | 47 | @Article{Orl_ci_1974, 48 | doi = {10.1139/b74-229}, 49 | url = {https://doi.org/10.1139/b74-229}, 50 | year = {1974}, 51 | month = {jul}, 52 | publisher = {Canadian Science Publishing}, 53 | volume = {52}, 54 | number = {7}, 55 | pages = {1773--1776}, 56 | author = {L{\a'a}szl{\a'o} Orl{\a'o}ci}, 57 | title = {Revisions for the Bray and Curtis ordination}, 58 | journal = {Canadian Journal of Botany}, 59 | } 60 | 61 | @Manual{R_Core_Team_2019, 62 | title = {R: A Language and Environment for Statistical Computing}, 63 | author = {{R Core Team}}, 64 | organization = {R Foundation for Statistical Computing}, 65 | address = {Vienna, Austria}, 66 | year = {2019}, 67 | url = {https://www.R-project.org/}, 68 | } 69 | 70 | @Comment{jabref-meta: databaseType:bibtex;} 71 | -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/2318-Texto del artículo-10878-1-2-20211118.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/2318-Texto del artículo-10878-1-2-20211118.docx -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/.gitignore: -------------------------------------------------------------------------------- 1 | # History files 2 | .Rhistory 3 | .Rapp.history 4 | # Session Data files 5 | .RData 6 | # User-specific files 7 | .Ruserdata 8 | # Example code in package build process 9 | *-Ex.R 10 | # Output files from R CMD build 11 | /*.tar.gz 12 | # Output files from R CMD check 13 | /*.Rcheck/ 14 | # RStudio files 15 | .Rproj.user/ 16 | # produced vignettes 17 | vignettes/*.html 18 | vignettes/*.pdf 19 | # OAuth2 token, see https://github.com/hadley/httr/releases/tag/v0.3 20 | .httr-oauth 21 | # knitr and R markdown default cache directories 22 | *_cache/ 23 | /cache/ 24 | # Temporary files created by R markdown 25 | *.utf8.md 26 | *.knit.md 27 | # R Environment Variables 28 | .Renviron 29 | nota_git_github.Rproj 30 | git_github.docx 31 | revision 32 | -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/Ecosistemas_template.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/Ecosistemas_template.docx -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/ecosistemas.csl: -------------------------------------------------------------------------------- 1 | 2 | 186 | -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/git_github.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "¡Se puede entender cómo funcionan Git y GitHub!" 3 | 4 | author: Julen Astigarraga^1^, Verónica Cruz-Alonso^2^ 5 | 6 | output: 7 | word_document: 8 | fig_caption: yes 9 | fig_height: 6 10 | fig_width: 7.5 11 | highlight: null 12 | reference_docx: Ecosistemas_template.docx 13 | 14 | csl: ecosistemas.csl 15 | 16 | bibliography: references.bib 17 | --- 18 | 19 | > (1) Universidad de Alcalá, Grupo de Ecología Forestal y Restauración (FORECO), Departamento de Ciencias de la Vida, 28805 Alcalá de Henares (Madrid), España 20 | > (2) Department of Landscape Architecture, Graduate School of Design, Harvard University, 02138 Cambridge MA, Estados Unidos 21 | 22 | > Autor para correspondencia: [julenastigarraga\@gmail.com](mailto:author@gmail.com){.email}, [veronica.cral\@gmail.com](mailto:author@gmail.com){.email} 23 | 24 | > Contribución de los autores: 25 | > 26 | > Julen Astigarraga: conceptualización y redacción -- borrador original. Verónica Cruz-Alonso: conceptualización, visualización y redacción -- revisión y edición. 27 | 28 | # Palabras clave 29 | 30 | > ciencia abierta; control de versiones; trazabilidad; reproducibilidad 31 | 32 | # Keywords 33 | 34 | > open science; reproducibility; traceability; version control 35 | 36 | La reproducibilidad, entendida como la capacidad que tienen algunos trabajos o proyectos de ser recreados de forma independiente a partir de los mismos datos y el mismo código que utilizó el equipo original [@theturingwaycommunity2021], es una condición *sine qua non* del método científico [@peng2011]. Algunos autores plantean que gran parte de la ecología es ya una ciencia de *big data* [@hampton2013; @farley2018], lo que hace indispensable utilizar herramientas informáticas que garanticen la trazabilidad de todo el proceso de desarrollo de proyectos (desde su creación hasta su publicación), asegurando de esta manera su reproducibilidad [@rodríguez-sánchez2016]. En este sentido, es recomendable utilizar alguna herramienta de control de versiones como Git () combinada con plataformas en línea para albergar los proyectos (p. ej. GitHub, ), facilitando así el seguimiento de los proyectos y la coordinación entre colaboradores [@blischak2016; @galeano2018; @rodríguez-sánchez2020]. Aunque existen multitud de manuales disponibles gratuitamente sobre cómo utilizar Git y GitHub (ver Apéndice 1), estas herramientas son complejas y tienen una curva de aprendizaje pronunciada. El objetivo de la presente nota es dar a conocer la estructura, funcionalidad y potencialidad de Git, así como su interacción con GitHub, para el trabajo en proyectos colaborativos en ecología. 37 | 38 | # ¿Qué es Git? 39 | 40 | Git es un sistema avanzado de control de versiones (como el "control de cambios" de Microsoft Word) distribuido [@blischak2016; @ram2013]. Git permite "rastrear" el progreso de un proyecto a lo largo del tiempo ya que hace "capturas" del mismo a medida que evoluciona y los cambios se van registrando. Esto permite ver qué cambios se hicieron, quién los hizo y por qué, e incluso volver a versiones anteriores (**Fig. 1**). Además, Git facilita el trabajo en paralelo de varios participantes. Mientras que en otros sistemas de control de versiones (p. ej. Subversion (SVN, ) o Concurrent Versions System (CVS, )) hay un servidor central y cualquier cambio hecho por un usuario se sincroniza con este servidor y de ahí con el resto de usuarios, Git es un control de versiones distribuido que permite a todos los usuarios trabajar en el proyecto paralelamente e ir haciendo "capturas" del trabajo de cada uno para luego unirlos. Otras alternativas de control de versiones distribuido comparables a Git son Mercurial () o Bazaar (), pero Git es con diferencia el más utilizado. 41 | 42 | # ¿Qué es GitHub? 43 | 44 | GitHub es un servidor de alojamiento en línea o repositorio remoto para albergar proyectos basados en Git que permite la colaboración entre diferentes usuarios o con uno mismo [@galeano2018; @perez-riverol2016]. Un repositorio es un directorio donde desarrollar un proyecto que contiene todos los archivos necesarios para el mismo. Aunque existen distintos repositorios remotos (p. ej. GitLab, , o Bitbucket, ) con funcionalidad similar, GitHub es hoy en día el más utilizado. GitHub registra el desarrollo de los proyectos de manera remota, permite compartir proyectos entre distintos usuarios y proporciona la seguridad de la nube entre otras funciones. Cuando se trabaja en proyectos colaborativos, la base de la interacción entre Git y GitHub es que todos los colaboradores de un proyecto están de acuerdo en que GitHub contiene la copia principal del proyecto, es decir, GitHub contiene la copia centralizada del control de versiones distribuido o descentralizado (**Fig. 2**). 45 | 46 | # Flujo de trabajo en Git y GitHub 47 | 48 | Git es capaz de rastrear todos los archivos contenidos en un repositorio. Para comprender cómo Git registra los cambios y cómo podemos compartir dichos cambios con nuestros colaboradores es importante entender cómo se estructura Git y cómo se sincroniza con GitHub. Hay cuatro "zonas" de trabajo (**Fig. 3**): 49 | 50 | 1. **Directorio de trabajo (*working directory*):** es donde se está trabajando. Esta zona se sincroniza con los archivos locales del ordenador. 51 | 52 | 2. **Área de preparación (*staging area* o *Index*):** es la zona intermedia entre el directorio de trabajo y el repositorio local de Git. Es la zona de borradores. El usuario debe seleccionar los archivos que se van a registrar en la siguiente "captura" de Git. 53 | 54 | 3. **Repositorio local (*local repository* o *HEAD*):** es donde se registran todos los cambios capturados por Git en tu ordenador. 55 | 56 | 4. **Repositorio remoto (*remote repository*):** es donde se registran todos los cambios capturados por Git en la nube (GitHub). 57 | 58 | Si se ejecuta Git desde la línea de comandos de *Unix shell* (para más información sobre el *shell* o terminal ver ), la transición entre zonas de trabajo se realiza mediante comandos (**Fig. 4**). Adicionalmente, también se puede trabajar en Git a través de un cliente, como RStudio (), que incorpora una pestaña llamada "Git" que facilita la transición entre zonas de trabajo ya que contiene funcionalidades básicas de Git. Usar un cliente como RStudio es recomendable para usuarios noveles de Git (ver ). 59 | 60 | El primer paso para trabajar con Git es crear un repositorio en GitHub (repositorio remoto) y clonarlo en nuestro ordenador (repositorio local; para hacerlo desde RStudio ver , y para hacerlo mediante la línea de comandos ver @galeano2018). Para añadir una actualización de algún archivo del directorio de trabajo al área de preparación se utiliza el comando `git add `. Este comando indica a Git que se quieren incluir las actualizaciones de algún archivo en la próxima "captura" del proyecto y que Git las registre. Sin embargo, `git add` no afecta al repositorio local. Para ver el estado del directorio de trabajo y del área de preparación se utiliza `git status`. Este comando permite ver qué archivos están siendo rastreados por Git, qué cambios han sido añadidos al área de preparación (*staged*) y qué archivos están siendo registrados por Git. 61 | 62 | Para registrar los cambios que nos interesan se utiliza `git commit`. Al ejecutar `git commit` se hace una "captura" del estado del proyecto. Junto con el *commit* se añade un mensaje con una pequeña explicación de los cambios realizados y por qué (p. ej. "incluyo las referencias en el formato de Ecosistemas"). Cada `git commit` tiene un SHA (Secure Hash Algorithm) que es un código alfanumérico que identifica inequívocamente ese *commit* (p. ej. 1d21fc3c33cxxc4aeb7823400b9c7c6bc2802be1). Con el SHA siempre se pueden ver los cambios que se hicieron en ese *commit* y volver a esa versión fácilmente. 63 | 64 | Por último, `git push` permite subir los cambios que hemos hecho a GitHub y quedarán visibles para nuestros colaboradores. Básicamente, `git commit` registra los cambios en el repositorio local y `git push` actualiza el repositorio remoto con los cambios y archivos asociados. Cuando se retoma un proyecto tras horas, días o incluso meses, con `git pull` se descargan todas las actualizaciones que haya en GitHub (nuestras o de nuestros colaboradores), que se fusionarán (*merge*) con el último *commit* en nuestro repositorio local. 65 | 66 | # ¿Cómo se puede trabajar paralelamente? 67 | 68 | Git permite crear una "rama" (*branch*) paralela al proyecto si se desea seguir una línea independiente de trabajo, bien por ser diferente de la principal (p. ej. probar un nuevo análisis) o bien para desarrollar específicamente una parte del proyecto (p. ej. trabajar sólo en la escritura de los métodos de un artículo mientras otros colaboradores trabajan en otras secciones). Las ramas permiten trabajar en el proyecto sin interferir con lo que están haciendo los compañeros (**Fig. 5**). En Git, una rama es un *commit* al que le se le da un nombre y que contiene un "enlace" (puntero o *pointer*) a un SHA específico que es el origen de la rama. La rama *main* es la rama por defecto cuando se crea un repositorio. Las demás ramas se crean con `git checkout -b `. Para moverse de una rama a otra se utiliza `git checkout ` (p. ej. `git checkout main` para volver a la rama principal). 69 | 70 | Cuando el trabajo desarrollado en una rama se da por finalizado y se quiere unir a la rama principal *main* hay que hacer la unión utilizando el comando `git merge` (**Fig. 5**). Con `git checkout main` se posiciona el puntero de Git en el último *commit* de la rama principal a la que quiero unir la otra rama y con `git merge ` se fusionan los cambios hechos en las dos ramas. Esto se puede hacer en el *shell* como acabamos de ver pero también se puede hacer con el botón "*pull request*" en la página del proyecto en GitHub (ver @galeano2018). 71 | 72 | Git puede encontrar conflictos al fusionar ramas que hay que arreglar manualmente. Esto ocurrirá si en las dos ramas se han cambiado las mismas líneas de un archivo. Git muestra dónde están los conflictos así: 73 | 74 | `<<<<<>>>>>` 75 | 76 | Para solucionarlo hay que escoger los cambios de la rama principal o de la rama a unir según corresponda. Esto también se puede hacer a través de un cliente de Git, como GitKraken () o SourceTree (). Una vez solucionados, Git permite completar el *merge* (es decir, un nuevo *commit* que contendrá las ramas fusionadas). La mejor manera de evitar conflictos o por lo menos reducir su dificultad es realizar cambios pequeños y sincronizar frecuentemente con GitHub. 77 | 78 | # Agradecimientos 79 | 80 | JA está financiado por el Programa Predoctoral de Formación de Personal Investigador No Doctor del Departamento de Educación del Gobierno Vasco y VCA por el Real Colegio Complutense (Becas Postdoctorales 2020). Agradecemos al grupo de Ecoinformática de la AEET, especialmente a F. Rodríguez-Sánchez e I. Bartomeus por adentrarnos en el mundo de Git y Github, a P. Ruiz-Benito por su paciencia y colaboración en todo nuestro proceso de aprendizaje, y a C. Lara-Romero, J. Galeano, H. Saiz, A. Garmendia, J. Salgado-Rojas y F. Rodríguez-Sánchez por sus sugerencias para mejorar esta nota. 81 | 82 | ###### REFERENCIAS 83 | 84 | ::: {#refs} 85 | ::: 86 | 87 | ###### PIES DE FIGURA 88 | 89 | **Figura 1**. Ejemplo de un proyecto rastreado por Git con indicaciones de cómo se registran los cambios y la evolución del proyecto, el autor o autora de los cambios (¿quién?), el momento en que se han registrado (¿cuándo?), en qué documentos o líneas se han producido cambios (¿dónde?) y qué ha cambiado (¿qué?). 90 | 91 | **Figura 2**. Interacción entre Git y GitHub. Git, al ser un control de versiones distribuido, permite que todos los usuarios trabajen paralelamente sin interferir en el trabajo de los demás. Luego cada usuario sincroniza su trabajo con la copia principal del proyecto ubicado en GitHub. 92 | 93 | **Figura 3**. Representación gráfica de las diferentes zonas de trabajo en Git y GitHub: Directorio de trabajo (*working directory*), área de preparación (*staging area* o *Index*), repositorio local (*local repository* o *HEAD*) y repositorio remoto (*remote repository*). Imagen de fondo de Philip Brookes (). 94 | 95 | **Figura 4**. Flujo de trabajo en Git y GitHub mostrando las diferentes zonas de trabajo y los comandos utilizados para la transición de una zona de trabajo a otra. 96 | 97 | **Figura 5**. Proceso de creación y unión de ramas. Ejemplo de unión (*merge*) de la rama *monchi* a la rama *main*. 98 | 99 | ###### FIGURA 1 100 | 101 | ![](images/git.png) 102 | 103 | ###### FIGURA 2 104 | 105 | ![](images/conexiones.png) 106 | 107 | ###### FIGURA 3 108 | 109 | ![](images/arboles.png) 110 | 111 | ###### FIGURA 4 112 | 113 | ![](images/workflow_git_github.png) 114 | 115 | ###### FIGURA 5 116 | 117 | ![](images/merge.png) 118 | 119 | ###### Apéndice 1: recursos para entender Git y Github 120 | 121 | **Información más detallada de los temas tratados en esta nota y ejercicios** 122 | 123 | - [Introducción a Git y GitHub, dos herramientas para una ecología más colaborativa y reproducible](https://github.com/Julenasti/intro_git-github) 124 | 125 | **Ciencia reproducible** 126 | 127 | - [Ciencia reproducible: qué, por qué, cómo](https://github.com/ecoinfAEET/Reproducibilidad) 128 | 129 | **Control de versiones (Git)** 130 | 131 | - [Manual de referencia de Git](https://git-scm.com/docs) 132 | 133 | - [Software Carpentry](http://swcarpentry.github.io/git-novice/) 134 | 135 | - [Atlassian Bitbucket](https://www.atlassian.com/git/tutorials) 136 | 137 | - [Oh Shit, Git!?!](https://ohshitgit.com/) 138 | 139 | - [git - la guía sencilla](https://rogerdudler.github.io/git-guide/index.es.html) 140 | 141 | **Integrar Git, GitHub y RStudio** 142 | 143 | - [Happy Git and GitHub for the useR](https://happygitwithr.com/){.uri} 144 | 145 | **Enseñar y aprender con GitHub** 146 | 147 | - [GitHub Education para profesores e investigadores](https://docs.github.com/en/education/explore-the-benefits-of-teaching-and-learning-with-github-education/use-github-in-your-classroom-and-research/about-github-education-for-educators-and-researchers) 148 | -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/arboles.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/arboles.jpg -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/arboles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/arboles.png -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/conexiones.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/conexiones.png -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/git.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/git.png -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/merge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/merge.png -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/workflow_git_github.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/Rmd/images/workflow_git_github.png -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/Rmd/references.bib: -------------------------------------------------------------------------------- 1 | 2 | @article{galeano2018, 3 | title = {¿Por qué usar GitHub? Diez pasos para disfrutar de GitHub y no morir en el intento}, 4 | author = {{Galeano}, {Javier}}, 5 | year = {2018}, 6 | month = {07}, 7 | date = {2018-07-12}, 8 | journal = {Ecosistemas}, 9 | pages = {140--141}, 10 | volume = {27}, 11 | number = {2}, 12 | doi = {10.7818/ECOS.1604}, 13 | url = {https://www.revistaecosistemas.net/index.php/ecosistemas/article/view/1604}, 14 | note = {Number: 2}, 15 | langid = {es} 16 | } 17 | 18 | @article{perez-riverol2016, 19 | title = {Ten Simple Rules for Taking Advantage of Git and GitHub}, 20 | author = {{Perez-Riverol}, {Yasset} and {Gatto}, {Laurent} and {Wang}, {Rui} and {Sachsenberg}, {Timo} and {Uszkoreit}, {Julian} and {Leprevost}, {Felipe da Veiga} and {Fufezan}, {Christian} and {Ternent}, {Tobias} and {Eglen}, {Stephen J.} and {Katz}, {Daniel S.} and {Pollard}, {Tom J.} and {Konovalov}, {Alexander} and {Flight}, {Robert M.} and {Blin}, {Kai} and {Vizcaíno}, {Juan Antonio}}, 21 | year = {2016}, 22 | month = {07}, 23 | date = {2016-07-14}, 24 | journal = {PLOS Computational Biology}, 25 | pages = {e1004947}, 26 | volume = {12}, 27 | number = {7}, 28 | doi = {10.1371/journal.pcbi.1004947}, 29 | url = {https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1004947}, 30 | note = {Publisher: Public Library of Science}, 31 | langid = {en} 32 | } 33 | 34 | @article{ram2013, 35 | title = {Git can facilitate greater reproducibility and increased transparency in science}, 36 | author = {{Ram}, {Karthik}}, 37 | year = {2013}, 38 | month = {02}, 39 | date = {2013-02-28}, 40 | journal = {Source Code for Biology and Medicine}, 41 | pages = {7}, 42 | volume = {8}, 43 | number = {1}, 44 | doi = {10.1186/1751-0473-8-7}, 45 | url = {https://doi.org/10.1186/1751-0473-8-7} 46 | } 47 | 48 | @article{peng2011, 49 | title = {Reproducible Research in Computational Science}, 50 | author = {{Peng}, {Roger D.}}, 51 | year = {2011}, 52 | month = {12}, 53 | date = {2011-12-02}, 54 | journal = {Science}, 55 | pages = {1226--1227}, 56 | volume = {334}, 57 | number = {6060}, 58 | doi = {10.1126/science.1213847}, 59 | url = {https://www.science.org/doi/10.1126/science.1213847}, 60 | note = {Publisher: American Association for the Advancement of Science} 61 | } 62 | 63 | @article{farley2018, 64 | title = {Situating Ecology as a Big-Data Science: Current Advances, Challenges, and Solutions}, 65 | author = {{Farley}, {Scott S} and {Dawson}, {Andria} and {Goring}, {Simon J} and {Williams}, {John W}}, 66 | year = {2018}, 67 | month = {08}, 68 | date = {2018-08-01}, 69 | journal = {BioScience}, 70 | pages = {563--576}, 71 | volume = {68}, 72 | number = {8}, 73 | doi = {10.1093/biosci/biy068}, 74 | url = {https://doi.org/10.1093/biosci/biy068} 75 | } 76 | 77 | @article{rodríguez-sánchez2020, 78 | title = {Quince consejos para mejorar nuestro código y flujo de trabajo con R}, 79 | author = {{Rodríguez-Sánchez}, {Francisco}}, 80 | year = {2020}, 81 | month = {12}, 82 | date = {2020-12-26}, 83 | journal = {Ecosistemas}, 84 | pages = {2129--2129}, 85 | volume = {29}, 86 | number = {3}, 87 | doi = {10.7818/ECOS.2129}, 88 | url = {https://revistaecosistemas.net/index.php/ecosistemas/article/view/2129}, 89 | note = {Number: 3}, 90 | langid = {es} 91 | } 92 | 93 | @article{blischak2016, 94 | title = {A Quick Introduction to Version Control with Git and GitHub}, 95 | author = {{Blischak}, {John D.} and {Davenport}, {Emily R.} and {Wilson}, {Greg}}, 96 | year = {2016}, 97 | month = {01}, 98 | date = {2016-01-19}, 99 | journal = {PLOS Computational Biology}, 100 | pages = {e1004668}, 101 | volume = {12}, 102 | number = {1}, 103 | doi = {10.1371/journal.pcbi.1004668}, 104 | url = {https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1004668}, 105 | note = {Publisher: Public Library of Science}, 106 | langid = {en} 107 | } 108 | 109 | @article{rodríguez-sánchez2016, 110 | title = {Ciencia reproducible: qué, por qué, cómo}, 111 | author = {{Rodríguez-Sánchez}, {Francisco} and {Pérez-Luque}, {Antonio Jesús} and {Bartomeus}, {Ignasi} and {Varela}, {Sara}}, 112 | year = {2016}, 113 | month = {07}, 114 | date = {2016-07-16}, 115 | journal = {Ecosistemas}, 116 | pages = {83--92}, 117 | volume = {25}, 118 | number = {2}, 119 | doi = {10.7818/ECOS.2016.25-2.11}, 120 | url = {https://revistaecosistemas.net/index.php/ecosistemas/article/view/1178}, 121 | note = {Number: 2}, 122 | langid = {es} 123 | } 124 | 125 | @article{hampton2013, 126 | title = {Big data and the future of ecology}, 127 | author = {{Hampton}, {Stephanie E} and {Strasser}, {Carly A} and {Tewksbury}, {Joshua J} and {Gram}, {Wendy K} and {Budden}, {Amber E} and {Batcheller}, {Archer L} and {Duke}, {Clifford S} and {Porter}, {John H}}, 128 | year = {2013}, 129 | date = {2013}, 130 | journal = {Frontiers in Ecology and the Environment}, 131 | pages = {156--162}, 132 | volume = {11}, 133 | number = {3}, 134 | doi = {10.1890/120103}, 135 | url = {https://onlinelibrary.wiley.com/doi/abs/10.1890/120103}, 136 | note = {{\_}eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1890/120103}, 137 | langid = {en} 138 | } 139 | 140 | 141 | @book{theturingwaycommunity2021, 142 | title = {The Turing Way: A handbook for reproducible, ethical and collaborative research (1.0.1)}, 143 | author = {{The Turing Way Community}, {}}, 144 | year = {2021}, 145 | month = {11}, 146 | date = {2021-11-10}, 147 | publisher = {Zenodo}, 148 | doi = {10.5281/zenodo.5671094}, 149 | url = {https://zenodo.org/record/5671094}, 150 | note = {DOI: 10.5281/zenodo.5671094} 151 | } 152 | -------------------------------------------------------------------------------- /Git-GitHub_Astigarraga_CruzAlonso/git_github_ver_rev.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/Git-GitHub_Astigarraga_CruzAlonso/git_github_ver_rev.docx -------------------------------------------------------------------------------- /GitHub_para_Ecologos/imagenes/Procastination_poem.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/GitHub_para_Ecologos/imagenes/Procastination_poem.png -------------------------------------------------------------------------------- /GitHub_para_Ecologos/imagenes/diff.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/GitHub_para_Ecologos/imagenes/diff.png -------------------------------------------------------------------------------- /GitHub_para_Ecologos/imagenes/history_commits.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/GitHub_para_Ecologos/imagenes/history_commits.png -------------------------------------------------------------------------------- /GitHub_para_Ecologos/ms_JGP.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "¿ Por qué usar GitHub? Diez pasos para disfrutar de GitHub y no morir en el 3 | intento. \n" 4 | author: "Javier Galeano^1^" 5 | csl: ecosistemas.csl 6 | output: 7 | word_document: 8 | fig_caption: yes 9 | fig_height: 6 10 | fig_width: 7.5 11 | highlight: null 12 | reference_docx: Ecosistemas_template.docx 13 | pdf_document: default 14 | html_document: default 15 | bibliography: 16 | - references.bib 17 | - knitcitations.bib 18 | --- 19 | 20 | 21 | > (1) Grupo de Sistemas Complejos, ETSIAAB, Univerisdad Politécnica de Madrid. 22 | 23 | > Autor para correspondencia:Javier Galeano [javier.galeano@upm.es] 24 | 25 | 26 | # Palabras clave 27 | 28 | > GitHub; Git; control de versiones ; 29 | 30 | 31 | # Keywords 32 | 33 | > GitHub; Git; version control; 34 | 35 | 36 | ```{r knitcitations, echo=FALSE, cache = FALSE} 37 | library(knitcitations) 38 | cleanbib() 39 | cite_options(citation_format = "pandoc") 40 | ``` 41 | 42 | Los estudios en ecología han pasado de ser trabajos personales, donde se dedicaba una vida de esfuerzo personal al estudio de una especie o un pequeño sistema, a realizar trabajos multidisciplinares en que involucran a un grupo de colaboradores con diferentes bagajes. En consecuencia, la cantidad de datos en un estudio típico de ecología ha aumentado exponencialmente, creciendo la necesidad de realizar programas para tratar de gestionar y modelizar todos esos datos. Además, en todos los ámbitos científicos, y en particular en ecología, se está intentando que cada investigación pueda ser reproducible hasta el más mínimo detalle (por ejemplo [@Rodr_guez_Sanchez_2016]). Con todas estas ideas el uso de herramientas de control de versiones comienza a ser imprescindible en nuestros trabajos. Con esta nota se pretende animar a los investigadores a utilizar una de las herramientas más populares en control de versiones como es GitHub. 43 | 44 | 45 | # ¿Necesito usar GitHub? 46 | 47 | Para responder a esta pregunta voy a mostrarte un ejemplo. En la figura \ref{Fig1} se puede ver todas las versiones que he hecho de mi poema sobre el arco iris. A pesar de que el poema es sencillo, y probablemente sin ningún interés literario, hay bastantes versiones del poema, si esto te suele ocurrir con tus ficheros puede ser una buena idea que uses alguna herramienta de control de versiones. git es precisamente una herramienta de control de versiones que se usa en tu propio ordenador y te puede ayudar a tener controladas todas las versiones de tu poema o de tu artículo. 48 | 49 | 50 | Por otra parte seguramente te ha tocado colaborar con mucha gente para escribir un proyecto científico, o el código de un programa donde se va haciendo el software a pedazos, cortando, pegando y probablemente sin documentarlo. Si te ha pasado todo esto, está claro que una herramienta como GitHub puede ayudarte mucho para que tu trabajo sea más fácil y eficiente. Me gustaría aclarar que hay otras herramientas similares a git y GitHub, pero yo uso éstas por dos razones: son gratuitas y tienen un uso cada vez más extenso [@Blischak16;@Perez16] . Además si Linus Torvald, el creador de Linux, creó git puede ser una buena razón para usarlo. 51 | 52 | Pero si todo son ventajas, ¿por qué no lo usa más gente? Yo creo que el principal problema es que la curva de aprendizaje de git y GitHub al principio es dura, y eso hace que mucha gente decida no avanzar en estas herramientas. Otro de los problemas es que se enseña a usar las dos herramientas centrándose en git, usandolo desde el terminal. Esto puede ser bastante duro si no tienes demasiada experiencia desde un terminal en Windows o Mac. Para resolver este último problema, algunas autores proponen comenzar aprendiendo a usar GitHub, que aunque está basado en git, como entorno puede ser bastante más fácil y amigable ( [videotutoriales de Github](https://www.youtube.com/playlist?list=PLRqwX-V7Uu6ZF9C0YMKuns9sLDzK6zoiV) ). 53 | 54 | # Diez pasos para comenzar a usar GitHub 55 | 56 | Estos diez pasos son una guía sencilla que explican las acciones básicas para iniciarnos en el uso de GitHub. El paso 0 debería ser hacerse una cuenta en GitHub, pero como eso es bastante sencillo, vamos a suponer que ya tenemos esa cuenta. 57 | 58 | 1. **Paso 1. Primer Repositorio** Entramos en nuestra cuenta de GitHub y nos vamos a la pestaña de repositorios, Repositories en inglés. En la pestaña que pone **New**, damos un click para crear nuestro primer repositorio, que suele abreviarse en repo, en GitHub. 59 | Lo primero que tenemos que hacer es poner el nombre del repositorio, en este caso *poema arco iris*, pero veremos que a GitHub no le gustan los espacios así que me lo renombrará a *poema-arco-iris*. Añadimos una descripción, que no es obligatoria, para conocer el contenido de mi repositorio *Mi poema sobre el arco iris*. El repositorio tendrá un caracter público, podéis ver que está activo el botón de *Public* y además le decimos que al crear el repositorio añada un fichero *Readme*. Por favor, añade este fichero, de no hacerlo luego se complica todo mucho más. En este fichero que aparecerá como presentación de lo que hay en nuestro repositorio, por defecto se copiará el título del repo y debajo la descripción que hemos añadido. Si queremos añadir más contenido podemos editarlo posteriormente. Por último hay dos pestañas que nos piden añadir dos ficheros: .gitignore y license. De momento vamos a dejarlo en **None** y ya veremos más adelante qué tipos de ficheros son y para qué nos sirven. Es por tanto el momento de darle al botón **Create repository**. Tendremos nuestro primer repositorio con el fichero README.md que pone el título y la descripción del repo. 60 | 61 | 2. **Paso 2. Primer fichero, el poema del Arco Iris** Usemos nuestro repositorio para escribir directamente aquí nuestro primer fichero, el poema. Clicamos en el botón para crear un fichero nuevo, **Create new file** y aparecerá un sencillo editor donde podemos escribir nuestro primer texto. En la parte superior le ponemos el título del fichero, *poema_arco_iris.txt*. En nuestro caso el fichero será de tipo txt, que es uno de los tipos de ficheros que GitHub puede gestionar sin problemas. Nuestro texto es un poema sobre el arco iris y sus colores. Querríamos dejarlo de momento grabado para seguir más tarde. En git y en GitHub el equivalente a grabar un fichero podríamos decir que se llama **commit**. Si bajamos en la página podremos ver un botón que se llama **Commit new file**. Inicialmente está deshabilitado, pero si escribimos en el campo que está debajo del título **Commit new file**, el botón se activará y se marca el botón de **commit directly to the master branch**. Ya hablaremos de lo que son las *branch*, pero de momento no toquemos nada. En este campo vamos a escribir una pequeña referencia de lo que hemos escrito, por ejemplo `Comienzo el poema`. Con esto ya estaríamos listos para crear nuestro primer commit. Una vez creado, volvemos automáticamente a la carpeta de repositorio. Tenemos un nuevo fichero en la lista, `poema_arco_iris.txt`, y además debajo del título aparece que ya tenemos dos commits. Debajo del botón donde pone master, sale el nombre de nuestra cuenta, el texto del último commit y si en esa línea seguimos a la derecha pone *Last commit* y un montón de letras y números. Git usa un identificador que es un número hexadecimal de 40 dígitos generado como clave de hash SHA1, es decir, cada commit tiene un indentificador único. Como os podéis imaginar no se suele llamar al commit por su identificador largo, pero sí que hay una versión corta del indentificador con los 7-8 dígitos iniciales (\ref{Fig2}). 62 | 63 | 3. **Paso 3. Veamos la historia** Después de visitar Wikipedia, nos volvió la inspiración de todos los colores que componen el arco iris, así que nos fuimos al fichero, lo editamos de nuevo, esta vez añadiendo todos los colores que faltaban, y para terminar, cambiamos la frase final. Por supuesto para que quede grabado hacemos un nuevo commit, diciendo que añadimos todos los colores. Con el fichero del poema abierto, nos fijamos en la parte derecha veremos un botón que pone **History**, si clicamos aparece la lista de todos los commits. Vemos que en este caso hay dos commits, y si miramos a la derecha nos sale su hash abreviado, es decir, su identificador único. Es probable que hasta ahora no nos hayamos dado cuenta de la ventaja de GitHub, pero ahora al ver todas las versiones listadas de nuestro fichero, sin esos titulos de ficheros de primera version, segunda version, versión final, ... . Todas las versiónes están aquí recogidas y organizadas en una lista. Pero esto no es lo mejor, si hacemos click en el último commit nos va a aparecer una imagen donde se nos va a marcar en verde lo que hemos añadido con un signo + delante de la línea, en nuestro caso la lista de los nuevos colores que añadimos. En rojo nos marca la línea que hemos modificado y en verde claro lo que ya estaba y en verde más oscuro lo que añadimos al final de la frase. Tenemos todos los cambios hechos en la versión y marcados con colores (\ref{Fig3}). 64 | 65 | 4. **Paso 4. .gitignore y license** Cuando creamos el primer repositorio añadimos el fichero *readme.rmd*. Este fichero hace que el repositorio sea más fácil de usar y que, de una manera sencilla, veamos de qué va el repositorio. Pero justo debajo teníamos dos botones que ignoramos: **Add .gitignore** y **Add a license**. GitHub nos hace la vida más fácil pudiendo añadir esos dos ficheros. El botón de license, nos añade un fichero con la licencia de tipo creative commons para que la comunidad pueda usar esos ficheros libremente pero con las restricciones típicas. Cada uno puede estudiar el tipo de licencia que quiere usar. El botón de **.gitignore** puede sernos más útil. Supongamos que trabajamos en un lenguaje de programación, por ejemplo Python. Podemos añadir un fichero .gitignore para la programación en python. Lo que va a hacer ese fichero es dicerle a git cuales son los ficheros que no hace falta que trabaje con ellos. Los motivos son muchos, pero si uno trabaja por ejemplo con Jupyter el programa hace copias automáticas de los programas para que no se pierdan los cambios, pero nosotros no queremos que estén en nuestro repositorio de GitHub, pues si tenemos esos ficheros en nuestro.gitignore cuando hagamos un commit o cualquier otro proceso no buscará esos ficheros. 66 | 67 | 5. **Paso 5. Creando una nueva rama** Tenemos nuestro repositorio donde hemos ido haciendo cambios en el fichero del poema de arco iris. Pero queremos hacer una prueba experimental que no sabemos si funcionará, es el momento de hacer una nueva rama. Si nos situamos en el repositorio **poema-arco-iris**, podemos ver un botón en el que pone **Branch:master**. Por defecto la rama principal se conoce como master, que es donde hemos ido trabajando, pero queremos trabajar en una nueva rama. Clicamos en el botón y aparecerá un campo que pone **create o find a new branch**. En mi nueva rama voy a explorar la posibilidad de introducir nuevos animales mitológicos en el poema así que lo llamaré `mitos`. Una vez que escribimos el nombre, aparecerá un botón que pone **create new branch** y clicamos. Parece que nada ha cambiado en nuestro repositorio, pero si nos volvemos a fijar en el botón de branch ahora pone **Branch:mitos**. Voy a añadir a el poema un par de mitos, este caso el basajaun y la basandere. Edito el fichero del `poema_arco_iris.txt` y añado al basajaun y la basandere al final de los colores. Para que la variación se guarde tengo que hacer el commit, y vemos que está activado el botón **commit directly to the mitos branch**. Por tanto estoy añadiendo mi modificación sobre la rama de mitos y no sobre la rama master. Creo el commit y volvemos a la página del repositorio. Ha aparecido un nuevo botón que pone **compare & pull request**. 68 | 69 | 6. **Paso 6. Compare & and pull request** Antes de trabajar con el nuevo botón, veamos qué ha pasado con este repositorio y la nueva rama. Para ello en la parte superior vemos un botón de **insights**, entramos y aparece una columna a la izquierda donde vemos **network**. Entrando veremos que hay una línea horizontal negra, con la etiqueta *master* y por debajo le ha salido una flecha que ha avanzado y que pone *mitos*. Son las dos ramas que tenemos ahora en nuestro repositorio vistas de una manera gráfica. Volvamos a la página principal del repositorio. Allí sigue nuestro nuevo botón **compare and pull request** y el botón de branch ha vuelto a ponerse sobre master, **Branch: master**. Si nos fijamos en el fichero del poema, como estamos en la rama master, no aparecen los cambios que hemos hecho en el poema, ya que esos cambios están en la rama mitos. Supongamos que me gusta como ha quedado el nuevo poema añadiendo estos dos mitos vascos y los quiero juntar a la rama master, que es donde se supone que dejamos los ficheros principales. Es el momento de clicar en **compare & pull request**. Me sale una ventana nuevo **open pull request** ya que estamos solicitando que los cambios se añadan a master. Rellenamos títulos y los campos necesarios y le damos a **create pull request**. GitHub, mira a ver si hay algún problema a la hora de juntar los dos ficheros, y en nuestro caso nos pone que no hay ningún conflicto **This branch has no conflicts with the base branch**. Así que le damos al botón **merge pull request**, nos pide que lo confirmemos, y cuando lo hacemos nos da la posibilidad de borrar la rama de mitos. En este caso no lo voy a hacer para que veamos gráficamente que ha pasado. Volvemos de nuevo a **network** y ahora vemos que la rama *mitos* y la rama *master* se han juntado en un punto. Hemos trabajado con nuestro primera rama. 70 | 71 | 7. **Paso 7. Fork** Es el momento de pasearnos por GitHub y buscar algún repositorio que nos interese. Supongamos que lo encontramos y queremos hacer una copia de dicho trabajo para trabajar con él. En la parte derecha superior veremos un botón de **Fork**. Lo que vamos a tener es un repositorio igual a este que nos ha gustado pero en nuestra cuenta de GitHub, así podremos tarabajar con él e incluso ayudar a un desarrollo colaborativo del proyecto. 72 | 73 | 8. **Paso 8. Pull request** Supongamos que el repostirio que hemos copiado con *Fork* es un código colaborativo sobre el que estamos trabajando con nuestros colegas. Encontramos algo que fuinciona mal o que pensamos que podemos mejorar y hacemos el cambio en nuestro repositorio. Pensamos que por tanto podría ser interesante enviarlo al repositorio original, pero nosotros no tenemos los permisos para poder hacerlo, así que lo que hacemos es pedir un **Pull request**. El proceso es similar a lo que hicimos nosotros en el paso 6, lo único es que esta vez tiene que ser el propietario original del repositorio. Es esta la base de trabajo en un proyecto colaborativo. 74 | 75 | 9. **Paso 9. Intro a linea de comandos: git** La herramienta GitHub tiene como columna vertebral, git. Git es la herramienta de control de versiones que se creó para trabajar en línea de comandos para el desarrollo de Linux. Está pensada para trabajar en este entorno, pero puede usarse en otros sistemas operativos como Windows o MacOs. En MacOs, ya que su nucleo central está desarrollado en unix, basta con abrir un terminal y poner git. En Windows es algo más complejo y hay que instalar un pequeño programa llamado git bash. Antes de comenzar a trabajar con git en local, tenemos que pensar que estamos en un sistema operativo de Unix/Linux y por tanto necesitaremos algunos comandos de Unix que nos permitan hacer algunas trabajos sencillos como cambiar de directorio, listar los archivos en un directorio y pocas cosas más (Tabla 1). Pero, ¿ por qué necesitamos usar git? Supongamos que os he convencido de que es interesante usar un control de versiones, la mayoría de las veces estamos trabajando en local en nuestro ordenador, y una vez realizados los cambios querremos subir a GitHub nuestros cambios. Tenemos que hacer por tanto lo que ya hemos aprendido desde GitHub, por ejemplo hacer un commit, pero en local. Lo primero que tenemos que hacer es configurar nuestro git de tal manera que sea fácil conectarlo con nuestro GitHub y el flujo de trabajo sea muy fácil. Lo primero que tenemos que hacer es conectar nuestro git local con nuestra cuenta de GitHub, para ello basta con escribir en el terminal dos comandos bastante sencillos: 76 | 77 | `git config --global user.name "User Name"` 78 | 79 | `git config --global user.emal email_usado_en_GitHub` 80 | 81 | y para ver si esto ha funcionado, escribimos `git config --list` y deberíamos ver nuestro nombre y el email. 82 | 83 | 10. **Paso 10. Clonar un Repo, push and pull** Partimos de que tenemos ya git instalado y ahora queremos trabajar en nuestro repositorio en local para luego subirlo a GitHub. Lo primero que recomiendo es crear un directorio donde pueden estar nuestros proyectos de GitHub, así podemos tener todo organizado. Abrimos nuestro terminal, nos vamos al directorio donde queremos poner nuestro repositorio. Ahora tenemos que clonar el repositorio que tenemos en GitHub para poder empezar a trabajar en local. Lo primero que podemos hacer es ir a nuestro repositorio en GitHub, por ejemplo a **poema-arco-iris**. Allí veremos un botón que pone **clone or download**, si hacemos click aparece la direccción https de nuestro repositorio, copiemos esa dirección, nos vamos al terminal y escribimos, `git clone dirección_url` en mi caso, `git clone https://github.com/galeanojav/poema-arco-iris.git`. Ese será el paso para clonar el repositorio entero en mi directorio local, que se acaba de convertir en un repositorio. Nos metemos en el directorio con `cd poema-arco-iris` y ya podemos ver lo que hay dentro del repositorio con `ls`. Editemos ahora nuestro poema.txt con cualquier editor y grabamos el cambio. Si escribimos en el terminal `git status` veremos que nos dice que nuestro fichero se ha modificado. Es el momento de hacer el commit para que esa modificación se guarde de verdad. Escribimos en el terminal `git commit -a -m "Primer commit en local"` y tendremos nuestro fichero cambiado y guardado con el commit. Tenemos entonces que subirlo a GitHub. Para ello vamos a usar un nuevo comando de git, **push**. Si queremos subir desde nuestro ordenador a GitHub usamos `git push` y si queremos bajar por ejemplo un cambio que se hizo en nuestro programa y que alguien subió al repositorio, necesitamos hacer `git pull`. Probemos a hacer `git push` y nuestro cambio en local del fichero de texto aparecerá en GitHub con el nuevo commit que habáimos añadido en local. 84 | 85 | # Apendice: GitHub en Rstudio 86 | 87 | Un pequeño apéndice para hacer notar que todos estos pasos con los **commits**, **push** and **pull** pueden hacerse de una manera bastante sencilla e intuitiva desde *Rstudio*, que suele ser una herramienta que muchos usamos para programar en `R`. El uso de Git en Rstudio necesitaría una nota entera para contarlo, pero comenzar es sencillo. Vamos 'File -> New Project`. Aparece una ventana donde podemos elegir **Version control**, y decidir usar Git y proporcionar la url que hemos copiado en el paso 10 para clonar un repositorio. Si hacemos esto, aparecerá el repositorio y una pestaña de Git, donde apareceran los botones para hacer **commits**, **push** and **pull**. En cualquier caso hay varios tutoriales en la propia ayuda de Rstudio [Tutorial de Git y GitHub en Rstudio](https://support.rstudio.com/hc/en-us/articles/200532077?version=0.99.896&mode=desktop) 88 | 89 | # Conclusiones 90 | 91 | Estos diez pasos para trabajar con git y GitHub pretenden ser una pequeña guía de iniciación a estas herramientas que considero pueden ser de gran ayuda a cualquier investigador que esté diseñanado código, aunque sea el más sencillo imaginable, y quiere compartirlo con sus colaboradores. Además esta política de subir codigo y compartirlo coincide con la idea de hacer ciencia reproducible que se considera actualmente indispensable para un mejor avance científico. 92 | 93 | 94 | # Agradecimientos 95 | 96 | Me gustaría agradecer a Ana Negredo por la revisión del manuscrito. Y agrader al grupo de ecoinformática de la AEET por la posibilidad de enviar esta nota y los comentarios. Esta nota está escrita con RMarkdown [@Saiz17] 97 | 98 | 99 | 100 | 101 | 102 | ###### REFERENCIAS 103 | 104 |
105 | 106 | 107 | 108 | ###### TABLA 1 109 | 110 | **Tabla 1**. Comandos Minimos de Unix necesarias para trabajar en local. 111 | 112 | **Table 1**. Minumum commands to work in UNIX to work in local terminal. 113 | 114 | 115 | | comandos de Unix | Empleo | 116 | | :------ | :--------------------------------:| 117 | | `pwd` | devuelve la ruta actual | 118 | | `ls` | listar un directorio | 119 | | `mk nombre_dir` | crea directorio `nombre_dir` | 120 | | `cd nombre_dir` | cambiar al directorio `nombre_dir`| 121 | | `cd ..` | cambiar al directorio superior | 122 | 123 | 124 | ###### PIES DE FIGURA 125 | 126 | **Figura 1**. Directorio de mi primer poema. 127 | **Figura 2**. History and commits de mi primer poema. 128 | **Figura 3**. Diferencias en las versiones de mi poema. 129 | 130 | ###### FIGURE LEGENDS 131 | 132 | **Figure 1**. Directory of my first poem. 133 | **Figura 2**. History and commits of my first poem. 134 | **Figura 3**. Differences in the versions of my poem. 135 | 136 | 137 | 138 | ###### FIGURA 1 139 | 140 | ![Fig1:Directorio de mi primer poema](imagenes/Procastination_poem.png "Directorio de mi primer poema")\label{Fig1} 141 | 142 | ###### FIGURA 2 143 | 144 | ![Fig2: History and commits](imagenes/history_commits.png "History and commits") 145 | 146 | 147 | ###### FIGURA 3 148 | 149 | ![Fig3: Diferencias en las versiones de mi poema](imagenes/diff.png "Diferencias en las versiones de mi poema") 150 | 151 | 152 | 153 | 154 | 155 | -------------------------------------------------------------------------------- /GitHub_para_Ecologos/ms_JGP.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/GitHub_para_Ecologos/ms_JGP.docx -------------------------------------------------------------------------------- /GitHub_para_Ecologos/references.bib: -------------------------------------------------------------------------------- 1 | 2 | @Article{Perez16, 3 | author = {Perez-Riverol, Yasset and Gatto, Laurent and Wang, Rui and Sachsenberg, Timo and Uszkoreit, Julian and Leprevost, Felipe da Veiga and Fufezan, Christian and Ternent, Tobias and Eglen, Stephen J. and Katz, Daniel S. and Pollard, Tom J. and Konovalov, Alexander and Flight, Robert M. and Blin, Kai and Vizcaíno, Juan Antonio}, 4 | journal = {PLOS Computational Biology}, 5 | publisher = {Public Library of Science}, 6 | title = {Ten Simple Rules for Taking Advantage of Git and GitHub}, 7 | year = {2016}, 8 | month = {07}, 9 | volume = {12}, 10 | url = {https://doi.org/10.1371/journal.pcbi.1004947}, 11 | pages = {1-11}, 12 | abstract = {}, 13 | number = {7}, 14 | doi = {10.1371/journal.pcbi.1004947} 15 | } 16 | 17 | @Article{Blischak16, 18 | title = {A Quick Introduction to Version Control with Git and GitHub}, 19 | volume = {12}, 20 | issn = {}, 21 | url = {}, 22 | doi = {10.1371/journal.pcbi.0027537}, 23 | number = {1}, 24 | urldate = {2016-01-19}, 25 | journal = {PLoS Comput Biol}, 26 | author = {John D. Blischak and Emily R. Davenport and Greg Wilson}, 27 | editor = {}, 28 | month = {Jan}, 29 | year = {2016}, 30 | pages = {e1004668}, 31 | numeral = {1}, 32 | } 33 | @Article{Rodr_guez_Sanchez_2016, 34 | doi = {10.7818/ecos.2016.25-2.11}, 35 | url = {https://doi.org/10.7818/ecos.2016.25-2.11}, 36 | year = {2016}, 37 | month = {aug}, 38 | publisher = {Asociacion Espa{\~{n}}ola de Ecologia Terrestre ({AEET})}, 39 | volume = {25}, 40 | number = {2}, 41 | pages = {83--92}, 42 | author = {Francisco Rodr{\'{\i}}guez-Sanchez and Antonio Jes{\'u}s P{\'e}rez-Luque and Ignasi Bartomeus and Sara Varela}, 43 | title = {Ciencia reproducible: {\textquestiondown}qu{\'{e}}, por qu{\'{e}}, c{\'{o}}mo?}, 44 | journal = {Ecosistemas}, 45 | } 46 | @Article{Saiz17, 47 | doi = {10.7818/ecos.2017.26-3.14}, 48 | url = {https://doi.org/10.7818/ecos.2017.26-3.14}, 49 | year = {2017}, 50 | month = {sep}, 51 | publisher = {Asociacion Espa{\~{n}}ola de Ecologia Terrestre ({AEET})}, 52 | volume = {26}, 53 | number = {3}, 54 | pages = {110--111}, 55 | author = {H. Saiz}, 56 | title = {Procesadores de texto Markup: m\'as all\'a de MS Word}, 57 | journal = {Ecosistemas}, 58 | } 59 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Notas Ecoinformáticas 2 | 3 | Toda la información relativa a las notas se puede encontrar en la página web del grupo: 4 | 5 | [![DOI](https://zenodo.org/badge/81460385.svg)](https://doi.org/10.5281/zenodo.14627640) 6 | -------------------------------------------------------------------------------- /VegX/VegX_Nota_Ecosistemas.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/VegX/VegX_Nota_Ecosistemas.docx -------------------------------------------------------------------------------- /VegX/VegX_Nota_Ecosistemas_FRS.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/VegX/VegX_Nota_Ecosistemas_FRS.docx -------------------------------------------------------------------------------- /VegX/vegX: -------------------------------------------------------------------------------- 1 | Sobre el intercambio de datos de vegetación: el estándar ‘Veg-X’ y el paquete de R ‘VegX’ 2 | 3 | Miquel De Cáceres1,2,* 4 | 5 | 1 Centro Tecnológico Forestal de Cataluña, Ctra. antiga St. Llorenç de Morunys km. 2; 25280 Solsona, Catalunya, España; 6 | 2 CREAF, Cerdanyola del Vallès 08193, España; 7 | * Autor de correspondencia: miquelcaceres@gmail.com 8 | 9 | Actualmente existe una cantidad ingente de datos sobre la vegetación de los ecosistemas terrestres del mundo. En muchos casos se trata de datos de parcelas de muestreo, establecidas para estudios concretos o que forman parte de esfuerzos colectivos de observación a gran escala, como son los inventarios florísticos o los inventarios forestales. A menudo dichos datos se encuentran archivados en bases de datos relacionales, con una estructura de datos conocida. El Global Index of Vegetation-Plot Databases (GIVD; www.givd.info) (Dengler et al. 2011) es una meta-base de datos que en marzo de 2018 contiene información sobre 260 bases de datos de vegetación. Sin embargo, los datos de la mayoría de las bases de datos listadas en GIVD a menudo están almacenados en bases de datos con estructuras únicas. Esto no supone un problema para estudios que utilicen bases de datos grandes, tales como los inventarios forestales, dado que solo es necesario comprender una sola estructura de datos (Wiser 2016). Sin embargo, cuando uno desea integrar distintas fuentes de datos para realizar nuevos análisis es necesario establecer mapas de campos y conceptos, cosa que enlentece en gran medida el proceso y puede ser fuente de errores. En el caso de redes de parcelas a escala mundial que comparten los mismos protocolos de muestreo de campo, el problema se puede aliviar estableciendo estándares de modelos de datos para bases de datos (Condit et al. 2014). Sin embargo, esta solución no es aplicable para armonizar e integrar datos provenientes de distintos estudios (e.g. distintas formas de las parcelas y/o subparcelas, distinta definición de estratos, etc.). Así pues, los análisis requiriendo la integración de datos de vegetación de varias fuentes se ven dificultados por la no existencia de estándares de intercambio de datos de vegetación reconocidos internacionalmente. 10 | 11 | En 2003, el grupo de trabajo de ecoinformática de la International Association for Vegetation Science (IAVS; www.iavs.org) decidió promover el desarrollo de un estándar de intercambio de datos de parcelas de vegetación. A partir del trabajo en distintos talleres internacionales se llegó a la publicación de Veg-X, un estándar de intercambio de datos implementado en un esquema XML (extensible markup language) y diseñado para ser compatible con un gran número estructuras de datos de vegetación existentes (Wiser et al. 2011). El estándar distingue entre la entidad observada (p.ej. un árbol) y el acto de observación (p.e. las mediciones) y permite almacenar tanto datos de plantas individuales (p.ej. diámetros, alturas, …) como datos de plantas ‘agregados’ (p.ej. porcentaje de cobertura de una especie), incluyendo su posición en estratos verticales. El estándar también soporta el muestreo repetido de organismos y parcelas, así como la agrupación de observaciones por criterios no temporales (p.ej. a partir de definir sub-parcelas). Todos los elementos del esquema XML están claramente definidos para facilitar el mapeo de los campos de cualquier base de datos de vegetación. 12 | 13 | Desde su publicación, una de las barreras a la adopción de Veg-X para el intercambio de datos ha sido su complejidad, por otro lado necesaria para acomodarse a la gran variedad de estructuras de datos existentes. Para conseguir que el formato de intercambio sea adoptado por un conjunto amplio de usuarios es importante desarrollar herramientas ecoinformáticas para facilitar el mapeo desde distintas estructuras de datos a Veg-X, así como para la integración de documentos en dicho formato, incluyendo la armonización de unidades, etc. Desde 2017, desde el grupo de trabajo de ecoinformática de la IAVS nos hemos puesto a desarrollar un paquete de R que sirva para realizar las tareas mencionadas. El desarrollo del paquete, llamado VegX, se ha realizado en paralelo a una revisión importante del estándar mismo. Tanto el esquema en XML del estándar (ver. 2.0) como el paquete de R y su documentación (descripción detallada del esquema, manual de usuario del paquete) se encuentran disponibles en un repositorio de desarrollo y distribución de GitHub (https://github.com/miquelcaceres/VegX). 14 | 15 | Aunque se puede considerar funcional, el paquete VegX se encuentra actualmente en un estado de desarrollo en el que es necesario testear su usabilidad para importar e integrar distintos tipos de datos fuente. Además, uno de nuestros objetivos es el de promover que los datos de vegetación asociados a publicaciones científicas que sean archivados en repositorios públicos (e.g. DRYAD; https://datadryad.org/) estén almacenados mediante estándar tales como Veg-X, para facilitar su reutilización en estudios posteriores. Para ello, sería interesante disponer de varios ejemplos de importación de datos (escritos p.ej. en Rmarkdown). Es por ese motivo que quisiera aprovechar esta Nota Ecoinformática para hacer un llamamiento a investigadores (ecólogos terrestres, ingenieros forestales, botánicos, etc.) con datos de vegetación propios (p.ej. en tablas de Excel o ficheros ASCII de texto) interesados en probar la importación de sus datos y reportarnos los problemas o dudas que hayan surgido, así como el código usado en el proceso. No es necesario que dichos datos sean públicos, dado que solamente nos interesa su estructura, no su contenido. Esta información nos ayudará enormemente a mejorar la herramienta que proponemos. 16 | 17 | Agradecimientos 18 | Gracias al grupo de ecoinformática de la AEET por la permisión de escribir esta nota. Miquel De Cáceres cuenta con una ayuda Ramón y Cajal del MINECO (RYC-2012-11109). 19 | 20 | Referencias 21 | 22 | Condit, R., Lao, S., Singh, A., Esufali, S., & Dolins, S. 2014. Data and database standards for permanent forest plots in a global network. Forest Ecology and Management 316: 21–31. 23 | 24 | Dengler, J., Jansen, F., Glöckler, F., Peet, R.K., De Cáceres, M., Chytrý, M., Ewald, J., Oldeland, J., Lopez-Gonzalez, G., Finckh, M., Mucina, L., Rodwell, J.S., Schaminée, J.H.J., & Spencer, N. 2011. The Global Index of Vegetation-Plot Databases (GIVD): a new resource for vegetation science. Journal of Vegetation Science 22: 582–597. 25 | 26 | Wiser, S.K. 2016. Achievements and challenges in the integration, reuse and synthesis of vegetation plot data. Journal of Vegetation Science 27: 868–879. 27 | 28 | Wiser, S.K., Spencer, N., De Cáceres, M., Kleikamp, M., Boyle, B., & Peet, R.K. 2011. Veg-X - an exchange standard for plot-based vegetation data. Journal of Vegetation Science 22: 598–609. 29 | 30 | -------------------------------------------------------------------------------- /WhyBayesian/NotaEcosistemas_09may.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/WhyBayesian/NotaEcosistemas_09may.docx -------------------------------------------------------------------------------- /cienciometria/cienciometria.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/cienciometria/cienciometria.docx -------------------------------------------------------------------------------- /consejos_mejor_codigo/consejos_mejor_codigo.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Quince consejos para mejorar nuestro código y flujo de trabajo con R" 3 | 4 | author: Francisco Rodríguez-Sánchez 5 | 6 | output: 7 | word_document: 8 | reference_docx: Ecosistemas_template.docx 9 | csl: ecosistemas.csl 10 | bibliography: 11 | - references.bib 12 | - knitcitations.bib 13 | --- 14 | 15 | 16 | > Departamento de Biología Vegetal y Ecología, Universidad de Sevilla, Avda. Reina Mercedes s/n, 41012 Sevilla, España. 17 | 18 | > Autor para correspondencia: Francisco Rodríguez-Sánchez [f.rodriguez.sanc@gmail.com] 19 | 20 | 21 | 22 | 23 | # Palabras clave 24 | 25 | > flujo de trabajo; programación; R; reproducibilidad 26 | 27 | # Keywords 28 | 29 | > programming; R; reproducibility; workflow 30 | 31 | 32 | 33 | ```{r knitcitations, echo=FALSE, cache = FALSE} 34 | library("knitcitations") 35 | cleanbib() 36 | cite_options(citation_format = "pandoc") 37 | ``` 38 | 39 | 40 | 41 | La mayoría de los ecólogos que escribimos código informático para desarrollar nuestros análisis somos autodidactas [@Hernandez_2012]. Nunca hemos recibido formación sobre buenas prácticas de programación [@Wilson_2014; @Wilson_2017; @Rodriguez_Sanchez_2016]. En consecuencia, nuestro código es a menudo ineficiente, desordenado, propenso a errores, difícil de revisar y reutilizar. 42 | 43 | En esta nota se recogen 15 recomendaciones para mejorar nuestro flujo de trabajo y programación particularmente en lenguaje R `r citep(citation())` (aunque muchas de estas buenas prácticas sean igualmente aplicables a otros lenguajes). R se ha convertido en la herramienta estadística y lenguaje de programación más popular en ecología [@Lai_2019]. Estas recomendaciones pretenden evitar errores frecuentes y mejorar la calidad del código desarrollado en nuestros análisis. 44 | 45 | 46 | ## 1. Utiliza un sistema de control de versiones 47 | 48 | En lugar de guardar distintas versiones de nuestro código como `script_v1`, `script_v2`, etc., es muy recomendable utilizar herramientas como `git` (https://git-scm.com) que permiten tener un archivo perfectamente organizado de todos los cambios realizados en datos y código. `git` registra minuciosamente quién hizo qué, cuándo y por qué, y permite comparar y recuperar versiones anteriores. Cuando además se combina con plataformas como GitHub, GitLab o Bitbucket, se facilita enormemente el desarrollo colaborativo de proyectos [@Blischak_2016]. 49 | 50 | 51 | ## 2. Utiliza una estructura estándar de proyecto 52 | 53 | Idealmente, todos los archivos relacionados con un proyecto (datos, código, figuras, etc.) deben alojarse en la misma carpeta [@Wilson_2017; @cooper_guide_2017], por ejemplo aprovechando la infraestructura de [proyectos de RStudio](https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects). Utiliza el paquete `here` `r citep(citation("here"))` o `rprojroot` `r citep(citation("rprojroot"))` para especificar las rutas a los diferentes archivos dentro del proyecto. 54 | 55 | 56 | ## 3. Añade un fichero README 57 | 58 | Añade un fichero README al directorio raíz de tu proyecto que sirva como presentación del mismo [@Wilson_2017]: objetivos y elementos del proyecto, desarrolladores, licencia de uso, cómo citarlo, etc. 59 | 60 | 61 | ## 4. Utiliza un script maestro 62 | 63 | En proyectos relativamente complejos, donde se manejan varios conjuntos de datos o *scripts* de código, es muy recomendable tener un *script maestro* que se encargue de ejecutar todas las piezas en el orden correcto. Podría ser algo tan sencillo como este `makefile.R`: 64 | 65 | ```{r echo=TRUE, eval=FALSE} 66 | source("clean_data.R") 67 | source("fit_model.R") 68 | source("generate_report.R") 69 | ``` 70 | 71 | Paquetes como `drake` `r citep(citation("drake"))` o `targets` `r citep(citation("targets"))` permiten un control mucho más potente del flujo de trabajo, ejecutando solo aquello que necesita actualización, permitiendo paralelizar, etc. 72 | 73 | 74 | ## 5. Evita guardar el *workspace* 75 | 76 | En general, es preferible no guardar el espacio de trabajo (*workspace*, fichero `.RData`) al finalizar cada sesión de trabajo, para evitar la acumulación de objetos innecesarios en memoria. En su lugar, debemos guardar siempre el código fuente y guardar opcionalmente aquellos objetos (p. ej. usando `saveRDS`) que requieren computación larga o costosa [@bryan_what_2019]. 77 | 78 | 79 | ## 6. Aprovecha las ventajas de Rmarkdown 80 | 81 | Rmarkdown (https://rmarkdown.rstudio.com) permite integrar texto y código (no solo de R) y generar documentos dinámicos (incluyendo tablas, figuras, etc) que reproducen todo el proceso de análisis. Así, Rmarkdown facilita la colaboración y comunicación de resultados, y reduce drásticamente el número de errores [@cooper_guide_2017]. 82 | 83 | 84 | ## 7. Aprovecha las herramientas que ayudan a escribir mejor código 85 | 86 | Paquetes como `fertile` `r citep(list("10.1002/sta4.332", citation("fertile")))`, que nos avisa sobre posibles problemas en nuestro código y formas de solucionarlos, o `Rclean` `r citep(citation("Rclean"))`, que nos devuelve el código mínimo empleado para producir cualquier resultado, son muy útiles para escribir mejor código o mejorar código ya existente. 87 | 88 | 89 | ## 8. Comenta tu código 90 | 91 | Utiliza los comentarios para guiar al lector, [distinguir subsecciones](https://support.rstudio.com/hc/en-us/articles/200484568-Code-Folding-and-Sections), o explicar por qué se hacen las cosas de una determinada manera. 92 | 93 | 94 | ## 9. Utiliza nombres memorables 95 | 96 | Utiliza nombres con significado que resuman el contenido o función del objeto (p. ej. `modelo_aditivo`, `modelo_interactivo` en lugar de `m1`, `m2`); ver https://style.tidyverse.org/syntax.html. 97 | 98 | 99 | ## 10. Documenta los datos 100 | 101 | Prepara metadatos explicando qué representa cada variable (tipo de medida, unidades), autores, licencia de uso... Herramientas como `dataspice` `r citep(citation("dataspice"))` facilitan enormemente esta tarea, y mejoran la visibilidad y potencial de reutilización de los datos. 102 | 103 | 104 | ## 11. Comprueba los datos antes del análisis 105 | 106 | En cualquier proyecto puede ocurrir que los datos de partida contengan errores (introducidos al teclear los datos, importarlos o manipularlos). Por tanto es fundamental comprobar la calidad de los datos antes del análisis. Para ello, paquetes como `assertr` `r citep(citation("assertr"))`, `validate` `r citep(citation("validate"))` o `pointblank` `r citep(citation("pointblank"))` resultan muy útiles. 107 | 108 | Por ejemplo, el siguiente código 109 | 110 | ```{r echo=TRUE, eval=FALSE} 111 | library("assertr") 112 | 113 | dataset %>% 114 | assert(within_bounds(0, 0.20), fruit.weight) %>% 115 | assert(in_set("rojo", "negro"), colour) 116 | ``` 117 | 118 | comprueba que la variable `fruit.weight` contenga valores numéricos entre 0 y 0.20, y que la variable `colour` contenga solo dos valores ("rojo" y "negro"). Si estas condiciones no se cumplen, `assertr` nos avisará. 119 | 120 | 121 | ## 12. Comprueba los resultados del análisis 122 | 123 | Al igual que comprobamos los datos originales, podemos comprobar que los resultados del análisis entran dentro de lo esperado. Por ejemplo, si el resultado debe estar comprendido entre 0 y 1: 124 | 125 | ```{r echo=TRUE, eval=FALSE} 126 | output %>% 127 | assert(within_bounds(0, 1), result) 128 | ``` 129 | 130 | Tales comprobaciones son muy útiles para detectar posibles errores en nuestro código, cambios inesperados en paquetes, etc. 131 | 132 | 133 | ## 13. Escribe código modular 134 | 135 | Los *scripts* de código largos y desorganizados son más difíciles de revisar y, por tanto, más proclives a contener errores. Es conveniente escribir código modular; por ejemplo, partiendo un *script* largo en varios pequeños, o escribiendo funciones con un cometido específico e independientes del código principal del análisis. 136 | 137 | 138 | ## 14. Evita repeticiones 139 | 140 | A menudo necesitamos ejecutar unas líneas de código repetidamente. Por ejemplo, para producir una figura con distintas especies: 141 | 142 | ```{r echo=TRUE, eval=FALSE} 143 | dataset %>% 144 | filter(species == "Laurus nobilis") %>% 145 | ggplot() + 146 | geom_point(aes(x, y)) 147 | 148 | dataset %>% 149 | filter(species == "Laurus azorica") %>% 150 | ggplot() + 151 | geom_point(aes(x, y)) 152 | ``` 153 | 154 | ¿Cómo podemos evitar repetirnos? Una opción podría ser escribir un bucle (`for loop`) con iteraciones para cada especie: 155 | 156 | ```{r echo=TRUE, eval=FALSE} 157 | species <- c("Laurus nobilis", "Laurus azorica") 158 | 159 | for (i in species) { 160 | dataset %>% 161 | filter(species == i) %>% 162 | ggplot() + 163 | geom_point(aes(x, y)) 164 | } 165 | ``` 166 | 167 | Aún mejor, podríamos escribir una función que produzca la gráfica para una especie dada: 168 | 169 | ```{r echo=TRUE, eval=FALSE} 170 | plot_species <- function(sp, data) { 171 | data %>% 172 | filter(species == sp) %>% 173 | ggplot() + 174 | geom_point(aes(x, y)) 175 | } 176 | ``` 177 | 178 | Y después ejecutar esa función para todas las especies. Por ejemplo, usando `lapply`: 179 | 180 | ```{r echo=TRUE, eval=FALSE} 181 | lapply(species, plot_species, data = dataset) 182 | ``` 183 | 184 | o `purrr` `r citep(citation("purrr"))`: 185 | 186 | ```{r echo=TRUE, eval=FALSE} 187 | purrr:::map(species, plot_species, data = dataset) 188 | ``` 189 | 190 | 191 | ## 15. Registra las dependencias 192 | 193 | Todo análisis depende de un conjunto de paquetes que conviene documentar de manera consistente e interpretable. Ello nos permite, por ejemplo, ejecutar fácilmente el análisis en otro ordenador, o recrear el entorno computacional tras una actualización. 194 | 195 | Existen muchas opciones de documentar las dependencias de nuestro análisis, desde la función `sessionInfo`, paquetes como `automagic` `r citep(citation("automagic"))` o `renv` `r citep(citation("renv"))` que registran todos los paquetes utilizados (y sus versiones), a paquetes como `containerit` que facilitan la creación de un 'dockerfile' para recrear el entorno computacional en cualquier computadora [@N_st_2020]. 196 | 197 | 198 | Muchas de estas medidas son fáciles de implementar y no requieren grandes cambios en la organización del trabajo ni el estilo de programación; no obstante pueden contribuir a mejorar notablemente la calidad del código desarrollado para nuestros análisis, redundando por tanto en beneficios tanto para el programador como sus colaboradores y revisores. 199 | 200 | 201 | ###### AGRADECIMIENTOS 202 | 203 | Al Integrative Ecology Group, por incitar a la escritura de esta nota, y al grupo de Ecoinformática de la AEET (en particular a Antonio Pérez-Luque, Ruth Delgado, Hugo Saiz, Alfonso Garmendia, Aitor Ameztegui, David García-Callejas e Ignasi Bartomeus), por sus sugerencias para mejorarla. 204 | 205 | 206 | 207 | ###### REFERENCIAS 208 | 209 | ```{r write_citations, cache=FALSE, include=FALSE} 210 | write.bibtex(file = "knitcitations.bib") 211 | ``` 212 | 213 |
214 | 215 | 216 | 217 | ###### TABLA 1 218 | 219 | **Tabla 1**. Quince recomendaciones para mejorar nuestro código y flujo de trabajo en R. 220 | 221 | ```{r Tabla1, results='asis', echo=FALSE, cache=FALSE} 222 | library("knitr") 223 | tabla <- data.frame(Consejo = c( 224 | "1. Utiliza un sistema de control de versiones", 225 | "2. Utiliza una estructura estándar de proyectos", 226 | "3. Añade un fichero README al directorio raíz de tu proyecto", 227 | "4. Utiliza un script maestro ('makefile')", 228 | "5. Evitar guardar el espacio de trabajo ('workspace')", 229 | "6. Aprovecha las ventajas de Rmarkdown", 230 | "7. Aprovecha las herramientas que ayudan a escribir mejor código", 231 | "8. Comenta tu código", 232 | "9. Utiliza nombres memorables para los objetos", 233 | "10. Documenta los datos", 234 | "11. Comprueba los datos antes del análisis", 235 | "12. Comprueba los resultados del análisis", 236 | "13. Escribe código modular", 237 | "14. Evita repeticiones en el código", 238 | "15. Registra las dependencias" 239 | )) 240 | kable(tabla) 241 | ``` 242 | 243 | 244 | 245 | ###### PIES DE FIGURA 246 | 247 | **Figura 1**. Ejemplo de estructura de proyecto. Existe un fichero README (normalmente en formato markdown) con información general del proyecto (**recomendación nº 3**), un fichero especificando la licencia de uso de los datos y/o código, un fichero registrando las dependencias (**recomendación nº 15**), un *script* maestro o 'makefile' que ejecuta los distintos pasos del análisis en el orden correcto (**recomendación nº 4**), una carpeta de datos separando datos brutos y procesados, y una carpeta de análisis que contiene el código para generar las figuras finales y documentos Rmarkdown (**recomendación nº 6**) con los distintos pasos del análisis (**recomendación nº 13**). 248 | 249 | 250 | ###### FIGURA 1 251 | 252 | ```{r Fig1, echo=FALSE, fig.cap="Figura 1. Ejemplo de estructura de proyecto. Existe un fichero README (normalmente en formato markdown) con información general del proyecto (**recomendación nº 3**), un fichero especificando la licencia de uso de los datos y/o código, un fichero registrando las dependencias (**recomendación nº 15**), un *script* maestro o 'makefile' que ejecuta los distintos pasos del análisis en el orden correcto (**recomendación nº 4**), una carpeta de datos separando datos brutos y procesados, y una carpeta de análisis que contiene el código para generar las figuras finales y documentos Rmarkdown (**recomendación nº 6**) con los distintos pasos del análisis (**recomendación nº 13**).", cache=FALSE} 253 | knitr::include_graphics("Fig1.png") 254 | ``` 255 | -------------------------------------------------------------------------------- /consejos_mejor_codigo/consejos_mejor_codigo.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/consejos_mejor_codigo/consejos_mejor_codigo.docx -------------------------------------------------------------------------------- /consejos_mejor_codigo/consejos_mejor_codigo.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/consejos_mejor_codigo/consejos_mejor_codigo.pdf -------------------------------------------------------------------------------- /crear_paquetes_R/ecosistemas.csl: -------------------------------------------------------------------------------- 1 | 2 | 186 | -------------------------------------------------------------------------------- /crear_paquetes_R/notaAEET_crear_paquetes_R.rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Cómo crear paquetes de R \n" 3 | author: "David García-Callejas^1^, Marcelino de la Cruz Rot^2^" 4 | csl: ecosistemas.csl 5 | output: 6 | word_document: default 7 | fig_caption: yes 8 | fig_height: 6 9 | fig_width: 7.5 10 | highlight: null 11 | reference_docx: notaAEET_crear_paquetes_R.docx 12 | bibliography: 13 | - references.bib 14 | 15 | --- 16 | 17 | 18 | > (1) Estación Biológica de Doñana (CSIC). Américo Vespucio 26, 41092 Sevilla. 19 | > (2) Departmento de Biología y Geología, Física y Química Inorgánica. ESCET. Universidad Rey Juan Carlos. Móstoles. 20 | 21 | > Autor para correspondencia: David García-Callejas [david.garcia.callejas@gmail.com] 22 | 23 | 24 | # Palabras clave 25 | 26 | > Ciencia reproducible. 27 | 28 | 29 | # Keywords 30 | 31 | > Reproducible research. 32 | 33 | 34 | ```{r include=FALSE} 35 | 36 | knitr::opts_chunk$set(eval = FALSE) 37 | 38 | # NOTA: Todos los chunks de código necesarios para seguir paso a paso 39 | # la construcción del paquete tienen implícito EVAL=TRUE. 40 | # En este chunk los reseteamos a EVAL=FALSE para que no se evalúe durante 41 | # la compilación del documento, pero haciendo esto podríamos ejecutar: 42 | # 43 | # knitr::purl("notaAEET_crear_paquetes_R.rmd") 44 | # 45 | # lo que nos generará el archivo "notaAEET_crear_paquetes_R.R" con todo el 46 | # código necesario. Haciendo: 47 | # 48 | # source("notaAEET_crear_paquetes_R.R") 49 | # 50 | # creamos el paquete y corremos todos los ejemplos. 51 | 52 | ``` 53 | 54 | ```{r knitcitations, echo=FALSE, cache = FALSE, eval=TRUE, warning = FALSE} 55 | library(knitcitations) 56 | library(bibtex) 57 | cleanbib() 58 | cite_options(citation_format = "pandoc") 59 | ``` 60 | 61 | ```{r, eval=FALSE, echo=F} 62 | 63 | 64 | # CREAR DOCUMENTO: 65 | # library(rmarkdown) 66 | # render("Cómo crear paquetes de R.rmd") 67 | 68 | 69 | ``` 70 | 71 | # ¿Por qué crear un paquete de R? 72 | 73 | En el lenguaje de programación R `r citep(citation())`, los paquetes son la mejor manera de organizar, mantener y distribuir código y documentación. La motivación más directa para crear un paquete es la facilidad con que permiten compartir código con otros usuarios, pero de igual manera resulta extremadamente útil crear paquetes "de consumo propio", por ejemplo con funciones generales que son utilizadas en diferentes proyectos (véase @Delacruz_2019 para la creación de funciones en R). Incluir un paquete de R, bien documentado, en el material suplementario de un artículo o de un informe científico garantiza la reproducibilidad de los resultados y promueve la difusión de los mismos. 74 | 75 | [[ibartomeus: Yo añadiria una frase sobre cuando crear un paquete de R? tan pronto tienes al menos una funcion que sus recurrentemente. No necesitan ser grandes]] 76 | 77 | Existen numerosos recursos en internet con consejos y recetas para crear paquetes de R. La referencia fundamental es el manual oficial ["Writing R Extensions"][1], que acompaña cada instalación de R, centrado en la construcción manual, paso a paso, de los paquetes. Además, Wickham [-@Wickham_2015] (disponible en http://r-pkgs.had.co.nz/; segunda edición en camino disponible en https://r-pkgs.org/) proporciona una visión alternativa basada en la automatización de las tareas necesarias para la construcción y, sobre todo, el mantenimiento de paquetes. En esta sucinta nota, proporcionaremos una visión muy básica de la creación de paquetes usando la funcionalidad de los paquetes `devtools` `r citep(citation("devtools"))` y `roxygen2` [@Wickham_2018]. Por lo tanto, necesitaremos tener instalados ambos paquetes. Con la instrucción 78 | 79 | ```{r, eval=FALSE} 80 | install.packages("devtools", dependencies=TRUE) 81 | ``` 82 | nos aseguramos de tener instalados ambos. En todo caso, recomendamos que los usuarios interesados en conocer en detalle la estructura y creación de paquetes se remitan al manual oficial. ~~En dicho manual, además, se detallan los requisitos adicionales para la publicación de paquetes en [CRAN][cran0], el repositorio oficial de paquetes de R.~~ [[En el manual de Hadley también se explica cómo preparar el paquete para CRAN. Propongo corregir o eliminar esta frase]] 83 | 84 | # Estructura básica 85 | 86 | El primer paso para crear un paquete es la creación de la estructura de directorios (carpetas) asociada al paquete. Si, para nuestro pequeño ejemplo, creamos un paquete que se llama `paqueteR`, lo primero que necesitamos es crear una carpeta con dicho nombre y, dentro de ella, un archivo llamado `DESCRIPTION` (tal cual, sin extensión) que contenga, como mínimo, el siguiente texto: 87 | 88 | [[ibartomeus: Yo añadiria una linea con la importancia de usar nombres y un link]] 89 | 90 | ```` 91 | Package: paqueteR 92 | Version: 0.1 93 | encoding: UTF-8 94 | ```` 95 | Si queremos hacer todo esto directamente desde R, solo tendremos que escribir: 96 | ```{r} 97 | dir.create("paqueteR") 98 | setwd("./paqueteR") 99 | cat(c("Package: paqueteR", "Version: 0.1", "encoding: UTF-8"), sep="\n", file="DESCRIPTION") 100 | ``` 101 | 102 | [[Esto por supuesto es correcto, pero para una nota introductoria de cómo crear paquetes me parece innecesariamente enrevesado. Creo que hay formas mucho más sencillas, por ejemplo usethis::create_package, o directamente en Rstudio -> create new package, para usuarios de Rstudio. Y si no el viejo package.skeleton... Yo recomendaría Rstudio o usethis]] 103 | 104 | El archivo `DESCRIPTION` suele contener, además de estos campos, multitud de información, incluyendo un pequeño resumen de su funcionalidad, los autores y, en su caso, las dependencias del paquete, es decir, los paquetes auxiliares que utilicemos en las funciones de nuestro propio paquete. En el manual citado anteriormente (sección [*"1.1.1 The DESCRIPTION file"*][DESCRIPTION_REF]) se puede consultar en detalle el contenido de este importante archivo. 105 | 106 | # Añadir y documentar código 107 | 108 | El siguiente paso es añadir el código que queremos incluir en nuestro paquete. Siguiendo con nuestro ejemplo, nos gustaría que nuestro `paqueteR` incluya dos funciones: 109 | 110 | [[esto ya es cuestión de preferencias personales, pero como sugerencia, quizás meter la función entre llaves? i.e. function (x) {sqrt(x)}. Porque para funciones más complejas al final las van a necesitar...]][[ibartomeus: estoy de acuerdo que facilita comprension]] 111 | 112 | ```{r} 113 | sqrtfun1 <- function(x) sqrt(x) 114 | sqrtfun2 <- function(x) x^(1/2) 115 | ``` 116 | 117 | En general, es recomendable guardar cada función en un archivo independiente que tenga el mismo nombre que la función. Esto facilita la modularidad del código y evita potenciales duplicidades. En nuestro caso, por tanto, tendríamos un archivo `sqrtfun1.R` y otro `sqrtfun2.R`. Para incluir ambas funciones en nuestro paquete, hemos de crear una carpeta llamada `R` dentro del directorio principal, y mover allí nuestras funciones. 118 | 119 | [[Creo que esta parte de abajo se puede quitar, por simplificar la nota e intentar acercarnos a las 1000 palabras. Además creo que en general las funciones ya se escribirán directamente sobre un fichero .R, no directamente en la consola no?]] 120 | 121 | ~~Si las funciones las tenemos en nuestro *workspace*, y queremos hacerlo todo desde R podemos escribir en la consola: 122 | 123 | ```{r} 124 | dir.create("R") 125 | dump("sqrtfun1", file="./R/sqrtfun1.R") 126 | dump("sqrtfun2", file="./R/sqrtfun2.R") 127 | ``` 128 | 129 | 130 | 131 | 132 | Con estos sencillos pasos ya tenemos la estructura básica de un paquete, pero antes de "construirlo" es necesario documentar nuestro código, para facilitar su distribución y uso por parte de otros usuarios (o de nosotros mismos en un futuro). Generar documentación a través de `roxygen2` es muy sencillo. Basta con añadir, al comienzo de nuestros archivos .R, una serie de campos que expliquen el uso de la función en cuestión (el comando 'Insert Roxygen Skeleton' en RStudio puede ayudar generando una plantilla). En nuestras funciones, los archivos documentados tendrían la siguiente forma: 133 | 134 | ```` 135 | #' Raíz cuadrada 1 136 | #' 137 | #' Función para calcular la raíz cuadrada. 138 | #' 139 | #' @param x Un vector, o array, numérico o complejo 140 | #' 141 | #' @return Raíz cuadrada de x 142 | #' @export 143 | #' 144 | #' @examples sqrt(10) 145 | sqrtfun1 <- function(x) sqrt(x) 146 | ```` 147 | ```{r, echo=FALSE} 148 | # ESTO LO INCLUYO PARA TENER TODOS LOS PASOS EN R 149 | # NO SALE EN LA NOTA ECOINFORMATICA 150 | 151 | cat("#' Raíz cuadrada 1 152 | #' 153 | #' Función para calcular la raíz cuadrada. 154 | #' 155 | #' @param x Un vector, o array, numérico o complejo 156 | #' 157 | #' @return Raíz cuadrada de x 158 | #' @export 159 | #' 160 | #' @examples sqrtfun1(10) 161 | sqrtfun1 <- function(x) sqrt(x)",file="./R/sqrtfun1.R") 162 | 163 | cat("#' Raíz cuadrada 2 164 | #' 165 | #' Función para calcular la raíz cuadrada. 166 | #' 167 | #' @param x Un vector, o array, numérico o complejo 168 | #' 169 | #' @return Raíz cuadrada de x 170 | #' @export 171 | #' 172 | #' @examples sqrtfun2(10) 173 | sqrtfun2 <- function(x) x^(1/2)", file="./R/sqrtfun2.R") 174 | 175 | ``` 176 | 177 | Como se puede observar, la parte dedicada a la documentación viene distinguida por dos caracteres especiales al comienzo de cada línea (`#'`). La primera línea indica el título de la función, y las siguientes pueden llevar una descripción más detallada de la misma. Cada argumento de la función viene documentado por un campo `@param`, y el tipo de dato que devuelve la función viene explicado en el campo `@return`. El campo `@export` indica que la función estará disponible para los usuarios del paquete, y en `@examples` podemos incluir ejemplos de uso de nuestra función. Estos campos corresponden exactamente con los que podemos ver en la ayuda de cualquier función de R; existen varios campos más que, por concreción, no detallamos aquí pero pueden ser consultados en la ayuda o en las [viñetas][roxygen2] de `roxygen2`. Una vez nuestras funciones están apropiadamente documentadas, y con el directorio de trabajo en el directorio base de nuestro paquete, podemos procesar la documentación con 178 | 179 | ```{r} 180 | devtools::document() 181 | ``` 182 | Si no ha habido ningún problema, esta acción habrá generado un archivo nuevo en nuestro directorio llamado `NAMESPACE`, así como un archivo .Rd en la subcarpeta `man` por cada función de nuestro paquete. El ~~"espacio de nombres"~~`NAMESPACE` [[creo que es mejor usar NAMESPACE]] es una guía que indica a R 1) si una función del paquete está disponible (una función exportable) o no (una función interna) y 2) dónde se encuentran las funciones de otros paquetes que se emplean dentro del código de nuestras funciones. Cada uno de los archivos .Rd contiene la documentación que hemos creado y servirá para generar las páginas de ayuda y el manual del paquete cuando realicemos la instalación. 183 | 184 | # Creación del paquete 185 | 186 | Con esta estructura básica, ya tenemos todos los requisitos para construir nuestro `paqueteR`. Para este último paso basta con teclear en la terminal de R (de nuevo, desde la carpeta principal del paquete) 187 | 188 | ```{r} 189 | devtools::build() 190 | ``` 191 | Esta función generará un archivo comprimido .tar.gz con nuestro flamante paquete listo para ser compartido. Para instalar el paquete, basta con teclear el comando [[(desde el directorio raiz del paquete, verdad?]] 192 | 193 | ```{r} 194 | devtools::install() 195 | ``` 196 | Podemos comprobar si todo ha ido bien cargando nuestro paquete como cualquier otro e invocando directamente las funciones o la ayuda sobre las mismas. 197 | 198 | ```{r} 199 | library(paqueteR) 200 | sqrtfun1(25) 201 | ?sqrtfun1 202 | ``` 203 | Frente a la facilidad para crear un paquete sencillo como este, la única pega que le podemos poner a `devtools` es que no siempre respeta los caracteres propios del español (por ejemplo, la **ñ** o las vocales con tilde) en los ficheros de ayuda. Teniendo en cuenta que lo habitual es escribir la documentación de los paquetes de R en inglés, esto no suele suponer un problema (que por otra parte se puede solucionar o bien evitando dichos caracteres o bien adoptando la aproximación ortodoxa promovida en el manual oficial y aprovechando la posibilidad de [codificación alternativa][encoding_issues]). 204 | 205 | Además de lo esbozado en esta nota, los paquetes de R pueden incluir conjuntos de datos, y son estructuras ideales para trabajar con plataformas de control de versiones como git y el servidor github. En internet se pueden encontrar multitud de tutoriales específicos, entre los cuales recomendamos [el desarrollado por Karl Broman][tutorial]. El código necesario para reproducir este documento y el `paqueteR` usado como ejemplo se puede consultar en [GitHub][github_nota]. 206 | 207 | [1]: https://cloud.r-project.org/doc/manuals/r-release/R-exts.html 208 | [cran0]: https://cran.r-project.org/ 209 | [roxygen2]: https://roxygen2.r-lib.org/index.html 210 | [DESCRIPTION_REF]: https://cloud.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file 211 | [encoding_issues]: https://cloud.r-project.org/doc/manuals/r-release/R-exts.html#Encoding-issues 212 | [tutorial]: https://kbroman.org/pkg_primer/ 213 | [github_nota]: https://github.com/marcelinodelacruz/Como-crear-paquetes-de-R 214 | 215 | # Agradecimientos 216 | 217 | MCR agradece la financiación del proyecto REMEDINAL TE-CM (S2018/EMT-4338). DGC agradece la financiación del proyecto SIMPLEX (MINECO PRPCGL2017-92436-EXP). 218 | 219 | 220 | ###### REFERENCIAS 221 | 222 | ```{r write_citations, cache=FALSE, include=FALSE, eval=FALSE} 223 | ref <- read.bib("references.bib", encoding = 'UTF-8') 224 | #write.bibtex(file = "knitcitations.bib", encoding="UTF-8") 225 | write.bibtex(entry = ref, append=FALSE) 226 | ``` 227 | -------------------------------------------------------------------------------- /crear_paquetes_R/references.bib: -------------------------------------------------------------------------------- 1 | 2 | @Article{Delacruz_2019, 3 | author = {Marcelino de la Cruz}, 4 | title = {Como escribir funciones en R.}, 5 | journal = {Ecosistemas}, 6 | year = {2019}, 7 | } 8 | 9 | @Book{Wickham_2015, 10 | title = {R Packages: Organize, Test, Document, and Share Your Code.}, 11 | publisher = {O'Reilly}, 12 | year = {2015}, 13 | author = {Hadley Wickham}, 14 | isbn = {9781491910580}, 15 | url = {http://r-pkgs.had.co.nz/}, 16 | } 17 | 18 | @Manual{Wickham_2018, 19 | title = {roxygen2: In-Line Documentation for R}, 20 | author = {Hadley Wickham and Peter Danenberg and Manuel Eugster}, 21 | year = {2018}, 22 | note = {R package version 6.1.1}, 23 | url = {https://CRAN.R-project.org/package=roxygen2}, 24 | } 25 | 26 | 27 | @Manual{R_Core_Team_2019, 28 | title = {R: A Language and Environment for Statistical Computing}, 29 | author = {{R Core Team}}, 30 | organization = {R Foundation for Statistical Computing}, 31 | address = {Vienna, Austria}, 32 | year = {2019}, 33 | url = {https://www.R-project.org/}, 34 | } 35 | 36 | @Manual{Wickham_2019, 37 | title = {devtools: Tools to Make Developing R Packages Easier}, 38 | author = {Hadley Wickham and Jim Hester and Winston Chang}, 39 | year = {2019}, 40 | note = {R package version 2.2.1}, 41 | url = {https://CRAN.R-project.org/package=devtools}, 42 | } -------------------------------------------------------------------------------- /directrices_revisores.MD: -------------------------------------------------------------------------------- 1 | # Directrices para los revisores de las notas 2 | 3 | Las [Notas Ecoinformáticas](https://ecoinfaeet.github.io/notas-ecoinformaticas.html) se revisarán mediante un proceso abierto y dinámico siguiendo el proceso de revisión grupal. Estas son algunas directrices básicas que los revisores tendrán que responder en el proceso de revisión: 4 | 5 | 1) ¿Está escrita de forma clara? 6 | 7 | 2) ¿Da una visión general del tema para ecólogos no especialistas en ecoinformática? 8 | 9 | 3) ¿Son las referencias o tutoriales especializados para quien quiera saber más adecuados y suficientes? 10 | 11 | 4) ¿Están los ejemplos (con código) suficientemente explicados y funcionan? 12 | 13 | 5) ¿En caso de incluir código utiliza un estilo consistente a lo largo de la nota? Por ejemplo, en caso de incluir código de R, ¿el código sigue las normas de estilo especificadas [aquí](http://adv-r.had.co.nz/Style.html)? 14 | -------------------------------------------------------------------------------- /estadistica_circular/.gitignore: -------------------------------------------------------------------------------- 1 | # History files 2 | .Rhistory 3 | .Rapp.history 4 | 5 | # Session Data files 6 | .RData 7 | 8 | # Example code in package build process 9 | *-Ex.R 10 | 11 | # Output files from R CMD build 12 | /*.tar.gz 13 | 14 | # Output files from R CMD check 15 | /*.Rcheck/ 16 | 17 | # RStudio files 18 | .Rproj.user/ 19 | 20 | # produced vignettes 21 | vignettes/*.html 22 | vignettes/*.pdf 23 | 24 | # OAuth2 token, see https://github.com/hadley/httr/releases/tag/v0.3 25 | .httr-oauth 26 | 27 | # knitr and R markdown default cache directories 28 | /*_cache/ 29 | /cache/ 30 | 31 | # Temporary files created by R markdown 32 | *.utf8.md 33 | *.knit.md 34 | 35 | # Shiny token, see https://shiny.rstudio.com/articles/shinyapps.html 36 | rsconnect/ 37 | .Rproj.user 38 | 39 | # html documents 40 | 41 | /*.html 42 | 43 | # figures 44 | 45 | /*.jpg 46 | 47 | -------------------------------------------------------------------------------- /estadistica_circular/README.md: -------------------------------------------------------------------------------- 1 | # Nota_estadistica_circular 2 | Nota para la revista ecosistema sobre estadística circular aplicada a la Ecología 3 | -------------------------------------------------------------------------------- /estadistica_circular/ecosistemas.csl: -------------------------------------------------------------------------------- 1 | 2 | 186 | -------------------------------------------------------------------------------- /estadistica_circular/knitcitations_estadistica_circular.bib: -------------------------------------------------------------------------------- 1 | @Manual{Agostinelli_2017, 2 | title = {{R} package \texttt{circular}: Circular Statistics (version 0.4-93)}, 3 | author = {C. Agostinelli and U. Lund}, 4 | address = {CA: Department of Environmental Sciences, Informatics 5 | and Statistics, Ca' Foscari University, Venice, Italy. UL: Department of Statistics, California Polytechnic State University, San Luis Obispo, California, USA}, 6 | year = {2017}, 7 | url = {https://r-forge.r-project.org/projects/circular/}, 8 | } 9 | 10 | @Article{Landler_2018, 11 | doi = {10.1007/s00265-018-2538-y}, 12 | url = {https://doi.org/10.1007/s00265-018-2538-y}, 13 | year = {2018}, 14 | month = {jul}, 15 | publisher = {Springer Science and Business Media {LLC}}, 16 | volume = {72}, 17 | number = {8}, 18 | author = {Lukas Landler and Graeme D. Ruxton and E. Pascal Malkemper}, 19 | title = {Circular data in biology: advice for effectively implementing statistical procedures}, 20 | journal = {Behavioral Ecology and Sociobiology}, 21 | } 22 | 23 | @Manual{Lund_2018, 24 | title = {CircStats: Circular Statistics, from "Topics in Circular Statistics" (2001)}, 25 | author = {S-plus original by Ulric Lund and R port by Claudio Agostinelli}, 26 | year = {2018}, 27 | note = {R package version 0.2-6}, 28 | url = {https://CRAN.R-project.org/package=CircStats}, 29 | } 30 | 31 | @Article{Monterroso_2014, 32 | doi = {10.1007/s00265-014-1748-1}, 33 | url = {https://doi.org/10.1007/s00265-014-1748-1}, 34 | year = {2014}, 35 | month = {jun}, 36 | publisher = {Springer Science and Business Media {LLC}}, 37 | volume = {68}, 38 | number = {9}, 39 | pages = {1403--1417}, 40 | author = {Pedro Monterroso and Paulo C{\a'e}lio Alves and Pablo Ferreras}, 41 | title = {Plasticity in circadian activity patterns of mesocarnivores in Southwestern Europe: implications for species coexistence}, 42 | journal = {Behavioral Ecology and Sociobiology}, 43 | } 44 | 45 | @Manual{R_Core_Team_2019, 46 | title = {R: A Language and Environment for Statistical Computing}, 47 | author = {{R Core Team}}, 48 | organization = {R Foundation for Statistical Computing}, 49 | address = {Vienna, Austria}, 50 | year = {2019}, 51 | url = {https://www.R-project.org/}, 52 | } 53 | 54 | @Manual{Rowcliffe_2019, 55 | title = {activity: Animal Activity Statistics}, 56 | author = {Marcus Rowcliffe}, 57 | year = {2019}, 58 | note = {R package version 1.3}, 59 | url = {https://CRAN.R-project.org/package=activity}, 60 | } 61 | 62 | @Manual{Tsagris_2020, 63 | title = {Directional: Directional Statistics}, 64 | author = {Michail Tsagris and Giorgos Athineou and Anamul Sajib and Eli Amson and Micah J. Waldstein}, 65 | year = {2020}, 66 | note = {R package version 4.1}, 67 | url = {https://CRAN.R-project.org/package=Directional}, 68 | } 69 | 70 | @Book{Wickham_2016, 71 | author = {Hadley Wickham}, 72 | title = {ggplot2: Elegant Graphics for Data Analysis}, 73 | publisher = {Springer-Verlag New York}, 74 | year = {2016}, 75 | isbn = {978-3-319-24277-4}, 76 | url = {https://ggplot2.tidyverse.org}, 77 | } 78 | 79 | @Manual{Xu_2019, 80 | title = {cplots: Plots for Circular Data}, 81 | author = {Danli Xu and Yong Wang}, 82 | year = {2019}, 83 | note = {R package version 0.4-0}, 84 | url = {https://CRAN.R-project.org/package=cplots}, 85 | } 86 | -------------------------------------------------------------------------------- /estadistica_circular/manuscript_estadistica_circular.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Estadística circular aplicada a la Ecología\n" 3 | 4 | author: Irene Mendoza^1^ 5 | 6 | csl: ecosistemas.csl 7 | output: 8 | word_document: 9 | fig_caption: yes 10 | fig_height: 8 11 | fig_width: 10 12 | highlight: null 13 | reference_docx: estadistica_circular.docx 14 | 15 | bibliography: 16 | - references_estadistica_circular.bib 17 | - knitcitations_estadistica_circular.bib 18 | --- 19 | 20 | 21 | > (1) Departamento de Ecología Integrativa. Estación Biológica de Doñana (CSIC). 22 | 23 | > Autora para correspondencia: Irene Mendoza [irene.mendoza@ebd.csic.es] 24 | 25 | 26 | ## Palabras clave 27 | 28 | > fenología; actividad diaria; test de Rayleigh; test de Mardia-Watson-Wheeler 29 | 30 | 31 | ## Keywords 32 | 33 | > phenology; diel activity; Rayleigh test; Mardia-Watson-Wheeler test 34 | 35 | 36 | ```{r knitcitations, echo=FALSE, cache = FALSE, warning = FALSE} 37 | library(knitcitations) 38 | library(RefManageR) 39 | library(bibtex) 40 | cleanbib() 41 | cite_options(citation_format = "pandoc") 42 | ``` 43 | 44 | 45 | 46 | La estadística circular es una poderosa herramienta que permite analizar variables que tienen una naturaleza cíclica para las que la estadística lineal no es apropiada. Algunos ejemplos clásicos en Ecología incluyen el estudio de la fenología de una especie a lo largo del año o los patrones de actividad diarios de animales. En estos casos, la designación de un cero (y de valores mayores o menores) es completamente arbitraria. Por ejemplo, la diferencia entre el mes de enero y diciembre es de solo un mes en una escala circular, mientras que en una escala lineal, dicha diferencia sería de 12 meses. 47 | 48 | # Transformación en ángulos de nuestra variable de naturaleza circular 49 | La primera transformación que debemos hacer con nuestros datos de naturaleza circular es convertirlos en ángulos mediante una simple ecuación [@Zar1999]: 50 | 51 | 52 | $$ 53 | a = \frac{(360^\circ)(X)}{k} 54 | $$ 55 | *X* representa la variable temporal que queremos convertir en un valor angular (en $^\circ$) y *k* es la cantidad total de unidades de tiempo de nuestra circunferencia (*k* = 365 para días del año o *k* = 12 para meses, por ejemplo). De esta manera, el 14 de febrero, que es el 45º día del año, corresponde a 56 | 57 | ```{r ejemplo14feb, eval = TRUE, echo = TRUE} 58 | a <- 360*45/365 59 | ``` 60 | `r round(a, 2)`$^\circ$. En el caso de medidas mensuales, los 360$^\circ$ se dividen en 12 sectores de 30$^\circ$. Por convención, se considera el punto medio del sector como el correspondiente a cada mes, es decir 15$^\circ$ para enero, 45$^\circ$ para febrero, ... y 345$^\circ$ para diciembre. 61 | 62 | # Ejemplos usados 63 | Usaré dos ejemplos en esta nota, uno referido a fenología de la fructificación en Nouragues (Guyana francesa) extraído de Mendoza *et al.* [-@Mendoza2018] y el otro a los patrones de actividad del agutí y del pecarí de la Isla de Barro Colorado [@Rowcliffe2014], extraídos del paquete `activity` `r citep(citation("activity"))`. Me centraré en tres de los muchos paquetes de R `r citep(citation())` que permiten analizar datos circulares: `Directional` `r citep(citation("Directional"))`, `CircStats` `r citep(citation("CircStats"))`, y `circular` `r citep(citation("circular"))`, así como el paquete `ggplot2` `r citep(citation("ggplot2"))` para las representaciones gráficas. Debido a las limitaciones de espacio de esta nota, se recomienda revisar otras referencias para tener más detalle de los métodos, fórmulas exactas y aplicaciones a la Ecología de la estadística circular [@Zar1999; @Batschelet1981; @Morellato2010; @MardiaJupp2000; @Staggemeier2020] así como otros paquetes de R disponibles para análisis circulares (p.ej. `NPCirc` `r citep(citation("NPCirc"))`. 64 | 65 | ```{r librarycall, eval = TRUE, echo = TRUE, warning = FALSE, message = FALSE} 66 | library(activity) 67 | library(circular) 68 | library(CircStats) 69 | library(Directional) 70 | library(ggplot2) 71 | ``` 72 | 73 | 74 | ```{r dataexample, eval = TRUE, echo = TRUE} 75 | aguti <- subset(activity::BCItime, species == "agouti") 76 | pecari <- subset(activity::BCItime, species == "peccary") 77 | #se seleccionan los datos del agutí y pecarí de la base de datos BCItime del paquete "activity". El tiempo de muestreo está expresado como una proporción relativa a las 24 horas de un día. 78 | 79 | frutofrq <- data.frame(meses = month.abb, meses.ang = seq(15, 350, 30), numspp = c(21, 23, 32, 31, 29, 20, 19, 18, 15, 17, 21, 16)) 80 | 81 | #estos datos representan el número de especies en fruto por mes en Nouragues (extraído de Mendoza et al. 2018). 82 | #"meses.ang" es el valor angular de cada mes 83 | ``` 84 | 85 | # Representaciones gráficas de datos circulares 86 | 87 | Cualquier estadística descriptiva pasa por la representación gráfica de los datos. En el caso de datos circulares, el paquete `circular` `r citep(citation("circular"))` permite hacer *diagramas de rosa* convirtiendo los datos circulares en un objeto `circular` primero y usando luego `rose.diag` (Fig. 1). 88 | 89 | ```{r circaguti, echo = TRUE, eval = FALSE} 90 | aguti.circ <- circular::circular(aguti$time*24, units = "hours", template = "clock24") 91 | pecari.circ <- circular::circular(pecari$time*24, units = "hours", template = "clock24") 92 | #convertimos en horas los valores temporales expresados como proporción 93 | 94 | #Fig. 1: 95 | circular::rose.diag(aguti.circ, main = "agutí", bins = 24, prop = 2) 96 | circular::rose.diag(pecari.circ, main = "pecarí", bins = 24, prop = 2) 97 | #el argumento "bins" especifica el número de grupos en los que se divide la circunferencia. En nuestro caso son 24, uno por cada hora del día. 98 | ``` 99 | 100 | 101 | En los diagramas de rosa cada sección del histograma (con forma de cuña) muestra el número de observaciones para cada rango de valores angulares (o temporales). El área del sector es proporcional a la frecuencia de cada grupo y el radio, a la raíz cuadrada de la frecuencia relativa de cada grupo. La función `coord_polar` del paquete `ggplot2` permite muchas más opciones gráficas para representarlos (Fig. 2). 102 | 103 | ```{r fig2, echo = TRUE, eval = FALSE} 104 | fig2 <- ggplot(frutofrq, aes(x = meses.ang, y = sqrt(numspp))) + geom_bar(stat='identity') + coord_polar() + ylim(-7,35) #gracias al parámetro "ylim" controlamos el círculo interno. 105 | ``` 106 | 107 | # Principales métricas circulares: media angular, desviación estándar angular y vector *r* 108 | 109 | La estadística linear no sirve para describir adecuadamente datos circulares. Para eso, se han desarrollado métricas circulares como la media, varianza y desviación estándar circulares. Se calculan fácilmente con la función `circ.summary` del paquete `Directional`. Se recuerda que los datos se convierten de grados a radianes usando la fórmula $360^\circ = {2\pi}\; rad$. 110 | 111 | ```{r circmetric, echo = TRUE, eval = TRUE} 112 | aguti.sum <- Directional::circ.summary(aguti$time*2*pi, plot = F) 113 | 114 | aguti.sum$mesos #media angular en radianes 115 | 116 | aguti.sum$circstd #desviación estándar circular en radianes 117 | ``` 118 | 119 | En el caso de datos resumidos en forma de frecuencias (como ocurre para los datos de fruto de Nouragues), se deben convertir las frecuencias en un vector único que repita cada valor angular el número de veces de su frecuencia. Una vez conseguido este vector, se podrá aplicar la función `circ.summary` como en el caso anterior. 120 | 121 | ```{r circmetricfreq, echo = TRUE, eval = TRUE} 122 | 123 | fruto <- c(rep(15,21), rep(45,23), rep(75,32), rep(105,31), rep(135,29), rep(165,20), rep(195,19), rep(225,18), rep(255, 15), rep(285,17), rep(315,21), rep(345,16)) 124 | 125 | fruto.sum <- Directional::circ.summary(fruto, plot = F, rads = F) 126 | 127 | fruto.sum$MRL 128 | 129 | #la forma elegante de hacer esto es con un loop: 130 | #for (i in 1:12) { 131 | #frut <- rep(frutofrq$meses.ang[i], frutofrq$numspp[i]) 132 | #if (i == 1) fruto = frut else fruto = c(fruto, frut) 133 | #} 134 | ``` 135 | De estas métricas, el vector *r* representa la longitud del vector medio (llamado *MRL* por la función `circ.summary`). Es un valor adimensional que varía entre 0 y 1 y mide la dispersión de los datos (0 indica dispersión uniforme en todas las direcciones y 1, todas las observaciones apuntando en la misma dirección). El vector *r* se utiliza en fenología como una estima de la concentración de la actividad o la estacionalidad de la fenofase, siendo mayor cuanto más cercano a 1. En el caso de la fructificación en Nouragues, al estar los datos agrupados por meses, debemos multiplicar *r* por un factor de corrección $c<- (30*\pi/360)/sin(30/2)$, resultando en `r round(fruto.sum$MRL*(30*pi/360)/sin(30/2), 2)`. 136 | 137 | # Test de uniformidad de una muestra: test de Rayleigh como medida de estacionalidad 138 | 139 | La forma de verificar estadísticamente si una distribución circular es significativamente estacional es usando el *test de Rayleigh* [@Zar1999]. La hipótesis nula es que la distribución circular es uniforme, es decir, que no hay una dirección angular preferida. El test de Rayleigh asume que la distribución de los datos es unimodal. Para distribuciones multimodales, existen otros test [ver`r citep("10.1007/s00265-018-2538-y")`]. 140 | 141 | ```{r rtest, echo = TRUE, eval = TRUE} 142 | CircStats::r.test(fruto, degree = T) 143 | ``` 144 | Gracias a este test podemos ver que, a pesar del bajo valor de *r* para Nouragues, la fructificación es significativamente estacional, con el valor máximo en marzo (Fig. 2). 145 | 146 | # Test entre dos distribuciones circulares: test de Mardia-Watson-Wheeler aplicado a los patrones actividad de los animales 147 | 148 | Muchos trabajos [ver `r citet("10.1007/s00265-014-1748-1")` como ejemplo] analizan los patrones de actividad diaria de diferentes especies animales usando el *test de Mardia-Watson-Wheeler* [@Batschelet1981]. Este test permite detectar si dos muestras circulares difieren significativamente entre sí de una forma no paramétrica. La forma más sencilla de calcularlo es usando la función `watson.wheeler.test` del paquete `circular`. 149 | 150 | ```{r mardiatestfalse, echo = TRUE, eval = FALSE, warning = FALSE} 151 | circular::watson.wheeler.test(list(aguti.circ, pecari.circ)) 152 | ``` 153 | 154 | ```{r mardiatest, echo = FALSE, eval = TRUE, warning = FALSE} 155 | aguti.circ <- circular::circular(aguti$time*24, units = "hours", template = "clock24") 156 | pecari.circ <- circular::circular(pecari$time*24, units = "hours", template = "clock24") 157 | 158 | circular::watson.wheeler.test(list(aguti.circ, pecari.circ)) 159 | ``` 160 | En el ejemplo de los datos de actividad del agutí y el pecarí, tal y como se observaba en la Fig. 1, el test nos demuestra que las dos especies difieren en su patrón de actividad diaria. 161 | 162 | # Consideraciones finales 163 | En esta nota apenas se han esbozado algunas de las aplicaciones básicas de la estadística circular a la Ecología, especialmente para el estudio fenológico de los patrones estacionales o de actividad diaria de diferentes organismos. Obviamente, hay muchas métricas y otros análisis, como las correlaciones circular-linear o circular-circular, que han quedado sin explicar por falta de espacio. Gracias a la funcionalidad de los paquetes de *R* especializados en estadística circular, estas métricas y análisis están fácilmente disponibles para el usuario interesado que quiera seguir avanzando. 164 | 165 | El código necesario para reproducir este documento se puede consultar en [GitHub][github_nota]. 166 | 167 | [sesgo_diagrama]: https://www.data-to-viz.com/caveat/circular_bar_yaxis.html 168 | [github_nota]: https://github.com/ecoinfAEET/Notas_Ecosistemas/tree/master/estadistica_circular 169 | 170 | # Agradecimientos 171 | 172 | Esta nota es un producto del proyecto TEMPNET, financiado con una beca Marie-Sklodowska Curie (798269 - TEMPNET - H2020-MSCA-IF-2017). 173 | 174 | 175 | 176 | ### REFERENCIAS 177 | 178 | ```{r write_citations, cache=FALSE, include=FALSE} 179 | write.bibtex(file = "knitcitations_estadistica_circular.bib") 180 | ``` 181 | 182 |
183 | 184 | 185 | ###### PIES DE FIGURA 186 | 187 | **Figura 1**. Diagramas de rosa representando la actividad diaria del agutí y el pecarí en la Isla de Barro Colorado. (Datos extraídos de Rowcliffe *et al.* 2014). 188 | 189 | **Figura 2**. Diagrama de rosa representando el número de especies con fruto en cada mes del año en la reserva de Nouragues (Guyana Francesa). Datos extraídos de Mendoza *et al.* 2018. 190 | 191 | ###### FIGURA 1 192 | 193 | ```{r Fig1, echo=FALSE, fig.cap="Figura 1.", cache=FALSE, fig.fullwidth = T} 194 | tiff(file = "Figura1.tiff", width = 4200, height = 3200, units = "px", res = 800, compression = 'lzw') 195 | aguti.circ <- circular::circular(aguti$time*24, units = "hours", template = "clock24") 196 | pecari.circ <- circular::circular(pecari$time*24, units = "hours", template = "clock24") 197 | #convertimos en radianes los valores temporales 198 | par(mfrow = c(1,2), mar = c(1,1,3,1)) 199 | circular::rose.diag(aguti.circ, main = "agutí", bins = 24, prop = 2, shrink = 0.95, cex = 0.9) 200 | circular::rose.diag(pecari.circ, main = "pecarí", bins = 24, prop = 2, shrink = 0.95, cex = 0.9) 201 | dev.off() 202 | ``` 203 | 204 | 205 | ###### FIGURA 2 206 | 207 | ```{r Fig2, echo=FALSE, fig.cap="Figura 2.", cache=FALSE} 208 | library(dplyr) 209 | library(ggplot2) 210 | tiff(file = "Figura2.tiff", width = 4200, height = 3200, units = "px", res = 800, compression = 'lzw') 211 | frutofrq2 <- frutofrq %>% mutate(meses2 = c("ene", "feb", "mar", "abr", "may", "jun", "jul", "ago", "sep", "oct", "nov", "dic")) 212 | ggplot(frutofrq2, aes(x = meses.ang, y = numspp)) + geom_bar(stat='identity') + coord_polar() + ylim(-7,35) + 213 | geom_text(aes(y = 35, label = meses2)) + xlab(label ="meses")+ ylab(label ="número de especies en fruto") + 214 | theme_bw() + 215 | theme(axis.text = element_text(size = 12, colour = "black"), 216 | axis.text.x = element_blank(), 217 | axis.title = element_text(size = 15, colour = "black")) 218 | 219 | dev.off() 220 | ``` 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | -------------------------------------------------------------------------------- /estadistica_circular/manuscript_estadistica_circular.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/estadistica_circular/manuscript_estadistica_circular.docx -------------------------------------------------------------------------------- /estadistica_circular/manuscript_estadistica_circular_enviado.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/estadistica_circular/manuscript_estadistica_circular_enviado.docx -------------------------------------------------------------------------------- /estadistica_circular/references_estadistica_circular.bib: -------------------------------------------------------------------------------- 1 | @Inbook{Morellato2010, 2 | author="Morellato, L. Patricia C. 3 | and Alberti, L.F. 4 | and Hudson, Irene L.", 5 | editor="Hudson, Irene L. 6 | and Keatley, Marie R.", 7 | title="Applications of Circular Statistics in Plant Phenology: a Case Studies Approach", 8 | bookTitle="Phenological Research: Methods for Environmental and Climate Change Analysis", 9 | year="2010", 10 | publisher="Springer Netherlands", 11 | address="Dordrecht", 12 | pages="339--359", 13 | abstract="Phenology is the study of recurring biological events and its relationship to climate. Circular statistics is an area of statistics not very much used by ecologists nor by other researchers from the biological sciences, and indeed not much visited, till recently in statistical science. Nevertheless, the connection between the evaluation of temporal, recurring events and the analysis of directional data have converged in several papers, and show circular statistics to be an outstanding tool by which to better understand plant phenology. The aim of this chapter is to assess applications for circular statistics in plant phenology and its potential for phenological data analysis in general. We do not discuss the mathematics of circular statistics, but discuss its actual and potential applications to plant phenology. We provide several examples at various levels of application: from generating circular phenological variables to the actual testing of hypotheses, say, for the existence of certain a priori seasonal patterns. Circular statistics has particular value and application when flowering onset (or fruiting) occurs almost continuously in an annual cycle and importantly in southern climates, where flowering time may not have a logical starting point, such as mid-winter dormancy. We conclude circular statistics applies well to phenological research where we want to test for relationships between flowering time and other phenological traits (e.g. shoot growth), or with functional traits such as plant height. It also allows us to group species into annual, supra-annual, irregular and continuous reproducers; to study seasonality in reproduction and growth; and to assess synchronization of species.", 14 | isbn="978-90-481-3335-2", 15 | doi="10.1007/978-90-481-3335-2_16", 16 | url="https://doi.org/10.1007/978-90-481-3335-2_16" 17 | } 18 | 19 | @book{Zar1999, 20 | author = {Jerrold H. Zar}, 21 | title = {Biostatistical Analysis}, 22 | publisher = {Prentice Hall}, 23 | year = 1999, 24 | address = {New Jersey}, 25 | edition = 4, 26 | note = {An optional note}, 27 | isbn = {0-13-081542-X} 28 | } 29 | 30 | @book{Batschelet1981, 31 | author = {Edward Batschelet}, 32 | title = {Circular Statistics in Biology}, 33 | publisher = {Academic Press}, 34 | year = 1981, 35 | address = {London}, 36 | edition = 1, 37 | note = {An optional note}, 38 | isbn = {0-12-081050-6} 39 | } 40 | 41 | @Article{Yan2011, 42 | title = {The Spread of Scientific Information: Insights from the Web Usage Statistics in PLoS Article-Level Metrics}, 43 | volume = {6}, 44 | issn = {1932-6203}, 45 | shorttitle = {The Spread of Scientific Information}, 46 | url = {http://dx.plos.org/10.1371/journal.pone.0019917}, 47 | doi = {10.1371/journal.pone.0019917}, 48 | number = {5}, 49 | urldate = {2013-12-10}, 50 | journal = {PLoS ONE}, 51 | author = {Koon-Kiu Yan and Mark Gerstein}, 52 | editor = {Alessandro Vespignani}, 53 | month = {may}, 54 | year = {2011}, 55 | pages = {e19917}, 56 | numeral = {1}, 57 | } 58 | 59 | @Article{Sutherland2011, 60 | title = {Quantifying the Impact and Relevance of Scientific Research}, 61 | volume = {6}, 62 | issn = {1932-6203}, 63 | url = {http://dx.plos.org/10.1371/journal.pone.0027537}, 64 | doi = {10.1371/journal.pone.0027537}, 65 | number = {11}, 66 | urldate = {2013-12-10}, 67 | journal = {PLoS ONE}, 68 | author = {William J. Sutherland and David Goulson and Simon G. Potts and Lynn V. Dicks}, 69 | editor = {Tammy Clifford}, 70 | month = {nov}, 71 | year = {2011}, 72 | pages = {e27537}, 73 | numeral = {1}, 74 | } 75 | 76 | @article{Mendoza2018, 77 | author = {Mendoza, Irene and Condit, Richard S. and Wright, S. Joseph and Caubère, Adeline and Châtelet, Patrick and Hardy, Isabelle and Forget, Pierre-Michel}, 78 | title = {Inter-annual variability of fruit timing and quantity at Nouragues (French Guiana): insights from hierarchical Bayesian analyses}, 79 | journal = {Biotropica}, 80 | 81 | volume = {50}, 82 | number = {3}, 83 | pages = {431-441}, 84 | keywords = {Amazon Basin, dispersal modes, frugivory, long-term monitoring, phenology, rain forest, seed production}, 85 | doi = {10.1111/btp.12560}, 86 | url = {https://onlinelibrary.wiley.com/doi/abs/10.1111/btp.12560}, 87 | eprint = {https://onlinelibrary.wiley.com/doi/pdf/10.1111/btp.12560}, 88 | year = {2018} 89 | } 90 | 91 | @article{Rowcliffe2014, 92 | author = {Rowcliffe, J. Marcus and Kays, Roland and Kranstauber, Bart and Carbone, Chris and Jansen, Patrick A.}, 93 | title = {Quantifying levels of animal activity using camera trap data}, 94 | journal = {Methods in Ecology and Evolution}, 95 | 96 | volume = {5}, 97 | number = {11}, 98 | pages = {1170-1179}, 99 | keywords = {activity level, activity time, circular kernel, proportion active, remote sensors, Von Mises distribution, weighted kernel}, 100 | doi = {10.1111/2041-210X.12278}, 101 | url = {https://besjournals.onlinelibrary.wiley.com/doi/abs/10.1111/2041-210X.12278}, 102 | eprint = {https://besjournals.onlinelibrary.wiley.com/doi/pdf/10.1111/2041-210X.12278}, 103 | abstract = {Summary Activity level (the proportion of time that animals spend active) is a behavioural and ecological metric that can provide an indicator of energetics, foraging effort and exposure to risk. However, activity level is poorly known for free-living animals because it is difficult to quantify activity in the field in a consistent, cost-effective and non-invasive way. This article presents a new method to estimate activity level with time-of-detection data from camera traps (or more generally any remote sensors), fitting a flexible circular distribution to these data to describe the underlying activity schedule, and calculating overall proportion of time active from this. Using simulations and a case study for a range of small- to medium-sized mammal species, we find that activity level can reliably be estimated using the new method. The method depends on the key assumption that all individuals in the sampled population are active at the peak of the daily activity cycle. We provide theoretical and empirical evidence suggesting that this assumption is likely to be met for many species, but may be less likely met in large predators, or in high-latitude winters. Further research is needed to establish stronger evidence on the validity of this assumption in specific cases; however, the approach has the potential to provide an effective, non-invasive alternative to existing methods for quantifying population activity levels.}, 104 | year = {2014} 105 | } 106 | 107 | @book{MardiaJupp2000, 108 | author = {Kanti V. Mardia and Peter E. Jupp}, 109 | title = {Directional Statistics}, 110 | publisher = {John Wiley & Sons}, 111 | year = 2000, 112 | address = {Chichester}, 113 | edition = 1, 114 | note = {An optional note}, 115 | isbn = {0-471-95333-4} 116 | } 117 | 118 | @article{Staggemeier2020, 119 | author = {Staggemeier, Vanessa Graziele and Camargo, Maria Gabriela Gutierrez and Diniz-Filho, Jose Alexandre Felizola and Freckleton, Robert and Jardim, Lucas and Morellato, Leonor Patricia Cerdeira}, 120 | title = {The circular nature of recurrent life cycle events: a test comparing tropical and temperate phenology}, 121 | journal = {Journal of Ecology}, 122 | volume = {108}, 123 | number = {2}, 124 | keywords = {circular statistics, climate seasonality, first flowering date, K-statistic, Mantel correlation, Pagel's lambda, phylogenetic eigenvector regression, phylogenetic signal}, 125 | doi = {10.1111/1365-2745.13266}, 126 | url = {https://besjournals.onlinelibrary.wiley.com/doi/abs/10.1111/1365-2745.13266}, 127 | eprint = {https://besjournals.onlinelibrary.wiley.com/doi/pdf/10.1111/1365-2745.13266}, 128 | year = {2020} 129 | } 130 | -------------------------------------------------------------------------------- /interpretacion-modelos-lineales/linear models & p-values.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/interpretacion-modelos-lineales/linear models & p-values.docx -------------------------------------------------------------------------------- /interpretacion-modelos-lineales/linear models & p-values_FRS.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/interpretacion-modelos-lineales/linear models & p-values_FRS.docx -------------------------------------------------------------------------------- /interpretacion-modelos-lineales/linear models & p-values_V2.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/interpretacion-modelos-lineales/linear models & p-values_V2.docx -------------------------------------------------------------------------------- /interpretacion-modelos-lineales/linear models & p-values_V2_FRS.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/interpretacion-modelos-lineales/linear models & p-values_V2_FRS.docx -------------------------------------------------------------------------------- /interpretacion-modelos-lineales/linear models & p-values_V3.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/interpretacion-modelos-lineales/linear models & p-values_V3.docx -------------------------------------------------------------------------------- /markup/Ecoinf.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Procesadores de texto Markup: más allá de MS Word \n" 3 | 4 | author: Hugo Saiz^1^ 5 | 6 | output: 7 | word_document: 8 | fig_caption: yes 9 | fig_height: 6 10 | fig_width: 7.5 11 | highlight: null 12 | reference_docx: Ecosistemas_template.docx 13 | 14 | csl: ecosistemas.csl 15 | bibliography: 16 | - references.bib 17 | --- 18 | 19 | 20 | > (1) Departmento de Biología y Geología, Física y Química Inorgánica, Escuela Superior de Ciencias Experimentales y Tecnología, Universidad Rey Juan Carlos. C/ Tulipán s/n, 28933 Móstoles, ESPAÑA 21 | 22 | > Autor para correspondencia: Hugo Saiz [saizhugo@gmail.com] 23 | 24 | 25 | # Palabras clave 26 | 27 | > Procesador de texto; Lenguaje Markdown; Lenguaje Text; RMarkdown 28 | 29 | 30 | # Keywords 31 | 32 | > Text processor; Markdown language; Text language; Rmarkdown 33 | 34 | 35 | Con la aparición del lenguaje de programación R los ecólogos hemos empezado a perder el miedo a los programas informáticos que sustituyen los clicks de ratón en menús y pestañas por el uso del teclado para escribir líneas de comando. El principal motivo de ello es que R proporciona unas ventajas que otros programas de análisis estadístico no tienen (p.ej. es gratuito y de código abierto, permite realizar casi cualquier análisis y reproducirlo en otro ordenador, se actualiza constantemente etc), por lo que el esfuerzo dedicado a aprender R es una inversión que en el futuro nos permitirá resolver nuestros problemas de manera más eficiente. En esta nota voy a presentaros alternativas basadas en comandos a los procesadores de texto tradicionales (p.ej. MS Word) y comentaré qué beneficios pueden suponer para realizar trabajos científicos. 36 | 37 | Los procesadores de texto por comandos se basan en una idea sencilla. Cuando escribimos un código informático, cada línea de código que escribimos le indica al programa la acción a realizar. Por ejemplo, cuando en R escribimos: 38 | 39 | ``` 40 | x<-mean(c(1,2,3)) 41 | ``` 42 | 43 | estamos indicando al programa que cree un objeto "x" que contenga la información "promedio de los número 1, 2 y 3". Al ejecutar esta línea obtenemos un objeto x con valor dos. 44 | 45 | Del mismo modo, en procesadores de texto basados en comandos podemos indicar mediante código qué formato queremos que tengan las palabras (p.ej. cursiva, negrita), los párrafos (p.ej. sangrados, separación entre párrafos) e incluso el documento entero (p.ej. numeración de páginas, interlineados). Por ejemplo, en Markdown (un lenguaje para escribir mediante comandos) cuando escribimos: 46 | 47 | ``` 48 | **Negrita** y *cursiva*` 49 | ``` 50 | 51 | el resultado es "**Negrita** y *cursiva*". 52 | 53 | Existen diferentes procesadores de texto basados en comandos, como [Latex](https://www.latex-project.org/) o los programas basados en lenguaje Markdown. Además, incluso R tiene un paquete específico ([Rmarkdown](http://rmarkdown.rstudio.com/)) que permite crear textos dentro de la propia consola de R y combinarlos fácilmente con otras salidas del programa. Así, es posible añadir las figuras y tablas en el texto directamente conforme las vamos creando en R. El poder combinar diferentes funciones como analizar datos y escribir textos dentro de un mismo programa supone varias ventajas, como por ejemplo permitir el intercambio de información entre usuarios sin tener que recurrir al envío de varios ficheros. Es por ello que en los últimos años varios usuarios han propuesto el uso generalizado en ciencia de estos programas sobre los procesadores de texto tradicionales. 54 | 55 | En general, los partidarios de los procesadores de texto basados en comandos presentan diferentes ventajas que harían de estas herramientas más deseables en investigación: 56 | 57 | 1. *Permiten incluir ecuaciones de manera más sencilla*. Existen disciplinas científicas como matemáticas y física donde el uso de ecuaciones en artículos científicos es común. Por ello, es necesario contar con un procesador de texto que permita escribir ecuaciones de forma rápida y simple. Si bien es cierto que MS Word ha mejorado mucho incluyendo pluggins como [MathType](http://www.dessci.com/en/products/mathtype/), los matemáticos y físicos prefieren utilizar procesadores de texto por comandos para escribir sus trabajos científicos (@brischoux2009don). 58 | 59 | 2. *Simplifican el cambio de formato*. Cuando se envía un trabajo científico a una revista, es habitual tener que enviar el texto con un formato particular (*sensu* bibliografía, numeración de páginas etc) que puede cambiar en función de la revista. Esto implica que cada vez que se envía un trabajo hay que invertir tiempo en comprobar que el trabajo se acomoda a dicho formato. Sin embargo, en los procesadores de texto por comandos el formato se define en líneas de código, que además pueden estar proporcionadas por las propias revistas (aunque no es común en ecología). De esta forma, simplemente habrá que cambiar estas líneas de código para tener el artículo con el nuevo formato que nos interese. 60 | 61 | 3. *No tienen problemas de compatibilidad y ocupan poco espacio*. Los textos generados por estos procesadores suelen estar en formatos de texto universales (p.ej. ".txt") que pueden ser abiertos por cualquier ordenador. De hecho, la mayoría de revistas científicas permiten enviar los trabajos en estos formatos de texto. Además, los archivos de texto ocupan menos espacio que los archivos de los procesadores tradicionales como los ".doc", por lo que también hacen que trabajar sobre el documento sea mucho más eficiente. 62 | 63 | 4. *Facilitan el intercambio de archivos y la reproducibilidad en la ciencia*. Al poder combinar dentro de un único archivo texto con otros componentes, como análisis estadísticos, cualquiera puede reproducir exactamente un trabajo científico al completo. De esta forma, al recibir un trabajo no sólo tendríamos acceso a la información escrita en el mismo sino que podríamos hacer los análisis, comprobar los datos etc. En resumen, tendríamos toda la información necesaria para repetir el trabajo. Además, si compartimos los archivos en repositorios como [GitHub](https://github.com/), el sistema permite llevar un registro de todos los cambios que se hagan sobre el documento, pudiendo identificar en todo momento cuándo y quién ha realizado qué modificación, y haciendo muy sencillo recuperar versiones anteriores del trabajo. 64 | 65 | 5. *Es software libre y gratuito*. Programas como MS Word requieren comprar licencias de usuario, que además no garantizan el acceso a nuevas versiones del producto. Sin embargo, los procesadores de texto por comando son gratuitos y al ser de código abierto, cualquiera puede modificarlos para el beneficio de (normalmente) todos los usuarios. 66 | 67 | Por supuesto, el uso de este tipo de procesadores no está exento de problemas. El principal de ellos es que requieren un proceso de aprendizaje mayor que los procesadores de texto tradicionales, lo cual puede resultar problemático para usuarios no acostumbrados al uso de comandos. Por ejemplo, un estudio de la universidad de Giessen (@knauff2014efficiency) encontró que los nuevos usuarios de MS Word escribían de foma más eficiente que los nuevos usuarios de Latex. Aunque el estudio mostró que Latex también presentaba algunas ventajas (p.ej. mayor eficiencia para escribir ecuaciones, menor cansancio), la respuesta general fue que trabajando en MS Word se escribía más rápido y con menos errores. Por ello, muchos usuarios de procesadores de texto tradicionales consideran que el esfuerzo necesario para aprender procesadores alternativos no compensa las posibles ventajas que éstos puedan tener. 68 | 69 | Cómo escribir un trabajo científico es una decisión personal que depende de cada autor. Mi objetivo no es convencer a nadie para que cambien MS Word por algún procesador de texto basado en comandos. Simplemente, es dar a conocer esta herramienta de trabajo tan común en otras disciplinas científicas. Al final, cada uno debe trabajar con el método en que se sienta más a gusto. Personalmente, al trabajar en equipo lo más eficiente es que todos los colaboradores trabajen usando las mismas herramientas. Sin embargo, nunca está de más aprender nuevas herramientas que puedan resultar necesarias para trabajos futuros. Por ejemplo, las cada vez más comunes colaboraciones entre físicos y ecólogos (@vermeulen2013understanding) pueden hacer necesario el conocimiento de este tipo de herramientas. De este modo, cuando nos llegue el momento de trabajar juntos podamos todos comunicarnos en el mismo idioma. 70 | 71 | En esta nota he tratado de presentaros un alternativa para escribrir textos científicos. Ahora ya depende de cada uno sumergirse en el mundo de los procesadores de texto por comandos. Existen muchos manuales abiertos y gratuitos (@oetiker1995introduccion,@baumer2014r) para comenzar a manejar este tipo de programas, y decidir qué método de trabajo nos parece el más adecuado. Sin embargo, no debemo olvidar que el objetivo de la ciencia es transmitir los descubrimientos para que todo el mundo pueda beneficiarse de ellos. Más importante que el "cómo", es el "qué" escribimos. Y este "qué" siempre debe ser lo más riguroso posible, ya escribamos en MS Word o en cualquier otro programa. 72 | 73 | ####Agradecimientos 74 | Gracias al grupo de ecoinformática de la AEET, especialmente a I. bartomeus, por su revisión de esta nota. Hugo Saiz cuenta con una beca Juan de la Cierva-Formación del MINECO. Esta nota ecoinformática está escrita en RMarkdown. El archivo donde se incluye todo el código para reproducir el texto está incluido como material suplementario (S1). 75 | 76 | ####Referencias 77 | 78 | -------------------------------------------------------------------------------- /markup/Ecoinf.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/markup/Ecoinf.docx -------------------------------------------------------------------------------- /markup/Ecoinf2.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/markup/Ecoinf2.docx -------------------------------------------------------------------------------- /markup/Ecoinf2_FRS.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/markup/Ecoinf2_FRS.docx -------------------------------------------------------------------------------- /markup/Ecosistemas_template.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/markup/Ecosistemas_template.docx -------------------------------------------------------------------------------- /markup/ecosistemas.csl: -------------------------------------------------------------------------------- 1 |  2 | -------------------------------------------------------------------------------- /markup/references.bib: -------------------------------------------------------------------------------- 1 | 2 | @article{knauff2014efficiency, 3 | title={An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development}, 4 | author={Knauff, Markus and Nejasmic, Jelica}, 5 | journal={PloS one}, 6 | volume={9}, 7 | number={12}, 8 | pages={e115069}, 9 | year={2014}, 10 | publisher={Public Library of Science} 11 | } 12 | 13 | @article{brischoux2009don, 14 | title={Don’t format manuscripts}, 15 | author={Brischoux, Fran{\c{c}}ois and Legagneux, Pierre}, 16 | journal={The Scientist}, 17 | volume={23}, 18 | number={7}, 19 | pages={24}, 20 | year={2009} 21 | } 22 | 23 | @article{vermeulen2013understanding, 24 | title={Understanding life together: A brief history of collaboration in biology}, 25 | author={Vermeulen, Niki and Parker, John N and Penders, Bart}, 26 | journal={Endeavour}, 27 | volume={37}, 28 | number={3}, 29 | pages={162--171}, 30 | year={2013}, 31 | publisher={Elsevier} 32 | } 33 | 34 | @article{oetiker1995introduccion, 35 | title={La introducci{\'o}n no-tan-corta a LATEX2$\varepsilon$}, 36 | author={Oetiker, Tobias and Partl, Hubert and Hyna, Irene and Schlegl, Elisabeth}, 37 | year={1995} 38 | } 39 | 40 | @article{baumer2014r, 41 | title={R Markdown: Integrating a reproducible analysis tool into introductory statistics}, 42 | author={Baumer, Ben and Cetinkaya-Rundel, Mine and Bray, Andrew and Loi, Linda and Horton, Nicholas J}, 43 | journal={arXiv preprint arXiv:1402.1894}, 44 | year={2014} 45 | } -------------------------------------------------------------------------------- /markup/~$Ecoinf.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/markup/~$Ecoinf.docx -------------------------------------------------------------------------------- /multimodel_inference/fig_1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/multimodel_inference/fig_1.pdf -------------------------------------------------------------------------------- /multimodel_inference/fig_1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/multimodel_inference/fig_1.pptx -------------------------------------------------------------------------------- /multimodel_inference/multimodel_inference.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/multimodel_inference/multimodel_inference.docx -------------------------------------------------------------------------------- /ropensci/Ecosistemas_template.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/ropensci/Ecosistemas_template.docx -------------------------------------------------------------------------------- /ropensci/ecosistemas.csl: -------------------------------------------------------------------------------- 1 | 2 | 186 | -------------------------------------------------------------------------------- /ropensci/knitcitations.bib: -------------------------------------------------------------------------------- 1 | @Article{Robertson_2016, 2 | doi = {10.1111/ecog.02118}, 3 | url = {https://doi.org/10.1111%2Fecog.02118}, 4 | year = {2016}, 5 | month = {feb}, 6 | publisher = {Wiley-Blackwell}, 7 | volume = {39}, 8 | number = {4}, 9 | pages = {394--401}, 10 | author = {Mark P. Robertson and Vernon Visser and Cang Hui}, 11 | title = {Biogeo: an R package for assessing and improving data quality of occurrence record datasets}, 12 | journal = {Ecography}, 13 | } 14 | 15 | @Article{Rodr_guez_Sanchez_2016, 16 | doi = {10.7818/ecos.2016.25-2.11}, 17 | url = {https://doi.org/10.7818%2Fecos.2016.25-2.11}, 18 | year = {2016}, 19 | month = {aug}, 20 | publisher = {Asociacion Espa{\~{n}}ola de Ecologia Terrestre ({AEET})}, 21 | volume = {25}, 22 | number = {2}, 23 | pages = {83--92}, 24 | author = {Francisco Rodr\'\iguez-Sanchez and Antonio Jes{\a'u}s P{\a'e}rez-Luque and Ignasi Bartomeus and Sara Varela}, 25 | title = {Ciencia reproducible: {\textquestiondown}qu{\'{e}}, por qu{\'{e}}, c{\'{o}}mo?}, 26 | journal = {Ecosistemas}, 27 | } 28 | 29 | @Article{Reichman_2011, 30 | doi = {10.1126/science.1197962}, 31 | url = {https://doi.org/10.1126%2Fscience.1197962}, 32 | year = {2011}, 33 | month = {feb}, 34 | publisher = {American Association for the Advancement of Science ({AAAS})}, 35 | volume = {331}, 36 | number = {6018}, 37 | pages = {703--705}, 38 | author = {O. J. Reichman and M. B. Jones and M. P. Schildhauer}, 39 | title = {Challenges and Opportunities of Open Data in Ecology}, 40 | journal = {Science}, 41 | } 42 | 43 | @Article{Hampton_2013, 44 | doi = {10.1890/120103}, 45 | url = {https://doi.org/10.1890%2F120103}, 46 | year = {2013}, 47 | month = {apr}, 48 | publisher = {Wiley-Blackwell}, 49 | volume = {11}, 50 | number = {3}, 51 | pages = {156--162}, 52 | author = {Stephanie E Hampton and Carly A Strasser and Joshua J Tewksbury and Wendy K Gram and Amber E Budden and Archer L Batcheller and Clifford S Duke and John H Porter}, 53 | title = {Big data and the future of ecology}, 54 | journal = {Frontiers in Ecology and the Environment}, 55 | } 56 | 57 | @Article{Michener_2012, 58 | doi = {10.1016/j.tree.2011.11.016}, 59 | url = {https://doi.org/10.1016%2Fj.tree.2011.11.016}, 60 | year = {2012}, 61 | month = {feb}, 62 | publisher = {Elsevier {BV}}, 63 | volume = {27}, 64 | number = {2}, 65 | pages = {85--93}, 66 | author = {William K. Michener and Matthew B. Jones}, 67 | title = {Ecoinformatics: supporting ecology as a data-intensive science}, 68 | journal = {Trends in Ecology {\&} Evolution}, 69 | } 70 | -------------------------------------------------------------------------------- /ropensci/ropensci.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "| rOpenSci: cómo acceder de forma reproducible a repositorios de datos públicos \n" 3 | 4 | author: Ignasi Bartomeus^1^ 5 | 6 | output: 7 | word_document: 8 | fig_caption: yes 9 | fig_height: 6 10 | fig_width: 7.5 11 | highlight: null 12 | reference_docx: Ecosistemas_template.docx 13 | 14 | csl: ecosistemas.csl 15 | bibliography: 16 | - knitcitations.bib 17 | --- 18 | 19 | 20 | > (1) Departmento de Ecología Integrativa, Estación Biológica de Doñana, Consejo Superior de Investigaciones Científicas, Avda. Américo Vespucio 26, 41092 Sevilla, España. 21 | 22 | > Autor para correspondencia: Ignasi Bartomeus [nacho.bartomeus@gmail.com] 23 | 24 | 25 | ```{r knitcitations, echo=FALSE, cache = FALSE} 26 | library(knitcitations) 27 | cleanbib() 28 | cite_options(citation_format = "pandoc") 29 | ``` 30 | 31 | El uso de datos públicos ha abierto la puerta a responder un abanico de preguntas que antes era inimaginable `r citep(list("10.1126/science.1197962", "10.1016/j.tree.2011.11.016", "10.1890/120103"))`. En ecología hay repositorios de datos de ocurrencia de especies (www.gbif.com), climáticos (www.worldclim.com) o filogenéticos (www.treebase.com) que por sí solos o combinados permiten realizar análisis para testar teorías generales a una escala global. Sin embargo, obtener estos datos suele hacerse de forma no reproducible mediante el uso de interfaces web. Estas interfaces son útiles para explorar los datos y además permiten seleccionar qué tipo de datos quieres y descargarlos a tu ordenador, pero este proceso es subóptimo por dos razones. Primero, una vez tienes los datos, es imposible recordar qué selección hiciste exactamente (no hay trazabilidad `r citep("10.7818/ECOS.2016.25-2.11")`). Segundo, cuando hay nuevos datos disponibles o se han corregido errores en los datos originales del repositorio es imposible actualizar los datos que descargaste de forma automática. 32 | 33 | El equipo de rOpenSci (https://ropensci.org), entre otras cosas, se dedica a crear paquetes de R que permiten el acceso a datos públicos desde tu terminal de R. Esto te permite tener un código legible tanto por máquinas como por humanos que especifica exactamente qué datos has descargado (hay una trazabilidad completa). Asimismo, actualizar los datos con los últimos cambios no requiere más esfuerzo que volver a correr el código. Las ventajas no están solo en incrementar la reproducibilidad de tus resultados, sino que sobre todo, el acceso a los datos directamente desde R te permite ahorrar tiempo y reducir el número de pasos de tu flujo de trabajo, y por consiguiente el número de potenciales errores de bulto que se pueden cometer en cada paso. 34 | 35 | Un ejemplo de cómo usar estos paquetes es bajar datos de tu especie favorita de gbif usando el paquete `rgbif`. Vamos a verlo en tres simples pasos que apenas ocupan cuatro líneas de código en R. 36 | 37 | 1) Instalar y cargar el paquete. 38 | 39 | ```{r results='hide', echo = TRUE, message=FALSE, warning=FALSE} 40 | #install.packages("rgbif") #solo has de instalarlo la primera vez 41 | library(rgbif) 42 | ``` 43 | 44 | 2) Obtener los datos que queremos. 45 | ```{r} 46 | dat <- occ_search(scientificName = "Andrena flavipes", limit = 10000) 47 | ``` 48 | 49 | 50 | 3) Mostrar gráficamente los datos obtenidos (Fig. 1). 51 | 52 | ```{r eval=FALSE} 53 | library(mapr) 54 | map_ggmap(dat, zoom = 4) 55 | ``` 56 | 57 | En este ejemplo tan simple nos limitamos a representar datos gráficamente, pero se pueden hacer análisis más interesantes combinando datos de varias fuentes (e.j. https://ropensci.org/usecases/). Como advertencia, hay que tener en cuenta que este tipo de datos abiertos pueden contener información erronea que deberá ser depurada antes correr los análisis `r citep("10.1111/ecog.02118")`. El paquete `scrubr`, en desarrollo, ayuda a realizar esta necesaria limpieza inicial para este tipo de datos (https://github.com/ropensci/scrubr). 58 | 59 | La lista de paquetes disponibles para acceder a datos crece año a año (https://ropensci.org/packages/#data_access) y los paquetes se actualizan con regularidad solucionando errores o introduciendo mejoras. Por tanto, si encuentras algún fallo lo mejor que puedes hacer es comentárselo a sus autores. 60 | 61 | Si estás interesado en el uso de datos libres y quieres hacerlo de forma programática, rOpenSci es un buen inicio, pero hay otros paquetes para R disponibles en CRAN, y para los que no usan R a veces existen clientes específicos para otros lenguajes (e.j. python). Solo es cuestión de saber buscar la herramienta que necesitas. 62 | 63 | # Agradecimientos 64 | 65 | Han contribuido a su revisión: Carlos Lara, Ana Isabel García-Cervigón, Antonio Jesús Pérez Luque y Francisco Rodríguez-Sánchez. 66 | 67 | 68 | ###### Referencias 69 | 70 | ```{r write_citations, cache=FALSE, include=FALSE} 71 | write.bibtex(file = "knitcitations.bib") 72 | ``` 73 | 74 |
75 | 76 | 77 | 78 | ###### Pies de figura 79 | 80 | **Figura 1**. Mapa de localidades de *Andrena flavipes* disponibles en GBIF, obtenido directamente desde R. 81 | 82 | 83 | 84 | ###### Figura 1 85 | 86 | ```{r Fig1, echo=FALSE, fig.cap="Figura 1. Mapa de localidades de *Andrena flavipes* disponibles en GBIF, obtenido directamente desde R.", cache=FALSE, message=FALSE, warning=FALSE} 87 | library(mapr) 88 | map_ggmap(dat, zoom = 4) 89 | ``` 90 | -------------------------------------------------------------------------------- /ropensci/ropensci.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/ropensci/ropensci.docx -------------------------------------------------------------------------------- /template/.gitignore: -------------------------------------------------------------------------------- 1 | knitcitations.bib 2 | plantilla_NotaEcoinf.docx 3 | -------------------------------------------------------------------------------- /template/Ecosistemas_template.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ecoinfAEET/Notas_Ecosistemas/d1fc942ced841fc917a7df04a311c1e11dcde863/template/Ecosistemas_template.docx -------------------------------------------------------------------------------- /template/ecosistemas.csl: -------------------------------------------------------------------------------- 1 | 2 | 186 | -------------------------------------------------------------------------------- /template/plantilla_NotaEcoinf.Rmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Nota ecoinformática sobre..." 3 | 4 | author: Nombre Apellidos^1^, Nombre Apellidos^2^ 5 | 6 | output: 7 | word_document: 8 | fig_caption: yes 9 | fig_height: 6 10 | fig_width: 7.5 11 | highlight: null 12 | reference_docx: Ecosistemas_template.docx 13 | 14 | csl: ecosistemas.csl 15 | 16 | bibliography: 17 | - references.bib 18 | - knitcitations.bib 19 | --- 20 | 21 | > (1) Institución 1 22 | 23 | > (2) Institución 2 24 | 25 | > Autor de correspondencia\*: Nombre Apellidos [[author\@gmail.com](mailto:author@gmail.com){.email}] 26 | 27 | # Palabras clave 28 | 29 | > palabraclave1; palabraclave2; palabraclave3; palabraclave4 30 | 31 | # Keywords 32 | 33 | > keyword1; keyword2; keyword3; keyword4 34 | 35 | ```{r knitcitations, echo = FALSE, cache = FALSE, warning = FALSE, message = FALSE} 36 | library(rmarkdown) 37 | library(knitcitations) 38 | library(lme4) 39 | cleanbib() 40 | options("citation_format" = "pandoc") 41 | ``` 42 | 43 | Esta es una plantilla para escribir [Notas Ecoinformáticas](https://ecoinfaeet.github.io/notas-ecoinformaticas.html) en formato Rmarkdown para la revista [Ecosistemas](https://www.revistaecosistemas.net/index.php/ecosistemas). Para saber más sobre Rmarkdown, visite . Para ver un ejemplo de Nota Ecoinformática escrita íntegramente en Rmarkdown, visite . 44 | 45 | Hay varias formas de citar bibliografía (véase ). Una de ellas requiere simplemente adjuntar un fichero BibTex con todas las referencias (en este ejemplo `references.bib`), y citar cada una de ellas usando su 'CitationKey' [e.g. @Yan2011; @Sutherland2011]. También pueden buscarse referencias en internet, citar utilizando el DOI, o conectarse a una bibliografía de Zotero (ver ). 46 | 47 | ## Cómo incluir ejemplos 48 | 49 | ```{r read_data, eval = FALSE, echo = FALSE} 50 | dataset <- read.csv("mydata.csv") 51 | ``` 52 | 53 | Ajustamos un modelo lineal: 54 | 55 | $$ 56 | y_{i} = \alpha + \beta*x_{i} 57 | $$ 58 | 59 | ```{r model, echo = FALSE, eval = FALSE} 60 | model <- lm(y ~ x) 61 | ``` 62 | 63 | Utilizamos R `r citep(citation())` y Rmarkdown `r citep(citation("rmarkdown"))` para todos nuestros análisis. Para ajustar los modelos mixtos utilizamos `lme4` `r citep(citation("lme4"))`. 64 | 65 | # Resultados 66 | 67 | Esta sección está dividida en subsecciones. 68 | 69 | ## Subsección 1 70 | 71 | Los árboles de la parcela A fueron más altos que en la parcela B (altura media: `r mean(25, 31, 28)` vs `r mean(13, 19, 16)` m). Y muchos más resultados que se actualizan dinámicamente. 72 | 73 | ## Subsección 2 74 | 75 | Texto. 76 | 77 | ## Subsección 3 78 | 79 | Texto. 80 | 81 | # Discusión 82 | 83 | Texto. 84 | 85 | # Conclusiones 86 | 87 | Texto. 88 | 89 | # Contribución de los autores 90 | 91 | Texto. 92 | 93 | # Agradecimientos 94 | 95 | Esta nota se ha revisado siguiendo un proceso colaborativo y público disponible en (link al issue correspondiente). 96 | 97 | # Referencias 98 | 99 | ```{r write_citations, cache = FALSE, include = FALSE} 100 | write.bibtex(file = "knitcitations.bib") 101 | ``` 102 | 103 | ::: {#refs} 104 | ::: 105 | 106 | ###### TABLA 1 107 | 108 | **Tabla 1**. Cada tabla debe tener su correspondiente encabezamiento explicativo. En los artículos de investigación, de revisión y comunicaciones breves se aportarán los encabezamientos tanto en castellano como en inglés, en letra Arial 10 y en una página independiente. Es importante que las tablas sean simples y que no superen el ancho una página DIN A4 vertical. Los originales se deben aportar en formato tabla y no en formato imagen. 109 | 110 | **Table 1**. Table heading in English. 111 | 112 | ```{r Tabla1, results = 'asis', echo = FALSE, cache = FALSE, warning = FALSE} 113 | library(knitr) 114 | kable(head(iris)) 115 | ``` 116 | 117 | ###### PIES DE FIGURA 118 | 119 | **Figura 1**. Pie de figura 1. 120 | 121 | **Figura 2**. Pie de figura 2. 122 | 123 | ###### FIGURE LEGENDS 124 | 125 | **Figure 1**. Figure caption. 126 | 127 | **Figure 2**. Figure caption. 128 | 129 | ###### FIGURA 1 130 | 131 | ```{r Fig1, echo = FALSE, fig.cap = "Figura 1. Esto es un ejemplo.", cache = FALSE} 132 | x <- rnorm(100) 133 | y <- jitter(x, 1000) 134 | plot(x, y) 135 | ``` 136 | 137 | ###### FIGURA 2 138 | 139 | ```{r Fig2, echo = FALSE, fig.cap = "Figura 2. Segundo ejemplo", cache = FALSE} 140 | a <- sort(rnorm(100)) 141 | b <- c(rep("Group Small", 35), rep("Group Big", 65)) 142 | boxplot(a ~ b) 143 | ``` 144 | -------------------------------------------------------------------------------- /template/plantilla_NotaEcoinf.qmd: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Nota ecoinformática sobre..." 3 | 4 | author: Nombre Apellidos^1^, Nombre Apellidos^2^ 5 | 6 | format: 7 | docx: 8 | fig-height: 6 9 | fig-width: 7.5 10 | reference-doc: Ecosistemas_template.docx 11 | 12 | csl: ecosistemas.csl 13 | 14 | bibliography: 15 | - references.bib 16 | - knitcitations.bib 17 | --- 18 | 19 | > (1) Institución 1 20 | 21 | > (2) Institución 2 22 | 23 | > Autor de correspondencia\*: Nombre Apellidos \[[author\@gmail.com](mailto:author@gmail.com){.email}\] 24 | 25 | # Palabras clave 26 | 27 | > palabraclave1; palabraclave2; palabraclave3; palabraclave4 28 | 29 | # Keywords 30 | 31 | > keyword1; keyword2; keyword3; keyword4 32 | 33 | ```{r knitcitations} 34 | #| echo: false 35 | #| cache: false 36 | #| warning: false 37 | library(quarto) 38 | library(knitcitations) 39 | library(lme4) 40 | cleanbib() 41 | cite_options(citation_format = "pandoc") 42 | ``` 43 | 44 | Esta es una plantilla para escribir [Notas Ecoinformáticas](https://ecoinfaeet.github.io/notas-ecoinformaticas.html) en formato Quarto para la revista [Ecosistemas](https://www.revistaecosistemas.net/index.php/ecosistemas). Para saber más sobre Quarto, visite . La diferencia principal de Quarto respecto a Rmarkdown es que se ha generado para la colaboración de más de una comunidad (es decir, no solo usuarios de R o Python) y utiliza una sintaxis y formato compartido entre distintos lenguajes. 45 | 46 | Hay varias formas de citar bibliografía (véase ). Una de ellas requiere simplemente adjuntar un fichero BibTex con todas las referencias (en este ejemplo `references.bib`), y citar cada una de ellas usando su 'CitationKey' [e.g. @Yan2011; @Sutherland2011]. También pueden buscarse referencias en internet, citar utilizando el DOI o conectarse a una bibliografía de Zotero (ver ). 47 | 48 | ## Cómo incluir ejemplos 49 | 50 | ```{r read_data} 51 | #| eval: false 52 | #| echo: false 53 | dataset <- read.csv("mydata.csv") 54 | ``` 55 | 56 | Ajustamos un modelo lineal: 57 | 58 | $$ 59 | y_{i} = \alpha + \beta*x_{i} 60 | $$ 61 | 62 | ```{r model} 63 | #| echo: false 64 | #| eval: false 65 | model <- lm(y ~ x) 66 | ``` 67 | 68 | Utilizamos R `r citep(citation())` y Quarto `r citep(citation("quarto"))` para todos nuestros análisis. Para ajustar los modelos mixtos utilizamos `lme4` `r citep(citation("lme4"))`. 69 | 70 | # Resultados 71 | 72 | Esta sección está dividida en subsecciones. 73 | 74 | ## Subsección 1 75 | 76 | Los árboles de la parcela A fueron más altos que en la parcela B (altura media: `r mean(25, 31, 28)` vs `r mean(13, 19, 16)` m). Y muchos más resultados que se actualizan dinámicamente. 77 | 78 | ## Subsección 2 79 | 80 | Texto. 81 | 82 | ## Subsección 3 83 | 84 | Texto. 85 | 86 | # Discusión 87 | 88 | Texto. 89 | 90 | # Conclusiones 91 | 92 | Texto. 93 | 94 | # Contribución de los autores 95 | 96 | Texto. 97 | 98 | # Agradecimientos 99 | 100 | Esta nota se ha revisado siguiendo un proceso colaborativo y público disponible en (link al issue correspondiente). 101 | 102 | # Referencias 103 | 104 | ```{r write_citations} 105 | #| cache: false 106 | #| include: false 107 | write.bibtex(file = "knitcitations.bib") 108 | ``` 109 | 110 | ::: {#refs} 111 | ::: 112 | 113 | ###### TABLA 1 114 | 115 | **Tabla 1**. Cada tabla debe tener su correspondiente encabezamiento explicativo. En los artículos de investigación, de revisión y comunicaciones breves se aportarán los encabezamientos tanto en castellano como en inglés, en letra Arial 10 y en una página independiente. Es importante que las tablas sean simples y que no superen el ancho una página DIN A4 vertical. Los originales se deben aportar en formato tabla y no en formato imagen. 116 | 117 | **Table 1**. Table heading in English. 118 | 119 | ```{r Tabla1} 120 | #| output: asis 121 | #| echo: false 122 | #| cache: false 123 | #| warning: false 124 | library(knitr) 125 | kable(head(iris)) 126 | ``` 127 | 128 | ###### PIES DE FIGURA 129 | 130 | **Figura 1**. Pie de figura 1. 131 | 132 | **Figura 2**. Pie de figura 2. 133 | 134 | ###### FIGURE LEGENDS 135 | 136 | **Figure 1**. Figure caption. 137 | 138 | **Figure 2**. Figure caption. 139 | 140 | ###### FIGURA 1 141 | 142 | ```{r Fig1} 143 | #| echo: false 144 | #| fig-cap: "Figura 1. Esto es un ejemplo." 145 | #| cache: false 146 | x <- rnorm(100) 147 | y <- jitter(x, 1000) 148 | plot(x, y) 149 | ``` 150 | 151 | ###### FIGURA 2 152 | 153 | ```{r Fig2} 154 | #| echo: false 155 | #| fig-cap: "Figura 2. Segundo ejemplo" 156 | #| cache: false 157 | a <- sort(rnorm(100)) 158 | b <- c(rep("Group Small", 35), rep("Group Big", 65)) 159 | boxplot(a ~ b) 160 | ``` 161 | -------------------------------------------------------------------------------- /template/references.bib: -------------------------------------------------------------------------------- 1 | 2 | @Article{Yan2011, 3 | title = {The Spread of Scientific Information: Insights from the Web Usage Statistics in PLoS Article-Level Metrics}, 4 | volume = {6}, 5 | issn = {1932-6203}, 6 | shorttitle = {The Spread of Scientific Information}, 7 | url = {http://dx.plos.org/10.1371/journal.pone.0019917}, 8 | doi = {10.1371/journal.pone.0019917}, 9 | number = {5}, 10 | urldate = {2013-12-10}, 11 | journal = {PLoS ONE}, 12 | author = {Koon-Kiu Yan and Mark Gerstein}, 13 | editor = {Alessandro Vespignani}, 14 | month = {may}, 15 | year = {2011}, 16 | pages = {e19917}, 17 | numeral = {1}, 18 | } 19 | 20 | @Article{Sutherland2011, 21 | title = {Quantifying the Impact and Relevance of Scientific Research}, 22 | volume = {6}, 23 | issn = {1932-6203}, 24 | url = {http://dx.plos.org/10.1371/journal.pone.0027537}, 25 | doi = {10.1371/journal.pone.0027537}, 26 | number = {11}, 27 | urldate = {2013-12-10}, 28 | journal = {PLoS ONE}, 29 | author = {William J. Sutherland and David Goulson and Simon G. Potts and Lynn V. Dicks}, 30 | editor = {Tammy Clifford}, 31 | month = {nov}, 32 | year = {2011}, 33 | pages = {e27537}, 34 | numeral = {1}, 35 | } 36 | --------------------------------------------------------------------------------