Revolutions

Easy R Tutorials with Dev Containers

Ever written a tutorial for R — or simply shared some R code with someone — and been told that your code doesn't work on their machine? There's now an easy way to solve that problem: Dev Containers. Dev Containers are a standardized container format designed for interactive use. You can set up a Dev Container with the specific version of R, R packages, and other software to guarantee that your R code will run on their machine just as it did on yours. Dev Containers are 100% open source and integrated with Visual Studio Code, which provides a convenient environment for running your R scripts and notebooks. 

At the recent User!2022 conference, I gave a 20-minute presentation describing how Dev Containers work with R:

(Dev Containers also work with GitHub CodeSpaces, to create a cloud-based environment for running your R code in a single click. I demonstrated that at last week's RStudio::conf, and I'll post that video when it's available.)

If you'd like to set up a Dev Container for your own R project, the GitHub repository linked at the link below provides all the info you need.

GitHub (revodavid): Easy R Tutorials with Dev Containers

Obtaining tokens with AzureAuth inside a Shiny app

by Hong Ooi, senior data scientist, Microsoft Azure

As of version 1.2.0 (released to CRAN late last month), it’s possible to use the AzureAuth package to login interactively to Azure from within a Shiny webapp. Because a Shiny app has separate UI and server components, some changes had to be made to the interactive authentication flows. In particular, the authorization step (logging in to Azure) has to be conducted separately from the token acquisition step.

AzureAuth now provides the build_authorization_uri function to facilitate this separation. You call this function to obtain a URI that you browse to in order to login to Azure. Once you have logged in, Azure will return an authorization code as part of a redirect, which can be captured by the browser. The code is then passed to the get_azure_token function in the auth_code argument, which then completes the task of acquiring the token.

Here is a skeleton Shiny app that demonstrates its use.

Note that this process is only necessary within a web app, and only when using an interactive authentication flow. In a normal R session, or when using the client credentials or resource owner grant flows, you can simply call get_azure_token directly.

A DevOps Process for Deploying R to Production

I've been at the EARL Conference in London this week, and as always it's been inspiring to see so many examples of R being used in production at companies like Sainsbury's, BMW, Austria Post, PartnerRe, Royal Free Hospital, the BBC, the Financial Times, and many others. My own talk, A DevOps Process for Deploying R to Production, presented one process for automating the process of building and deploying R-based applications using Azure Pipelines and Azure Machine Learning Service. The talk at EARL wasn't recorded, but you can see the slides here, and also watch a slightly shorter version of the talk as it was presented at the useR!2019 conference in Toulouse, below:

If you'd like to try setting up a build process for R yourself with Azure Pipelines, this GitHub repository is a good place to start. It provides a simple example of a model built with R, which gets triggered on check-in to the repository (you can see the builds in Pipelines, here). The README.md file also includes links to useful resources on setting up an end-to-end workflow for machine learning.

GitHub (revodavid):  MLOps with R and Azure Pipelines

An architecture for real-time scoring with R

Let's say you've developed a predictive model in R, and you want to embed predictions (scores) from that model into another application (like a mobile or Web app, or some automated service). If you expect a heavy load of requests, R running on a single server isn't going to cut it: you'll need some kind of distributed architecture with enough servers to handle the volume of requests in real time.

This reference architecture for real-time scoring with R, published in Microsoft Docs, describes a Kubernetes-based system to distribute the load to R sessions running in containers. This diagram from the article provides a good overview:

You can find detailed instructions for deploying this architecture in Github. This architecture uses Azure-specific components, but you could also use their open source equivalents if you wanted to host them yourself:

• Microsoft Machine Learning Server (and specifically, the mrsdeploy package) is used to expose an R function for prediction as an HTTP endpoint. You can use any method you like to make R into a REST service: for example, standard R and the plumber package.
• Azure Container Registry is where the container images with R and your prediction code are stored. You could also use your own private Docker Registry, or Docker Hub here. 
• Azure Kubernetes Service provides a managed Kubernetes cluster to host the containers and manage them in the underlying server cluster (which can be scaled up and down in size dynamically, according to load). If you have your own Kubernetes cluster, you can substitute it here (but note the security considerations and authentication required).

For more details on this architecture, take a look at the Microsoft Docs article linked below.

Microsoft Docs: Real-time scoring of R machine learning models

How to deploy a predictive service to Kubernetes with R and the AzureContainers package

by Hong Ooi, senior data scientist, Microsoft Azure

It's easy to create a function in R, but what if you want to call that function from a different application, with the scale to support a large number of simultaneous requests? This article shows how you can deploy an R fitted model as a Plumber web service in Kubernetes, using Azure Container Registry (ACR) and Azure Kubernetes Service (AKS). We use the AzureContainers package to create the necessary resources and deploy the service.

Fit the model

We’ll fit a simple model for illustrative purposes, using the Boston housing dataset (which ships with R in the MASS package). To make the deployment process more interesting, the model we fit will be a random forest, using the randomForest package. This is not part of R, so we’ll have to install it from CRAN.

data(Boston, package="MASS")
install.packages("randomForest")
library(randomForest)

# train a model for median house price
bos_rf <- randomForest(medv ~ ., data=Boston, ntree=100)

# save the model
saveRDS(bos_rf, "bos_rf.rds")

Scoring script for plumber

Now that we have the model, we also need a script to obtain predicted values from it given a set of inputs:

A small logical change with big impact

In R, the logical || (OR) and && (AND) operators are unique in that they are designed only to work with scalar arguments. Typically used in statements like

while(iter < 1000 && eps < 0.0001) continue_optimization()

the assumption is that the objects on either side (in the example above, iter and eps) are single values (that is, vectors of length 1) — nothing else makes sense for control flow branching like this. If either iter or eps above happened to be vectors with more than one value, R would silently consider only the first elements when making the AND comparison.

In an ideal world that should never happen, of course. But R programmers, like all programmers, do make errors, and using non-scalar values with || or && is a good sign that something, somewhere, has gone wrong. And with an experimental feature in the next version of R, you will be able to set an environment variable, _R_CHECK_LENGTH_1_LOGIC2_, to signal a warning or error in this case. But why make it experimental, and not the default behavior? Surely making such a change is a no-brainer, right?

It turns out things are more difficult than they seem. The issue is the large ecosystem of R packages, which may rely (wittingly or unwittingly) on the existing behavior. Suddenly throwing an error would throw those packages out of CRAN, and all of their dependencies as well.

We can see the scale of the impact in a recent R Foundation blog post by Tomas Kalibara where he details the effort it took to introduce an even simpler change: making if(cond) { ... } throw an error if cond is a logical vector of length greater than one. Again, it seems like a no-brainer, but when this change was introduced experimentally in March 2017, 154 packages on CRAN started failing because of it ... and that rose to 179 packages by November 2017. The next step was to implement a new CRAN check to alert those package authors that, in the future, their package would fail. It wasn't until October 2018 that the number of affected packages had dropped to a suitable level that the error could actually be implemented in R as well.

So the lesson is this: with an ecosystem as large as CRAN, even "trivial" changes take a tremendous amount of effort and time. They involve testing the impact on CRAN packages, coding up tests and warnings for maintainers, and allowing enough time for packages to be udpated. For an in-depth perspective, read Tomas Kalibera's essay at the link below.

R Developer blog: Tomas Kalibera: Conditions of Length Greater Than One

How R gets built on Windows

I wasn't at the Use of R in Official Statistics (uRos2018) conference in the Netherlands last month, but I'm thankful to Jeroen Ooms for sharing the slides from his keynote presentation. In addition to being a postdoc staffer at ROpenSci, Jeroen maintains the official repository for the daily R builds on Windows — you might recognize his name from the verification certificate that pops up when installing R on Windows. His uRos2018 talk provides a fascinating glimpse into the complex systems, dependencies, and processes that come together to make installing R as easy as as double-click.

On thing I found if interest is that while R is a complex program in its own right — made up of a mix of C (32%), Fortran (24%) and R (37%)  code — it also relies on a number of external libraries to perform some of its underlying tasks. For example:

• When you multiply two matrices or perform other linear algebra operations, R uses the BLAS and LAPACK libraries for the calculation. (Microsoft R open swaps in the Intel Math Kernel Library here, which provides the same calculations using different algorithms.)
• When you download a file with download.file or install.packages, R uses the libcurl library to manage the network transfer.
• When you use character data with foreign encodings (for example text with accents, symbols, and emojis), R uses the libicu library so those strings can be handled and compared in a uniform way.
• When you use regular expressions with grep and regexpr, R uses the PCRE library to parse the syntax and perform the search operation.
• For graphics, R uses the cairo library to render points, lines, and text as a bitmap image for display and/or export.

Using these libraries means that the R maintainers don't need to reimplement the wheel, but can instead use open-source libraries that are used in a plethora of systems to accomplish these universal tasks. On Linux-based systems, these libraries are generally pre-installed for any application to use. But on Windows (and Mac), R needs to build these libraries for its own use, which makes building R a complex process. Not only do you have to have the right set of compilers and scripts to build R itself, but also all its library dependencies as well. R packages may, in turn, depend on other third-party libraries and in that case the same issues apply to building them, too.

You can find all of the scripts used to create the official releases and daily builds (r-patched and r-devel) for R for Windows on Github. Brian Ripley and Duncan Murdoch (and now, Jeroen Ooms) have long provided RTools: a collection of Windows programs (shell commands, other programs) which, given the right compiler, will allow R's build scripts to run. One other interesting bit of news from Jeroen's keynote is that an experimental version of RTools is on the way, which promises to make it easier to build, distribute and install external libraries on Windows.

If you're at all interested in the inner workings of what it takes to make R run on Windows, I recommend checking out Jeroen's talk at the link below.

Jeroen Ooms: The R infrastructure

R in the Windows Subsystem for Linux

R has been available for Windows since the very beginning, but if you have a Windows machine and want to use R within a Linux ecosystem, that's easy to do with the new Fall Creator's Update (version 1709). If you need access to the gcc toolchain for building R packages, or simply prefer the bash environment, it's easy to get things up and running.

Once you have things set up, you can launch a bash shell and run R at the terminal like you would in any Linux system. And that's because this is a Linux system: the Windows Subsystem for Linux is a complete Linux distribution running within Windows. This page provides the details on installing Linux on Windows, but here are the basic steps you need and how to get the latest version of R up and running within it.

First, Enable the Windows Subsystem for Linux option. Go to Control Panel > Programs > Turn Windows Features on or off (or just type "Windows Features" into the search box), and select the "Windows Subsystem for Linux" option. You'll need to reboot, just this once. 

Next, you'll need to install your preferred distribution of Linux from the Microsoft Store. If you search for "Linux" in the store, you'll find an entry "Run Linux on Windows" which will provide you with the available distributions. I'm using "Ubuntu", which as of this writing is Ubuntu 16.04 (Xenial Xerus).

Once that's installed you can launch Ubuntu from the Start menu (just like any other app) to open a new bash shell window. The first time you launch, it will take a few minutes to install various components, and you'll also need to create a username and password. This is your Linux username, different from your Windows username. You'll automatically log in when you launch new Ubuntu sessions, but make sure you remember the password — you'll need it later.

From here you can go ahead and install R, but if you use the default Ubuntu repository you'll get an old version of R (R 3.2.3, from 2015). You probably want the latest version of R, so add CRAN as a new package repository for Ubuntu. You'll need to run these three commands as root, so enter the password you created above here if requested:

sudo echo "deb http://cloud.r-project.org/bin/linux/ubuntu xenial/" | sudo tee -a /etc/apt/sources.list

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E084DAB9

sudo apt-get update

(Don't be surprised by the message key E084DAB9: public key "Michael Rutter <[email protected]>" imported. That's how Ubuntu signs the R packages.)

Now you're all set to install the latest version of R, which can be done with:

sudo apt-get install r-base

And that's it! (Once all the dependencies install, anyway, which can take a while the first time.) Now you're all ready to run R from the Linux command line:

Note that you can access files on your Windows system from R — you'll find them at /mnt/c/Users/<your-Windows-username>. This FAQ on the WSL provides other useful tips, and for complete details refer to the Windows for Linux Subsystem Documentation.

Update Dec 14: Jeroen Ooms shares that this works for running RStudio Server and OpenCPU Server as well.

Wow the Windows Subsystem for Linux totally works. Installed both opencpu-server and rstudio-server on Windows 10 using standard Ubuntu installers from https://t.co/clTdvM7ezt. Thanks to @revodavid for pointing this out at https://t.co/iTea5cc5hZ pic.twitter.com/2gyLPVquT0

— Jeroen Ooms (@opencpu) December 14, 2017

Developing AI applications on Azure: learning plans at three levels

If you're looking to expand your skills as an AI developer, or just getting started, these learning plans for AI Developers on Azure provide a wealth of information to get you up to speed. The beginner, intermediate and advanced tracks all provide step-by-step guides to setting up the tools and data in Azure, along with worked examples in iPython Notebooks.

• The Beginner AI Developer Learning Plan provides an introduction to artificial intelligence and cognitive systems. It begins with an overview of Cognitive Services, and then works through several examples of using those APIs in applications: handwriting comprehension, speech comprehension, and face detection.
• The Intermediate AI Developer Learning Plan walks through the process of creating an AI application that understands voice input. It begins with an overview of LUIS, the Language Understanding Intelligent Service, and walks through the process of defining intents, entities, and utterances, and labels. By the end of the session, you will have created a Python app that can understand commands you define and execute them when they are spoken.
• The Advanced AI Developer Learning Plan focuses on vision-enabled applications. It begins with an introduction to computer vision and deep learning, and sets you up with a data science virtual machine for development. You will use CNTK to train a simple neural network on image data, and logistic regression to build a classifier. Then, you'll build a convolutional neural network and use transfer learning to implement object recognition in the app, and learn how to deploy the recognizer to a Raspberry Pi device.

Each of the learning paths will take 4-6 hours to work through. A Microsoft Azure subscription is required to implement various services in the plan (you can get an Azure free account if you don't already have one). You can find all three AI Developer Learning Plans at the link below.

Microsoft Azure Learning Paths: AI Developer on Azure

How to make best use of the byte compiler in R

Tomas Kalibera,  the newest member of the R Core Team, has been working for the last several years with fellow Core Team member Luke Tierney implementing R's byte-code compiler and interpreter. Byte-compiling R code often improves its speed of execution, and usually happens without you having to take any explicit action. R's base and recommended packages are compiled when R is installed, and your scripts and functions are automatically compiled "just-in-time" as you execute them. 

At the useR!2017 conference last month, Tomas Kalibera gave a very interesting talk: Taking Advantage of the Byte Compiler. In particular, he shows that not all R code is equivalent to the byte compiler. For example, the byte compiler has most impact on code that works with scalar arithmetic in tight loops. There's also some kinds of R code that takes a relatively long time to compile, which can swamp the performance benefits if the function is compiled at execution-time. (Package authors can avoid this for their users by declaring that their packages be compiled on install, by including Byte-Compile: yes in the DESCRIPTION file.) For package authors and R users that care about performance, you can find lots of tips like this in the talk embedded below.

For even more details on the implementation of the byte-compiler, take a look at the document A Byte Compiler for R by Luke Tierney.