R on Jon Calder

Naming things is hard

Mon, 04 Dec 2017 00:00:00 +0000

‘There are only two hard things in Computer Science: cache invalidation and naming things.’

The above quip by Phil Karlton is fairly well known and often quoted, sometimes with amusing extensions:

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
— Jeff Atwood (@codinghorror) August 31, 2014

There are only 2 hard things in computer science:
0. Cache invalidation
1. Naming things
7. Asynchronous callbacks
2. Off-by-one errors
— Paweł Zajączkowski (@gvaireth) September 18, 2017

These are funny, but they do also convey some truth: in the midst of all the technicalities and abstractions we can find ourselves caught up with in the world of programming, it’s surprising how often seemingly ‘simple’ things like naming things trip us up.

I was recently reminded of this when a difference of opinions about function names sparked some healthy debate in a pull request I was reviewing for one of my personal projects.

So the question I want to raise is this:

“When (if ever) is it a good idea to adopt a prefixing convention for the names of exported functions in an R package?”

Disclaimers

Before I dive into the details I feel it is important to state a few things upfront.

Firstly, I want to thank my friends and collaborators Katrin and Lorenz who are strong proponents of open source software and for whom I have a lot of respect. On this occasion they both seem to disagree with me, but that is not a bad thing - discussion and debate is valuable, and that’s not gonna happen when everyone agrees with each other all the time. I did also ask for their permission before publishing this post.

Secondly, my purpose in writing about this is less about trying to determine who is right, and more about attempting to convert this experience into insight. Often we learn more from our failures than from our successes, but it’s harder to share our mistakes than it is to share our triumphs. So this post is my way of being vulnerable about something that is a work in progress and the process of trying to improve on it. As an aside, if you haven’t encountered survivorship bias before, I highly recommend you read this.

Thirdly, I was wrong. This is especially important in light of the previous point. I was wrong to raise the issue of function names (for the package as a whole) in a pull request which was focused on something else. This is a valuable lesson. One should always aim to keep pull requests (and issues) narrow in scope because attempting to tackle multiple problems in one place (unless they are inherently linked or dependent on each other) is messy and complicates matters unnecessarily.

Lastly, what I share will be my own opinion, but it is just an opinion and I’m always open to learning from others with different views. My hope is that collectively we can share some worthwhile perspectives from both sides and possibly encourage more thinking and conversation around this or related issues.

Background Context

Ok, so having made those upfront disclaimers, I’ll begin by summarizing the back-story and context in which the discussion arose. If you’d like to refer to the pull request itself - it can be found here.

excercism.io is a learning platform that aims to provide code practice and mentorship for everyone. I got involved in developing the R track on Exercism and wrote about it earlier this year. Unlike most online learning platforms, with Exercism, all the coding happens on your machine in an environment you’re familiar with. So Exercism provides a command line tool which leverages an API in order to facilitate the process of fetching and submitting exercises.

A few months ago, I had an idea to write an R package which wraps this API. The thinking was that the user experience (for R users) might be improved upon by facilitating interaction with exercism.io directly from R itself. This removes the need for switching repeatedly between R and a shell when fetching, iterating on and submitting exercises - although now the addition of terminal tabs in RStudio 1.1 has already reduced this friction to a degree. In any case, there are additional opportunities for Exercism helper functions in the package which can be context aware and integrate with the RStudio if it is being used. An example this could be functions (or addins) which make use of the rstudioapi to detect which problem was last worked on when submitting so that it doesn’t need to be specified manually.

Katrin, who is a co-maintainer for the R track on exercism.io, has also been collaborating on this R package with me and has had some great ideas like leveraging testthat’s auto_test() to facilitate and encourage test driven development, as this is one of the implicit goals of Exercism. In the PR introducing this feature, the potential for function name confusion was soon evident when this new Exercism specific version of testthat::auto_test() was (initially) given the name autotest(). This reminded me that I’d in fact been thinking for a while about renaming all the exported functions to adopt the prefixing convention ex_* (for a few different reasons which I’ll get to later). So I figured this “name clash” was as good a catalyst as any, and made the suggestion to start adopting the new naming convention in the PR. Once again it’s worth noting that this was a mistake - I should have instead opened a separate issue to discuss my proposed change in naming conventions.

Discussion & follow-up

The suggestion was met with some resistance, and after some further discussion it became clear to me that it was a thoughtfully considered resistance. So I asked my friend Lorenz to weigh in on the discussion too, given that he knows Katrin and I but is not involved in the project and thus has the benefit of a more neutral perspective. To my surprise, he did not agree with me either!

But I did still seem to have Jenny Bryan on my side (thanks Jenny!), and I figured Hadley had to have thought it was a good idea at some point given the str_ prefix for stringr and fct_ prefix for forcats among others. So after thinking on the problem for a while, out of curiousity I eventually tweeted out a poll to see if I could get any sense of where the #rstats community falls on this issue.

What is your take on prefixing conventions for #rstats function names? (e.g. stringr/stringi, forcats, googlesheets)
— Jon Calder (@jonmcalder) October 20, 2017

At a glance it looks like a reasonable proportion are actually in favour of prefixing conventions for function names (or at least not against the idea), but of course there are a number of disclaimers to make here:

Character limits (at the time of the poll) made it hard to communicate the question clearly or to include any additional context for the question, so that probably leaves a lot of room for interpretation
I don’t have much reach on Twitter, so there weren’t many responses (81 votes is not much to go on)
Even if there had been a good number of responses, Twitter polls need to be looked at skeptically given the potential for sampling bias
Speaking of sampling bias, most of the votes came in after Hadley tweeted a reply to the poll so it makes sense that the results would be skewed towards his legions of followers (I’m one of them and the degree of influence is clear because his packages are what got me considering prefixing conventions in the first place, among others like googlesheets)

Maëlle had two helpful follow-ups for me. Firstly, she encouraged me to blog about this (and I don’t think I would have done so otherwise so thanks Maëlle!). Secondly, she directed me to the ROpenSci review process for her package ropenaq, which provides access to air quality data via the OpenAQ API. In his review of the package, Andrew MacDonald suggested the following:

“I was thinking that the names of functions might be a bit similar to functions in other packages that also use geography. What do you think of prefixing every function with a package-specific string? Perhaps something like aq_ before all the user-facing functions (i.e. countries() becomes aqcountries()). This is similar to another rOpenSci package, geonames, which uses GN (as in GNcities()). This has the added benefit of playing very nicely with Rstudio, which will show all the package functions as completions when users type aq and hit tab.”

Interestingly, this suggestion (although the original inspiration may have come from elsewhere) was later incorporated into ROpenSci’s packaging guide:

Consider an object_verb() naming scheme for functions in your package that take a common data type or interact with a common API. object refers to the data/API and verb the primary action. This scheme helps avoid namespace conflicts with packages that may have similar verbs, and makes code readable and easy to auto-complete. For instance, in stringi, functions starting with stri_ manipulate strings (stri_join(), stri_sort(), and in googlesheets functions starting with gs_ are calls to the Google Sheets API (gs_auth(), gs_user(), gs_download()).

Though I hadn’t seen this recommendation from ROpenSci at the time, it aligns very strongly with my initial reasoning for wanting to change the function names in the exercism package. It is primarily an API package, and all functions either interact with the exercism.io API or act on some (local) Exercism data/code (exercises). A potential objection could be that in some cases the ex_* prefix may be interpreted either as exercism_* or as exercise_*, but I don’t think that’s a problem since either way the context is common and shared implicitly.

Having said that, I’m also aware that a prefixing convention is not suitable in the majority of cases and there are reasons to avoid it, otherwise it would already be far more common. I’ve not tried to summarize the arguments for and against it here since this post is already quite lengthy, but I believe Katrin and Lorenz both raised a number of good points over in the original PR thread, so I would encourage you to read through that to get some more insight into the potential pros and cons.

Below is an overview of the currently exported functions for exercism, along with a brief description of what they do and potential new names for each should we adopt a prefixing convention:

Current Function	Description	New Name?
`set_api_key()`	Set an environment variable for the provided exercism.io API key, and store in .Renviron so that it can persist for future sessions.	`ex_set_key()`
`set_exercism_path()`	Set an environment variable for the provided exercism path, and store in .Renviron so that it can persist for future sessions.	`ex_set_path()`
`track_status()`	Fetches current track status from exercism.io	`ex_status()`
`check_next_problem()`	Returns the next problem for a language track	`ex_check()`
`fetch_problem()`	Fetches the files for a problem via the Exercism API and writes them into a new problem folder in the Exercism directory	`ex_fetch()`
`fetch_next()`	Checks for the next problem via the Exercism API, and writes the files into the folder in the Exercism directory	*special case of `ex_fetch()`
`open_exercise()`	Open files for an exercism.io problem	`ex_open()`
`start_testing()`	Exercism- and R-specific wrapper for `testthat::auto_test()` that starts testing your solution against the problem’s test cases.	`ex_auto_test()`
`submit()`	Submits the specified solution to exercism.io	`ex_submit()`
`skip_problem()`	Marks a problem as ‘skipped’ via the Exercism API	`ex_skip()`
`browse_exercise()`	Navigate to an exercise description on exercism.io	`ex_browse()`
`browse_solution()`	Navigate to an exercise solution on exercism.io	*special case of `ex_browse()`

So looking at the above, do you think this a good use case for an object_verb() naming convention? How should one determine this? Please feel free to comment with your thoughts and suggestions either in the comments section below, on Twitter, or in this RStudio Community discussion thread.

Data Science Podcasts

Wed, 31 May 2017 00:00:00 +0000

Podcasts are awesome. Especially when you’re stuck in traffic on the way to work.

Below are some podcasts I listen to that relate to data science and statistics. Each of them has something slightly different to offer, so if this is an area of interest to you then I recommend you give these a try!

Not So Standard Deviations

Roger Peng and Hilary Parker talk about the latest in data science and data analysis in academia and industry.

Data Skeptic

Data Skeptic is your source for a perspective of scientific skepticism on topics in statistics, machine learning, big data, artificial intelligence, and data science.

More or Less: Behind the Stats

Tim Harford and the More or Less team from BBC Radio 4 try to make sense of the statistics that surround us.

The R-Podcast

Giving practical advice on how to use R for powerful and innovative data analyses. The host of the R-Podcast is Eric Nantz, a statistician working in the life sciences industry who has been using R since 2004.

Partially Derivative

Hosted by Jonathon, Vidya, and Chris, Partially Derivative is a podcast about data science in the world around us. Episodes are a mix of explorations into the techniques used in data science and discussions with the field’s leading experts.

Linear Digressions

Hosts Katie Malone and Ben Jaffe explore machine learning and data science through interesting (and often very unusual) applications.

Are there other data science podcasts missing from this list that you can recommend? Feel free to comment below and let me know!

R track on exercism.io

Wed, 05 Apr 2017 00:00:00 +0000

As I’ve said before, when it comes to programming I’m a firm believer in the “learn by doing” approach. exercism.io is a project which exemplifies this.

I came across exercism.io earlier this year while exploring GitHub looking for an open source project to contribute to. The premise is fairly simple:

pick a language that you’d like to learn or improve on
fetch an exercise via the Command Line Interface (CLI)
code up and submit a solution for the exercise
return to the site to get feedback on your solution and/or to compare it to the solutions others have come up with

The problems are very simple to begin with, (usually starting out with the traditional “Hello, World!”), progressing to more difficult problems further on. It’s aimed at both newbies and experienced developers, with the philosophy being that for newer programmers the exercises are achievable but “with enough complexity to uncover bite-sized knowledge gaps”, whereas for more experienced developers, the problems “provide a balance of constraints and freedom and encourage you to explore trade-offs and best-practices”.

More experienced developers are also encouraged to get involved reviewing the solutions of others and/or to contribute to the project which is all completely open source, whether it is the website itself, API’s, the CLI, documentation or track content. The site is also well suited to those with experience in one or more languages who are wanting to ramp up in a new language, or to get a sense of the how the idiomatic approach to a problem might differ from language to language.

There are currently 35 active language tracks, with another 20+ language tracks planned or upcoming (essentially in an incubation stage). One of those which is hopefully soon-to-be-launched is the R language track, which I’ve been contributing to over the past two months and am pretty excited about.

If you’re interested, there are a number of ways you can get involved:

Firstly, give the R language track a try! (you’ll need to login on exercism.io using your GitHub account)
Once you’ve submitted a solution to a problem, you’ll be able to see other peoples submissions and are encouraged to comment on these and get discussions going around style and best practice, pros and cons of different approaches etc.
If you encounter any problems along the way (e.g. setup/install instructions, fetching or submitting exercises, running tests etc) then raise it via the online chat support in order to get help and/or bring it to someone’s attention if something needs to be fixed
With regard to the above, if you encounter an issue which applies specifically to the R track, then please open an issue on the R track repo
Consider becoming a mentor for the R track (if you’re interested, please reach out to me on Twitter or via my contact page)
Checkout the list of unimplemented exercises for the R track and follow the instructions there to submit a pull request
Lastly, look through exercism.io's contributing doc, which outlines a number of other ways you can get involved (either with a specific language track, or across other areas of the project as well)

Based on my involvement so far the exercism.io community seems very friendly and open, and I think its a great open source initiative, so there’s no reason why the #rstats community shouldn’t be well represented there.

On that note, a big thank you to exercism’s contributors, and especially to Jonathan Boiser and Katrina Owen for being friendly, helpful and supportive of my involvement in the project thus far. You guys are excellent role models for the greater open source community.

satRday Cape Town

Mon, 13 Mar 2017 00:00:00 +0000

Almost a full month has passed since satRday Cape Town. Time races on (as always) bringing plenty of challenges and opportunities with each new day, but part of me wants to go back and re-live the experience, just to have some more time to take it all in again.

It’s an event which I hope will remain firmly ensconced in my memory for many years to come. I met many amazing individuals and made a whole lot of new friends. It was a fantastic time. As a result, I figured it would be a good idea to thank some of the people who made it possible.

Right at the outset, I think it’s only right to give a big shoutout to Andrew: without whom, satRday would not have come to South Africa. To give you some context, I believe he first got the process started around May 2016 with a proposal to host satRday in Cape Town. Over the following nine months as things started to come together, he worked tirelessly in order to nail down all the conference details ahead of time, and also planned and executed brilliantly during the week of the conference itself. If asked, he’ll probably say the execution was mostly down to his ability to delegate but the truth is he put in most of the hours. We all owe him a debt of gratitude.

R-ladies at Boulders Beach to see some penguins @JennyBryan @SteffLocke pic.twitter.com/fe8StAIPJh
— Julia Silge (@juliasilge) February 19, 2017

To Ryan and Etienne, who helped out with a myriad of things including web design, planning and chairing sessions, manning the registration table, recording talks, and sorting out catering - thank you for all your hard work.

Also a special thanks to Katie Lennard who helped out as a teaching assistant for both days of workshops prior to speaking on Saturday.

To our wonderful keynote speakers - Julia Silge, Jenny Bryan and Steph Locke - who all travelled a long way in order to be with us: we really appreciate you and are so grateful that you were able to be there to play your part in making the conference such a success. We really value all the effort you put into your workshops and talks, and also your willingness to invest time in conversation with many of us in the midst of it all. I hope you enjoyed your time in South Africa!

To all of the speakers and to those who led tutorials - especially those of you who travelled from elsewhere in SA or even further afield in order to be here - thank you for the time and effort spent in preparation to present at satRday Cape Town. Thank you also for being flexible in dealing with the time constraints due to the packed programme!

I hope that you all got a lot out of the experience as we did. It was a treat to have such a diverse group spanning many disciplines within both industry and academia, and I think the breadth and depth of topics covered reflect a vibrant and rapidly growing R community in South Africa.

Then to the management and staff of Workshop17 for making your magnificent facility available for this conference and for looking after us while we were there - thank you!

My final thanks go to all of our sponsors for Cape Town satRday, and especially to Vantage Data for sponsoring the Data Visualisation Challenge along with post-conference drinks. This extended the opportunity for networking and was a great way to wrap things up after a jam-packed day.

There were over 200 people in attendance, with tickets sold out for both the workshops and the conference day itself. Thank you to all of you for being part of the event. I hope that like me you were rewarded by the experience, in the form of both new knowledge and fresh inspiration.

For those who weren’t able to make it, note that the workshop resources, as well as slides and videos from the talks are available via the conference website.

Welcome to R-bloggers!

Mon, 23 Jan 2017 00:00:00 +0000

Hooray! I am now part of the R-bloggers community!

R-bloggers is a blog aggregator for content created by the Rstats community. It was founded by Tal Galili towards the end of 2009, in order to help connect R bloggers with R users (and each other).

I came across R-bloggers relatively soon after it got going and have benefitted so greatly from it over the years. It has been quite something to see how it has grown and flourished in this time. Just take a look at Tal’s annual retrospectives between 2010 and 2012 which highlight the early growth of R-bloggers and you’ll see what I mean:

2009: R-bloggers gets up and running, 17 contributing blogs
2010: 143 contributing blogs, 3000 posts, 600 000 visits from over 200 countries
2011: almost 300 contributing blogs, over 1.4 million visits
2012: over 400 contributing blogs, 2.7 million visits by over 1.1 million people

These days R-bloggers continues to serve a large global audience with over 600 contributing bloggers. It is the go-to place for R news and tutorials and one of the core spokes of the R community.

Tal, I’m sure I speak for many in the R community when I say thank you for continuing to invest in and develop this resource which we all benefit from on a daily basis. Having appreciated content from R-bloggers for so many years I now look forward to being able to contribute some of my own and hope that I will be able to add value for others in the process.

Eduardo from Data Science LA did a really nice interview with Tal at the useR conference back in 2014. They discussed how he came to start R-bloggers, his thoughts on and involvement with R and the community, as well as another of his projects, R-Users: “A job board for people and companies looking to hire R users”.

Listening to it again now, two years later, I was struck by how much of their discussion is still so relevant, and Tal has some great insight and advice to share (e.g. don’t get too caught up with newer tech developments before they’re ready, unless they really solve a problem that you have).

Two of the things he mentions in particular I would like to highlight:

learn to create R packages as soon as possible
supplement your R and stats knowledge with some C++ (i.e. learn to use Rcpp)

These are two areas which have been really pivotal for me in terms of improving my knowledge and understanding of R, and empowering myself to dig deeper and do more with it. If you’re looking for good learning resources in either of these areas, I highly recommend Hadley Wickham’s books R packages and Advanced R (which has a great chapter on Rcpp).

When asked what his advice would be to an R user back in 2007, I had to chuckle at Tal’s remark not to invest in Tinn-R because it won’t be around much longer :-)

But jokes aside, whether you are a new or long time R user, it’s a great interview that is worth a listen.

Why swirl?

Mon, 09 Jan 2017 00:00:00 +0000

swirl is a software package for the R programming language that turns the R console into an interactive learning environment. Users receive immediate feedback as they are guided through self-paced lessons in data science and R programming.

I think I first came across swirl in mid-2014, while working through the early stages of the Data Science Specialization on Coursera, put together by Johns Hopkins University professors Roger Peng, Brian Caffo and Jeff Leek.

The courses in this specialization make extensive use of swirl to introduce and explore various topics in the form of interactive programming assignments in R (e.g. R programming). This is probably largely due to the fact that these three professors were involved in the early development of swirl with it’s creator Nick Carchedi who is a graduate of Johns Hopkins Biostatistics. For those who may be new to R or data science - these Coursera courses are an excellent resource which I can highly recommend.

Of course there are many, many great resources for getting started (and later improving) with R programming: try the online learning suggestions from RStudio, or take a look through some of these Quora answers and you will find a wealth of R resources: online courses, books, tutorials and more. If that’s not enough for you - Google is your friend. There is so much out there!

I’d like to focus on swirl in this post however, since I feel it doesn’t really get as much attention as it should. There are three key ways in which I think swirl has got it right as a learning platform:

it directly facilitates learning by doing
it runs from within R
it is free and open source

Learn by Doing

First is the “learn by doing” component, which is almost as crucial to learning to program as it is to learning to ride a bike, or to drive a car.

Sure, programming is mostly cognitive, but in my experience you only begin to internalize and understand concepts, syntax etc properly when you start to apply them. The primary learning you do when learning to ride a bike or drive a car happens when getting onto a bike or into a car for the first time and (usually) having someone walk you through the interface, controls etc as you experience them for yourself.

The need to learn by doing might seem obvious, but if you stop and think about it for a moment, you might find that given the wealth of great R programming books, videos, courses etc its entirely plausible that you could begin your learning path there and after being pulled in different directions end up spending very little (or no) time in R. A few days ago I was chatting to one of my cousins who has been learning R on and off for a while now and when I asked him how it was going he said he thinks his learning process so far has lacked sufficient “hands on” practice with R.

swirl is great because it forces you to learn by doing, whether that means copying code/syntax from an instruction, interrogating R’s help documentation in order to work out how to make use of a particular function, or experimenting with different options by trial and error.

Learn R, in R

Second is the “learn R, in R” component, which is what makes swirl pretty unique. There are a few other learning platforms which embed or reproduce the R console within their own web environments to produce a similar outcome, but at the end of the day, in some or other (possibly quite small) respects none can be equivalent to the reality of working in a local R environment on your own computer, whether that be RStudio (recommended!), some other IDE of your choosing, or even just running R from the terminal.

Since swirl runs within R itself, when you learn with swirl, you can work with the exact same local R environment you will later use to program in R. By way of a poor analogy, this is somewhat like the difference between taking your driving lessons in someone elses car and taking them in the car that you plan to use once you have obtained your license. If you have the option of the latter, there are certainly benefits to doing so.

At the same time I do acknowledge that there can also be some downsides to this when considered from certain perspectives (e.g. the swirl approach of embedding the learning environment within R is not as flexible as the reverse and does constrain the learning environment to some extent). However as mentioned above I think what swirl has to offer is unique in this respect and it is worth highlighting that the advantages are significant.

I am certainly not averse to other R learning platforms and realize that some have other advantages over swirl. For example, it is worth noting that the creator of swirl is now working at DataCamp, which is an excellent learning platform that offers a host of courses in both Python and R, some of which in fact still make use of swirl.

Free and Open Source

Third is the fact that swirl is completely free and open source. This means that students, instructors and other R developers can dig into both swirl itself and swirl lesson content, learn from it, and then suggest and/or contribute towards corrections and improvements over time. Being able to look behind the curtain opens up a world of learning opportunities.

For example, my first ever pull request on GitHub, was in the swirl courses repository. It was only a simple spelling correction for lesson content from one of the aforementioned Coursera swirl courses, but you’ve got to start somewhere. It’s open source projects like swirl that offer these opportunities for “getting started”.

In a little over two years since that first pull request, and I have been able to contribute in a number of different ways to various swirl projects and courses, learning as I go. A few months ago, I also decided to get started on two of my own swirl courses, which I’m continuing to work on iteratively as and when I can make time. I’ve still got a long way to go, but I’ve already learnt so much through the process, and will definitely discuss these further in later posts.

My recommendation is that you checkout swirl if you haven’t already done so, because it is worth using. The easiest starting point is the students page on the swirl website, which provides all the steps you’ll need (especially if you are completely new to R).

And if you’re a more advanced R user, why not consider contributing a course? The documentation for swirl is excellent, and it is very easy to get started creating a course. All the information you’ll need to do so is provided on the instructors page on the swirl website. Also note that the developers of swirl have created a swirl course network (SCN) in an effort to “list and organize all publicly available swirl courses”. If you have created a swirl course or are considering doing so, please take a look at this to find out how to share your course.

If you need help or would like to collaborate on a swirl course please get in touch with me. I’ll be happy to assist where and when I am able to do so.

satRday in Cape Town

Sat, 17 Dec 2016 00:00:00 +0000

In just two months time, the second satRday will be taking place right on my doorstep, in Cape Town, South Africa. I keep telling people I am looking forward to it, but to be honest that’s really quite an understatement. I am super excited!

satRdays are SQLSaturday-inspired, community-led, one-day, regional and affordable conferences around the world to support collaboration, networking and innovation within the R community.

If you don’t know what satRdays are about, here is the back story…

In early-mid 2015, Steph Locke got conversation going around the possibility of a SQLSaturday-inspired R conference after raising the idea at EARL 2015 Boston. With fantastic support from the #rstats community, a proposal was developed and later submitted to the R Consortium in January 2016.

In March 2016, the R Consortium announced their support for satRdays, with three events to be hosted initially, and plans for additional meet-ups as the R user base grows. Multiple locations were suggested for the first three satRdays and the agreed upon strategy was to host one in Eastern Europe, one in North America, and one on another continent elsewhere in the world.

Having been involved with the project early on, Gergely Daróczi agreed to organise the first satRday in Budapest. More than 2000 people from the online community voted on where the next two satRday events should take place, and Puerto Rico and Cape Town claimed the most votes for North America and the rest of the world.

The first satRday took place in Budapest on the 3rd September 2016 and was a big success, with almost 200 people from 19 countries registering for the event. The conference delegates comprised of a good mix of R enthusiasts from both industry and academia, who were treated to high quality workshops as well as invited and contributed talks from 25 local and international speakers.

So that brings us to the present, with preparations for Cape Town satRday already well under way. The conference will take place on the 18th February 2017, and the venue is Workshop 17, located in the heart of Cape Town’s beautiful V&A Waterfront.

Keynote speakers Steph Locke, Jenny Bryan and Julia Silge will be conducting workshops on the 16th & 17th February, covering the building and validation of logistic regression models, the intersection of R, Git & Github, and the development of reactive web apps with Shiny (you can find further workshop details here).

A number of other speakers have already been confirmed, with sessions planned around topics such as R in the Sciences, R and Big Data, and Applications of R in Industry. Presentations may take the form of a workshop (90min), standard talk (20min), lighting talk (5min) or poster, and proposals can be submitted here.

Note that early-bird registration closes less than a week from now, and presentation proposals will be accepted up until 20th January 2017. Below is a summary of all the key dates relating to the conference:

Event	Date
Early-Bird Registration Deadline	2016-12-23
Workshop Submission Deadline	2017-01-20
Talk Submission Deadline	2017-01-20
Notification of Acceptance	2017-01-25
Registration Deadline	2017-02-15
Workshops	2017-02-16 / 2017-02-17
Conference	2017-02-18

All this information - and more - can be found on the website. I look forward to seeing many of you at the conference!