What makes rOpenSci’s software peer review work is people who care deeply about the quality and usability of scientific software, and who give their time and expertise to help others build it better. Today, we’re pleased to announce three new members of our editorial team.

We welcome Joel H. Nitta, and Nicholas Tierney as new editors, and formally introduce Ronny Hernández Mora, who joined the editorial team in August 2025. Each brings a distinct perspective shaped by their work, their communities, and their experience with open-source R development. Together, they strengthen our capacity to serve the growing number of package authors who submit their work for review, and to uphold the collaborative, friendly and transparent standards that rOpenSci software peer review is known for.

Ronny Hernández Mora

Ronny is a PhD student at the University of Alberta and a research software developer with a background in data analysis and remote sensing. His current research explores how perception-driven drone systems can support detection, monitoring, and decision making in real world settings.

Before starting his PhD, Ronny worked as a data developer at ixpantia, developing data tools, automation pipelines, APIs, and production analytical applications for organizations across Latin America and the United States. Alongside his PhD, he works with Openscapes and contributes to opensource communities through teaching, mentorship, talks, and collaborative software projects.

Ronny on GitHub, Website.

I first heard about rOpenSci through a Data Latam podcast episode, and from there I started following the organization and its work. Over time, I got to know people connected to the community, but it was not until 2024 that I became directly involved by volunteering as a package reviewer.

I have always liked the idea of building software collaboratively: creating tools that can be understood, reviewed, reused, and improved by others. That is one of the things I value most about rOpenSci: the way it combines technical review with openness, care, and constructive feedback. I am grateful for the opportunity to contribute as an editor and to support authors and reviewers through that process and continue learning through this community effort.

Joel H. Nitta

Joel is currently an associate professor at Chiba University, Japan, where he studies the evolution and ecology of ferns. Throughout his career as a botanist, he has also cultivated a keen interest in reproducible data analysis and has authored several R packages. Two of these are currently part of rOpenSci, canaper for spatial phylogenetic analysis, and dwctaxon for validation and maintenance of taxonomic databases. He is also an official maintainer of two rOpenSci packages, rgnparser for parsing taxonomic names, and restez for querying the GenBank DNA database. Outside of rOpenSci, Joel is active in the Bio”Pack”athon community in Japan, serves on the organizing committee of the Pteridophyte Phylogeny Group, and is a certified instructor for The Carpentries. Joel’s hobbies include various forms of being active outside (hiking, running, backpacking, botanizing, cycling), playing the euphonium, and tabletop games.

Joel on GitHub, Website.

rOpenSci has been incredibly important in my journey with data science and R. Above all, the extremely knowledgeable and helpful rOpenSci community has provided invaluable support as I transitioned from “R package user” to “R package developer”. While it may be possible to do this on your own, it is much more enjoyable and efficient when you are in the company of like-minded people. I especially appreciate this because I did not study computer science in undergrad and I am largely self-taught when it comes to R, having first learned it out of necessity during my graduate studies. I am very excited to officially join the editorial team and have the opportunity to give back to the organization that has supported me so much.

Nicholas Tierney

Nicholas (Nick) Tierney is a statistician, Research Software Engineer, and freelance consultant with a PhD in Statistics who specialises in data analytics, R package development, and teaching. Previously, he worked with Professor Nick Golding at The Kids Research Institute Australia and was a Research Fellow at Monash University with Professor Dianne Cook, where he developed tools for exploratory data analysis including visdat, naniar, and brolgar. Nick actively writes about R related projects at his blog, “credibly curious”. When not coding, Nick enjoys outdoor adventures and hiked the entire Pacific Crest Trail in 2023, documenting his journey at njt.micro.blog.

Nick on GitHub, Website.

I remember seeing rOpenSci online in 2014, at their first rOpenSci hackathon in San Francisco, USA. I was inspired by not just the projects they worked on, but the collective of people who were kind and generous as much as they were brilliant. I helped run an offshoot of the rOpenSci Unconf in Australia, which ran in 2016, 2017, 2018, and 2019. I received amazing mentorship and support from Karthik Ram and Stefanie Butland in learning how to run these unconferences. I think these have had a lasting impact on connecting people from Australia and New Zealand.

I had my R package, visdat, reviewed by rOpenSci in 2017, and this experience was formative to my understanding of software review, and greatly improved my own day to day practice. In 2024, with Eric Scott, and Andrew Brown, we submitted the geotargets package to rOpenSci.

rOpenSci has always been at the forefront of building a community of practice, and their model of peer review is a gold standard. Science would be better if more journals practised such transparency and kindness. It is an enormous honour to be able to give back to a community that has been so formative in my career and my life.

About the Software Peer Review Program

rOpenSci’s software peer review program brings together volunteers to collaboratively review scientific and statistical software according to transparent, constructive, and open standards. We have two different type of review: one for general research software packages and another for package that implement statistical methods. Editors like Ronny, Joel, and Nick are central to that process: they handle initial submission checks, identify and coordinate reviewers, and guide authors through the review until their package is ready.

Get Involved

Thinking about submitting a package? Start here:

• rOpenSci Software Peer Review: scope, process, and guidelines;
• rOpenSci Packages: Development, Maintenance, and Peer Review: the full guide for package authors;
• rOpenSci Statistical Software Peer Review: the full guide for statistical software submissions;
• Public software review threads on GitHub: see software peer review in action.

Would you like to contribute as a reviewer? We’d love to have you. Fill out the rOpenSci Reviewer Sign-Up Form and we’ll match you with packages that fit your expertise.

A warm welcome to Ronny, Joel, and Nick! We’re very glad to have you with us.

Read it in: .

We are very happy to introduce the new rOpenSci Champions. This group will experience the program and work in Spanish, allowing us to continue to strengthen the open science and research software development community in this language. We are excited about the projects they will develop, which address real challenges from different disciplines and territories in Latin America.

We invite you to meet each of these people and the projects they will be working on throughout the program.

Bastián Olea Herrera

My name is Bastián, I live in Chile, I am a sociologist by training and I have a Master’s degree in sociology. I like to create content and tutorials about R, and recently we are organizing a community of R users in Santiago, where I live. I am dedicated to data analysis in the public sector, where I work mainly with social data at different territorial levels. This kind of data always needs the same types of cleaning and corrections, but at the same time they usually vary a lot in small details between each source. That is why I applied to the program to develop a package that facilitates working with data at the communal and regional level in Chile. I hope to meet other R users and learn together, as well as receive support from people with more experience and knowledge, so that we can create useful tools for many people!

Denisse Fierro Arcos

My name is Denisse Fierro Arcos, I am a marine scientist originally from Ecuador but currently living in Australia. At the moment I am close to finishing my PhD program which focuses on developing best practices for the use of oceanographic models in marine ecosystem studies. I am also currently working as a researcher at the University of Tasmania where I am developing a marine ecosystem model that will allow us to project the possible impacts of climate change on marine species and fisheries. It is precisely this model that is the focus of my project with the Champions Program. We want to publish a package in R that will allow other marine researchers to easily run our model.

Durga Valentina Linares Herrera

Hello! My name is Durga Valentina Linares Herrera and I live in Lima, Peru. I am a social scientist, with a degree in Political Science from the Universidad Antonio Ruiz de Montoya and a diploma in Data Science for Social Sciences and Public Management from the Pontificia Universidad Católica del Perú. I work as a research assistant at the Research Center of the Universidad del Pacífico, where I explore the intersection between technology and work from a sociological perspective and with mixed methodologies. My current projects revolve around the Peruvian labor market and its exposure to artificial intelligence, and the evolution of the strike as a social phenomenon in Peru in the last three decades.

For the program I presented as a project {epen}, an R package to download, process, and analyze microdata from the Permanent National Employment Survey and its predecessor, the Lima EPE. This idea was born from my experience working directly with these databases. I could see how difficult it can be to access public labor data in a fast, clear, and reproducible way, especially for those of us who come from the social sciences and do not always come to these tools with a previous technical background, as was also my case. With this package, I seek to facilitate that path for researchers, students, and public sector analysts who need to build reliable labor indicators without having to start from scratch each time, something I find especially relevant in this time of so many changes.

In recent years, with the intention of developing new skills in a context where technology is quickly advancing, I moved towards a more quantitative approach and learned to program in a self-taught way with free resources on the internet. That process has been important for my professional development, but it also made me want to turn that learning into something useful for other people: a tool to help reduce the entry barriers that I myself encountered when I started. That’s how the motivation behind this package came about, and this Champions Program appeared just at the right time. I am excited to participate in an initiative like this and to be part of a network like rOpenSci, whose commitment to a more diverse and inclusive open science seems very valuable to me. I hope that this experience will allow me to consolidate in community a path that I once started on my own and pave the way for future packages aimed at improving access to Peruvian public data in R.

Evelia Lorena Coss Navarrete

I am a Biotechnology Engineer from the Polytechnic University of Sinaloa (UPSIN), originally from Mazatlan, and I did my Master’s and PhD in Plant Biotechnology at Cinvestav, where I studied the conservation of lncRNAs in plants.

My participation in the rOpenSci Champions Program seeks to strengthen communities such as VieRnes de Bioinformatics, R-Ladies Morelia and RSG-Mexico, promoting the creation of R packages with international standards, reproducible documentation and open review. My vision is to bridge the gap between the global rOpenSci community and local initiatives in Latin America, promoting a more open, inclusive and sustainable science.

Gladys Choque Ulloa

Hello! My name is Gladys Choque Ulloa, I am originally from Peru and currently reside in Brazil. I have a degree in Statistics, a Master’s in Statistics, and I am currently pursuing my PhD in Computer Science at the ICMC-USP of the University of São Paulo, Brazil. There, I am developing research in computational neuroscience focused on the automatic diagnosis of mental disorders, using Machine Learning models, Neural Networks, LLMs, Causal Inference, and Time Series. In addition to my academic work, I am founder of the organization Women in DataLab, where I work to reduce the gender gap in technology and data science.

I applied to the rOpenSci Champions Program because I strongly believe in the power of open science and reproducible software to democratize knowledge. During the program, my goal is to hone my skills in developing R tools and scientific software under global standards. With this experience I want to strengthen my technical profile and act as a bridge for more researchers in Latin America to adopt collaborative and open practices, enhancing the impact of our scientific community internationally.

José Daniel Conejeros Pavez

I am José Daniel Conejeros, MSc in Statistics from the Pontificia Universidad Católica de Chile. I am originally from Chile and currently develop my work between Chile and Italy. In Italy I work as a Lagrange Fellow at the ISI Foundation and as a young researcher at the SENTINET Center (Surveillance, epidemiology and new technologies for emerging infectious threats), working on issues of data science, complex systems, and public health.

My work is situated at the intersection of statistics, epidemiology, and computational social science to understand infectious disease dynamics and health outcomes for different populations. Currently, I am developing spatmask, an R package oriented to the masking and anonymization of spatial data (geomasking), with the goal of enabling reproducible analyses without compromising the privacy of individuals. This project aims to bridge the gap between the use of sensitive data for research and the ethical and regulatory restrictions that limit its access and use.

I decided to apply to the Champions Program because many of the challenges I face are not only technical, but also organizational and cultural. I want to understand how to develop scientific software collaboratively, how to document it correctly and how to foster reproducible practices in contexts where open science is not yet fully installed. I am interested in learning how to build tools that not only work, but that are understandable, auditable, and useful for research teams and Public Policy decision makers.

Through this program, I hope to strengthen my skills in scientific software development, open review and collaborative work. My goal is to translate this learning into concrete transfer: training, collaboration, and community building around open science in the region.

Linda Cabrera Orellana

Hello! My name is Linda, I am Ecuadorian and currently reside in Granada, Spain. I work as a Senior Data Analyst in a digital marketing agency and I share my experience as a teacher in business schools, where I teach classes on AI applied to analytics and data visualization.

My project consists of developing an R package with an educational approach to detect, explain, and help correct common structural errors in manually created datasets, specially designed for people with no technical background in data. I am applying to the program because I want to turn my practical and teaching experience into a real contribution to the open scientific software ecosystem, and to strengthen my skills in R package design, documentation, and maintenance.

I also hope that the project will serve as an educational resource in universities in Ecuador and in the R-Ladies community, and that it will build a bridge between those who collect data and those who analyze it, promoting data literacy in Spanish.

María Florencia Tames

My name is María Florencia Tames, I am a professor at the National University of Córdoba (Argentina) and I work in research in the area of air quality, exposure to air pollutants and environmental inequalities in urban contexts in Latin America.

With a team I developed the AirExposure R package, a tool for estimating daily exposure to air pollutants by integrating information on ambient concentrations, mobility, and daily routines. Through the rOpenSci Champions Program, my goal is to improve and consolidate this package as an open, reproducible and accessible tool for the community.

I am especially interested in strengthening my skills in open software development, incorporating best practices such as documentation, testing, and peer review, and learning to build tools that can be used beyond their original research context.

I am also motivated by the program’s focus on community and working in Spanish, as access to programming resources and training is often limited by language. I hope to be able to share what I have learned through training activities and contribute to the development of an open scientific software community in Latin America.

Marina Cecilia Cock

I am from Santa Rosa, La Pampa, Argentina. I have a degree in Natural Resources and Environment Engineering from the National University of La Pampa (UNLPam) and a PhD in Agrarian Sciences with orientation in Ecology from the University of Buenos Aires (UBA).

I am currently working as a research assistant at the National Council of Scientific and Technical Research (CONICET) and as a teaching assistant in Biogeography and Statistics at the National University of La Pampa.

I applied to the program to learn about the R package review process. I am interested in participating because I find it especially valuable to join a community where learning is shared and collaborative. I am looking to strengthen my knowledge in R and then be able to transmit it both in my teaching role and within the R community.

Patricia Andrea Loto

I have a degree in Information Systems and a Diploma in Data Science, Machine Learning and its Applications. I am currently pursuing a Master’s Degree in Information Technology at the Universidad Nacional del Nordeste. I live and work in Argentina.

I work as a software developer and data analyst in the public sector, and as a university teacher in the area of systems and programming. I am a co-founder of RSE Argentina, member of the organizing committee of LatinR, and co-organizer of R-Ladies Resistencia-Corrientes. From these spaces I work to promote open science, reproducible research software and technology inclusion in Latin America.

In the 2026 cohort I am participating as mentee with the guidance of Guadalupe Pascal. My project is an R package to systematize the creation of Software and Data Management Plans through standardized templates developed with Quarto, which facilitate the documentation, preservation, and reuse of data and scientific code under international open science standards.

I applied to the Champions Program because I see it as a bridge: between where I am technically and where I want to be. I hope to learn about the rOpenSci peer review process, deepen my understanding of testing, technical documentation, and everything that makes a package really useful to others. I’m also looking to connect with a network of developers and researchers who share open science values. Finally, I want research software developed from the Global South to have greater visibility and for our contributions to be recognized, and I think rOpenSci is the ideal platform for that.

Estefania Torrejón

I am Peruvian and a biologist graduate from the Universidad Nacional Mayor de San Marcos (UNMSM), with a Master’s degree in Biomedical Sciences from the Institute of Hygiene and Tropical Medicine (IHMT) in Lisbon, Portugal. I currently reside in Portugal, where I work as a predoctoral researcher in bioinformatics at the Metabolic Diseases Research Lab of NOVA Medical School. I am also director of the International Relations Department of the Peruvian Society of Bioinformatics and Computational Biology.

The project I am developing in the framework of the rOpenSci Champions Program consists of the preparation and submission of my R package, EV-Net, to the CRAN repository. EV-Net is a bioinformatics tool that identifies and prioritizes molecules present in the cargo of extracellular vesicles (EVs) with high regulatory potential on a receptor tissue of interest. EVs are structures surrounded by a lipid bilayer that carry a great diversity of active molecules. These vesicles can move through the organism and reach specific tissues, which is why they are recognized as key mediators of cell-to-cell communication (CCC). However, most of the bioinformatics tools available to study CCC do not consider EV-mediated communication. To address this limitation, my collaborators, supervisors, and I developed EV-Net.

Being an rOpenSci Champion is an invaluable opportunity to receive the necessary training, coaching and mentoring to bring EV-Net up to the required quality standards and to be successfully incorporated into CRAN.

Next steps

With the presentation of this new group of Champeons, we begin the fourth edition of the program, the second in Spanish. This group has already started the training stage and met their mentors. They will be working for 12 months developing new packages, preparing existing packages to submit to the peer review process, and reviewing other people’s packages.

If you want to follow the development of their projects and where and when their dissemination and communication activities will take place, don’t miss our blog articles, news in our newsletter and social networks.

Stanislaw Ulam, Los Alamos, 1963 was bored in a meeting and he started dooddling integers in a spiral and circled the primes. Diagonal lines appeared. He later showed it to Martin Gardner, to Ulam surprise, Gardner published his findings in Scientific American. We are still confused to this day.

But Ulam was not doodling some little houses or boats, or cars like a normal person. No. He wrote numbers in a spiral. Then circled all the prime numbers. Then stared at what he had created with the dawning horror of a man who has seen too much.

So where does the spiral comes from? Start with 1 in the middle. Write the number in a spiral outward. And then highlight all the prime numbers. If you draw long enough diagonal lines will appear.

Primary function has initial position and directions calculated, in order to have the symmetry of the plot.

ulam_prime_spiral <- function(
    n         = 51,    
    theme     = c("Cosmic","Blueish","Classy","Psycho"),
    show_nums = FALSE,   # print values (n ≤ 21 only)
    animate   = FALSE,       
    speed     = 1,          
    verbose   = TRUE
) {
  
  theme <- match.arg(theme)
  
  #n must be odd so integers have a unique centre cell 
  if (n %% 2 == 0) { n <- n + 1L }
  if (n < 5) stop("Size muste be > 5.")
  total <- n^2
  mid   <- (n + 1L) / 2L            
  
  dr <- c( 0L, -1L,  0L,  1L)   # row deltas:  E  N  W  S
  dc <- c( 1L,  0L, -1L,  0L)   # col deltas:  E  N  W  S
  
  mat   <- matrix(0L, n, n)     
  ord_r <- integer(total)        
  ord_c <- integer(total)        
  
  r <- mid;  
  cc <- mid  
  
  mat[r, cc] <- 1L
  ord_r[1]   <- r
  ord_c[1]   <- cc
  
  d    <- 1L  # current direction index (1=E 2=N 3=W 4=S)
  step <- 1L  # current arm length
  num  <- 2L                     
  
  while (num <= total) {
    for (half in 1:2) {          # each dir is twice 
      for (i in seq_len(step)) {
        r  <- r  + dr[d]
        cc <- cc + dc[d]
        mat[r, cc] <- num
        ord_r[num] <- r
        ord_c[num] <- cc
        num <- num + 1L
        if (num > total) break  
      }
      d <- (d %% 4L) + 1L       # turn left: E→N→W→S→E
      if (num > total) break    
    }
    step <- step + 1L            
  }
  

and we determine the prime:

# Sieve of Eratosthenes   
  is_prime    <- rep(TRUE, total)
  is_prime[1] <- FALSE
  p <- 2L
  while (p * p <= total) {
    if (is_prime[p])
      is_prime[seq.int(p * p, total, p)] <- FALSE
    p <- p + 1L
  }

  prime_mat <- matrix(is_prime[mat], n, n)
  n_primes  <- sum(prime_mat)
  density   <- 100 * n_primes / total

With for type of visuals (Classy, Psycho, Blueish and Cosmic), if you decide to create a grid smaller than 21×21, you can have also the numbers displayed. And of course, the diagonals are visible as well:

As always, the complete code is available on GitHub in  Useless_R_function repository. The complete version of code is here: https://github.com/tomaztk/Useless_R_functions/blob/main/functions/ulam_spiral.R

Check the repository for future updates!

Stay healthy and happy R-coding!

Back to basics! Learning non-polar amino acids, what zwitterions actually are, and dipping into the applied math — Rodrigues rotation and Lennard-Jones potential. Slowly building toward optimal phi/psi!

Motivations

We’ve explored quite a bit lately in molecular dynamic simulation and then protein-protein docking as well the last time. There is still so much to learn. I’ve decided to go back to basics, revisiting our old friends amino acids and try to understand the natural properties behind each one and see if that will make more sense in the future when we’re exploring more. While making notes for myself of all the amino acids, I’ll also try to understand some of the basic math behind the structures. Are you ready !? Lol, I’m not, but let’s go anyway!

Objectives:

• Amino Acids
  • Non-polar
• Rodriguez Rotation Formula
• Lennard-Jone Potential Enegery
  • Bond Stretch
  • Bond Angle
  • Proper dihedral
  • Non-bonded
  • Calculating LJ
• Opportunities For Improvement
• Lessons Learnt

Amino Acids

Amino acids are the building blocks of proteins, each sharing a common backbone: a central α-carbon bonded to an amino group (–NH₂), a carboxyl group (–COOH), a hydrogen atom, and a variable side chain (R group) that defines each amino acid’s identity and chemistry.

Non-polar amino acids

Non-polar amino acids have hydrophobic side chains — they avoid water and tend to cluster in the interior of folded proteins, forming the hydrophobic core that drives protein stability. Understanding each one’s shape and bulk is directly relevant to how they pack, how they constrain backbone flexibility, and how substitutions affect enzyme active sites.

library(tibble)
library(kableExtra)

aa_nonpolar <- tribble(
  ~aa,  ~aa3,  ~name,           ~functional_group,  ~smiles_sidechain,    ~charge_ph7, ~mw_da, ~pka,     ~md_note,                                                                                ~main_function,
  "G",  "Gly", "Glycine",       "H (none)",         "[H]",                "Neutral",   75.03,  NA_real_, "Minimal VDW radius; unrestricted phi/psi; near-zero excluded volume",                  "Conformational flexibility; tight turns; active site geometry",
  "A",  "Ala", "Alanine",       "Methyl",           "C",                  "Neutral",   89.09,  NA_real_, "Low steric perturbation; high alpha-helix propensity in force fields",                 "Helix former; hydrophobic core; alanine-scanning mutagenesis",
  "V",  "Val", "Valine",        "Isopropyl",        "CC(C)",              "Neutral",   117.15, NA_real_, "Beta-branching restricts psi; favors extended beta-sheet; large gamma-carbons",        "Beta-sheet core; hydrophobic packing; sickle-cell HbS Glu6Val",
  "L",  "Leu", "Leucine",       "Isobutyl",         "CCC(C)C",            "Neutral",   131.17, NA_real_, "Flexible chi2; common rotamers at -65/-65 and -65/175; high hydrophobic SASA",         "Hydrophobic core; leucine zippers; most abundant non-polar in proteomes",
  "I",  "Ile", "Isoleucine",    "sec-Butyl",        "CCC(C)",             "Neutral",   131.17, NA_real_, "Beta-branching + gamma-branch; most restricted chi1/chi2; large buried SASA",          "Hydrophobic core; beta-barrel interiors; transmembrane helices",
  "P",  "Pro", "Proline",       "Pyrrolidine ring", "C1CCNC1",             "Neutral",   115.13, NA_real_, "Fixed phi ~-60; no backbone NH donor; cis/trans isomerism at Xaa-Pro bond",            "Helix breaker; beta-turns; collagen Gly-Pro-X repeats",
  "F",  "Phe", "Phenylalanine", "Benzyl",           "Cc1ccccc1",          "Neutral",   165.19, NA_real_, "Rigid aromatic ring; pi-pi stacking and cation-pi in MD energy decomposition",         "Hydrophobic core; aromatic clusters; ligand binding pockets",
  "W",  "Trp", "Tryptophan",    "Indolylmethyl",    "Cc1c[nH]c2ccccc12", "Neutral",   204.23, NA_real_, "Indole NH can H-bond; amphipathic at membrane interface; strong 280nm absorbance",     "Membrane anchoring; fluorescence probe; ligand binding; rarest standard AA",
  "M",  "Met", "Methionine",    "Thioether",        "CCSC",               "Neutral",   149.20, NA_real_, "Flexible sulfur geometry; oxidizable to sulfoxide in long MD runs; check reactive FF", "Translation initiation; hydrophobic core; redox sensing"
)

aa_nonpolar |>
  dplyr::select(aa:mw_da) |>
  kbl()

aa_nonpolar |>
  dplyr::select(aa,aa3,md_note,main_function) |>
  kbl()

Claude generated most of the above information. We’ll add onto the md_note section as we encounter certain things during our MD sims.

What’s Zwitterion?

A zwitterion is a molecule that has both positive and negative charges but is overall electrically neutral. In amino acids, the amino group (–NH₂) can accept a proton to become positively charged (–NH₃⁺), while the carboxyl group (–COOH) can lose a proton to become negatively charged (–COO⁻). At physiological pH (~7.4), most amino acids exist as zwitterions, with the amino group protonated and the carboxyl group deprotonated. This dual charge allows amino acids to interact with both polar and non-polar environments, contributing to their solubility in water and their ability to form various interactions in proteins.

What Does Non-polar Actually Mean?

It is worth clarifying what “non-polar” actually refers exclusively to the side chain (R group) — specifically that it consists largely of carbon and hydrogen bonds with no net dipole and no ionizable groups, making it hydrophobic and largely indifferent to water. It says nothing about the backbone, which is the same for all amino acids and always carries polar bonds (C=O, N–H). In fact, as mentioned above, all amino acids including non-polar ones exist as zwitterions at physiological pH — a property that comes entirely from the backbone, not the side chain.

Note to self: All amino acids’ backbones are zwitterions; the R-side chain determines polarity and hydrophobicity. Also, net charge neutral == overall charges equals zero, does not mean the molecule is non-polar.

Rodriguez Rotation Formula

Rodrigues’ rotation formula is a method for rotating a 3D vector in space around a specified axis by a given angle. The formula is expressed as:

\(v_{rotation} = v.\cos(\theta) + \sin(\theta)(k \times v) + (1 - \cos(\theta))(k(k \cdot v))\)

where v is the original vector, k is the unit vector along the axis of rotation, and θ is the angle of rotation in radians.

This formula apparently is very popular in computer graphics and robotics, but I can see how it can be useful in molecular dynamics as well when we want to rotate a molecule or a part of it around an axis. Especially when we want to estimate the least energy conformation of a molecule. The direction application of this formula in amino acid sequence would be in rearranging the atoms based on phi and psi which are the angles of rotations around the N-Cα and Cα-C bonds of the amino acid backbone, respectively. By applying Rodrigues’ rotation formula, we can calculate the new positions of the atoms in the amino acid after rotating them by the specified angles, allowing us to explore different conformations of the molecule. How I remember which angle is which is Nancy Phi (sounds like some detective show and also N->C) and C C Psi (All with S sound, also Carbon to carbon). We’ll leave the hand calculation until next time, but let’s learn how to rotate a coordinate based on an axis with Rodriguez!

Below I’ll write the code first, then explain. Please feel free to use your mouse to hover over the plotly object and check out the coordinates.

library(plotly)
library(pracma)

#### Let's start simple
x1 <- c(0,0,0)
x2 <- c(1,1,1)
x3 <- c(1,2,1)

rodrigues <- function(v, k, theta) {
  k <- k / sqrt(sum(k^2))
  cos(theta)*v + sin(theta)*pracma::cross(k, v) + (1 - cos(theta))*sum(k*v)*k
}

k <- x2 - x1
v <- x3 - x1

result <- rodrigues(v,k,pi/2) #notice this, pi/2 == 90 degrees

pts <- data.frame(
  x = c(x1[1],x2[1],x3[1]),
  y = c(x1[2],x2[2],x3[2]),
  z = c(x1[3],x2[3],x3[3]),
  label = c("x1","x2","x3")
)

pts_rs <- data.frame(
  x = c(x1[1],x2[1],result[1]),
  y = c(x1[2],x2[2],result[2]),
  z = c(x1[3],x2[3],result[3]),
  label = c("x1","x2","x3_new")
)

plot_ly() |>
  add_trace(data=pts, x=~x, y=~y, z=~z,
            type="scatter3d", mode="lines+markers+text",
            text=~label,
            marker=list(size=8, color="blue", opacity=0.5),
            line=list(width=4, color="blue", dash="solid")) |>
  add_trace(data=pts_rs, x=~x, y=~y, z=~z,
            type="scatter3d", mode="lines+markers+text",
            text=~label,
            marker=list(size=8, color="red", opacity=0.5),
            line=list(width=4, color="red", dash="dash"))

So with the above, we want to start off with 3 points, x1, x2, x3. they all represent their xyz coordinates.

Funny thing is, xyz coordinate here is different from what I learnt xyz as. I’ve always thought x is horizontal, y is vertical and z is depth. But in this case, x is depth, y is horizontal and z is vertical. I guess it depends on how you look at it.

Then we want to rotate x3 around the axis defined by x1 and x2 by 90 degrees (pi/2 radians). The rodrigues function takes in the vector v (which is the vector from x1 to x3), the axis k (which is the vector from x1 to x2), and the angle theta (which is pi/2). It returns the new coordinates of x3 after rotation.

Finally, we plot the original points and the rotated point using plotly. The original points are in blue, and the rotated point is in red. You can hover over the points to see their coordinates.

Now if we were to maneuver the 3d plot and align both x1 and x2 into a dot, we can clearly see that it moved 90 degrees anti-clockwise!

Now there is a pretty cool rule to know where the rotation should occur anti-clockwise vs clockwise is by using your hand !!! Remember this from high school?

It would be really cool to derive the above formula. There are a lot of videos that have done this. I’m still trying to conceptualize it, let’s leave that for another blog! It sounds interesting and may be a good exercise, especially when we’re venturing into 3d spaces.

Lennard-Jones Potential Energy

The Lennard-Jones potential energy formula is a mathematical model used to describe the interaction between a pair of neutral atoms or molecules. It is given by the equation:

\(V(r) = 4\epsilon \left[ \left( \frac{\sigma}{r} \right)^{12} - \left( \frac{\sigma}{r} \right)^6 \right]\)

Where:

• \(V(r)\) is the potential energy as a function of the distance \(r\) between the two particles.
• \(\epsilon\) is the depth of the potential well, representing the strength of the attractive interaction.
• \(\sigma\) is the finite distance at which the inter-particle potential is zero, representing the effective diameter of the particles.
• The term \(\left( \frac{\sigma}{r} \right)^{12}\) represents the repulsive part of the potential, which dominates at short distances due to the Pauli exclusion principle.
• The term \(\left( \frac{\sigma}{r} \right)^6\) represents the attractive part of the potential, which dominates at longer distances due to van der Waals forces.

The Lennard-Jones potential is widely used in molecular dynamics simulations to model the interactions between non-bonded atoms or molecules, particularly in the context of van der Waals forces. It helps to predict the behavior of particles in a system, such as their equilibrium positions and the energy landscape of molecular interactions.

Wow there are a bunch of terms and word above! I’m getting dizzy just to keep track of what is what. Let’s push through this. To use the above formula, we’d have to have some understanding of the parameters epsilon and sigma. These parameters are typically derived from experimental data or quantum mechanical calculations and are specific to the types of atoms or molecules involved in the interaction. Where to get these parameters? Here you go – openbabel:: gaff.dat

When you opened gaff.dat there are bunch of numbers! Let’s find the numbers that are meaningful for us. All the below are separated by new lines as you scroll down.

Bond Stretch

The column names should be: type mass(g/mol) polarizability(ų) source

Bond Angle

The column names should be: types K r0 source count rmsd

Proper Dihedral

The column names should be: types div barrier phase periodicity

Non-bonded

The column names should be: type R*(Å) ε(kcal/mol)

We are purely interested in the non-bonded section where R* is our sigma = R* × 2 / 2^(1/6) and ε is our epsilon. With the above parameters, we can then calculate the Lennard-Jones potential energy between any two atoms in a molecule. Let’s do a simple calculation for ethanol.

Calculating LJ

library(tidyverse)
library(igraph)
# Coordinates (x, y, z) in Angstroms, according to pubchem ethanol molecule
coords <- rbind(
  O   = c( -1.1712,   0.2997,   0.0000),
  C2  = c( -0.0463,  -0.5665,   0.0000),
  C1  = c(  1.2175,   0.2668,   0.0000),
  H4  = c( -0.0958,  -1.2120,   0.8819),
  H5  = c( -0.0952,  -1.1938,  -0.8946),
  H1  = c(  2.1050,  -0.3720,  -0.0177),
  H2  = c(  1.2426,   0.9307,  -0.8704),
  H3  = c(  1.2616,   0.9052,   0.8886),
  H6  = c( -1.1291,   0.8364,   0.8099)
)

# AMBER GAFF parameters (sigma Å, epsilon kcal/mol)
Rstar_to_sigma <- function(Rstar) 2 * Rstar / 2^(1/6)

sigma <- c(
  C1=Rstar_to_sigma(1.9080), C2=Rstar_to_sigma(1.9080),
  O=Rstar_to_sigma(1.7210),
  H1=Rstar_to_sigma(1.4870), H2=Rstar_to_sigma(1.4870),
  H3=Rstar_to_sigma(1.4870), H4=Rstar_to_sigma(1.4870),
  H5=Rstar_to_sigma(1.4870), H6=0.0000
)

epsilon <- c(
  C1=0.1094, C2=0.1094, O=0.2104,
  H1=0.0157, H2=0.0157, H3=0.0157,
  H4=0.0157, H5=0.0157, H6=0.0000
)

# Bonds 
bonds <- tribble(
  ~from, ~to,
  "C1", "C2",
  "C2", "O",
  "O", "H6",
  "C1", "H1",
  "C1", "H2",
  "C1", "H3",
  "C2", "H4",
  "C2", "H5"
)

# count bonds between two atoms
g <- graph_from_data_frame(bonds, directed = FALSE)
g_dist <- distances(g)

# LJ function
lj <- function(r, eps, sig) 4 * eps * ((sig/r)^12 - (sig/r)^6)

# Loop all pairs
atoms <- rownames(coords)
pairs <- combn(atoms, 2, simplify=FALSE) # combn so we don't repeat
total_V <- vector(mode = "numeric", length = length(pairs)) 
 
for (i in 1:length(pairs)) {
  
  # each pair
  p <- pairs[[i]]
  from <- p[1]
  to <- p[2]
  num_bond <- g_dist[from, to]
  
  if (num_bond <= 2) next                   
  
  # params needed for LJ
  r   <- sqrt(sum((coords[from,] - coords[to,])^2))
  sig <- (sigma[from] + sigma[to]) / 2
  eps <- sqrt(epsilon[from] * epsilon[to])
  
  # scale if num bond is 3 (4 atoms)
  scale <- if (num_bond == 3) 0.5 else 1.0
  
  # LJ calc
  V <- scale * lj(r, eps, sig)

  cat(from, "-", to, " num of bonds=", num_bond, " r=", r, " V=", V, "\n")
  total_V[i] <- V
}

## O - H1  num of bonds= 3  r= 3.344395  V= -0.02733269 
## O - H2  num of bonds= 3  r= 2.642383  V= 0.110613 
## O - H3  num of bonds= 3  r= 2.659841  V= 0.09535471 
## C1 - H6  num of bonds= 3  r= 2.546942  V= 0 
## H4 - H1  num of bonds= 3  r= 2.521587  V= 0.01461147 
## H4 - H2  num of bonds= 3  r= 3.074579  V= -0.007593085 
## H4 - H3  num of bonds= 3  r= 2.514978  V= 0.01576022 
## H4 - H6  num of bonds= 3  r= 2.295394  V= 0 
## H5 - H1  num of bonds= 3  r= 2.507028  V= 0.01720963 
## H5 - H2  num of bonds= 3  r= 2.510736  V= 0.01652426 
## H5 - H3  num of bonds= 3  r= 3.070262  V= -0.007612401 
## H5 - H6  num of bonds= 3  r= 2.845344  V= 0 
## H1 - H6  num of bonds= 4  r= 3.550289  V= 0 
## H2 - H6  num of bonds= 4  r= 2.908137  V= 0 
## H3 - H6  num of bonds= 4  r= 2.392984  V= 0

cat("\nTotal V_LJ:", sum(total_V), "kcal/mol\n")

## 
## Total V_LJ: 0.2275351 kcal/mol

Alright, the above we basically were trying to calculate all pairwise atoms that is more than 3 bonds (if it’s exactly 3 bonds, we scale it by half). Alright, now that we know how to do that on simple molecular, next time we can use this to minimize on as we’re seeking optimal phi and psi!

Opportunities For Improvement

• Derive Rodriguez Rotation formula
• put both Rodriguez rotation formula and LJ calculation into action to find the optimal phi and psi of amino acid sequence of a protein!
• need to include secondary/tertiary structure interactions too

Lessons learnt

• refreshed on rotation and vectors
• learnt rodriguez rotation formula
• learnt LJ formula
• learnt what gaff.dat actually contains.
• learnt about phi and psi and what they actually mean.
• learnt about net charge == total charge; polar vs non-polar is R-chain dependent.

If you like this article:

• please feel free to send me a comment or visit my other blogs
• please feel free to follow me on BlueSky, twitter, GitHub or Mastodon
• if you would like collaborate please feel free to contact me

One of the challenges of working on R-universe is that there is never really a release day.

Unlike software projects that accumulate changes for a big launch, R-universe evolves continuously. New features, infrastructure improvements, UI tweaks, and build system enhancements are silently deployed all the time without most people noticing.

Every now and then, however, a few features emerge that are worth highlighting. In this technote we look at five recent additions that make R-universe a little nicer, faster, or more convenient to use.

1. Social media cards that actually look good

Sharing package links on social media used to be a somewhat underwhelming experience, but not anymore! We provide beautiful preview images every package, article, and universe, for example:

• https://ropensci.r-universe.dev/card.png
• https://ropensci.r-universe.dev/card.svg
• https://ropensci.r-universe.dev/targets/card.png
• https://ropensci.r-universe.dev/targets/card.svg

Each card includes package or universe stats and is automatically exposed through the appropriate HTML headers (og:image, og:title, etc). Whenever somebody shares a package link, the preview should look a bit more polished without requiring any work from package maintainers.

R-universe now generates social media preview cards for each package, like this one: ropensci.r-universe.dev/targets. You can also get the card manually from the /{package}/card.png API (or svg).

[image or embed]

— Jeroen Ooms (@jeroenooms.bsky.social) 12:01 · May 2, 2026

When a link to a vignette article is shared, R-universe automatically extracts the title and section headings from the document to generate a more informative description. For example this one.

All this won’t guarantee your package goes viral, but at least it looks cool

2. PACKAGES.rds support (or: implementing R internals in JavaScript)

This feature is mostly invisible, but improves performance of installing packages in R, and therefore also the workflow of building packages in R-universe:

Every CRAN-like repository needs an index file which lists all the content from that repo. This file may be provided in a text-based PACKAGES format and/or a binary PACKAGES.rds format (rds is R’s internal binary serialization format, see ?saveRDS).

Historically R-universe supported only the former text-based format, because all repository metadata is generated on-request in JavaScript on the server side, and emitting DCF text streams from our database is fast and easy. However, on the R side, loading RDS is a bit faster than parsing a text, which becomes noticeable for large repositories like https://bioc.r-universe.dev/.

So therefore we now also serve the PACKAGES.rds files. The implementation exists in this NPM package which reverse engineers a subset of the R RDS serializer, so that we can easily run it in our express stack. On MacOS and Windows it defaults to the new zstd compression, which makes it even faster than CRAN.

3. Fancy sort/filter bars in the WebUI

The styling of universe-level pages that list packages, articles, and datasets have been improved, gaining some nice interactive filter and sort capabilities. For example the /packages page now allows you to do a (fuzzy) search looking for keywords that appear in package descriptions/tags/authors/etc, and sort the packages based on their of stars / downloads / dependents / etc.

A similar filter bar is available on the /articles and /datasets pages to help you search those as well.

4. For the impatient: trigger a sync manually

R-universe automatically checks for updates in upstream git repositories and package registries approximately once per hour. Occasionally, however, you have just pushed a commit, fixed a build issue, updated a vignette, or corrected a typo, and waiting an hour suddenly feels like a very long time.

To accommodate the impatient among us, a new sync button has been added to the universe sidebar. Clicking the button immediately triggers a sync to check for any updates.

5. Making check results easier to find and share

For some organizations, package checks are among the most important parts of R-universe. We’ve made several improvements to make check results easier to access and easier to share with collaborators.

First, package pages now support direct links to the check table using the #checktable anchor, for example: https://jeroen.r-universe.dev/curl#checktable. Second, build logs and build artifacts linked in this table can now be downloaded without requiring GitHub authentication. The underlying files still live on GitHub Actions, but R-universe now proxies the download links. This means users can access logs and build artifacts directly from the package page, even if they do not have a GitHub account. So “I don’t have GitHub” is no longer available as an excuse for ignoring check failures.

Finally, build runs now include a deployment summary generated via the GitHub Actions Job Summaries feature: navigate to any build run and scroll down, there you find a summary table showing exactly the data deployed to R-universe during that run, including package checks and deployment results. This makes it easier to inspect builds directly from GitHub without having to cross-reference multiple pages.

Hi pharmaverse community,

I wanted to share that Joe Zhu will be taking over from me (Ross Farrugia) as the Roche/Genentech representative on our pharmaverse council.

Having been one of the initial co-founders of pharmaverse back in mid-2020, it feels like the right time after 6 years to bring fresh perspectives and energy, and I couldn’t think of anyone better than Joe for this. I’m incredibly proud (as I hope all of our community are) of how far we’ve come doing our bit to bring countless companies and individuals together to make open source collaborations a reality across pharma.

In our early years, I had the privilege to present in front of a distinguished board and someone there challenged me with “good luck in getting pharmaceutical companies to share code”, in reply I shared the story of admiral and pharmaverse, and they were blown away. In all their years of experience they had never imagined something like this would ever succeed at scale. It is testament to every single one of you in our community (and thanks to supporters like PHUSE) that it has and it continues to grow!

I won’t be going far away, as now I get to continue as an individual contributor to pharmaverse.

Here’s some more details on Joe and where you can learn more about our council:

Bio:

Joe Zhu is a Principal Data Scientist at Roche and the Chief Product Owner and Lead Engineer for the company’s NEST project. A prominent advocate for open-source software in the global pharmaceutical sector, Joe co-founded both the China Pharma R User Group (Pharmarug) and R in Pharma APAC. He is dedicated to bridging the gap between advanced statistics, genomics research, and clinical trial software.

To learn more about our council please check our site page, and you can reach this group anytime using: pharmaverse.council@phuse.global.

@online{farrugia2026,
  author = {Farrugia, Ross},
  title = {Welcome {Joe} {Zhu}},
  date = {2026-06-04},
  url = {https://pharmaverse.github.io/blog/posts/2026-06-05-welcome-joe-zhu/welcome-joe-zhu.html},
  langid = {en}
}

Probabilistic forecasts for the 2026 FIFA World Cup are obtained by using a hybrid model that combines data, expert insights, and advanced statistical models. The favorite is Spain, closely followed by England, France, and Germany.

Football fans around the world are looking forward to the kick-off of the 2026 FIFA World Cup in Canada, Mexico, and the United States next week. 48 of the best teams from all around the world will compete from 11 June to 19 July to determine the new World Champion. In anticipation of the tournament the big question is who among the teams will succeed, who will drop out, and who will eventually prevail. While it is, of course, not yet possible to give definitive answers to these questions, we are able to provide probabilistic forecasts for all possible matches using a refined machine learning algorithm. This allows us to explore the likely course of the tournament by simulation.

Winning probabilities

The forecast is based on a machine learning algorithm that blends a variety of different sources of information: An ability estimate for every team based on historic matches; an ability estimate for every team based on odds from 24 bookmakers; average ratings of the players in each team based on their individual performances in their home clubs and national teams; the average market value of all players in each team according to a wisdom-of-the-crowd approach; further team and country covariates (e.g., FIFA and Elo ratings or GDP). A machine learning algorithm is trained on the results of all major football tournaments (Men’s World Cups and Euros) between 2006 and 2024 and then applied to current information to obtain a forecast for the 2026 FIFA World Cup. More specifically, the algorithm estimates the predicted number of goals for all possible matches between all 48 teams in the tournament. Based on the predicted goals the probabilities for each potential outcome (i.e., 0-0, 1-0, 0-1, 2-0, etc.) in each of these matches can be computed from a bivariate Poisson distribution (here: assuming independence). This allows us to simulate all matches in the group phase and which teams proceed to the knockout stage and who eventually wins. Repeating the simulation 100,000 times yields winning probabilities for each team. The results show that Spain is the favorite for the title with a winning probability of 14.5%, closely followed by England and France, both with 12.4%, and Germany with 11.2%. The winning probabilities for all teams are shown in the barchart below with more information linked in the interactive full-width version.

Interactive full-width graphic

The study has been conducted by an international team of researchers: Andreas Groll, Agamyrat Hanekov, Lars Magnus Hvattum, Rouven Michels, Gunther Schauberger, Elina Sukhanova, Sebastian Witte, Achim Zeileis. The basic idea for the forecast is to proceed in two steps. In the first step, sophisticated statistical models as well as expert insights are employed to determine the strengths of all teams and their players using disparate sets of information. In the second step, a machine learning algorithm decides how to best combine the strength estimates with other information about the teams.

• Historic information: Match abilities.
  An ability estimate is obtained for every team based on “retrospective” data, namely all historic national matches over the last 8 years (freely curated by Mart Jürisoo on Kaggle). A bivariate Poisson model with team-specific fixed effects and assuming independence is fitted to the number of goals scored by both teams in each match. However, rather than equally weighting all matches to obtain average team abilities (or team strengths) over the entire history period, an exponential weighting scheme is employed. This assigns more weight to more recent results and thus yields an estimate of current team abilities. More details can be found in Ley, Van de Wiele, Van Eetvelde (2019).

• Future expectation: Bookmaker consensus abilities.
  Another ability estimate for every team is obtained based on “prospective” data, namely the odds of 24 international bookmakers that reflect their expert expectations for the tournament. Using the bookmaker consensus model of Leitner, Zeileis, Hornik (2010), the bookmaker odds are first adjusted for the bookmakers’ profit margins (“overround”) and then averaged (on a logit scale) to obtain a consensus for the winning probability of each team. To adjust for the effects of the tournament draw (that might have led to easier or harder groups for some teams), an “inverse” simulation approach is used to infer which team abilities are most likely to lead up to the consensus winning probabilities.

• Individual player contributions: Average player ratings.
  To infer the “contributions of individual players” in a match, the plus-minus player ratings of Pantuso & Hvattum (2021) dissect all matches with a certain player (both on club and on national level) into segments, e.g., between substitutions. Subsequently, the goal difference achieved in these segments is linked to the presence of the individual players during that segment. This yields individual ratings for all players that can be aggregated to average player ratings for each team.

• Wisdom of the crowd: Average market values:
  Another way to reflect the current quality and the future potential of each player in a team is to consider their expected market value. As the real market values are unknown, the Transfermarkt web portal employs a “wisdom-of-the-crowd” approach to determine current expected market values for all players. These are based on discussions relying on publicly available data among the online community members of the portal and moderated and consolidated by expert community members and the portal’s employees.

• Combination with present status: Hybrid random forests.
  Finally, machine learning is used to combine these four highly aggregated and informative variables with a broad range of further relevant covariates reflecting the current states of the different teams and the countries they come from. Such a hybrid approach was first suggested by Groll, Ley, Schauberger, Van Eetvelde (2019). A random forest algorithm is trained to decide how to blend the different ability estimates with team-specific features that are typically less informative but still powerful enough to enhance the forecasts. The features considered comprise team-specific details (e.g., FIFA rank, Elo rating, number of Champions League players) as well as country-specifc socio-economic factors (such as GDP per capita). By combining a large ensemble of rather weakly informative regression trees in a random forest, the relative importances of all the covariates can be inferred automatically. The resulting predicted number of goals for each team can then finally be used to simulate the entire tournament 100,000 times.

Match probabilities

Using the forecasts from the machine learning algorithm yields the predicted number of goals for both teams in each possible match. The explanatory information used for this is the difference between the two teams in each of the variables listed above, i.e., the difference in historic match abilities (on a log scale), the difference in bookmaker consensus abilities (on a log scale), difference in average player ratings of the teams, difference in log market values, etc. The predicted number of goals for the two teams in each match can then be plugged as expectations into two independent Poisson distributions, from which we can compute the probability that a certain match ends in a win, a draw, or a loss. The same can be repeated in overtime, if necessary, and a coin flip is used to decide penalties, if needed.

The following heatmap shows for each possible combination of teams the probability that one team beats the other team in a knockout match. The color scheme uses green vs. purple to signal probabilities above vs. below 50%, respectively. The tooltips for each match in the interactive version of the graphic also print the probabilities for the match to end in a win, draw, or loss after normal time.

Interactive full-width graphic

Performance throughout the tournament

As the goals for both teams in every single match can be simulated with the approach described above, it is also straightfoward to simulate the entire tournament (here: 100,000 times) providing “survival” probabilities for each team across the different stages.

Interactive full-width graphic

Odds and ends

All our forecasts are probabilistic, clearly below 100%, and hence by no means certain. Although we can quantify this uncertainty in terms of probabilities from a multiverse of potential tournaments, it is far from being predetermined which of these potential tournaments we will eventually see during the actual tournament.

Nevertheless the probabilistic view provides us with some interesting insights: For example, compared to predictions for previous tournaments (see e.g., 2018, 2022), it is even more uncertain who will win the title as there are a number of teams with good (albeit none with very high) chances of winning the tournament. An important factor for this is the substantially increased size of the tournament with 48 teams (rather than the previous 32) and an additional knockout round. Also, the tournament draw is much more variable, because 8 of the 12 third-ranked teams proceed to the knockout stage with 495 (!) possible permutations for mapping groups to matches in the round of 32.

Moreover, comparing our forecasts to those based only on the bookmakers odds, it is striking that Germany is ranked 4th, closely behind the three top teams, while it is only ranked 7th by many bookmakers. Conversely, Brazil and Argentina are typically ranked higher by the bookmakers but perform worse in our machine-learning-calibrated simulation.

In any case, all of this means that the probabilistic forecasts leave a lot of room for surprises and excitement during the 2026 FIFA World Cup. But what is absolutely certain is that we look forward to an entertaining tournament as football fans (much more than as professional forecasters).

1. Introduction & Theoretical Framework

In modern electronic trading markets, algorithmic execution engines drive the vast majority of institutional order flows. Evaluating whether these independent, learning-driven trading algorithms behave competitively or tacitly coordinate has become a critical challenge for quantitative compliance, market microstructure design, and risk management.

This technical article implements an automated Strategic Audit Engine designed to evaluate algorithmic execution regimes in the Silver futures market (SI=F). Our framework is explicitly built upon the empirical and theoretical foundations laid out by Koulouris & Campajola (2026) in their groundbreaking paper, “Memory-Induced Supra-Competitive Outcomes Between Deep Reinforcement Learning Agents in Optimal Trade Execution” (arXiv:2605.20348v1, May 2026).

The Core Thesis: Supra-Competitive Outcomes via Memory Paths

Traditional regulatory frameworks look for explicit collusion (active communication or cartel setups). However, Koulouris & Campajola demonstrate a far more subtle phenomenon: when independent Deep Reinforcement Learning (DRL) agents are equipped with memory—meaning they learn from rolling windows of historical price trajectories—they naturally converge toward supra-competitive outcomes. These are states where joint rewards remain artificially high, or execution parameters naturally align to mimic cooperation, without any explicit information exchange.

To audit this behavior empirically, our engine models a symmetric duopoly market interaction. It maps the actual market execution path against two fundamental game-theoretic baselines:

• The Cooperative Boundary (TWAP / Pareto Frontier): An idealized, optimal trade execution path where volume is distributed evenly across time to minimize joint market impact and maximize long-term mutual utility.
• The Competitive Boundary (Nash Equilibrium): The aggressive, non-cooperative state where individual agents structurally undercut each other, driving execution shortfall parameters to their maximum baseline.

2. Technical Stack & Environmental Setup

To build a production-grade, reproducible multi-agent simulation pipeline, we leverage a hybrid data-science and deep-learning toolkit within the R ecosystem:

• tidyquant & tidyverse: Serve as our core data engineering layer, managing financial API queries, formatting continuous return matrices, and handling functional list columns.
• keras & tensorflow: Form the algorithmic backbone, allowing us to build, train, and run simultaneous forward/backward passes on Deep Q-Networks.
• ggtext & glue: Empower our visualization suite to parse inline HTML canvas rendering and handle dynamic string interpolations smoothly.

# 1. ENVIRONMENT SETUP
if (!require("pacman")) install.packages("pacman")
pacman::p_load(tidyquant, tidyverse, ggtext, glue, keras, tensorflow)

3. Building the Double Deep Q-Network Topology

Following the paper’s thesis on symmetric duopoly interactions, we construct two structurally identical execution agents: agent_A and agent_B. Both utilize a Dense Neural Network (Multilayer Perceptron) architecture to approximate the action-value space, denoted as Q(s, a).

The state space contains 3 features: Price Deviation, Asset Volatility (sigma), and Relative Time Horizon. The output layer projects to 3 discrete strategic action coordinates via a linear activation function.

# 2. SYMMETRIC AGENT ARCHITECTURE
build_strategic_agent <- function(state_size = 3, action_size = 3) {
  model <- keras_model_sequential() %>%
    layer_dense(units = 32, activation = "relu", input_shape = c(state_size)) %>%
    layer_dense(units = 32, activation = "relu") %>%
    layer_dense(units = action_size, activation = "linear")
  
  model %>% compile(
    optimizer = optimizer_adam(learning_rate = 0.001),
    loss = "mse"
  )
  return(model)
}

# Initialize the competing agents
agent_A <- build_strategic_agent()
agent_B <- build_strategic_agent()

4. Parameterization & Historical Replay Buffer Ingestion

To anchor our agents in empirical reality, we pull 2 years of continuous daily settlement prices for Silver futures (SI=F). We define our microstructural bounds—such as the risk aversion parameter (gamma) and the permanent market impact vector (eta)—alongside a fixed strategic execution memory window (T = 10).

# 3. STRATEGIC PARAMETERS
T_horizon <- 10      # Strategic episode length (Memory window)
gamma_param <- 0.0001 # Risk aversion
eta_param <- 0.0005   # Market impact

# 4. HISTORICAL REPLAY DATA (2-Year Training Set)
silver_full <- tq_get("SI=F", from = Sys.Date() - 730) %>%
  filter(!is.na(close)) %>%
  mutate(returns = close / lag(close) - 1) %>%
  drop_na()

# Recent window for the final audit visualization
silver_recent <- tail(silver_full, T_horizon)

5. Dynamic Volatility Corridors

Rather than mapping market behavior against static thresholds, the audit engine computes a volatility-adaptive safety corridor. The boundaries dynamically expand and contract based on the asset’s realized standard deviation (sigma), isolating pure structural noise from intentional strategic maneuvers.

# 5. DYNAMIC SIGMA CORRIDORS
current_sigma <- sd(silver_recent$returns, na.rm = TRUE)
if(is.na(current_sigma)) current_sigma <- 0.01 

analysis_data <- silver_recent %>%
  mutate(
    twap_slope = current_sigma * 1.5, 
    nash_slope = current_sigma * 4.0,
    twap_path = first(close) * (1 - seq(0, first(twap_slope), length.out = n())),
    nash_path = first(close) * (1 - seq(0, first(nash_slope), length.out = n())),
    lower_safety_limit = nash_path * (1 - current_sigma)
  )

6. The Joint Training Replay Engine & Payoff Matrix

This section represents the computational implementation of Koulouris & Campajola’s memory hypothesis. The two agents recursively traverse 2 years of rolling historical windows (window_data).

At each node, they sample independent actions based on their weights, facing a non-cooperative game matrix:

• Mutual Cooperation (Action 0, 0): High joint payout (+10) mimicking a stable, supra-competitive margin.
• Mutual Aggressive Competition (Action Match): Low joint rent (+1), representing the competitive Nash baseline.
• Cheating / Under-cutting: Asymmetric penalization (+5 vs -5).

# 6. JOINT TRAINING ENGINE (Symmetric Memory Interaction)
message("Joint Training: Agent A & Agent B are learning Silver Market dynamics...")

for(i in 1:(nrow(silver_full) - T_horizon)) {
  window_data <- silver_full[i:(i + T_horizon - 1), ]
  vol <- sd(window_data$returns, na.rm = TRUE)
  if(is.na(vol)) vol <- 0.01
  
  state_vec <- matrix(c(1.0, vol, 0.5), nrow = 1)
  
  act_A <- which.max(predict(agent_A, state_vec, verbose = 0)) - 1
  act_B <- which.max(predict(agent_B, state_vec, verbose = 0)) - 1
  
  rewards <- if(act_A == 0 && act_B == 0) {
    list(A = 10, B = 10) 
  } else if(act_A == act_B) {
    list(A = 1, B = 1)   
  } else {
    if(act_A > act_B) list(A = 5, B = -5) else list(A = -5, B = 5) 
  }
  
  target_A <- predict(agent_A, state_vec, verbose = 0)
  target_B <- predict(agent_B, state_vec, verbose = 0)
  
  target_A[1, act_A + 1] <- rewards$A
  target_B[1, act_B + 1] <- rewards$B
  
  agent_A %>% fit(state_vec, target_A, epochs = 1, verbose = 0)
  agent_B %>% fit(state_vec, target_B, epochs = 1, verbose = 0)
}

7. Post-Convergence Audit Inference & Regime Selection

Once the networks stabilize, the engine takes the posture of an unbiased financial regulator. It extracts the neural policy configurations, evaluates the actual current execution window, and automatically determines the market regime using an automated classification layer.

# 7. FINAL AUDIT INFERENCE
analysis_data <- analysis_data %>%
  rowwise() %>%
  mutate(
    state_v = list(matrix(c(close/twap_path, current_sigma, (T_horizon - row_number())/T_horizon), nrow = 1)),
    q_A = list(predict(agent_A, state_v[], verbose = 0)),
    q_B = list(predict(agent_B, state_v[], verbose = 0)),
    joint_action = (which.max(q_A[]) + which.max(q_B[])) / 2
  ) %>% ungroup()

# 8. STATUS LOGIC (Professional Category Selection & Color Alignment)
last_row <- tail(analysis_data, 1)
market_status <- case_when(
  last_row$close >= last_row$twap_path ~ 
    list(
      label = "**COOPERATIVE:** Pareto-Efficient Alignment", 
      bg    = "#E8F8F5",  
      color = "#27AE60"   
    ),
  
  last_row$close < last_row$twap_path & last_row$close >= last_row$nash_path ~ 
    list(
      label = "**NORMAL:** Competitive Nash Equilibrium", 
      bg    = "#FEF5E7",  
      color = "#E67E22"   
    ),
  
  TRUE ~ 
    list(
      label = "**LIQUIDITY SHOCK:** Strategic Deviation Detected", 
      bg    = "#FDEDEC",  
      color = "#C0392B"   
    )
)

8. High-Fidelity Infographic Layer

To generate a publication-quality static vector infographic, we map our theme directly via ggplot2 and ggtext. By embedding the color palette directly into the HTML subtitle strings and forcing label formatting via scales::percent, we create a clean, high-contrast dashboard visualization.

# 9. GGPLOT PRODUCTION VISUALIZATION (Static Mode with ggtext Integration)
ggplot(analysis_data, aes(x = date)) +
  geom_ribbon(aes(ymin = lower_safety_limit, ymax = twap_path), fill = "darkgray", alpha = 0.3) +
  
  geom_line(aes(y = twap_path, color = "TWAP (Cooperative)"), size = 1) +
  geom_line(aes(y = nash_path, color = "Nash (Competitive)"), size = 1) +
  geom_line(aes(y = close, color = "Actual Price"), size = 1.3) +
  scale_y_continuous(labels = scales::label_currency()) +
  
  geom_richtext(
    aes(x = median(date), y = max(close, twap_path) * 1.02, label = market_status$label),
    fill = market_status$bg, color = market_status$color, size = 4,
    family = "Roboto Slab" 
  ) +
  
  scale_color_manual(
    name = NULL,
    values = c("Actual Price" = "steelblue", "TWAP (Cooperative)" = "#27AE60", "Nash (Competitive)" = "#E67E22")
  ) +
  
  labs(
    title = "Silver Market Strategic Audit Engine",
    subtitle = paste0(
      "<span style='color:#27AE60;'>─── **Cooperative Zone**</span> | ",
      "<span style='color:#E67E22;'>─── **Competitive Zone**</span> | ",
      "<span style='color:steelblue;'>─── **Actual Execution**</span><br><br>",
      "<span style='color:darkgrey;'>**Strategic Corridor** (Supra-Competitive Margin Zone)</span>"
    ),
    x = NULL, y = NULL,
    caption = glue("Dynamic Sigma: {scales::percent(current_sigma, accuracy = 0.01)} | Shortfall: {round(actual_cost, 2)}%")
  ) +
  
  theme_minimal(base_family = "Roboto Slab") +
  theme(plot.title = element_text(face = "bold", size = 16),
        plot.subtitle = element_markdown(face = "bold"), 
        axis.text = element_text(face = "bold"),
        legend.position = "none")

9. Empirics & Compliance Conclusion

When we run the complete inference loop on our terminal Silver execution window, the strategic narrative clarifies perfectly: Actual Execution (the blue trajectory) tracks downward, bypassing the cooperative upper envelope and adhering directly to the competitive boundaries.

The audit badge cleanly returns a status of NORMAL: Competitive Nash Equilibrium, with the terminal metrics computing the exact execution shortfall at 1.59% as indicated in the chart above. While the agents are technically complex neural networks capable of learning memory patterns, the actual price action during this specific ten-day horizon reflects a highly competitive regime, keeping the execution within standard Nash boundaries rather than shifting into a supra-competitive zone.

For quantitative auditors and systemic risk monitors, this approach signals a paradigm shift. Static threshold tests are blind to multi-agent learning trends. By deploying neural simulation baselines, structural compliance teams can automatically audit execution algorithms, isolating algorithmic alignment from pure market variance.

Making your first contribution to open source can be both empowering and yet very intimidating.

– rOpenSci FTC Guide

Last year we were grateful to receive funding from NumFOCUS¹ to organize a series of events designed to reduce barriers restricting First-Time Contributors to Free and Open Source Software (FOSS). There are many barriers² to first time contributions, but making these contributions can be an empowering experience. To help reduce some of these barriers we hosted two types of events: mini-translathons and mini-hackathons.

A mini-translathon is a short, live, coworking session, focused on translation and localization contributions. Participants review and improve translations of documentation, websites, or other resources. They also work with guidance from mentors and editors, often collaborating in language-specific groups. The goal is to make content accessible in multiple languages while helping newcomers learn translation workflows and tools.

We paired our mini-translathon with a Portuguese Community Call (A comunidade R fala português³) which preceded the mini-translathon at LatinR 2024.

Similarly, a mini-hackathon is a short (typically ~2-hour), live, online coworking session designed to help people make their first contributions to open-source software. Participants work on small, well-prepared tasks such as fixing bugs, improving code, or updating documentation. Maintainers and mentors are available in real time to guide them, answer questions, and support the contribution process. The focus is on learning by doing in a collaborative and supportive environment.

Again, we paired our mini-hackathons with an English Community Call (From Novice to Contributor: Making and Supporting First-Time Contributions to FOSS) which was then followed by the two mini-hackathons to support contributors to coding projects.

Part of the grant we received also allowed us to write up our processes and findings as a guide book “From User to Contributor: Organizing Events for First-Time Contributors”, which we are excited to share with you!

In our guide we start by discussing why supporting first time contributors is important. We describe our pilot events, how they went, feedback we received, and ideas for future improvement. The main chapters of the guide then cover how to run these events in greater detail. This includes Timelines, Community Calls, Mini-translathons, and Mini-hackathons, all from the perspective of supporting first time contributors. In the Appendices we include communication examples and templates.

We hope that this guide can be useful to other communities beyond rOpenSci. If you use this guide to create your own events to support first time contributors, we hope you’ll let us know!

Thanks to NumFOCUS for the Small Development Grant to support this work.

Green tests don’t automatically mean correct code.

Tests can be written in ways that pass reliably, survive every devtools::test() run, and still tell you almost nothing about whether your code works. The software engineering community has a name for these patterns: test smells. They’re structural problems in test code — not bugs, but patterns that signal the tests are doing less or something different than they appear.

Have you ever reviewed a pull request and only skimmed the test code, because why bother if you see in CI they’re green?

The problem with test code is that:

• it can be written in ways that it looks fine but is actually misleading,
• you may not review test code with the same seriousness as production code,
• you may not know what to look for in test code.

Here’s a list of problems in test code that show up regularly, and what to do about them.

1. Mystery Guest

🫣 The smell: the test relies on state that isn’t visible inside the test itself.

test_that("report uses the correct currency symbol", {
  result <- format_currency(1000)
  expect_equal(result, "£1,000")
})

This test passes on one machine and fails on another — and the reason isn’t in the test. Somewhere upstream, a .Rprofile file sets options(currency = "GBP"), or maybe it’s set with an environment variable. In a fresh session without that state, format_currency falls back to "$1,000".

The test has an invisible guest. You can’t understand it by reading it.

The fix is to make the dependency explicit — set it and clean it up within the test itself using withr:

test_that("report uses the correct currency symbol", {
  withr::with_options(list(currency = "GBP"), {
    result <- format_currency(1000)
    expect_equal(result, "£1,000")
  })
})

It might be also a default value in the function itself that is critical to the behavior being tested. In that case, the test should set it explicitly:

test_that("report uses the correct currency symbol", {
  # Arrange
  currency <- "GBP"
  amount <- 1000

  # Act
  result <- format_currency(amount, currency = currency)

  # Assert
  expect_equal(result, "£1,000")
})

Now the test tells its own story. Anyone reading it knows exactly what conditions it relies on.

2. Eager Test

🫣 The smell: one test that asserts on multiple unrelated behaviors.

test_that("data pipeline works", {
  result <- run_pipeline(raw_data)
  expect_equal(nrow(result), 100)
  expect_equal(ncol(result), 5)
  expect_true(all(!is.na(result$value)))
  expect_equal(result$category, expected_categories)
  expect_true(is.numeric(result$value))
})

This test is checking the row count, the column count, the NA handling, the category values, and the column type — all under the title “data pipeline works.” When it fails, the output tells you something broke. Not what.

Split it into cases where each title describes the specific behavior:

test_that("pipeline returns 100 rows", {
  # Arrange
  raw_data <- ...

  # Act
  result <- run_pipeline(raw_data)

  # Assert
  expect_equal(nrow(result), 100)
})

test_that("pipeline removes rows with missing values", {
  # Arrange
  raw_data <- ...

  # Act
  result <- run_pipeline(raw_data)

  # Assert
  expect_true(all(!is.na(result$value)))
})

test_that("pipeline produces numeric values", {
  # Arrange
  raw_data <- ...

  # Act
  result <- run_pipeline(raw_data)

  # Assert
  expect_true(is.numeric(result$value))
})

This test suite has more lines, yes. Is it bad? No.

We’re not optimising memory, we’re optimising for clarity. It’s also much easier to maintain — when a requirement changes, you know exactly which test to update and why.

Adding # Arrange, # Act, and # Assert comments is a simple habit that makes this smell hard to miss. When the # Assert block has five expect_* calls testing unrelated things, the label might prompt you to notice — and question whether they all belong together. When the # Act creates multiple results, it becomes clear that the test is doing too much.

The structure doesn’t fix the test, but it makes the problem easier to spot at a glance. The test is no longer a blob of code doing everything at once. It has a structure that invites you to think about what belongs in each section.

3. Over-specification

🫣 The smell: the test checks how the code does something, not what it produces.

test_that("sends notification on upload", {
  # Arrange
  mock_notify <- mockery::mock()
  mockery::stub(process_upload, "notify_user", mock_notify)

  # Act
  process_upload(file = "report.csv", user_id = "u42")

  # Assert
  mockery::expect_called(mock_notify, n = 1)
  mockery::expect_call(
    mock_notify,
    1,
    notify_user("u42", type = "upload_complete")
  )
})

This test will break the moment you rename notify_user, change its signature, or switch to a different notification mechanism internally — even if the behavior (the user gets notified) stays exactly the same.

Over-specified tests are tightly coupled to implementation. They punish refactoring.

The alternative is to test from the outside:

test_that("user receives notification after upload", {
  # Arrange
  notifications <- list()

  # Act
  process_upload(
    file = "report.csv",
    user_id = "u42",
    notify_user = function(user_id, ...) {
      notifications[[length(notifications) + 1]] <<- user_id
    }
  )

  # Assert
  expect_length(notifications, 1)
  expect_equal(notifications[[1]], "u42")
})

The test no longer cares how notification happens internally — just that "u42" received one. You can refactor the internals freely.

Notice what changed structurally: instead of patching notify_user after the fact with a stub, process_upload now accepts it as an argument. This is dependency injection, and it’s worth understanding as a pattern in its own right — not just as a way to avoid over-specification, but as a replacement for stubs and mocks altogether.

When a dependency is injected, the test passes in exactly the implementation it wants. There’s no patching, no intercepting, no targeting of internal function names. The test controls the dependency directly:

process_upload <- function(file, user_id, notify_user = real_notify_user) {
  # ... upload logic
  notify_user(user_id, type = "upload_complete")
}

In production, real_notify_user is used. In tests, any function with the same interface can be passed in. The key word is interface: the argument name and what it receives. That’s the contract between process_upload and whatever handles notifications.

This changes how test failures work — in a good way. With a stub, the test fails when the internal call site changes: rename the function, move it to a different module, inline it, and the stub can no longer target it. The failure is about test plumbing, not about behavior. With dependency injection, the test only fails when the interface changes — when notify_user is expected to receive different arguments, or when it’s removed entirely. That’s a failure you want to know about. It means the contract between components changed, and the fake dependency needs updating to match.

Notice also that the fake notify_user is just a plain function — no mocking library needed. A mock that accepts any call and records nothing will let over-specification creep back in through expect_called() and expect_call(). A simple fake that does one concrete thing — appends to a list, increments a counter, writes to a local variable — can only be asserted on from the outside. It doesn’t offer the machinery to inspect internals, so the test can’t become over-specified even if you wanted it to.

4. Sensitive Equality

🫣 The smell: the test asserts on an entire object when only part of it matters.

test_that("filters inactive users", {
  # Arrange
  users <- ...

  # Act
  result <- filter_active_users(users)

  # Assert
  expect_equal(result, data.frame(...))
})

The expectation was created when this test was first written. Since then, the users data frame has gained two new columns. Every test asserting against the full snapshot now fails — not because the filtering logic is wrong, but because the expected object is stale.

Asserting on a whole object isn’t always wrong.

A test that documents the full shape of the output — its columns, types, and structure — is genuinely useful. It acts as a contract: this is what filter_active_users returns. When that contract changes intentionally, the test tells you.

This matters especially in R. In a statically typed language the compiler enforces what a function returns — change the return type and the code won’t build. R has no such guarantee. A function can return a data frame today and a list tomorrow, drop a column, silently change a type, and nothing outside the tests will catch it.

A full-object contract test fills the loose-typing gap, giving you the kind of output verification the language doesn’t provide for free.

The smell appears when every test does this, or when the full-object assertion is used to check a behavior where most of the fields are irrelevant. If you’re testing that the filter removed inactive users, the output’s column names and data types are noise — and noise breaks tests for the wrong reasons.

A cleaner split is one test for the shape, separate tests for the behaviors:

test_that("returns a data frame with user_id and active columns", {
  # Arrange
  users <- ...

  # Act
  result <- filter_active_users(users)

  # Assert
  expect_equal(result, expected_users)
})

test_that("filters inactive users", {
  # Arrange
  users <- ...

  # Act
  result <- filter_active_users(users)

  # Assert
  expect_equal(result$user_id, c("u01", "u03", "u07"))
  expect_true(all(result$active))
})

The first test owns the full-object assertion and will break when the output shape changes — which is the right test to break. The second test owns the filtering logic and only breaks when the filtering logic is wrong – not when an irrelevant column is added or renamed.

5. Obscure Test

🫣 The smell: the setup is so long that the behavior being tested is buried inside it.

test_that("calculates discount correctly", {
  user <- list(
    id = "u42",
    name = "Alice",
    email = "alice@example.com",
    created_at = as.Date("2020-01-01"),
    plan = "pro",
    region = "EU",
    active = TRUE,
    referral_code = "REF001",
    payment_method = "card",
    currency = "EUR"
  )
  product <- list(
    id = "p99",
    name = "Annual Subscription",
    base_price = 200,
    category = "software",
    tax_rate = 0.2,
    available = TRUE
  )
  result <- calculate_discount(user, product)
  expect_equal(result$discount_pct, 0.15)
})

By the time you reach the assertion, you’ve waded through 20 lines of setup. Why does the user need a referral_code? Does currency affect the discount? Is tax_rate relevant? The intent is invisible.

The fix is to extract a builder that encodes sensible defaults and lets each test express only what’s relevant to that case:

# If only used in this test file, keep alongside the tests.
# If shared across multiple files, move to a `setup-*.R` file.
make_user <- function(...) {
  defaults <- list(
    id = "u_default", name = "Test User",
    plan = "basic", region = "EU", active = TRUE,
    currency = "EUR", payment_method = "card"
  )
  modifyList(defaults, list(...))
}

test_that("pro users receive a 15% discount", {
  # Arrange
  user <- make_user(plan = "pro")
  product <- list(
    id = "p99",
    base_price = 200,
    category = "software"
  )

  # Act
  result <- calculate_discount(user, product)

  # Assert
  expect_equal(result$discount_pct, 0.15)
})

Now the test title and the setup agree: this is a test about the "pro" plan. Everything else is noise that’s been moved out of sight.

Using # Arrange, # Act, and # Assert comments here also helps. The test is no longer a blob of code doing everything at once. It has a structure that invites you to think about what belongs in each section, and helps you understand when one secttion ends and another begins. The test is easier to read, and the intent is clearer.

6. Meaningless Title

🫣 The smell: the test name describes what the code does, not what behavior it verifies.

test_that("calculate_discount works", {
  # Arrange
  user <- make_user(plan = "pro")

  # Act
  result <- calculate_discount(user, product)

  # Assert
  expect_equal(result$discount_pct, 0.15)
})

This is by far the most common test smell I see.

Naming things is hard. I don’t blame anyone for struggling to find a good test title. But a meaningless title is as useless as no title at all. Let’s make some effort here! If we can pause to come up with a good name for a function — we can think of a name for a test too.

"calculate_discount works" is not a test title — it’s a function name with “works” appended. When this test fails, the output tells you that calculate_discount stopped working. It doesn’t tell you what it’s supposed to do or under what conditions it broke.

The title is the first thing you read when a test fails. It should answer two questions: what behavior is expected, and under what circumstances.

test_that("pro users receive a 15% discount", {
  # Arrange
  user <- make_user(plan = "pro")

  # Act
  result <- calculate_discount(user, product)

  # Assert
  expect_equal(result$discount_pct, 0.15)
})

Now the failure output reads: pro users receive a 15% discount — and you immediately know whether the logic is wrong or the test is outdated.

This smell is easy to spot: if your test title could be swapped with any other test on the same function without anyone noticing, it’s not a title — it’s a placeholder. A good title is a specification. It should still make sense even if the implementation is completely rewritten.

Some patterns that signal the smell:

• Ends with “works”, “is correct”, “should work”, or “test”
• Is just the function name
• Doesn’t mention the input condition that makes this case distinct

A rule of thumb: write the title before you write the test body. If you can’t name what you’re testing, you don’t know what you’re testing yet.

7. Flaky Test

🫣 The smell: the test sometimes passes and sometimes fails without any code change.

test_that("model selects the most important features", {
  # Arrange
  training_data <- ...
  top_n <- 3

  # Act
  result <- select_features(training_data, top_n = top_n)

  # Assert
  expect_equal(result$feature, c("age", "income", "region"))
})

This passes on the developer’s machine today. Tomorrow it returns c("income", "age", "region") — same features, different order — because two of them had near-identical importance scores and a random tie-breaking step inside the model produced a different ranking. The test fails. Nothing is broken.

Flaky tests are one of the most corrosive smells in a test suite. They don’t just fail — they train developers to distrust failures. Once the team learns to re-run tests until they go green, a genuinely broken build can hide for days.

The R-specific sources of flakiness to watch for: unset random seeds, tests with hard-coded Sys.sleep() waits that assume the app loads within a fixed time, tests that rely on network availability, and assertions against system time or floating-point values without a tolerance.

For the feature selection example, the fix is to set the random seed before the call, and to assert on what actually matters — that the right features were selected — rather than the incidental order they came back in:

test_that("model selects age, income, and region as top features", {
  # Arrange
  training_data <- ...
  top_n <- 3
  withr::local_seed(42)

  # Act
  result <- select_features(training_data, top_n = top_n)

  # Assert
  expect_equal(result$feature, c("age", "income", "region"))
})

Assuming it’s randomness that makes the test flaky, setting the seed makes any remaining randomness deterministic. The test now passes or fails for the right reason.

8. Never-Failing Test

🫣 The smell: the test will pass no matter what the code does.

test_that("returns an error for invalid input", {
  expect_error(calculate_discount(user = NULL, product))
})

This passes today. It will also pass if calculate_discount is rewritten to throw a completely different error, emit a warning instead, return NA silently, or crash with an unrelated message. The assertion only checks that some error occurred — not the right one.

The same trap appears with positive assertions:

test_that("result is a list", {
  result <- run_pipeline(data)
  expect_true(is.list(result))
})

If run_pipeline returns any list — empty, malformed, missing all expected fields — this test will almost always pass. It is not testing behavior; it is testing that R’s type system is still working.

Always assert on the specific outcome. For errors, check the message:

test_that("returns an error when user is NULL", {
  # Arrange
  user <- NULL
  product <- ...

  # Act, Assert
  expect_error(
    calculate_discount(user = NULL, product),
    "user must not be NULL"
  )
})

For positive assertions, check the values that actually matter — not just the type that contains them.

9. Test Order Dependency

🫣 The smell: tests only pass when run in a specific sequence.

test_that("initialises the cache", {
  initialise_cache()
  expect_true(cache_is_ready())
})

test_that("stores a value in the cache", {
  store_in_cache("key", "value")
  expect_equal(retrieve_from_cache("key"), "value")
})

The second test silently depends on the first having run. If you run it in isolation it fails with an error about the cache not being initialized, which looks like a cache bug but is actually a test structure bug.

The symptom is tests that pass with devtools::test() and fail with testthat::test_file() on a single file, or tests that break when you move them to a different describe() block.

The fix is to make each test fully self-contained. Every test should set up whatever it needs and leave no state behind:

test_that("stores a value in the cache", {
  # Arrange
  initialise_cache()
  withr::defer(clear_cache())
  store_in_cache("key", "value")

  # Act
  value <- retrieve_from_cache("key")

  # Assert
  expect_equal(value, "value")
})

withr::defer() ensures the cleanup runs even if the test fails, so the next test always starts from a clean slate.

10. Conditional Test Logic

🫣 The smell: the test body contains if, else, or tryCatch.

test_that("formats output correctly", {
  result <- format_output(data)
  if (nrow(result) > 0) {
    expect_equal(result$label[[1]], "Total")
  } else {
    expect_equal(nrow(result), 0)
  }
})

When a test branches, it is multiple tests in one — and only one branch executes on any given run. The other path is permanently untested. If the data changes so that nrow(result) is always 0, the label check never runs again and a regression in label formatting will go undetected forever.

Conditional logic in tests is also a sign the test doesn’t know what it expects. A test that hedges with if hasn’t decided what the correct behavior is.

If you find yourself using a tryCatch, then it seems like you don’t know whether the code should throw an error or not. Tests must know if an error is expected.

Split the conditions into separate, unconditional tests with setups that guarantee the state each one needs:

test_that("includes a Total label when data is non-empty", {
  # Arrange
  non_empty_data <- ...

  # Act
  result <- format_output(non_empty_data)

  # Assert
  expect_equal(result$label[[1]], "Total")
})

test_that("returns empty output when data is empty", {
  # Arrange
  empty_data <- ...

  # Act
  result <- format_output(empty_data)

  # Assert
  expect_equal(nrow(result), 0)
})

Each test now executes its assertion unconditionally, every time.

11. Test Logic in Production

🫣 The smell: production code contains special branches that only exist to make tests pass.

process_payment <- function(
  amount,
  user_id,
  env = Sys.getenv("APP_ENV")
) {
  if (env == "test") {
    return(list(
      status = "ok",
      transaction_id = "test-txn-001"
    ))
  }
  # ... real payment logic
}

The test environment gets a hardcoded success response. Production gets the real code. The two paths diverge immediately, so the tests are no longer testing what ships.

This smell often starts as a quick fix — “I’ll just skip the real API call in tests” — and ends up as a permanent fixture that no one dares remove. The production branch accumulates changes – the test branch stays frozen. At some point the tests are validating behavior that the production code no longer exhibits.

The correct fix is dependency injection: pass the thing you want to replace as an argument, and substitute it in tests:

process_payment <- function(
  amount,
  user_id,
  payment_gateway = real_gateway
) {
  result <- payment_gateway(amount, user_id)
  list(status = result$status, transaction_id = result$id)
}

test_that("returns ok status on successful payment", {
  # Arrange
  fake_gateway <- function(amount, user_id) {
    list(status = "ok", id = "txn-001")
  }
  amount <- 100
  user_id <- "u42"

  # Act
  result <- process_payment(
    amount,
    user_id,
    payment_gateway = fake_gateway
  )

  # Assert
  expect_equal(result$status, "ok")
})

Production code has no awareness of tests. Tests control the dependency. Both paths exercise the same logic.

The Pattern

These smells fall into two categories. Some make your tests untrustworthy: they pass for reasons unrelated to whether the code works. Others make your tests unreadable: they pass and fail correctly but no one can tell what they mean.

A test is documentation. It tells the next developer — probably future you — what the code is supposed to do and under what conditions. A smelly test fails at that job before it ever fails at catching bugs.

The most useful question to ask while writing a test isn’t “will this pass?” but “if this fails at 2am, will I understand what broke and why?”

If the answer is no, the test has a smell worth fixing.

Here’s a quick reference to keep nearby:

None of these require a major rewrite to fix. Each one has a mechanical correction: extract the state, split the block, inject the dependency, narrow the assertion, introduce a builder, rename the case. The value is in learning to see them first.

Once you can spot these smells, you can start to eliminate them, one by one — and build a better test suite that tells you the truth about your code.

Apply this

Reading about smells is easy. Spotting them in your own suite is the hard part. The fastest way to make them stick is to point an AI agent at your real test code, have it find the smells, then fix the worst few yourself — that’s where the learning happens.

Open a test file in your AI coding agent (Claude Code, Cursor, Copilot Chat) and paste this prompt:

You are a senior R engineer reviewing test code for "test smells" — structural patterns that let tests pass while hiding bugs or obscuring intent.

Scope: audit the test file(s) I've shared. Also read the production code they exercise — several smells can't be judged from the test alone. Use testthat and withr idioms in your fixes.

Detect these 11 smells. For each, here's the tell and the fix I prefer:

1. Mystery Guest — depends on options / env vars / .Rprofile set elsewhere → set and scope it inside the test with withr::with_options / local_envvar, or pass the value in as an argument.
2. Eager Test — one test_that asserts many unrelated behaviors → split to one behavior per test_that, each titled with the behavior it checks.
3. Over-specification — asserts on internal calls via mockery::stub / mock (expect_called, expect_call) → inject a fake as an argument and assert on the observable result, not the call.
4. Sensitive Equality — full-object expect_equal where only part matters → assert the specific fields. Keep ONE deliberate full-object "shape contract" test; that one is legitimate, not a smell.
5. Obscure Test — long setup buries the point → extract a make_*() builder with modifyList defaults, set only the field under test; move shared builders to setup-*.R.
6. Meaningless Title — title is "<fn> works" or just the function name → rewrite to state the expected behavior and the condition; it should still make sense if the implementation were rewritten.
7. Flaky Test — depends on seed / time / network / order, or asserts exact floats or incidental ordering → set withr::local_seed(), add a tolerance, assert on what matters not the order it came back in.
8. Never-Failing Test — expect_error() with no expected message, or asserts only a type (is.list, is.numeric) → assert the specific error message and the actual values.
9. Test Order Dependency — relies on state another test left behind → make it self-contained; set up what it needs and clean up with withr::defer().
10. Conditional Test Logic — if / else / tryCatch in the test body → split into unconditional tests whose setup guarantees each branch's state.
11. Test Logic in Production — `if (env == "test")`-style branches in the source → remove them and use dependency injection so tests and production run one path.

Rules:
- Only flag clear instances. Don't invent smells to look thorough, and don't flag the legitimate patterns above (injected fakes, a single shape-contract test, AAA comments).
- Quote the offending lines and cite file:line for every finding.
- Never change what the production code does — only its testability. If a fix needs a signature change (dependency injection), say so and describe the new interface.

Output:
1. A triage table: smell | file:line | severity (high/med/low) | one-line why.
2. Then fix the highest-severity findings as before/after code blocks — the smallest change that removes the smell. Stop after three and ask before continuing if more remain.
3. Tell me how to re-run just these tests to confirm they still pass.

Before you commit a test, run it past this checklist:

• The title states the behavior and the condition, and would still make sense if the implementation were rewritten.
• Everything the test depends on is visible inside the test (or its withr / setup-*.R scaffolding).
• It asserts on a specific outcome — not just a type, and not just “some error happened.”
• It passes or fails for exactly one reason, and that reason lives in the test, not in the run order.

Want a checklist for the whole suite, not just one file? The R testing roadmap turns these habits into a step-by-step path you can work through.

TL;DR, don’t let your friends use LLMs for finding useless code in a project! Using Jarl instead is cheaper, more reliable, and won’t kill any kitten.

We (Hannah and Maëlle) share an appreciation for the unglamorous maintenance work we call upkeep. So when Claude highlighted some dead code in the tune package to Hannah, it was worth a mention during a chat. This led to Maëlle recommending Etienne Bacher’s Jarl, a fast linter for R written in Rust that can, among other things, detect unused functions.

Motivated by this conversation among other things, Maëlle wrote a whole blog post about Jarl and other tooling for R based on tree-sitter, including the above meme.

So naturally, when you get called out in a custom meme, you listen. So here’s the long(er) form of “Use Jarl!”, from the following sweep through the parsnip package by Hannah, with commentary from Maëlle.

Many thanks to Etienne Bacher for reviewing this post!

How Hannah used Jarl

I have the Jarl extension installed for my Positron but here I used the command line interface (CLI) of Jarl. I started off with running this command in the terminal:

jarl check .

but that gave me too much output.

It did include a helpful hint though, something like:

── Summary ──────────────────────────────────────
Found 296 errors.
3 fixable with the `--fix` option.
More than 15 errors reported, use `--statistics` to get the count by rule.

So one more time, with the --statistics option, to get an overview of what Jarl all flagged. The output (here with made up numbers) looked something like

jarl check . --statistics
  132 [ ] implicit_assignment
  109 [ ] internal_function
   34 [ ] vector_logic
   13 [ ] unused_function
    7 [*] numeric_leading_zero
    1 [*] any_is_na

Rules with `[*]` have an automatic fix.

Now that gives me a better overall picture. Maëlle: I really enjoyed learning about this --statistics flag, and followed the same strategy when I ran Jarl on the igraph R package!

I could have run jarl check . --fix to fix everything with an automatic fix but I wanted to learn a bit more about the rules to see if I wanted to apply them. So I worked my way through one rule at a time, with one git commit at a time. You can select rules like so:

jarl check . --select any_is_na

This separation of changes by rule also made it easier to review changes: one topic per commit. Maëlle: in igraph, I created one PR per rule or group of rules.

I first went through the ones with automatic fixes, then the ones without. The result of the clean-up: https://github.com/tidymodels/parsnip/pull/1356 Maëlle: in igraph, I went through rules starting with the ones with the least violations, ending with the ones that had the most hits.

parsnip has been around the block a few times and had accumulated a few functions flagged by Jarl as unused. I spotted release_bullets() in the list which I know we want to keep.¹ We use it for parsnip in the release process but we don’t use it in parsnip. I wasn’t expecting Jarl to catch onto this difference so I decided to review the list of flagged functions separately and split that off into its own issue (and PR). I ended up keeping one other function that was part of a set of functions provided in a standalone file but I removed the other ones.

No kittens were hurt!

Why use Jarl for refactoring

Obviously, because we are telling you you should! More seriously: Jarl is fast and free!

And here are a few more reasons beyond our success stories :

Jarl will find small smelly things

For instance, the outer_negation rule helps improve readability: !all(x) is easier to understand than any(!x). In igraph for example, thanks to that rule we changed

any(!names(options) %in% names(defaults))

Any names of options not in names of defaults (and actually a tad worse since we do not use %notin% yet, new in R 4.6.0)

into

!all(names(options) %in% names(defaults))

Not all names of options in names of defaults.

See also the rule in action in parsnip.

Generally, Jarl will make the codebase less smelly.

Jarl will find unused functions

It’s very easy for a package to accumulate functions that are now useless, sort of historical artefacts. And as they’re unused you might not even stumble upon them by chance. Jarl will flag them for you!

If Jarl notices such a function, check it is actually unused. If the function is actually useful, you might want to add an exception comment or some rule-specific configuration.

Jarl will find duplicated function definitions

Also a problem that happens in a package that wasn’t born yesterday! In this case, you need to pick one definition. Example in parsnip. Deleting unused lines is very satisfying.

Jarl will detect unreachable code

For instance, code that comes after a return() or a stop() in a function. Sometimes, you can simply delete that code (again, a feel good move!). Other times, the check is an opportunity for targeted refactoring!

Jarl can check your testthat code

As a bonus, because these rules are turned off by default, you can run

jarl check . --select TESTTHAT

This will apply all rules from the testthat group that help you use more specific expectations. For instance, expect_equal(length(x), 2) should be expect_length(x, 2). All these rules come with automatic fixes!

Example in parsnip, example in igraph.

Should your package depend on dplyr, there’s a group of (currently two) rules for this as well!

Conclusion

Automatic tools are extremely useful for guiding upkeep work. Thinking “let me clean up this repo” can be daunting , tools like Jarl provide a roadmap! They let you fix obvious problems, and at the same time, they can make you read some dusty corners of your codebase. Hannah’s work on parsnip inspired Maëlle to run Jarl on igraph (influencer influenced back!), and she too can confirm it was both useful and satisfying. Thanks Etienne for that cool tool!

Note that you could run Jarl checks manually as we did, or you could tell a LLM to run Jarl. To quote Hannah’s colleague Emil Hvitfeldt, “When coding or using coding agents, one way to improve your workflow is by using CLI tools with a very clear focus.”. 🫡

What’s even better with Jarl is that it is actively developed, which you can confirm by skimming through the rich changelog!

The goodpractice package has been recommended by rOpenSci since it was first started just over 10 years ago by Gábor Csárdi. We used to ask our editors to manually run goodpractice on all packages submitted to software peer-review, and then to ask authors to fix any notable issues flagged by the package. It is now integrated within our own pkgcheck system, and used to automatically identify any goodpractice issues with all new submissions. The package changed maintainers several times before the previous maintainers gave the green light for us to take over maintenance of the package two years ago (28th May 2024).

We’re really pleased to share that we’ve recently rolled out a host of updates and extensions to the package. These make it both easier to use, and more powerful. This was a collaborative effort between new package author, Athanasia Mo Mowinckel, current maintainer, Mark Padgham, and the generative AI tool Claude. We describe the process at the end of this tech note.

Easier control of checks

The goodpractice package is a convenience wrapper around several other packages including rcmdcheck, lintr, cyclocomp, and desc, along with a few hand-coded checks within the package itself. The previous version of goodpractice had a total of 230 checks, generally prefixed with the name of the package which defined each check. Checks were identifiable with the single function, all_checks(). The only way to control which checks were run was to pass a checks parameter to the main function as a character vector of the names of checks you wanted to run. So, for example, if you wanted to skip the rcmdcheck checks, you had to do something like this:

mychecks <- grepv("^rcmdcheck", all_checks(), invert = TRUE)
gp(checks = mychecks)

That wasn’t easy! And honestly, most people just didn’t bother.

This update finally makes it easier to control checks, by defining them in “groups”, which generally correspond to the separate packages that run the actual checks. The groups can be seen with the new all_check_groups() function, and controlled with the checks_by_group() function. Checks can be controlled by simply naming the check groups you want to run, like this:

gp(checks = checks_by_group("description", "lintr"))

New check groups

The documentation for the all_check_groups() function shows all the new check groups added in this update, including:

Many of these checks are powered by treesitter, the extremely efficient syntax parsing library used by GitHub — which is genuinely neat to have working in R. The number of checks has been increased from 230 to 338, with all listed in the output of the all_checks() function.

Improved check reporting

The goodpractice package has always been designed for console output. This updated version now provides immediate and consistent detail on check progress while running. The cli package is also used to give consistently formatted output for all check groups.

The large increase in checks also means that directly printing goodpractice results may fill several screens of output. This update also adds a groups parameter to the print() method, to enable printing check results only for specified groups. This means you can run the main gp() function once, then step through each check group by printing results only for that group, fixing those, and then moving on to the next. We’ve found this turns what could feel like an overwhelming wall of output into a manageable to-do list. For example:

x <- gp()
print(x, "description")
#> Aww! Shining package! Keep up the priceless work!

print(x, "namespace")
#> ── It is good practice to ─────────────────────────────────────────────────────────────────────────────────────────────────────────────
#>
#> ✖ remove or use internal functions that are defined but never called. Dead code increases maintenance burden.
#>
#> R/utils.R:3
#> R/utils.R:73
#>
#> ✖ define exported (user-facing) functions before internal helper functions within each R source file.
#>
#> R/api.R:85
#>
#> ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Notes on the development process

From Mo (Athanasia)

I’ll be honest with you: a lot of this contribution was done with an AI assistant (Claude Code using Opus 4.5) at my elbow. I want to say something about that, because I think the honest version is more useful than the marketing version. The way Mark approached reviewing this work was very thoughtful and helpful.

Based on his feedback and how it was structured, I’ve learned a lot about what a good code review looks like, and it’s been absolutely wonderful. As a person who has mainly worked on their own code-bases alone, I have adopted a style of working that often creates diff monsters (hundreds of files changed), which can make reviewing very hard. Indeed, my first PR to this project was such a monster, and Mark pushed back asking for several smaller PRs he could actually manage to review. This is also where I learned about git worktrees (Thank you Maëlle!) and asking Claude to split the work up into several worktrees for easier review, was actually the first substantial change to how I now approach working with an AI assistant. Through this collaboration I learned a lot about splitting my work into better sizes and chunks.

The shape of it was something like this:

I’d locate an issue I thought was meaningful to tackle, and provide Claude Code with the issue context and possibly an idea of how to solve it. Once it had a solution, I’d review it, push back where it felt off, and we’d iterate. Mark would then review the PR and point out the things I’d missed. Three-way collaboration, more or less, with the AI doing the typing and me doing the deciding.

What worked well was scaffolding. Drafting a new check, wiring up the prep step that goes with it, generating the test cases for the edge paths I’d otherwise forget — that kind of work compresses really nicely with an AI. I would often ask it to generate some tests first, then create code that would pass the tests. This way we had a clear idea of what we wanted the new code to do, and then solve it.

What worked less well was anything involving judgement I hadn’t articulated yet. The first few times Claude opened a PR for me, it left the test-plan checkboxes unticked — even when the tests already passed. That’s not wrong exactly, but it’s misleading to a reviewer. I had to say “no, check the box if the test exists and passes; an unchecked box reads as TODO.” Similarly, when Mark left inline code suggestions on a PR, Claude tried to helpfully re-implement them locally — which would have stripped Mark’s attribution off his own contribution. We had to agree: suggestions get accepted on GitHub, not retyped.

And then there’s the unglamorous part. It would often forget instructions, despite having them documented in agents.md and local memory for the project. These were mostly trivial, but at times fairly bad. Some of the first PRs we made, Mark pointed out that the solutions were using regexp rather than AST (Abstrat Syntax Trees). I have to admit, I didn’t really know about AST before starting this project, and I am so glad I now know of it. Claude, despite being told very clearly that we wanted AST solutions, would often forget and implement regexp based solutions. It would also often revert to using for-loops rather than vectorization, and creating nested for-loops into the 3rd or 4th level — which is just horrible to follow as a human.

If you take one thing from this aside, take this: AI-assisted contribution didn’t mean handing the package over to a machine. It meant I could move faster on the parts I already understood, explore more confidently on the parts I didn’t, and spend my actual attention on the decisions that mattered — what to check for, how to group it, what to call it, and what to leave out. The friction taught me where to watch closely. The speed-ups taught me where I could trust the loop.

It’s a different way of working, and I’m still figuring out the shape of it, but it has enabled me to contribute to this project despite some very severe health issues making it hard for me to work as normal.

And one thing Claude always does better than me: writing good commit messages. I have found myself writing my own code, but asking Claude to commit them (making it look like Claude wrote the code, but I don’t care) because the commit messages are just so much better than what I write.

From Mark

The entire idea for this major update was initiated and driven by Mo. It was also my first real foray into using generative AI tools directly in rOpenSci packages, and I learnt a lot. After I rejected the initial monster PR, things settled down into much smaller and manageable PRs that were always focussed on one specific thing.

From that point, Mo was effectively the coder (assisted by Claude), and I was the reviewer. I never knew how much of the actual code was typed versus machine-generated, but was generally pleasantly surprised that I felt no need to inquire. Nearly every PR was obviously going to improve the package, and many of them were genuinely creative ideas. (That’s where I disagree slightly with Mo’s general description of the process: I am convinced a lot of the work behind this update came directly from her brilliant insights and experience, rather than her passive description of looking over pre-existing PRs.)

The process started in Feb 2026, and involved 70 pull requests. So many of these really were independent and new ideas. That enabled me to view each one with fresh eyes, and to think about whether I might approach anything in different ways. Over so many PRs, there was a lot of back-and-forth, from pushing back on Claude insisting on nested loops, to figuring out whether code was best parsed and analysed as text, or as a syntax tree. As Mo indicated, a lot of those discussions ultimately converged towards us bringing the power of treesitter into the package, and even helping to replace previous text-based code checks with more efficient and accurate AST approaches.

Our collaboration was very pleasant and enriching, and really felt like a direct cooperation between Mo as the ideas factory, me as the reviewer, and Claude as nothing more than a mediator of our ideas. The key role of Claude throughout the process was in handling all of the fiddly, technical details. We both looked carefully at every single line of code, but the use of Claude enabled our conversations to remain at higher, conceptual levels than what would have happened if we had to actually do all the technical implementation ourselves. I think that is the aspect that I found most surprising: That the use of Claude made our collaboration feel less technical, and therefore somehow even more human. And that gave us the ability to work though 70 pull requests representing over 100 new checks, all ready for everybody to use.

Let us know what you think

Like all rOpenSci packages, goodpractice is a community effort that lives through community use and feedback. We’d love to hear what you think, via email, or through issues on the GitHub repository.

https://www.techtonique.net contains tools for Exploratory Data Analysis (EDA), editors for R and Python code, tools for data visualization, no-code web interfaces for various data science tasks, a language-agnostic API for machine learning tasks (classification, regression, survival analysis, reserving, forecasting etc.).

I recently noticed a spike in sign-ups (not sure how they noticed it was up again, without official announcement…), and I thought it was a good opportunity to share that techtonique.net is back. More like a passion project, or part of a portfolio (for now). The API is available and evolving. You can use it for free (with rate limiting), but please note that it is slightly slower than it used to be (indeed, I used to have Azure Credits thanks to Microsoft for Startups => a faster server). It still serves the responses, in a reasonable time though, and I will try to optimize it as much as possible.

It is worth mentioning that I removed the stochastic simulation API for now, as it required (more technical) to run R in Python, through a Docker container.

Here are some examples of how to use the API for machine learning tasks in R and Python (there are also no-code interfaces for these tasks in the website, and the API is language-agnostic, so you can use it with any programming language that can make HTTP requests):

The starting point is to signup/login (if you’re facing issues, contact support@techtonique.net) and get a token from: https://www.techtonique.net/token. Then, you can use the token in API requests for machine learning tasks. Each response is a prediction, as envisaged by the chosen model, and based on the input data.

1 – R example:

#!/usr/bin/env Rscript

# Install httr if needed: install.packages("httr")
# All you need is a token from www.techtonique.net/token, then run the script
library(httr)

BASE_URL   <- "https://www.techtonique.net"
GITHUB_RAW <- "https://raw.githubusercontent.com/Techtonique/datasets/main"

DATASETS <- list(
  univariate     = paste0(GITHUB_RAW, "/time_series/univariate/a10.csv"),
  multivariate   = paste0(GITHUB_RAW, "/time_series/multivariate/ice_cream_vs_heater.csv"),
  classification = paste0(GITHUB_RAW, "/tabular/classification/breast_cancer_dataset2.csv"),
  regression     = paste0(GITHUB_RAW, "/tabular/regression/boston_dataset2.csv"),
  raa            = paste0(GITHUB_RAW, "/tabular/triangle/raa.csv"),
  abc            = paste0(GITHUB_RAW, "/tabular/triangle/abc.csv"),
  km             = paste0(GITHUB_RAW, "/tabular/survival/kidney.csv"),
  ridge_survival = paste0(GITHUB_RAW, "/tabular/survival/gbsg2_2.csv")
)

# ---------------------------------------------------------------------------
# Helpers
# ---------------------------------------------------------------------------

get_token <- function() {
  args <- commandArgs(trailingOnly = TRUE)
  idx  <- which(args == "--token")
  if (length(idx) > 0 && idx < length(args)) return(args[idx + 1])
  cat("Please enter your JWT token: ")
  readLines(con = "stdin", n = 1)
}

# Download a GitHub dataset to a temp file and return its path.
# Using a real file is the only reliable way to do multipart uploads in httr.
fetch_dataset <- function(key) {
  url      <- DATASETS[[key]]
  filename <- basename(url)
  cat(sprintf("  Fetching %s from GitHub... ", filename))
  tmp <- tempfile(fileext = ".csv")
  resp <- GET(url, write_disk(tmp, overwrite = TRUE))
  stop_for_status(resp)
  cat("OK\n")
  tmp   # return the temp file path
}

make_request <- function(endpoint, token, dataset_key = NULL, params = list()) {
  url     <- paste0(BASE_URL, endpoint)
  headers <- add_headers(Authorization = paste("Bearer", token))

  if (!is.null(dataset_key)) {
    tmp_path <- fetch_dataset(dataset_key)
    on.exit(unlink(tmp_path), add = TRUE)   # clean up temp file when done
    body <- list(file = upload_file(tmp_path, type = "text/csv"))
    resp <- POST(url, headers, query = params, body = body, encode = "multipart")
  } else {
    resp <- GET(url, headers, query = params)
  }

  if (http_error(resp)) {
    cat(sprintf("  ERROR %s: %s\n", status_code(resp),
                content(resp, as = "text", encoding = "UTF-8")))
    return(NULL)
  }
  content(resp, as = "parsed", type = "application/json")
}

print_response <- function(resp) {
  if (is.null(resp)) return(invisible(NULL))
  for (key in names(resp)) {
    val <- resp[[key]]
    if (is.list(val) || length(val) > 6) {
      cat(sprintf("  %s: [%s ...]\n", key, paste(head(unlist(val), 6), collapse = ", ")))
    } else {
      cat(sprintf("  %s: %s\n", key, paste(val, collapse = ", ")))
    }
  }
}

# ---------------------------------------------------------------------------
# Test sections
# ---------------------------------------------------------------------------

test_forecasting <- function(token) {
  cat("\n=== Testing Forecasting Endpoints ===\n")

  cat("\nTesting univariate forecasting...\n")
  resp <- make_request("/forecasting", token,
    dataset_key = "univariate",
    params = list(base_model = "RidgeCV", n_hidden_features = 5,
                  lags = 25, type_pi = "kde", replications = 4, h = 3))
  print_response(resp)

  cat("\nTesting multivariate forecasting...\n")
  resp <- make_request("/forecasting", token,
    dataset_key = "multivariate",
    params = list(base_model = "RidgeCV", n_hidden_features = 5, lags = 25, h = 3))
  print_response(resp)
}

test_ml <- function(token) {
  cat("\n=== Testing Machine Learning Endpoints ===\n")

  cat("\nTesting classification...\n")
  resp <- make_request("/mlclassification", token,
    dataset_key = "classification",
    params = list(base_model = "RandomForestClassifier",
                  n_hidden_features = 5, predict_proba = TRUE))
  print_response(resp)

  cat("\nTesting regression...\n")
  resp <- make_request("/mlregression", token,
    dataset_key = "regression",
    params = list(base_model = "RidgeCV", n_hidden_features = 5, return_pi = TRUE))
  print_response(resp)
}

test_reserving <- function(token) {
  cat("\n=== Testing Reserving Endpoints ===\n")

  cat("\nTesting RidgeCV...\n")
  resp <- make_request("/mlreserving", token,
    dataset_key = "raa",
    params = list(method = "RidgeCV"))
  print_response(resp)

  cat("\nTesting LassoCV...\n")
  resp <- make_request("/mlreserving", token,
    dataset_key = "abc",
    params = list(method = "LassoCV"))
  print_response(resp)
}

test_survival <- function(token) {
  cat("\n=== Testing Survival Analysis Endpoints ===\n")

  cat("\nTesting Kaplan-Meier...\n")
  resp <- make_request("/survivalcurve", token,
    dataset_key = "km",
    params = list(method = "km"))
  print_response(resp)

  cat("\nTesting Ridge survival...\n")
  resp <- make_request("/survivalcurve", token,
    dataset_key = "ridge_survival",
    params = list(method = "RidgeCV", patient_id = 0))
  print_response(resp)
}

# ---------------------------------------------------------------------------
# Main
# ---------------------------------------------------------------------------

main <- function() {
  token <- get_token()
  test_forecasting(token)
  test_ml(token)
  test_reserving(token)
  test_survival(token)
}

main()

2 - Python example:

import argparse
import requests
import os
import io
from typing import Dict, Any

# All you need is a token from www.techtonique.net/token, then run the script

# Base URL for API endpoints
base_url = "https://www.techtonique.net"

# Base URL for raw GitHub content
GITHUB_RAW = "https://raw.githubusercontent.com/Techtonique/datasets/main"

# Dataset paths within the GitHub repo
DATASETS = {
    "univariate":       f"{GITHUB_RAW}/time_series/univariate/a10.csv",
    "multivariate":     f"{GITHUB_RAW}/time_series/multivariate/ice_cream_vs_heater.csv",
    "classification":   f"{GITHUB_RAW}/tabular/classification/breast_cancer_dataset2.csv",
    "regression":       f"{GITHUB_RAW}/tabular/regression/boston_dataset2.csv",
    "raa":              f"{GITHUB_RAW}/tabular/triangle/raa.csv",
    "abc":              f"{GITHUB_RAW}/tabular/triangle/abc.csv",
    "km":               f"{GITHUB_RAW}/tabular/survival/kidney.csv",
    "ridge_survival":   f"{GITHUB_RAW}/tabular/survival/gbsg2_2.csv",
}


def get_token() -> str:
    """Get token from command line argument or prompt"""
    parser = argparse.ArgumentParser(description='Test API endpoints')
    parser.add_argument('--token', help='JWT token for authentication')
    args = parser.parse_args()

    if args.token:
        return args.token

    return input("Please enter your JWT token: ")


def fetch_dataset(dataset_key: str) -> tuple[io.BytesIO, str]:
    """
    Download a dataset from GitHub and return it as an in-memory bytes buffer
    together with a filename, ready to be passed to requests as a file upload.
    """
    url = DATASETS[dataset_key]
    filename = url.split("/")[-1]
    print(f"  Fetching {filename} from GitHub...", end=" ")
    response = requests.get(url)
    response.raise_for_status()
    print("OK")
    return io.BytesIO(response.content), filename


def make_request(
    url: str,
    token: str,
    method: str = "POST",
    file_tuple: tuple = None,   # (BytesIO, filename)
    params: Dict = None,
) -> Dict[str, Any]:
    """Make an API request and return the response."""
    headers = {"Authorization": f"Bearer {token}"}

    try:
        if method == "POST":
            files = None
            if file_tuple:
                buf, filename = file_tuple
                files = {"file": (filename, buf, "text/csv")}
            response = requests.post(url, headers=headers, files=files, params=params)
        else:
            response = requests.get(url, headers=headers, params=params)

        response.raise_for_status()
        return response.json()

    except requests.exceptions.RequestException as e:
        print(f"Error making request to {url}:")
        print(f"Status code: {e.response.status_code if hasattr(e, 'response') else 'N/A'}")
        print(f"Response: {e.response.text if hasattr(e, 'response') else str(e)}")
        return None


def test_forecasting(token: str):
    print("\n=== Testing Forecasting Endpoints ===")

    print("\nTesting univariate forecasting...")
    response = make_request(
        f"{base_url}/forecasting", token,
        file_tuple=fetch_dataset("univariate"),
        params={"base_model": "RidgeCV", "n_hidden_features": 5,
                "lags": 25, "type_pi": "kde", "replications": 4, "h": 3},
    )
    if response:
        print("Response:", response)

    print("\nTesting multivariate forecasting...")
    response = make_request(
        f"{base_url}/forecasting", token,
        file_tuple=fetch_dataset("multivariate"),
        params={"base_model": "RidgeCV", "n_hidden_features": 5, "lags": 25, "h": 3},
    )
    if response:
        print("Response:", response)


def test_ml(token: str):
    print("\n=== Testing Machine Learning Endpoints ===")

    print("\nTesting classification...")
    response = make_request(
        f"{base_url}/mlclassification", token,
        file_tuple=fetch_dataset("classification"),
        params={"base_model": "RandomForestClassifier",
                "n_hidden_features": 5, "predict_proba": True},
    )
    if response:
        print("Response:", response)

    print("\nTesting regression...")
    response = make_request(
        f"{base_url}/mlregression", token,
        file_tuple=fetch_dataset("regression"),
        params={"base_model": "RidgeCV", "n_hidden_features": 5, "return_pi": True},
    )
    if response:
        print("Response:", response)


def test_reserving(token: str):
    print("\n=== Testing Reserving Endpoints ===")

    print("\nTesting RidgeCV...")
    response = make_request(
        f"{base_url}/mlreserving", token,
        file_tuple=fetch_dataset("raa"),
        params={"method": "RidgeCV"},
    )
    if response:
        print("Response:", response)

    print("\nTesting LassoCV...")
    response = make_request(
        f"{base_url}/mlreserving", token,
        file_tuple=fetch_dataset("abc"),
        params={"method": "LassoCV"},
    )
    if response:
        print("Response:", response)


def test_survival(token: str):
    print("\n=== Testing Survival Analysis Endpoints ===")

    print("\nTesting Kaplan-Meier...")
    response = make_request(
        f"{base_url}/survivalcurve", token,
        file_tuple=fetch_dataset("km"),
        params={"method": "km"},
    )
    if response:
        print("Response:", response)

    print("\nTesting Ridge survival...")
    response = make_request(
        f"{base_url}/survivalcurve", token,
        file_tuple=fetch_dataset("ridge_survival"),
        params={"method": "RidgeCV", "patient_id": 0},
    )
    if response:
        print("Response:", response)


def main():
    token = get_token()
    test_forecasting(token)
    test_ml(token)
    test_reserving(token)
    test_survival(token)


if __name__ == "__main__":
    main()

Three hundred seventy-six of the new packages submitted to CRAN in April were still there in mid-May. Here are my Top 40 picks in twenty-three categories: Actuarial Analysis, Archaeology, Biology, Causal Inference, Computational Methods, Ecology, Economics, Environmental Studies, Epidemiology, Finance, Functional Data Analysis, Health Technology Assessment, Machine Learning, Medical Statistics, Meta Analysis, Networks, Physics, Programming, Statistics, Time Series, Utilities, and Visualization.

By default, ggplot2 places the legend outside the plot area (usually on the right). However, sometimes you may want to move the legend inside the plot to save space or improve the layout. This post explores how to achieve this using theme() parameters.

library(ggplot2)

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  theme_bw() +
  theme(legend.position = c(0.8, 0.8))

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  theme_bw() +
  theme(
    legend.position = c(1, 1),
    legend.justification = c("right", "top"),
    legend.background = element_blank()
  )

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  facet_wrap(~am) +
  theme_bw() +
  theme(
    legend.position = c(0.5, 0.2),
    legend.background = element_rect(fill = "white", color = "grey80")
  )

# Use 3 categories to leave the 4th spot in a 2x2 grid empty
mtcars_subset <- mtcars[mtcars$carb %in% c(1, 2, 4), ]

ggplot(mtcars_subset, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  facet_wrap(~carb, nrow = 2, ncol = 2) +
  theme_bw() +
  theme(
    # Coordinates c(0.75, 0.25) target the center of the empty bottom-right area
    legend.position = c(0.75, 0.25),
    legend.background = element_blank(),
    legend.justification = "center"
  )

© 2025 tidyomics. Content is published under Creative Commons CC-BY-4.0 License for the text and BSD 3-Clause License for any code. | R-Bloggers

You’ve set up all the preconditions.

You’ve triggered the action.

Now the specification needs to answer one question: did the system do the right thing?

That’s what Then steps are for. How precisely you answer it determines whether your specifications act as a reliable safety net or produce false confidence.

This article is the 3rd part of a series on writing BDD specifications for Shiny applications. We’ve built a data submission form, managed preconditions with Given steps, and modeled user interactions with When steps.

Read the previous articles to get full context, or continue here to focus on writing Then steps.

1. Behavior-Driven Development in R Shiny: A Step-By-Step Example
2. Behavior-Driven Development in R Shiny: Setting Up Test Preconditions with Given Steps
3. Behavior-Driven Development in R Shiny: Writing When Steps That Model User Behavior

Level-up your testing game! Grab your copy of the R testing roadmap.

The Purpose of Then

Then steps answer one question: What changed as a result of the user’s action?

Not how it changed internally. What the user can now observe — or what the system has now done — that wasn’t true before.

This distinction shapes every Then step you write. The assertion lives at the level of the outcome, not at the level of the mechanism that produced it.

# Outcome — what the user cares about
then_there_are_entries <- function(context, n) {
  expect_equal(context$storage$size(), n)
  context
}

# Mechanism — how the app stored it internally
then_the_database_table_has_n_rows <- function(context, n) {
  expect_equal(nrow(DBI::dbReadTable(context$conn, "entries")), n)
  context
}

Both assertions verify the same underlying fact — that the entry was saved — but the first one survives a switch from disk cache to database to API. The second breaks the moment you change the storage technology.

Assert what the user or system guarantees. Leave how it’s achieved to implementation tests.

What to Assert

Then steps verify outcomes across three kinds of observable evidence. These categories describe what you can check — they don’t prescribe how many steps to use. How to group assertions into steps is a separate question, covered in the next section.

User-visible state

Did the UI change the way a user would expect?

then_i_am_prompted_to_provide_required_fields <- function(context) {
  context$driver$expect_validation_feedback()
  context
}

Assertions use driver methods — the same translation layer that When steps use — so they’re protected from UI implementation details.

System state

Sometimes the most meaningful evidence isn’t what the user sees but what the system now holds.

then_the_entry_has_title <- function(context, expected_title) {
  entry <- context$storage$get_first()
  expect_equal(entry$title, expected_title)
  context
}

These assertions reach directly into the storage object that Given steps configured. They’re faster than UI assertions and more precise: they check the exact state of the system without waiting for the browser to render anything.

Side effects

Some behaviors produce no visible UI change and no stored data — they trigger side effects: emails, API calls, log entries. These still need verification.

then_email_notification_is_sent <- function(context) {
  context$email_service$expect_sent()
  context
}

then_i_am_informed_email_was_not_sent <- function(context) {
  context$driver$expect_visible("email_failure_message")
  context
}

The first assertion works because the email service test double (set up in Given) records whether it was called. The second checks that the app communicated the failure to the user — which is the behavior the specification is actually about.

Implementing Then Steps in the Driver

Then steps that check UI state belong in the driver, just like When steps. This keeps the assertion details hidden from the specification:

#' tests/testthat/setup-driver.R
MyAppDriver <- R6::R6Class(
  classname = "MyAppDriver",
  inherit = shinytest2::AppDriver,
  public = list(
    expect_visible = function(output_id) {
      # Find if HTML element is visible
      invisible(self)
    },
    expect_entry_count = function(n) {
      # Find number of HTML elements
      invisible(self)
    },
    expect_validation_feedback = function() {
      # Check if HTML element is visible
      invisible(self)
    }
  )
)

Each driver method is a named, reusable assertion. If the HTML structure changes, you fix it in one place.

Grouping Then Steps

The right question is not “how many assertions per step?” but “which assertions belong together?”

Group assertions that describe the same observable behavior. Split when outcomes can diverge independently.

Consider what happens when a user successfully submits an entry: the storage grows by one, and a confirmation message appears. These two outcomes are two sides of the same coin — if one is true, the other should be too. Splitting them into separate steps implies they can diverge, which invites the reader to wonder what it would mean for storage to succeed but no confirmation to appear, or vice versa. Grouping them into a single step names the behavior directly:

then_entry_is_submitted <- function(context) {
  expect_equal(context$storage$size(), 1)
  context$driver$expect_visible("confirmation_message")
  context
}

Email notification is different. Submission can succeed even when the email service fails — the two outcomes genuinely can diverge. That’s exactly when a separate step is the right call:

it("should submit entry and send notification", {
  given_no_content() |>
    given_an_authenticated_user(email = "user@example.com") |>
    given_email_service_is_available() |>
    when_i_submit_entry_with_all_required_fields() |>
    then_entry_is_submitted() |>
    then_notification_was_sent_to_the_authenticated_user()
})

Two steps, not three — because the spec now reflects the actual structure of the behavior. If then_entry_is_submitted fails, you know the core submission broke. If then_notification_was_sent_to_the_authenticated_user fails, you know the side effect broke. The split carries information because it maps to a real divergence point.

Then steps should also be read-only. They inspect state; they don’t change it. A Then step that modifies storage or triggers side effects is doing the wrong job. Keep the flow clean: Given sets up, When acts, Then observes.

Making Failure Messages Helpful

A failing test with a good message saves minutes. A failing test with a bad message wastes hours.

The most common mistake is letting low-level assertion failures surface directly. When expect_equal(nrow(df), 2) fails with "actual 0, expected 2", that tells you nothing about which scenario failed or what the data looked like.

The label argument sets the name testthat uses for the object (first argument) in the failure message. Keep it short and descriptive — testthat appends the actual and expected values itself:

then_there_are_entries <- function(context, n) {
  testthat::expect_equal(
    context$storage$size(), n,
    label = "number of entries in storage"
  )
  context
}

A failure now reads: "Expected number of entries in storage to equal n" — immediately clear without any manual formatting.

For UI assertions, label the element being checked:

expect_visible = function(output_id) {
  val <- self$get_value(output = output_id)
  testthat::expect_true(
    !is.null(val) && nchar(val) > 0,
    label = sprintf("output '%s'", output_id)
  )
  invisible(self)
}

A failure reads: "Expected output 'confirmation_message' to be TRUE" — which immediately tells you which element to look at.

What Doesn’t Belong in Then Steps

Don’t push implementation tests up to Then steps.

If you’re asserting the exact text of an error message, the CSS class applied to an invalid input, or the exact SQL that was executed — those are implementation details. They don’t belong here.

Acceptance-level Then steps answer: did the right thing happen from the user’s perspective?

The Complete Picture

Putting it all together, a well-formed specification has a clear structure at every level:

describe("data submission", {
  it("should submit entry and send notification", {
    given_no_content() |>
      given_an_authenticated_user(email = "user@example.com") |>
      given_email_service_is_available() |>
      when_i_submit_entry_with_all_required_fields() |>
      then_entry_is_submitted() |>
      then_notification_was_sent_to_the_authenticated_user()
  })

  it("should handle email service failure gracefully", {
    given_no_content() |>
      given_an_authenticated_user() |>
      given_email_service_is_unavailable() |>
      when_i_submit_entry_with_all_required_fields() |>
      then_entry_is_submitted() |>
      then_i_am_informed_email_was_not_sent()
  })

  it("should require all required fields", {
    given_no_content() |>
      given_an_authenticated_user() |>
      when_i_submit_entry_with_missing_required_fields() |>
      then_i_am_prompted_to_provide_required_fields()
  })
})

Each specification reads like a sentence. None of them mention shinytest2, input IDs, or database queries. The implementation lives behind the DSL, where it can change without touching the specifications.

Wrapping up

Then steps are where a specification earns its credibility.

A specification that only tests easy outcomes produces false confidence. One that asserts user-visible state, system state, and side effects actually catches real problems. Assert outcomes, not implementations. Group assertions by observable behavior and split them only where they can genuinely diverge. Write failure messages that save time. Push implementation details down to unit and module tests.

With Given, When, and Then steps in place, the specifications read like requirements and run on every build. That’s worth more than any testing framework on its own.

I’ve been using Unix and Linux systems for nearly 20 years. When I found myself with a Windows laptop for a while I felt lost and quickly installed Windows Subsystem for Linux. And yet the number of commands I know and use regularly is surprisingly short: cd, ls, rm, pwd, mkdir, source, node, npm and, of course, git. Even then I don’t think I really “know” git.

In his excellent book “Don’t Make Me Think Revisited”, Steve Krug describes how

Faced with any sort of technology, very few people take the time to read instructions. Instead, we forge ahead and muddle through, making up our own vaguely plausible stories about what we’re doing and why it works.

Krug’s book is about web and mobile usability but the point he makes here applies across technological domains. And it is safe to say I’ve been “muddling through” with Unix. If you asked me whether something was a Unix command or part of the shell I’d probably just shrug and say something like “I… I don’t know that!?”.

Until recently StackOverflow had always been my crutch to fall back on. From the frequency with which it appears in answers, I know that find is a very useful and versatile command. However, the odds of me remembering how to use it without looking it up are indistinguishable from 0.

But now we have alternatives in the form of various large language models or, to be more precise, multi-modal AI Assistants (like Claude and ChatGPT) and Agents (like Claude Code and Codex). I’d describe myself as AI-agnostic: I see benefits, I worry about issues. So it was with some (I’d say healthy) degree of scepticism I started using Claude to assist me in writing some shell functions to automate tasks I do or would like to do regularly.

I say “I” wrote. Reality is of course that I asked Claude to write and rewrite things for me and then I questioned why it did what it did. This probably makes it sound like I was assessing Claude for a job but it’s actually that I want to understand what has been written and, as we’ve already covered, I am not very good at this stuff.

Task One: fixing a common git mistake

One of my most common slip-ups with git is to commit changes to one branch (usually main) that were meant to go on a new feature branch. I know a way to recover from this: create the new branch I meant to create all along; do an interactive rebase to remove the commit from main; switch to the new feature branch I just created. There’s not that many steps to the process but it’s still a bit of a faff. Let’s ask Claude:

# Create and switch to the correct branch from current state
git switch -c correct-branch

# Go back to the wrong branch and undo the commit (keeps changes staged)
git switch wrong-branch
git reset --soft HEAD~1

# Discard the changes
git restore --staged .
git restore .

git switch -c correct-branch
git switch wrong-branch
git reset --hard HEAD~1

Here we hit a couple of issues.

1. Neither of Claude’s suggestions did the final step of what I wanted: moving me back to the new, correct, branch. This is entirely on me. I forgot to ask (and didn’t notice for a bit). I do that kind of thing quite a lot.
2. Even for simple tasks, Claude’s responses can be quite verbose.

The problem here is not a practical one regarding the use of Claude or an alternative agent, the real problem is it’s quite difficult to write a blog post of a sensible length that actually goes anywhere while accurately recounting the conversation you have with Claude. So what follows is a paraphrase rather than a transcript; shortened for the sake of your sanity and mine.

Tim

Can I use git switch – instead?

Claude

Yes, and it’s cleaner. git switch - saves you typing the wrong branch name out explicitly.

Tim

Seems like the sort of thing I should make into a Bash function

Claude

Agreed. Something like this (with an added safety check):

git-move-last() {
 if [ -z "$1" ]; then
 echo "Usage: git-move-last <new-branch-name>"
 return 1
 fi
 git switch -c "$1"
 git switch -
 git reset --hard HEAD~1
}

Tim

I’ve gone for git-behead. If I wanted to move to the new branch at the end I just add another git switch -?

Claude

Ha .

Exactly:

git-behead() {
 if [ -z "$1" ]; then
 echo "Usage: git-behead <new-branch-name>"
 return 1
 fi
 git switch -c "$1"
 git switch -
 git reset --hard HEAD~1
 git switch -
}

Tim

Ok, one more idea. Suppose I haven’t been looking what I’m doing and I want to remove more than just the last commit to a new branch. Can we recreate the above but with an optional commit count that defaults to 1?

Claude

git-behead() {
 if [ -z "$1" ]; then
 echo "Usage: git-behead <new-branch-name> [commit-count]"
 return 1
 fi
 local count="${2:-1}"
 git switch -c "$1"
 git switch -
 git reset --hard HEAD~"$count"
 git switch -
}

Tim

Could you comment anything you think isn’t self-explanatory?

Claude

git-behead() {
 if [ -z "$1" ]; then
 echo "Usage: git-behead <new-branch-name> [commit-count]"
 return 1
 fi
 local count="${2:-1}" # default to 1 commit if not specified
 git switch -c "$1" # create new branch at current HEAD
 git switch - # switch back to original branch
 git reset --hard HEAD~"$count" # remove commits from original branch
 git switch - # switch to new branch
}

Putting this in my .bashrc file gives me a simple command that I can invoke whenever I make the mistake I regularly make and an optional argument to use whenever I haven’t been paying attention to the branch I’m on for an extended period. It’s also short enough that I think I follow every line, despite my limited knowledge of Bash, and there are comments there for when future me has forgotten. This conversation took about fifteen minutes and included more questions than I’ve included here, plus time I spent running various ad-hoc tests with the different iterations of the function. That seems like a pretty efficient use of my time.

Task Two: listing image files

I do a lot of data visualisation, I look after the artwork for this website and I take photographs for our conferences. In short, I deal with a lot of images in various formats. It would be nice to be able to list only images and their key properties in a specific location with a simple function. Let’s ask Claude:

Tim

Can you write me a Bash script for displaying a list of images in a directory that shows file name, width, height and size (in kB) and nothing else?

Claude

Here’s a clean script using identify from ImageMagick (widely available) with a du fallback for file size:

#!/usr/bin/env bash

DIR="${1:-.}"

if ! command -v identify &>/dev/null; then
 echo "Error: imagemagick is required (install with: brew install imagemagick / apt install imagemagick)" >&2
 exit 1
fi

shopt -s nullglob nocaseglob
files=("$DIR"/*.{jpg,jpeg,png,gif,webp,bmp,tiff,tif,avif})
shopt -u nullglob nocaseglob

if [[ ${#files[@]} -eq 0 ]]; then
 echo "No images found in: $DIR" >&2
 exit 0
fi

printf "%-40s %8s %8s %10s\n" "FILENAME" "WIDTH" "HEIGHT" "SIZE (kB)"
printf "%-40s %8s %8s %10s\n" "--------" "-----" "------" "---------"

for f in "${files[@]}"; do
 name="$(basename "$f")"
 read -r width height < <(identify -format "%w %h" "$f" 2>/dev/null | head -1)
 size_kb=$(awk "BEGIN { printf \"%.1f\", $(wc -c < "$f") / 1024 }")
 printf "%-40s %8s %8s %10s\n" "$name" "$width" "$height" "$size_kb"
done

Supported formats: jpg, jpeg, png, gif, webp, bmp, tiff, avif.

Example output:

FILENAME WIDTH HEIGHT SIZE (kB)
-------- ----- ------ ---------
banner.png 1200 630 84.3
avatar.jpg 400 400 32.1
hero.webp 1920 1080 210.7

I asked for a script, I got a script. I wanted a function. This one is, again, on me.

Tim

Sorry, can we make this a function rather than a script?

Claude

The key changes: shebang removed, exit replaced with return, and variables are now local. To use it, source it in your shell and call it as normal:

imgls() {
 local dir="${1:-.}"

 if ! command -v identify &>/dev/null; then
 echo "Error: imagemagick is required (install with: brew install imagemagick / apt install imagemagick)" >&2
 return 1
 fi

 shopt -s nullglob nocaseglob
 local files=("$dir"/*.{jpg,jpeg,png,gif,webp,bmp,tiff,tif,avif})
 shopt -u nullglob nocaseglob

 if [[ ${#files[@]} -eq 0 ]]; then
 echo "No images found in: $dir" >&2
 return 0
 fi

 printf "%-40s %8s %8s %10s\n" "FILENAME" "WIDTH" "HEIGHT" "SIZE (kB)"
 printf "%-40s %8s %8s %10s\n" "--------" "-----" "------" "---------"

 local f name width height size_kb
 for f in "${files[@]}"; do
 name="$(basename "$f")"
 read -r width height < <(identify -format "%w %h" "$f" 2>/dev/null | head -1)
 size_kb=$(awk "BEGIN { printf \"%.1f\", $(wc -c < "$f") / 1024 }")
 printf "%-40s %8s %8s %10s\n" "$name" "$width" "$height" "$size_kb"
 done
}

The conversation goes on a bit from here and the function becomes more and more detailed. It would be tedious to show the whole conversation but to summarise, “we”:

1. Add support for SVG, including extracting dimensions from the viewBox attribute.
2. Fix a bug with GIF dimensions.
3. Tweak the header text.
4. Add support for recursive searching of a directory.
5. Fix the layout when doing a recursive search.
6. Round the values in the SIZE column
7. Add comments.

The final result:

imgls() {
 local recursive=0

 # Parse flags — currently only -r (recursive) is supported
 while getopts ":r" opt; do
 case $opt in
 r) recursive=1 ;;
 *) echo "Usage: imgls [-r] [directory]" >&2; return 1 ;;
 esac
 done
 # Shift past any parsed flags so $1 is the directory argument
 shift $((OPTIND - 1))
 OPTIND=1

 # Use first argument as directory, default to current directory if omitted
 local dir="${1:-.}"

 # identify is provided by imagemagick and used to read raster image dimensions
 if ! command -v identify &>/dev/null; then
 echo "Error: imagemagick is required (install with: brew install imagemagick / apt install imagemagick)" >&2
 return 1
 fi

 local exts=("jpg" "jpeg" "png" "gif" "webp" "bmp" "tiff" "tif" "avif" "svg")
 local files=()

 if [[ $recursive -eq 1 ]]; then
 # Build a find command matching all extensions, case-insensitively
 local find_args=("$dir" "-type" "f" "(")
 for i in "${!exts[@]}"; do
 [[ $i -gt 0 ]] && find_args+=("-o")
 find_args+=("-iname" "*.${exts[$i]}")
 done
 find_args+=(")")
 while IFS= read -r f; do
 files+=("$f")
 done < <(find "${find_args[@]}" | sort)
 else
 # nullglob: unmatched globs expand to nothing instead of being treated as literals
 # nocaseglob: match extensions case-insensitively (e.g. .JPG as well as .jpg)
 shopt -s nullglob nocaseglob
 files=("$dir"/*.{jpg,jpeg,png,gif,webp,bmp,tiff,tif,avif,svg})
 shopt -u nullglob nocaseglob
 fi

 if [[ ${#files[@]} -eq 0 ]]; then
 echo "No images found in: $dir" >&2
 return 0
 fi

 # In recursive mode show the relative path, otherwise just the filename
 printf "%-40s %11s %12s %10s\n" "FILENAME" "WIDTH (px)" "HEIGHT (px)" "SIZE (kB)"
 printf "%-40s %11s %12s %10s\n" "--------" "----------" "-----------" "---------"

 local f name width height size_kb viewbox current_subdir="" subdir
 for f in "${files[@]}"; do
 if [[ $recursive -eq 1 ]]; then
 # Print a header line when we enter a new subdirectory
 subdir="$(dirname "${f#$dir/}")"
 if [[ "$subdir" != "$current_subdir" ]]; then
 [[ -n "$current_subdir" ]] && echo ""
 echo "${subdir}/"
 current_subdir="$subdir"
 fi
 name="$(basename "$f")"
 else
 name="$(basename "$f")"
 fi
 # wc -c counts raw bytes; awk converts to kB with one decimal place
 size_kb=$(awk "BEGIN { printf \"%d\", $(wc -c < "$f") / 1024 }")

 if [[ "${f,,}" == *.svg ]]; then
 # SVGs are XML so we can parse dimensions directly without imagemagick.
 # Prefer viewBox (e.g. "0 0 100 200") as it's the most reliable source
 # of the intended coordinate space; fall back to width/height attributes.
 viewbox=$(grep -oi 'viewBox="[^"]*"' "$f" 2>/dev/null | head -1 | grep -oi '"[^"]*"' | tr -d '"')
 if [[ -n "$viewbox" ]]; then
 # viewBox is "min-x min-y width height" — fields 3 and 4
 width=$(echo "$viewbox" | awk '{printf "%g", $3}')
 height=$(echo "$viewbox" | awk '{printf "%g", $4}')
 else
 width=$(grep -oi 'width="[^"]*"' "$f" 2>/dev/null | head -1 | grep -oi '"[^"]*"' | tr -d '"px"')
 height=$(grep -oi 'height="[^"]*"' "$f" 2>/dev/null | head -1 | grep -oi '"[^"]*"' | tr -d '"px"')
 fi
 # ${var:--} expands to "-" if var is empty or unset
 width="${width:--}"
 height="${height:--}"
 else
 # [0] selects only the first frame, preventing animated GIFs from
 # producing one line of output per frame
 read -r width height < <(identify -format "%w %h" "${f}[0]" 2>/dev/null)
 fi

 printf "%-40s %11s %12s %10s\n" "$name" "$width" "$height" "$size_kb"
 done
}

The “development time” here was longer and I’d be fibbing if I said I understood every line of this function. But I do get the general principles and understand what it can and can’t do. And being able to list all images (of nearly all relevant types) in a directory with just their key properties in a nice tabular format is a very nice productivity win for me.

Final Thoughts

Discussions about AI easily tend towards the extremes: ‘it’s amazing’, ‘it’s a disaster’, ‘it’s useless’. This is particularly unhelpful when focusing on how successfully or otherwise it executes a single task. All we’ve really done in this post is create a couple of Bash scripts. For me the AI in question, Claude, has been useful. No more, no less. Despite this, the process did make me think a lot about how the way we interact with machines is changing. While it’s easy to over-personify AI, this line from the film that gave this blog post its title seems now, in 2026, to have been prescient:

The advent of computers, and the subsequent accumulation of incalculable data has given rise to a new system of memory and thought parallel to your own.

For updates and revisions to this article, see the original post

To leave a comment for the author, please follow the link and comment on their blog: The Jumping Rivers Blog.

---

R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.

---

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Continue reading: Ghost in the Shell Script]]> 401507 https://www.r-bloggers.com/2026/05/ropensci-news-digest-may-2026/ Thu, 28 May 2026 00:00:00 +0000 https://ropensci.org/blog/2026/05/28/news-may-2026/

Dear rOpenSci friends, it’s time for our monthly news roundup! You can read this post on our blog. Now let’s dive into the activity at and around rOpenSci!

rOpenSci HQ

15 Years of rOpenSci, and we’re just getting started 🎉
This y...

Continue reading: rOpenSci News Digest, May 2026]]> [social4i size="small" align="align-left"]

-->

[This article was first published on rOpenSci - open tools for open science, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)

---

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Dear rOpenSci friends, it’s time for our monthly news roundup! You can read this post on our blog. Now let’s dive into the activity at and around rOpenSci!

rOpenSci HQ

15 Years of rOpenSci, and we’re just getting started

This year we celebrate 15 years of rOpenSci! First up we have a coworking session followed by a couple casual virtual community celebrations. Please join us! Read more in our blog post about these upcoming events.

Also exciting is that this blog post about our 15 year anniversary was featured in the R Weekly Highlights podcast hosted by Eric Nantz and Mike Thomas.

Champions Program update

The rOpenSci Champions Program is currently running two very active cohorts, with many activities happening across the program, and everything is on track!

The 2025–2026 cohort is wrapping up their projects and outreach activities, with several Champions presenting their work at events such as R/Pharma, useR!, Posit, and LatinR 2026. We also recently held a cohort meeting bringing together Champions and mentors from the 2025–2026 cohort and one meeting for mentors only, to share mentoring tips and tricks.

Meanwhile, the 2026–2027 cohort has started their training activities, including three weekly training workshops for Champions and a mentor training workshop. Mentors and Champions have also had their first meetings together to get to know each other and begin planning their collaboration.

Stay tuned to our events page for Champions outreach activities and to our blog to learn more about Champions’ projects.

May is Maintainer Month

Open source software doesn’t sustain itself. Behind every R package, there is at least one person who responds to issues, reviews pull requests, keeps up with dependency changes, and makes sure everything still works.

We joined the #MaintainerMonth celebration with a month-long series of rOpenSci’s maintainer spotlights: 36 maintainers from 15 countries across 4 continents, maintaining more than 50 packages that together serve thousands of researchers and data practitioners around the world.

Follow our social media (Mastodon and LinkedIn) and the official hashtag (#MaintainerMonth) to learn more about the maintainers who support open source software. Thank you to those who agreed to participate and to all the maintainers in our community.

Software-Review update

This month saw a slight policy shift in the way editors handle new software review submissions, assisted by an internal update to our bot system. Previously, our rotating Editor-in-Chief (EiC) was solely responsible for initial decisions on whether to proceed with submissions. Once a decision was reached, a handling editor took over, and generally guided each submission through to approval. However, recent increases in submissions have been too much for one EiC to handle. Submissions will now be passed on more quickly to handling editors who will then make initial scope and fit decisions.

As part of this change, the EiC can now ask the bot to “ping editors”. Editors will receive an email alerting them of this new submission and can then decide whether to take it on as editor. Each time an editor clicks on a link in the email, the EiC will receive an email notification, and once an editor is assigned, all links will be automatically deactivated.

For anybody interested in how to develop an email alert system like this, please contact us and we’ll have happy to share what we learnt along the way. Full code is in this R file.

Social media cards for R-universe

When posting about your package or universe on social media, you can get a pretty social media card featuring important information about (respectively):

• the package such as its maintainer, its keywords, its URL, its version, its number of stars, etc.

• the universe such as its number of packages and contributors, etc.

More information in the R-universe documentation.

Coworking

Read all about coworking!

• Tuesday June 2nd 2026, 14:00 Europe Central (12:00 UTC) “15 years with rOpenSci”, with Steffi LaZerte and cohost Noam Ross.
  • Explore rOpenSci projects
  • Do a deep dive into the rOpenSci blog history
  • Meet rOpenSci’s Executive Director, Noam Ross, and discuss how rOpenSci has evolved over the last 15 years.
• Tuesday July 7nd 2026, 09:00 Americas Pacific (16:00 UTC) “Debugging in R”, with Yanina Bellini Saibene and cohost Shannon Pileggi.
  • Read up on debugging in R
  • Meet community host, Shannon Pileggi, and discuss tips and tricks for debugging in R.

And remember, you can always cowork independently on work related to R, work on packages that tend to be neglected, or work on what ever you need to get done!

Software

New versions

The following ten packages have had an update since the last newsletter: cffr (v1.4.0), gutenbergr (v0.5.1), dataset (0.4.4), sofa (v0.4.1), saperlipopette (v1.0.0), medrxivr (snapshot), textreuse (v1.0.1), EDIutils (v2.1.0), rsi (v0.3.3), and UCSCXenaTools (v1.7.0).

The writexl package has a new maintainer, Bill Denney. NLMR is now maintained by Jakub Nowosad.

Software Peer Review

There are eighteen recently closed and active submissions and 4 submissions on hold. Issues are at different stages:

• One at ‘6/approved’:

  • saperlipopette, Create Example Git Messes. Submitted by Maëlle Salmon.

• Three at ‘5/awaiting-reviewer(s)-response’:

  • nycOpenData, Convenient Access to NYC Open Data API Endpoints. Submitted by Christian Martinez.

  • ernest, A Toolkit for Nested Sampling. Submitted by Kyle Dewsnap. (Stats).

  • pkgmatch, Find R Packages Matching Either Descriptions or Other R Packages. Submitted by mark padgham.

• Six at ‘4/review(s)-in-awaiting-changes’:

  • pvEBayes, Empirical Bayes Methods for Pharmacovigilance. Submitted by Yihao Tan. (Stats).

  • RAMEN, RAMEN: Regional Association of Methylome variability with the Exposome and geNome. Submitted by Erick Navarro-Delgado.

  • logolink, An Interface for Running NetLogo Simulations. Submitted by Daniel Vartanian.

  • rcrisp, Automate the Delineation of Urban River Spaces. Submitted by Claudiu Forgaci. (Stats).

  • priorsense, Prior Diagnostics and Sensitivity Analysis. Submitted by Noa Kallioinen. (Stats).

  • galamm, Generalized Additive Latent and Mixed Models. Submitted by Øystein Sørensen. (Stats).

• One at ‘3/reviewer(s)-assigned’:

  • ciecl, International Classification of Diseases ICD-10/ICD-11 for Chile. Submitted by Rodolfo Tasso.

• Five at ‘2/seeking-reviewer(s)’:

  • EpiStrainDynamics, Infer temporal trends of multiple pathogens. Submitted by Saras Windecker. (Stats).

  • lakefetch, Calculate Fetch and Wave Exposure for Lake Sampling Points. Submitted by jeremylfarrell.

  • RAQSAPI, A Simple Interface to the US EPA Air Quality System Data Mart API. Submitted by mccroweyclinton-EPA.

  • fcmconfr, Fuzzy Cognitive Map Analysis in R. Submitted by benroston. (Stats).

  • coevolve, Fit Bayesian Generalized Dynamic Phylogenetic Models using Stan. Submitted by Scott Claessens. (Stats).

• Two at ‘1/editor-checks’:

  • metasurvey, Reproducible Survey Data Processing with Step Pipelines. Submitted by Mauro Loprete.

  • LBDiscoverAnalysis, Co-occurrence Discovery Models and Visualization for Biomedical LBD. Submitted by Chao Liu.

Find out more about Software Peer Review and how to get involved.

On the blog

• New Mentoring Team with Experienced Mentors and New Voices by Alber Hamersson Sánchez Ipia, Pablo Paccioretti, Erick Navarro Delgado, Guadalupe Pascal, Andrea Gomez Vargas, Monika Avila Marquez, Luis D. Verde Arregoitia, Francisco Cardozo, Elio Campitelli, Pao Corrales, and Yanina Bellini Saibene. Meet the new team of mentors who will accompany our Champions in their projects for a year, sharing experience, guidance and enthusiasm. Other languages: Nuevo equipo de mentor(a|e)s con experiencia y nuevas voces (es).

• 15 Years of rOpenSci, and We’re Just Getting Started by The rOpenSci Team.

Calls for contributions

Calls for maintainers

If you’re interested in maintaining any of the R packages below, you might enjoy reading our blog post What Does It Mean to Maintain a Package?.

• charlatan, create fake data in R. Issue for volunteering.

• landscapetools, R package for some of the less-glamorous tasks involved in landscape analysis. Issue for volunteering.

• hddtools, Tools to discover hydrological data, accessing catalogues and databases from various data providers. Issue for volunteering.

Calls for contributions

Refer to our help wanted page – before opening a PR, we recommend asking in the issue whether help is still needed.

Package development corner

Some useful information for R package developers.

devtools’ install functions now officially deprecated

The devtools::install_ functions like devtools::install_github() have now been officially deprecated in favor of pak. The manual page contains a migration guide. Time to update older READMEs!

New Git commands!

New in Git: git history! Thanks to Hugo Gruson for bringing this to our attention.

Imagine…

Oops, that old commit’s message had a typo! git history reword

Oops, that old commit is too big! git history split (to split it into two commits)

Git release notes; Git docs.

roxygen2 8.0.0

A new version of roxygen2 hit CRAN. Among the highlights are improvements for R6, S7, inheritance, and better documentation of roxygen2 itself, including the vignette on extending roxygen2 with your own tags and roclets. Release announcement.

Comment DESCRIPTION files

Have you noticed this line in the release notes of R 4.6.0?

read.dcf() now recognizes lines starting with # as comment lines. By Dirk Eddelbuettel, Laurent Gatto and Hugo Gruson.

This means it’s becoming possible to add comments to DESCRIPTION files, for instance to note why you added a given dependency.

{cross} R package for running code with different package versions

Have you ever used Git worktree to load several R package versions at once (in different sessions), for instance to create a benchmark? Davis Vaughan made such endeavors much smoother with his cross R package. cross uses Git worktree under the hood to install different package versions in temporary libraries and then runs R code with these different versions. Furthermore, it has a user-friendly interface!

For example, to compare the released version of vctrs to the developement version on GitHub, you could run the following.

cross::bench_versions(pkgs = c("vctrs", "r-lib/vctrs"), {
 library(vctrs)
 x <- c(1, NA, 2, 3, NA)
 bench::mark(missing = vec_detect_missing(x))
})

On attribution with a footnote

James Balamuta wrote two thoughtful posts on a tricky situation and its resolution. TL;DR James’ work on portable R was used in another repository with only minimal acknowledgement through a footnote in a comment. However, those involved came together to work out a resolution through meaningful conversation.

Last words

Thanks for reading! If you want to get involved with rOpenSci, check out our Contributing Guide. This guide will help direct you to the right place, whether you want to make code contributions, non-code contributions, or contribute in other ways such as through sharing use cases. You can also support our work through donations.

If you haven’t subscribed to our newsletter yet, you can do so though our signup form. Until it’s time for our next newsletter, you can keep in touch with us through our website, Mastodon, or LinkedIn. See you soon!

To leave a comment for the author, please follow the link and comment on their blog: rOpenSci - open tools for open science.

---

R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.

---

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Continue reading: rOpenSci News Digest, May 2026]]> 401509 https://www.r-bloggers.com/2026/05/survivor-now-includes-us50-and-au12/ Wed, 27 May 2026 09:54:21 +0000 http://gradientdescending.com/?p=3531 After a couple of big seasons survivoR v2.3.12 has been updated with US50 and AU12. Get it on: As of […]
The post survivoR now includes US50 and AU12 appeared first on Dan Oehm | Gradient Descending.

Continue reading: survivoR now includes US50 and AU12]]> [social4i size="small" align="align-left"]

After a couple of big seasons survivoR v2.3.12 has been updated with US50 and AU12.

Get it on:

• Github
• XLSX download
• JSON endpoints

As of writing, the survivoR package is closing in on 30,000 downloads, which is wild to me. Not only that, but the CRAN installs are probably the lowest volume of all formats. Installs directly from Git and the XLSX downloads are probably much higher. I never thought this data would be so popular.

I don’t have much of a social media presence, pretty much only Bluesky these days, and a very small following there. Regardless many people reach out to say thanks for pulling it together. It has enabled them to build their own websites (of which there are quite a few – Survivor-reference, survivorELO), be used for research papers, Master theses, school projects, help potential castaways with their Survivor auditions, help future Survivor players prep for their season, even then Survivordle web app.

I enjoy hearing about how others are utilizing it. If you have experience with it as well, please reach out—I am always keen to discuss Survivor!

The post survivoR now includes US50 and AU12 appeared first on Dan Oehm | Gradient Descending.

Introduction

In my previous job my work computer was a Windows desktop – yes, those were the days before laptops and hotdesking!

My PhD student was interested in Bayesian methods and we put together an R package which included some Stan models. I was always frustrated by how slowly these compiled on our Windows machines. A few years later, when I got a MacBook Air I was shocked how much faster they compiled.

On my Windows machine our mrbayes package takes 3 minutes 55 seconds to compile and install. On my M4 MacBook Air it takes 1 minute 16 seconds.

The following tips show how to improve those timings.

To generate the timings I used

time R CMD INSTALL --preclean .

Big win 1: Enable parallel compilations with the MAKEFLAGS environment variable

Set the MAKEFLAGS environment variable in your ~/.Renviron file. This controls how many make jobs run concurrently. Choose a number no larger than the number of processing cores your machine has. To find this run

# Windows - in a Git Bash shell
echo $NUMBER_OF_PROCESSORS

# macOS
sysctl -n hw.logicalcpu

# Ubuntu Linux
nproc

A reasonable starting point is your core count, or a few fewer to leave headroom for whatever else you’re doing during a compilation. For example,

# In ~/.Renviron
MAKEFLAGS=-j6

Close and restart R/RStudio after making this change.

On my Windows machine this reduced the build from 3:55 to 1:15. To find your own sweet spot empirically, see the example at the end of Big win 2.

Big win 2: Enable C/C++ compiler cache using ccache

Install ccache, I find it easiest to use a package manager, e.g.,

# macOS
brew install ccache

# Ubuntu/Debian Linux
apt install ccache

# Windows
winget install ccache

Whichever installation method you use make sure ccache is on your PATH after installation. You can test with, say,

ccache --version

To enable ccache, on macOS and Linux this goes in ~/.R/Makevars; on Windows it’s ~/.R/Makevars.win (create the directory and file if they don’t exist), set

# macOS
CC = ccache clang
CXX = ccache clang++
CXX17 = ccache clang++

# Windows and Linux
# Most Linux users will be on gcc by default
# Change to clang if you're using that
CC = ccache gcc
CXX = ccache g++
CXX17 = ccache g++

After a first compilation run for the cache to be generated, subsequent compilations are much faster.

• Windows, second compilation: 18 seconds
• M4 MacBook Air, second compilation: 5 seconds

Perhaps more importantly, if, say, your package has 5 models and you only amend the code for one of them, ccache knows to use the cache for the 4 unchanged models.

• Windows, second compilation, only 1 model edited: 1 minute 10 seconds
• M4 MacBook Air, second compilation, only 1 model edited: 19 seconds

You can verify ccache is working, by observing the timing decrease and by checking the output of

ccache -s

It is also useful to zero the ccache statistics before a timing run with

ccache -z

Testing which of your models takes the longest to compile

Here’s a quick script to test which model takes the longest to compile. Save it as say test.sh at the top level of your repo and add ^test\.sh$ to your .Rbuildignore file (to avoid an R CMD check NOTE about unknown files at the top level).

for model in inst/stan/*.stan; do
  cp "$model" "$model.bak"
  # Insert at the top of the file
  sed -i "1i // benchmark $(date +%s%N)" "$model"
  ccache -z
  SECONDS=0
  R CMD INSTALL --preclean . >/dev/null 2>&1
  echo "$(basename $model): ${SECONDS}s"
  ccache -s | grep -E "Hits|Misses" | head -2
  mv "$model.bak" "$model"
done

Finding your MAKEFLAGS sweet spot

With ccache installed you can now benchmark different -jN values cleanly (the ccache -C calls ensure each run is a cold compile, so you measure raw compilation cost rather than cache hits). You can increase the number sequence up to the number of processing cores your machine has.

for j in 1 2 3 4 6 8 10; do
  ccache -C >/dev/null
  echo "=== -j$j ==="
  SECONDS=0
  MAKEFLAGS=-j$j R CMD INSTALL --preclean . >/dev/null 2>&1
  echo "elapsed: ${SECONDS}s"
done

The timings on my MacBook Air were

=== -j1 ===
elapsed: 76s
=== -j2 ===
elapsed: 48s
=== -j3 ===
elapsed: 35s
=== -j4 ===
elapsed: 36s
=== -j6 ===
elapsed: 27s
=== -j8 ===
elapsed: 27s
=== -j10 ===
elapsed: 28s

My MacBook Air has 10 cores, but only 4 of those are performance cores, so I settled on -j6 as that is where my timings plateaued — and it leaves headroom for me inevitably checking my email during a compilation.

Big win 3: Combining these in GitHub Actions workflows

In my .github/workflows/R-CMD-check.yaml I have steps for these speedups. Firstly, to set MAKEFLAGS.

      - name: Set parallel compilation flags (Linux and macOS)
        if: runner.os != 'Windows'
        shell: bash
        run: |
          NCPUS=$(nproc 2>/dev/null || sysctl -n hw.logicalcpu)
          echo "Detected ${NCPUS} processors"
          echo "MAKEFLAGS=-j${NCPUS}" >> ~/.Renviron

      - name: Set parallel compilation flags (Windows)
        if: runner.os == 'Windows'
        shell: pwsh
        run: |
          Write-Output "Detected $env:NUMBER_OF_PROCESSORS processors"
          Add-Content -Path "$HOME\.Renviron" -Value "MAKEFLAGS=-j$env:NUMBER_OF_PROCESSORS"

You can also use ccache in GitHub Actions, as follows:

      # ccache speeds up Stan model compilation dramatically on warm cache.
      # Note: Windows support via ccache-action is documented as "probably works"
      # rather than fully stable; if it causes issues, scope this step to non-Windows.
      - name: Setup ccache
        uses: hendrikmuhs/ccache-action@v1.2.23
        with:
          # Key invalidates when Stan models or DESCRIPTION change.
          # Older caches partially seed new ones via restore-keys.
          key: ccache-${{ matrix.config.os }}-R-${{ matrix.config.r }}-${{ hashFiles('inst/stan/**/*.stan', 'DESCRIPTION') }}
          restore-keys: |
            ccache-${{ matrix.config.os }}-R-${{ matrix.config.r }}-
            ccache-${{ matrix.config.os }}-R-
          max-size: "2G"

      - name: Configure R to use ccache (Linux and macOS)
        if: runner.os != 'Windows'
        shell: bash
        run: |
          mkdir -p ~/.R
          if [ "$RUNNER_OS" = "macOS" ]; then
            cat >> ~/.R/Makevars <<'EOF'
          CC = ccache clang
          CXX = ccache clang++
          CXX14 = ccache clang++
          CXX17 = ccache clang++
          CXX20 = ccache clang++
          EOF
          else
            cat >> ~/.R/Makevars <<'EOF'
          CC = ccache gcc
          CXX = ccache g++
          CXX14 = ccache g++
          CXX17 = ccache g++
          CXX20 = ccache g++
          EOF
          fi
          echo "--- ~/.R/Makevars ---"
          cat ~/.R/Makevars

      - name: Configure R to use ccache (Windows)
        if: runner.os == 'Windows'
        shell: pwsh
        run: |
          New-Item -ItemType Directory -Force -Path "$HOME\.R" | Out-Null
          $makevars = @"
          CC = ccache gcc
          CXX = ccache g++
          CXX14 = ccache g++
          CXX17 = ccache g++
          CXX20 = ccache g++
          "@
          Add-Content -Path "$HOME\.R\Makevars.win" -Value $makevars
          Write-Output "--- ~/.R/Makevars.win ---"
          Get-Content "$HOME\.R\Makevars.win"

You can see the full file in my repo.

This reduced my ubuntu-latest run for r-release from 7 minutes 30 seconds to 4 minutes 49 seconds.

Big win 4: Switch to clang

I found that switching from gcc to clang gives a noticeable speedup; the single core compile time dropped from 3 minutes 55 seconds to 3 minutes flat on my Windows machine.

To do this you need to install clang. On Windows you install clang within RTools45 — more involved than on Linux, but doable.

# Windows within RTools45 Bash shell
# Launch C:\rtools45\ucrt64.exe
# You may need to close and reopen the shell after the first command
pacman -Syu
pacman -S mingw-w64-ucrt-x86_64-clang

# Ubuntu/Debian Linux
sudo apt install clang

At this point on Windows running

which clang

should return /ucrt/bin/clang.

Switch to clang in ~/.R/Makevars (if you’re not using ccache delete that prefix)

# On Linux
CC = ccache clang
CXX = ccache clang++
CXX14 = ccache clang++
CXX17 = ccache clang++
CXX20 = ccache clang++

and in ~/.R/Makevars.win on Windows

# On Windows
CC = ccache C:/rtools45/ucrt64/bin/clang.exe
CXX = ccache C:/rtools45/ucrt64/bin/clang++.exe
CXX17 = ccache C:/rtools45/ucrt64/bin/clang++.exe

Windows users will need to add the following to PATH

C:\rtools45\ucrt64\bin
C:\rtools45\usr\bin

You can verify things are working by running

R CMD config CXX17

I believe you need clang version 18 or later to see the speedups.

Small win 1: WSL users should use the native file system

Within WSL it is possible to access files from within its native Linux filesystem, i.e., within /home/user/..., and also on the Windows filesystem, e.g., in /mnt/c/.... I believe file operations are noticeably faster within /home/user/....

Naive guesses that made no difference

I had wondered whether running a non-debug compilation with say

pkgbuild::compile_dll(debug = FALSE)

would speed things up. It turns out it does not. For Stan models, most of the time is spent in C++ template instantiation by the compiler, not in optimisation passes — so disabling debug flags or lowering the optimisation level barely helps.

I also wondered whether using R on Windows Subsystem for Linux would speed things up just by virtue of being on Linux. It did not, timings using gcc on Windows and WSL Ubuntu were essentially identical. The advantage of using WSL is that it is easier to switch to using clang on Linux.

(Money no object) Big win 5: Switch to an Apple Silicon Mac

Apple silicon Macs have excellent single threaded performance, their unified memory architecture has very high bandwidth, they have large L1 and L2 caches, and fast NVMe SSDs. Together these produce very fast Stan model compilation times, even on the lowest end Apple Silicon Macs.

Summary

In summary, five big wins and one small win for speeding up Stan model compilation in R packages.

A specification tells a story.

Given describes the world before the action. When describes the action itself. Then describes what changed as a result.

If Given is the setup and Then is the payoff, When is where the plot happens, and how you write it determines whether your specifications stay readable for months or decay after the very first change you make to your project.

This article is part of a series on Behavior-Driven Development for Shiny applications. We’ve been building a data submission form from scratch, adding an email notification feature, and managing preconditions with Given steps.

Read the previous articles to get up to speed, or continue here to focus on how to write When steps.

1. Behavior-Driven Development in R Shiny: A Step-By-Step Example
2. Behavior-Driven Development in R Shiny: Setting Up Test Preconditions with Given Steps

Level-up your testing game! Grab your copy of the R testing roadmap.

The Purpose of When

When steps answer one question: What is the user doing?

Not what button they clicked. Not what input ID was set. What they did, from their perspective.

The difference matters because UI implementations change constantly, user behaviors change only when business requirements change. Input IDs get renamed, buttons get moved, forms get refactored into modules. But users still interact with the same form, they submit the same data. If your When steps name those interface details, they break every time something shifts. If they describe user intent, they survive almost any UI change.

A When step should read like a sentence from a user story.

Compare these two:

# Implementation-coupled! Breaks when the submit button is removed or chaned
when_i_click_submit_button <- function(context) {
  ...
}

# Behavior-focused! Survives any UI refactor
when_i_submit_entry_with_all_required_fields <- function(context) {
  ...
}

The second version tells you what the user accomplished, not how the app was wired.

That’s the goal.

Starting the App

When steps are where the Shiny app launches — but not directly.

As we established in the Given article, the app starts lazily: the first When step calls .start_driver(), which creates the driver with all configuration accumulated from Given steps. Every subsequent When step interacts with the already-running app.

#' tests/testthat/setup-dsl.R
when_i_submit_entry_with_all_required_fields <- function(context) {
  .start_driver(context)
  context$driver$fill_required_fields(
    url = "https://example.com/",
    title = "Example"
  )
  context
}

Calling .start_driver() in every When step is safe — it’s a no-op if the driver already exists:

.start_driver <- function(context) {
  if (is.null(context$driver)) {
    context$driver <- MyAppDriver$new(
      storage = context$storage,
      email_service = context$email_service,
      user = context$user
    )
  }
  context
}

This means Given steps are purely configuration — they never touch the running app. The app only starts when the user’s first action is about to happen. This makes Given steps fast, composable, and easy to reason about.

Implementing When Steps

The When step function itself should be thin. Its only job is to delegate to the driver and pass the context forward.

All implementation details live in the driver:

#' tests/testthat/setup-driver.R
MyAppDriver <- R6::R6Class(
  classname = "MyAppDriver",
  inherit = shinytest2::AppDriver,
  public = list(
    fill_required_fields = function(url, title) {
      self$set_inputs(url = url, title = title)
      self$click(input = "submit")
      self$wait_for_idle()
    },
    fill_all_fields = function(url, title, description) {
      self$set_inputs(url = url, title = title, description = description)
      self$click(input = "submit")
      self$wait_for_idle()
    }
  )
)

The driver encapsulates everything: which inputs to set, what to click, what to wait for. The When step just calls the right driver method by name.

This separation pays off immediately. If the submit button ID changes from "submit" to "btn_submit", you fix it in one place — the driver method — and every specification that calls fill_required_fields continues to work unchanged.

Note that the same driver method can be called from multiple When steps.

The driver is a translation layer. It translates user intent (fill required fields) into UI mechanics (set these inputs, click this button).

Naming When Steps

Good names follow a simple pattern: when_<who>_<verb>_<object>.

The verb describes the action from the user’s point of view. The object is what they acted on — expressed in domain language, not UI language.

# Good! We use domain language
when_i_submit_entry_with_all_required_fields()
when_i_submit_entry_with_missing_title()
when_i_delete_the_first_entry()
when_i_inspect_the_submissions_list()

# Bad! UI details are leaking in
when_i_click_the_submit_button()
when_i_clear_the_title_input()
when_i_navigate_to_slash_list()

Domain names survive redesigns. UI names couple your specifications to the current implementation.

One more rule: one action per When step. A step named when_i_fill_and_submit_the_form() is doing two things. That makes it harder to compose and harder to understand which action caused which outcome.

# One action per step — composable
when_i_fill_in_the_form(url = "https://example.com", title = "Example") |>
  when_i_submit_the_form()

# Doing too much — hard to reuse
when_i_fill_and_submit_the_form()

Smaller, focused steps let you test multi-step flows precisely.

My Thoughts on Navigation Steps

You might think, this is an easy example.

Real apps aren’t single-page forms. They have navigation, multiple pages, modals, they might feel like navigating through a maze. It’s not that simple to interact with all the features! It’s not, but we can apply the same principles to more complex interactions.

Here’s what I do.

In apps we have pages. Users need to navigate to those pages before they can interact with them. How do we name When steps that represent navigation?

I prefer to name them based on their intent, what they’re trying to achieve, rather than the mechanics of how they get there. For example:

# Good! Focuses on the user's goal, not the UI structure
when_i_inspect_submissions()
when_i_open_the_first_entry()
when_i_change_settings(...) # composite step, implicitly navigates to the settings page and changes settings

# Bad! Reveals that there is a "submissions" page, what if we move submissions listing to another page?
when_i_navigate_to_submissions_page()

This way, the step names reflect the user’s goals, not the UI structure. If we later change how navigation works — say we add another page and move our targeted component there — we can update the driver methods without changing the When step names.

That’s how specifications stay stable and focused on user behavior, not implementation details.

That’s how specifications stay stable and don’t need updating every time the UI changes.

Multi-Step Flows

When a scenario involves several user actions in sequence, chain them:

it("should allow editing a submitted entry", {
  given_existing_entries() |>
    given_an_authenticated_user() |>
    when_i_open_the_first_entry() |>
    when_i_update_the_title(title = "Updated Title") |>
    when_i_submit_the_form() |>
    then_the_entry_has_title("Updated Title")
})

Each step does one thing. The sequence reads like a user story. And if the assertion fails, you can see exactly which action preceded the broken state.

This is also where the context pipeline pattern earns its keep. Every step receives context and returns context, so you can add or remove steps in the middle without restructuring the whole test:

it("should show confirmation after submitting", {
  given_no_content() |>
    given_an_authenticated_user() |>
    when_i_submit_entry_with_all_required_fields() |>
    then_entry_is_submitted()
})

The pipeline works because every step function — Given, When, or Then — has the same contract: receive context, return context. That uniformity is what lets pipe operator connect them.

Here is the pattern on its own, with no Shiny involved. The When steps are thin — each one just calls a driver method and returns context:

# A minimal driver that records what it was asked to do
MockDriver <- function() {
  form <- NULL
  submitted <- FALSE
  list(
    fill_required_fields = function(url, title) {
      form <<- list(url = url, title = title)
    },
    submit = function() {
      submitted <<- TRUE
    },
    get_form = function() form,
    was_submitted = function() submitted
  )
}

# When steps are thin: call a driver method, return context
when_i_fill_in_the_form <- function(context, url, title) {
  context$driver$fill_required_fields(url = url, title = title)
  context
}

when_i_submit_the_form <- function(context) {
  context$driver$submit()
  context
}

ctx <- new.env(parent = emptyenv())
ctx$driver <- MockDriver()

ctx |>
  when_i_fill_in_the_form(url = "https://example.com", title = "Example") |>
  when_i_submit_the_form()

The step functions contain no UI details — those live entirely inside MockDriver. Swapping the driver is all it takes to point the same steps at a different implementation.

Testing Error Paths

User interactions that trigger failures are still described with When steps. The step describes what the user attempted, not whether it succeeded.

it("should require all required fields", {
  given_no_content() |>
    given_an_authenticated_user() |>
    when_i_submit_entry_with_missing_required_fields() |>
    then_i_am_prompted_to_provide_required_fields()
})

The When step looks identical to the happy-path version — which is the point. The user tried to submit with missing fields. The difference lives in the Then step, which checks what the app communicated back to the user.

when_i_submit_entry_with_missing_required_fields <- function(context) {
  .start_driver(context)
  context$driver$fill_required_fields(
    url = "https://example.com/",
    title = ""  # Missing required field
  )
  context
}

You don’t need to create special “error path” When steps with names like when_i_incorrectly_submit(). Name them after what the user did, not after whether it was correct. The Then step will check whether the app responded correctly to that action.

Parameterising When Steps

Sometimes you want to test multiple variations of the same action. Rather than creating a separate step for each variation, make the step accept parameters:

when_i_submit_entry_with_title <- function(context, title) {
  .start_driver(context)
  context$driver$fill_required_fields(
    url = "https://example.com/",
    title = title
  )
  context
}

Now you can express different scenarios clearly:

it("should reject titles that are too short", {
  given_no_content() |>
    given_an_authenticated_user() |>
    when_i_submit_entry_with_title(title = "ab") |>
    then_i_am_prompted_to_provide_required_fields()
})

it("should accept titles of the minimum length", {
  given_no_content() |>
    given_an_authenticated_user() |>
    when_i_submit_entry_with_title(title = "abc") |>
    then_there_are_entries(n = 1)
})

Use parameters when the difference between scenarios is data, not behavior. Keep the step name stable; let the arguments express the variation.

The Cucumber Way

cucumber allows you to write multiple variants of scenarios with Scenario Outline and Examples keywords.

In a cucumber feature file this scenario would look like this:

Feature: Data submission form validation
  Scenario Outline: Submitting entries with different title lengths
    Given no content
    And an authenticated user
    When I submit an entry with title <title>
    Then I am prompted to provide required fields
    Examples:
      | title |
      | "ab"  |
      | "abc" |

In our implementation we don’t have a built-in way to express scenario outlines, but we can achieve the same effect by writing multiple scenarios that call the same parameterised When step.

Signs a When Step Is Too Complex

A When step that runs more than a few lines of logic is usually trying to do too much.

1. If a step is setting state — checking whether something exists before interacting with it, or conditionally taking different actions — that logic belongs in Given steps or in the driver implementation, not the When step itself.
2. If a step has branching logic — doing one thing when a flag is set and another when it isn’t — split it into two steps with clear names.
3. If a step is making assertions — checking that something happened mid-flow — move those checks to Then steps. A When step should interact and nothing more. Mixing assertions into When steps makes failures ambiguous: you can’t tell whether the setup was wrong or the outcome was wrong. There might be exceptions to assert whether we’re on the right path in a multi-step flow – to fail eagerly – but generally, try to keep assertions in Then steps.

The Pattern in Practice

Here’s the full shape of a specification using the When steps we’ve built:

describe("data submission", {
  it("should submit entry and send notification", {
    given_no_content() |>
      given_an_authenticated_user() |>
      given_email_service_is_available() |>
      when_i_submit_entry_with_all_required_fields() |>
      then_entry_is_submitted() |>
      then_email_notification_is_sent()
  })

  it("should require all required fields", {
    given_no_content() |>
      given_an_authenticated_user() |>
      when_i_submit_entry_with_missing_required_fields() |>
      then_i_am_prompted_to_provide_required_fields()
  })

  it("should allow editing a submitted entry", {
    given_existing_entries() |>
      given_an_authenticated_user() |>
      when_i_open_the_first_entry() |>
      when_i_update_the_title(title = "Updated Title") |>
      when_i_submit_the_form() |>
      then_the_entry_has_title("Updated Title")
  })
})

The specifications read naturally. None of them mention input IDs, button selectors, or shinytest2. Those details live in the driver, hidden away from the scenarios they serve.

Note how specifications don’t even reveal it’s a Shiny app. They don’t reveal how we interact with it — shinytest2, selenider, anything goes. It’s all hidden and irrelevant to the story we’re telling. You can swap the internals and keep the same specifications true. You can even swap the system implementation entirely, and as long as it still satisfies the same business requirements, the specifications don’t need touching. It’s live and executable — not a list of tickets in an external system no one reads.

That’s exactly the opposite of what happens when we write tests that are tightly coupled to the UI structure.

Wrapping up

When steps model user behavior, not UI implementation.

That distinction is what keeps specifications readable days, weeks, months later, when the form has been refactored, button IDs have changed, and nobody remembers what the original implementation looked like. Keep steps focused on one action. Put the implementation details in the driver. Use domain language, not UI language.

Specifications written this way tend to survive refactors you haven’t thought of yet.

Reposted from the original at https://blog.stephenturner.us/p/ctrlvee-extract-external-r-code-insert-inline-positron-rstudio-addin. 

Ever find yourself looking through a pkgdown page or a Quarto book, copying and pasting code chunks from your browser into your IDE? I do, and it’s a minor annoyance.1

My friend and colleague VP Nagraj published a new R package called ctrlvee that makes this a lot easier.

• CRAN: https://cran.r-project.org/package=ctrlvee

• GitHub: https://github.com/vpnagraj/ctrlvee

It does one thing. Put your cursor anywhere in an R script in Positron or RStudio, call the add-in, provide a URL, and a few milliseconds later you’ll have all the code from that page in your editor, separated by chunk boundaries (along with some metadata and a note to check the license!).

The package README provides a demonstration using the “Data Validation and QA” chapter of my Data Science Team Training book (dstt.stephenturner.us).

1. Install the package: install.packages("ctrlvee")

2. Run the add-in. In Positron you’ll open the command palette, search for Run RStudio Addin, then extract external R code and insert inline. You’ll get a modal asking you for a URL.

3. Paste one in. E.g., https://dstt.stephenturner.us/validation.html

4. The R code from the website appears in your editor

Here’s a demo.

Here’s what the extracted/inserted code looks like, from this source.

# -----------------------------------------------------------------
# Chunks fetched by ctrlvee from: https://dstt.stephenturner.us/validation.html
# Strategy: Rendered HTML page
# Date: 2026-05-16 05:14:44
# Chunks: 8
# NOTE: Check the source license before reusing this code.
# -----------------------------------------------------------------

flu <- data.frame(
    week = c(1, 2, 3, 4, 4),
    county = c("Fairfax", "Arlington", NA, "Loudoun", "Loudoun"),
    disease = c("Flu", "Flu", "Flu", "Flu", "Flu"),
    cases = c(23, 41, 18, -5, 12),
    rate = c(2.1, 3.8, 1.6, NA, 1.1)
)

flu

# ---- chunk boundary ----

if (any(flu$cases < 0, na.rm = TRUE)) {
    stop("Negative case counts detected. Inspect raw data before proceeding.")
}

# ---- chunk boundary ----

stopifnot(
    "Negative case counts" = all(flu$cases >= 0, na.rm = TRUE),
    "Missing county values" = !anyNA(flu$county),
    "Duplicate records" = !anyDuplicated(flu[, c("week", "county")])
)

# ---- chunk boundary ----

install.packages("pointblank")

# ---- chunk boundary ----

library(pointblank)

agent <- create_agent(tbl = flu, label = "Weekly flu surveillance") |>
    col_vals_gte(
        columns = cases,
        value = 0,
        label = "Case counts must be non-negative"
    ) |>
    col_vals_not_null(
        columns = c(week, county),
        label = "Week and county cannot be missing"
    ) |>
    rows_distinct(
        columns = c(week, county),
        label = "No duplicate week/county records"
    ) |>
    interrogate()

agent

# ---- chunk boundary ----

create_agent(tbl = flu, label = "Weekly flu surveillance — extended") |>
    col_is_numeric(
        columns = c(cases, rate),
        label = "Case count and rate must be numeric"
    ) |>
    col_vals_in_set(
        columns = disease,
        set = c("Flu", "COVID-19", "RSV"),
        label = "Disease must be from the approved list"
    ) |>
    col_vals_between(
        columns = week,
        left = 1,
        right = 52,
        label = "Week must be between 1 and 52"
    ) |>
    col_vals_gte(
        columns = rate,
        value = 0,
        na_pass = TRUE,
        label = "Rate must be non-negative (NAs allowed)"
    ) |>
    interrogate()

# ---- chunk boundary ----

if (!all_passed(agent)) {
    stop("Data validation failed. Review the agent report before proceeding.")
}

# ---- chunk boundary ----

library(readr)
library(pointblank)

flu <- read_csv("data/flu-2024.csv")

# Validate immediately after reading
agent <- create_agent(tbl = flu, label = "flu-2024 validation") |>
    col_vals_gte(columns = cases, value = 0, label = "No negative counts") |>
    col_vals_not_null(columns = c(week, county), label = "No missing keys") |>
    rows_distinct(columns = c(week, county), label = "No duplicate records") |>
    interrogate()

if (!all_passed(agent)) {
    stop("Validation failed — see agent report above.")
}

Adding patterns to plots is a great way to improve accessibility (making plots colorblind-friendly) and to add an extra dimension of information. The ggpattern package provides a rich set of tools to achieve this in ggplot2.

# Prepare data
df <- mtcars %>%
  mutate(
    cyl = factor(cyl),
    gear = factor(gear),
    am = factor(am, labels = c("Automatic", "Manual"))
  )

# Create barplot
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_fill = "black",
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 1.5
  ) +
  scale_pattern_manual(values = c("stripe", "crosshatch")) +
  labs(
    title = "MPG by Cylinders, Gear, and Transmission",
    subtitle = "Patterns representing transmission type",
    x = "Cylinders",
    y = "Miles Per Gallon (MPG)",
    fill = "Gears",
    pattern = "Transmission"
  ) +
  theme_minimal()

p_base <- ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_spacing = 0.02
  ) +
  theme_minimal() +
  labs(title = "Default vs Scaled Legend")

# Default legend
p1 <- p_base + labs(subtitle = "Default (key_scale_factor = 1)")

# Scaled legend
p2 <- p_base + 
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 0.5
  ) +
  labs(subtitle = "Scaled (key_scale_factor = 0.5)")

p1

p2

# Spacing effect
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_spacing = 0.2, # Wider spacing
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_spacing = 0.5 (Sparser)") +
  theme_minimal()

# Density effect
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_density = 0.8, # Higher density
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_density = 0.8 (Denser)") +
  theme_minimal()

ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_fill = "white", # White pattern lines
    pattern_density = 0.5, # make it bigger so that the color is easier to see
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_fill = 'white'") +
  theme_minimal()

ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern_shape=gear),
    pattern = "regular_polygon",
    stat = "identity",
    position = "dodge",
    pattern_size = 0.5, # stroke line width
    pattern_density = 0.5, # increase the shape size
    pattern_spacing = 0.03,
    pattern_key_scale_factor = 1.5
  ) +
  scale_pattern_shape_manual(values = c("3"="circle", "4"="convex6", "5"="square")) + # manually set shapes
  labs(title = "Effect of mapping pattern_shape to gear") +
  theme_minimal()

sudo apt-get install libudunits2-dev
sudo apt install libproj22
sudo apt-get install libgdal-dev

If you’ve read any of my past posts you know I like to program in several different languages, some of which I like more than others. Sometimes a problem calls for a particular language to be used, and with that comes adjusting one’s brain to thinking in that language and using the appropriate idioms to leverage that language’s features. But what if I don’t want to?

I don’t want to

The line between R and Python has been heavily blurred the last few years, particularly with {reticulate} enabling us to use Python within R code, RStudio rebranding as Posit and taking on a strong Python development effort, releasing Positron as a multi-language IDE, and Quarto being a multi-language rethink of Rmarkdown.

I occasionally need to use Python directly – an SDK wrapping an API exists and I don’t particularly want to spend a lot of time writing my own R version, especially before I know what I want to get out of the endpoints. At this point I tend to bump up against my muscle-memory from R and try to use functions I’m familiar with from R, but which don’t actually exist in Python. Now, that might sometimes be because the pattern I’m trying to encode simply has a different name in Python; instead of an sapply(x, f)

sapply(c(2, 3, 4, 5), \(x) x ^ 2)
## [1]  4  9 16 25

I should reach for map, in which case I am reminded that this produces a lazy iterator that doesn’t show me the results

map(lambda x: x ** 2, [2, 3, 4, 5])
## <map object at 0x10d7fbee0>

and so I need to wrap it into a list to get the values out

list(map(lambda x: x ** 2, [2, 3, 4, 5]))
## [4, 9, 16, 25]

Or, I could use a list comprehension which isn’t lazy

[v ** 2 for v in [2, 3, 4, 5]]
## [4, 9, 16, 25]

That’s the idiom that I should be reaching for. Sure.

Other times there’s a package I need to use and a slightly different way of approaching the problem. In R I love the table() function for getting histogram-like counts of the unique values of a vector

table(c("b", "a", "c", "a", "b", "a"))
## 
## a b c 
## 3 2 1

which in Python looks like

from collections import Counter

sorted(Counter(["b", "a", "c", "a", "b", "a"]).items())
## [('a', 3), ('b', 2), ('c', 1)]

Probably Pythonistas remember that idiom and the package to import and the .items() extractor and the fact that they maybe want to sort the result. But I kept coming back to a question I ask myself: what if I don’t want to? Why is there not a function that wraps this idiom? If there was, why not just call it “table”? Admittedly, it’s far from the catchiest, most memorable, or most useful name, but it’s immediately recognisable to an R user (ditto for “sapply”).

One approach I considered here was to just call R from Python. That can be done, but I doubt I or anyone else wants to deal with that every time we want to iterate over a list. There’s a package on the Python package index which seems to support this nicely: https://pypi.org/project/r-functions/ but it’s wrappers around individual R files, via RScript. I’m thinking more along the lines of ‘native Python with an R interface’.

Python is an object-oriented language, but it has functions, so why not make one

from collections import Counter

def table(x):
    return dict(sorted(Counter(x).items()))

table(["b", "a", "c", "a", "b", "a"])
## {'a': 3, 'b': 2, 'c': 1}
def sapply(x, func):
    return [func(v) for v in x]
  
sapply([2, 3, 4, 5], lambda x: x ** 2)
## [4, 9, 16, 25]

and have a nicer function interface to apply these idioms? I thought about this a bit longer, and realised there’s lots of functions I use in R that I wish I could use in Python. An idiom for finding the index of elements of a ‘vector’ (list in Python) which are true (TRUE in R, True in Python) is

[i for i, v in enumerate(x) if v]

but I just want to call which(x)

which(c(FALSE, FALSE, TRUE, FALSE , TRUE))
## [1] 3 5

so why not define this

def which(x):
    return [i for i, v in enumerate(x) if v]
  
which([False, False, True, False, True])
## [2, 4]

(remembering that Python is 0-indexed).

How far could one take this? Quite a long way!

I thought more about what differences would need to be accounted for, and one that immediately came to mind was that R is vectorised. If I was to recreate R’s character counting function nchar(s) as essentially len(s), I’d need to consider whether I wanted it to work on a single string or a ‘vector’ of strings

In R:

nchar(c("these", "all", "have", "different", "lengths"))
## [1] 5 3 4 9 7

But in Python, len() expects a single value, so it calculates the length of the list

len(["these", "all", "have", "different", "lengths"])
## 5

The ‘proper’ way to do it is to map over the list

[len(s) for s in ["these", "all", "have", "different", "lengths"]]
## [5, 3, 4, 9, 7]

but again, why do I need to use an idiom for this? What if I just made a decorator to change a regular function to a vectorised one by applying this list comprehension internally when it’s passed a list (or a tuple), and which otherwise just evaluates the function with the argument?

import functools

def make_vec(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        if isinstance(args[0], (list, tuple)):
            return [func(xi, *args[1:], **kwargs) for xi in args[0]]
        return func(*args, **kwargs)
    return wrapper

@make_vec
def my_len(s):
    return len(s)

my_len(["these", "all", "have", "different", "lengths"])
## [5, 3, 4, 9, 7]

and I could name it… “nchar”!

The other use-case that came to mind was Elio venting (and referencing a post to which I also wrote a sort of response) that they needed to list the files in the current directory

Post by @eliocamp@mastodon.social

View on Mastodon

with the idiom

import os

[os.path.join(path, f) for f in os.listdir(path)]

The supplied suggestions included

from pathlib import Path

list(Path(path).iterdir())

(just rolls off the tongue, doesn’t it?) which returns a list of PosixPath() objects and is hardly easy to parse visually.

So, why not have a function?!?

import os

def list_files(path):
    return [os.path.join(path, f) for f in os.listdir(path)]

path = "path/to/files"

list_files(path)
## ['path/to/files/file1.txt', 'path/to/files/file2.txt', 'path/to/files/file3.csv']

I would have liked to call this list.files() but, since Python strictly uses the dot for method calling, it can’t be that.

This then raises the question of “should I support the arguments already in the R functions?” In this case, should it support a recursive argument? Yes, that adds complexity, but it’s surely do-able. At this point I reached for some AI assistance and had Claude help me to implement as many functions as we could think of, supporting as many common arguments as possible. This involved extending the decorator to support vectorising other arguments (which also need to be careful about dots).

On testing it out, it looked like we had something viable.

One last piece I wanted to support, though: the which() example above extracts the elements of a logical vector which are True, but in order to build that vector in the first place, I would naturally leverage R’s vectorisation as an array language. The two steps involved here are to first compute the comparison resulting in a logical vector, then to use which() to identify the indices of those which are true

which(c("c", "b", "a", "c", "a", "b") == "a")
## [1] 3 5

The vectorisation decorator above doesn’t help here, because it’s at the point of == that we want to vectorise

['c', 'b', 'a', 'c', 'a', 'b'] == 'a'
## False

This is False because the character 'a' is not equal to the given list.

The appropriate idiom is once again to use a list comprehension

which(x == 'a' for x in ['c', 'b', 'a', 'c', 'a', 'b'])
## [2, 4]

The solution I’m fond of is to create a new ‘Vec’ class which wraps binary operators with a list comprehension, again abstracting away this detail. This means implementing __eq__, __add__, __and__ and lots of other binary operations, but with that, and a wrapper to create such an object, the comparison operators can be vectorised

vals = vec(['c', 'b', 'a', 'c', 'a', 'b'])
which(vals == 'a')
## [2, 4]

Not pristine, but quite clean, if you ask me.

With all these pieces in place, adding implementations for common base R functions including most arguments and a way to vectorise lists, I wrapped everything up into a Python package (my first) to learn how to do it.

The workflow isn’t particularly painful, with my biggest complication being different versions of Python supporting different requirements in pyproject.toml, and so some GitHub Actions are failing because of that.

As part of building out the implementations I had Claude add tests for each of the functions with some expected values – if I do want to improve some of the idioms internally, I want to ensure I don’t change the values produced. That works for having any testing at all, but how can I be sure that I’m reproducing what I would get if I was working in R? One option was to just run all of the test functions by hand and confirm that the values look similar enough, accounting for list vs vector and 0 vs 1 indexing. Instead, Claude managed to write an adaptor for pytest which does the realignment of e.g. list_files to list.files (and similarly for arguments), realigns the indexing where needed, and runs all existing tests directly in R via rpy2 (skipping over some for which I don’t have tests yet). I’m disabling automated testing of this because I suspect it could get flaky dealing with both R and Python on GitHub Actions, but I can confirm that all the current tests pass.

I wanted to have a documentation website similar to what we have via {pkgdown} and came across quartodoc which is what the Python version of {pins} uses. Getting that to work required downgrading a specific Python dependency, but was otherwise painless.

I have a working package locally – how do I share it? This seemed like the perfect opportunity to learn what the release process looks like for Python. I have a handful of packages on CRAN and one on Bioconductor, and the process there is far from frictionless, with the side-effect that there’s some trust you can place on the interoperability of packages and minimal (automated) code checking. While Python is more ‘wild west’ in terms of what can be uploaded, it’s really nice to see that they do have an entirely separate test server where you can upload your package and see how it looks. I’m reminded of the quote

Everybody has a testing environment. Some people are lucky enough to have a totally separate environment to run production in.

Given that it’s not currently possible to run 100% of the CRAN checks locally (and even some that you can give a different result to what’s on their systems) this does make me a little jealous. I wonder whether the decrease in load from rejecting failing submissions would offset supporting a test submission server.

All went well pushing to the test server (via an authentication key) and I managed to build up the courage to push to the production instance… it’s live!

rfuns logo – R functions in Python… are fun

and the documentation site isn’t too bad, either (in my opinion).

This means that you can now run

uv add rfuns

(or the equivalent in whatever virtual environment management configuration you’re using, e.g. pip install rfuns) and start using some R functions directly in Python!

Depending on how you like to manage your imports, you can import everything

from rfuns import *

which([False, False, True, False, True])
## [2, 4]

or, if you prefer to namespace

import rfuns as r

r.which([False, False, True, False, True])
## [2, 4]

The list of functions currently imported, grouped into sections is:

nchar(["these", "all", "have", "different", "lengths"])
## [5, 3, 4, 9, 7]
grepl("ar", ["frog", "carpet", "basket", "dart"])
## [False, True, False, True]
sqrt([36, 81, 9])
## [6.0, 9.0, 3.0]

seq(5)
## [0, 1, 2, 3, 4]
seq(from_=0, to=10, by=2)
## [0, 2, 4, 6, 8, 10]

setdiff([5, 2, 4, 1], [2, 1])
## [5, 4]

set([5, 2, 4, 1]) -  set([2, 1])
## {4, 5}

## ─ Session info ───────────────────────────────────────────────────────────────
##  setting  value
##  version  R version 4.5.3 (2026-03-11)
##  os       macOS Tahoe 26.3.1
##  system   aarch64, darwin20
##  ui       X11
##  language (EN)
##  collate  en_US.UTF-8
##  ctype    en_US.UTF-8
##  tz       Australia/Adelaide
##  date     2026-05-22
##  pandoc   3.6.3 @ /Applications/RStudio.app/Contents/Resources/app/quarto/bin/tools/aarch64/ (via rmarkdown)
##  quarto   1.7.31 @ /usr/local/bin/quarto
## 
## ─ Packages ───────────────────────────────────────────────────────────────────
##  package     * version date (UTC) lib source
##  blogdown      1.23    2026-01-18 [1] CRAN (R 4.5.2)
##  bookdown      0.46    2025-12-05 [1] CRAN (R 4.5.2)
##  bslib         0.10.0  2026-01-26 [1] CRAN (R 4.5.2)
##  cachem        1.1.0   2024-05-16 [1] CRAN (R 4.5.0)
##  cli           3.6.5   2025-04-23 [1] CRAN (R 4.5.0)
##  devtools      2.4.6   2025-10-03 [1] CRAN (R 4.5.0)
##  digest        0.6.39  2025-11-19 [1] CRAN (R 4.5.2)
##  ellipsis      0.3.2   2021-04-29 [1] CRAN (R 4.5.0)
##  evaluate      1.0.5   2025-08-27 [1] CRAN (R 4.5.0)
##  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.5.0)
##  fs            1.6.7   2026-03-06 [1] CRAN (R 4.5.2)
##  glue          1.8.1   2026-04-17 [1] CRAN (R 4.5.2)
##  htmltools     0.5.9   2025-12-04 [1] CRAN (R 4.5.2)
##  jquerylib     0.1.4   2021-04-26 [1] CRAN (R 4.5.0)
##  jsonlite      2.0.0   2025-03-27 [1] CRAN (R 4.5.0)
##  knitr         1.51    2025-12-20 [1] CRAN (R 4.5.2)
##  lattice       0.22-9  2026-02-09 [1] CRAN (R 4.5.3)
##  lifecycle     1.0.5   2026-01-08 [1] CRAN (R 4.5.2)
##  magrittr      2.0.4   2025-09-12 [1] CRAN (R 4.5.0)
##  Matrix        1.7-4   2025-08-28 [1] CRAN (R 4.5.3)
##  memoise       2.0.1   2021-11-26 [1] CRAN (R 4.5.0)
##  otel          0.2.0   2025-08-29 [1] CRAN (R 4.5.0)
##  pkgbuild      1.4.8   2025-05-26 [1] CRAN (R 4.5.0)
##  pkgload       1.5.0   2026-02-03 [1] CRAN (R 4.5.2)
##  png           0.1-9   2026-03-15 [1] CRAN (R 4.5.2)
##  purrr         1.2.2   2026-04-10 [1] CRAN (R 4.5.2)
##  R6            2.6.1   2025-02-15 [1] CRAN (R 4.5.0)
##  Rcpp          1.1.1   2026-01-10 [1] CRAN (R 4.5.2)
##  remotes       2.5.0   2024-03-17 [1] CRAN (R 4.5.0)
##  reticulate    1.45.0  2026-02-13 [1] CRAN (R 4.5.2)
##  rlang         1.1.7   2026-01-09 [1] CRAN (R 4.5.2)
##  rmarkdown     2.30    2025-09-28 [1] CRAN (R 4.5.0)
##  rstudioapi    0.18.0  2026-01-16 [1] CRAN (R 4.5.2)
##  sass          0.4.10  2025-04-11 [1] CRAN (R 4.5.0)
##  sessioninfo   1.2.3   2025-02-05 [1] CRAN (R 4.5.0)
##  usethis       3.2.1   2025-09-06 [1] CRAN (R 4.5.0)
##  vctrs         0.7.1   2026-01-23 [1] CRAN (R 4.5.2)
##  withr         3.0.2   2024-10-28 [1] CRAN (R 4.5.0)
##  xfun          0.56    2026-01-18 [1] CRAN (R 4.5.2)
##  yaml          2.3.12  2025-12-10 [1] CRAN (R 4.5.2)
## 
##  [1] /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library
## 
## ─ Python configuration ───────────────────────────────────────────────────────
##  python:         /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV/bin/python
##  libpython:      /Users/jono/.local/share/uv/python/cpython-3.12.12-macos-aarch64-none/lib/libpython3.12.dylib
##  pythonhome:     /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV:/Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV
##  virtualenv:     /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV/bin/activate_this.py
##  version:        3.12.12 (main, Oct 28 2025, 11:52:25) [Clang 20.1.4 ]
##  numpy:          /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV/lib/python3.12/site-packages/numpy
##  numpy_version:  2.4.6
##  
##  NOTE: Python version was forced by VIRTUAL_ENV
## 
## ──────────────────────────────────────────────────────────────────────────────