posts on TanHo.ca

Dry Aging At Home, Episode 1

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

One of my deep nerd obsessions is food, especially food science, and I’ve long wanted to try out dry-aging at home. The premise sounds “simple”: you just need a dedicated fridge, a big old hunk of meat, and a way to monitor the temperature and humidity inside. Pair that with some burgeoning homelab skills and … how hard could it be? Here are some reflections on my first dry-aging experiment, a 45-day boneless ribeye roast.

Code for this project lives on GitHub at tanho63/dry-age-monitor.

equipment and setup
#

I got a dedicated fridge from Costco - around 6.0 cubic feet with a glass door and wire shelving - and on balance I think it worked really well: it held humidity pretty decently, was able to fit a good sized chunk of meat on a shelf, and the glass door let me look in on it whenever I wanted. The one downside is that it uses a mechanical thermostat for deciding when to kick on the compressor, and I ended up needing to fiddle with it a bit (more on that later). A digital thermostat that let me control top-end and bottom-end temperature would probably be better, but honestly I’m very pleased with what I got for ~$350 CAD.

The Raspberry Pi monitoring setup worked great for tracking temperature and humidity. I’ve mostly had experience with the Pi Zero 2 WH (i.e. with headers already soldered on), so went with that and paired it with a BME690 air quality sensor that promised to monitor temperature, humidity, gas, and pressure. I could probably have cheaped out and gone with a simpler sensor like the AHT20, since the gas and pressure turned out to be pretty useless, but the BME690 worked well enough once I got it set up and calibrated.

I don’t have a soldering kit, so plugging everything in via Stemma/QT cables was the move and it was painless. I made sure to get a longer (400mm) cable for the sensor-to-hub connection so that I could put the sensor closer to the middle of the fridge, and then used a velcro cable tie to secure it to the desired fridge rack. I didn’t have any worries about the sensor breakout board being exposed to cold temperatures or potential humidity, since it is designed to read those, and the actual Pi is mounted outside of the fridge.

I used a spare computer case fan I already had, paired with this USB-powered fan controller. I initially tried a USB fan, but the cable was pretty thick and awkward to fit into the fridge’s door seal. The case fan’s cable was much thinner and easier to route, and the adjustable fan speed was pretty useful too. I didn’t end up needing to adjust it very often at all because I found that a higher fan speed messed with the temperature more than I wanted while not really changing the effective humidity much at all.

Sealing off the cable gaps in the door gasket was very helpful in maintaining temperature. I duct-taped the cables down first to make sure it stayed put, then put foam tape over top to help reduce air leakage.

I bought a cheap thermohygrometer as a backup in case the Pi ever went down. It worked fine as a sanity check but I’d want to invest in a better one if I was relying on it directly.

meat
#

I was a bit impulsive about buying the meat: I’d had the fridge for a while, but had been procrastinating actually starting on everything, so one day I was at Costco Business Centre and decided to just get a starter piece of meat for the sake of giving myself a kick in the pants.

The beef I ended up with for this first experiment was an ungraded, boneless ribeye roast weighing 14.2 lbs. Not a particularly great one either: the fat cap was thick, the meat wasn’t especially marbled, and the spinalis was thinner than I’d have liked. I mostly wanted to get a roast I wouldn’t be too upset about ruining if the experiment flopped.

I didn’t do a great job of documenting the “before” state: I forgot to log the total cost and size of the whole roast before trimming, so I can’t do a really good cost estimate, but I did remember to portion off a steak so I could have a before/after comparison tasting. I also trimmed it up so that it would fit horizontally on the shelf with some space for airflow around the sides.

My goal was to age this first roast for 45 days. I’ve had 30-day dry-aged steaks before, so with my home experimentation I really wanted to try going for a meaningful increase but not necessarily going all the way to 60 days (which the research suggests is potentially quite overpowering).

monitoring
#

I set up the Pi to record data (temp, humidity, pressure, gas) every 30 seconds, which gave me a pretty good representation of the fridge cycle, and I calculated the mean values for the whole up/down fridge cycle as well as the 5th, 20th, 80th, and 95th percentile values (avoiding outliers in case I opened the fridge momentarily).

I put together an R Markdown report to summarize the data, and set it up to knit via a cron job every 15 minutes on my main home server rather than on the Pi itself (which was too underpowered). I also chose to push the report to an S3 bucket page rather than continually committing it to GitHub like I might have in the past (lots of images being committed that often would lead to repository size growing indefinitely).

temperature
#

Temperature-wise, the internet says that dry-age temperatures should be between 34F and 38F, that meat freezes at about 30F, and that the danger zone from a food safety perspective starts at 40F. I decided to shoot for:

mean cycle temp between 36F and 38F
5th and 20th percentiles above 30F
95th percentile at or below 41F
80th percentile at or below 40F

These felt like reasonable goals because the meat itself shouldn’t actually reach over 41F - the sensor reacts to air temperature swings much faster than the meat’s surface does. I also wanted to avoid short-cycling the fridge compressor, which would reduce the lifespan of the fridge and also probably cost more money to run overall.

Unfortunately, my fridge’s cycle maxes and mins seemed to naturally range between 32F and 42F, even on the coldest fridge setting. While I was willing to risk a small portion (less than 20%) of the time being between 40F and 41F, I was worried that any more time than that, or any warmer a band, would be more likely to cause spoilage and “bad” bacteria growth.

I tried increasing fan speed, thinking that it would circulate cold air up faster. However, this didn’t really change the set-point of the fridge’s thermostat: the cooling happened faster since the cold air would circulate more quickly on the “down” part of the cycle, but the compressor didn’t kick on any earlier.

I ended up messing with the fridge’s thermostat sensor itself: this is basically a wire that sat in a little housing on the back of the fridge, so I took the housing off and bent the wire upwards to move the end of the sensor into a warmer spot of the fridge. This kicked the compressor on a little earlier (~41F) and also caused it to turn off a bit later (~28F), since it took longer for the “cold” to register on the sensor. That latter part was easy to fix: just turn the dial down!

I also wanted to try to lengthen the cycle to help the fridge run a little more efficiently, so I added some thermal mass in the form of 4L jugs of water - this helped slow the rate at which the fridge warmed between the compressor shutting off and kicking on again.

humidity
#

Humidity seemed to sit really high throughout the process, swinging from 50% to 100%+, according to the BME690 sensor. This led to some worries about condensation forming on either the meat or on the walls of the fridge (and eventually ice). My research suggested that the meat would give off moisture for at least 2-3 weeks, so I just added a quarter sheet pan of kosher salt hoping that it would resolve itself eventually.

This didn’t really happen: humidity levels stayed basically the same, so I replaced the salt with a quarter sheet pan of silica beads (making sure to orient the fan to blow air across the tray but not allowing the meat to touch the silica at all). This made a meaningful difference in bringing down the humidity, but only lasted a short while and needed replacing about every week.

Interestingly, when I left for a one-week trip to Croatia, the humidity declined steadily while I was away, but somehow spiked immediately before I got home. This clued me in to a potential reason why the humidity was sitting so high: when I left, I turned the house’s AC off and programmed it to turn back on shortly before I got back from the trip. The fridge is in the same room as the HVAC, and that room gets warmer and more humid when either the heating or air conditioning is running. The fridge pulls that humid air in, which keeps the internal humidity high even after the meat has lost the moisture it was always going to lose.

tasting notes
#

Starting weight: 14.2 lbs
Ending weight: 12.36 lbs (13% loss)
Post-trim weight: ~9 lbs (largeish fat cap mostly to blame), cut into 10 steaks about 1.5" thick and between 12 and 14 oz each.

The dry-aged taste was noticeable but not overpowering (especially since I had been semi-aggressive in trimming off the pellicle) - really tasty! I’m very satisfied with the results. Haven’t tried a before/after comparison of flavour and tenderness yet - I think I’m saving that for when Mi Yen is home next.

thoughts for next time
#

get a larger subprimal with bone + meat to protect the main steak, something like a 107
try hanging vertically via meat hooks instead of being constrained by the shelf width
go for only a little bit more time (maybe 50 days?)
investigate inoculating fridge/meat with mold
move fridge into a different room to be less sensitive to temp/humidity swings?

All in all: delicious, 10/10 would do again - maybe even this week to be ready before my birthday in November?

Things I Think You Should Read and Watch

Tue, 21 Jul 2026 00:00:00 +0000

This is a curated, non-exhaustive list of tech-adjacent content I’ve really enjoyed and shared with friends and colleagues.

Mostly general thoughts on life as a data scientist, learning/teaching programming, technical leadership, career advice, and other tech-adjacent topics, and not specific to R or sports analytics (will probably tackle that another time).

Inspired by Derek Sivers’s book notes and Vicki Boykis’s favourite essays, and organized loosely by topic (click to jump to section):

life as a programmer & data scientist
#

Michael Lynch: How to Do Code Reviews Like A Human and part two, blog posts (18 and 15 min reads, respectively)
- Code reviews are daily interactions that shape both the code itself and, maybe even more importantly, the relationships between programmers - these posts really help with how to approach these in a constructive and positive way.
Hank Green: The Secret to My Productivity, YouTube video (4 min)
- Invaluable advice on when to stop working on creative projects: stop working on it when you have reached 80% of “the best you can do”, release it to the world, and then go do your next project. Applies in hobbies and tbh to professional projects as well.
Randy Au: Succeeding as a Data Scientist in Small Companies / Startups, blog post (8 min read)
- How to succeed in a small company where you are the first “data” person there: helping the company succeed TODAY and setting up the company to be data driven TOMORROW. Also has a very nice “hierarchy of needs” graphic that explains what it means to set up a company to be data driven. Immediately relevant for people in small companies and also for understanding the core needs for a data team (and seeing how that scales as you add more people.)
Alberto Savoia: The Way of Testivus, PDF blog post
- Advice on developer and unit testing, packaged up as pseudo-Confucian tenets worth living by.
Dan McKinley: Boring Technology, talk/slides and original blogpost
- Core idea: you get “innovation tokens” to spend as a (developer, team) and you don’t have that many even across a team. In order to keep those innovation tokens spent on the team’s core mission (e.g. solving soccer), you should spend less time innovating on the core technologies (fancy database stuff, programming paradigms etc), because fixing bleeding edge database stuff takes up “innovation tokens” that you want to spend doing other things.
David Robinson: Unreasonable Effectiveness Of Public Work, YouTube talk recording (40 min)
- Anything you put out into the world is going to be far better and far more useful than anything that sits in your drafts folder waiting for some arbitrary threshold of “good” before it gets published. Go out there and do things!

learning and teaching programming
#

Greg Wilson: what everyone in tech should know about teaching and learning, YouTube video (41 min)
- Massively useful! Especially the ideas right at the beginning about mental models and the differences between how beginners, competent users, and experts learn. The whole video is incredible, but I recommend at least the first 8:23 to cover these ideas.
Andy Harris: how to begin thinking like a programmer, YouTube video (61 min)
- A riveting talk (given at a Python conference, which should surprise you if you know me). which covers how to think like a programmer. Especially profound: comments are not for explaining code to other programmers - instead, code is there to explain comments to the computer!

technical leadership
#

Tanya Reilly: Being Glue, annotated talk slides and YouTube video (28 min)
- A brutally honest talk about the non-promotable “glue” work that programmers can get silently stuck with, and that hurts your technical development and ultimately your career development if you’re not prepared. Can disproportionately affect teams, especially women and/or introverted/non-assertive personalities.
Julia Evans: Help, I Have A Manager!, zine (~$12)
- Having a good relationship with your manager is probably the most important factor in your happiness at work. This zine is full of great advice on how to make that relationship better - how to handle 1:1s, asking for feedback, figuring out what they’re good at, building a support system for areas they aren’t as good, and more.
Vasily Zubarev: How to hire sane engineers 2.0 (~15 min read)
- A pragmatic Russian’s take on hiring engineers in a “sane” and effective way. Would love to implement this one day to help with bypassing some of the technical interview steps that are so common now.

career advice
#

Derek Sivers: How To Do What You Love And Make Good Money, blog post with audio recording (4 min read/listen)
- This is the advice I share when folks ask me about getting their dream job and making a career from sports analytics or other hobbies - you don’t need to force sports analytics to be both your livelihood and your art! The dream job that does both may or may not come along, but you can be happy in both career and art without it. Part of a larger book, Hell Yeah or No, which is also very worth reading (~$15).
Austin Kleon: Show Your Work, short book (~$15)
- The book I share when people ask me how to build their public portfolio and personal networks: share something small every day without being human spam, teach what you know, and tell good stories. A lot of insights packed into a small and easy to read format. Also great are the other books in the Steal trilogy, including Steal Like An Artist on how to be creative and Keep Going on how to sustain the creative effort
Jacqueline Nolis & Emily Robinson: Build A Career In Data Science, book (~$24) and podcast series (~20 episodes each about 60min)
- A great resource for finding a job in data science. Really like the definitions of data science as an industry - essentially the intersection of programming, statistics, and domain knowledge. Book was available online for free at one point but now seems to be only paid - very worth it, but listening to each of the podcast episodes is a pretty good equivalent.
Haseeb Qureshi: Rules for Negotiating a Job Offer and part two, blog posts (24 and 34 minute reads)
- More people should negotiate job offers and simply don’t. This is good, not-too-kitschy advice on how to approach negotiating.

specific technologies
#

Vasily Zubarev: Machine Learning For Everyone, blog post (~40 min read)
- “Machine Learning is like sex in high school. Everyone is talking about it, a few know what to do, and only your teacher is doing it.” An impressively nontechnical and yet surprisingly comprehensive overview of machine learning that I found useful early on in my data science career as someone with neither a CS nor a stats background.
Julia Evans: Hell Yes CSS, zine (~$12) and comics
- I’ve always found CSS to be incredibly frustrating, but reading this zine was super helpful. Still refer back to the CSS Selectors comic to this day whenever I need to format something.
OhShitGit.com (reference page)
- For the times I manage to fuck up using git, this page consistently saves me every single time.
data.table vs base vs dplyr (reference page)
- An awesome syntax lookup page to go between dplyr, base, and data.table in R - a worthy successor to the original post by atrebas

changelog
#

2026-07-21: added data.table vs base vs dplyr reference page
2025-09-04: added ohshitgit.com
2025-03-17: added David Robinson’s Unreasonable Effectiveness Of Public Work talk
2024-11-29: first version

Data Science Hangout

Thu, 23 Oct 2025 00:00:00 +0000

Recording
#

DSLC Slack: Debugging Netlify Deploys

Thu, 19 Dec 2024 00:00:00 +0000

I greatly enjoy the DSLC Slack Community ( dslc.io/join), and spend a fair bit of time answering questions! This post is part of a series where I curate some interesting questions and/or answers that I’ve come across there.

Question
#

Hi all! I’m having a hard time understanding why netlify checks on a Pull Request with only a empty line added in the commit are failing for a blogdown website. I created this PR as a small example, but basically any kind of PR is failing nevermind its content, and the site is published-rendered without problem if we commit directly to main.

I’m super puzzled by this, does anyone have any tips on how can I debug it? Thanks 🙏

- MC Nanton

Answer
#

Let’s look through some of your Netlify deploy logs. I found these from your GitHub repo automated checks:

editor’s note: archived the deploy logs in question to this gist just in case the deploy logs are deleted at some point

It seems like your PR deploy logs show this warning immediately before failing:

WARN 2024/12/10 21:35:19 Module "hugo-academic" is not compatible with this Hugo
version; run "hugo mod graph" for more information.

and this definitely doesn’t show up on your main deploy logs. Let’s try to figure out where your hugo versions are specified. Here’s a relevant section of the deploy logs:

35:19 PM: ❯ Current directory
35:19 PM: /opt/build/repo
35:19 PM: ​
35:19 PM: ❯ Config file
35:19 PM: /opt/build/repo/netlify.toml
35:19 PM: ​
35:19 PM: ❯ Context
35:19 PM: deploy-preview

The logs say that the file responsible for specifying hugo version is netlify.toml, so let’s have a look at what that looks like on GitHub right now:

[context.production.environment]
HUGO_VERSION = "0.64.0"

Notice that it specifies context.production here, and that the context for the failing logs is deploy-preview. If we go back into the failing logs, we can confirm that the hugo-version specified here isn’t working properly:

4:35:12 PM: Installing Hugo 0.57.2

So a solution that should work is to update the netlify.toml to specify the HUGO_VERSION for the deploy-preview context:

[context.production.environment]
HUGO_VERSION = "0.64.0"
[context.deploy-preview.environment]
HUGO_VERSION = "0.64.0"

and this should do the trick. You might need to push it to main instead of to a PR branch though, Netlify usually uses the config from the main repo branch.

(Update: this solution worked!)

The Beginner Data Science Programming Book That Doesn't Exist (Yet?)

Tue, 10 Dec 2024 00:00:00 +0000

Ideas are worth nothing unless executed, and I’m tired of adding ideas to my backlog only to never get to them. This series aims to set those ideas free - let me know if you take it on!

Hot take: the ideal beginner data science programming book doesn’t exist (yet)
#

The beloved R for Data Science is a fantastic book, and yet I struggled immensely with following along with it. I think it’s because I can only care so much about flower irises, penguins, and NYC taxis: I quit halfway through the third chapter of R4DS on my first attempt in 2018ish, … because I got bored.

Since then, I’ve gotten treatment for ADHD (which probably explains a lot, tbh), but I think what really helped the most with learning programming was that I started working on projects that I actually cared about: fantasy football and NFL.

I’d work on something for a while, get stuck on something I didn’t know, Ctrl-F the R4DS book + dplyr/tidyr reference manuals, figure out what I needed to know and how it fit into what I already knew, and then keep going. Reading R4DS cover to cover was utterly unhelpful until I knew how to fit each concept into a mental model that I knew how to use.

My love of all things R and data has since taken off (enough to have made a whole career of it), and now I often get asked what books I’d recommend for learning NFL/sports analytics, R, data science, programming etc. I supply the easy answer (“you should read R4DS”), but I’m a little uncomfortable with it because the book I wish I could recommend doesn’t quite exist.

the ideal book for learning programming and NFL analytics
#

There are a lot of introductory data science and programming books out there, and even ones that apply the context of NFL: both Eric Eager and Brad Congelio have great iterations of this (and the latter is free online)!

I’m so glad these books exist now and they’d have certainly helped a lot when I first got started, but I’m not quite sure these are the ones I’ve been wanting:

how do they stay up to date with a fast-evolving programming landscape?
how do they compare with the existing literature that is beloved by the community, like R4DS, and how should beginners proceed if the books disagree on best code approach?
what happens if I want to learn another programming language other than R?

I think the book I want to exist would be structured as a companion to books like R4DS, but not include any language-specific code whatsoever. Instead, I’d focus on a few goals:

create a series of case studies and exercises that challenge learners to write their own solutions based on domain-specific research questions
- provide starter data of appropriate complexity/cleanliness in a data repository
cover a full breadth of high-level data science / programming topics
- kind of like R4DS’s visualize, transform, import, program, communicate sections
maintain up-to-date links to readings for each case study that help learners find best-practice guidance on a given topic in a supported programming language
- each case study should provide links to “prerequisite reading” to solve it, e.g. links to relevant R4DS chapters for R
- should be easily extended to other languages by linking to equivalent material, e.g. pivoting data, group by + summarize are relational data concepts that have parallels in almost every language
introduce the essential background knowledge for the domain in question
- for NFL this should include concepts like EPA, fourth downs, completion probability, expected rushing yards etc - essentially covering the body of public research
suggest further research questions that can be tackled beyond the controlled sandbox of the book/repository

I think something like this would be massively helpful for introducing people to the relevant public research in a domain, and with putting technical topics into practical use for learners. It would be robust to existing languages evolving (could approach the same case study in e.g. tidyverse, data.table etc), easily extended to new languages (e.g. Python, Julia, Rust), and even to new technologies (probably could do the whole thing in DuckDB one day). The format also would be easy to adopt in different sports (soccer, basketball, baseball, hockey?) and to other domains altogether.

Of course, I’ve been sitting on this idea for a while: I first started a repo for this idea ~ three years ago and convinced friends like Sebastian Carl to start thinking about it, but neither of us have made much progress, which I think is more due to just a lack of time/energy/expertise in it. I still think it’s a worthwhile idea and am writing this post mostly to set it free and hope someone is inspired to pick it up!

A similar idea has come up since then: the SCORE project led by CMU’s Statistics and Data Science department aims to provide case studies across all sports for learning statistics and data science, and has a set of modules already. I’m not sure if ~ learning to program in a given language is in the scope of the project - it seems to be very statistics-focused - but it could otherwise be an interesting parallel project?

Adventures In Scaling Shiny: Lessons Learned Building DynastyProcess

Thu, 10 Oct 2024 00:00:00 +0000

Recording
#

Materials
#

Repo: https://github.com/tanho63/talk_shinyprod2024_scaling

tidyr pivot trick: names_to -> .value

Thu, 30 Nov 2023 00:00:00 +0000

I originally shared this tip for extracting data from column names as a tweet, and I’ve found myself sharing it over and over again since. Here’s a brief transcription now that I’m no longer on Twitter.

One of my favourite data-wrangling tricks is tidyr::pivot_longer’s names_to & .value sentinel - use-cases don’t come up often, but it’s so deeply ✨ satisfying ✨ when it does!

Scenario
#

Let’s say you have this starting dataframe:

# A tibble: 601 × 22
 season title caught_fred caught_daphnie caught_velma caught_shaggy
 <chr> <chr> <chr> <chr> <chr> <chr>
 1 1 What a Nig… FALSE FALSE FALSE TRUE
 2 1 A Clue for… FALSE FALSE FALSE TRUE
 3 1 Hassle in … FALSE FALSE FALSE FALSE
 4 1 Mine Your … TRUE FALSE FALSE FALSE
 5 1 Decoy for … FALSE FALSE FALSE FALSE
 6 1 What the H… TRUE FALSE FALSE FALSE
 7 1 Never Ape … TRUE FALSE FALSE FALSE
 8 1 Foul Play … FALSE FALSE FALSE FALSE
 9 1 The Backst… FALSE FALSE FALSE TRUE
10 1 Bedlam in … FALSE FALSE FALSE TRUE
# ℹ 591 more rows
# ℹ 16 more variables: caught_scooby <chr>, captured_fred <chr>,
# captured_daphnie <chr>, captured_velma <chr>, captured_shaggy <chr>,
# captured_scooby <chr>, unmask_fred <chr>, unmask_daphnie <chr>,
# unmask_velma <chr>, unmask_shaggy <chr>, unmask_scooby <chr>,
# snack_fred <chr>, snack_daphnie <chr>, snack_velma <chr>,
# snack_shaggy <chr>, snack_scooby <chr>
# ℹ Use `print(n = ...)` to see more rows

and you want this ending dataframe:

# A tibble: 3,005 × 7
 season title character caught captured unmask snack
 <chr> <chr> <chr> <chr> <chr> <chr> <chr>
 1 1 What a Night for a Knight fred FALSE FALSE FALSE TRUE
 2 1 What a Night for a Knight daphnie FALSE FALSE FALSE FALSE
 3 1 What a Night for a Knight velma FALSE FALSE FALSE FALSE
 4 1 What a Night for a Knight shaggy TRUE FALSE FALSE FALSE
 5 1 What a Night for a Knight scooby TRUE FALSE TRUE FALSE
 6 1 A Clue for Scooby Doo fred FALSE TRUE TRUE FALSE
 7 1 A Clue for Scooby Doo daphnie FALSE TRUE FALSE FALSE
 8 1 A Clue for Scooby Doo velma FALSE TRUE FALSE TRUE
 9 1 A Clue for Scooby Doo shaggy TRUE FALSE FALSE FALSE
10 1 A Clue for Scooby Doo scooby FALSE FALSE FALSE FALSE
# ℹ 2,995 more rows
# ℹ Use `print(n = ...)` to see more rows

How do you extract the characters (Fred, Velma, Daphnie, Shaggy, Scooby) from the column names into a character column?

Past me
#

Hmm, well, I can pivot_longer, then separate the name, then pivot_wider again?

three_lines <- x %>%
 pivot_longer(cols = -c("season","title")) %>%
 separate(name,into = c("action","character"), sep = "_") %>%
 pivot_wider(names_from = "action", values_from = "value")

# A tibble: 3,005 × 7
 season title character caught captured unmask snack
 <chr> <chr> <chr> <chr> <chr> <chr> <chr>
 1 1 What a Night for a Knight fred FALSE FALSE FALSE TRUE
 2 1 What a Night for a Knight daphnie FALSE FALSE FALSE FALSE
 3 1 What a Night for a Knight velma FALSE FALSE FALSE FALSE
 4 1 What a Night for a Knight shaggy TRUE FALSE FALSE FALSE
 5 1 What a Night for a Knight scooby TRUE FALSE TRUE FALSE
 6 1 A Clue for Scooby Doo fred FALSE TRUE TRUE FALSE
 7 1 A Clue for Scooby Doo daphnie FALSE TRUE FALSE FALSE
 8 1 A Clue for Scooby Doo velma FALSE TRUE FALSE TRUE
 9 1 A Clue for Scooby Doo shaggy TRUE FALSE FALSE FALSE
10 1 A Clue for Scooby Doo scooby FALSE FALSE FALSE FALSE
# ℹ 2,995 more rows
# ℹ Use `print(n = ...)` to see more rows

This seems to work okay!

But what if I told you there’s a one-liner for this exact situation?
#

pivot_longer has a “names_to” argument that takes a special “sentinel value” called ".value" - it immediately re-pivots the columns so that “character” (fred, daphne etc) stays as a column and then the “.value” part becomes colnames again (caught, captured etc)

one_line <- x %>%
 pivot_longer(
 cols = -c("season","title"),
 names_to = c(".value","character"),
 names_sep = "_"
 )

# A tibble: 3,005 × 7
 season title character caught captured unmask snack
 <chr> <chr> <chr> <chr> <chr> <chr> <chr>
 1 1 What a Night for a Knight fred FALSE FALSE FALSE TRUE
 2 1 What a Night for a Knight daphnie FALSE FALSE FALSE FALSE
 3 1 What a Night for a Knight velma FALSE FALSE FALSE FALSE
 4 1 What a Night for a Knight shaggy TRUE FALSE FALSE FALSE
 5 1 What a Night for a Knight scooby TRUE FALSE TRUE FALSE
 6 1 A Clue for Scooby Doo fred FALSE TRUE TRUE FALSE
 7 1 A Clue for Scooby Doo daphnie FALSE TRUE FALSE FALSE
 8 1 A Clue for Scooby Doo velma FALSE TRUE FALSE TRUE
 9 1 A Clue for Scooby Doo shaggy TRUE FALSE FALSE FALSE
10 1 A Clue for Scooby Doo scooby FALSE FALSE FALSE FALSE
# ℹ 2,995 more rows
# ℹ Use `print(n = ...)` to see more rows

Why use many line when one line do trick?

You can read more about this pivot_longer feature in this tidyr vignette.

Bonus: data.table equivalent
#

I learned later (from Hadley quote-tweeting my thread) that this feature was inspired by a similar feature in data.table, so I wanted to track down how it would be done there. As it turns out, kind of difficult because the feature isn’t in the CRAN version: it was in development as of October 2020, merged to main in May 2021, and still hasn’t made it onto CRAN because of some data.table governance issues (which are finally getting close to being resolved?)

In any case, with the main branch of rdatatable/data.table as of today, here’s how you could do the same pivot trick:

# requires development version of data.table and/or 1.15.0+
rlang::check_installed("data.table (>= 1.14.99)")
data.table::data.table(x) |>
 data.table::melt(
 id.vars = c("season", "title"),
 # measure() is not actually exported but is silently parsed under the hood by melt()
 # - uses `sep = "_"` to identify & process the column names (i.e. split with sep "_")
 # - new column names (i.e. character) are provided unquoted
 # - value.name is equivalent to tidyr's `.value`
 measure.vars = measure(value.name, character, sep = "_")
 )

 season title character caught captured unmask snack
 <char> <char> <char> <char> <char> <char> <char>
1 What a Night for a Knight fred FALSE FALSE FALSE TRUE
1 A Clue for Scooby Doo fred FALSE TRUE TRUE FALSE
1 Hassle in the Castle fred FALSE FALSE TRUE TRUE
1 Mine Your Own Business fred TRUE FALSE TRUE FALSE
1 Decoy for a Dognapper fred FALSE FALSE FALSE FALSE
 ---
2 The Dreaded Remake of Jekyll & Hyde! scooby FALSE FALSE FALSE FALSE
Movie Happy Halloween, Scooby-Doo! scooby FALSE FALSE FALSE FALSE
Movie Scooby-Doo! The Sword and the Scoob scooby FALSE FALSE FALSE FALSE
2 Dark Diner of Route 66! scooby TRUE FALSE FALSE FALSE
2 Total Jeopardy! scooby FALSE FALSE FALSE FALSE

Full Code
#

library(tidyverse)

scooby_data <- read.csv("https://raw.githubusercontent.com/rfordatascience/tidytuesday/master/data/2021/2021-07-13/scoobydoo.csv")

x <-
 scooby_data %>%
 select(season, title,
 starts_with("caught"),
 starts_with("captured"),
 starts_with("unmask"),
 starts_with("snack"),
 -contains("other"),
 -contains("not")) %>%
 filter(title!= "Wrestle Maniacs")

three_lines <- x %>%
 pivot_longer(cols = -c("season","title")) %>%
 separate(name,into = c("action","character"), sep = "_") %>%
 pivot_wider(names_from = "action", values_from = "value")

one_line <- x %>%
 pivot_longer(cols = -c("season","title"), names_to = c(".value","character"), names_sep = "_")

rlang::check_installed("data.table (>= 1.14.9)")
data.table::data.table(x) |>
 data.table::melt(
 id.vars = c("season", "title"),
 # measure() is not actually exported but is silently parsed under the hood by melt()
 # - uses `sep = "_"` to identify & process the column names (i.e. split with sep "_")
 # - new column names (i.e. character) are provided unquoted/as bare symbols
 # - value.name is equivalent to tidyr's `.value`
 measure.vars = measure(value.name, character, sep = "_")
 )

Original gist for reference.

Effective Logging Strategies

Fri, 13 Oct 2023 00:00:00 +0000

Recording
#

Materials
#

Repo: https://github.com/tanho63/talk_shinyprod2023_logging

Debugging Shiny Apps

Fri, 17 Mar 2023 00:00:00 +0000

Recording
#

Materials
#

https://github.com/tanho63/talk_shinyconf2023_debugging

Using GitHub To Make Your Work Live Forever

Wed, 27 Jul 2022 00:00:00 +0000

Recording
#

blogdown, distill, and personal websites with R

Fri, 04 Feb 2022 00:00:00 +0000

I’ve recently been asked three times for my advice on whether to use blogdown or distill when getting started with your first website with R, so in true DRob fashion: here’s a blog post!

2023 note This post never actually got properly fleshed out beyond a set of bullet notes, but I figure it’s still worth sharing 😅 Have added a couple of 2023 notes as well.

TLDR
#

They’re both great, and incredibly well supported within the R community.
It doesn’t matter what you start with, you can redo your site later. You probably will want to at some point down the line regardless, it’s part of the learning process! Your content will transfer with minimal effort.
I recommend starting with blogdown and Hugo Apero in most cases, EXCEPT
…if you know you dislike CSS and styling, in which case Distill is perfect for you
Buy a domain name, serve it with Netlify or GitHub Pages, and go forth and grow your garden!

Distill
#

Distill is minimalist in that it doesn’t let you do a lot aesthetically - this means that most distill sites are straightforward and clean and incredibly easy to maintain/use going forward.
The most you’ll do is pick fonts and colours - everything else is pretty much set out for you.

2023 note RStudio/Posit folks are promoting Quarto websites for this minimal/simple aesthetic now.

Distill sites will still work (Distill simplicity at it’s finest!), but if you haven’t started your site yet you might be interested in starting from the “latest hotness”.

Another compelling reason to use to Quarto is the ability to use Python and Observable JS alongside with R chunks, so if that’s of interest I’d look into switching.

Blogdown
#

blogdown is decidedly not minimal - everything is flexible and can be laid out in any number of ways
this means you can pick out some kickass hugo themes from somewhere and plug them in so that your site doesn’t look like other people’s sites
- e.g. https://tanho.ca/ and https://ffverse.com/ are both blogdown sites, but don’t have the same feel at all
the flexibility means you’re more likely to break your site somehow, and also increases the temptation that you’ll end up nuking your site and rebuilding it from scratch.
the latest/safest hotness in blogdown is Alison Hill’s Hugo Apero theme
I spend a bunch of time doing front-end with Shiny so I’m not as scared to wade into the guts of css/html crap - this site is primarily made from a theme called Toha, and ffverse.com from a theme called Osprey

2023 note I’ve since ported tanho.ca to a new theme, Blowfish.

I found that I was overriding a lot of the Toha theme components manually and realized I wanted something that was more flexible.

Which one do I choose?
#

Whichever one appeals to you, if you’ve read all the way through to here! In most cases, I think there’s a lot of value in learning to use blogdown, and would recommend starting there with Apero…except if:

you don’t care about the aesthetics,
you know you hate CSS and style decisions, or
you want to get started quickly

in which case Distill is perfect for you!

Setting Up Your Own Shiny Server

Mon, 11 Oct 2021 00:00:00 +0000

Recording
#

Eating Habits as Levers

Sat, 09 Oct 2021 00:00:00 +0000

I stepped on the scale today and realized I had hit a milestone: I’ve lost fifty pounds since starting my weight loss efforts five months ago. It’s a nice, if somewhat bittersweet milestone to hit on this weight loss journey - I recorded a pretty similar milestone in 2018 while going from 275 lbs to 200 lbs. Life happened (happens, I guess) and while I’m a tad bitter, there’s some comfort in the confidence that I’m capable of reaching my goals when I put the effort in.

I wanted to write down a mental model that I’ve been experimenting with around dieting, eating habits, and weight loss. While this post is not a formally qualified opinion and does not constitute medical advice, it feels like a useful mental model for understanding the many varied paths to the same goal.

Levers to use towards a caloric deficit
#

lever (noun):

A long handle used to operate a machine or control panel.

A simple machine consisting of a straight, rigid bar and a fulcrum, used to multiply mechanical force to do more work.

Losing weight involves consuming less calories than you expend over a significant amount of time¹ - aka “caloric deficit”. In most cases (and especially among those with a lot of weight to lose), adjusting your eating habits is a much bigger driver of caloric deficits than purely exercising (although exercise is good and useful). So let’s define for ourselves the work (in a mechanical sense) as being “eating a caloric deficit”.

Now that we’ve defined work, we can frame all “diets” as three types of levers (in the “simple machines” sense above) that we can apply force (i.e. effort, time, discipline) to: what you eat, when you eat, and how much you eat.

What you eat covers all kinds of food restrictions, including low carb (keto, Atkins etc), low fat, high protein, vegetarian/vegan, paleo, or otherwise. These primarily work because there’s a property about that food that makes it hard to overeat - in keto, you eat more fats and your brain thinks you’re satiated before you reach a certain calorie threshold, while in low fat and/or vegetarian diets you eat more greens and proteins so that your stomach becomes full before it can take in a certain number of calories etc. This works - the primary mechanism for me losing weight in 2018 was eating a keto diet and being ruthless about cutting out carbs.
When you eat covers all kinds of fasting - intermittent, extended, or otherwise. The primary mechanism here is eating fewer meals, so while you do eat to fullness you end up eating less calories than you would have if you’d eaten three meals. In practice your appetite is also somewhat diminished (or your stomach “shrinks”) so your fullness threshold happens more quickly and at a lower calorie threshold. This can also work on a broader scale as I’m doing right now in 2021, where over the course of a seven day week I fast on three days - effectively reducing my calorie intake by 40%.
How much you eat covers calorie, macro, or portion control for each meal. If this is the lever you’re using, you’re doing the classic “track your calories at each meal” methodology and being precise about how much you take in at each meal - think of classic apps like My Fitness Pal, IIFYM etc.

All three of these levers, when properly applied² within the goal of caloric deficit, successfully lead to weight loss over time with adherence. If you use none of them, you’re eating the Standard American Diet (SAD being an apt acronym).

Some levers are easier for some people to use than others - the one that is easiest for me may not be the easiest for someone else. Heck, the one that’s easiest for me today (when to eat/fasting) is not the same as the one that worked the last time (what to eat/keto). In 2018, I ground out a keto strategy to some success, but found food boringly repetitive and socializing difficult. I’m finding fasting easier to stick to this time around, because when I do eat I don’t need to worry about “what” I’m eating or “how much” I’m eating at each meal - I can eat until I’m full when I do eat and eat whatever I’m craving.

You can apply force on these levers with varying degrees of intensity (fasting for longer, reducing portion sizes more, cutting out more foods), and you can use one, two, or three levers at a time. It is mentally draining to use two or all three levers intensely at once - i.e. keto + one meal a day is very tough to stick to, as I’ve found out - it could be doable in the short term as a treatment but feels so unsustainable as a long term plan.

If you can strive to put consistent effort into just one of these levers at a time, you should be able to stick to that pattern for a longer period of time - and adherence to a caloric deficit leads to more successful weight loss.

There are some other hypotheses about why obesity exists, including the carbohydrate-insulin model, but I don’t personally find them very convincing after experimenting with them. I’m not sure I’m the right person to discuss those without having done the research. ↩︎
All three levers have possible ways to fail at the goal of eating a caloric deficit - you can still indulge in too many calories while eating keto, you can binge eat when fasting so as to wipe out your efforts, and you can be poor/ineffective at tracking your calories at each meal (or misjudge the correct calorie numbers etc). ↩︎

Wrangling JSON and Lists

Mon, 02 Aug 2021 00:00:00 +0000

Recording
#

Web Scraping with rvest

Mon, 19 Jul 2021 00:00:00 +0000

Recording
#

Adventures in HTTP Testing for R

Mon, 08 Mar 2021 00:00:00 +0000

Embrace unit testing karma

Karma says:

Do good things and good things will happen to you.

Do them the way you know.

Do them the way you like.

Karma is flexible. Testing needs flexibility.

Karma thrives on creativity. Testing needs creativity. - Testivus

While developing ffscrapr, I’ve taken a deeper dive into HTTP testing for R packages. I’ve settled on using httptest and find it very convenient path to building and using mock data, especially since I’m using httr extensively within the package. I wish Scott Chamberlain & Maelle Salmon’s new book HTTP testing in R had been written before I started - that would have been incredibly helpful as a guiderail for my experimentations! Here are some thoughts on what I’ve discovered while testing ffscrapr, mostly trying to capture parts of my experiences that differ from what’s already in the HTTP testing book.

Why test?
#

Testing is about making sure that the package (and functions) work as intended, in spite of external factors. With API packages, sources of errors can include:

internet connectivity (both from the user and from the API)
API response changes (format changes, variable naming, etc)
dependency changes (this could include base R versions, operating systems, as well as the more obvious package dependencies)
users doing unexpected things with your package (finding corner cases)

A good test setup should test at least the first three of these (user-side corner cases being difficult to foresee at time of function definition), and ideally should test each area individually while holding the other two parts constant. For example, you want to test how the package handles internet connectivity without worrying about whether the API response changes, or whether the dependencies have changed. You also want to test the package every time the dependencies change, without worrying about internet connectivity or API responses changing. And lastly, you want to test and make sure that the real API response has not changed, because it might return unexpected results. In addition to these concerns, another really important element to consider is making sure that it is easy to maintain the testing setup.

For ffscrapr, I think the most important of these are testing the code for dependency changes and testing the code for API response changes. Internet connectivity seems fairly straightforward to write code for, and is worth doing at least once, but especially in a heavier-weight package like ffscrapr (which imports quite liberally from tidyverse packages like dplyr, purrr, tidyr etc), dependency testing is crucial to making sure the package continues to clean and process the data in the intended fashion. Also, fantasy platform APIs do change on a pretty frequent basis, adding and removing features nearly every year. It’s worth testing against the live APIs to make sure that ffscrapr continues to operate as intended and without errors.

Why not skip CRAN testing?
#

Many API packages skip all testing on CRAN - it’s a hassle to maintain, and the risk of being booted from CRAN can outweigh the effort of making sure tests don’t fail. I’m here to suggest otherwise! I think developers are missing out on one of CRAN’s most important benefits, which is being a massive dependency testing suite. Packages are tested on many different combinations of operating systems and R versions on a regular basis, and CRAN will also require your dependency packages to make sure that changes they make don’t break your package (and/or if they do, to give you advanced notice that it will break your package). This gives you time to make the appropriate changes to the package to accommodate the change!

Skipping these tests on CRAN is doing yourself a disservice, in my opinion, especially with the development of packages like httptest (which I use) and alternatives like vcr/webmockr - I think the extra work in making the package CRAN-testable (at least, to make sure that your R code processes the responses properly) is worth doing. These packages essentially create local copies of the data that the API would return from your http query, and redirect your request to read from the local files instead of letting your request go through to the API - allowing you to test while holding the API responses constant.

Storing mock data in a separate repository
#

In an ideal world, tests and files are small and can be stored alongside the test data, such that you don’t overrun CRAN’s limitations on compressed or installed package sizes (5MB, generally speaking). With ffscrapr, I was finding that responses from certain sites (cough, Fleaflicker, ESPN, cough) were enormous - they package a whole whack of player data within each call, such that their responses were coming back at 5-10MB each!

In consulting the available documentation, I came across this GitHub issue in the httptest repository, in which Neal Richardson describes some of his suggested approaches to solving this problem:

Creating a function to redact the responses on capture
Manually pruning the captured responses
Refactor larger functions so that they can be tested on smaller chunks of data
Lastly (and least-optimally, in Neal’s opinion) - creating a separate data package that holds the response cache

I took a stab at each of these approaches, but one by one I had to discard them:

API responses for fantasy football platforms are subject to change on a pretty regular basis - I’ve had to rebuild the captured responses several times since I started developing this package in August 2020, and corner cases are unlikely to appear in the first 5-10 responses of data
Manually pruning the captured responses is unfeasible for similar reasons as above, and is also infinitely more time-consuming!
I did try to refactor some of the larger/longer-running functions into smaller/more-testable units, especially since APIs frequently have options to limit and paginate. However, some of these requests were very difficult to configure in this fashion, and other functions that I wanted to test needed to aggregate large amounts of data. I wanted the tests to be easily evaluated via the naked eye.

Thus, I landed on creating a separate package of test data files as my best route forward. I briefly considered the idea of pushing the data package to CRAN - this would ensure that it would always be “accessible” to the CRAN package wherever accessed - but discarded the prospects of both getting an exemption on package size AND maintaining regular updates to the test data. Instead, I opted for a separate GitHub repository of test files, which I considered to be a relatively reliable place to store the data.

Of course, a few concerns popped up with this option, which needed handling:

I would need to check that I could download the data at the time of test/vignette-build, and then skip testing/evaluating if GitHub or the data were unavailable.
I would need to find a way to version-control and make sure that I didn’t accidentally delete test data that would cause CRAN testing to break - that would defeat the whole purpose of going through all the trouble of mocking the data!

I managed the latter concern with a GitHub release, which allowed me to version-lock the test-data to match the CRAN version. I’ll need to make sure to update the links within the package at every CRAN release, but I think this should be feasible!

2023 note I didn’t know of the existence of piggyback at the time of this writing but if I did I would have used it instead so as to not have to track another repository. It’s been buried on my project list, but I’ve wanted to make a PR to add a piggyback option to httptest for a while now.

Accessing the mock data
#

This needed some finagling, but I eventually settled on the following code in my testthat setup file:

suppressPackageStartupMessages({
 library(testthat)
 library(httptest)
 library(checkmate)
})

(Packages)

if (identical(Sys.getenv("MOCK_BYPASS"), "true")) with_mock_api <- force 

If a system environment variable named MOCK_BYPASS has value of true, override the definition of “with_mock_api” to be “force”, which stops the mocking behaviour and replaces it with normal evaluation.

download_mock <- !identical(Sys.getenv("MOCK_BYPASS"), "true") & !is.null(curl::nslookup("github.com", error = FALSE))

If not mock_bypass AND github.com is available (via a curl check), set download_mock to TRUE, otherwise set to FALSE. This checks as to whether the mock data should be downloaded at all.

skip <- FALSE

if (download_mock) {
 tryCatch(
 expr = {
 download.file("https://github.com/dynastyprocess/ffscrapr-tests/archive/1.3.0.zip", "f.zip")
 unzip("f.zip", exdir = ".")

 httptest::.mockPaths(new = "ffscrapr-tests-1.3.0")

 withr::defer(
 unlink(c("ffscrapr-tests-1.3.0", "f.zip"), recursive = TRUE, force = TRUE),
 testthat::teardown_env()
 )
 },
 warning = function(e) skip <<- TRUE,
 error = function(e) skip <<- TRUE
 )
}

With “skip” as default FALSE, try to download the data from the archive link (version controlled) and then unzip it. Then, set the .mockPaths to read this unzipped directory. When done, delete the zipped file and the test data. If anything generates a warning or error, set skip to TRUE.

skippy <- function() NULL
if (skip) skippy <- function() testthat::skip(message = "Unable to download test data")

With skippy defined by default as a function that does nothing, if skip is TRUE (because of the previous step), change the definition of skippy to skip all tests.

I think this addresses my concerns - if running in a non-live-situation AND mock data can be downloaded, do so, otherwise skip all tests! A similar setup and teardown happens in all the vignette RMDs as well.

Capturing the mock data
#

Capturing the mock data turned out to be a fairly straightforward process. I made sure to have the test-data folder in the same top-level directory as the package itself, and then capturing the mock data was comfortably done with:

library(httptest)
start_capturing("../ffscrapr-tests")
{run the tests}
stop_capturing()
{commit and push the test data}

I’ve had some problems with my PC’s locale settings encoding the JSON oddly in the past, but I usually get around that by jumping onto an available RStudio server instance on a Linux server and re-recording the tests there when necessary. (This is probably overkill - if you’re reading this and have better suggestions, let me know!)

Testing the real APIs with GitHub Actions
#

CRAN obviously cannot test the real APIs, because it cannot handle failures gracefully. Instead, I have a GitHub Action that does this by running the package tests with the MOCK_BYPASS environment variable set to “true”. Paired with a cron schedule of once a week, this successfully catches API changes and issues before users can find them, which helps me anticipate and start patching bugs more effectively.

Like-Hearted

Thu, 04 Mar 2021 00:00:00 +0000

I immensely recommend Austin Kleon and the Steal trilogy to everyone, especially those looking to “make it” as a creator, programmer, or data analyst.

TLDR: Curating your feed, finding your friend groups, and getting into online arguments can be good
#

Each year, I embark on a journey to re-read Austin Kleon’s Steal trilogy, and each time I read it, something new grabs my attention. I was struck today by this image from a chapter in Keep Going called “Like-Minded vs Like-Hearted”:

Modern day Bart Simpson would totally be punished with this

Like many people, I’m not immune to getting drawn into online arguments - just ask the folks on the Dynasty Movement Discord server about my many different soapboxes - so reading this immediately after having been drawn into a particularly vivid discussion hit a little closer to home.

I’ve heard many a time that you should never get drawn into an argument online: it’s impossible to win, petty trolls cannot be fed, and that it’ll have a negative impact on your work, life, and mental health. It’s easy to point to examples of this - a notable Twitter presence making personal attacks, someone repeatedly moving the goalposts on a debate, or someone standing up for an controversial idea and getting bombarded with bits of conventional wisdom - and think that you’d better served by avoiding confrontations altogether.

And yet,

“To think independently of other human beings is impossible. Thinking is necessarily, thoroughly, and wonderfully social. Everything you think is a response to what someone else has thought and said.” - Alan Jacobs, How To Think (c/o Keep Going)

I’ve spent a large amount of time trying to fill my Twitter feed with thoughts, ideas, and opinions from brilliant and insightful people, on topics that I want to get better at. I want my feed to be intelligent, open, and thought-provoking. I’m not as interested in helping others make it big, amass follower counts, become more influential - heck, I’m not looking to do that myself! My Twitter feed is precious to me, and I’m fastidious about stripping away the content that doesn’t fit those goals, or just plain old doesn’t make me happy.

This is both a blessing and a curse: it’s very easy to fall into a trap where you fill your feed (and friend groups) with like-minded people - the people who like the same programming language you do, the same dynasty fantasy strategies, the same analytical methods. Having too much in common makes it tricky to find your own space and niche within your friend group, and you become deeply set in your ways.

If you really want to explore ideas, you should consider hanging out with people who aren’t so much like-minded as like-hearted - those who are temperamentally disposed to openness and have habits of listening. The ones who think about what you’re saying rather than just reacting.

This is a really valuable idea - and one that I feel like I need to strive for, and keep striving for. I’ve backed into finding like-hearted people in my feed, inadvertently, because I’ve been following more and more open source sports data and R stats community members, and that community is inherent more likely to share, listen, and celebrate each other’s achievements.

I’ve also lucked into a community in the TDM Discord where I feel comfortable making those online arguments and challenging opinions, because so many folks there feel like-hearted to me - they listen, they challenge me to be articulate my opinions, and when we disagree we can still respect each other’s opinions. It’s rare that I feel like I’m left angry or drained after spending time there.

The takeaway from the chapter, for me, is that I should continue to strive to surround myself with like-hearted people - on my Twitter feed, in my Discord/Slack communities, and in real in-person friend groups. I’m lucky to have the communities I’m in, and I’m very glad to be able to get drawn into debates amongst my like-hearted friends.

DSLC Slack: Changing Window Titles in Shiny

Tue, 20 Oct 2020 00:00:00 +0000

`Dhiraj` asks:
#

I have a shiny application which uses the navbarPage() layout. The app has multiple tabPanels with their own titles. Is it possible to have the windowTitle of the navbarPage dynamic to show the titles of the tabPanels ?

Answer
#

Here’s a minimal example of the Shiny and JS code you’ll need:

library(shiny)
library(tidyverse)

custom_js <- 'Shiny.addCustomMessageHandler("handler_windowtitle", switch_window_title );
function switch_window_title(message){
 document.title = message;
}'

ui <- navbarPage(
 title = 'navbarpage',
 id = 'displayed_tab',
 tags$head(tags$script(custom_js)),
 tabPanel(title = "StrangePlanet"),
 tabPanel(title = "DarthVader")
)

server <- function(input, output, session) {
 observeEvent(
 input$displayed_tab,
 session$sendCustomMessage("handler_windowtitle",input$displayed_tab)
 )
}

shinyApp(ui, server)

If you give navbarPage an ID, it’ll create an input variable that can be accessed as input${id}, returning the value argument of the tabPanel. In this case, tabPanel returns the title argument as the default value - you can specify something else if you prefer.

In a production app, I’d also move the JS into a separate JS file (stored in www) and use includeJS() instead of using the tags$script method.

DSLC Slack: Explaining Shiny to Your IT Team

Thu, 15 Oct 2020 00:00:00 +0000

`Piranha` asks:
#

Hello, This might be bit of a stretch…. I could use a bit of help in prepping for some upcoming conversations with the head of my company’s IT/Security.

I am trying to get IT support for Shiny (currently IT supports Tableau).

Question: Is there any kind of high level summary of this Admin Guide document? https://docs.rstudio.com/shiny-server/

More specifically, I want to summarize the official document into about a 3-5 slide presentation. Topics that I want to include:

What is Shiny? (3-5 bullet points, in language that a “traditional” IT person will understand)

How to think about security and authentication for both the Shiny Server free and Pro.

How to think about Dockerizing an application.

I attempted to summarize the official docs into a 3-5 slide PowerPoint (ugh, yes, PowerPoint!), but am really struggling. This is a massive document and I am not an IT person!
Any pointers would be really helpful.
Thanks!

Answer (by me)
#

I don’t know if I have a document to point you at, but I would suggest a mental model where you separate Shiny the app (the app.R file and all of the things included in it) from the ways you deploy Shiny. Writing out some of my personal thoughts on it:

Shiny (the app):

is an R package that allows you to write UI (client-side) and server-side logic in R, which can be implemented quickly (from a code-writing perspective) and powerfully (leverages all of the modelling/data-wrangling packages and abilities of R).
has an architecture consisting of a client (the browser) and a server (an R process). The two are connected by a websocket that receives state changes from the client, such as new values for input controls, and distributes state changes from the server, such as new output values.

Shiny is not self-contained because it relies on R and other libraries (Shiny, as well as whatever else you use in the app) that are installed onto the server. Docker is one of the best ways to handle this, because it creates a container that holds an installation of R and all of the relevant packages, and can be version-locked to ensure stability. Once a Shiny app has been dockerized, it can be turned over to a devops team to deploy, and the devops team does not have to know R or Shiny in order to use the app.

This allows for a division of expertise:

the data scientist makes the app, and makes sure the docker container builds and works as intended
the devops engineer can take care of the details with deploying and securing the apps, by controlling/restricting access to the container itself rather than forcing the data scientist to worry about it inside the app.
Both the data scientist and the devops engineer should responsible for performance:
- data scientist by improving the code for efficiency
- engineer by supplying the containers with the right amount of processing power/memory/load-balancing
A dedicated devops person can pretty easily deploy a docker container into an existing app/microservices system, if such already exists.

At the other end of the spectrum, shinyapps.io and RS Connect are solutions that RStudio provides to help data teams who want this sort of devops process but don’t want to have the work done in house. They’ll manage the servers for you and make it very easy for R users to just upload all of the app data and configs, and they’ll manage deployment, performance and authentication for you.

I’m a data generalist for a small team, and manage the full stack from data import/wrangle/model to app dev to app deploy. I wouldn’t necessarily recommend that path if your team is large enough - let devops be devops and data scientists be data scientists where possible!

Some followup questions
#

In a discussion earlier this week, a person from IT asked me “I dont know R, can you tell me how Shiny connects to the user’s browser?” I didn’t know much about WebSocket technology at the time, so my response was: “Shiny comes with its own webserver, but a common practice is to use nginx webserver in front of the shiny app”.

Now that I know a bit more…would it be accurate to some something along these lines: “Shiny uses WebSocket technology to create a 2-way communication between the server and the browser. This allows the data scientist to leverage the full data-processing and analytical capabilities of R. In our current process, we need to do processing/analysis in one tool (e.g. SAS, R) and visualization/sharing in Tableau/Excel - creating lots of inefficiencies. Using Shiny, we can fine-tune and scale our analysis to exactly what is needed by the client and serve that via a Shiny dashboard.”

Furthermore, “From the data science team’s perspective, this is our ask. We need the ability to deliver interactive analysis to our clients at scale. Can you help us do that in a secure way? We’ll build the Shiny app and dockerize it. We need help from IT to provide secure access by clients”.

and response:

Shiny uses WebSocket technology to create a 2-way communication between the server and the browser

I cribbed that chunk from here: https://community.rstudio.com/t/is-there-any-equivalent-of-web-sockets-in-shiny-world/17908. If you’re hoping to communicate how Shiny works to an IT person, I would use the wording as described rather than paraphrasing it too much - receives state changes from client and distributes state changes from server is high-level enough for most IT people to understand - and you lose something by abstracting beyond that.

Using Shiny, we can fine-tune and scale our analysis to exactly what is needed by the client and serve that via a Shiny dashboard

I’d change this to say that it allows you to use the same R code that you use to process and generate the data right in the app, which allows you to package the “business logic” right into the app for immediate interactive analyses. I’m not familiar with your team and the ask - but identifying the docker container as the handoff point where IT helps deploy the app and serve it securely and effectively to clients is a good start. That lets IT do the security bit.

DSLC Slack: Things I Learned From Advanced R Book Club

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

I set out reading this book hoping to understand the metaprogramming chapter, and ended up learning a bunch of other stuff along the way!

Here’s a non-exhaustive list of things I learned from each of the sections of Advanced R:

I - Foundations:
#

I notice that I use the switch function a ton now, where previously I used if-else nests.
I use condition-handling to pass errors back to the user of my Shiny apps now.
I now know what an Environment is and where and why R would look for something. (This helps both in function-writing and debugging!)
I write a heck of a lot of functions (this ties into II: Functional Programming, of course)

II - Functional Programming
#

I map the crap out of everything now (if I didn’t before, it’s way worse now!), and have learned to use functions in a ton of different ways.
I now understand what a function factory is, and what to do if a function somehow returns me a function instead (as opposed to panicking about it!)
I now know about a series of modifiers to help adjust function behaviours (memoise, quietly, safely, possibly) - although I use tryCatch as much as I do these.

III - Object Oriented Programming
#

I wrote a package that uses S3! It’s cool to minimize the user interface for multiple platforms and the mental load accompanying.
I still lean to using the explicit “switch” function a lot instead of writing out a useMethod call. May be a habit/pattern worth breaking in the future.
I’m now comfortable USING an R6 package - I don’t know that I’d reach for an R6 system now but the whole “function$method” thing doesn’t scare me anymore
S4? wot that

IV Metaprogramming
#

I now know how to pass expressions to tidyverse stuff!
I now know where to look in the Metaprogramming and how to intepret the text.

V Techniques
#

Debugging: I now know how to use browser(), and love it! Also debug()!
Performance measure/improve: still don’t do a ton of this, even though I’m a shiny dev. I feel like I should care more but I mostly work with smaller data (sub 1,000,000 rows) right now.
I … still don’t know C++ or Rcpp. ¯\(ツ)/¯

Toy Code
#

library(dplyr)
library(rlang)

grouping_variables <- switch(
 params$group_type,
 "S" = exprs(CraftCode, starts_with("Product"), ModelCode, Elevation),
 "B" = exprs(starts_with("Rate")),
 "P" = exprs(starts_with("Part"))
)
 
null_bids <- bids %>%
 group_by(SupplierID, ProjectID, !!!grouping_variables) %>%
 slice_max(LastModDate) %>%
 ungroup() %>%
 select(!!!grouping_variables, ProjectID, SupplierAID, SupplierName, UnitPrice) %>%
 left_join(lowest_bids, by = as.character(grouping_variables))

Metaprogramming - how to pass expressions into select statements. Also example of switch.

Regatta Cheatsheet

Fri, 05 Jul 2019 00:00:00 +0000

The ORC Rec Guide to Regattas
#

A guide to everything regattas: a packing list, approximate scheduling, de-rigging and re-rigging, trailer loading, rules of racing, race plans, and more.

Contents
#

Equipment List
#

A list of gear to pack in your regatta bag.

Three wrenches: 10mm, 7/16", and an adjustable - you will need all three! (Ratcheting helps but is not required.)
Sunscreen, bug spray
Water
Snacks, food
ID, money for concession stand
Optional: First aid kit (including anti-septic, bandages, blister bandages, after-bite, sunburn lotion etc)
ORC uni (or a uni top) - a red shirt will do in a pinch but will create problems at more serious regattas
Spare rowing outfit
Rain jacket
Change of clothes
Towel
Flip flops
Sunglasses
Hat
Oakleys, bucket hat, Fat Ergos uni, Crocs, butter for greasing boat (all optional, for free speed)

Scheduling
#

Generally speaking, the process for any regatta looks like this, but check with coaches to confirm exact dates/times.

Day before: derig all boats going to regatta, load onto trailer, secure.
Morning of: arrive at minimum two hours before your scheduled start time to ensure that you have time to rig your boat, get any last minute regatta-specific instructions, and launch at the start. The two hours will disappear incredibly quickly.
After races, derig the boat again and load onto trailer.
Either same day or next day (check with coach), arrive at ORC for trailer unloading and re-rigging.

Derigging and Rigging
#

Derigging

Get the boat on stretchers, guts up - this will likely require the help of others.
Determine whether the boat uses 7/16" or 10mm hardware, and get the appropriate hardware out.
If others are helping you, divide and conquer: one person (or team of people) go around and loosen all of the rigger nuts and bolts until they are finger-loose, while the other person follows behind to remove the hardware with their fingers, putting the nuts and bolts back into the loose rigger and finger-tightening. Once all nuts and bolts are loosened, that person should ensure that all seats are fastened to the boat with bungee cords. If no bungee cords are available, worst-case you can remove the seats from the boat and place with riggers, but this is generally a very poor alternative that leads to missing equipment.
Place all of the boat’s riggers in a pile near the truck/trailer.

Follow procedure in reverse for rigging - stretchers, finger-tighten nuts and bolts, finish with wrenches, remove bungee cords from seats. Also a good opportunity to check shoes, heel-tiedowns, and speedwashers.

Trailer Loading
#

{TBC}

Rules of Racing
#

{TBC}

Race Plans
#

{TBC}

Short Mobility Warmup for Rowing

Wed, 29 May 2019 00:00:00 +0000

The few short minutes before ORC Rec practices are often hectic as everyone rushes over after work, gets coach boats and equipment ready, and then hops into a boat. That said, I’m hoping to add another wrench into the works this year - a short dynamic warmup to promote mobility and get ourselves ready for rowing.

Short Description
#

Two sets of the following circuit:

Halos (5 reps in each direction)

Cossack Squat (5 reps each side)

(Walking) Spiderman with Hip Lift and Overhead Reach (10 total reps)

Focus on body control, consistent pace, and as much mobility as you can manage. Aim to complete at least one set of the circuit before every practice, although if time allows three wouldn’t hurt.

Exercise Details
#

Halos
#

Focus: Shoulder mobility, posture, abdominal strength (if weighted)

Halos can be done with anything in your hands - a weight plate, medicine ball, kettlebell, or anything similar in size/shape - and weighing something like 10-25 pounds. The goal is to draw a circle around your head at face-level while holding onto the item with both hands and not letting go. If you don’t have something to hang onto, you can get a lot of the same mobility/warmup benefits by interlacing your fingers at the appropriate height.

Cues: Focus on standing tall, keeping your head neutral, and bracing your core. You’re looking to activate the full range of motion in your shoulders. You don’t have to alternate directions every rep - I generally find it simpler to do five rotations in one direction and then five in the other.

Cossack Squats
#

Focus: Ankle/Knee/Hip/Groin mobility, core strength, balance

Cossack Squats are a fantastic way to work on mobility and strength at the catch position. This is a difficult exercise to pick up for most people, but it’s extremely rewarding! You’ll want to work on getting better at it over the course of the rowing season - take it slowly and gradually work on pushing your ranges on this a little more every day.

The basic Cossack Squat motion involves an extra-wide stance, squatting down as deep as possible on one leg while keeping heels on the floor, and pointing the other leg out straight to the side with the toes pointing to the ceiling. Transition from one side to the other and sink in on that new side. I find it helpful to hold a weight while doing this (the same weight as from the Halos exercise is usually fine) - this helps counterbalance you and lets you keep a stronger back position while sinking a little deeper.

Cues: [try to add one of these at a time]

Keep your heels on the floor!
Keep a strong back position (chest up, eyes up, no slumping!)
Keep your hips low as you swing across to the other side (activates a better groin stretch)
Get a little more depth by sitting a little lower each time
Get a little more forward ankle compression by rocking your weight forward on each foot.

This video demo from FitnessFAQs.tv is quite good - he does a good job of demonstrating body position cues as well as going through a progression from beginner to more advanced Cossack Squats, although I recommend keeping hips low as you go across to activate the groin stretch whereas he prefers standing up between each rep.

If you’re struggling with the initial variations of the Cossack squats, this page details a few more progressions that might help you get there: https://juanlugofitness.com/cossack-squat/

(Walking) Spiderman with Hip Lift and Overhead Reach
#

Focus: Hamstring/Quadricep/Groin/Thoracic mobility

Walking Spidermans (as designed by Eric Cressey, video demo below) combines a few familiar warmup elements in a dynamic exercise. I would describe it as a lunge (quads/hip flexors/groin), hip lift to hamstring stretch, and an overhead reach (thoracic rotation). This doesn’t have to be done “walking” if space is limited - just come back to a standing position and do the other leg.

The demo below is very straight-forward, although I recommend the overhead reach in the other direction (i.e. rotating towards the front leg as opposed to away from it). This makes the warmup a more similar to the sweep rowing motion.

Cues: Keep your hips low in the lunge, work to find that stretch, and track your overhead reach with your eyes.

Any questions? I’ll be happy to demonstrate these motions over the next few months.

The ORC Rec Guide to Being a Coxswain on the Ottawa River

Wed, 04 Jul 2018 00:00:00 +0000

Created by: Peter Aubin with contributions from Lauren E and myself

Congratulations, you’re in charge. Your rowers expect you to be clear, prepared, and commanding - speak up!

Responsibilities
#

Provide clear, loud, and commanding instructions to rowers
Navigate and steer the boat

Required Items
#

Cox box and headset - found in upstairs office, make sure cox box turns on and headset fits into cox box
Life jacket (Bay 2), whistle and lights (your own)

Delivering Instructions
#

General Principle: Make sure your rowers understand the instruction before doing the action!

On-Land and Stationary
#

The general format is: “Ready to ______, [pause], and ________”
- i.e. “Ready to lift, [pause], and LIFT”
This applies on land and when boat is stationary (i.e.“Ready to row, and row”).

On-Water
#

When in motion, give all instructions “In Two [Strokes]”
- “In two, ______. This is one, [wait for a stroke], two, [wait for a stroke] and ________”.
- i.e. “In two, let it run. This is one [stroke], two [stroke], let it run.”
In case of emergency, call for immediate actions (“LET IT RUN!” or “HOLD WATER!)

From Boathouse to Dock
#

Your crew should be waiting for you at the boat having brought already brought down oars - make sure you have eight rowers
Check to make sure that the bow of the boat faces the bay doors (this affects the direction you swing the boat, you want to be on the dock with bow facing Parliament)
Directions may vary slightly depending on what rack the boat is on (if higher than waist height, rowers can just get underneath, otherwise bear-hug and under is required) - sample below assumes waist height or lower
At any point if there is a delay (e.g. because boats are ahead of you) it is most comfortable for the crew to be waiting with the boat at waist height (i.e. “Down to Waist”)

Specific Instructions
#

Specific Instructions: Boathouse to Dock
#

“Hands on the rack. Ready to pull, and pull.”
“Bunch up bow and stern” (make sure rowers are grouped tightly/shoulder-to-shoulder to reduce load)
“Hands across (bear hug)” (bear hug only applicable when waist height or lower)
“Up an inch, ready and up”. (keep an eye so that the boat does not hit anything above it. Boats are tight)
“Walk it back” (to get to middle of bay) “Up to Waist” (if not at waist level)
“From bow, split under the boat.” (Call out names of people to go under, if you can)
“Hands on your side”
“Up to shoulders on Prime Minister’s side, ready and up”
(check the outside of the bay to avoid collisions) “Heads-up” (loudly)
“Walk it out” (instruct to move right or left if needed to ensure that riggers clear the door)
(When clear of bay door), “Let it run. Up to shoulders on Parliament, ready and up”
“Walk it down”
As rowers reach the ramp, “Swing left” [or right, if for some reason stern is facing outwards]
“Let it run” (at this point bow should be facing Parliament, upstream and parallel to the edge of the dock)

Specific Instructions: Getting the Boat Into the Water and Away
#

“Toes to the edge”
“Up Overhead, ready and up”
“Roll to waist, ready and roll! Reaching out and into the water” (watch the fin of the boat near the stern to make sure it does not catch on the dock)
“Go get your oars, check your oarlocks, seats, and footstops”
While they are getting oars, plug your cox box in and test the speakers/microphone
A coach should assign seats at this point, flag one down if they have not
Rowers should make adjustments to oarlocks/seats/footstops unless dock is busy, in which case they can be made on the water.
“Starboard oars across, [pause] one foot in and down” - wait for rowers to get in, then get in
“Number off from bow when ready”
“Hands on the dock. Lean away. Ready to shove, and shove”
If necessary, “2 seat please push us off the dock” (if any port oars still touching the dock)
Get “bow pair to take a few strokes” to get clear of the docks, then go into warmups

Specific Instructions: Docking and Getting the Boat Out of the Water
#

Under the Macdonald Cartier bridge, “Stern Four drop out” (alternatively, ask Bow Four to drop out if they are less experienced) to slow down the approach to the dock
Try to angle the boat gently into the dock - a sharp approach can cause damage to the bow ball. Give instructions to bow pair or stern pair to help get your angles right.
Ask crew to “lean away from the dock” as you get close
Coxie gets out first
“One foot on the dock, ready and up - starboard blades across”
While rowers are removing blades, remove cox box assembly from boat
“Bunch up bow and stern”
“Right hands across, ready to roll up to waist and UP! Up overheads, ready and UP!”
“From Stern, split to shoulders.”

Specific Instructions: Putting the Boat back into the Boathouse
#

Make sure the stern of the boat goes into the boathouse first - this may involve getting rowers to “turn and face the bow” and “Walk it down” until the stern is in line with the ramp. Then get the rowers to “turn and face the stern”.
“Swing it up the ramp” until the boat is about to reach the bay doors then “Let it run”
“Down to waist on Parliament, ready and down” then “Walk it in”
Once the bow is fully in the boathouse, “Let it run” and “Down to waist, ready and down”
You want to put the boat back on the same racks, so [as necessary] “bear hug” and “from bow, cross under”
[As applicable] “Down to ankles” and “Walk it on” - watching the top of the boat and riggers
“Check for riggers” - the rowers will tell you if the riggers are touching the racks, and then make the appropriate adjustments
“Bow Pair wipe it down, the rest get oars”
Return the cox box, microphone, and any lights back to the office then return for debrief

Steering (adjusting course while boat is in motion)
#

Try to make gradual adjustments for hazards/obstacles while they are still far away
Rudder controls are diagrammed below > they are only effective while the boat is moving with some speed.
You can always get your rowers to assist you - asking for “Hard on Starboard” will help you get towards port etc. Don’t forget to go back to “Even Pressure” when you’re done.
Stay close to shore as much as possible to avoid traffic from cruise boats and power boats

Normal Practice Patterns
#

Warmups are done between the bridges, then technical/drill work while on the Quebec side and power/pyramids on the way back.
Normal stopping places are: before the Alexandra Bridge, after the Macdonald Cartier Bridge, before the Gatineau River, at the tip of Kettle Island, the Airport, and ONEC - try not to stop the boat while in front of marinas or in front of the falls.
You can always consult with coaches or your stroke seat if you have any questions.

Normal Warmups
#

Warmups should be done with all eight, and they should be balanced and in time with each other. If you can see anyone who is out of time, call them out by seat number (“three seat you’re late” etc)
“All eight from the finish, arms only - ready and row” (continue for 20-25 strokes)
“In two, arms and body - this is one [stroke] two [stroke] arms and body” (20-25)
“In two, half-slide - this is one [s], two [s], half-slide. This will normally take you up to the turning point to cross the river- give the rowers a second to adjust feet and grab water, then complete a turn and then continue again at half-slide until you get across (i.e. “From the finish, half-slide, ready and row”)
Once on the Quebec side, you’ll want to start at half slide and then transition into full-slide (i.e. “in two, full-slide, …”)
Once you cross the Macdonald Cartier Bridge, “let it run” to wait for other crews and coaches.

Turns (i.e. while stationary)
#

The majority of turns or spins will be turning the boat 90 degrees to starboard (your right)
“Holding on Star and Tapping on Port, ready and tap”
Continue until pointing in the correct direction
Minor adjustments when stationary can be made by asking bow seat or two seat to tap.

Calling Power Pieces
#

Power pieces and pyramids are a large part of the practice. You should be able to feel the rowers putting power on (let them know if you can’t) and the stroke rate should still feel controlled.
General format is the same: “Hard 10 in two, this is one, two, ten hard - one, two, three …”
Pyramids are sequential power pieces (5on-5off-10on-10-off-15/15/10/10/5/5 etc)
You should count all of the strokes for pieces of ten strokes or shorter - if fifteen or more, count the first five or ten, then give them a warning every five strokes until you count off the last five or ten.
- e.g. for 30 strokes, count off the first ten, “this is fifteen” at fifteen, and count off the last ten

Adjusting for Bad Water or Weather
#

When water is wavy, get rowers to start at half-slide and then go into full slide (if possible, otherwise stay at half-slide)
Try to warn your crew when a large wake is coming in (“wake coming in on starboard”) although you alternatively say “sit up tall and relax your shoulders” to help relax your crew instead of making them tense up.
If you see lightning or hear thunder, regardless of whether a coach is with you or not, turn the boat around to go home.

posts on TanHo.ca

Dry Aging At Home, Episode 1

equipment and setup #

meat #

monitoring #

temperature #

humidity #

tasting notes #

thoughts for next time #

Things I Think You Should Read and Watch

life as a programmer & data scientist #

learning and teaching programming #

technical leadership #

career advice #

specific technologies #

changelog #

Data Science Hangout

Recording #

DSLC Slack: Debugging Netlify Deploys

Question #

Answer #

The Beginner Data Science Programming Book That Doesn't Exist (Yet?)

Hot take: the ideal beginner data science programming book doesn’t exist (yet) #

the ideal book for learning programming and NFL analytics #

Adventures In Scaling Shiny: Lessons Learned Building DynastyProcess

Recording #

Materials #

tidyr pivot trick: names_to -> .value

Scenario #

Past me #

But what if I told you there’s a one-liner for this exact situation? #

Bonus: data.table equivalent #

Full Code #

Effective Logging Strategies

Recording #

Materials #

Debugging Shiny Apps

Recording #

Materials #

Using GitHub To Make Your Work Live Forever

Recording #

blogdown, distill, and personal websites with R

TLDR #

Distill #

Blogdown #

Which one do I choose? #

Setting Up Your Own Shiny Server

Recording #

Eating Habits as Levers

Levers to use towards a caloric deficit #

Wrangling JSON and Lists

Recording #

Web Scraping with rvest

Recording #

Adventures in HTTP Testing for R

Why test? #

Why not skip CRAN testing? #

Storing mock data in a separate repository #

Accessing the mock data #

Capturing the mock data #

Testing the real APIs with GitHub Actions #

Like-Hearted

TLDR: Curating your feed, finding your friend groups, and getting into online arguments can be good #

DSLC Slack: Changing Window Titles in Shiny

Dhiraj asks: #

Answer #

DSLC Slack: Explaining Shiny to Your IT Team

Piranha asks: #

Answer (by me) #

Some followup questions #

DSLC Slack: Things I Learned From Advanced R Book Club

I - Foundations: #

II - Functional Programming #

III - Object Oriented Programming #

IV Metaprogramming #

V Techniques #

Toy Code #

Regatta Cheatsheet

The ORC Rec Guide to Regattas #

Contents #

equipment and setup
#

meat
#

monitoring
#

temperature
#

humidity
#

tasting notes
#

thoughts for next time
#

life as a programmer & data scientist
#

learning and teaching programming
#

technical leadership
#

career advice
#

specific technologies
#

changelog
#

Recording
#

Question
#

Answer
#

Hot take: the ideal beginner data science programming book doesn’t exist (yet)
#

the ideal book for learning programming and NFL analytics
#

Recording
#

Materials
#

Scenario
#

Past me
#

But what if I told you there’s a one-liner for this exact situation?
#

Bonus: data.table equivalent
#

Full Code
#

Recording
#

Materials
#

Recording
#

Materials
#

Recording
#

TLDR
#

Distill
#

Blogdown
#

Which one do I choose?
#

Recording
#

Levers to use towards a caloric deficit
#

Recording
#

Recording
#

Why test?
#

Why not skip CRAN testing?
#

Storing mock data in a separate repository
#

Accessing the mock data
#

Capturing the mock data
#

Testing the real APIs with GitHub Actions
#

TLDR: Curating your feed, finding your friend groups, and getting into online arguments can be good
#

`Dhiraj` asks:
#

Answer
#

`Piranha` asks:
#

Answer (by me)
#

Some followup questions
#

I - Foundations:
#

II - Functional Programming
#

III - Object Oriented Programming
#

IV Metaprogramming
#

V Techniques
#

Toy Code
#

The ORC Rec Guide to Regattas
#

Contents
#

Equipment List
#

Scheduling
#

Derigging and Rigging
#

Trailer Loading
#

Rules of Racing
#

Race Plans
#

Short Description
#

Exercise Details
#

Halos
#

Cossack Squats
#

(Walking) Spiderman with Hip Lift and Overhead Reach
#

Responsibilities
#

Required Items
#

Delivering Instructions
#

On-Land and Stationary
#

On-Water
#

From Boathouse to Dock
#

Specific Instructions
#

Specific Instructions: Boathouse to Dock
#

Specific Instructions: Getting the Boat Into the Water and Away
#

Specific Instructions: Docking and Getting the Boat Out of the Water
#

Specific Instructions: Putting the Boat back into the Boathouse
#