Maëlle's R blog

Showcase of my (mostly R) work/fun

The current introduction to my package development workshops

I somewhat regularly teach about package development. One recent example was a workshop for rOpenSci champions. I am improving my teaching over time (thankfully 😅) but one thing I have down by now is the intro, which is mostly my throwing together my favorite quotes about R package development! Let me write it up. Where I explain why people shouldn’t flee the workshop After boasting a bit (a.k.a. sharing my package development creds to introduce myself), I answer three retorical questions:

Useful functions for dealing with object names

My sticky note filled up quickly after I only added setNames() on it, with related functions for dealing with object names, in base R and beyond! (Un)Setting object names: stats::setNames(), unname() and rlang::set_names() I noticed a function ending with something like this: blop <- function() { # code creating the df data.frame # ... names(df) <- c("col1", "col2") df } It struck me as simplifiable by:

Reading notes on Git in Practice by Mike McQuaid

While preparing materials for teaching Git a few months ago, I re-read Suzan Baert’s excellent post about Git and GitHub, where she mentioned having read “Git in Practice” by Mike McQuaid. I added the book to my Momox alerts, where it got available a few weeks later. The book source is on GitHub. The book isn’t too heavy, so I took it with me on a long train journey! 🚋

3 (actually 4) neat R functions

Time for me to throw away my sticky note after sharing what I wrote on it! grep(...) not which(grepl(...)) Recently I caught myself using which(grepl(...)), animals <- c("cat", "bird", "dog", "fish") which(grepl("i", animals)) #> [1] 2 4 when the simpler alternative is animals <- c("cat", "bird", "dog", "fish") grep("i", animals) #> [1] 2 4 And should I need the values instead of the indices, I know I shouldn’t write

Reading notes on A Philosophy of Software Design by John Ousterhout

When I see a book recommendation somewhere, be it for work or leisure, I often either order the book or set an alert in my favorite online second-hand bookstore. By the time I am notified the book is available, I sometimes don’t remember why I listed it! That’s what happened for the book A Philosophy of Software Design by John Ousterhout. I decided to trust my past self and buy it.