• Update README [https://github.com//issues/13 ]
• Add License
• Add bibliography. Should make a bibliography file with refs like tidyverse, edgeR, 1-2-3 limma papers.
• Maybe add in some comparative examples to show how tidy style can save on writing large code blocks
• Improve exercises [ https://github.com//issues/12]
• Could perhaps have an additional_Info.Rmd file in the vignettes folder with things we won't have time to include but that could be useful to show (e.g. how to use tidybulk if starting from tables of counts & sample information, bar plots, pathway/GO analyses...)
• Shorten to 1 hr & update timings (have shortened it a bit but may need to adjust more)
• Add image at beginning to show RNA-seq workflow & where this fits

Add URLs to workshop's README file

1. Pkgdown website
2. Docker image
3. Build status badge:
   https://github.com///workflows/.github/workflows/basic_checks.yaml/badge.svg

The test code you gave me

counts_de_pasilla <- tidyHeatmap::pasilla %>%
mutate(type=str_replace(type, "-", "_")) %>%
test_differential_abundance(
.sample=sample,
.transcript=symbol,
.abundance=count normalised adjusted,
.formula = ~ 0 + condition + type,
.contrasts = c("conditiontreated - conditionuntreated"))

use str_replace

however stringr is not in DESCRIPTION library nor suggest

When running the following code form the course notebook to scale counts:

counts_scaled <- counts_tt %>% scale_abundance(factor_of_interest = dex)

I get the following error:

Error in scale_abundance(., factor_of_interest = dex) : 
  unused argument (factor_of_interest = dex)

This does not occur when using the legacy versions on the docker image provided. Please could you advise whether there is a workaround for the scaling of counts with the up to date version of tidybulk? This would be useful for future projects! Thanks!

Heya, I just found I do not seem to get the same result with the base R and tidybulk code for the keep_variable genes e.g.

these gene ids

counts_scaled %>% 
	
	# extract 500 most variable genes
	keep_variable( .abundance = counts_scaled, top = 500)

are not the same as these gene ids

dgList <- SE2DGEList(airway)
group <- factor(dgList$samples$dex)
keep.exprs <- filterByExpr(dgList, group=group)
dgList <- dgList[keep.exprs,, keep.lib.sizes=FALSE]
dgList <- calcNormFactors(dgList)
logcounts <- cpm(dgList, log=TRUE)
var_genes <- apply(logcounts, 1, var)
select_var <- names(sort(var_genes, decreasing=TRUE))[1:500]
highly_variable_lcpm <- logcounts[select_var,]

and using your code on the tidybulk website (below) I get same 500 as with base R but again different to tidybulk

s <- rowMeans((logcounts-rowMeans(logcounts))^2)
o <- order(s,decreasing=TRUE)
x <- logcounts[o[1L:500],,drop=FALSE]

I thought it might be to do with the filtering so I tried adding in filter as below (I should probably add that filter into the workshop code) but I'm still getting about 23 genes different to the base R code

counts_scaled %>% 
filter(!lowly_abundant) %>% 
keep_variable( .abundance = counts_scaled, top=500)

Do you know why that might be?

As discussed we should see if we can improve the exercises (the current ones are not final just some to get started)

• This paper has some good Tips for exercises (below) I think we could try to follow.

• R for Data Science book is an example of using a variety of exercises e.g. here: https://r4ds.had.co.nz/data-visualisation.html#aesthetic-mappings

For Tip 1 we could aim for ~6 sets of exercises in total for a 2x50 min workshop (think that's the time we've got) where each set takes 1-2 mins. Maybe 2-3 exercises per set - 1 easy, others harder. For Tip 3 we should aim to have a variety of exercise types.

Tip 1: Use formative assessment every 10–15 minutes
Instructors always want to get through more material than time allows, so we often teach at the speed at which we can talk rather than the speed at which people can learn. Having learners do something every 10–15 minutes slows us down to the speed at which people can learn rather than the speed at which we can talk. It also keeps them engaged and gives us and them feedback on whether they have actually understood.

In-class checks like this are called formative assessments. Good ones take only a minute or two to complete so that they don't derail the flow of the lesson and have an unambiguous correct answer so that they can be checked in large classes. Popular kinds of formative assessment in programming classes include:

• Answer a multiple choice question.
• Write a few lines of code.
• Predict what the code on the screen will do when it runs.
• Contribute the next line of code.
• Label a diagram of a data structure.
• Trace the order in which statements are evaluated.

Starting with a formative assessment that reviews a previous lesson is a good way to signal that class has started, and having learners recall older material before tackling something new improves learning outcomes [11]. Similarly, ending the class with such an exercise gives learners a sense of how far they have progressed.

Some formative assessments should be designed in advance; in fact, they should be designed before the lesson content is written so that they can act as goalposts [6]. However, they can also be created on the fly to incorporate and respond to learners' questions and confusions. For example, after writing and presenting a few lines of code, an instructor can ask what would happen if something was added or modified. If learners make different predictions, the instructor can then ask them to debate the outcomes as a form of ad hoc peer instruction [7].

Tip 3: Use a variety of exercise types
The final rule in [7] said, "Don't just code," and it bears elaboration here. Most programming classes rely primarily on code-and-run exercises in which learners write software that behaves in a tightly specified way. To keep learners engaged and to give them opportunities to practice other skills and higher-level reasoning, you should also use the following:

Parsons Problems, which give them the lines of code needed to solve a problem but in jumbled order [12, 13, 14]. Parsons Problems reduce cognitive load by allowing learners to focus on control flow without simultaneously having to recall syntax.

Multiple choice questions whose wrong answers have been chosen to probe for specific misconceptions. For example, learners who have worked with spreadsheets may believe that after executing a = 10, b = a, and a = 20, the value of b will be 20.

Matching and ranking problems in which they match terms from one column to definitions in another, put predefined labels on a diagram, or sort items according to some criteria (e.g., most likely to least likely).

Debugging, completion, and extension exercises in which learners must fix, finish, or extend an existing program. These all model authentic tasks (i.e., the kinds of things programmers spend most of their time doing in real life).

Tracing execution order or tracing values, in which the learner lists the order in which the statements in a program are executed or the values that one or more variables take on as the program runs, which are essential program comprehension skills.

Code reviews in which learners score a program against a marking guide supplied by the instructor in order to learn how to find flaws in code. Learners start with a perfect score and lose points for false positives, as well as false negatives so that they don't simply mark every statement as being wrong in all possible ways.

Need to either create the bioc2020 docker tag on Dockerhub, remove this tag from your Dockerfile, or change the tag to one that exists on Dockerhub (eg bio2020).