jmablog

What was the best year for a saxophone lover to be listening to the Billboard Top 100?

Thu, 26 Feb 2026 00:00:00 +0000

(Tidy Tuesday is a project to supply weekly data sets for R users to practice their coding skills on. You can find full details here.)

I turned to my wife in the car the other day and said, out of nowhere: “You know, I love a bit of sax in a song.”

She laughed.

But I was deadly serious.

Coincedentally, while looking through the Tidy Tuesday archives for some data to play around with in R after not using the language for a while, I found the Billboard Hot 100 Number Ones data set. And it contains a flag for “…if the song contains a saxophone”.

Hell yeah.

Which in turn got me wondering, which year had the most sax in it?

Sadly, since my birth in 1987, only 11 years in total have even had a sax-song go to number 1. And since I was old enough to meaningfully care, i.e. 1994, only 5 years had a sax-tastic hit. What are we even doing as a society? I say the AI can take us, for truly we lost our souls decades ago.

Two songs in particular though hold down the fort - Whitney Houston’s “I Will Always Love You” in 1992, with a whopping 14 weeks at no. 1, pushing 1992 to the highest scoring year (31%) with the assistance of The Heights’ “How Do You Talk To An Angel”. ¹ Then, in 2015, Bruno Mars’ “Uptown Funk” was a shining reprieve in the darkness and also achieved 14 weeks at no. 1, but sadly struggled on alone, leaving 2015 at only 27% saxy.

Code (also on GitHub):

library(tidyverse)
library(ggtext)
library(tidytuesdayR)
library(tinieR)

# importing data

data <- tidytuesdayR::tt_load('2025-08-26')
songs <- data$billboard

# data manip

sax_songs <- songs |>
    filter(saxophone == 1) |> 
    separate(cdr_genre, into = c("main_genre", "other_genres"), sep = ";", fill = "right") |> 
    replace_na(list(main_genre = "Rock")) |> 
    separate(date, c("year", "month", "day"), sep = "-", remove = FALSE) |>
    select(year, weeks_at_number_one, main_genre) |> 
    group_by(year) |> 
    summarise(perc_of_year = (sum(weeks_at_number_one)/52)) |> 
    ungroup() |> 
    mutate(year = as.Date(paste(year, "01", "01", sep = "-")))

# plot

sax_songs |> 
    ggplot(aes(year, perc_of_year)) +
    geom_point(colour = "#E03135", size = 2) +
    scale_y_continuous(labels=scales::percent) +
    scale_x_date(date_breaks = "10 year", date_labels = "%Y", expand = expansion(add = 0)) +
    xlim(c(as.Date("1959-01-01"), as.Date("2023-01-01"))) +
    theme(legend.position = "none",
        axis.text.x = element_text(face = "bold", colour = "#4D556B"),
        axis.text.y = element_text(face = "bold", colour = "#4D556B"),
        axis.title.y = element_text(face = "bold", colour = "#4D556B"),
        #axis.ticks.y = element_blank(),
        axis.line = element_line(colour = "#4D556B"),
        #panel.border = element_rect(color = "black", fill = NA),
        panel.grid = element_blank(),
        panel.grid.major.y = element_line(size = 0.3, colour = "black", linetype = 3),
        #plot.title.position = "plot",
        plot.title = element_textbox(face = "bold", colour = "#AE030E", size = 14),
        plot.background = element_rect(fill = "#FFF8E7"),
        panel.background = element_rect(fill = "#FFF8E7"),
        plot.margin = margin(20,20,20,20),
        plot.subtitle = element_textbox(face = "bold"),
        plot.caption = element_textbox(face = "italic", colour = "#4D556B")) +
    labs(x = "", y = "% of Year",
       title = "Percentage of each year where the Billboard No. 1 song <br> prominently contained a saxophone",
       subtitle = "",
       caption = "% calculated as total no. 1 weeks in year / 52") +
    annotate("segment", x = as.Date('2015-01-01'), y = 0.24, xend = as.Date('2015-01-01'), yend = 0.26, arrow = arrow(type = "closed", length = unit(0.01, "npc"))) +
    annotate("text", x=as.Date('2015-01-01'),y=0.24, label = "Uptown Funk", color = "#185AA6", angle = 0, hjust = 0.5, vjust = 1.5, size = 3, fontface = "bold") +
    annotate("segment", x = as.Date('1992-01-01'), y = 0.28, xend = as.Date('1992-01-01'), yend = 0.3, arrow = arrow(type = "closed", length = unit(0.01, "npc"))) +
    annotate("text", x=as.Date('1992-01-01'),y=0.28, label = "I Will Always Love You", color = "#185AA6", angle = 0, hjust = 0.5, vjust = 1.5, size = 3, fontface = "bold")

You know. The Heights. Angel talking song. 2 weeks at no. 1 in 1992. We all know it. ↩︎

Some Animated Joins

Sun, 26 Feb 2023 00:00:00 +0000

I spent the weekend picking up the basics of Manim, a Python library used for making maths animations - most famously for the YouTube channel 3Blue1Brown.

In need of something to make, I decided to try and visualise some common SQL joins, as it’s something I’ve been teaching lately. They’ve come out quite nice, so now you get to enjoy them too!

Inner join

Sorry, your browser does not support the video tag.

Left join

Sorry, your browser does not support the video tag.

Outer join

Sorry, your browser does not support the video tag.

But how was Manim?

A very strange mix of ‘incredibly easy’ and ‘mind-boggling’. You can get some basic things up and running surprisingly quickly, but then little things like fonts and colours will be hair-pulling time drains. And I definitely don’t think I’m using it to the best of its ability here. But overall I recommend it!

I want to shout out this video from Brian Amedee as a good resource for getting to grips with Manim, alongside the main docs!

Can I use these?

Yes! In fact, if you’d like any higher-res versions for use in something, please drop me an email and I’ll be happy to provide. You can also find the (probably poorly optimised) code for these animations on GitHub here.

Tinier 0.5.0

Thu, 18 Aug 2022 00:00:00 +0000

I had some time on my hands in the last few weeks while I wait to start a new job, so I went back to the tinieR package to fiddle around!

New things - `petit_plot`

I’d long wanted to find a way to export plots directly from R into pre-tinified image files, and although I’d found a way to do it for ggplot2 plots, doing it with base R plots and devices eluded me.

Finally I found a (slightly hacky) way of doing it by simply recording the last plot created with recordPlot, and then replaying it inside the chosen device! One of those things that seems obvious in hindsight, but it works. So, I’ve put together two new functions, petit_plot() and petit_ggplot() to save and auto-tinify plots!

You can use most of the same tinify() options as usual, including keeping the un-tiny image file too, and pass through all regular plotting options to the underlying device too. You can even use petit_plot with ragg if you have it!

You can read more in the new ‘saving plots’ package vignette here, and here’s an example of the new function in action:

library(tinieR)

p <- ggplot(data = palmerpenguins::penguins,
            aes(flipper_length_mm, body_mass_g)) +
     geom_point(aes(color = species)
     
petit_ggplot(filename = "penguins", plot = p)

I love tinkering away on this little project. Once again, I’m going to really recommend developing a package for getting to know R better. It doesn’t have to do much fancy - tinieR certainly doesn’t - but having problems to solve really gives purpose to your learning. If you want to try it, check out the R Packages book by Hadley Wickham and Jenny Bryan for a complete guide!

I hope you’ll try out tinieR for yourself - and if you encounter any issues, please let me know!

How To Spot Bad Coaching Advice Online

Wed, 09 Mar 2022 00:00:00 +0000

This post was written in collaboration with John ‘Hedge’ Hall of Access Parkour. You can also find a copy of this post on the Access Parkour blog and on Parkour Earth’s article section. There are minor formatting differences to fit the style of each site, but otherwise they are all identical.

As sports coaches, we are endlessly bombarded with different sources of information. Finding our way through this endless stream of opinions and assertions is difficult and it’s not uncommon for coaches to be exposed to the best marketing arguments instead of the most valid ones. Scientific literature is often dense and difficult to understand, and instead we often absorb it via a pop-sci article written by a third party. Which articles are relevant to our needs? Which are useful and which are not? Sometimes, an article is flawed through error or unfamiliarity, and sometimes it’s just a bad take by a good salesman. How do we tell which is which?

Within this article we want to explore evidence based coaching, it’s limits and how conventional wisdom fits into the picture. We hope that, by the end of this discussion, you’ll at least have a good idea of the reason it can be so difficult to separate fact from fiction and better understand the struggles of a sports coach. Even if, like us, you’ll probably walk away still a little unsure how to deal with it all.

Sports science and empirical evidence

It’s been famously claimed that “democracy is the worst form of government, except for all those other forms.” Similar things could be said about the modern sports science approach of controlled experimentation and peer review.

Modern science works through observation, hypothesis, experiments, and review. A hypothesis is proposed (men in their 30s like to write long winded blog posts). An experiment is designed (we asked 57 different men of all different ages if they enjoyed producing blog posts over 1000 words) and then results are analysed (men in their 30s were significantly more likely to report they enjoyed producing blog posts over 1000 words than other age groups). But the experiment may have structural flaws that aren’t exposed until it is compared to many others (it turns out Hedge’s mates aren’t a representative statistical sample of the adult male population as a whole). This flaw is hopefully spotted when another party takes a look at the study (James peer reviews Hedge’s work and points this out). If the flaw is spotted, we can update the hypothesis or experiment and try again (ask a whole lot more adult men than just Hedge’s mates).

The scientific method (mostly) produces information that is true, for the majority of cases within a defined population. They are narrow in scope and should be read as such. It’s a feature, not a bug. Make your study too broad, and you risk introducing factors that make it more difficult to determine if the cause and effect link you are looking for is actually present. Famously, shark attacks increase in correlation with ice cream sales, because hotter weather prompts more visits to the beach, not because sharks buy a lot of ice cream.

So results should be analysed within the context of each experiment and whichever hypothesis prompted the experiment. An individual paper only discusses how valid the evidence is in relation to what is being studied and the method used to study it. Wider meaning may be inferred as an outcome of the results of the study, but this is usually a call for further investigation rather than a statement of truth. Consequently a single paper very rarely provides overwhelming proof and it’s perfectly possible for two valid papers to exist that contain opposing evidence.

Using this process, nothing can ever be shown to be 100% true. We can only find as many different ways as possible to show that it isn’t not true. The scientific process is messy and complicated and you can rarely read a lot into a specific study unless you are an expert in that particular niche. Even those with scientific training from different disciplines should hesitate before drawing conclusions from a single paper. These things often aren’t settled until sufficient evidence has been compiled, the meta-analysis has been done and then someone in scientific communication comes along and tries to form the body of evidence into a coherent story that is easy for others to digest. This is often how a larger picture is reached: in the aggregate.

All of this is a way of saying that empirical evidence is good and studies are important, but we should bear in mind that a single study alone is rarely sufficient evidence to change our approach to fitness. While recognising that sports science is absolutely producing important evidence that we, as coaches, should be listening to in order to improve our practice.

Conventional wisdom

Conventional wisdom can be thought of as any practice where people using these methods report that it has worked for them. However, either the underlying mechanisms aren’t understood enough to definitively say why it works, or there just isn’t enough evidence yet to call it one way or another. The practice often comes with proposed explanations about how it works and these explanations often lack credible evidence. Usually that evidence is personal, anecdotal experience. People have followed this process and it has worked for them. This is a valid experience but, unfortunately, it is not sufficient evidence that it will work for everyone or that it worked for exactly the reasons claimed.

Essentially, it’s not disputed that a number of people have had positive wellbeing results from the practice, but the mechanism may be different from what is described. Healing crystals can have really positive effects for a lot of people and astrology horoscopes provide comfort to many. But rocks don’t produce healing fields and stars don’t impact your personality. At the other end of the discussion, no-one is seriously arguing that stretching and mobility isn’t good for you. But we simply aren’t sure about why it works and exactly what it is doing. To compound the matter, two people may have very different results from the same stretching protocol. Massage is another topic where consensus is difficult to find and there are no easy answers, despite the fact that it’s almost universally agreed that massage provides benefits to those on the receiving end of it.

It’s quite common for these conventional practices to have many integrated parts that form part of a lifestyle. In Ashtanga Yoga, you are getting up earlier, exercising first thing, doing long stretches with specific breathing protocols and it is often associated with changes in diet as well. This is a fairly complex set of lifestyle changes that all occur at once. While the entire practice cumulatively may benefit people, it isn’t a simple matter for a study to be able to understand which parts of this practice are responsible for that.

As a sports coach, you’ll find there’s a lot more conventional wisdom out there than there are well written scientific op-eds that explain things to you. Especially if you work in a niche sport that isn’t well studied. It’s important to know that the two can co-exist and do not automatically cancel each other out. Scientific papers provide information on the population. Individuals provide information on themselves. If a client presents themselves to you and says that acupuncture really helped with their knee pain before, you can believe them. It does not mean acupuncture is the only thing that will help them and it does not mean you need to start delivering acupuncture to all your clients.

Unfortunately, you are likely to encounter many instructors with large media followings citing specific studies to back up their conventional wisdom. This can be a double edged sword as they may be experts in the field having deep domain specific discussions, or they may be using marketing gimmicks to appear to be experts. They may even be bad actors actively encouraging you to ignore a scientific consensus that exists against them. Most people likely lack the tools to properly assess the difference between these instructors.

Spotting good advice

Inevitably, at some point you are going to find yourself considering whether to trust someone without sufficient evidence backing up their claims. So within this whirling world of difficult to digest evidence, how do we actually decide who we should be trusting?

There are a few different areas you can focus on if you want to make sure you are following good advice online:

The goals and outcomes of the advice are applicable to you, your clients, or your sport and not just generic advice
You can see some evidence of successful results that indicate a generally positive, healthy outcome. If anecdotal, you are able to find or verify these success stories from sources independent of the person making the claims
The instructors’ clients are fairly diverse and their work is adaptable to many different bodies
The instructor seems to have a long history in the activity they are promoting and isn’t just jumping into the latest fad
The instructor rarely gives definitive answers about ‘why’ things are happening, but instead provides education and possibilities, with options to suit a variety of situations
You can try out and assess the advice for yourself with very low risk and commitment

Above all, avoid programmes that encourage an ‘all-or-nothing’ attitude. Anything where someone is claiming that this one simple trick fixes everything, or tells you that everyone else is wrong is almost certainly just selling something. We strongly encourage everyone to read widely, discuss openly, and engage with a variety of sources. Be critical but open, analytical but empathetic, discerning but not dismissive. Ultimately, it comes down to your judgement, personal and professional, to consider the evidence and potential risks in any modality you are delivering to a client or patient. But that judgement should absolutely be an informed one.

Parkour, Perpetual Challenge, and Burnout

Sat, 29 Jan 2022 00:00:00 +0000

This post was written and shared as part of Time To Talk Day 2022, an initiative to encourage conversations around mental health. You can check out more on Time To Talk here and start your own conversations using the tag #TimeToTalk on social media.

I’ve been hanging out on the Parkour Earth Discord for a little while now. ^[Which you can also join here: https://discord.com/invite/aESab8czGw] While there, a conversation came up in the coaching channel about motivation for your own training as a coach, and how it changes after you stop coaching. In particular, this quote stood out to me:

I’ve gone through many ups-and-downs over the years in coaching / training but now have a good equilibrium I think. The key was that all-important word - challenge. If you’re not challenging yourself while training and just going through movements you can already do, then it just gets boring. I’ve found the key to be that I HAVE to do something I’ve not before in every session of training and I have to be scared of it. If I’m not worried, then I’m comfortable - which means I’m not going to get much out of it.

What was interesting was that my own experience was almost the complete opposite - for one, the impetus of needing to keep in good condition for coaching kept my motivation up, and since stopping coaching I’ve found it harder to care about my own training as much. But the idea of ‘challenge’ in a training session is also something I’ve been thinking about a fair bit recently. In fact, I’ve tried to write a variation on this blog post a number of times and abandoned it, but the conversational nature of the Discord chat finally got me to lay it out in a way I kind of liked. So, I’ve taken my replies and expanded on them a bit to put together this post.

Burnout and challenge

Looking back, I think I went through a really intense period of burnout last year (in many aspects of my life, not just training). As a result, I found that the second I encountered meaningful challenge in my training - whether that be psychologically or physically - my body would just shut down, and kill the session dead. The best way I find to describe it is that my ‘spare emotional bandwidth’ is severely reduced, and things I would normally take in stride or even relish the challenge of instead boil me over into stress and anxiety much quicker. Consequently I’ve had to curtail the intensity of my training to the point that my criteria for success for a day will sometimes be as as little as “did a single push up” or “went for a walk”. ^[Small side story: the only physical activity I really got into last year was running. Recently, after about 18 months of not doing any strength or resistance training at all, I discovered I couldn’t do a single push-up anymore. I decided to commit to doing a minimum of one push-up a day for a while, just to get a bit of strength back. After only a month, I was back up to sets of about 12-15 reps. This is why I like to tell people not to overly worry about taking a break from particular exercises or training in general - you might not retain your strength or fitness completely, but it comes back so much quicker than it took to get it in the first place.]

But that in turn has had a very negative interaction with my understanding of what makes a worthwhile training session - that is, it HAS to be hard, or challenging. I would end a training session feeling guilty that I had not pushed myself within it. And that would further fuel an apathy for training over time - what’s the point in doing it if I’m not dying by the end of every training session, or conquering fears constantly?

I think it’s an attitude that I built up over time because, well, that’s the implicit culture of parkour. It’s unspoken, but there are often extremely unrealistic standards for the elite physical and mental abilities parkour athletes are expected to have. Those expectations are often not a reasonable level of athleticism for someone to achieve or maintain who is not pursuing the sport full time as a professional or with the dedicated passion of a true devotee. There is also an implicit expectation of constant progression and improvement that is hard to reconcile when you inevitably encounter training plateaus. ^[Not that there’s anything wrong with that mindset when you’re capable of it - just that it’s not realistic to always maintain.] This leads to an environment of perpetual challenge where there is no rest and no finishing line. It’s anecdotal but I know SO many people who have either burnt out on the sport or suffered from the same feelings of guilt about not being ‘good enough’ or training ‘hard enough’ that I have. I think it is, in short, really hard to just be a hobbyist traceur. ^[For a lot more in-depth look at some of these points, check out Kasturi’s (of Esprit Conrete) PhD thesis: https://repository.londonmet.ac.uk/6852/1/Torchia-Kasturi_DCouPsy-thesis-submission.pdf]

Identity

To really pile on the problems, my loss of interest in training and parkour had yet another knock-on effect. As a lifestyle sport, it is very easy for parkour to become the dominant pillar in your life. Up until relatively recently, parkour was my career, hobby, entertainment, and social circle. Even more importantly, it was what I did, what I was. Without it, what am I?

I was still at university at this point, so I couldn’t call myself a ‘sports therapist’ or ‘researcher’ or ’lecturer’ or any of the things I aspired to be yet. ‘Student’ is itself a transitional term. What was left? I love being a husband, but I didn’t want to be a ‘husband’. Other hobbies had been crowded out by parkour over the years. I don’t mind telling you that I felt truly adrift.

This phenomena of sudden disassociation with something previously established as a core aspect of an identity is sadly one that can come up in sport, particularly lifestyle sports, a lot. Often it’s as a result of an injury - if you can no longer physically play, it can feel like it’s been snatched away from you. In my case it was a more gradual fading away, but it left me just as bereft.

So in very short order I went from burnt out, to apathetic, to bereft of identity. All because I stopped engaging with a single activity. That’s a lot. I may be an extreme case but I know it’s happened to others. As a result, I always feel a little pang of worry when I see someone who has the word ‘parkour’ or ’traceur’ in their personal social media handles. It shouldn’t be in your name, in your identity. It feels too… close.

Cheer pressure

As a discipline, I don’t think we really talk about these potential negative psychological effects (effects that are found in almost any degree of high-level sports performance) and the impact they can have on athletes nearly enough. And I have a couple of theories why. Firstly, we’re still striving for acceptance and legitimacy in the eyes of much of the established sporting world, or hell, the world in general. Everyone wants to present parkour in the best possible light, which is great, but it doesn’t mean we get to just ignore the downsides.

In a way, I think we’d benefit from coming to terms with the fact that parkour isn’t as special or unique as we’ve all sometimes pretended it is. Many of the special things touted for parkour (physical fitness, seeking challenge, facing fear, community) can happily be found in other activities, and just as similarly, many of the downsides of other activities (social pressure, identity, burnout) can be found in parkour. But the relentless act of presenting parkour in the best possible light - even if entirely understandable in the circumstances - brushes those conversations under a rug.

Secondly, parkour is still very young-male dominated, a group of people famous for not being able to talk about their feelings. Discouraged from doing so by society, even! What’s worse, I’ve seen an increase in the embracing and sharing of a disturbingly ‘man-up’ approach to training and mental health in some circles, through advocacy for the works of (sigh) Jordan Peterson and his ilk. ^[I won’t mince my words, I fucking loathe ol’ J. Piddles. Here’s a pretty comprehensive break down of his schtick from 2018, and he’s only gotten worse since then.] It’s through phrases like ‘anti-fragility’ and ‘grit’ that young men who are suffering are led to believe they have somehow failed at being tough enough rather than experiencing an entirely normal and human ebb and flow of emotion. The wrapping up of constant risk-facing or fear-conquering, something often understood to be an intrinsic part of parkour, with macho-masculinity is something I’ve also wondered about since reading “Masculinity ≠ Risky Business” last year.

In my opinion, and forgive me for the upcoming very dramatic sentence, but: it all combines with the perceived assumption of elite-level ability and expectation of perpetual unending challenge inherent in parkour practise to form an environment that is extraordinarily effective at suppressing the honest expression of male anguish, which in turns bleeds out to become the dominant culture of the sport.

Oh boy. It’s sentences like that make me glad I don’t have a comment section on these posts.

Sorry, your browser does not support the video tag.

More broadly, I also think this ties into a lot of the ‘overcoming obstacles’ aspect of parkour. It is a pretty central tenet of parkour practise to find a challenge, and try and conquer it. This can lead to a very objective, problem-solving mindset, and a tendency to not allow oneself to quit something hard. In theory this is grand, but this narrative overwhelms empathetic discussion of issues; I’ve seen pleas for help absolutely subsumed by suggestions for ways to ‘solve the problem’, rather than simply providing genuine emotional support. It also smothers the idea that, sometimes, the right thing to do for your own well-being is actually to quit.

I’ll say that again: sometimes, the right thing to do is to honestly assess why you feel you should be doing the thing, and to quit the thing if it’s making you miserable rather than struggle on out of some feeling of obligation. It’s what I did. I made the decision to consciously decouple myself from parkour training, as it was no longer the right thing for me to be doing at that stage of my life. And, let me tell you, finally actively giving myself permission to walk away from that source of stress in my life to focus on other things felt so good.

Talk

It’s important to emphasise something I mentioned above - these things are mostly implicit in parkour. It is a side-effect. Nobody (at least in my experience) is intending to stress out fellow athletes or wilfully looking to turn a blind eye to these issues, particulary in the coaching community. I often as a coach heard, took part in, or initiated conversations about reassuring a student they were doing well or that it’s not about comparing themselves to other athletes. ^[For a nice example of the foregrounding of a positive mental approach to parkour training in coaching: see this blog post by John ‘Hedge’ Hall of Access Parkour about their values and mission statement] But there can be quite a big difference between what is said and how it feels. And these conversations tend to be aimed at reassuring beginners, not aimed at providing psychological aid to experienced athletes who are, I expect, simply assumed to be able to cope.

As a developing sport/discipline, we are in a great position to instead build the psychological well-being of our athletes into the very foundations of our practise. All it takes is being willing to talk about it.

Quarto templates for lecturers and educators

Wed, 26 Jan 2022 00:00:00 +0000

Quarto is a fantastic scientific and technical document publishing tool that I just discovered - it’s basically Rmarkdown, but expanded beyond R to become a standalone document processor, whether that be just for markdown or including R, Python, and JavaScript code ¹.

While looking through the Quarto docs, I realised that it also solves another problem I had when I was lecturing as part of my Masters degree last year - generating multiple file formats from a single input file! I didn’t bother blogging about it, but last year I ended up setting up a convoluted Pandoc and Pandocomatic workflow to generate PDF, HTML, and Word / Powerpoint files from a single markdown input.

Why? Well, I believe that providing multiple file formats is better for the student experience, letting them download and use them in a format convenient for them. In particular, a well formatted HTML file is very portable, able to adapt and display nicely on a range of device sizes ².

The trouble is, maintaining multiple file formats by hand is a nuisance - you change one thing, and have to update it in three different places. Instead, having a single source of truth - a markdown file, in this case - that the other formats build from is much easier to manage and update.

So, I went ahead and updated my Pandocomatic workflow to use Quarto, and I couldn’t be happier. It’s much simpler and more straightforward, requiring a lot less technical setup to use.

There are two versions of these workflows:

Worksheets - to produce working materials / documents for classes
Presentations - to produce slides for lectures / tutorials

Full details on how to setup and use these workflows are in the GitHub repos linked above. I deliberately kept them simple in style and substance - while Quarto can produce some really nice documents, I used my own templates to strip everything right back to basics, whilst still looking pleasing and clean. Using my own templates did break a bit of Quarto functionality in my testing, so I’ve included my own lua filter ³ to re-implement the things I consider essential, as well as a little extra function in the auto-linking of questions and answers in the Worksheets.

Thanks for reading, I hope these workflows might be even a tiny bit helpful to someone out. Get in touch if you’ve got any writing / document processing tips of your own to share!

Seriously, it does so much stuff. ↩︎
Also, giving a nice range of options for use with screen readers and other accessibility tools through semantic HTML. ↩︎
See my blog post on lua filters for details on how to write your own! ↩︎

Generating Pretty Instagram Quote Images in R

Tue, 07 Dec 2021 00:00:00 +0000

Here’s a fun little project I worked on over the weekend. This script can take a .tsv file of quotes/text and their sources, and output pretty Instagram-ready quote images with a splash of random colouring. For example:

I’d seen a few people getting onboard the quote-image train on Instagram as a fairly easy way of generating content for the site. And this intrigued me as generating social media content is definitely something I’ve, uh, struggled with since launching Parkour Clinic. But, considering I just self-published a 15,000 word paper (on top of the 6,500 word paper from last year) full of juicy parkour quotes, I figured this would be an ideal way for me to get my own content train finally moving.

The only trouble is, I kind of hate image editing these days? I find it really finicky, and I know what I’m like - I’ll create twenty images and then decide I don’t like the font, and have to create them all over again. So I decided to look into a way of creating them programmatically, and the magick package in R can do exactly that.

Initially I was creating the background colours by hand and just overlaying the text - not that hard to do with magick’s image annotate function. But, the fun came when I decided to try and also vary the colours of the background slice and text together in pure code, using magick::image draw along with some of R’s base graphics functions. These were fun to figure out because they felt like something older and less user-friendly than a lot of modern R package functionality, and at the end of it all, left me with a sense of understanding R better, which is always a great outcome to these little side projects.

I also totally spent ages figuring out and implementing my own word_wrap function, that was a bit rubbish, before accidentally discovering there was already one in base R with strwrap. Oh well. Good to know for the future!

The result is that, with ten minutes work copying and pasting choice excerpts from my papers into a single quotes.tsv file, I was able to quickly and easily generate nearly 40 quote images I can drip out on the Parkour Clinic Instagram over the coming months. Perfect. And if I decide to change some colours or a font, well, it takes about ten seconds to recreate them all. Absolute bliss.

If you’d like to generate your own quotes, you can download this project from GitHub!

Using the Expertise of Parkour Coaches to Understand Parkour Movement: The Kong Vault

Wed, 22 Sep 2021 00:00:00 +0000

This project was my thesis for my MRes Sport and Exercise Science degree. In the spirit of my undergraduate degree, I decided to also post this online to share my research with the wider parkour community.

This was a big project, but essentially aimed to talk to parkour coaches to really get a good description and potential model of the kong vault for future use in research. As “any quantitative assessment of human movement must be preceded by a measurement and description phase” (Winter, 2009), well, this was aiming to fill the description phase.

While much came of the project, my main takeaway personally is that it is entirely possible to work scientifically within parkour without losing sight of the importance of subjectivity and individuality in the movements. There is also an important point about the differences in experiences with learning parkour movements between male and female athletes in the ‘Future Studies’ section.

I hope sharing this is useful or informative for someone out there, and I’m happy to talk further about anything regarding the project, just get in touch.

Big thank you to all those who took part!

Read Online

📔 Read online in full

📄 Download PDF from ResearchGate

Bonus Materials

🗞 Download poster version from ResearchGate

Disclaimer

It’s important to know that this work has not been peer reviewed.

Still, I’m proud of my work and I think my findings are, at the very least, interesting. But, please bear the above in mind as you read and consider the results found—and conclusions drawn from those results—with an appropriately critical eye.

Data

You can also download the full anonymised interview data I collected if you would like to perform your own analysis. If you do so, please get in touch and let me know what you use it for and what you find.

⬇ Download from Figshare | ⬇ Download from Github repo

Abstract

Parkour is a discipline in which practitioners (traceurs) traverse their environment using a variety of movements. Parkour’s decentralised spread and community commitment to diverse practice does not provide easily identifiable definitions or outcome measures for a given movement. This can make it challenging to identify a dependent variable of a parkour movement for study or qualitative assessment. In the absence of objective parkour technique definitions, 15 parkour coaches were interviewed about the performance and goals of a common parkour technique, the kong vault. This sampling of expert knowledge provided a broad yet detailed overview of a movement that can be performed with a high degree of variability within a dynamic range of environments. Subsequent analysis led to the development of a deterministic model intended to assist in the understanding of the kong vault in application to highly individual or situational outcomes, rather than comprehensively prescribing objective performance. The model positions the kong vault as consisting of distinct take-off, obstacle contact, and flight phases, and allows connection to any subsequent landing or movement. Flight is determined by the actions taken during take-off and obstacle contact, with obstacle contact making only moderate changes to an existing projectile arc but expressing a greater change in the angular momentum of the body. The optimal outcome of the kong vault can therefore be considered as achieving a projectile arc and body position that effectively places the traceur in as advantageous position as possible to efficiently and consistently perform a given landing or movement.

Mario Kart 64 World Records

Sat, 29 May 2021 00:00:00 +0000

(Tidy Tuesday is a project to supply weekly data sets for R users to practice their coding skills on. You can find full details here.)

It’s been a while since I took part in a Tidy Tuesday, but having not played with any R code for a while I got the urge to create some utterly pointless plots this weekend, so here we are. This week’s dataset is looking at world records in Mario Kart 64, which despite being over two decades old (don’t let it set in), is still active in the videogame speedrunning community.

First up, a ridgeline plot of the density of world record activity per track over the years:

I’d seen ridgeplots quite a lot when browsing #TidyTuesday on Twitter so I figured it was about time I gave one a shot myself. I used the ggridges package and it was fun to finally have an excuse to try it out! Looking at the plot, it seems like there was a resurgence in world record activity later in the games life - most likely due to more widespread internet access and the growth of the speedrunning scene in general as a result, I imagine.

Second, a plot showing the total amount of time it would take you to complete all the tracks in Mario Kart 64 at the fastest world record pace each year:

The plot itself isn’t the most interesting result (although what happened with shortcuts in 2020? My brief research reveals the possible discovery of a new technique - maybe it made all the difference!) But, the method to get the fastest time per year for both shortcut and non-shortcut uses was a fun puzzle to solve, and involved some fancy pivoting back and forth alongside the use of tidyr’s fill function to flesh out those years where no records were set. See the code for all the steps.

Speaking of the code, have you noticed the new native R pipe operator? I thought I’d give it a whirl. |> is certainly easier and quicker to type than the old %>% one, although there are one or two bits of functionality missing that mean %>% probably isn’t going away entirely just yet.

Code (also on GitHub):

library(tidyverse)
library(ggtext)
library(ggridges)

# importing data

tuesdata <- tidytuesdayR::tt_load(2021, week = 22)

drivers <- tuesdata$drivers
records <- tuesdata$records

# activity plot

records |>
  separate(date, into = c("year", "month", "day"), sep = "-") |>
  filter(shortcut == "No") |>
  ggplot(aes(x = year, y = track, group = track)) +
  geom_density_ridges(rel_min_height = 0.01, fill = "#F97B64", alpha = .8) +
  labs(x = "", y = "", title = "Mario Kart 64 World Record Activity per Track",
       subtitle = "Plenty of records set near release, with a slump in activity followed by a surge in the 2010s") +
  scale_x_discrete(breaks = c(1997, 2009, 2021)) +
  scale_y_discrete(expand = expansion(mult = c(0.01, .12))) +
  theme(legend.position = "none",
        axis.text.x = element_text(face = "bold", colour = "#3A5678"),
        axis.text.y = element_text(vjust = 0.3, face = "bold", colour = "#3A5678"),
        axis.ticks = element_blank(),
        axis.line = element_blank(),
        panel.grid = element_blank(),
        panel.grid.major.y = element_line(size = 0.3, colour = "black", linetype = 3),
        plot.title.position = "plot",
        plot.title = element_text(face = "bold", colour = "#AE030E", size = 18),
        plot.background = element_rect(fill = "#FFF8E7"),
        panel.background = element_rect(fill = "#FFF8E7"),
        plot.margin = margin(20,20,10,20))

# calculating the total times per year

all <- records |>
  separate(date, into = c("year", "month", "day"), sep = "-") |>
  filter(type == "Three Lap") |>
  expand(year, track, shortcut)

fastest <- records |>
  separate(date, into = c("year", "month", "day"), sep = "-") |>
  filter(type == "Three Lap") |>
  group_by(year, track, shortcut) |>
  summarise(min = min(time)) |>
  ungroup()

total_times <- all |>
  left_join(fastest) |>
  pivot_wider(names_from = c("track", "shortcut"), values_from = "min") |>
  fill(where(is.double), .direction = "down") |>
  pivot_longer(-1) |>
  fill(where(is.double), .direction = "down") |>
  separate(col = "name", into = c("track", "shortcut"), sep = "_") |>
  group_by(year, shortcut) |>
  summarise(total_time = sum(value)) |>
  ungroup() |>
  mutate(shortcut = factor(shortcut))

# total times plot

total_times |>
  pivot_wider(names_from = "shortcut", values_from = "total_time") %>% 
  ggplot(aes(x = year)) +
  geom_linerange(aes(ymin = Yes/60, ymax = No/60), colour = "#4C4A42", linetype = 3) +
  geom_point(aes(y = No/60), size = 3, colour = "#E03135") +
  geom_point(aes(y = Yes/60), size = 3, colour = "#185AA6") +
  labs(x = "", y = "Minutes",
       title = "Total time to finish all Mario Kart 64 tracks<br>at world record pace",
       subtitle = "<span style = 'color:#E03135;'>Without</span> shortcuts vs. <span style = 'color:#185AA6;'>with</span> shortcuts",
       caption = "World record pace calculated as lowest time per track each year") +
  expand_limits(x = c(-1, 28), y = c(15, 45)) +
  scale_x_discrete(breaks = seq(1997, 2021, by = 3)) +
  theme(legend.position = "none",
        axis.text.x = element_text(face = "bold", colour = "#4D556B"),
        axis.text.y = element_text(face = "bold", colour = "#4D556B"),
        axis.title.y = element_text(face = "bold", colour = "#4D556B"),
        axis.line = element_line(colour = "#4D556B"),
        panel.grid = element_blank(),
        plot.title = element_textbox(face = "bold", colour = "#AE030E", size = 18),
        plot.background = element_rect(fill = "#FFF8E7"),
        panel.background = element_rect(fill = "#FFF8E7"),
        plot.margin = margin(20,20,20,20),
        plot.subtitle = element_textbox(face = "bold"),
        plot.caption = element_textbox(face = "italic", colour = "#4D556B"))

The Problem with Using Youtube Clips for Posture Analysis

Mon, 26 Apr 2021 00:00:00 +0000

There’s been a few videos going around the parkour community recently claiming to perform postural and biomechanical analysis on some of the Storror athletes. I have a number of issues with these videos, but mostly, I think the methods used to conduct this kind of ‘analysis’ are deeply flawed.

Rather than write a lengthy blog post, I thought it easier to just my thoughts into a video, where I can also actively demonstrate some of the points as I’m making them:

For what it’s worth, I hate the idea of putting this kind of ‘response’ video out. The last thing I want is a return to the good ol’ days of internet flame-wars and drama. But, if you’re making grand claims in a public forum under the pretense of a scientific approach, I think it’s important that you are challenged on those claims when they don’t hold up to scrutiny.

Anyway. Tweet me if you want to discuss, I guess.

tinieR 0.4.1

Fri, 05 Feb 2021 00:00:00 +0000

I got really, really bored this week, so I decided to go back to the R package, tinieR, that I released last year (if you haven’t seen it before, tinieR shrinks image file sizes using the TinyPNG.com API). My idle tinkering ended up with a few cool little additions to the package, so I figured it was time for a new release: v0.4.1!

Why 0.4.1? Because I set it all up to be 0.4.0, but then I wasn’t entirely happy with some things and kept tinkering, and didn’t realise that it wasn’t exactly straightforward to change git release/tag options. So .1 it is…

New things

Here are the main additions to the package:

Added ability to set global defaults for tinify() arguments with tinify_defaults(). Changes made are printed to the console, and if called without any arguments, prints all current default settings.
Added new suffix argument in tinify() to change the “_tiny” suffix applied to tinified file names.
Added new return_path = "proj" option to return_path argument in tinify() to return the path to the newly tinified file relative to the project directory, no matter the current working directory.

You can read more in the new package vignette here, and here’s an example of the new defaults options in action:

```{r setup, include=FALSE}
library(tinieR)

tinify_defaults(
	suffix = 'resized',
	quiet = 'true',
	return_path = 'rel',
	resize = list(method = 'scale', width = 100)
)
```

Here is my image:

```{r}
knitr::include_graphics(tinify("imgs/example.png"))
```

Useful things I learnt

Aside from being slightly useful, the main reason I work on tinieR is to give me an excuse to poke around in R and learn new things about the language. So what did this latest round of tinkering show me?

tinify_defaults() really taught me about how to set and retrieve options in R, and in particular, how useful it is that they have a default argument to fall back on when not set.
It also taught me more about returning messages and warnings in R, how to suppress warnings when required, and how to use tryCatch to collect errors and supply my own or perform a new action.
…And how to deal with storing, setting, and retrieving these default options for use in package tests (using on.exit() mostly).
I didn’t end up actually using it (yet), but I also found out about the crayon package for printing coloured text to the R console - fun!
The new "proj" setting for return_path got me familiar with the rprojroot package. I’d used it before for… something that I forget, but it was great to really spend some time poking around in it. It’s a very useful package when you need it!
I wrote my first vignette, and it was interesting to see how the usethis package and my prior experience with Rmarkdown made it exceptionally easy.
Not directly for the release of 0.4.1, but I also spent some time tinkering with the pkgdown configuration for the package documentation site. Nothing drastic, just a new theme and some moving around of contents, but good to know!

I really recommend developing a package for getting to know R better. It doesn’t have to do much fancy - tinieR certainly doesn’t - but having problems to solve really gives purpose to your learning. If you want to try it, check out the R Packages book by Hadley Wickham and Jenny Bryan for a complete guide!

I hope you’ll try out tinieR for yourself - and if you encounter any issues, please let me know!

Pandoc filters in Bookdown

Sat, 30 Jan 2021 00:00:00 +0000

tldr: I wrote a Pandoc Lua filter to correctly format my Bookdown/Rmarkdown documents no matter the output file. You can see the filter as a Github gist here.

Apparently I’m never satisfied enough to stop futzing around with Bookdown. I’ve been twiddling and tweaking settings endlessly to see what kind of documents I can produce and, more importantly, how I can get similar results across a number of formats.

In the process, I’ve fallen over some really useful discoveries. They’re usually well-documented discoveries and mostly right there, out in the open, but for some reason I don’t see them talked about much despite their incredible usefulness!

Among these, number #1 with a bullet is the use of Pandoc’s custom filters to modify your source document. These are amazing. They’re basically ways of changing the output from Pandoc based on some logic, such as the output format. So I thought I’d talk about them a little bit here, and explain how I’ve put them to good use.

Pandoc filters

You can use JSON manipulation in any code language you prefer to do this, or write the filter in Lua. I chose to use Lua (despite not knowing Lua) because Pandoc includes a Lua interpreter embedded in it, so you don’t need any external dependencies. Fortunately, some Lua basics weren’t too hard to pick up, but please excuse my shoddy Lua coding in the examples given.

I think a diagram will help explain how filters work with Pandoc. Normally, building your book in Bookdown/Rmarkdown looks like this:

You write all your source docs, Bookdown/R processes all your code to produce plots/tables/etc and compiles all that into one mega-source doc, then ships that over to Pandoc with all your Bookdown options to produce your final output file (pdf/html/what-have-you).

With a filter, there is an extra step in the middle of the Pandoc circle. Under the hood, Pandoc reads in the input doc (book.Rmd in our case) and turns it into Pandoc’s own interstitial format (an ‘abstract syntax tree’ or AST). Normally this then gets written straight back out into your desired output format.

But! With a filter, you get a chance to jump in and apply some logic to the AST, before it then gets sent over to the writer for the output format.

So, let’s say we wanted to change something in the original source document based on whether we are creating a PDF or HTML document. Using a filter, we can create something this:

This gives you a chance to affect elements of your document independent of any input/output foibles, and most usefully, change what output Pandoc’s writer will generate based on whatever criteria you define. ¹

Writing the filter

Writing the filter is not super complicated, and the docs are very comprehensive, but it can take a second to wrap your head around how it works. Essentially, the filter should consist of a function named for one of the elements of Pandoc’s AST. Which is just another way of saying, the elements of your source document.

So, if you want to affect all the Strong elements of your document, you would write a function named “Strong” and pass it the element as an argument - Strong(elem). Pandoc will ‘walk’ the AST with your filter, and every time it finds a Strong element ², apply your filter function to the contents of it (elem).

The only caveat is that a function must return the same type of element that went into it - so for Strong elements, the function Strong() must return an Inline element. Some elements are Block elements, like entire paragraphs or divs, that must also return a Block.

This can be a bit finicky but basically, if the element can appear in the middle of a sentence, it’s probably an Inline. If the element is a collection of smaller elements, it’s probably a Block.

Example

Here’s a practical example. I like to use Pandoc’s fenced div syntax to define little breakout boxes of information in my documents. Here’s the syntax in my source Markdown file:

# Heading

Some text goes here.

::: notes
Here's the content of my breakout box.
:::

Pandoc already processes this into HTML, resulting in the following output:

<h1>Heading</h1>
<p>Some text goes here.</p>
<div class="notes">
<p>Here's the content of my breakout box.</p>
</div>

Notice how Pandoc has spotted our ’notes’ label on the paragraph in the Markdown and automatically applied it as a class to the div in the HTML. With a little CSS, this div then shows as:

Great. ³ But, if we want to output our document as anything else, this won’t work. Under the hood, Pandoc is still applying the ’notes’ label to our element in the AST, but that label doesn’t mean anything to the other output formats. Instead, we can use a filter to add the required information to style these boxes in other output formats, without having to change our input syntax.

For Word/docx output, Pandoc does let you apply a custom label to a fenced div, and will then map that onto a style with the same name in your Word reference doc. We could just change our syntax and write our source document like this:

# Heading

Some text goes here.

::: {.notes custom-style="notes"}
Here's the content of my breakout box.
:::

Here, we’re still applying the ‘.notes’ class in HTML (we have to include a period in front of it now though, as we’ve switched to use the bracketed divs syntax) but also declaring a custom-style of ’notes’ that, if we have the corresponding style in our Word reference doc, Pandoc will apply to the content of the div.

This is okay, but it’s nowhere near as convenient as the first example’s syntax. Why not stick with that, and instead have the filter add in the extra syntax for us instead?

After all, the whole point of all this effort is to keep the output syntax completely divorced from the input syntax, so you can export to any format you might need at a later time. If I start filling my Markdown with code aimed specifically at Word outputs, it defeats the purpose of using a tool like Pandoc in the first place!

In the filter file (using the .lua extension), we can define a function named Div and pass in our element. In this case, we’re passing in everything contained within the div - so a nested series of paragraphs, and within each of those, any inline elements. You could drill down and access those if you needed, but for our purposes, we just want to add an extra attribute to the div:

function Div (elem)
  if FORMAT:match 'docx' then
    if elem.classes[1] == "notes" then
      elem.attributes['custom-style'] = 'Notes'
      return elem
    else
      return elem
    end
  end
end

FORMAT is a global variable in a filter that just contains the output format currently being generated. Here, all we’re saying is:

If the output is docx, look at each div within the document.
For each div, see if it has the class ’notes’ with elem.classes[1]. ⁴
If a div has the class ’notes’, then also add a new attribute named ‘custom-style’ with the content ‘Notes’ and return the new div.
Otherwise, just return the original div.

Now, provided we have the style ‘Notes’ setup in our Word reference doc, it will automatically get assigned to our div in the output!

Importantly, if we switch our output back to HTML, it makes no difference - the class is just applied to the div as before, and the filter skips over the function as FORMAT doesn’t match docx.

Now, let’s also look at PDF output. Pandoc uses LaTeX as an intermediary to generate PDF files. Unfortunately there’s no way (I know of) to apply custom styling to LaTeX output natively in Pandoc that doesn’t involve just filling your source doc with actual LaTeX. At which point you might as well just… write LaTeX. Instead, we can use a filter to find our notes div as before, and wrap some custom LaTeX commands around the div contents instead.

I used the LaTeX package tcolorbox for this. The precise mechanisms of tcolorbox aren’t the main point here, but if you want to use it exactly as I have you’ll need to customise the LaTeX template to include tcolorbox as a package. Easiest way I found was to just put \usepackage{tcolorbox} in the LaTeX preamble as detailed here.

I also use some dvipsnames colour names in the code from xcolor with \usepackage[dvipsnames]{xcolor} so I can create shades of colours, but having recently stumbled over defining your own colours in LaTeX I might just swap these out for some good ol’ RGB values in the future. Hey, have you heard of the colour ‘Cosmic Latte’? (Thanks, Robin Sloan)

Anyway.

Here’s the filter code:

function Div (elem)
  if FORMAT:match 'latex' then
    if elem.classes[1] == "notes" then
      return {
        pandoc.RawBlock('latex', '\\begin{tcolorbox}[colframe=Apricot!20!white, colback=Apricot!8!white]'),
        elem,
        pandoc.RawBlock('latex', '\\end{tcolorbox}')
      }
    else
      return elem
    end
  end
end

This works much like the Word filter:

If the output is LaTeX, look at each div in the document.
See if each div has the class ’notes’.
If it does, create and return a new Block element.
- This Block element will contain some raw LaTeX code, followed by the entire original div itself (elem), followed again by some more raw LaTeX.
Otherwise, return the original div.

pandoc.RawBlock is what allows us to write some raw code in the language our output format uses - in this case, LaTeX. So the function basically ends up wrapping a \begin{tcolorbox} and \end{tcolorbox} around our div and, when output to PDF, the div is now surrounded by the LaTeX code required to create a coloured box!

And again, if we switch back to HTML, Pandoc just ignores this function and our output looks the same as before.

We can combine these two functions into one:

function Div (elem)
  if FORMAT:match 'docx' then
    if elem.classes[1] == "notes" then
      elem.attributes['custom-style'] = 'Notes'
      return elem
    else
      return elem
    end
  elseif FORMAT:match 'latex' then
    if elem.classes[1] == "notes" then
      return {
        pandoc.RawBlock('latex', '\\begin{tcolorbox}[beforeafter skip=1cm, ignore nobreak=true, breakable, colframe=Apricot!20!white, colback=Apricot!8!white, boxsep=2mm, arc=0mm, boxrule=0.5mm]'),
        elem,
        pandoc.RawBlock('latex', '\\end{tcolorbox}')
      }
    else
      return elem
    end
  end
end

(GitHub Gist)

I’ve since thought of a more streamlined way of doing this that doesn’t involve writing an ‘if’ statement for each type of box you’d like to create - see the edit at the end of this post.

Now we can use fenced divs with ::: notes with abandon in our original Markdown doc, and not worry about how it’s going to come out in our output format - no matter which we choose, it’ll be formatted as a coloured box.

Using with Bookdown/Rmarkdown

To use the filter with Bookdown/Rmarkdown, save it as a .lua file and place it somewhere convenient within your Bookdown project. I use filters/shortcodes.lua.

The most straightforward way I found to use the filter was to just tell Pandoc about it directly when we issue the command to build our document. In your _output.yml, just pass the filter as an extra argument to Pandoc using pandoc_args and --lua-filter. ⁵ You’ll need to include it for each output you want:

bookdown::pdf_document2:
	toc: false
	pandoc_args: ["--lua-filter", "filters/shortcodes.lua"]
bookdown::word_document2:
	reference_docx: "assets/ref-doc.docx"
	pandoc_args: ["--lua-filter", "filters/shortcodes.lua"]

Obviously you’ll also need to modify any of the surrounding files affected - maybe some custom CSS, or the Word reference doc, or the LaTeX template. ⁶

Once you get the hang of these filters, you can easily start applying all sorts of custom styling to your outputs from these fenced divs. You could very quickly add mores fenced div to this example - say, ::: warning, that produces red styled boxes. That’s on you though as this post has gone on long enough!

Thanks for reading, I hope it’s been even a tiny bit helpful. Get in touch if you’ve got any Pandoc/Bookdown tips of your own to share!

Edit: Another method

Since writing this post, I’ve also realised another way of applying these filters that doesn’t involve writing endless ‘if’ statements in your filter. Here’s the new function:

function Div (elem)
  if FORMAT:match 'docx' then
    if elem.classes[1] then
      elem.attributes['custom-style'] = elem.classes[1]
      return elem
    else
      return elem
    end
  elseif FORMAT:match 'latex' then
    if elem.classes[1] then
      local box = "\\begin{tcolorbox}[colframe=" .. elem.classes[1] .. "-frame, colback=" .. elem.classes[1] .. "-bg]"
      return{
        pandoc.RawBlock('latex', box),
        elem,
        pandoc.RawBlock('latex', '\\end{tcolorbox}')
      }
    else
      return elem
    end
  end
end

It’s not that different, but instead of explicitly assigning custom-styles in the docx we just apply elem.classes[1] directly. As before, as long as your Word reference doc contains a style named the same as the div you create, it’ll map over just fine. But this way, you can just create the styles in your Word reference doc and start applying them in your Markdown without having to touch the filter.

For PDF/LaTeX, the function now creates a string (with the extremely weird Lua string concatenation operator ..) that sets the colours in tcolorbox to a name matching the div name, with ‘-bg’ and ‘-frame’ appended to distinguish box background and border colours. The idea is similar - you can now just create the colours in your LaTeX template/preamble and start applying them in your Markdown without having to touch the filter, like so:

\definecolor{notes-bg}{RGB}{255, 248, 231}
\definecolor{notes-frame}{RGB}{255, 248, 231}

Or, you could always take out the ‘-bg’ and ‘-frame’ bits, and just give your divs the same names as some of the colour names LaTeX has built in.

These changes mean you can basically just leave the filter alone and create your styles/colours elsewhere to incorporate them, just as with the HTML/CSS output.

Just be a little careful, as this will apply to all divs in Pandoc - so if you’re creating a PowerPoint presentation for example, and you use the ::: incremental div to create incremental bullet points in your slides, then this filter will also try and apply the styles/colours ‘incremental’ to your output docs in Word/PDF formats. Word will just ignore any styles it doesn’t find in your reference doc, but this can stall PDF creation completely, so be ready to work round it or go back to the original elem.classes[1] == 'notes' method in the filter.

You might have already used one of these without realising - Rmarkdown uses a Pandoc filter to let you use the LaTeX command \newpage in your Markdown to force a page-break, even if your output format isn’t LaTeX/PDF. If you look, you can spot it in the command line arguments sent over to Pandoc when you build your book. ↩︎
Don’t forget this is in the AST, after Pandoc has read in and translated your source doc. So it doesn’t matter if the source was Markdown defined with **asterisks**, or HTML defined with <strong>tags</strong>. At this point, it’s all just Pandoc.Strong in the AST. ↩︎
If you noticed and wondered - I used ::before to add the text ‘Notes:’ in front of the first paragraph within each div with the class ’notes’. Custom CSS styling for your output is also bonkers-crazy-useful, but that’s another post. ↩︎
Pandoc will have already assigned it to our div from the fenced div syntax without us needing to do anything extra. ↩︎
If you want to get really fancy, you could create a custom Rmarkdown format to knit to that includes the filter by default - see here for more. ↩︎
I haven’t tried this with gitbook output yet, but in theory you can just inject the CSS for the breakout box into that and it should work fine. ↩︎

Scrivdown

Sat, 12 Dec 2020 00:00:00 +0000

In my last post on Bookdown, I mentioned using writing environments other than RStudio to work on non-code text sections. As I recommended in that post, I’ve been using iA Writer as my main text editor. It’s a great plain editor - I’m using it to write this post now. But, as my last big writing project got bigger, and bigger ¹, I found myself missing a lot of the writing project management tools from my previous preferred writing app - Scrivener.

In particular, I missed the ability to segment my work into an outline structure. I initially tried having separate plain text files to break up the text into sections to work on, but although Bookdown would stitch these back together into one final piece fine, they weren’t easy to work with. In particular, Bookdown reassembles these files in the order they are listed in the directory, so I ended up numbering all my files (01-intro.Rmd, 02-litreview.Rmd, 03-method.Rmd, etc). But, in Scrivener I would often work as small as the paragraph level, dragging and dropping chunks of text around to see what flowed best in the overall document. This just wasn’t practical in plain text files, as I’d have to re-number everything if I wanted to insert something between two existing files, or just live with cutting and pasting paragraphs within docs. Not the end of the world, but just not as easy as Scrivener.

So I wanted to move back to Scrivener, but I wanted to keep all the benefits of Bookdown - namely, having my R code included in the document to produce plots/tables, rather than importing images or copying/pasting tables into Scrivener each time I iterated on my code. I also wanted to keep the benefits of compiling to PDF with LaTeX, like auto-generated tables of contents and lists of figures/tables.

I basically wanted to use Scrivener as my plain text editor. And it turns out, that’s actually pretty easy, but not necessarily straightforward. Here’s how I set it up.

Inspiration

The idea for this workflow was heavily inspired by Scrivomatic, by Ian Max Andolina. Scrivomatic is great, and I used it extensively in the past, but it doesn’t deal with R code. This is the main difference to my setup; the additional layer of R and Bookdown, which also results in a simpler Scrivener setup as things like front-matter yaml code remain in Bookdown itself.

There are some other useful hints in the Scrivomatic docs worth looking at, like this tip on using custom styles when exporting to Word. It’s definitely worth checking Scrivomatic out if you like the idea of this kind of workflow and don’t need the additional step of including R code when compiling your document.

Scrivener setup

The nice thing about Scrivener is that you can set up your writing preferences in it, then tell Scrivener how much of that to keep or discard when it comes time to export your document to the final file format. So, you can set up your internal Scrivener editor pretty much as you like - fonts, colours, styles, whatever makes writing easiest for you. As we’re compiling to plain text, all that will be stripped out of the final export, but it can be useful for editing (I like to highlight bits I need to work on, for example).

The main thing you need for your project is in the menu Project > Project Settings... > Section Types. Here, I suggest just having Heading and Text sections setup, and under Default Types by Structure, setting all folders to Heading and files to Text. Then, you can setup your project in your binder with folders for each heading, nested folders for sub-headings, and files within these containing your actual text.

Because Scrivener can auto-detect heading levels from the Binder structure, then top-level folders will be H1s (# Heading), sub-folders will be H2s (## Heading), and so on.

Then, in the File > Compile menu, set the Compile for dropdown at the top to MultiMarkdown. You should set up your own custom compile format - in the left of the window, right-click Basic MultiMarkdown and choose Duplicate & Edit Format. This will open the compile format editing menu ². Give your new format a name, and choose to save it either into the project - so it will travel around with the actual .scriv file you’re working on - or globally, so it will be available in Scrivener no matter which project you open. I like to save a generic global version, then duplicate that into each project that I can fine-tune to that individual project if required.

In the format editor, click Section Layouts, then click the little gear settings icon in the top right. Make sure to untick Add closing hashes to titles. By default, Scrivener puts markdown headings as # Heading #, and this option will turn them into just # Heading. This allows you to put additional Bookdown header options, like {-} to create an unnumbered heading, in your folder names/headings.

If you like to use styles in your Scrivener editor while writing, then while still in the format editor, click MultiMarkdown Options, then set all the dropdown options here to None. This stops Scrivener from formatting our output based on internal Scrivener styles you might use - for example, by default it indents any text marked with the Code block style in the output. I found it easier to just switch these off, but you can experiment with them if you like.

You can play with some of the other settings in the compile format editor too. Most of it is fine as default, but you might like to explore it more. Make a note of the Processing section - we’ll come back to this later. Otherwise, just click Save to save your new compile format.

Back in the compile menu, you can make sure all the headings/text you want to compile are selected on the right, and that they’ve all been assigned the correct section layout. If you get a yellow box in the middle saying your layouts haven’t been assigned to a section type, just click Assign Section Layouts at the bottom and make sure Heading is set to Heading, and Text is set to Text Section.

Click the little tag icon in the top right of the compile menu, and delete any metadata fields listed here by clicking the row in the key box, then clicking the minus sign at the bottom of the menu. If the default metadata is left in, Scrivener will insert it as yaml at the top of the exported file. It won’t break anything, but as we’re using Bookdown for all our metadata, it’s unnecessary to include it again.

Finally, click the cog icon in the top right of the compile menu, and tick Convert rich text to MultiMarkdown. This lets you use visual WYSIWYG styling like italics and bold in the editor, and Scrivener will automatically put markdown formatting around it on export. Then, untick Escape special characters, otherwise Scrivener will escape out the code chunks we write later. The other options here can remain as default, but you can experiment with them if you feel confident.

And that’s it for Scrivener setup - you can then click Compile to export your plain text file. Scrivener will default to file.md as a file extension, but you can actually just type file.Rmd in the save dialogue for your filename to export to .Rmd - you’ll get a pop-up warning but just click the option that lets you use a custom file extension. You can check the output looks how you want - it should basically just resemble any other Rmarkdown file, as if you’d written it straight in RStudio.

So that’s Scrivener setup - what about R and Bookdown?

R / Bookdown setup

On the R side of things, you can basically setup a Bookdown project as normal - so project creation, index.Rmd setup, _bookdown.yml and _output.yml, all that stuff, remains the same. If you’re unclear on any of that, the Bookdown manual is the best place to start.

The main thing is to make sure you’ve set up Bookdown to find the file you’re exporting from Scrivener - I usually have a subdirectory like book/src that I then direct _bookdown.yml to find with rmd_subdir = "book/src", and then export from Scrivener into that directory. There’s a bit more detail on that in the manual specifically here.

The main difference is that code isn’t going to be written directly into your Rmarkdown text in Scrivener - instead, code is written and worked on in separate .R script files. ³ I like to store mine in another directory (I use an analysis folder in the Bookdown project directory). These can be worked on in Rstudio in the normal way. But, although the code will be written in .R files, rather than .Rmd, we’re still going to divide the code up into Knitr chunks using the following syntax:

## ---- example-table

mtcars %>%
  head(3) %>%
  kable(caption = "Example table with a long caption.",
      caption.short = "Short caption.",
      booktabs = T)
      
## ---- example-plot

mtcars %>%
  ggplot(aes(drat, wt)) +
  geom_point()

Knitr chunks in .R files are a bit strange, and don’t look like they do in .Rmd files, but basically boil down to two hashes and at least four dashes, followed by a chunk name: ## ---- chunk-name. Make sure not to have any spaces in the chunk name. It’s a little unclear, but a chunk will basically include everything up to the next chunk header.

Aside: I got curious about this syntax change and it led me down a rabbit hole of literate programming history, with a lot of this stuff seemingly coming from places like noweb, filtering through Sweave and into the Knitr we know and love today.

Anyway. You can work through your analysis in R exactly the same as usual, importing/creating data and analysing it however you see fit, then creating all your output tables/plots as chunks. For example, I can put the code above in a file called my-code.R in the analysis folder. You can split your analysis across multiple .R files too, if that’s easier. Just make sure each chunk name, even if in different .R files, is unique.

Why do it this way? You’ll see in the next step.

Linking the two

So, now we have our Scrivener setup to export to a plain text file for Bookdown to find in book/src, and our analysis code in analysis. But what if I now want to include the example-table from above in my final document?

This is where knitr::read_chunk() comes in! This function reads in an external file, without evaluating it. So, somewhere at the start of our index.Rmd file for Bookdown, we just insert a chunk with the following:

knitr::read_chunk("analysis/my-code.R")

You can do this for any .R file you want included.

Then, in Scrivener, at the point we want to insert the table, we just have to put an empty Rmarkdown code chunk, making sure it has the same chunk name as the table’s chunk in the .R file. For example:

Here is my text in Scrivener.

```{r example-table}
```

See my table above for more.

This will come out as plain text in our Scrivener export, and then when the book is rendered with Bookdown, be evaluated as code. Basically, if a chunk is empty, knitr looks for another chunk with the same name, and runs the code within that. As we pulled in our .R file with read_chunk, Knitr instead goes and finds our example-table chunk there, and runs it at the point in our document where we included our empty code chunk. This is why every chunk needs a unique name!

We can even cross-reference these chunks the exact same way we usually cross-reference things in Bookdown, with \@ref(tab:example-table) for the above. It all just works exactly the same as regular Rmarkdown docs, we’re just inserting the chunk code from an external source.

Phew! That’s a little mind-bendy, but it means that when we update any code in our analysis, we can re-render the book with Bookdown and have the relevant code chunk automatically fetched and run within the text.

The whole workflow therefore becomes:

Setup Bookdown
Analyse data with .R files in analysis folder
Create any tables/plots required as knitr chunks in .R files in analysis
Write prose in Scrivener
Include empty named chunks where tables/plots are required in Scrivener prose
Compile from Scrivener to .Rmd in Bookdown source directory
Render final document with Bookdown

All the normal Bookdown options for step 7 should work fine, including my previous post about compiling to different document formats from Bookdown.

Update (22nd June 2021): I recently stumbled over this blog post by Yihui Xie, the main author of Knitr, about using knitr::spin_child() to include R scripts in Rmarkdown documents. It pulls in and processes an entire R script file at a time rather than working by chunks, and can convert comments written in the R script into markdown. If you’d rather use individual script files to break up your work than chunks within files, this could be a nice alternative without needing to worry about chunk names.

Some complications

There are a couple of caveats worth noting with this method. First, only chunks from our analysis files that we explicitly include with an empty code chunk will be run. Anything not referenced with an empty code chunk somewhere in our final .Rmd source text won’t be run. This means any setup code - for example, data creation/import/cleaning steps - in an analysis script still need to be referenced somewhere, even if they aren’t creating a table or plot to be displayed. I find the easiest way to deal with this is to just put all the setup code in one big data-setup chunk at the start of an analysis script named something like setup.R, then include an empty chunk with the same data-setup name in index.Rmd.

Secondly, if you want to set code chunk options, you need to include those on the empty chunks, rather than in the analysis code chunks. This most usefully applies to plots in my experience so far. For example, to insert the example-plot from above with some chunk options:

Here is a plot:

```{r example-plot, fig.cap="Here is the caption for my example plot.", fig.scap="Example plot"}
```

Wow! What a plot. Figure \@ref(fig:example-plot) is amazing.

Because this can get messy in Scrivener, I tend to just use individual chunk options to set plot captions as above, then set a whole load of default chunk options for plots in my setup in index.Rmd:

knitr::opts_chunk$set(echo = FALSE,
                      fig.pos = "tbp",
                      out.extra = "",
                      out.width = "100%",
                      fig.retina = 2)

Post processing

If you’d like to make things a little more efficient, we can also link steps 6 and 7 from our workflow above using Scrivener’s ability to run a processing script on our exported plain text file. ⁴

Note: The below is for getting this working on MacOS. I don’t know how it differs for other operating systems. Soz.

Head to File > Compile, right-click your custom format and select Edit Format, then click the Processing menu option on the left. Tick the box that says Post-process on command-line to enable the post-processing options below. Click the Edit script button now to pop-up a little window that we can put our script in.

You can run R code from the command line using the Rscript executable and linking to it at the top of your shell script - if you’ve installed R, you can find where this is installed by running which Rscript at the command-line. Mine was in /usr/local/bin/Rscript, so I entered this at the top of my script following a shebang. This lets us run regular R code in the rest of the script, that will be passed to Rscript to run.

Scrivener also provides the full file path of the exported .Rmd file to our script as a command-line argument. Using this, we can run commandArgs(trailingOnly=TRUE) to collect those args. Then, using the rprojroot package, we can run:

rprojroot::find_root(rprojroot::is_rstudio_project, path = args[1])

…to set our working directory to the Rstudio project directory for our Bookdown project (assuming you’re using Rstudio projects with your Bookdown setup) and then render our book! ⁵

Basically, just copy and paste this in to the Edit Script pop-up:

#!/usr/local/bin/Rscript

args <- commandArgs(trailingOnly=TRUE)
proj <- rprojroot::find_root(rprojroot::is_rstudio_project, 
				path = args[1])
setwd(proj)
bookdown::render_book("index.Rmd")

Provided all your Bookdown files are setup (metadata in index.Rmd, _bookdown.yml and _output.yml in project folder), the book should build.

You can also just set the working directory manually if you don’t want to install rprojroot:

#!/usr/local/bin/Rscript

setwd("~/path/to/project/folder")
bookdown::render_book("index.Rmd")

Just be aware this will be hard-coded into your compile format, so if you move your files, or change project, be sure to update it.

Once you’re able to set your project directory as the working directory, you can write any R code you want afterwards. For example, I use renv to manage my project libraries and have built my own custom book rendering function that I load with devtools, so my full post-processing script in Scrivener is actually this:

#!/usr/local/bin/Rscript

args <- commandArgs(trailingOnly=TRUE)
proj <- rprojroot::find_root(rprojroot::is_rstudio_project,
			path = args[1])
setwd(proj)

source("renv/activate.R")
devtools::load_all()
build_book()

I turn this post-processing on/off as I feel when I’m working - sometimes it’s easier to render the book from within Rstudio, if I’m tweaking Bookdown settings for example, and sometimes I want to iterate on my actual prose so I’ll set it to auto-render from Scrivener.

Finally, because the shell Scrivener uses is (to quote the manual) “a very limited non-interactive shell”, I found it was having trouble finding my lualatex install. The answer was to enter this in the Environment text field under the Edit Script button:

/Users/james/bin:/Library/TeX/texbin

This added my user bin folder and TeX install to the PATH environment variable for Scrivener’s shell. If you’re getting similar errors, you may need to figure out where the thing Scrivener is failing to find lives on your computer, and add that to the Environment text field. Just enter the full paths to any folders you want found, separated by a colon.

Downsides

There are a couple downsides to this workflow that are worth noting. Mainly, it’s a one-way street from Scrivener to .Rmd. If you render your final document, then notice some plot caption needs to be changed, you have to go all the way back to Scrivener and re-export to .Rmd then re-render with Bookdown. The post-processing setup above can help minimise this, but it is a little more round-the-houses than just editing and knitting directly in Rstudio. I find this trade-off worth it, as it still saves me from all the time I used to spend exporting plots as images, importing them into Scrivener, then compiling from Scrivener anyway.

Secondly, in my experience Scrivener doesn’t play all that nicely with version control systems like git. It will work, but because a .scriv project file is really just a directory of other files, there’ll be a large amount of changes per commit every time you change something in your Scrivener project. So, if GitHub or similar is your preferred way of syncing your work across devices, it might be a little inconvenient. I find it best to set my gitignore to exclude .scriv files, only track my exported .Rmd files in git, and then just sync Scrivener using Dropbox to edit on the go with the iOS app. I also use the Snapshot feature in Scrivener itself as an in-built version control, if I ever need to rewind to previous drafts of pieces of text.

I feel like these drawbacks are pretty manageable and are definitely offset by all the writing tools Scrivener provides, now paired with all the functionality of Rmarkdown/Bookdown and LaTeX.

Thanks for reading this behemoth of a post, and I hope it’s somewhat helpful to anyone looking to make use of these two amazing writing tools together. Get in touch if you’ve got any other Scrivener/Bookdown tips!

And bigger. ↩︎
You can also get here by right clicking any compile format and choosing Edit Format. ↩︎
You could, of course, write your code in Scrivener directly - it’ll be run by R just fine when you export to .Rmd. But, it won’t be interactive - you won’t be able to run a bit of code, see how it comes out, tweak it, change it, re-run it… If you’re like me, this is the main way I work on code. It’s sadly very rare for something to come out right the first time! ↩︎
This is the main influence of Scrivomatic, which does the same to plug into Pandoc. ↩︎
find_root() locates the Rstudio project directory for a file, even if that file is in multiple sub-directories. There are other ways to find working directories for R projects with rprojroot, so if you’re not using Rstudio projects, check out the docs. ↩︎

GNU Terry Pratchett with Netlify and Hugo

Sun, 22 Nov 2020 00:00:00 +0000

Terry Pratchett is my favourite author. It’s not even close. His wit and wisdom shaped about as much of my worldview as my own parents.

He died in 2015, and it was awful. In the global trash fire of 2020, I’ve been re-reading a lot of his books for comfort, and it reminded me of this little endeavour.

There is a project, GNU Terry Pratchett, to keep his name alive in the internet, based on an idea from one of his books. His name is placed into the headers of a website - little bits of metadata that sites transmit to tell your browser how to deal with their contents - and transmitted with every request to that site’s server. In this way, his name will ping-pong around the internet forever.

If you’re interested in taking part, I recommend checking out the project site for details on how you can include the header in a bunch of different types of sites. You can also install some browser extensions that allow you to detect the header on other people’s sites when they’ve included it. It’s delightful to see it light up in places you weren’t expecting it.

Netlify and Hugo

This site is built with Hugo and hosted on Netlify. Netlify has a couple fairly easy ways to customise your site headers - check out their docs here. The most direct way I found with Hugo is to drop a file just named _headers in my static folder (and I imagine there’ll be similarities with other static site generators). Yes, the underscore at the beginning is important, and no it’s not got a file extension. On build, Netlify moves this extensionless file up to the publish directory, and it becomes the headers file for your site.

You can edit this extensionless file in any plain text editor. Within this _headers file then, just enter the following:

/*
    X-Clacks-Overhead: GNU Terry Pratchett

The /* means ’everything within root’, so this will apply to every page on your site. Then, you can just declare the custom header. Don’t worry, it doesn’t actually do anything except send the name. Browser’s will just ignore it. As proof - it’s activated on this site. Even if you don’t have the browser extensions installed, you can probably see it in your browser’s development tools, if you go looking under the Network tab.

Anyway. Here’s a nice Terry quote to finish this post:

“It’s still magic even if you know how it’s done.”

GNU Terry Pratchett.

Bookdown, Not Bookout

Tue, 15 Sep 2020 00:00:00 +0000

I first got to grips with the R coding language to do the statistical analysis for my dissertation, but I still did all my actual writing in more traditional word processing apps. ¹ This became a pain any time I needed to copy-paste an update into a table or, even worse, change a plot and re-export to an image and re-import it into my writing environment. Going forward, I resolved to find a better way to incorporate my analysis code and writing to avoid this problem.

Bookdown is a fantastic R package that compiles Rmarkdown source documents into one big output, with code evaluated and, crucially, the ability to add cross-references to tables/plots etc. It seems to work best when producing HTML or PDF output, for which it has a whole bunch of great customisation options. This is great, as I always submit my final work in PDF. Unfortunately, due to needing to interact with lecturers and non-R-code-users for feedback on my work, I also need it to work with the Word docx file format. It can do this, but it does not have nearly as many options for customising the output. And a lot of the things you can build when producing a PDF just flat out don’t work in Word.

This has led to… some work on my part.

Functionally building your book

The most obvious solution to me seemed to simply change what my code was doing depending on the format I was exporting to. I can tweak the final PDF output to be perfect, but the docx format has to be just good enough to get the point across to whoever I’m seeking feedback from.

You can set Bookdown to export to multiple formats, and set options for each export format, using an _output.yml file. But, weirdly, I didn’t actually find an easy way to change code execution within your document text itself based on the format currently being rendered by Bookdown. You’d think there’d be a way to declare is(pdf) or is(docx) and execute appropriately, right? Unfortunately not. ²

According to this Stackoverflow thread, you can determine the currently rendering format with rmarkdown::all_output_formats(knitr::current_input())[1]. I think _output.yml is supposed to be ‘shuffled’ by Rstudio so that index 1 is always the currently rendering output, but that wasn’t occurring when I tested it; every time I would just get back the first format listed in _output.yml, even if it wasn’t the one currently being rendered.So if _output.yml had bookdown::pdf_document and then bookdown::word_document in it, all I would get back is bookdown::pdf_document even when rendering to docx. ³

I could just swap in and out various outputs as I need them, of course, but I ended up taking a step back and considering what was really going on when rendering the document source files. If, like me, you’re using Rstudio as your IDE it gives you a handy ‘knit’ or ‘build’ button in your toolbar when it detects you’re in a Rmarkdown/Bookdown project. While nice, this abstraction actually ended up obscuring the underlying method until I went looking for it. Really all these buttons are doing is calling bookdown::render_book, itself a wrap around rmarkdown::render. This render function takes an argument for the format(s) to render when called, defaulting to the options found in _output.yml for each particular output format.

Once I realised that rendering a book is just another function, I decided to wrap it in my own function. I can then provide formats as specific arguments to bookdown::render_book, and use some yaml management packages (specifically yaml and ymlthis) to read and write the different, unique _output.yml files for each call as I need them:

build_book <- function(format = "all"){

  switch(format,
    "all" = formats <- c("bookdown::pdf_document2",
                         "bookdown::word_document2"),
    "pdf" = formats <- "bookdown::pdf_document2",
    "word" = formats <- "bookdown::word_document2"
  )

  for(fmt in formats) {
  
    if(grepl("all", fmt)) {
      out_yml <- yaml::read_yaml("_all_output.yml")
      ymlthis::use_yml_file(ymlthis::as_yml(out_yml), "_output.yml")
    }

    if(grepl("pdf", fmt)) {
      out_yml <- yaml::read_yaml("_pdf_output.yml")
      ymlthis::use_yml_file(ymlthis::as_yml(out_yml), "_output.yml")
    }
    
    if(grepl("word", fmt)) {
      out_yml <- yaml::read_yaml("_word_output.yml")
      ymlthis::use_yml_file(ymlthis::as_yml(out_yml), "_output.yml")
    }

    bookdown::render_book(here::here("index.Rmd"),
                          output_format = fmt)

    fs::file_delete("_output.yml")
  }
}

This pulls in a specific yaml file for a format from the project folder and sets it as the _output.yml for Bookdown to find and use. Now, when rendering, using rmarkdown::all_output_formats(knitr::current_input())[1] returns the correct file format for the current render, as it’s the only format in the output yaml file! This allowed me to put this at the start of my bookdown source files:

fmt <- rmarkdown::all_output_formats(knitr::current_input())[1]

And then test for output with:

if(!grepl("word", fmt)) {
  my_table %>%
    kableExtra::kbl(caption = "My full table caption",
                 caption.short = "Short caption for ToC",
                 booktabs = TRUE) %>%
    kableExtra::kable_styling(latex_options = c("striped",
                                                "HOLD_position",
                                                "scale_down"))
} else {
  exTab %>%
    knitr::kable(caption = "My full table caption",
                 booktabs = TRUE)

This lets me, for example here, use kableExtra to style my table for PDF/HTML output, then just use regular ol’ knitr::kable to render it for docx.

Taking it further

Once I started writing my own book rendering/wrapper function, other opportunities opened up for customising my build process. For example - one thing I like to do is build my drafts and save them into folders with today’s date, so I can put my feedback from lecturers in that same folder and keep it all together for easy reference. So I added the following to my build_book() function:

build_path <- glue::glue("book/builds/{Sys.Date()}")

bookdown_yml <-
      ymlthis::yml_bookdown_opts(.yml = ymlthis::yml_empty(),
        book_filename = "My Project",
        rmd_subdir = c("src"),
        delete_merged_file = FALSE,
        output_dir = build_path
      )

Now by creating a custom _bookdown.yml file for each call to build_book(), each build will save into a book/src/DATE specific folder.

There are tons of ways to further change how Bookdown builds your book based on arguments you provide to your own build_book, swapping in and out various Bookdown configuration files as required. Is this the most efficient way to customise your Bookdown project? Probably not, with all the creating and changing of existing yaml files, but speed isn’t really my concern here - running build_book and having to step back and wait for a minute or two for my code to run is much more preferable to the stupid amounts of time I spent correcting fiddly tables/plot/cross reference output by hand in Word before!

Word / .docx output tweaks

So now I can customise my output based on where I’m rendering, I need to fix a couple of other things in my docx output. These now need to be done by editing my reference document for Bookdown docx output. For a primer on creating and editing your reference doc, check out this article.

One extra thing I needed was numbered section headings, not just H1, H2 etc rendered as headings. This can’t just be set in Bookdown, but instead can be done in your reference doc by selecting your header, going to Format -> Style... -> Modify, and then finding this hidden gem of a menu in the lower left of the style formatting menu:

Then clicking Outline Numbered:

You can also click ‘customise’ here for some extra options, such as how much sub-headings should indent. Be aware you also need to do this for every heading you want numbered, so H1, H2, etc. I then combined this with build_book to choose whether to number headings in docx output:

build_book <- function(format = "word", word_num = TRUE){
    
  ...
   
    if(grepl("word", fmt)) {
      if(word_num = TRUE) {
        out_yml <- yaml::read_yaml("_word_output_numbered.yml")
        ymlthis::use_yml_file(ymlthis::as_yml(out_yml), "_output.yml")
        } else {
        out_yml <- yaml::read_yaml("_word_output.yml")
        ymlthis::use_yml_file(ymlthis::as_yml(out_yml), "_output.yml")
        }
    }

  ...

}

And just refer to the two differently formatted ref docx’s within _word_output_numbered.yml and _word_output.yml respectively. Each one gets swapped in when called upon.

Finally, I needed to put in a table of contents and lists of figures/tables at the start of the document. There really doesn’t seem to be an easy way to create ToCs in docx from Bookdown, but fortunately it’s just a quick click or two in Word to auto-generate them from document headings or existing document styles. ⁴ But, I wanted some blank pages at the start, with ‘Table of Contents’ etc as a heading on each one, so at least I had space for all these things set aside automatically that I didn’t need to think about.

You can include some basic latex functions in Rmarkdown, one of which is \newpage to start a new page. But, if I tried adding # Table of Contents as a header on a page at the start of the document, when I auto generate the ToC in Word this heading itself gets included in the ToC.

I ended up declaring pandoc custom style fences to give this page the style of ‘Title’ rather than ‘heading’, so it won’t be included in the auto generated ToC. I also used glue and the output detector from above to only include it in docx output:

if(grepl("word", fmt)) {
  word_toc <- glue::glue('
\\newpage
::: {{custom-style="Title"}}
Table of Contents
:::
\\newpage
::: {{custom-style="Title"}}
List of Figures
:::
\\newpage
::: {{custom-style="Title"}}
List of Tables
:::
\\newpage
::: {{custom-style="Title"}}
List of Appendices
:::
             ')
} else {
  word_toc <- NULL
}

word_toc

Remember to escape your forward slashes and your curly brackets in glue by doubling up!

Writing environment

Just as an aside, as great as Rstudio is, I wouldn’t really recommend it as the best pure writing environment. You can certainly make it a bit nicer with themes and by editing the font used, but you’re not going to get away from its original purpose as a coding environment. While fine for coding within projects, there was also going to be quite a lot of just regular prose writing, and I wanted to find somewhere a bit nicer to work on those parts.

Although Rmarkdown’s .Rmd files are theoretically plain text files, I found options to be limited when looking for a writing app that can handle them. Initially I tried using VS Code, as while first and foremost a coding environment, it’s highly customisable. In particular, a solarized colour theme, an R markdown plugin, and discovering VS Code’s zen mode got me quite a long way towards a pleasant writing environment, but it still felt a little janky.

I’ve ended up settling on IA Writer as my main ‘writing’ app of choice. It handles .Rmd files without a problem, feels super smooth, and full-screen provides a nice, distraction free writing environment. It’s not particularly cheap, but you get what you pay for. As a bonus, I can use Working Copy to sync my git repo for each project to my mobile devices and continue working on them in IA Writer’s mobile apps just as if I was on desktop.

If IA Writer is a bit too steep in cost, Typora is a really nice alternative. It’s currently free while in beta, so not sure how much longer that’s going to be the case, but it also handles .Rmd files really well. I just preferred some of the library/file management options in IA myself.

On mobile, 1Writer or Textastic are also great choices for iOS, and JotterPad on Android is also great for markdown, although I haven’t been able to check it works with .Rmd files myself yet.

Reproducibility

Once I start cobbling together workflows and hacks like those I’ve detailed in this blog post, I invariably start worrying about stability and reproducibility. ⁵ What happens when I want to start a new project? Or if I lose or break my laptop and I need to start over again on a new device?

This is where working in code is really handy, and having recently tried my hand at R package development comes in really handy. See, now I know just enough about how R works with packages to put my custom project functions - like build_book() - in an R/ folder within my project, and have the usethis package create me a DESCRIPTION file that lists my project’s dependencies.

I can then also drop all my book building assets - like my custom reference docs for docx files, custom latex preambles ⁶, bibliography files, the works - into that same project, push it to GitHub, and turn that whole thing into a template repository. ⁷ Now, anytime I need to create a new Bookdown project, I can just clone that repo, and run devtools::load_all() to have my custom build_book function back in action!

Taking it a step further, I can use the new-ish renv package to create a renv.lock file in my template repo that I can then use to exactly re-install the package dependencies I might need for any book project. ⁸

As a side bonus, while reassuring myself in creating a stable and reproducible project setup, this also follows a lot of the steps recommended to turn your research into a research compendium. This means that someone else can also download the git repositories I create this way, and similarly, use my renv.lock or package dependencies in DESCRIPTION to very quickly get up and running with a similar environment to mine to test out my work for themselves. I could even take it a step further and include a Dockerfile and link to an online Rstudio server using the holepunch package to recreate it exactly.

Wrapping up

This blog post is really the result of a couple weekends of StackOverflow diving and thinking about what I really need for my next big writing project. It can be a bit overwhelming working with something that has as many options as Bookdown/Rmarkdown does. The sheer amount of configurations alongside the integration with Rstudio can lead you to forget that, underneath it all, it’s all still just code you can pull apart and make do what you want with a little sideways thinking. I found a lot of questions online while researching this stuff from people trying to make Bookdown do something from within, when really a little meta-coding with a function that just swaps out different _bookdown.yml files as needed would do the trick.

I hope this post helps a little bit for those out there in the same boat as me. Us poor souls that still have to deal with docx and Bookdown need to stick together. If you have your own Bookdown/Rmarkdown hints and tips, tweet them to me, I’d love to hear them!

I like Scrivener, but man, be ready to spend some time reading the manual and figuring out all the little things you can tweak. ↩︎
There is knit::is_latex_output() and knit::is_html_output() but no is_word. You could work in the negative, but I wanted a way to be explicitly clear about exactly the format being rendered. ↩︎
Maybe I was doing something wrong, but it never worked for me. ↩︎
And nicely, table and figure captions from kable/knitr get given their own styles that can be used to generate separate indexes in Word. See this help article for more on generating lists of figures/tables in Word from document styles. ↩︎
My dissertation project was such a house of cards by the end that I was scared to change anything in any configuration menu/file incase I broke the whole thing. ↩︎
Now that’s a whole other rabbit hole to fall down… ↩︎
For a fun trick, setup this template repo with exactly the folder structure you want in all your projects, and use .keep hidden files to keep otherwise empty directories synced in git. Useful for that ‘data’ folder you want to keep in the template but don’t actually have any data in yet. ↩︎
renv is great, and near as I can tell is aiming to replicate the functionality of things like npm’s package.json file and python’s virtual environments. Highly recommend checking out, it’s worked very smoothly for me so far. ↩︎

How joyful were the Friends main characters?

Wed, 09 Sep 2020 00:00:00 +0000

(Tidy Tuesday is a project to supply weekly data sets for R users to practice their coding skills on. You can find full details here.)

This week’s Tidy Tuesday dataset makes use of the friends package put together by Emil Hvitfeldt. It contains a bunch of datasets put together by analysing the transcripts of the TV show ‘Friends’.

One of these datasets includes ’emotions’, categorised into one of seven groups that included the emotions ‘joyful’ and ‘sad’. These describe the emotion being expressed at any particular line in an episode’s script (referred to as ‘utterances’ in the data). I thought it would be fun to see what the overall ’emotion score’ of each episode for each character would be, where a ‘joyful’ utterance scores +1 and a ‘sad’ utterance scores -1. Would the overall emotion score for each episode come out positive or negative?

Overall, Friends is a more joyful show than not! ¹ Mind, the ’emotions’ dataset only seems to cover seasons 1-4, so that’s what ended up on the plot. ² Generally characters finish seasons on an up, except for poor Phoebe with season 2. However Phoebe does also get the highest joyful score with season 4 episode 17, which is the one where she finds out she’s pregnant with triplets, so swings and roundabouts!

Chandler has the least number of negative scores across all 4 seasons with just 5 scores < 0, while Ross has the saddest time of it with 16 scores < 0. However Ross is also the only character other than Phoebe to score above 10 in any episode, twice, so I guess the lowest lows lead to the highest highs?

This plot uses a combination of ggthemr’s ‘pale’ theme ³ further customised to remove some axis lines/ticks and change the background colour. I also used ggtext to add in the TV show logo to the title with element_markdown and <img>, along with glue to create a column of <img> tags containing everyone’s headshots that could be used as a facet label. Before this, I was using just text for facet labels, and I stumbled onto using strip.text.y = element_text(angle = 0, hjust = 0) to turn the facet labels for characters to horizontal and left-aligned, which looks much nicer for this kind of thing so I left it in as a note to future James.

Oh! And I even used my very own tinieR package at the end to reduce the plot file size for uploading to the web. Pretty cool!

Code (also at GitHub):

library(tidyverse)
library(ggthemr)
library(ggtext)
library(tinieR)

ggthemr("pale")

tuesdata <- tidytuesdayR::tt_load('2020-09-08')

main_cast <- c("Monica Geller", "Rachel Green", "Phoebe Buffay", "Chandler Bing", "Joey Tribbiani", "Ross Geller")

data <- 
  tuesdata$friends %>%
  left_join(tuesdata$friends_emotions, by = c("season", "episode", "scene", "utterance")) %>%
  filter(emotion == "Joyful" | emotion == "Sad") %>%
  filter(speaker %in% main_cast)

emotion_scores <- data %>%
  select(-text) %>%
  mutate(emotion_score = case_when(emotion == "Joyful" ~ 1,
                                   emotion == "Sad" ~ -1)) %>%
  group_by(speaker, season, episode) %>%
  summarise(episode_score = sum(emotion_score)) %>%
  ungroup()

emotion_scores %>%
  mutate(speaker = str_extract(speaker, "^[a-zA-Z]+"),
         season = glue::glue("Season {season}"),
         headshot = glue::glue("<img src='{speaker}.png' width = '35' />")) %>%
  ggplot(aes(episode, episode_score, color = speaker)) +
  geom_point(alpha = .5, show.legend = F) +
  geom_smooth(se = F, show.legend = F) +
  geom_hline(yintercept = 0, color = "grey") +
  scale_y_continuous(breaks = c(-5, 10)) +
  labs(x = "Episode", y = "Emotion Score",
       title = "How joyful were the <img src = 'friends-logo-tr.png' width = '90' /> main characters?",
       subtitle = "'Joyful' utterance = Score +1, 'Sad' utterance = Score -1, summed per episode") +
  facet_grid(headshot~season) +
  theme(#strip.text.y = element_text(angle = 0, hjust = 0),
        strip.text.y = element_markdown(angle = 0, hjust = 0),
        panel.grid = element_blank(),
        axis.line.x = element_blank(),
        axis.ticks.x = element_blank(),
        axis.text.x = element_blank(),
        axis.title = element_text(face = "bold"),
        strip.text.x = element_text(face = "bold"),
        plot.title = element_markdown(size = 16),
        plot.subtitle = element_text(size = 8),
        plot.margin = margin(1, 1, 1, 1, "cm"),
        plot.background = element_rect(fill = "#fffcf2"),
        panel.background = element_rect(fill = "#fffcf2"),
        strip.background = element_rect(fill = "#fffcf2"))

ggsave("friends-plot.png")
tinify("friends-plot.png")

Shocker. ↩︎
Maybe it gets darker in the later seasons. ↩︎
‘Rachel Green’ coming out green on the plot was entirely a coincidence, but one I’m happy to take credit for nontheless. ↩︎

Hugo Clinic Notes Theme

Sat, 05 Sep 2020 00:00:00 +0000

While publishing my dissertation online and putting together the Parkour Clinic site over the summer, I got increasingly familiar with the Hugo static site generator. I’d first set myself up with Hugo when I decided to scrap my previous personal training site, and move the few blog posts I had there over to a personal blog instead. ¹ At the time I just picked a Hugo theme, dropped it in, exported my blog posts from Squarespace into markdown, and left it ticking away as it was.

Eventually, though, I started tinkering with the theme I was using, extending the templates provided to customise how my blog was running. Likewise, when it came time to create Parkour Clinic, I knew I wanted to be able to use template partials to handle things like a navigation bar, that could be updated in one place but included on all the pages across the site. The last time I had properly built a site for myself from scratch had been almost twenty years ago; I remembered well the pain of changing one navigation menu URL and having to go change it by hand across dozens of html files. No thanks.

My ongoing experience of getting more comfortable with Hugo’s templating sparked an idea for another problem I was trying to solve at the same time - how did I want to create and store my patient clinical notes for Parkour Clinic?

I’d been thinking about this for a while. All my sports therapy work placements to date had essentially used hard copies of forms filled out by hand and kept in a filing cabinet - I didn’t have the space (or printer toner) for that. Neither did I want to use Word or similar to actually create the notes - I’ve gotten used to the speed and simplicity of writing in markdown. Besides, there wasn’t really anything beyond the occasional table or image that I need to include in a patient’s notes that needed fancier layout abilities than markdown provides.

But, I didn’t really want to just have a directory of .md files on my hard drive - it’d be nice to have some interconnectivity between these notes, so I could flip between them quickly or sort and group them in various ways (by date or by patient name, for example). And I wanted the markdown processed when viewing, so it’s easier to read, and be able to print the formatted document to PDF or similar if I needed to share it with a patient.

Solutions for clinics are out there - Cliniko seemed to be a popular one I saw a lot while researching - but I didn’t want to pay for a service like this, as I’m aiming to keep the costs of Parkour Clinic as low as possible since I’m not really monetising it. I could use a markdown based notes app, like Bear, but this would tie me in to their ecosystem (even if just a bit, as it’s fairly easy to export from something like Bear), and I was a bit iffy about sending off all my patient info to some cloud server somewhere.

So I built my own!

Hugo clinic notes theme

Hugo Clinic Notes is a theme for Hugo that lets you create markdown based patient notes, and then view them on a site running on Hugo’s bundled local web server. It’s been on my GitHub for a little while but just got accepted onto the Hugo themes repository, where you can try a demo and find instructions for downloading it. ²

Admittedly this is probably for quite a niche audience of those who 1) run some kind of clinic/service that keeps records like this and 2) is nerdy enough to want to work in markdown and on a local web server, but if that’s you and you’re looking for a relatively easy and free way to run a patient records system this might do the job. You can customise the forms included or just delete them outright and use your own designs, and there’s a number of views and ways to get to the document you want.

There are some nice little additions I’m quite proud of, like the use of @media print CSS media queries to remove the top and bottom navigations when printing any document (useful for creating PDFs of your completed forms to send to patients), or the way you can include table of contents based on markdown headings in the top navigation by just changing a setting in the yaml front matter. Oh, and the way the loop logic on the list-all-patients-by-name index page only create alphabet headers for letters that actually have patients under them. Man, that one took a while… ³

Here’s a couple hints: it’s just in a browser, so use the good ol’ Cmd / Ctrl + F find command to search text for the bits you need. It’s all just markdown under the hood so I also suggest using Git or another version control system to kind of ’lock-in’ each form as you complete it or make edits to one, to create a really nice paper trail of patient records over time. ⁴ If you want to get really advanced, I’ve even set up macros with Keyboard Maestro to gather input from prompts and then use Hugo commands at the terminal to create new forms with the correct patient name/date/time for an appointment and open them for editing in my markdown editor… But that’s up to you.

Like I said, this one is probably solely for me. But, building it was hugely rewarding, and I’ve been using it for a couple months now with my Parkour Clinic appointments where it’s solved my problem of patient notes storage practically perfectly. If nothing else, it shows how useful a tool like Hugo can be for putting a graphical frontend on a very simple backend.

Why pick Hugo, over the growing number of other static site generators available these days? To be honest, it was just because my wife used Hugo for her own blog and it was useful to be able to lean over to her on the sofa and point at bits of code while going “WHY ISN’T THIS WORKING”. ↩︎
I didn’t quite appreciate the time frame between submitting the theme to the Hugo repo and it getting accepted, so after a few weeks of radio silence I kind of thought it was a nice way of saying “your theme isn’t accepted and we’re just going to leave it until we all quietly forget about it”, so it was a nice surprise to get the email notification saying it was approved. ↩︎
And required learning about scratch! ↩︎
Just keep it local - I wouldn’t recommend syncing to a service like GitHub, even a private repo, for confidentiality reasons. ↩︎

tinieR 0.3.0

Sun, 30 Aug 2020 00:00:00 +0000

Developing my first R package, tinieR was one of the most rewarding projects I’ve done this summer (and I’ve been busy). So much so that I couldn’t stop tinkering with it; and so now here’s tinieR 0.2.0, with added resize ability and more choice in how it returns the newly tinified file path!

Resizing

You can now use the resize argument to change the image dimensions along with its file size. I recommend reading the TinyPNG API documentation on resizing methods first, to familiarise yourself with the various options you can use to change image dimensions.

resize takes a named list, containing a method string and at least one of width or height, or both width AND height depending on your chosen resize method, to specify the dimensions in pixels you would like the image resized:

tinify("imgs/example.png", resize = list(method = "fit", width = 300, height = 150))

This should work fine alongside all existing options, like overwrite.

New return_path options

Instead of just returning the absolute file path of the newly tinified file, you can now choose to have it returned as an absolute file path, a relative file path, or a list of the two!

Set to return_path = "abs" to return the absolute file path to the tinified file as before. Set to return_path = "rel" to return the file path relative to the working directory at the time the file was tinified. This may be useful if sharing a script with others across platforms, if you can be sure your project setups will be the same and you are being strict with working directories!

Finally, set to return_path = "all" to return both types of file path as a named list:

shrunk_img_list <- tinify("imgs/example.png", return_path = "all")

knitr::include_graphics(shrunk_img_list$absolute)

I hope these new options are useful - they at least seemed like things I wanted when I was using the package myself! You can see full details at the tinieR package Github repo where the update is available for download now 🔥

tinieR 0.1.0

Mon, 17 Aug 2020 00:00:00 +0000

TLDR: I wrote an R package. You can find it here: tinieR - An R package to shrink image filesizes with TinyPNG.com

I learnt R about a year ago to do the statistical testing for my dissertation. While borne of neccessity, it ended up kickstarting a whole coding journey for me. I’d done some dabbling in the past, but R was the first language that I felt like I really “got” and worked in a way that made sense to me, particularly with the Tidyverse series of packages.

I’ve since experimented with Python and JavaScript (particularly with SquatCam), but R will always hold a special place in my heart and be my first choice for a coding project, if possible. Looking for ways to keep progressing my skills, package development kept cropping up, and so I felt like it would be a really good way to get even more familiar with the language. The only trouble was, I didn’t really have any good ideas for things that a) I felt warranted a package and b) were within the scope of my current knowledge.

TinyPNG is a service I’ve been using for ages. It lets you upload PNG or JPG files and compresses them, resulting in much smaller file sizes, without any noticeable loss in image quality. I’ve used it for pretty much every image on this blog. In particular, all the graphs I like endlessly populating my posts with make excellent candidates for TinyPNG to shrink.

After using TinyPNG for so long via their web interface, I finally decided to investigate a more economical way of using the service. They have a whole bunch of third-party plugins and tools listed on their site that people have built. While investigating and trying out a Node.js CLI, I realised that I knew just enough about making REST calls to APIs in R that I could potentially just code myself an integration that could run directly in my RMarkdown files for blog posts!

I threw together a minimum working version of a function named tinify() that took a path to an image file and sent it off to the TinyPNG API, saving the result. It worked great - well enough that it occurred to me that other people might like to use it as well…

A few bumps along the way

Turns out package development, even for the simplest of packages with just two actual functions, is complicated.

First, as an invaluable resource, I used the R Packages book by Hadley Wickham and Jennifer Bryan extensively. It’s a great beginning-to-end guide to building a package. In particular, all the various things you need - licenses, readmes, namespaces, test, docs - are really easy to populate your package with. You still need to fill them in, but as a result, you’re far less likely to end up missing something that should be there.

But, for some things, a guide can only really hold your hand so far. For example, it can tell you the mechanics of how to create a test file, what it should consist of, and how to run it, but it can’t write the actual test for you, more’s the pity.

Testing in particular is something I’d never done before. The testthat package is an amazing tool for this, and I was able to get the basics down fairly quickly. In the end, I probably went overboard on my tests - I only had the two functions, so I had the luxury of not needing to write hundreds of tests for dozens of different things. Consequently, I really tried to cover all the bases for the two lonely functions I did have. I’m proud to have reached 98% code coverage as a result though!

When I was fairly happy with the state of my package, my thoughts turned to deployment. This blog post by Matt Dray on using GitHub Actions was really useful in pointing me in the right directions to set up a continuous deployment workflow and creating an automatically generated package documentation site. While again, probably overkill for this particular package, I wanted to really get to grips with the full package development experience.

One particular hurdle I encountered was the need for a valid TinyPNG API key and an example image file to be present for all my behind-the-scenes package code - namely tests and R CMD checks run on deployment by GitHub Actions. I didn’t want to expose my personal TinyPNG API token to the world, so needed a way to include it without making it visible to the public. It took a little experimenting but you can set your API key as an encrypted secret on your GitHub repo, and then access it by placing it as an environment variable (env) in the workflow yaml file using ${{ secrets.SECRET_NAME }}:

jobs:
    steps:
        name: Check
            env:
            _R_CHECK_CRAN_INCOMING_REMOTE_: false
            TINY_API: ${{ secrets.TINY_API_KEY }}
            run: rcmdcheck::rcmdcheck(args = c("--no-manual", "--as-cran"), error_on = "warning", check_dir = "check")
            shell: Rscript {0}

This environment variable is then accessed within my package code as part of the tinify() function with Sys.getenv("TINY_API").

As for an example image, this turned out to require putting my example.png file in a sub-directory of my package named inst/extdata. This file could then be accessed using system.file("extdata", "example.png", package = "tinieR"). As I didn’t want to be continually overwriting this file again and again every time I tested the package, I ended up learning about tempfile() and unlink() as a way to create a temporary file path, copy the example.png image to it, submit the temporary file to my function for testing, and then delete the temporary file.

As an aside, this worked fine for clearing all my tests, but I kept getting errors when R CMD check would try and run any of this in the ’examples’ section of my documentation. I have to admit I never cracked this one and just ended up wrapping all my example code in my docs in \dontrun{} - if anyone knows how I should be doing this, please let me know 😕

After all this fiddling, getting my first ‘build passing’ badge show up on my GitHub repo readme was one of the most satisfying feelings I’ve had in coding so far!

tinieR

So, here it is - tinieR on GitHub or as a pkgdown package documentation site. With it, you can shrink image file sizes with a simple call of tinify():

tinify("example.png")

You can set options to overwrite the original file or create a new file next to it, to provide details on the amount of file size reduction and the number of API calls made this month, and to return the tinified image file path for use in other image functions. You can also combine tinify with functions like purrr::map and fs::dir_ls to tinify entire directories at a time. Check out the links above for full details!

If you find any bugs, please let me know. This is my first package and I’m determined to keep learning as I try and make it the best it can be!

Thanks for reading. I’ve been messing around with coding projects for a little while now - see more of them by clicking here, or for posts using R specifically, here.

Correlation Between Some Common Physiological Variables in Parkour Vaulting

Fri, 14 Aug 2020 00:00:00 +0000

In my last blog post, I explored the data that resulted from my undergraduate dissertation a little bit more. As I say in that post, I know it’s a little frowned-upon from a purely scientific point of view to double-dip on your data, but I can’t resist going back to that well.

So I got curious; my dissertation focused on movement choice and landing style as factors affecting ground reaction forces (GRFs), but I’d collected a bunch of characteristic data like age, height, etc. about the participants that went mostly unused. Could any of these also play a role in how well someone mitigates their GRFs?

I played about in RStudio for a while so try and explore this question. I’ve decided to stay away from much in the way of formal statistical tests in this post, and instead just tried to visualise things with a little commentary. This is mainly just to avoid anyone grabbing an offhand t-test result and declaring “tall people are statistically worse at parkour” somewhere. I just find it interesting to look at these connections (or really, as you’ll see, the lack of them) as a way to prompt questions for the future.

Regression and correlation

The first subset of characteristics were continuous variables, things like age, height, etc, and so it seemed that a linear regression would be a nice, simple way to visualise how two variables may relate. I decided to focus on just vertical GRF over horizontal (for a short primer on types of GRF, check out my resultant forces post), just because it’s often the most relevent to jumping and I didn’t want to completely overrun this post with plots (and I normally love plots).

I also chose to keep the breakdown of movement and landing style in each plot. This is how the original study ran and it made sense to me to break things down this way, to keep the data within each movement/landing style as homogeneous as possible.

For each plot, the blue points are the individual data points from each participant for that movement/landing style. The red line is the linear regression, which is the straight line that best fits the data - that is, that best fits in such a way that it minimises the distance between the line and all the data points as best as possible. The fainter red area around the regression line is the standard error (SE). The narrower the SE is, the less varied the data is, which means any correlation found may be more reliable.

Generally, the less ‘spread out’ the data points around are the line as it goes either up or down, the stronger the correlation between the variables (either positively correlated if the line is going up from left to right, or negatively if it’s going down). To help with this distinction, I’ve also annotated the plots with Pearson’s R, which is a numerical representation of the strength of the correlation relationship. The closer R is to 1, the stronger the correlation. A hazy cloud of points means there isn’t much correlation, while a perfect line indicates a very strong correlation. The ‘steepness’ of the line doesn’t indicate much about the correlation, but does kind of indicate how much a unit change in one variable affects the other - the steeper the line, the more a change in y produced by a change in x.

Just as an example of perfect correlation, from the parkour vaulting data - the plot below plots the participant’s weight as recorded on the force platform in Newtons against their weight calculated in kilograms. As the Newton-to-kilogram conversion is the same for each weight recorded (Newtons divided by 9.81 for earth’s gravity), they always correlate perfectly. As weight in Newtons goes up, weight in kilograms always goes up by the exact same amount. On the plot, this means a perfect 45° line of data points, an equally perfect linear regression line, and no SE shading at all.

Of course, correlation does not mean causation, so it’s important to note any relationships found with these plots doesn’t automatically mean one causes they other; there could be many reasons for the relationship outside of the two variables under the microscope. I’ll mention that a little bit more as we go.

Age

Let’s start with a simple one. What effect does age have on vertical ground reaction force?

The age of participants in this study ranged from early 20s to early 40s. That’s not covering every age bracket but it was pleasingly wider than the average age of traceurs, which skews young partly because of the urban-cool imagery of the sport but also because it’s just not been around long enough for many practitioners to really get old (although we’re getting there, aren’t we? Oh god my knees).

Age is a common enemy for athletes of all disciplines. For traceurs, the onset of osteoarthritic conditions, cartilage breakdowns, and increases in tissue healing time may present risks for joints placed under frequent high impacts, particularly in the lower body. Sarcopenia may result in the loss of muscle mass, reducing the ability of leg muscles to eccentrically absorb impacts and raising GRFs.

Fortunately, from this data alone, that doesn’t seem to be kicking in for our traceurs. The SE is pretty wide for most of these, so it’s difficult to draw too many conclusions from this, but it can at least be said that no obvious relationship exists. Continued exercise and training has been shown to combat many of the detrimental effects of aging, and I see no reason to think it’s not the same for our traceurs.

Training experience

If anything, the (slightly) older guys in the study had been training for longer - perhaps training experience offsets the effects of aging? Does practice really make perfect?

No, not really.

There is some, very slight, evidence of a downward trend in vGRF for the precision landing style as you gain more training experience, but weirdly the opposite for the running style landing. It’s all very weak though, and those SEs…

Even the least experienced traceur in this study had been practicing for 5 years. That’s still a pretty long time - you certainly couldn’t call any of the participants novices. And that’s not including any other sport or fitness experience before they started training parkour. The law of diminishing returns may be at play here, with the difference between 5 and 15 years experience being far less than might be seen between, say, 1 and 5. It would be interesting to run something similar but include much ’newer’ practitioners.

Height

Okay, let’s go back to some more physiological reasons. The study involved a vaulting box of a fixed height, so perhaps the various heights of the participants would interact with the height of the box differently and result in vGRF changes?

Actually, maybe!

There is certainly a stronger relationship seen between height and vGRF for the precision landing style, with vGRF decreasing the taller the participant. Purely as a function of distances travelled this makes sense - a shorter participant is falling a greater percentage of their overall height than a taller participant.

I can also imagine that taller participants had to jump less to clear the obstacles, generating less force in their take-off and potentially resulting in an overall decrease in momentum throughout the movement that they then had to re-absorb on landing.

Unfortunately, this speculation doesn’t really extend to why we don’t see the same relationship in the running style landing. The best I can think of is that there is a key biomechanical difference between two-leg and single-leg landings. Studies have found flexion at the knee is drastically lessened in single-leg landings. Does this even the playing field? Are taller traceurs actually mechanically better at absorbing GRFs due to the longer levers of their leg? And so if the ability to flex at the knee is taken away or reduced, they can’t benefit from it as much?

This one stumped me a bit. I’d be curious to hear if anyone out there has any thoughts.

Weight

Well this one should be obvious. The heavier you are, the more GRF you should be generati-…

Huh.

It’s not all that strong, but there seems to be a negative correlation here. That is, the heavier you are, the less vGRF you produce. What?

It’s worth noting that the force readings for this study (and all these plots) were standardised to multiples of bodyweight (BW). ¹ Weight and force were both initially measured in Newtons on a force platform. So, if one participant landed with a force of 600 Newtons, and they weighed 600 Newtons, they got a result of 1 x BW for that landing (600 / 600). If they landed at 1200 Newtons, they got 2 x BW (1200 / 600).

If someone weighing 1000 Newtons landed with a force of 1000 Newtons, they also got a result of 1 x BW (1000 / 1000). Generally, 1 x BW is the force you’ll be exerting on a force platform if you are just standing still on it.

So, in this plot, the heavier participants towards the right of the x axis are most likely still landing with more absolute force - that is, higher Newtons. You can see that if I take the previous plot and change the force units on the y axis back to Newtons:

Here’s that mostly upward trend we were expecting before. A good demonstration of why the units in a plot matter!

Still, it’s interesting to note that the heavier participants in this study were landing with lower multiples of their own bodyweight, or lower relative force. Perhaps they were heavier because they were more muscular, and better able to absorb their GRFs? Maybe they were heavier because they were taller, and therefore actually we’re just seeing another version of the height plot above? Oh no, now I have to go back and look at that plot again…

It’s a good example of why you can’t take variables in isolation, and why it’s so hard to conlusively prove the effect of some interventions. You have to control for these things and try and tease apart the relationships to make sure you aren’t just measuring the same thing twice!

Vertical and horizontal GRF

I was also curious, are the vertical and horizontal braking parts of a GRF correlated themselves? After all, in the ‘real world’, they’re really just components of a larger resultant force.

Plotting them against each other gives us this:

It varies from movement to movement, but there is some mid-to-strong correlation between the two for precision landings, with weaker correlation for running landings.

If you’re coming to a complete stop with a landing, you’re applying the brakes in both directions - vertically and horizontally. So it makes sense that they would kind of sync up - the harder a landing, the greater force in both directions the ground will produce to deal with it and bring you to a stop. With a running landing, you are trying to arrest your downwards vertical motion, but not your horizontal motion - if anything you’re doing the opposite and trying to minimise horizontal braking entirely to avoid slowing down. This desyncs the goals for vertical and horizontal GRF production, reducing their correlation.

It might be interesting to see if there’s a resulting correlation between vertical and propulsive horizontal force instead in running landings. I don’t have that data to hand but it could be worked out from the raw force platform data collected for the dissertation project. I may come back to it, or if anyone out there wants some homework…

Landing foot

Finally, moving away from regression and correlation a bit, I also asked participants which landing foot they preferred to land on for single foot landings. Would this make a difference to vGRFs?

This one just involved two categories, left foot or right foot, so a correlation/regression plot wouldn’t work, so this one is a boxplot with a simple t-test performed between the two groups (annotated by the lines at the top of each plot square).

Sometimes, lefties did better, and sometimes righties did. But, there was never a significant difference between their results. And good thing too! Otherwise, we’d be teaching everyone to land on the same foot all the time. This was one plot I was happy to find absolutely nothing worthwhile in.

Of course, it would still be interesting to see how performance differs between their own two feet for traceurs… But that’s another study for another time.

Thanks for reading. If you enjoy this kind of nerdy deep dive on parkour movement, you can check out the original study this data came from here and even grab the data for yourself if you would like to perform your own analysis. You can also view the source code for all the plots in this post here.

You can see this in the plot at the start of this post showing perfect correlation, because weight in Kg and weight in Newtons are just measuring the exact same thing. ↩︎

Parkour Clinic Launches!

Wed, 05 Aug 2020 00:00:00 +0000

After a few long months of planning and preparation, and some not-inconsiderable beauracratic wranglings, I’m happy to finally launch a new project: the Parkour Clinic!

Ever since graduating as a sports therapist earlier this year, I’ve been looking for something to do that used my hard-won therapy skills, but more importantly was also useful. I’m going to continue studying with a Masters degree starting in October 2020, but until then, the plan initially had been to fill my summer months by looking for some actual real work treating real patients. You know, like a real sports therapist, which I am now. ¹

Unfortunately, my graduation turned out to be bang in the middle of the covid-19 / coronavirus pandemic, and so setting up (or joining) an in-person sports therapy clinic became… somewhat impractical. Besides, even at the best of times, setting up my own clinic would involve a potentially large investment. So, I started looking into options for delivering therapy remotely.

It turns out this is a solution that the sports therapy (and physiotherapy) world is exploring more and more. The increasing focus on patient education and exercise prescription over hands-on therapies like massage means that a lot of effective therapy advice and guidance can be delivered over a webcam. ² This allows therapists to reach a much wider audience and potentially help a lot more people than just those who can physically attend a clinic session. And, delightfully, most of the things you need - a website, a booking system, and a video calling platform - can be setup for free these days. ³

Parkour has played a big role in my life, changing my career, social circle, and health. It did all this, basically, for free. So once I realised the cost to myself would be minimal, and could be run in my spare time, offering an online sports therapy service for the parkour community that was also free seemed a good way to give back to something that has given me so much. Once I had the idea, I couldn’t at least try it.

Parkour Clinic

So here it is - Parkour Clinic, offering free online sports injury therapy advice for parkour athletes.

I recommend checking out the clinic FAQ for more detailed information on how it works, what sports therapy is, and how it can help you. And, you can always send me a message if you have any questions not answered on the site.

You can also connect on social media if that’s your cup of tea, with @parkourclinic on:

Please consider sharing word of Parkour Clinic with your friends and parkour community!

And when you’re ready to make your appointment, book now and I look forward to speaking to you soon!

Still doesn’t quite feel real after studying it for so long! ↩︎
I’m grateful to the likes of Adam Meakins and the Better Clinician Project for opening my eyes to the possibilities of this approach. ↩︎
With the trade-off usually being the time and knowledge you invest in it - I did a lot of research setting up with the right tools, and building the website by hand instead of using a pre-built host like Squarespace. Buying off-the-shelf solutions might cost you, but it sure is quicker. ↩︎

Resultant Forces in Parkour Vaults

Tue, 04 Aug 2020 00:00:00 +0000

I had a lot of ideas for what I wanted to include in my dissertation. Starting out, writing my proposal, I wanted to look at everything I could think of in relation to vaulting in parkour and the landing forces that result. I wanted to include rate of force development, projectile motion of bodies in the air, motion tracking joint angles… Every biomechanical variable you could think of, I wanted it in there.

Unfortunately, the more variables you start throwing in, the more diluted your study becomes. It’s hard to tell a good story about so many outcomes! The best scientific studies I’ve read have picked one variable and really gone in on what it is, what it means, and why you should care about it. There’s also a lot more statistical work involved with more variables, and frankly for undergrad level it was overkill. So I drilled down, and went with what I considered the essential.

As a side effect, I ended up with a lot of research and ideas on the cutting room floor. As the final study is done and dusted, it seemed a shame to throw the data out with it. I get that’s how strict science is supposed to work; hypothesis, gather data, test hypothesis, done. But I’m not writing a second paper with it; I just want to poke and prod it a little to get some ideas.

Plus I like making graphs.

One discarded idea that really stuck with me was an investigation into the resultant landing forces that people experience when landing from parkour vaults. So I decided to dig into it further. I wanted to share some of these observations, but that’s all they are. I haven’t done any in-depth statistical testing here. But, resultant forces present a really interesting way to visualise the forces acting upon a body when landing from a movement, particular one that doesn’t just involve jumping straight up and down, but involves a horizontal travelling component.

Let’s jump in, but first…

What is a landing (or ground reaction) force?

Most people are at least vaguely familiar with Newton’s Third Law of Motion - often summarised as ‘for every action there is an equal and opposite reaction’. When it comes to landing, this means that the floor ‘pushes’ back on you exactly as hard as you push upon it. It has to; if it couldn’t match your force in coming down, you’d smash straight through the floor. This force is called the ground reaction force (GRF), which makes sense, as it’s the force the ground is reacting to you with. Sometimes science comes up with really hard, confusing names for things, and sometimes it’s just like ‘yeah, just call it exactly what it is’.

Anyway, if jumping straight up and down, it looks like this, with the green arrow as the force your landing is exerting, and the red arrow as the GRF:

This is generally known as vertical GRF.

The strength (or magnitude) of the forces at play depends upon a few things, such as your bodyweight, the speed you are travelling, and how much you are able to actively mitigate the impact you make. The final one is pretty much what I studied in the dissertation and one of the things people are most interested in with parkour - the ability to absorb and reduce some of these landing forces using good technique and strong leg muscles. Some people can land really softly, and some people can come down like a sack of bricks, despite weighing the same and dropping the same distance.

As well as jumping straight up and down, sometimes you jump forward and backward, or side to side. These movements have their own GRFs, corresponding to the direction you are moving. Again this makes sense - the ground has to stop you from continuing to move forward if you do a broad jump, otherwise you’d land and continue to slide forward forever until you met another obstacle. While hilarious, this would be impractical.

While side to side (or medial-lateral) GRF is useful for things like studying balance, I just looked at forward-backward (or anterior-posterior, or just horizontal) GRF alongside vertical. Here’s a diagram of horizontal GRF acting as a braking force to slow you down:

One interesting note here is that horizontal GRF also applies to activities like walking or running, and has two sub-divisions. Braking GRF is when the ground is stopping you from carrying on; if you’re coming to a dead stop after a movement, this is all that will affect you. But if you’re continuing to move forward in some way after landing, you also use propulsive GRF to push off the floor and accelerate. Suddenly, the ground isn’t pushing back on you to slow you down, but pushing you forwards:

The interplay of braking and propulsive forces is what allows us to walk, run, and sprint. This comes up when it comes to landing from a vault with a running landing. We’ll get there a little bit later.

So what’s a resultant force here?

So, we have vertical and horizontal as two directions of GRF commonly studied by sports scientists. But when you’re coming in to land from a broad jump or a vault, you’re often not just coming straight down, or sliding along the ground perfectly horizontally. You are moving in a combination of up-and-down, and forward-and-backward directions. The force you are exerting on the ground isn’t really split two distinct parts, even though it’s often studied in this way, but is actually a single force coming in at an angle. For our uses, the resultant landing force is therefore the combination of the vertical and horizontal GRFs acting upon you when landing, reflecting the kind-of-real-world-equivalent force you’re experiencing.

To illustrate, if you’re landing like this:

GRFs don’t push back upon you in separate vertical and horizontal stages, like this:

They match not only the magnitude of the combination of the forces, but also the angle:

This presents a fairly intuitive way to visualise the forces acting upon you when landing in any movement that isn’t just straight up-and-down. So, much like dealing with solely vertical or horizontal GRF, we can use the resultant GRF to determine the effect that a landing will have on you.

As an aside, you might wonder why GRFs are normally decomposed into separate vertical and horizontal components. Well, it’s just generally easier to analyse, and there’s usually more of a direct relation between one component and the movement being carried out. You might be more concerned with horizontal GRFs for a sport like sprinting where there isn’t as much up-and-down movement and acceleration is really important, so you focus there and leave vertical GRFs out to present a clearer picture of your area of interest. Jumping is usually up-and-down more than horizontal, so the focus is on vertical GRF. Parkour joins sports like gymnastics and dance where a combination of vertical and horizontal motion mean resultant forces might be something worth looking at more than the individual components.

Why look at landing forces at all?

Generally, the larger the magnitude of GRF you experience, the more stress is passed on to the body, and the greater your chance of an injury from that movement. It’s not always cut-and-dry, there are a lot of other factors that can go into it, but basically we know that larger GRF on landing is more demanding of the body to deal with, and more likely to hurt you in some fashion than a smaller GRF.

Since the exact amount of GRF you’ll experience varies a lot throughout the stages of a landing, generally we look at the peak amount, or largest magnitude value we can identify during the landing. In investigating these forces, I found that vertical GRF plays a much more influential role in the magnitude of peak resultant GRF than horizontal does; that is, peak vertical GRF is usually much larger than the peak horizontal GRF and so peak resultant GRF occurs mostly around the same time as peak vertical.

With resultant forces, we can also look at the angle that the GRF is applying itself to you, and mostly here I’ve looked at the angle that peak resultant GRF occurs. 0° is flat, and 90° is straight up, so any resultant angle lower than 90° means that the peak occurred during braking, and angles beyond 90° mean peak occurred during propulsion.

Here, I’ve looked at angle with just interested observations. I haven’t gone in depth on the subject (yet), but since shearing forces are a thing, it’s easy to imagine that the angle a GRF acts upon your tissues could also play a role in injury.

Calculating and plotting resultant forces

I won’t go into a lot of detail here; you can find a really good breakdown on how to calculate resultant forces in this article.

The nice thing about working with purely vertical and horizontal GRFs is that we know what the angles for each are always going to be. Vertical GRF will be 100% of the force at 90° and 0% at 0°, and horizontal will be vice versa. We don’t need to further break down the x and y components of each force. This means we can simplify our calculations to work out resultant from vertical and horizontal GRFs to just the following (in R):

resultant_magnitude = sqrt(Horizontal_GRF^2 + Vertical_GRF^2)
resultant_angle = (atan2(Vertical_GRF, Horizontal_GRF) * 180 / pi)

Applying this to all the GRFs in the force platform data I collected, it’s then quite easy to just filter for the peak value with max(resultant_magnitude), also grabbing the angle and vertical / horizontal GRFs at the time when that peak occurs. When it comes to plotting, we can then just use the horizontal GRF as our x co-ordinate, and the vertical GRF as our y component, provided we make sure the plotting grid has a 1-1 ratio for x and y co-ordinates. You can do this in R and ggplot2 with coord_fixed().

Et voila! We can now view our resultant force data in a variety of ways.

Finally, the point

I wanted to get a broad overview of the resultant forces in parkour vaults first. There were 10 participants in the study, and each performed 3 repetitions of every movement with each landing style.

Note: if you haven’t read the original study for this data, the movements performed were a drop landing, a step vault, a kong vault, and a dash vault. The landing styles were a precision landing, with two feet coming to a stop, and a running landing, with one foot and continuining into a run. Force readings were normalised to bodyweight (BW), to allow comparisons between people that weigh different amounts. Generally, 1 BW is the GRF you experience standing upright and still on the ground, as a result of gravity. The GRF figures for precisions landings were also halved to give the GRFs passing through a single limb, to match with the running landing.

Taking the mean of all 3 reps, and then the mean for all 10 participants, for all movement/landing style combinations gave the following:

You can view this plot (and all that follow) as if the participant was coming in to land from the top right of each square; the arrow indicates the direction and magnitude of the resultant GRF pushing back upon the participant as they hit the floor. For the Horizontal / x component of the plot, positive numbers indicate braking, while negative are propulsive. Like this:

(Definitely not to scale)

You can see a couple things straight away from this plot. Resultant GRF magnitudes increase with a running landing compared to a precision landing. This agrees with my findings in the original study about vertical GRF, and given the dominance of vertical GRF in calculating the peak resultant force, makes sense.

Resultant angles were all below 90° for precision landings, and all above 90° for running landings. This means peak resultant GRF occurred during braking for precisions, and during propulsion for running landings. This also makes sense, as you’re coming to a stop with a precision but continuing forwards with a run. Still, it’s good to note that the greatest GRF occurred because the participant was accelerating, and actively pushing on the ground, rather than during the initial period of landing. More on this later.

Alright, what if we try looking at individual participants? Do the resultant forces depend a lot on the person, or are they consistent regardless of who performs them?

Okay! So, it looks to me like precision landings produce a more consistent resultant force overall, with running landings have a lot more variation in resultant angle. There’s a pretty weird single arrow sticking off in the drop / running group, but otherwise the observations from the group averages stand. There’s an increase in magnitude when switching to a running landing, and running landings tends to be a bit more anteriorly (forward) shifted in their peak resultant force angles.

Can we get a broad overview of how this breaks down per partcicipant for each movement and landing style?

Yes! Although a bit harder to see as it’s zoomed out quite far, this plot shows each participant as a column, and each movement as a row. The red arrows show the average values we’ve been looking at so far, but the fainter blue arrows show the actual results from each individual rep that the participant performed. By seeing how much blue shows up, and how far apart the blue arrows are from each other, we can get a sense of how much the repetitions varied from each other for that participant and movement.

Just scanning your eye over it, you can get a sense for the general direction the arrows are taking for all precision landings - all posterior, or less than 90° from horizontal. There isn’t a lot of blue showing, indicating mostly consistent results per participant, although partly that could be because of the zoomed out scale. Still, the movement that seems to produce the most blue arrows is the kong; let’s make a note of that.

Here’s the equivalent for running landings:

Again, just scanning over the plot, you can get a sense of the general direction of the arrows; a lot more straight up or anteriorly orientated, at or beyond 90° from horizontal. This matches what we saw in the averages plot earlier. There’s also more blue showing up in the kong again…

We could start drilling down into each movement or landing style individually, but I don’t want this post to become a novel. We’ve seen the most blue showing up for the kong, in both precision and running landings. Let’s take a closer look at that.

Here, I’ve plotted the average resultant force in red for each participant (1-10) performing a kong with a running landing, and also included in blue the actual values recorded for each of the 3 reps they performed, similar to the previous plots. I’ve also added back in the peak resultant force magnitude and angle in text annotation:

I’d say a good 7 out of the 10 participants were actually quite consistent in their execution here. Shout out to number 9 in particular; you can barely even see the blue arrows for each rep, they’re so tightly grouped. Nice.

Notably the participants with the more variable results also produced a more posteriorly (backward) title arrow; that is, close to or less than 90°. They still had individual reps beyond 90°, but the average was pulled backwards.

How does this compare to a kong with a precision landing?

Everyone is a lot more consistent here, and all the angles are at or below 90°.

This is all very interesting, but it’s starting to lead to the question - if the peak magnitude for a resultant force with a running landing happens during propulsion, what is the actual peak magnitude for the landing part of a running landing?

For that, we need a way to separate out the landing part of the movement from the, well, running part. That’s difficult to do with peak values. We could try and delineate parts of the movement based on time but, well, it gets tricky standardising individual movements to the same timeline (some people land quickly, some people take longer). Luckily we’re not after hard statistical number-science here; there’s a nice visual way to look at these things.

Force profiles

With the force platform data I collected, it’s possible to plot the actual millisecond-by-millisecond changes in horizontal and vertical force readings as x and y components, and then connect them up to form a path of resultant forces throughout a movement. The plots get a little messy, as you’ll see, but it summarises the directions and magnitudes of forces acting on the body (in the vertical and horizontal axes, as least) quite nicely. Here is an example plot for one participant, with one rep. We’ve been looking at kongs with running landings, so let’s also stick with that:

It gets a little muddy due to the sheer number of data points, but I’ve tried marking little blue arrows to indicate the direction the forces are moving in throughout the movement. Each arrow occurs at 1 millisecond, so the more spread out the arrows are, the quicker the force is changing.

You can see that the force first spikes hard to the right (so, backwards) at the start, when the foot first makes contact with the floor and braking begins. It then loops back round and down, before moving to the left (or forwards) and back up as the participant weight shifts over the midfoot and the propulsion phase of the running landing begins. This is where peak resultant force occurs - at the highest point on the plot, which you can see is to the left of 0 on the x axis and therefore in the propulsive phase.

This lets us try and answer our question from before; in this one example, the peak landing resultant force (that first spike to the right) appears to be less than the absolute peak resultant force (that second spike on the left), albeit not by a lot. This is just one rep by one participant though; what if we widen things back out to the whole study?

Again it’s little tricky to show fine detail in these plots due to the density of data and zoomed out perspective, but scanning your eye over the results here gives a sense of what we’d started to suspect. For precision landings, there is nearly always that general tilt to the right that indicates most of the GRFs are occurring with a posterior orientation. And, tellingly, that sharp spike to the right on first landing appears to also be where the peak force magnitude occurs, with most of the rest of the movement not surpassing it, or at least not by much.

However, in running landings, that landing spike often isn’t the largest force seen, sometimes only by a bit, but sometimes by quite a large margin. Look at the running landing for participant 6; the landing spike is not even much above 1 x bodyweight, but the peak force occuring towards the left is way up at over 4 x bodyweight!

So what have we learned?

A couple of general observations can be made in all this:

peak resultant force magnitudes increase in running style landings
they also tend to be more anteriorly orientated at the time of peak magnitude

Since peak force, regardless of when it occurs during execution of a landing / movement, is a key measure of stress on the body, looking at peak resultant forces in general remains interesting and, I believe, relevant. But, mapping them out visually in the way I’ve done here raises some questions:

does the peak resultant force in a running style landing occur as a result of absorbing the landing, or from pushing back off the ground to accelerate and continue moving?
does this matter? Is it worth isolating the phases of a running landing when comparing to other landing styles? Or should we be including propulsive phases when investigating other landing styles, such as a precision landing into a plyometric jump?

This could be something fairly unique to parkour; I struggle to think of another physical activity or sport besides dance that could involve landing from some significant height on one leg before continuing into a run. I plan to continue my research into the biomechanics of parkour; I’m doing a Masters by Research next year in fact. So who knows. Maybe all this poking and prodding of old data will lead to something amazing in a full investigation.

Dissertation summary slides

Wed, 29 Jul 2020 00:00:00 +0000

If you don’t have the time, energy, or stomach to read all 6000+ words of my full dissertation (and frankly, who can blame you), I’ve put up some short summary slides:

⚡ View summary slides

These were written in Remark and so should work in the browser, even on mobile. Just click or swipe through.

A facsimile of an electrotherapy machine

Sun, 26 Jul 2020 00:00:00 +0000

Around the beginning of March was a strange time at university. The Covid-19 pandemic was rumbling in the distance, but it wasn’t quite real yet. Posters about washing your hands started cropping up in the uni bathrooms. Emergency plans were being discussed, but they weren’t really believed to be necessary. Everyone expected things to carry on as normal.

We all left on Friday 6th of March for reading week, and never went back.

Things became very real very quickly that week, and the university (wisely) took the initiative and closed campus, before even the offical country wide lockdown was announced. Lectures moved online, and as lockdown increasingly stretched out in front of us all, it became clear that assessments would need to move online too.

We were lucky, mostly, on the Sports Therapy course, as many of our remaining assessments could move online without much disruption. You can submit dissertations online, you can have viva exams over video calls. We didn’t have any formal written exams left, the kind that usually require you to sit in an exam hall to make sure you’re not just googling each question as you get to it.

Unfortunately, one practical exam remained, for electrotherapy (the delivery of ultrasound, interferential, or similar treatments). These treatments require a therapist to correctly setup a machine to deliver the appropriate desired effect (intensity, duration, tissue depth, things like that). The viva component of the exam - explaining why you’re doing what you’re doing for a given injury - could be done on video. The actual physical delivery is not complicated enough to require much assessment, it’s just applying some pads or moving an ultrasound head around the area (besides, our clinical skills for things like ensuring patient comfort, had already been assessed in a manual therapy exam).

But how do you test the ability of a student to correctly setup a machine to deliver a chosen modality if they’re not standing in front of it? The best we could do was pretend, and just talk through the settings we’d pick as if we had a machine in front of us.

Listening to my lecturer talk about the exam, it occurred to me that really all that was taking place was a series of menu selections. The exam isn’t testing if you can correctly press buttons on a machine - it’s testing that you can pick the right option from a given selection, for all the variables you might change when delivering an electrotherapy treatment. Talking this through without a machine in front of me was going to be brain-bending. So I needed a way to revise this stuff, and I couldn’t just go into a treatment room and start fiddling with a machine the way I normally would. Could I build the menu system for the machine for myself as a revision aid?

‘App’ is a bit of a grand term

Having played with adapting someone else’s JavaScript for the PoseNet app I built for my business module assessment, I was starting to get a grip on how JavaScript can be used to build interactivity into a website (in very basic terms). I didn’t have a lot of time to learn something advanced for web app development (my wife is a software engineer and I’ve often looked over her shoulder at the React based things she’s building and felt like she was essentially performing arcane rituals to tame futuristic cyber gods). What did I know already that could get this job done?

I present: an electrotherapy ‘machine’ built entirely out of showing and hiding CSS modal boxes when the user clicks various buttons.

Sorry, your browser does not support the video tag.

You can view the code here. It’s nothing special; I was getting better but was still rusty with my basic HTML/CSS, and JavaScript was still a new foreign land I was exploring. But it got the job done.

The hardest part was actually figuring out what the menu options should be. I’d had a go on the electrotherapy machines at uni, but not enough to memorise every part of their menu layout. There were revision videos on our student portal, but the video quality was so low that I couldn’t make out any of the text on the machine screens. I had to learn the parameters for electrotherapy treatment really well, and then use educated guesses to determine what they are probably selecting at each point in the video based on the treatment they were demonstrating, in order to figure out what menu item should occur in what order on the screen. I also found the PDF manual online for the specific model of electrotherapy machine we use, but even that left gaps I had to fill in with detective work.

All this turned out to be fantastic revision. Building a thing really is the best way to learn how that thing works! As a result, by the time I felt happy with the finished product, I didn’t even need to use it anymore.

And then I thought - could an emulation like this stand in for the real thing in the exam? Screensharing could allow a student to select variables in the app while the examiner watched, exactly as they would when standing in front of a physical machine. Would the university accept that? Feeling bold, I emailed it off to my lecturer.

About a month later, it was used in the electrotherapy assessment for everyone on my course.

I’m very proud of this small part I played in helping life carry on during an incredibly turbulent, Covid-19 flavoured time. And I’m pretty sure I’ve build the only online emulation of an electrotherapy machine menu that exists on the internet (let me know if I’m wrong please). Talk about niche. It’s still there, on Github, incidentally. If you’re a sports therapy student looking for a revision aid for electrotherapy, you can try it for yourself by clicking here.

Hope it helps.

SquatCam: Real-time Joint Feedback with PoseNet

Sat, 25 Jul 2020 00:00:00 +0000

Update: Since first writing this post, I’ve actually updated the web app in question to look a little nicer and even work on smaller screens, so the video demo in this post won’t match what you’ll see if you follow the links to try it yourself. The basic code running everything remains the same though.

So a while ago, I stumbled onto this post on the TensorFlow blog, talking about the release of a JavaScript version of the PoseNet machine learning model for real time human pose estimation that can run in a browser using a webcam. I noted it at the time as we were learning about motion capture in Biomechanics during my undergrad Sports Therapy course, and I was curious if this could be used as a form of markerless motion tracking, so I stored it away in the back of my mind.

Somewhat later, in third year, we had to take a Business Studies module. The one and only assessment for this module involved creating a business pitch for a new business of our choosing, but ideally related to our field of study. We were encouraged by our lecturer to add some ‘wow factor’ to the pitch by including something like a video or, even better, a live demonstration of our product.

The idea struck me to go back to PoseNet and create a business around delivering in-browser biomechanical analysis of movements, that sports therapists could use to assess patients remotely. All the patient would need to do is point their webcam at themselves while moving and the therapist could get a report on joint or segment angles to assess ranges of motion! I knew if I could get a demo of this working the way I wanted, it would definitely provide that ‘wow’ my lecturer was after.

One small problem - I’d never really done anything in JavaScript, never mind with machine learning. Hell, at that point I was still rusty with my HTML/CSS alone, having not done anything web related for half my life.

Fortunately for me, I’d also recently stumbled on to the Coding Train YouTube channel (seriously, the amount of stumbling onto exactly the thing I need on the web is kind of bizarre). Coding Train had recently uploaded some videos on ‘friendly’ machine learning models using something called ml5, including this one on Posenet that gave me exactly the base I needed to start. In fact, the example code for PoseNet with a webcam using ml5.js and p5.js is nearly entirely intact in my final code - I just built a couple things on top of it. I can heartily recommend both Coding Train and ml5 for anyone looking to start playing with some really interesting machine learning models!

I didn’t have time to build much, so I focused on one movement - the squat - and built a simple single page app that takes the pose info from PoseNet and adds a couple extra bits of maths to present some common biomechanical markers, before logging them to a little dashboard. Here’s an example video:

Sorry, your browser does not support the video tag.

Please excuse my general shabby state in the video - I was in full Covid-19 lockdown mode at the point this was recorded.

The PoseNet and skeleton-drawing (the white lines and dots overlaying the video) code was already there from ml5, so now I had to figure out how to get the joint and segment angles. I had the x and y coordinates of each white dot representing a joint, so I figured there must be a way to translate this into angles.

I’m no great mathematician, so a little google-fu found me this StackOverflow answer that gave me what I needed. I’d used atan2 in R for calculating resultant forces when I was resultant forces, so I was familiar with how it worked, and a little extra calculation allows you to translate the points in such a way that the ‘joint’ in our case becomes the equivalent of 0, 0 in a coordinate system. Here’s an example of this applied to knee flexion, where poses[0]... is the data coming from PoseNet:

knee = poses[0].pose.leftKnee;
hip = poses[0].pose.leftHip;
ankle = poses[0].pose.leftAnkle;

kneeFlexion = (
  Math.atan2(
    ankle.y - knee.y,
    ankle.x - knee.x
  )
  - Math.atan2(
    hip.y - knee.y,
    hip.x - knee.x
  )
) * (180 / Math.PI);

One interesting conundrum was calculating shin and trunk angle, given that these needed to be calculated from a fixed external point (an absolute angle in biomechanics terms) - ideally the floor or a wall. And, I still needed those three points to work with atan2 as in the example above. I ended up creating an imaginary third point, using a combination of the x coordinate from the most superior joint (shoulder for trunk, knee for shin) and the y coordinate from the inferior joint (hip, ankle) to project a third point out into space that moved along with these joints and created a nice right angle triangle. I could then, essentially, use the sides of this triangle as the external reference for these angles.

Here’s an example illustration for trunk lean:

And the code:

hip = poses[0].pose.leftHip;
shoulder = poses[0].pose.leftShoulder;
imaginaryPoint = { x: shoulder.x, y: hip.y };

trunkLean = 360 - (
  Math.atan2(
    imaginaryPoint.y - hip.y,
    imaginaryPoint.x - hip.x
  ) - Math.atan2(
    shoulder.y - hip.y,
    shoulder.x - hip.x)
) * (180 / Math.PI);

It’s not a perfect system, but it’s acceptable enough!

From there, it was just a case of logging the number reached to a variable and outputting that to the HTML, updating it only if that variable is exceeded - logging the maximum knee flexion achieved, for example. Just to be fancy, I threw in a button to switch sides (which just means changing poses[0].pose.leftKnee to poses[0].pose.rightKnee) and a button to snapshot the current video output and download it (using p5 saveCanvas).

For a first time adventure in JavaScript, this was probably jumping in at the deep end, but I’m pleased with the outcome (and it must have achieved that wow factor I was after, as I got a pretty great mark on the assessment). You can view the (probably quite ugly) code on GitHub and even try it for yourself here.

Once again, check out ml5 and Coding Train for more machine learning model goodness!

Common parkour vault techniques, landing styles, and their effects on landing forces

Thu, 16 Jul 2020 00:00:00 +0000

This project was my final year dissertation for my Sport Therapy BSc undergraduate degree, the abstract of which was accepted at the BASES Conference 2021 and presented as a poster where it won the Human Kinetics Student Poster Presentation Award. This abstract was then also published in a special edition of the Journal of Sports Sciences.

Read Online

📔 Read online in full

📄 Download PDF

Bonus Materials

🗒 Abstract in the Journal of Sports Sciences (search for the reference code D2.S3 on that page to find it!)

🗞 BASES 2021 Conference Poster

⚡ View summary slides

Disclaimer

It’s important to know that this has not been extensively peer reviewed beyond the abstract for the BASES Conference. I’m proud of my work and I think my findings are, at the very least, interesting. But, please bear that in mind as you read it.

Data

You can also download the full force platform data I collected if you would like to perform your own analysis. If you do so, please get in touch and let me know what you use it for and what you find, I’d be delighted.

⬇ Download from Figshare | ⬇ Download from Github repo

Abstract

The emerging sport of parkour has developed a landing technique focused on soft, quiet and controlled landings. The proficiency of practitioners (traceurs) for two-legged drop landing tasks is becoming increasingly established, but it is unknown whether the same aptitude will be demonstrated for different movements and with different landing techniques. This study will investigate the ground reaction forces (GRFs) produced during three common parkour vaulting techniques utilising two common landing styles, with the aim of understanding how GRFs may change between the different scenarios and the subsequent implications for injury risk. 10 traceurs (age 29.4 ± 7.2 years, height 173.8 ± 8.1 cm, weight 74.2 ± 8.4 kg, experience 9.7 ± 3.6 years) performed a drop landing, step vault, dash vault, and kong vault onto a force plate with a two-legged precision landing (precision) and a single-legged running landing (running). Peak vertical (vGRF) and braking (bGRF) GRFs per limb were analysed by repeated-measures two-way ANOVA. A significant interaction effect between movement choice and landing style was found for both peak vGRF (p = 0.007) and peak bGRF (p < 0.001). All movements increased in vGRF when using a running landing, but only the drop and kong vault increased in bGRF while the step and dash vaults decreased in bGRF. The kong vault resulted in the greatest peak vGRFs and bGRFs, differing significantly from all other movements with a precision landing and, even in comparisons that did not achieve significance, always producing at least a medium to large effect size. The dash vault produced the least peak vGRF and bGRF of all movements in both landing styles, differing significantly from all others in bGRF and the drop and kong vault in vGRF. Movement and landing style choice affect landing GRFs for common parkour vaulting techniques. While GRFs increased in running style landings, they still did not exceed those typically experienced in jogging, indicating that traceurs mimic their performance in two-legged drop landings and continue to effectively mitigate GRFs when vaulting. As a result traceurs are unlikely to be at risk of acute lower limb injury when vaulting, but may remain at risk of chronic lower limb injury.

Astronaut Mission Length: Longest v Average

Tue, 14 Jul 2020 00:00:00 +0000

(Tidy Tuesday is a project to supply weekly data sets for R users to practice their coding skills on. You can find full details here.)

This week’s Tidy Tuesday dataset “contains publicly available information about all astronauts who participated in space missions before 15 January 2020 collected from NASA, Roscosmos, and fun-made websites.”

Without a clear immediate question jumping out at me, I played around with the dataset a bunch to see what random variables I could make it spit out. I ended up with an average mission length for astronauts that flew more than one mission. Since I hadn’t really had a chance to play with creating a dumbbell plot before, I gave it a go.

It came out quite nicely as a visual, but the thing I really love about this plot is how utterly useless this information really is. I mean, it answers the question, but so what? I can’t think of a situation where knowing this going to be particularly useful in solving a problem. Perfect!

I used reorder_within from tidytext to order the astronaut names by longest mission within each facet of mission number. It’s one of the most useful functions for plotting I know, kinda hidden away in a package that I never use anything else from. I did hit a small glitch where you need to also use reorder_within on xend in geom_segment for the lines of the dumbbells to line up properly. That took a minute to figure out.

Also a fun bit of use of ggtext to put colour into the plot title, as it was much easier than trying to figure out how to put in a legend for the dumbbell ends. And a shout out to Regex101 for helping me put together the str_replace_all to abbreviate all the astronaut names.

Code:

library(tidyverse)
library(tidytuesdayR)
library(here)
library(tidytext)
library(ggthemr)
library(cowplot)
library(ggtext)
library(glue)

ggthemr("flat dark", type = "outer")

data <- tt_load(2020, week=29)$astronauts

avgs <- data %>%
  group_by(name) %>%
  summarise(across(hours_mission, mean, .names = "mean_{col}"),
            longest_mission = round(max(hours_mission)/24, 2),
            no_mission = unique(total_number_of_missions),
            total_hrs = unique(total_hrs_sum)) %>%
  mutate(avg_days_per_mission = round(mean_hours_mission / 24, 2),
         total_days = round(total_hrs / 24, 2)) %>%
  arrange(desc(avg_days_per_mission)) %>%
  select(-mean_hours_mission, -total_hrs) %>%
  filter(no_mission > 1) %>%
  group_by(no_mission) %>%
  slice_max(longest_mission, n=10) %>%
  ungroup()
  
plot <- avgs %>%
  mutate(no_mission = glue::glue("{no_mission} Missions"),
         name = str_replace_all(name,
                                "(\\w+), (.)[a-zA-Z]+($|( .).($|(, Jr)))",
                                "\\1, \\2.\\3"),
         name = str_replace(name,
                            "Yuri Vladimirovich Usachyov",
                            "Yuri, V. U.")) %>%
  ggplot(aes(x = reorder_within(name,
                                longest_mission,
                                no_mission))) +
  geom_segment(aes(xend = reorder_within(name,
                                         longest_mission,
                                         no_mission),
                   y = avg_days_per_mission,
                   yend = longest_mission),
               color = "white") +
  geom_point(aes(y = longest_mission),
             color = swatch()[4],
             size = 2) +
  geom_point(aes(y = avg_days_per_mission),
             color = swatch()[3],
             size = 2) +
  scale_x_reordered() +
  coord_flip() +
  facet_wrap(vars(no_mission), ncol = 2, scales = "free_y") +
  labs(x = "",
       y = "Mission Length (Days)",
       title = glue("How much longer than <span style='color:{swatch()[3]};'>average</span> was their <span style='color:{swatch()[4]};'>longest</span> mission?"),
       subtitle = "For the 10 longest missions by astronauts that flew more than one mission") + 
  theme(plot.title.position = "plot",
        plot.title = element_markdown(),
        strip.text = element_text(face = "bold"),
        axis.title.x = element_text(face = "bold"))
        
ggdraw(plot) +
  draw_image(here("astronauts", "rocket.png"),
             scale = 0.06, x = .25, y = .45)

Which X-Men character had it worst?

Wed, 08 Jul 2020 00:00:00 +0000

(Tidy Tuesday is a project to supply weekly data sets for R users to practice their coding skills on. You can find full details here.)

A little late, but I decided to have a go at Tidy Tuesday with the recent Claremont Run dataset, looking at Chris Claremont’s 16 year run writing for the Uncanny X-men comic.

Looking at the characters dataset provided, that describe some of the events that occur to each character in an issue, it seemed like being an X-Person was a pretty rough gig. I wondered, who got dealt the harshest hand during the entire Claremont run?

Poor Storm.

This also gave me a chance to (very slightly) play with the new across (docs) function in the latest dplyr release. I’ve seen a few blog posts from excited R users around singing it’s praises, so it was good to at least touch it, even if I clearly haven’t made the most of it here.

I also played with adorn_totals from the Janitor package for the first time, as well as adding an image to a plot with Cowplot’s draw_image. Random new functions - always my favourite thing about working with R.

Code:

library(tidyverse)
library(janitor)
library(tidytuesdayR)
library(ggthemr)
library(cowplot)
library(here)

# set theme with ggthemr
ggthemr('fresh')

# import tidy tuesday data
data <- tt_load(2020, week=27)
characters <- data$characters

# summarise total instances the state occurred on each character across run
char_states_totals <- characters %>%
  select(-issue) %>%
  group_by(character) %>%
  summarise(across(is.numeric, sum)) %>%
  ungroup() %>%
  select(1:4, 6, 8) %>%
  janitor::adorn_totals("col", name = "total") %>%
  janitor::untabyl() %>%
  slice_max(total, n = 10) %>%
  select(character, total, everything()) %>%
  pivot_longer(3:7, names_to="state", values_to = "count") %>%
  separate(character, sep = " = ", into = c("codename", "name")) %>%
  mutate(codename = case_when(codename == "Ariel/Sprite/Shadowcat" ~ "Shadowcat",
                              codename == "Marvel Girl/Phoenix" ~ "Jean Grey",
                              TRUE ~ codename))

# create stacked column plot
plot <- char_states_totals %>%
  mutate(state = str_replace_all(state, "_", " "),
         state = str_replace_all(state, "subject", "subjected"),
         state = str_to_sentence(state)) %>%
  mutate(state = fct_reorder(state, count),
         codename = fct_reorder(codename, total)) %>%
  ggplot(aes(codename, count, fill = state)) +
  geom_col() + 
  coord_flip() +
  labs(title = "Which X-Men character had it worst?",
       subtitle = "During Chris Claremont's 1975-1991 run on Uncanny X-Men",
       x = "",
       y = "No. of Occurrences",
       fill = "")

# add storm image to plot
cowplot::ggdraw(plot) +
  cowplot::draw_image(here("xmen", "storm.jpg"), scale = .3, x = .37, y = .3)

Differences In Postural Trunk Lean When Implementing A Decline Squat Protocol

Wed, 15 Apr 2020 00:00:00 +0000

This research was done as part of our final year biomechanics module. We explored the hypothesis that squatting on a 20° angle decline ramp will result in a more upright trunk at the bottom of the squat, potentially reducing the risk of lumbar spine injury during squatting when ankle dorsiflexion range is limited.

The abstract for this research was selected for poster presentation at the BASES Student Conference 2020, but unfortunately due to Covid-19 the conference was cancelled, so my colleagues and I decided to present it online.

View Online

🗞 Student Conference Poster

Meteorite Falls and Finds in the UK

Mon, 17 Jun 2019 00:00:00 +0000

(Tidy Tuesday is a project to supply weekly data sets for R users to practice their coding skills on. You can find full details here.)

The Tidy Tuesday dataset for this week, compiling meteorite strikes across the world, grabbed my interest so I decided to finally dive in and give it a go. I ended up looking at strikes in the UK, noted by mass.

I exported the original code image as a PDF and then applied some effects in Affinity Photo to give it an old, weathered look. This was my first time experimenting with something like this, so it’s a little sketchy, but I enjoyed seeing how I could pull a plot apart in Photo to apply image effects (although sorry, this does mean the code for this plot doesn’t get you all the way to the finished produced).

Code:

library(tidyverse)
library(maps)

meteorites <- readr::read_csv("https://raw.githubusercontent.com/rfordatascience/tidytuesday/master/data/2019/2019-06-11/meteorites.csv")

ukFalls <- meteorites %>% 
  filter(lat >= 50 & lat <= 60 & long <= 2 & long >= -11) %>% 
  filter(!name %in% c("Limerick", "Dundrum", "Mooresfort", "Leighlinbridge", "Pettiswood")) %>%
  mutate(massKG = mass/1000) %>% 
  mutate(nameYear = paste(name, year, sep = ", ")) %>% 
  arrange(year)

ukMap <- map_data(regions = "uk", map = "world") %>% filter(lat <=58.73)

ggplot(ukMap, aes(x = long, y = lat)) + 
  geom_polygon(aes(group = group), colour = "black", fill = "#222831") +
  geom_point(data = ukFalls, aes(x = long, y = lat, size = massKG), colour = "#d65a31") +
  geom_text(data = subset(ukFalls, massKG >=10), aes(label = nameYear), hjust = 0, nudge_x = 0.2, size = 3) +
  scale_size(range = c(0, 5), breaks = c(5,15,25,50), labels = c("5 kg", "15 kg", "25 kg", "50 kg")) +
  theme_void() +
  theme(plot.background = element_rect(fill = "#5588a3"),
        plot.margin = margin(.5, .5, .5, .5, "cm")) +
  labs(size = "Mass",
       alpha = "Mass")

ggsave("map.pdf")

Climber's Brain

Sun, 26 Aug 2018 00:00:00 +0000

I’ve been enjoying doing some (indoor) climbing recently. It tickles the same problem solving/figuring out a challenge part of my brain that parkour satisfies. I enjoyed this article on the strange brain of Alex Honnold, one of the current greats of climbing:

The Strange Brain of the World’s Greatest Solo Climber

One of the things I found really interesting is the way he seems to have just gotten used to fear through exposure. This is something that, again, I find in common between climbing and parkour. The more you expose yourself to situations that you find scary, the better you are at dealing with them. The fun part is that it spreads to situations that you haven’t exactly encountered before, but are just similar enough that your brain can deal with them in the same way. A broad experience of different situations can set you up to deal with fear in many different ways.

'Find Your Passion' Is Awful Advice

Sat, 25 Aug 2018 00:00:00 +0000

I found this article pretty interesting. The idea of developing your passion, rather than waiting for it to strike you like a lightning strike, rung very true to me. I didn’t take up a sport until I was 22 and never thought I’d pursue a career in it until years later. Now I’m at university studying it at 31. If I’d gone to uni straight from school, I’d probably have done something IT related - never in a million years would I have chosen sport therapy.

Check out the full article here.

The Benefits of Using a Half-Kneeling Position

Sat, 11 Aug 2018 00:00:00 +0000

Exploring working from different or weird positions has been something I’ve been enjoying lately. I do a lot of my mobility these days from a full kneeling sit position, for example. As such, I found this article from Juggernaut Strength to be a great read.

I switched to split squats a while back over regular squatting because, frankly, I was sick to death of the issues squatting was giving me with my back. Plus, a half kneel/lunge position is the starting point for a lot of explosive movements in sport. I’ve definitely seen benefits from the stability challenges to the trunk that the position provides, like the article talks about, and I plan to use it for some overhead work too in the future.

I think my interest here was inspired by the climbing I’ve been doing recently, where you often have to apply strength in unusual angles, but also from a general need to keep switching things up to maintain interest. Keeping the general movement the same - say, an overhead press - but varying it each week with little things like performing from a half-kneel helps avoid monotony. That’s the secret if just grinding reps out just doesn’t appeal to you!

Tricking Myself Into Doing Cardio

Sat, 23 Jun 2018 00:00:00 +0000

As I’ve mentioned before, I’m not a huge fan of cardio - I don’t really have the attention span for it. I get super bored with long slow distance. I have to find ways to make it interesting, and the best way I’ve found is to try and make it about learning some new skill.

To that end, I’ve been trying to learn to skip lately. Skipping is well known as great cardio - there’s a reason you see it in all the Rocky movies. I was surprised at how tricky it was to get going at first too, having not done it since my school days, which were longer ago than I care to admit. It also has the added bonus of having some variations and tricks you can throw in to try and learn.

When working on something like this, I tend not to worry about strict time or rep counts. Instead, I just set a timer for a general amount of time - 10-20 minutes usually - and just work on the skill during that time. I’ll still finish with a sweat, but because I’m focused more on learning and improving the skill than just counting down the minutes, I don’t get bored.

This video helped me get a bit of the timing down for learning the ‘jogging’ style skip. I apologise for the dude-bro vibe in the video, but the information is good, and you can check out their entire Youtube channel for more if you’re into it.

New Gym Syndrome

Fri, 15 Jun 2018 00:00:00 +0000

There’s a unique type of fear about a new gym. It comes storming up out of your gut and can lay low even the toughest of gym-bros; all stemming from one simple, unknowable fear.

What if they do something different, that I don’t know about, and I look like an idiot for not knowing it?

Gyms can be weird places. They can build cultures and subcultures within them that intimidate and exclude just as much as they can elevate and inspire. Cliques and traditions and expectations can all combine into one big melting pot that, if you’re familiar with it, can be as welcoming as your own home. But if you’re not familiar, they can feel obscure, bording on unfriendly.

As an example, I recently went to a new gym for the first time and found the single door into the building to be locked. It had one of those keypad things on it, but I couldn’t see anything indicating how I was meant to know the code to get in. I double checked their website; no luck. There weren’t windows so I could wave to someone and look gormless until they took pity on me. Eventually I bit the bullet and just knocked on the door. After a few minutes, a grumpy looking guy who was clearly mid-workout opened it.

He was silent as I stepped inside and started to head back to his squat rack immediately. Not knowing what was going on, I asked him if I’d used the right door. “Yeah,” he scowled, “and the code for it is right there.”

The code was inside the gym. What? Why? How was I supposed to know?!

Now fortunately I’m an experienced gym-goer and don’t particularly mind making a nuisance of myself. If a complete stranger wants to be grumpy at me, so be it, but I couldn’t help thinking about how this would have all felt if I’d been brand new to training. I know for sure a few years ago I might not have even had the nerve to knock on an imposing door, and if the first person I’d met inside had scowled at me it would have sent me running to the hills. That’s a shame, as getting into training is hard enough without encountering these social or emotional barriers to entry.

What can you do to avoid this kind of thing? Best thing to do is find a training partner to go with. If they’ve been to the gym before then they guide you, but even if you’re both brand new you’re far less likely to feel awkward if it’s two of you getting something wrong.

If you can’t find a partner, see if you can book an induction or 1-on-1 session before you get stuck in. Having a staff member show you around really helps - takes notes and don’t be embarrassed to ask hundreds of questions; everything from etiquette to how the lockers work. It’ll come up, trust me, so find out.

Finally, I’d advise anyone to just hit the ‘screw it’ button occasionally. You’re there to improve yourself and anyone who wants to judge you for minor mistakes is not someone to waste time on. Take it from someone who has fallen arse over head doing handstands in front of an entire row of packed treadmills more than once. Laugh it off and try again.

Eventually you’ll get comfortable in a space and it will become ‘your’ gym. That’s a pretty special feeling and worth persevering for. And hey, when you reach that place and have to open the door for some schmuck who can’t find the code?

Maybe give them a quick smile on the way in.

Weber's Law and Weightlifting

Sat, 02 Jun 2018 00:00:00 +0000

Short one today, but I found this video really interesting:

I love a bit of Numberphile and if you remotely enjoyed this one you should check out every other video on the channel.

Anyway what I found interesting is that you can feel this very principle when weight lifting. It’s harder to jump from 10kg to 15kg in an exercise than it is to jump from 100kg to 105kg. It’s something intrinsic we kind of just ‘know’ in the gym, but you can see the theory behind it here.

Another point to take away from this is that you never entirely know when information is going to apply to your field of interest. Maths and physics may not seem connected to sport and exercise on the surface, but the entire field of biomechanics is based on it, so keep your eyes open for inspiration everywhere.

Your Burpees Suck

Sat, 12 May 2018 00:00:00 +0000

I’m not sure where this habit of clapping just behind your head while jumping two inches off the ground during a burpee came from, but I hate it. cough I’m not saying you’re not still breathing hard by the end, but I suspect it’s just to chase numbers, to be able to do more for the sake of doing more. I like to use burpees as a very explosive full body movement, high speed and high power, and that includes the jump. I don’t necessarily think you should be able to do a hundred of them in a row.

Anyway, here’s a video of some better ones, and some other advanced variations. Do them like this. Fewer, harder, in sets. And jump higher.

Credit to Juan Lugo Fitness for the video.

The Last Conversation You'll Ever Need To Have About Eating Right

Sun, 06 May 2018 00:00:00 +0000

A great read on the common questions of healthy eating, without faff or any mention of Gwyneth Paltrow. The bit I like is right at the start; honestly, most people already know what is and isn’t healthy, but instead we’re all looking for shortcuts and super powers.

Unfortunately I can’t remember where it was, but I read about a study that found the most common indicator of ‘healthy’ eating was whether or not you make your own food. Regular home cooking from whole ingredients led to healthier eating. Essentially the less steps there are between your food going ‘moo’ in a field and reaching your kitchen, the better.

Enjoy: The Last Conversation You’ll Ever Need To Have About Eating Right

5 Minutes, Ratios, and Intensity

Sat, 28 Apr 2018 00:00:00 +0000

I’ve been struggling a little lately with cardio. I’ve never particularly enjoyed it, but fortunately the sport I do enjoy - parkour - has cardio kind of ‘baked in’. By doing parkour, you’ll work cardio, without really having it be the focus. You won’t be as good as someone who runs, sprints, cycles, etc, as their actual focused training method, but you will at least be able to go up a flight of stairs without throwing up. And hey, I’m not trying to run any marathons, so a basic level of cardio fitness is fine. I want to be able to sprint for a bus when I need to, maybe knock out a slow but steady 5k on occasion, and keep a fairly healthy heart, and that’s about it.

The trouble has come now that I’m not really doing parkour that much anymore. Not for any particular reason - it’s just been difficult to find a place for it in my life right now. It happens - you move house, start a new job, or in my case, up-end your entire life to start again by going to university at 31. I’ve still been training, but it’s been in the gym at uni, which isn’t exactly bleeding edge in terms of equipment or massively blessed with space, so my training has been in turn limited.

So I’ve been getting in my calisthenics - levers, muscle ups - and some basic weight lifting. But, well, I’m not a lover of static cardio machines - treadmills, bikes, rowers. And those are kind of my options in this gym. I could go outside and run once I get home, but ideally I want to wrap my training all up in one session so I can get on with my day. And, considering that I don’t enjoy it anyway, having to psyche myself up to train again at some other time is setting myself up for failure.

All this is a long way of explaining that I tried the video below and it fucked me right up:

Athlean-X is a great Youtube channel to check out. I think it’s focus is not exactly in line with my own, but I’ve yet to see anything on there that I consider bad information. They’ve got a few of these short, blast-it-out workouts videos. Perfect, I thought. Tack one of these on at the end of a normal gym workout and I’ll get a little cardio hit to just top me up.

And hey, I’m not really doing anything right now, why not test it out? What’s five minutes going to do?

Well that was an hour ago and I’m still feeling queasy. That’s not the fault of the video - I went HAM at this, not really taking into account that I had been slacking on cardio lately. But it does go to show how effective such an approach is - you’re only going for five minutes, so make it a hard five minutes. Pick an intensity that works for the workout your doing. A common complaint I hear is not having enough time in a day to train, but that’s only really true if you approach a five minute workout as if it was a half hour workout. Resting between sets for 30 to 60 seconds will render a five minute workout useless, sure - but it’s five minutes! Rest for 5 to 10 seconds instead and you’ll quickly feel the same level of intensity.

Think of work to rest instead as a ratio. Example - say you set a work:rest ratio of 2:1. You work in some capacity for 2, and rest for 1. So in a 45 minute running session, that’s:

30 minutes of running
15 minutes of rest

That could be:

10 minutes run
5 minutes rest
repeated three times

Five minute is a nice long time to recover in! The exact same ratio of 2:1 in a five minute workout would give you - well, the maths is a bit imprecise (alright, technically, the following is a ratio of 2:0.87, nerds), but let’s pretend it’s:

3 minutes 30 seconds work
1 minute 30 seconds rest

Split it up into three sets again and that’s only 30 seconds of rest at a time - a much higher intensity workout! So, adjust your workout so that intensity scales to your time limit, and you can squeeze a lot more out of a lot less time. As for myself, I’ll be repeating the video workout linked above many more times - I’ve got buses to catch, after all.

All The Mobility Exercises You'll Ever Need

Fri, 20 Apr 2018 00:00:00 +0000

Mobility is such a big topic, and is kind of in vogue at the moment, so it can be hard to figure out the good from the bad when it comes to exercises and routines to follow. To help, the folks at Hero Academy have put together a massive list of 100+ mobility exercises, organised by body part.

All you need to do is click the body area you want to work on, and follow the links to find all the details you need from a variety of sources. If you see anything from Tom Merrick (Bodyweight Warrior), I can recommend it!

If you’re not sure what body part to pick, or if there are too many body parts you want to work on for the time you have, just think about what is causing you the most pain or discomfort right now. Just work on that, until it no longer bothers you, and then pick another area. Eventually you will (hopefully) clear all the troublesome areas and can just mobilise generally as you go. Enjoy!

A Day In The Park

Wed, 13 Apr 2016 00:00:00 +0000

Sometimes, you just want to get outside, and fall over.

Hanging Out

Thu, 31 Mar 2016 00:00:00 +0000

A day in the gym.

Block

Sun, 28 Feb 2016 00:00:00 +0000

Sometimes, things worry you for no reason.

jmablog

What was the best year for a saxophone lover to be listening to the Billboard Top 100?

Some Animated Joins

Inner join

Left join

Outer join

But how was Manim?

Can I use these?

Tinier 0.5.0

New things - petit_plot

How To Spot Bad Coaching Advice Online

Sports science and empirical evidence

Conventional wisdom

Spotting good advice

Parkour, Perpetual Challenge, and Burnout

Burnout and challenge

Identity

Cheer pressure

Talk

Quarto templates for lecturers and educators

Generating Pretty Instagram Quote Images in R

Using the Expertise of Parkour Coaches to Understand Parkour Movement: The Kong Vault

Read Online

Bonus Materials

Disclaimer

Data

Abstract

Mario Kart 64 World Records

The Problem with Using Youtube Clips for Posture Analysis

tinieR 0.4.1

New things

Useful things I learnt

Pandoc filters in Bookdown

Pandoc filters

Writing the filter

Example

Using with Bookdown/Rmarkdown

Edit: Another method

Scrivdown

Inspiration

Scrivener setup

R / Bookdown setup

Linking the two

Some complications

Post processing

Downsides

GNU Terry Pratchett with Netlify and Hugo

Netlify and Hugo

Bookdown, Not Bookout

Functionally building your book

Taking it further

Word / .docx output tweaks

Writing environment

Reproducibility

Wrapping up

How joyful were the Friends main characters?

Hugo Clinic Notes Theme

Hugo clinic notes theme

tinieR 0.3.0

Resizing

New return_path options

tinieR 0.1.0

A few bumps along the way

tinieR

Correlation Between Some Common Physiological Variables in Parkour Vaulting

Regression and correlation

Age

Training experience

Height

Weight

Vertical and horizontal GRF

Landing foot

Parkour Clinic Launches!

Parkour Clinic

Resultant Forces in Parkour Vaults

What is a landing (or ground reaction) force?

So what’s a resultant force here?

Why look at landing forces at all?

Calculating and plotting resultant forces

Finally, the point

New things - `petit_plot`