A Fine Slice Of SQL Server
Steven P. Sanderson provides an overview of an R package:
If you’re looking for an easy-to-use package to calculate cumulative statistics in R, you may want to check out the TidyDensity package. This package offers several functions to calculate cumulative measurements, including mean, median, standard deviation, variance, skewness, kurtosis, harmonic mean, and geometric mean.
Click through for a quick description of each function, as well as examples of each. H/T R-Bloggers.
Comments closedJohn MacKintosh troubleshoots an issue:
I recently updated my R installation, and then realised that I’d broken my VSCode/ R set up in the process – I could not launch an R terminal either directly or via radian.
I have a repo where I’ve collated various blog posts relating to setting up VSCode for R, but that didn’t solve all my problems.
I did get it resolved eventually, and here’s how.
Read on for that resolution. H/T R-Bloggers.
Comments closedKeeping your R code organised is not as straightforward as one might think. Just think about the libraries, variables, functions, and many more. All these objects can be defined and later rewritten, some might get obsolete during the process.
This process is proven to be even more crucial when you are part of a larger group of engineers, and scientists, who collaborate with you.
Click through for some organizational tips specific to R code.
Comments closedNeil 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 closedAn 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 closedTim 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 closedNicola 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 closedRuss 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 closedSebastian Sauer compares all values across a row:
Sometimes is is neccessary to compute functions, such as mean values, rowwise, ie., summing the values for multiple variables (
my_vars) for each observation.
It’s actually pretty easy, and applies to functions other than mean(). Click through for a demonstration.
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 writinghead(iris). It helps to avoid long function chains likef(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.