Stephen Royle

I like to set up a standardised directory structure for RStudio
projects. The idea came from
[here](https://martinctc.github.io/blog/rstudio-projects-and-working-directories-a-beginner's-guide/).
In brief, the structure is:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
Data/
Output/Data/
Output/Plots/
Script/
```
:::

My typical workflow is therefore to:

- select File \> New Project in RStudio
- make a new directory and RProj file
- then use this [R script or these shell
  commands](https://gist.github.com/quantixed/42625f988a7b5da25b7e333c4a660b97)
  to setup the directories.

So far, so good. However, this process is a bit tedious.

I find it irritating to open up RStudio (which opens up a previous
project by default) and then go through these steps. Recently, I had to
make several R projects for a paper and I thought there must be a
quicker way. Here's my solution.

## The quick way: shell function {#the-quick-way-shell-function .wp-block-heading}

I made a shell function to set up an R Project with the correct
directory tree. The resulting `.Rproj` file can just be double-clicked
and you are good to go!

I previously wrote about [shell aliases and
functions](https://quantixed.org/2023/01/10/over-and-over-quick-ways-to-reuse-handy-shell-one-liners/){data-type="post"
data-id="2966"}. I am using zsh on macOS, but this should all work on
bash and possibly shells.

As described before, I had to initialise a file for zsh functions.

In the home directory (`~`), open `.zshrc` with your favourite editor
e.g.

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .bash; .title: .; .notranslate title=""}
nano .zshrc
```
:::

Then add the following to the file:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
# Alias definitions
if [ -f ~/.zsh_functions ]; then
    . ~/.zsh_functions
fi
```
:::

Now make and edit `zsh_functions`

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .bash; .title: .; .notranslate title=""}
nano .zsh_functions
```
:::

Now add the function:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
function setup_rproj() {
    if [[ $# -eq 0 ]] ; then
        echo 'Name of new directory required'
        return 0
    fi

    # setup preferred directory structure
    mkdir "$1"
    mkdir "$1"/Data;\
    mkdir "$1"/Output;\
    mkdir "$1"/Output/Data;\
    mkdir "$1"/Output/Plots;\
    mkdir "$1"/Script

    /bin/cat <<EOM >"$1"/"$1".Rproj
Version: 1.0

RestoreWorkspace: Default
SaveWorkspace: Default
AlwaysSaveHistory: Default

EnableCodeIndexing: Yes
UseSpacesForTab: Yes 
NumSpacesForTab: 2
Encoding: UTF-8

RnwWeave: Sweave
LaTeX: pdfLaTeX
EOM

    # end of function here
}
```
:::

And save by ctrl + x and y.

## How it works {#how-it-works .wp-block-heading}

The idea is that the user navigates to where they want to make the R
Project, i.e. `cd` to the location. Then call the function like this:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
setup_rproj analysis123
```
:::

The script will make a folder in the current directory called
analysis123, in there it will place the directory structure described
above, and then make the `.Rproj` file.

If you use a different `.Rproj` file the function needs to be edited
accordingly. Finally, if the user calls `setup_rproj` without specifying
a project name, the function will return an error message.

If the directory already exists, nothing will be overwritten.

---

Part of an occasional series of tech tips.


I like to set up a standardised directory structure for RStudio projects. The idea came from here. In brief, the structure is: Data/ Output/Data/ Output/Plots/ Script/  My typical workflow is therefore to: select File &gt; New Project in RStudio make a new directory and RProj file then use this R script or these shell commands to setup the directories. So far, so good. However, this process is a bit tedious.

Tips From The Blog XIX: initialising a new RStudio project

I recently made my [first R
package](https://quantixed.org/2022/09/05/tracking-announcing-new-r-package-trackmater/){data-type="post"
data-id="2806"} and was asked how I did it. The answer of course was: I
searched, read, and stumbled around until it was done. But having gone
through the process I figured it was worthwhile summarising what I did
and what I found tricky.

First off, there are a ton of resources out there that describe how to
go about building a package. Here are a few that I found useful:

- Hilary Parker's short guide --
  <https://hilaryparker.com/2014/04/29/writing-an-r-package-from-scratch/>
- Karl Broman's guide to building packages --
  <https://kbroman.org/pkg_primer/>
- The official guide --
  <https://cran.r-project.org/doc/manuals/r-release/R-exts.html>
- Using pkgdown --
  <https://martinctc.github.io/blog/make-package-even-more-awesome/>

## Why build a package? {#why-build-a-package .wp-block-heading}

If you are using R and you have developed some scripts and useful
functions, you might be wondering why build a package? There are quite a
few reasons. One is to make the functions available to use for other
projects. Another is to force yourself to document these functions in a
more rigorous way. In my case I needed to build an installable package
so that students taking a class I teach could easily install my code and
run a practical session.

One way to think of a package as a robust set of scripts that are well
documented. In fact, a package is probably best built out of a bunch of
scripts that are already working and ready to be "packaged" up for
release. Once you have some working code, the best approach is to use
RStudio to make the package.

## Very quick summary {#very-quick-summary .wp-block-heading}

Two libraries are required for making a package.

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .r; .title: .; .notranslate title=""}
install.packages("devtools")
install.packages("roxygen2")
```
:::

In RStudio, open **File** and select **New Project** and pick the option
for **R Package**. Now name your project and pick where it will be
saved.

RStudio will now initialise the project with a structure that will work
as a package. Briefly, besides the `.Rproj` file for the RStudio
project, you should see a folder called `R` (this is where all your `.R`
files containing your package functions should go). You should also see
a `NAMESPACE` file and a `DESCRIPTION` file. In the `DESCRIPTION` file
you can store information about your project. The `NAMESPACE` file is
auto-generated by `roxygen` and should not be edited by hand.

Once you have added your scripts into the `R` directory, you can get
`roxygen` to format the documentation. Please refer to the links above
for more information, but essentially a `.R` file might have one
function and that function comes after several lines of roxygen
comments. These are lines that start with `#'`

In **Project Options** in RStudio you can select **Build Tools** and
check the box for Create Documentation. This means that `roxygen` will
read the comments in all the `.R` files in `R/` and generate `.rd` (R
Documentation) files for each. It is also possible to build a PDF manual
for your package, in a way that looks exactly like those you will have
probably encountered for other packages on CRAN.

*That was a very quick summary of how to make the core parts of a
package. Here are a few things I ran into and how I solved them.*

## Putting the package onto GitHub {#putting-the-package-onto-github .wp-block-heading}

I did this part the wrong way around. Next time, I will develop the
package on GitHub in a private repo from the start. Instead this time, I
got a very basic working version going locally (without version control)
and then uploaded the project as a GitHub repo (outside of RStudio).
This allowed me to distribute a bare-bones version of the package to the
class using `devtools::install_github()`

When it came to adding more features to the package and developing it
further, I then cloned the repo and used that version for further
development.

## pkgdown {#pkgdown .wp-block-heading}

I used `pkgdown` to make a GitHub pages documentation website. This was
ridiculously simple to do and again, the links above helped a lot.

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .r; .title: .; .notranslate title=""}
library(pkgdown)
usethis::use_pkgdown()
pkgdown::build_site()
usethis::use_pkgdown_github_pages()
```
:::

The repo can be configured such that whenever a commit is pushed to the
remote, GitHub actions are triggered which does an `R CMD check` and
rebuilds your documentation website.

<figure class="wp-block-image size-full">
<img
src="https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?resize=640%2C189&amp;ssl=1"
class="wp-image-2803" loading="lazy" decoding="async"
data-attachment-id="2803"
data-permalink="https://quantixed.org/2022/09/06/the-package-learning-how-to-build-an-r-package/fbbvpokwaaanpiy/"
data-orig-file="https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?fit=914%2C270&amp;ssl=1"
data-orig-size="914,270" data-comments-opened="1"
data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}"
data-image-title="FbBVPOKWAAAnPiY" data-image-description=""
data-image-caption=""
data-medium-file="https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?fit=300%2C89&amp;ssl=1"
data-large-file="https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?fit=640%2C189&amp;ssl=1"
srcset="https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?w=914&amp;ssl=1 914w, https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?resize=300%2C89&amp;ssl=1 300w, https://i0.wp.com/quantixed.org/wp-content/uploads/2022/09/FbBVPOKWAAAnPiY.jpeg?resize=768%2C227&amp;ssl=1 768w"
sizes="(max-width: 640px) 100vw, 640px" data-recalc-dims="1" width="640"
height="189" />
<figcaption>will it, won’t it…. waiting to compile</figcaption>
</figure>

One worry I had was whether it is possible to have multiple github.io
sites (it is) or whether I should host the documentation at a custom
url. In the end, using GitHub pages was so simple, that I don't know why
I worried about this step at all.

## R CMD check {#r-cmd-check .wp-block-heading}

Before pushing some changes, it is a good idea to do `R CMD check` in
RStudio first and then fix any problems before pushing. This is
especially true if your package is already in a public repo (which mine
was) and someone could potentially install it in a broken state. In the
Build tab, and click Check to trigger `R CMD check`. This carries out
the check that your package can be installed and be run on someone
else's computer. It checks that all the code examples in your `roxygen`
comments will run too.

A tip here: make those code examples as simple as possible. In my case,
the package reads in a large file and does a lot of number crunching.
This meant I had to wait a few minutes for each check. Simplifying this
step would have saved me a lot of time. The checking stage can be halted
if there is a warning or note that you want to fix, rather than waiting
for the whole thing to complete (or crash).

I would recommend: developing the code in your cloned repo. Click
**Install** in the **Build** tab and then run your test code. When it
works correctly, add it as a function to the repo and commit/push. This
was certainly easier than the way I initially worked which was to have a
separate RStudio project where I installed the GitHub version of the
package and then developed code in that project before moving it to the
"real package". I thought this would be preferable and would keep the
"real code" clean, but it quickly got very annoying.

A common error I got during `R CMD check` was:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
no visible binding for global variable [variable name]
```
:::

This error usually meant that I used a variable name (usually a column
name in a data frame) without definition. This is not usually a problem
when you are working with objects in the global environment and just
running a script. However, in the context of a package, R needs to know
what you mean by \[variable name\]. There are many solutions to this,
but the simplest I found was:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .r; .title: .; .notranslate title=""}
id <- displacement <- time <- NULL
```
:::

added to the first line of the function. Where `id` `displacement` and
`time` were all variables without binding. There is disagreement over
the best way to handle this situation, but this solution was intuitive
for me -- and it worked.

## importFrom {#importfrom .wp-block-heading}

You will almost certainly use functions from other libraries and not
just base R. This means you need to import the whole library or *import*
a function *from* a library. It is possible to add these as roxygen
comments in the functions that need them, however, this can get out of
control if you have lots of functions. Instead use a file called
`myPackage-package.R` (where myPackage is the name of your package).
This file sits in `R/` and looks something like this:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
#' @importFrom utils write.csv
#' @importFrom XML xmlParse
#' @importFrom XML xmlDoc
#' @importFrom XML xpathApply
#' @importFrom zoo rollmean
#' @import ggplot2
#' @import dplyr
#' @import patchwork
NULL
#> NULL
```
:::

This way you can keep track of what has been loaded. I also collated the
libraries and documented them in `DESCRIPTION` although I admit that I
do not fully understand what is required here and what is best practice.

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .plain; .title: .; .notranslate title=""}
Imports:
  doParallel,
  dplyr,
  foreach,
  ggplot2,
  ggforce,
  patchwork,
  reshape2,
  utils,
  XML,
  zoo
Suggests:
  knitr,
  rmarkdown
```
:::

Logically, it is best to keep the number of dependencies as low as
possible. This is in case some future change in those libraries breaks
you code. However, with popular/established/well-developed libraries you
should be fairly safe.

## Organising functions {#organising-functions .wp-block-heading}

This is slightly heading into code style territory, but I found that in
general: one function per `.R` file was a good rule to follow. However,
it is possible to have more than one function in a file. I decided to
collate miscellaneous functions in one file and all general plotting
functions in another, but apart from that each `.R` file contained one
*main* function.

Some of these main functions had supporting functions which are only
used by the main function. If you are used to programming in other
languages, these supporting functions I am describing are similar to
STATIC functions. How to handle these? Firstly, they should not get the
`#' @export` roxygen comment, otherwise they will be made generally
available and you probably don't want this. However, even without this
tag they will still get documented and could therefore clog up the
Reference section built by `pkgdown`. So, the solution I found was to
add `#' @keywords internal` to the comments, and this hid the function
from the documentation whilst still being available for use in
internally in my package.

## How do I make some example data available? {#how-do-i-make-some-example-data-available .wp-block-heading}

The purpose of my package was to read in some data and then process it.
Therefore I needed to make some data available so that people can try
out the package, but also so the checks work on GitHub etc. When working
locally, the roxygen examples can point to a file on your hard drive,
but this will obviously fail when the code is run on a remote server.

I struggled for an answer to this one. Most packages either do not
require test data or they use `mtcars` or one of the other built-in
datasets. Other solutions talk about using an `.rda` file (an R object)
rather than raw data.

As far as I could tell the "correct" solution is to put an example file
in `inst/extdata/` Now bear in mind that this file will be installed
onto the user's computer so it shouldn't have sensitive info and
importantly, should not be huge. `R CMD check` will give a warning about
the size of the file anyhow. This file can then be accessed in your code
(or by the user) by:

::: {.wp-block-syntaxhighlighter-code}
``` {.brush: .r; .title: .; .notranslate title=""}
system.file("extdata", "nameOfFile.ext", package="myPackage")
```
:::

I toyed with the idea of making data available at some other location,
but this is really the only way that a user can install your package and
then be offline and work with your example file.

In case you are wondering, if the data is an R object e.g. `.rda` file,
the convention is to place it in `data/` rather than `inst/extdata/`

## Conclusion {#conclusion .wp-block-heading}

I tried to give an overview of roadblocks that I had to overcome to make
my first R package. I'm sure there may be better approaches out there to
tackle some of these things. I learnt a lot by going through this
process, hopefully some of you will find this info useful too.

---

The post title comes from "The Package" a track on Castor's [eponymous
1995 album](https://www.discogs.com/release/2665873-Castor-Castor).


I recently made my first R package and was asked how I did it. The answer of course was: I searched, read, and stumbled around until it was done. But having gone through the process I figured it was worthwhile summarising what I did and what I found tricky. First off, there are a ton of resources out there that describe how to go about building a package.

The Package: learning how to build an R package

rOpenSci

Stefanie Butland

Maëlle Salmon

After soliciting, reviewing, and publishing over 100 blog posts and tech notes by rOpenSci community members, we have created the rOpenSci Blog Guide for Authors and Editors to address many frequently asked questions and frequently given suggestions. Technically, we structured the content as a bookdown gitbook.

10 Things We Learned in Creating the Blog Guide with bookdown

Jorge Saturno

*Leaflet* es una biblioteca de Javascript para hacer mapas y existe un
paquete homónimo para que permite usar todo el potencial de *leaflet* en
nuestros mapas y hacerlos interactivos y aptos para móviles.

Para crear un mapa en blanco se usa la función `leaflet`. La función
`addTiles()` agrega "tiles" de OpenStreetMap.

::: {#cb1 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
library(leaflet)

m0 <- leaflet() %>%
  addTiles() %>%
  setView(lng=-75, lat=-12 , zoom=4) # Centrar el mapa en Suramérica

m0 # Visualizar el mapa
```
:::

::: {#arreglar-el-zoom-out-icon-namesearch-minus-packfas .section .level2}
## Arreglar el "zoom-out" {#arreglar-el-zoom-out .anchored anchor-id="arreglar-el-zoom-out-icon-namesearch-minus-packfas"}

Uno de los problemas que más pueden fastidiar al crear un mapa de
*leaflet* es que al hacer *zoom-out* se pueden llegar a ver "varios"
planetas Tierra, lo cual no tiene mucho sentido. Esto se puede arreglar
definiendo límites al hacer *zoom-out* y *zoom-in*. Se pueden cambiar
las opciones de la función `leaflet`. Un ejemplo es el siguiente:

::: {#cb2 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
library(leaflet)

m0 <- leaflet(options = leafletOptions(minZoom = 3, maxZoom = 8)) %>%
  addTiles() %>%
  setView(lng=-75, lat=-12 , zoom=4) # Centrar el mapa en Suramérica

m0
```
:::

En este caso, iniciamos con un zoom a nivel 4, definido en `setView`, y
sólo permitimos bajar un nivel más (3) y llegar a un máximo de 8. Estos
límites serán mejor definidos al crear y visualizar el mapa y dependerán
de la aplicación que se le quiera dar. Para dejar el mapa en un zoom
fijo y no permitir *zoom-out* ni *zoom-in*, se pueden fijar `minZoom` y
`maxZoom` al mismo nivel.
:::

::: {#cambiar-el-estilo-del-mapa-icon-namebrush-packfas .section .level2}
## Cambiar el estilo del mapa {#cambiar-el-estilo-del-mapa .anchored anchor-id="cambiar-el-estilo-del-mapa-icon-namebrush-packfas"}

Además de las capas de OpenStreetMap usadas por defecto en *leaflet*,
existen muchas otras disponibles. Una lista de diferentes estilos/capas
se puede encontrar
[aquí](http://leaflet-extras.github.io/leaflet-providers/preview/index.html).
Uno de mis temas favoritos es *Positron* de
[**CartoDB**](https://github.com/CartoDB/basemap-styles). Este mapa se
puede cargar de la siguiente manera:

::: {#cb3 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
m0_positron <- leaflet(options = leafletOptions(minZoom = 3, maxZoom = 8)) %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  setView(lng=-75, lat=-12 , zoom=4)

m0_positron
```
:::

También se puede cargar sin las etiquetas usando
`addProviderTiles(providers$CartoDB.PositronNoLabels)`.

**CartoDB** también provee un tema oscuro que puede ser usado de igual
forma con o sin etiquetas:
`addProviderTiles(providers$CartoDB.DarkMatter)` o
`addProviderTiles(providers$CartoDB.DarkMatterNoLabels)`,
respectivamente.

Acá una visualización del tema oscuro sin etiquetas:
:::

::: {#agregar-datos-al-mapa-icon-namedatabase-packfas .section .level2}
## Agregar datos al mapa {#agregar-datos-al-mapa .anchored anchor-id="agregar-datos-al-mapa-icon-namedatabase-packfas"}

Para este ejemplo vamos a agregar datos del paquete
[`{coronavirus}`](https://github.com/RamiKrispin/coronavirus). Más
detalles sobre el uso de estos datos se pueden conseguir en esta \[otra
entrada\](). Para cargar estos datos hacemos lo siguiente:

::: {#cb4 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
## Cargar datos

# Para instalar el paquete {coronavirus}:
# devtools::install_github("RamiKrispin/coronavirus")

require(coronavirus)

datacov <- coronavirus %>%
  # Seleccionar datos de interés
  select(country = Country.Region, type, cases, Lat, Long) %>%
  # Agrupar por país
  group_by(country, Lat, Long, type) %>%
  # Totalizar los casos
  summarise(total_cases = sum(cases)) %>%
  # Crear columnas para cada tipo de caso
  pivot_wider(names_from = type, values_from = total_cases) %>%
  # Ordenar por número de casos confirmados
  arrange(-confirmed) %>%
  ungroup()

# Cambios los nombres a español
datacov <- datacov %>%
  mutate(country = ifelse(country == "Peru", "Perú", country)) %>%
  mutate(country = ifelse(country == "Dominican Republic", "República Dominicana", country)) %>%
  mutate(country = ifelse(country == "Brazil", "Brasil", country)) %>%
  mutate(country = ifelse(country == "Haiti", "Haití", country)) %>%
  mutate(country = ifelse(country == "Panama", "Panamá", country)) %>%
  mutate(country = ifelse(country == "Mexico", "México", country))
```
:::

Usando la función `addCircleMarkers()`, se puede graficar la variable
*confirmed* (número de casos confirmados) sobre el mapa, usando el
logaritmo del número de casos para definir el radio de los círculos
graficados. Latitud y longitud están incluidos en los datos en las
variables `Long` y `Lat`. Usando el parámetro `popup` se puede crear una
caja de información con datos a ser mostrados al hace click en cada
círculo. En este caso se agrega el nombre del país y número de casos
confirmados y fallecidos.

::: {#cb5 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
m1 <- leaflet(datacov, options = leafletOptions(minZoom = 3, maxZoom = 8)) %>%
  addProviderTiles(providers$CartoDB.PositronNoLabels) %>%
  addCircleMarkers(
    lng = ~Long,
    lat = ~Lat,
    weight = 3,
    radius = ~log(confirmed)*3, # Adaptar según se desee
    color = "#ff7761",
    stroke = FALSE, fillOpacity = 0.9,
    popup = paste(datacov$country, "<br>",
                  "<b>Casos confirmados: </b>", datacov$confirmed, "<br>",
                  "<b>Fallecidos: </b>", datacov$death)
  ) %>%
setView(lng=-75, lat=-12 , zoom=4)

m1
```
:::

En el siguiente ejemplo se incluye una nueva capa con el número de
fallecidos, la cual estará debajo de la de número de casos confirmados
para garantizar que el área cliqueable siga activa en el círculo más
grande.

::: {#cb6 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
m2 <- leaflet(datacov, options = leafletOptions(minZoom = 3, maxZoom = 8)) %>%
  addProviderTiles(providers$CartoDB.PositronNoLabels) %>%
  addCircleMarkers(
    lng = ~Long,
    lat = ~Lat,
    weight = 3,
    radius = ~log(death),
    color = "#881600",
    stroke = FALSE, fillOpacity = 0.9,
  ) %>%
  addCircleMarkers(
    lng = ~Long,
    lat = ~Lat,
    weight = 3,
    radius = ~log(confirmed)*3,
    color = "#ff7761",
    stroke = FALSE, fillOpacity = 0.7,
    popup = paste(datacov$country, "<br>",
                  "<b>Casos confirmados: </b>", datacov$confirmed, "<br>",
                  "<b>Fallecidos: </b>", datacov$death)
  ) %>%
  setView(lng=-75, lat=-12 , zoom=4)

m2
```
:::
:::

::: {#mostrar-etiquetas-al-desplazar-el-cursor-icon-namemouse-pointer-packfas .section .level2}
## Mostrar etiquetas al desplazar el cursor {#mostrar-etiquetas-al-desplazar-el-cursor .anchored anchor-id="mostrar-etiquetas-al-desplazar-el-cursor-icon-namemouse-pointer-packfas"}

Para mostrar información al desplazar el cursor sobre los círculos, se
puede usar el argumento `label` dentro de la función
`addCircleMarkers()`. Una etiqueta con información del país y la
cantidad de casos confirmados se agrega usando el siguiente parámetro:

::: {#cb7 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
label = paste0(as.character(datacov$country)," | Casos confirmados: ", as.character(datacov$confirmed)),
```
:::

::: {#personalizar-las-etiquetas .section .level3}
### Personalizar las etiquetas {#personalizar-las-etiquetas .anchored anchor-id="personalizar-las-etiquetas"}

Estas etiquetas pueden ser personalizadas usando el argumento
`labelOptions`. En el siguiente mapa se agregan las etiquetas anteriores
y se hacen algunos cambios a los colores y la tipografía de las mismas:

::: {#cb8 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
m3 <- leaflet(datacov, options = leafletOptions(minZoom = 3, maxZoom = 8)) %>%
  addTiles() %>%
  addProviderTiles(providers$CartoDB.PositronNoLabels) %>%
  addCircleMarkers(
    lng = ~Long,
    lat = ~Lat,
    weight = 3,
    radius = ~log(death),
    color = "#881600",
    stroke = FALSE, fillOpacity = 0.9,
  ) %>%
  addCircleMarkers(
    lng = ~Long,
    lat = ~Lat,
    weight = 3,
    radius = ~log(confirmed)*3,
    color = "#ff7761",
    stroke = FALSE, fillOpacity = 0.7,
    popup = paste(datacov$country, "<br>",
                  "<b>Casos confirmados: </b>", datacov$confirmed, "<br>",
                  "<b>Fallecidos: </b>", datacov$death),
    label = paste0(as.character(datacov$country)," | Casos confirmados: ", as.character(datacov$confirmed)),
    labelOptions = labelOptions(style = list(
                                "color" = "#FFFFF3",
                                "font-family" = "Roboto",
                                "font-weight" = "bold",
                                "box-shadow" = "3px 3px rgba(0,0,0,0.25)",
                                "font-size" = "16px",
                                "background-color" = "#566270",
                                "border-color" = "rgba(0,0,0,0.5)"))
  ) %>%
  setView(lng=-75, lat=-12 , zoom=4)

m3
```
:::
:::

::: {#personalizar-las-cajas-popup .section .level3}
### Personalizar las cajas *popup* {#personalizar-las-cajas-popup .anchored anchor-id="personalizar-las-cajas-popup"}

La información mostrada en las cajas *popup* que aparecen al hacer click
también puede ser personalizada. Sin embargo, el paquete `{leaflet}` es
bastante limitado en este aspecto. Una forma de modificar el estilo a
gusto es usando la función `browsable()` del paquete `{htmltools}`. Un
ejemplo usando el mapa generado anteriormente es el siguiente:

::: {#cb9 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
browsable(
  tagList(list(
    tags$head(
      tags$style(
        ".leaflet-popup-content-wrapper {
        background: black;
        color: #ffffff;
        font-size: 15px;
        padding: 2px;
        border-radius: 0px;
        }"
      )
    ),
    m3
  ))
)
```
:::
:::
:::

::: {#guardar-y-publicar-el-mapa-icon-namesave-packfas .section .level2}
## Guardar y publicar el mapa {#guardar-y-publicar-el-mapa .anchored anchor-id="guardar-y-publicar-el-mapa-icon-namesave-packfas"}

El resultado se puede guardar como un archivo html usando el paquete
`{htmlwidgets}`.

::: {#cb10 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .r .code-with-copy}
library(htmlwidgets)
saveWidget(m3, "~/leaflet_m3.html")
```
:::

Este archivo html se puede subir e incrustar en un sitio web usando el
siguiente código:

::: {#cb11 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .html .code-with-copy}
<iframe src="leaflet_m0.html" frameborder="0" width="100%" height="600px"></iframe>
```
:::

::: {#publicar-en-un-sitio-web-hugo .section .level3}
### Publicar en un sitio web Hugo {#publicar-en-un-sitio-web-hugo .anchored anchor-id="publicar-en-un-sitio-web-hugo"}

Para publicar en un sitio estático de hugo se puede agregar un nuevo
*shortcode* en `/layouts/partials/shortcodes`. Esto se hace creando un
nuevo archivo en ese directorio, al cual, en este caso, llamaremos
`hp5.html`. El contenido de dicho archivo sería el siguiente:

::: {#cb12 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .html .code-with-copy}
<iframe src="{{.Get 0}}" width="100%" height="{{.Get 1}}" frameborder="0" allowfullscreen="allowfullscreen" allow="geolocation *; microphone *; camera *; midi *; encrypted-media *"></iframe>
```
:::

Aquí se define la forma en que se mostrará el mapa. En este caso, con un
ancho de "100%" y una altura variable en píxeles. El *shortcode* hp5,
tal como está definido, requerirá dos parámetros: 1. localización del
archivo y 2. altura (*height*) del mapa a ser mostrado.

Una vez definido el *shortcode*, podemos usarlo en cualquier publicación
de hugo para mostrar el mapa creado y mostrarlo con un altura de `"600"`
píxeles. Como se muestra en este ejemplo:

::: {#cb13 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .markdown .code-with-copy}
{{< hp5 "/leaflet/leaflet_m0.html" "600">}}
```
:::

¡Feliz mapeo!
:::
:::

::: {#quarto-appendix .default}
::: {.section .quarto-appendix-contents}
## Cómo citar {#cómo-citar .anchored .quarto-appendix-heading}

<div>

::: {.quarto-appendix-secondary-label}
BibTeX
:::

``` {.sourceCode .code-with-copy .quarto-appendix-bibtex}
@online{saturno2019,
  author = {Saturno, Jorge},
  title = {Mapas con \{leaflet\} en R},
  date = {2019-04-25},
  url = {https://kumulonimb.us/apuntes/leaflet},
  langid = {es}
}
```

::: {.quarto-appendix-secondary-label}
Por favor, cita este trabajo como:
:::

::: {#ref-saturno2019 .csl-entry .quarto-appendix-citeas}
Saturno, Jorge. 2019. "Mapas con {leaflet} en R." April 25, 2019.
<https://kumulonimb.us/apuntes/leaflet>.
:::

</div>
:::
:::


<em>
 Leaflet
</em>
es una biblioteca de Javascript para hacer mapas y existe un paquete homónimo para que permite usar todo el potencial de
<em>
 leaflet
</em>
en nuestros mapas y hacerlos interactivos y aptos para móviles. Para crear un mapa en blanco se usa la función leaflet. La función addTiles() agrega “tiles” de OpenStreetMap.

Mapas con {leaflet} en R

[RStudio](https://www.rstudio.com/) es el entorno de desarrollo para R
más popular hoy en día. Su instalación en Manjaro (y otras
distribuciones basadas en Arch Linux) es muy sencilla pero requiere usar
el repositorio mantenidos por los usuarios, conocido como Arch User
Repository (AUR). Usualmente, se usaba *yaourt* para instalar paquetes
del AUR pero dado que este fue descontinuado, tendremos que instalar
*yay*, uno de sus sustitutos.

::: {#instalar-yay .section .level2}
## Instalar *yay* {#instalar-yay .anchored anchor-id="instalar-yay"}

::: {#cb1 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .sh .code-with-copy}
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
```
:::
:::

::: {#instalar-rstudio-usando-yay .section .level2}
## Instalar RStudio usando *yay* {#instalar-rstudio-usando-yay .anchored anchor-id="instalar-rstudio-usando-yay"}

::: {#cb2 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .sh .code-with-copy}
yay -S rstudio-desktop-bin
```
:::
:::

::: {#instalación-de-openblas .section .level2}
## Instalación de OpenBLAS {#instalación-de-openblas .anchored anchor-id="instalación-de-openblas"}

Las librerías de BLAS instaladas por defecto en Manjaro no son las de
mejor rendimiento. Para incrementar el rendimiento, se recomienda
instalar [*OpenBLAS*](http://www.openblas.net/), el cual ofrece la
posibilidad de usar múltiples núcleos del CPU en vez de uno solo, como
normalmente ocurre. Para instalar OpenBLAS:

::: {#cb3 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .sh .code-with-copy}
yay -S openblas-lapack
```
:::

Durante el proceso de instalación tendrás que remover los paquetes
antiguos. Luego de culminada la instalación no es necesario configurar
nada. R estará usando los CPU disponibles.
:::

::: {#una-última-recomendación .section .level2}
## Una última recomendación {#una-última-recomendación .anchored anchor-id="una-última-recomendación"}

Muchos paquetes de R requerirán un compilador de Fortran. Luego de la
instalación es recomendable instalar gcc-fortran:

::: {#cb4 .sourceCode style="background: #f1f3f5;"}
``` {.sourceCode .sh .code-with-copy}
sudo pacman -S gcc-fortran
```
:::

::: {.callout .callout-style-default .callout-note .callout-titled}
::: {.callout-header .d-flex .align-content-center}
::: {.callout-icon-container}
:::

::: {.callout-title-container .flex-fill}
Nota
:::
:::

::: {.callout-body-container .callout-body}
Si usas Windows, puedes instalar RStudio siguiendo este
[tutorial](https://www.youtube.com/watch?v=IyJuTU82ikM).
:::
:::
:::

::: {#quarto-appendix .default}
::: {.section .quarto-appendix-contents}
## Cómo citar {#cómo-citar .anchored .quarto-appendix-heading}

<div>

::: {.quarto-appendix-secondary-label}
BibTeX
:::

``` {.sourceCode .code-with-copy .quarto-appendix-bibtex}
@online{saturno2019,
  author = {Saturno, Jorge},
  title = {RStudio en Manjaro Linux},
  date = {2019-04-05},
  url = {https://kumulonimb.us/apuntes/RStudio},
  langid = {es}
}
```

::: {.quarto-appendix-secondary-label}
Por favor, cita este trabajo como:
:::

::: {#ref-saturno2019 .csl-entry .quarto-appendix-citeas}
Saturno, Jorge. 2019. "RStudio en Manjaro Linux." April 5, 2019.
<https://kumulonimb.us/apuntes/RStudio>.
:::

</div>
:::
:::


RStudio es el entorno de desarrollo para R más popular hoy en día. Su instalación en Manjaro (y otras distribuciones basadas en Arch Linux) es muy sencilla pero requiere usar el repositorio mantenidos por los usuarios, conocido como Arch User Repository (AUR). Usualmente, se usaba
<em>
 yaourt
</em>
para instalar paquetes del AUR pero dado que este fue descontinuado, tendremos que instalar
<em>
 yay
</em>
, uno de sus sustitutos.

Rogue Scholar Posts

Tips From The Blog XIX: initialising a new RStudio project

The Package: learning how to build an R package

10 Things We Learned in Creating the Blog Guide with bookdown

Mapas con {leaflet} en R

RStudio en Manjaro Linux