R

webmockr v2 is here. You can find the source at https://github.com/ropensci/webmockr, and the docs at https://docs.ropensci.org/webmockr. There’s some big changes in this version; most importantly a breaking change, thus the major version change this time. Here’s a run down of the important items in this release. Installation pak::pak("webmockr") The breaking change: error handling Previous to v2 when stubs were constructed starting with stub_request() if an error occurred in a pipe chain, or non-pipe flow, the stub created prior to the error remained. This was not correct behavior from a logical perspective - i.e., one would expect if an error occurred that the thing they were trying to do did not stick around. The new behavior as of v2 deletes the stub upon any error during its creation. Under the hood we’re using withCallingHandlers() to handle different types of errors, throw warnings, etc. For example, wi_th() only accepts types list and partial, so fails with this code: ...

While reviewing an R package at work I realized I wasn’t totally sure what advice to give about examples for internal functions in a package. That is, there’s an R package. The package has some exported functions, and some internal functions that are not exported. Internal functions are not loaded when the package loads so the normal flow of running examples under roxygen2 tag @examples doesn’t work (assuming you don’t prevent it from running any of various ways). ...

cowsay is a command line program written in Perl. The original version had a final release in 2016 (that’s the version of many installed cowsay programs) and there’s a number of forks of that release in Perl. There are also many many versions of cowsay in other programming languages, like the one I maintain written in R, unimaginatively called cowsay. I wrote about cowsay here back in 2014. I didn’t think this would ever be 300+ stars popular, but here we are. Given that people seem to actually use it - or at least star it - seems worth putting some more time into it. ...

I wrote the other day about overcoming an issue with Shiny. Another issue I ran into concurrently was about file inputs. The issue was that file inputs (i.e., shiny::fileInput) was difficult to clear. That is, after a user uploads a file, it was easy to get some of the various parts cleared/cleaned up, but not others: (Not Easy) The UI components of fileInput (the text of the file name, the loading display) (Not Easy) The data behind the fileInput handler (Easy) Displaying some feedback in the UI after handling file input Load libraries ...

I’ve been working on Shiny app at work for the past few months. One of the many frustrating things about Shiny lately has been around buttons. Well, it wasn’t really about buttons, but that’s where it started. Load libraries library(shiny) library(bslib) library(crul) Helper function, returned a random UUID from an httpbin server httpbin_uuid <- function(...) { con <- crul::HttpClient$new("https://hb.opencpu.org") res <- con$get("uuid") jsonlite::fromJSON(res$parse("UTF-8"))$uuid } A bslib ui component ui <- page_sidebar( title = "My dashboard", sidebar = list( actionButton("submit", "Submit"), actionButton("reset", "Reset") ), textInput(inputId = "name", "Your name"), textOutput("uuid") ) Here’s the server part that was giving me trouble. As I said this was an inherited repo, and the server side handling for many buttons was done with eventReactive as below. Using eventReactive meant that button clicks only sometimes triggered the server side code. ...

Soooo, my last job at Deck was amazing. I loved it. I was doing data engineer stuff there, mostly maintaining infrastructure for data pipelines. Everyone was great and the mission was amazing: helping Democrats win. Yet the company was shut down about a month ago, sending me on another job search, the 3rd since early/mid 2021. I’m super thrilled to have landed a job (Software and Reproducibility Software Developer) at the Fred Hutch Data Science Lab (DASL), headed up by Jeff Leek, working with Sean Kross, Amy Paguirigan, and Monica Gerber, among many other amazing folks. ...

TL;DR In 6 months (end of November 2022) the CRAN Checks API https://cranchecks.info/ will be gone You can still get badges at https://badges.cranchecks.info You can use the new badges like: [](https://cran.r-project.org/web/checks/check_results_dplyr.html) Find more details at https://github.com/sckott/cchecksbadges Sunsetting the CRAN Checks API If you contribute an R package to CRAN, you may use badges from the CRAN checks API at https://cranchecks.info/. The CRAN Checks API has been operating since about September 2017 (I think). The API has a number of routes, but really people only use the badges. ...

You’ve experienced an HTTP redirect (or URL redirect, or URL forwarding) even if you haven’t noticed. We all use browsers (I assume, since you are reading this), either on a phone or laptop/desktop computer. Browsers don’t show all the HTTP requests going on in the background, some of which are redirects. Redirection is used for various reasons, including to prevent broken links when web pages are moved, for privacy protection, to allow multiple domains to refer to a single web page, and more. ...

In February this year I wroute about how many parameters functions should have, looking at some other languages, with a detailed look at R. On a related topic … As I work on many R packages that are API clients for various web services, I began wondering: What is the best way to deal with API routes that have a lot of parameters? The general programming wisdom I’ve seen is that a function should have no more than 3-4 parameters (e.g., this long SO thread, or this one). So should one do anything different from a normal function when that function is connecting to a web API route with a lot of parameters? I’ve not found very much spilled ink on this exact topic, but I’ll discuss what I have found. ...

Update on 2021-02-09: I’ve archived 8 more packages. Post below updated Code is often arranged in packages for any given language. Packages are often cataloged in a package registry of some kind: NPM for node, crates.io for Rust, etc. For R, that registry is either CRAN or Bioconductor (for the most part). CRAN has the concept of an archived package. That is, the namespace for a package (foo) is still in the registry (and can not be used again), but the package is archived - no longer gets updated and checks I think are no longer performed. ...