Maëlle's R blog

Showcase of my (mostly R) work/fun

Where to get help with your R question?

Last time I blogged, I offered my obnoxious helpful advice for blog content and promotion. Today, let me again be the agony aunt you didn’t even write to! Imagine you have an R question, i.e. a question related to how you can do something with R, and your search engine efforts haven’t been too successful: where should you ask it to increase your chance of its getting answered? You could see this post as my future answer to stray suboptimal Twitter R questions, or as a more general version of Scott Chamberlain’s excellent talk about how to get help related to rOpenSci software in the 2017-03-07 rOpenSci comm call.

I think that the general journey to getting answers to your R questions is first trying your best to get answers locally in the documentation of R, then to use a search engine, and then to post a well-formulated question somewhere. My post is aimed at helping you find that somewhere. Note that it’s considered best practice to ask in one somewhere at once, and to then move on to another somewhere if you haven’t got any answer… or if someone kindly redirects you to a better venue!

Get on your soapbox! R blog content and promotion

This year I had the chance to speak at two R-Ladies meetups (I might have invited myself to those meetups to make the most of being in town, create your own happiness!), one in Cape Town in March, one in Seattle in May. It was a blast both times! I gave the same talk twice, and decided it was about time to write it up.

My talk in March was aimed at pairing, well tripleting, with Marie Dussault’s talk about setting up your blogdown website, and Stephanie Kovalchik’s talk about sports blogging so it is not about these topics. What it is is my non data-driven, quite personal view on blog content and promotion, which hopefully features some useful tips for any wannabe R blogger!

Lintr Bot, lintr's Hester egg

Remember my blog post about automatic tools for improving R packages? One of these tools is Jim Hester’s lintr, a package that performs static code analysis. In my experience it mostly helps identifying too long code lines and missing space, although it’s a bit more involved than that. In any case, lintr helps you maintain good code style, and as mentioned in that now old post of mine, you can add a lintr unit test to your package which will ensure you don’t get lazy over time.

Now say your package has a lintr unit test and lives on GitHub. What happens if someone makes a pull request and writes looong code lines? Continuous integration builds will fail but not only that… The contributor will get to know Lintr Bot, lintr’s Hester (Easter) egg!