- Eurostat, World Bank and others: https://ikashnitsky.github.io/2017/data-acquisition-two/
- Star Wars data: in dplyr, http://dplyr.tidyverse.org/reference/starwars.html
- Baby names data: babynames package, https://cran.r-project.org/web/packages/babynames/index.html
- Movies data: https://cran.r-project.org/web/packages/ggplot2movies/index.html ggplot2movies package
- Game of Thrones screen time: https://github.com/Preetish/GoT_screen_time
- Open Bike Data: https://github.com/ropensci/bikedata
- Tons of data through 538: https://cran.r-project.org/web/packages/fivethirtyeight/vignettes/fivethirtyeight.html
- Public health data England: fingertipsR, https://cran.r-project.org/web/packages/fingertipsR/
- Financial data via Quandl: https://www.quandl.com/tools/r
- Cyclones: https://github.com/ropensci/rrricanesdat
# Install | |
# via http://askubuntu.com/questions/510056/how-to-install-google-chrome | |
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add - | |
sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list' | |
sudo apt-get update | |
sudo apt-get install google-chrome-stable | |
# Update |
This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.
A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:
- It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
- It is free, with no quotas.
- Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.
--- | |
title: "Get verbatim R chunks in R Markdown" | |
author: "Jenny Bryan" | |
date: "18 September, 2014" | |
output: | |
html_document: | |
keep_md: TRUE | |
--- | |
My periodic revisitation of "how can I include a verbatim R chunk in `.rmd`"? This time I am writing it down! Various proposed solutions: |
stratifiedDT <- function(indt, group, size, select = NULL, | |
replace = FALSE, keep.rownames = FALSE, | |
bothSets = FALSE) { | |
if (is.numeric(group)) group <- names(indt)[group] | |
if (!is.data.table(indt)) indt <- as.data.table( | |
indt, keep.rownames = keep.rownames) | |
if (is.null(select)) { | |
indt <- indt | |
} else { | |
if (is.null(names(select))) stop("'select' must be a named list") |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
stratified <- function(df, group, size, select = NULL, | |
replace = FALSE, bothSets = FALSE) { | |
if (is.null(select)) { | |
df <- df | |
} else { | |
if (is.null(names(select))) stop("'select' must be a named list") | |
if (!all(names(select) %in% names(df))) | |
stop("Please verify your 'select' argument") | |
temp <- sapply(names(select), | |
function(x) df[[x]] %in% select[[x]]) |