Merge pull request #2 from dmlond/master

Merge into my fork

Author: DanFaria

README.md

@@ -58,3 +58,8 @@ http://www.ee.surrey.ac.uk/Teaching/Unix/
 * docker https://www.docker.com/
 * docker-machine https://docs.docker.com/machine/
 * docker-compose https://docs.docker.com/compose/
+
+## Vagrant, virtualbox
+
+- vagrant http://vagrantup.com
+- virtualbox http://virtualbox.org

docs/2015-05-11/git/Readme.md

@@ -64,6 +64,8 @@ technology.
 changes in the project file system to descriptions and information about why those changes were made.  Much of the above documentation can be managed by carefully controlling the way you commit changes to files in the project to the git repository, and crafting well designed, informative commit messages to go with each commit.
 * Logical Commits: Researchers might use this by committing changes to analysis code along with new datasets that were produced by running the newly changed code, with a commit message describing how the changes to the code affected the changes to the dataset.
 * Clones and Forks: When you copy/tar/zip your project directory, or push it to Github, you are creating a clone.  Anyone that installs your clone on their machine (untar/unzip/git clone) can use the git command to access its entire life-history documentation, and even revert files to previous states to investigate or use them. They can then adapt the repository to their own uses, commit new changes, etc. without affecting the original repository. In addition, both you and your colleagues retain the potential to push and/or pull changes made in one fork of the repository into any other fork.
+* Citeable Code: github and zenodo have teamed up to allow specific versions of a [git repository to be assigned a DOI](https://guides.github.com/activities/citable-code/) that people can cite. An example of that is [here](https://github.com/naturalis/monophylizer) (notice the DOI badge at the bottom of the README.md).
+* Testable Code: you can make it so that after every push to github, the repository is submitted to a server that runs the tests you have written for your code. This way, users (and yourself) can verify that everything (still) works. An example is [here](https://github.com/naturalis/supersmart) (notice the ''build passing'' badge. Click on it and you can see the test results).
 
 Git Gotchas
 -----------

docs/2015-05-11/local_install/Worksheet.md

@@ -0,0 +1,15 @@
+We are going to try to run [pipeline.sh](https://github.com/dmlond/arangs2015/blob/master/bin/pipeline.sh). Have a look at the script.
+
+- How many values does the `$FASTQS` variable hold?
+- How many values will the `$SAIS` variable hold when running the script? Why?
+- How many times will the `$SAM` variable be assigned a value? Is it the same value? Why?
+- What's the function of the if/else statements, why would they be there?
+- Which programs need to be installed to run pipeline.sh?
+- Which versions of these programs do we need (consult the download* scripts)?
+- Download and (try to) compile these programs. 
+- Are there any libraries missing?
+- If there are missing libraries, try to install these with the package manager (`apt-get`)
+- Make sure the compiled programs are on the `$PATH`.
+- Download the data. If you use the download* scripts for this, where will the data end up?
+- Will the pipeline.sh be able to find the data there? 
+- Does it matter where you run the pipeline?