Merge pull request #430 from nextflow-io/minor_fixes_advanced

typo: minor fixes to the advanced training

docs/advanced/configuration.md

@@ -25,7 +25,7 @@ This gives us two complications:
 
 There may be some configuration values that you will want applied on all runs for a given system. These configuration values should be written to `~/.nextflow/config`.
 
-For example - you may have an account on a HPC system and you know that you will always want to submit jobs using the SLURM scheduler when using that machine and always use the Singularity container engine. In this case, your `~/.nextflow/config` file may include:
+For example - you may have an account on an HPC system and you know that you will always want to submit jobs using the SLURM scheduler when using that machine and always use the Singularity container engine. In this case, your `~/.nextflow/config` file may include:
 
 ```groovy
 process.executor = 'slurm'

docs/advanced/grouping.md

@@ -155,7 +155,7 @@ MapReads( samples, reference )
 | view
 ```
 
-This is easy enough, but the `groupTuple` operator has to wait until all items are emitted from the incoming queue before it is able to reassemble the output queue. If even one read mapping job takes a long time, the processing of all other samples is held up. We need a way of signalling to nextflow how many items are in a given group so that items can be emitted as early as possible.
+This is easy enough, but the `groupTuple` operator has to wait until all items are emitted from the incoming queue before it is able to reassemble the output queue. If even one read mapping job takes a long time, the processing of all other samples is held up. We need a way of signalling to Nextflow how many items are in a given group so that items can be emitted as early as possible.
 
 By default, the `groupTuple` operator groups on the first item in the element, which at the moment is a `Map`. We can turn this map into a special class using the `groupKey` method, which takes our grouping object as a first parameter and the number of expected elements in the second parameter.
 

docs/advanced/metadata.md

@@ -129,7 +129,7 @@ map { id, reads ->
 
     To quickly sanity-check a groovy expression, try the [Groovy web console](https://groovyconsole.appspot.com/)
 
-We are almost there, but we still don't have the "treatment" metadata captured in our meta map. The treament is encoded in this example in the name of the parent directory relative to the reads. Inside the map object, the reads are a list of two UnixPath objects. These objects implement the [`java.nio.Path`](https://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html) interface, which provides us many useful methods, including `getParent()`.
+We are almost there, but we still don't have the "treatment" metadata captured in our meta map. The treatment is encoded in this example in the name of the parent directory relative to the reads. Inside the map object, the reads are a list of two UnixPath objects. These objects implement the [`java.nio.Path`](https://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html) interface, which provides us many useful methods, including `getParent()`.
 
 We can call the `getParent()` method on each of the paths like so:
 

docs/advanced/operators.md

@@ -252,7 +252,7 @@ branch { meta, reads ->
 }
 ```
 
-We may want to emit a slightly different element than the one passed as input. The `branch` operator can (optionally) return a _new_ element to an channel. For example, to add an extra key in the meta map of the tumor samples, we add a new line under the condition and return our new element. In this example, we modify the first element of the `List` to be a new list that is the result of merging the existing meta map with a new map containing a single key:
+We may want to emit a slightly different element than the one passed as input. The `branch` operator can (optionally) return a _new_ element to a channel. For example, to add an extra key in the meta map of the tumor samples, we add a new line under the condition and return our new element. In this example, we modify the first element of the `List` to be a new list that is the result of merging the existing meta map with a new map containing a single key:
 
 ```groovy linenums="1"
 branch { meta, reads ->
@@ -483,7 +483,7 @@ The input channel has two elements. For each element in the input channel, we re
 
 !!! exercise
 
-    The `flatten` operation only "unfolds" one layer from the retuned collection. Given this information, what do you expect the following workflow to return?
+    The `flatten` operation only "unfolds" one layer from the returned collection. Given this information, what do you expect the following workflow to return?
 
     ```
     workflow {
@@ -636,7 +636,7 @@ If the contents of the input channel is a file, its _contents_ are appended to t
 
     In the example below, we include a line of groovy to define a variable `article` which is used in the interpolated script string. This is a convenient way to avoid crowding the final string block with too much logic.
 
-    This line includes two Groovy synax features:
+    This line includes two Groovy syntax features:
 
     1. The [ternary operator](https://docs.groovy-lang.org/latest/html/documentation/core-operators.html#_ternary_operator) - a terse if/else block
     2. The [find operator](https://docs.groovy-lang.org/latest/html/documentation/core-operators.html#_find_operator) `=~`

docs/advanced/structure.md

@@ -9,7 +9,7 @@ There are three directories in a Nextflow workflow repository that have a specia
 
 ## `./bin`
 
-The `bin` directory (if it exists) is always added to the `$PATH` for all tasks. If the tasks are performed on a remote machine, the directory is copied across to the new machine before the task begins. This Nextflow feature is designed to make it easy to include accessory scripts directly in the workflow without having to commit those scripts into the container. This feature also ensures that the scripts used inside of the workflow move on the same revision schedule as the workflow itself.
+The `bin` directory (if it exists) is always added to the `$PATH` for all tasks. If the tasks are performed on a remote machine, the directory is copied across to the new machine before the task begins. This Nextflow feature is designed to make it easy to include accessory scripts directly in the workflow without having to commit those scripts into the container. This feature also ensures that the scripts used inside the workflow move on the same revision schedule as the workflow itself.
 
 It is important to know that Nextflow will take care of updating `$PATH` and ensuring the files are available wherever the task is running, but will not change the permissions of any files in that directory. If a file is called by a task as an executable, the workflow developer must ensure that the file has the correct permissions to be executed.
 
@@ -208,7 +208,7 @@ workflow {
 }
 ```
 
-Why might this be helpful? You can add extra classes to the metadata which can be computed from the existing metadata. For example, we might want want to grab the adapter prefix:
+Why might this be helpful? You can add extra classes to the metadata which can be computed from the existing metadata. For example, we might want to grab the adapter prefix:
 
 ```groovy linenums="1"
 def getAdapterStart() {