No Clocks

Want to learn how to implement GTD® in Notion? Read this article to learn how I’m using Notion to get more done in less time.

A comprehensive guide to setup an R development environment for Ubuntu running in the Windows Subsystem for Linux (WSL)

One of the most common challenges that computer users often face is data organization. I see users with cluttered desktops full of individual files, folders that are duplicated (desktop and default home directory), and users struggling to find their own data which makes content management very difficult. In this article, I will share some guidelines […]

Using serverless containers to deploy scalable R functions.

This post provides a guide to effectively and securely scale your ShinyProxy deployment of shiny apps in production with Docker Swarm and Traefik

Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

This document is full of supplemental resources and content from the Shiny in Production Workshop delievered at rstudio::conf 2019.

This guide aims to introduce the reader to the main elements of the R ecosystem.

Collection of notifications, confirm dialogs and alerts for 'Shiny' applications - dreamRs/shinypop

Collections of resources for API Designers

Web applications can expose APIs so clients to interact with the application. Well-designed web APIs should support platform independence and service evolution.

If you’ve used the Plumber package to make R models or other code accessible to others via an API, sooner or later you will need to decide how to handle and report errors. By default, Plumber will catch R-level errors (like calls to stop()) and report them to users of your API as a JSON-encoded error message with HTTP status code 500 – also known as Internal Server Error. This might look something like the following from the command line: $ curl -v localhost:8000/ > GET /status HTTP/1.1 > Host: localhost:8000 > User-Agent: curl/7.64.0 > Accept: */* > < HTTP/1.1 500 Internal Server Error < Date: Sun, 24 Mar 2019 22:56:27 GMT < Content-Type: application/json < Date: Sun, 24 Mar 2019 10:56:27 PM GMT < Connection: close < Content-Length: 97 < * Closing connection 0 {"error":["500 - Internal server error"],"message":["Error: Missing required 'id' parameter.\n"]} There are two problems with this approach: first, it gives you almost zero control over how errors are reported to real users, and second, it’s badly behaved at the protocol level – HTTP status codes provide for much more granular and semantically meaningful error reporting. In my view, the key to overcoming these problems is treating errors as more than simply a message and adding additional context when they are emitted. This is sometimes called structured error handling, and although it has not been used much historically in R, this may be changing. As you’ll see, we can take advantage of R’s powerful condition system to implement rich error handling and reporting for Plumber APIs with relative ease.

Simple functions to lookup items in key-value pairs. See Mehta (2021) .

Learn how to use the open-source tool Plumber to create RESTful APIs for R programs.

Learn how to create a REST API in R using the plumber package.