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!
On Saturday I was at my second satRday conference this year, lucky me! I got to attend satRday Cardiff which was a great experience. I gave a talk about rOpenSci onboarding system of packages, find my slidedeck here and other slidedecks at this address. A lot of R goodness!
As I did in March for satRday Cape Town, I’ll use my own tweets to summarize the event, but this time, having switched my website to blogdown I can use Hugo shortcodes as recommended by Romain François!
It’s nearly been two years since I defended my PhD thesis! On top of allowing me to call myself doctor, having a PhD in statistics gives me the honour to feature in the data of the Mathematics Genealogy Project. Today, I decided to webscrape my mathematical ancestors.
I couldn’t miss the fun Twitter hashtag #BadStockPhotosOfMyJob thanks to a tweet by Julia Silge and another one by Colin Fay. The latter inspired me to actually go and look for what makes a data science photo… What characterizes “data science” stock photos?
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!