Press "Enter" to skip to content

Category: R

The Importance of Re-Learning for Knowledge Updates

Neil Saunders thinks about learning:

Some years ago I read an article – I forget where – describing how our general knowledge often becomes frozen in time. Asked to name the tallest building in the world you confidently proclaim “the Sears Tower!”, because for most of your childhood that was the case – never mind that the record was surpassed long ago and it isn’t even called the Sears Tower anymore. From memory the example in the article was of a middle-aged speaker who constantly referred to a figure of 4 billion for the human population – again, because that’s what he learned in school and had never mentally updated.

Is this the case with programming too? Oh yes – as I learned today when performing the simplest of tasks: reading CSV files using R.

The specific task involved ways to read a list of CSV files in R, though the impetus behind the post is ways to keep that knowledge up to date. This is one reason why it can be useful to attend introductory-level sessions on topics you already know: there might be new things in recent versions of software which change the game. There are also times when you learn something en passant: in a talk (or blog post or video) about topic X, the author might casually use some technique or tool not related to the topic itself.

Comments closed

Thoughts on Code Commenting

Maelle Salmon has comments:

An important goal of good code is to be readable so that future contributors can build with and upon it as needed. Good commenting is part of the toolset for reaching that goal. In this post we shall first present principles of code commenting, and then a few tips.

I agree with the general thrust of Maelle’s argument. “What and how” types of comments are fine for pseudo-code that you write before beginning the real work, but they’re scaffolding and shouldn’t stick around when the code is done. Instead, focus on the “why.”

One area of focus I’d bring in terms of how I view comments is that I will have (and like to see) more detailed comments in the most difficult sections of code. Yeah, if you can simplify the code, that’s better than adding a lengthy comment. But there’s always some bit of code which five people have tried to simplify over the years but it doesn’t work. Knowing what the business rules are, what you’ve unsuccessfully tried in the past, and why this is the best available option (as of the time of the last update) can help prevent developer six from tilting at windmills.

Comments closed

Improving the Shiny UI Experience

Tim Brock talks responsiveness:

Confusingly (and rather unhelpfully) when it comes to web applications there are two different topics that may be referred to by the terms “responsive” or “responsiveness”. If you stick “responsive UI” into your favourite search engine the top results will concern “responsive design” – the practice of making websites and applications work across devices, regardless of device and browser dimensions. That’s an interesting and important topic when it comes to designing data-science applications but it’s not what we’re covering here.

What we’re covering here is responsiveness that you might stick “un” in front of if things got really bad. It’s about making your user interface feel like it responds instantaneously to a user’s interaction. We’ll go from covering clicking a button and making sure the user sees some kind of simple acknowledgement the button has been clicked to clicking a button (or dragging a slider or…) and immediately seeing the results of complex computations.

Read on to learn a few things you can do to make those apps a little more user-friendly.

Comments closed

Building a Shiny App in R and Python

Nicola Rennie does a language throw-down:

Shiny is an R package that makes it easier to build interactive web apps straight from R. Back in July 2022 at rstudio::conf(2022), Posit (formerly RStudio) announced the release of Shiny for Python. As someone who knows Python but hasn’t written any Python code for quite a long time, I wanted to see how the two compared. So I did the only logical thing and built a Shiny app – twice!

After building (almost) identical Shiny apps, with one built solely in R and the other solely in Python, I’ve written this blog post to take you through some of the things that are the same, and a few things that are slightly different.

Note: at the time of writing Shiny for Python is still in alpha, so if you’re reading this blog quite a while after it was first published, some things may have changed.

The code, as you’d expect, looks quite similar. I also learned about plotnine, something I’ll need to keep in mind. H/T R-Bloggers.

Comments closed

Designing Test Code for shinytest2

Russ Hyde wraps up a series on shinytest2:

UI-driven end-to-end tests require a bit more code than unit tests. For example, starting the app and navigating around to set up some initial state will require a few lines of code. But these are things you’ll likely need to do in several tests. As you add more and more test cases and these commonalities reveal themselves, it pays to extract out some helper functions and / or classes. By doing so, your tests will look simpler, the behaviour that you are testing will be more explicit, and you’ll have less code to maintain. We’ll show some software designs that may simplify your {shinytest2} code.

This post builds upon the previous posts in the series, but is quite a bit more technical than either of them. In addition to shiny development, you’ll need to know how to define functions in R and for the last section you’ll need to know about object-oriented programming in R (specifically using R6). The ideas in that section may be of interest even if you aren’t fluent with R6 classes yet.

Click through for the series finale.

Comments closed

Using the Native Pipe in R 4.1+

Michael Mayer shows off the native R pipe:

What does the pipe do? It puts the object on its left as the first argument into the function on its right: iris %>% head() is a funny way of writing head(iris). It helps to avoid long function chains like f(g(h(x))), or repeated assignments.

In 2021 and version 4.1, R has received its native forward pipe operator |> so that we can write nice code like this:

Tying pipe syntax all back together, the magrittr pipe %>% was (as I recall) built with the F# pipe |> in mind. In R 4.1 and later, the built-in pipe is |>, as is right and natural in this world. Regardless, do check the comment before trying out this code, as it appear to work for R 4.2 and later, though not 4.1.

Comments closed

Writing Tests with shinytest2

Russ Hyde continues a series on shinytest2:

Here, we will write a simple shiny app (as an R package) and show how to generate tests for this app using {shinytest2}. As discussed in the previous post, {shinytest2} tests your app as if a user was interacting with it in their browser. The tests generated are application-focussed rather than component-focussed and so give some overall guarantees on how the app should behave.

This post is slightly more technical than the last, and assumes that the reader is comfortable with creating and unit-testing packages in R, and with shiny development in general.

Click through to see the code, as well as plenty of explanation.

Comments closed

Ways to Convert a List to DataFrame in R

Tomaz Kastrun starts the stopwatch:

When you are working with large datasets performance comes to everyone’s mind. Especially when converting datasets from one data type to another. And choosing the right method can make a huge difference.

So in this case, I will be creating a dummy list, and I will convert the values in the list into data.frame.

Click through for a variety of techniques and how well they performed. There are some good solutions in the comments as well.

Comments closed

End-to-End Testing via shinytest2

Russ Hyde begins a new series:

{shinytest2} builds upon the {shinytest} package and was written by Barret Schloerke and his colleagues at RStudio. Like puppeteer, {shinytest2} uses the Chrome DevTools Protocol to interact with the browser, which is a pretty stable basis for building a browser automation tool (the predecessor {shinytest} was built on a now-unsupported browser library called PhantomJS, so we strongly recommend migrating to {shinytest2} if you are still using {shinytest}). Test scripts are written in R and so should be accessible to R developers who are comfortable with {testthat}. There is an automated tool (described in the next post) for creating these test scripts. Also, {shinytest2} understands the architecture of shiny apps, and so it is simple to access the input and output variables that are stored by a shiny app at any given time, the inputs can be modified easily as well – to access these variables using the more general UI-based end-to-end testing tools is much more difficult.

Read on for the “why” behind this series and the next posts will get into more of the “how.”

Comments closed