Attending the R Forwards Women's Package Workshop (Hosted by R-Ladies Chicago)

This weekend, I had the pleasure of attending an R Forwards Women's Package Workshop. It was hosted and run by members of R-Ladies Chicago: Angela Li and Stephanie Kirmer.

Though I have attended and run many one or two hour workshops, this was my first long-day, single-topic workshop (9:30 to 4:00 pm) and I thoroughly enjoyed the experience! It’s definitely a format that would be useful to teach more complex topics, like software development and package building. There was a lot of info-in-brain-cramming, but I also felt like I learned a ton in a very short time span.

Attendees of the 2019 R Forward Package Workshop, taught by Angela and Stephanie of R Ladies Chicago!

Attendees of the 2019 R Forward Package Workshop, taught by Angela and Stephanie of R Ladies Chicago!

The session was broken down into a couple broad topics: package development, git+r, unit testing, documentation, and package sharing (e.g., licences, indicating dependencies, CRAN). This made the material useful for both specific-use packages (e.g., building a data wrangling package for my specific research group) and for more public-facing packages (e.g., a package that one would want to upload to CRAN).

Top 5 Things I Learned:

  1. The usethis package is so convenient and important for package development. For example, the function

    usethis::create_package("~/Desktop/mypackage")

    will create the skeleton of the package files for you, including folders for R-code, the “man” folder (“man” stands for manual), and description/namespace files. This makes package building so much earlier! You can learn more about it in Wickham’s R package book.

  2. Using the “::” operator allows you to see the exported variables or functions in a package namespace. But if you really want to see under the hood “:::” allows you to see everything (there’s some more about it on StackOverflow), including the functions that are not publicly exported.

  3. Semantic Versioning - How have I only learned about this now, despite attending several data carpentry workshops and classes?! I am such a stickler for version recording, even in my non-computational work (I have been subconsciously semantic versioning my human content analysis codebooks), and it’s so nice to finally have a specific phrase associated with this process.

  4. A quote from my favorite slide of the day: “If the first line of your #rstats script is

    setwd("C:\Users\jenny\path\that\only\I\have")

    I will come into your lab and SET YOUR COMPUTER ON FIRE 🔥.”

    Confession time: I do this a lot! 🙈 ::embarrassed:: In terms of workflow, I am generally quite sloppy about separating projects and keeping relative paths. I first read about projects in R for Data Science, but I never took the lesson to heart until this weekend. I know… it’s bad given how much I code. So I guess I’ll be “konmari-ing” my R code this semester(i.e., create an Rproject space for each of my projects)!

  5. A great tip from Stephanie’s top tweet (about Git): “when you screw up a git merge, you can use git reset --hard master@{"300 minutes ago"} with any time quantity you want in there to get back to where things were a period of time ago.“

Extra Bonus: Differencing vs. Logging Time Series Data

I happened to also sit next to economist Dweepobotee Brahma, which was a great coincidence since I’ve been binging time series models and papers for the past year. I happened to randomly gripe about how economic data is often processed (i.e., logged). She was kind enough to explain to me why economists did this, and why growth rates are so important to the research in economics and econometrics. Having been taught by a political scientist, whose questions are not as focused on exponential relationships, I didn’t know much about this alternative treatment/perspective on time series data, and it was really interesting!

I’m starting to wonder if this is especially important to modeling follower growth. Nearly all follower count time series I’ve analyzed have been fully integrated I(1), if not to I(2). Often I will first- or second- difference this as a way to make the series stationary. However, I’m realizing a logarithmic transformation is probably more appropriate for what we try to measure (implicitly, it’s a growth rate question).

Conclusion

Overall, I’m really, really glad that I was able to attend this workshop. It’s definitely up there on my “favorite R workshops ever” list. Organizationally, there were a lot of little things I wanted to take back to my workshop strategy (for example, this was the first workshop I attended where we used post it’s to indicate whether we needed help with specific tasks) and obviously it was great for advancing my R skills.

One of the most important “big picture” lessons I learned was that if I want to actually do software development in R (or any programming language), I have to be more organized about my code. I am organized when it comes to data management, but am definitely less-so with my scripts and functions. Workflow wise, I want to get on top of this by the end of the semester.

I’m also one step closer to completing a major R-new-year’s-resolution: Build an R package! I have a couple of functions that I rely on for data wrangling operationalized text data to time series data, so I’m eager to wrap them all up in a neat little package for future use.

And finally, attending the workshop was a great reminder about how amazing the R community is, both offline and online. That’s one of my favorite parts about being an R programmer—the community makes it easy to be excited about learning R.

I am so grateful to Angela and Stephanie for hosting this amazing workshop, and to R Forwards for sponsoring my attendance. If you are interested in checking out the materials from this weekend, they have made the workshop material available here.