Table of Contents

1  Reproducible Research
1.1  Non-reproducible research
1.2  Why reproducible research
1.3  How to be reproducible in statistics?
1.4  Tools for reproducible research
1.5  Version control using Git
1.5.1  Collaborative research.
1.5.2  Why version control?
1.5.3  Available version control tools
1.5.4  Why Git?
1.5.5  What do I need to use Git?
1.5.6  Basic workflow of Git
1.5.7  Basic Git usage
1.6  Branching in Git
1.6.1  Sample sessions
1.6.2  Etiquettes of using Git and version control systems in general
1.7  Dynamic document using IJulia notebook

Reproducible Research

An article about computational science in a scientific publication is not the scholarship itself, it is merely advertising of the scholarship. The actual scholarship is the complete software development environment and the complete set of instructions which generated the figures.

-- Buckheit and Donoho (1995)

Non-reproducible research

  1. Duke Potti Scandal

  2. Nature Genetics (2015 Impact Factor: 31.616). 20 articles about microarray profiling published in Nature Genetics between Jan 2005 and Dec 2006.

  3. Bible code.

    • Witztum, Rips, and Rosenberg (1994) Equidistant letter sequences in the book of genesis. Statist. Sci., 9(3):429-438.

    • McKay, Bar-Natan, Bar-Hillel, and Kalai (1999) Solving the Bible code puzzle, Statist. Sci., 14(2):150-173.

Why reproducible research

  1. Replicability has been a foundation of science. It helps accumulate scientific knowledge.

  2. Greater research impact.

  3. Better work habit boosts quality of research.

  4. Better teamwork. For you (graduate students), it means better communication with your advisor.

    while true  
    Stud: "that idea you told me to try - it doesn't work!"  
    Prof: "ok. how about trying this instead."
end

    Unless you reproduce the computing environment (algorithms, dataset, tuning parameters), there's no way professor can help you.

How to be reproducible in statistics?

When we publish articles containing figures which were generated by computer, we also publish the complete software environment which generates the figures.

-- Buckheit and Donoho (1995)

A good example: http://stanford.edu/~boyd/papers/admm_distr_stats.html

Tools for reproducible research

  • Version control: Git.
  • Distributing research, e.g., Julia or R packages: github, bitbucket.
  • Dynamic document: IJulia for Julia or RMarkdown for R.
  • Docker container for reproducing a computing environment.
  • Cloud computing tools.

We are going to practice reproducible research now. That is to make your homework reproducible using Git/GitHub, and IJulia.

Version control using Git

If it's not in source control, it doesn't exist.

Collaborative research.

Statisticians, as opposed to closet mathematicians, rarely do things in vacuum.

  • We talk to scientists/clients about their data and questions.
  • We write code (a lot!) together with team members or coauthors.
  • We run code/program on different platforms.
  • We write manuscripts/reports with co-authors.
  • We distribute software so potential users have access to your methods.

Why version control?

  • A centralized repository helps coordinate multi-person projects.
  • Time machine. Keep track of all the changes and revert back easily (reproducible).
  • Storage efficiency.
  • Synchronize files across multiple computers and platforms.
  • github.com is becoming a de facto central repository for open source development.
    E.g., all packages in Julia are distributed through github.com.
  • Advertise yourself thru github.com.

Available version control tools

  • Open source: Git, subversion (aka svn), cvs, mercurial, ...
  • Proprietary: Visual SourceSafe (VSS), ...
  • Dropbox? Mostly for file backup and sharing, limited version control (1 month?), ...

We use Git in this course.

Why Git?

  • History: Initially designed and developed by Linus Torvalds in 2005 for Linux kernel development.
    git is the British English slang for unpleasant person.

I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.

-- Linus Torvalds

  • svn: centralized version control system.
    Git: distributed version control system.

What do I need to use Git?

  • A Git server enabling multi-person collaboration through a centralized repository.

    • github.com: unlimited public repositories, private repositories costs $, academic user can get unlimited private repositories from the Student Developer Pack
    • bitbucket.org: unlimited public repositories, unlimited private repositories for academic account (register for free using your UCLA email)
    • We use github.com in this course for developing and submitting homework

  • Git client on your own machine.

    • Linux: shipped with many Linux distributions, e.g., Ubuntu. If not, install using a package manager, e.g., yum install git on CentOS
    • Mac: install by port install git or other package managers
    • Windows: GitHub for Windows (GUI), TortoiseGIT (is this good?)

Don't totally rely on GUI or IDE. Learn to use Git on command line, which is needed for cluster and cloud computing.

Basic workflow of Git

  • Synchronize local Git directory with remote repository (git pull = git fetch + git merge).
  • Modify files in local working directory.
  • Add snapshots of them to staging area (git add).
  • Commit: store snapshots permanently to (local) Git repository (git commit).
  • Push commits to remote repository (git push).

Basic Git usage

  1. Register for an account on a Git server, e.g., github.com.

  2. Upload your SSH public key to the server.

  3. Identify yourself at local machine, e.g.,

    git config --global user.name "Hua Zhou"
git config --global user.email "huazhou@ucla.edu"

    Name and email appear in each commit you make.

  4. Initialize a project:

    • Create a repository biostat-m280-2018-spring on the server.
    • Clone the repository to your local machine, e.g.,
      git clone git@github.com:Hua-Zhou/biostat-m280-2018-spring.git
      Now you have a local repo of the project.

  5. Working with your local copy.

    • git pull: update local Git repository with remote repository (fetch + merge)
    • git log filename: display the current status of working directory
    • git diff: show differences (by default difference from the most recent commit)
    • git add file1 file2 ...: add file(s) to the staging area
    • git commit: commit changes in staging area to Git directory
    • git push: publish commits in local Git repository to remote repository
    • git reset --soft HEAD~1: undo the last commit
    • git checkout filename: go back to the last commit, discarding all changes made
    • git rm: remove files from git control

Branching in Git

  • Branching in Git.

  • For this course, you need to have two branches:

    • develop for your own development
    • master for releases (homework submission). Note master is the default branch when you initialize the project; create and switch to develop branch immediately after project initialization.

  • Commonly used commands:

    • git branch branchname: create a branch
    • git branch: show all project branches
    • git checkout branchname: switch to a branch
    • git tag: show tags (major landmarks)
    • git tag tagname: create a tag

Sample sessions

  • Clone the project, create a develop branch, where your write solution for HW1.

    # clone the project
git clone git@github.com:UCLA-BIOSTAT-M280-2017-Spring/biostat-m280-2017-HuaZhou.git
# enter project folder
cd biostat-m280-2017-HuaZhou
# what branches are there?
git branch
# create develop branch
git branch develop
# switch to the develop branch
git checkout develop
# create folder for HW1
mkdir hw1
cd hw1
# let's write some code
echo "x = 1" > code.jl
echo "some bug" >> code.jl
# commit the code
git add code.jl
git commit -m "famous x = 1 function"
# push to remote repo
git push

  • Submit and tag HW1 solution to master branch.

    # which branch are we in
git branch
# change to the master branch
git checkout master
# merge develop branch to master branch
git pull origin develop 
# push to the remote master branch
git push
# tag version hw1
git tag hw1
git push --tags

Etiquettes of using Git and version control systems in general

  • Be judicious what to put in repository.

    • Not too less: Make sure collaborators or yourself can reproduce everything on other machines
    • Not too much: No need to put all intermediate files in repository. Make good use of the .gitignore file

  • Strictly version control system is for source files only. E.g. only xxx.tex, xxx.bib, and figure files are necessary to produce a pdf file. Pdf file doesn't need to be version controlled or, if version controlled, doesn't need to be frequently committed.

  • Commit early, commit often and don't spare the horses.

  • Adding an informative message when you commit is not optional. Spending one minute on commit message saves hours later for your collaborators and yourself. Read the following sentence to yourself 3 times:

    Write every commit message like the next person who reads it is an axe-wielding maniac who knows where you live.

Dynamic document using IJulia notebook

  • IPython notebook is a powerful tool for authoring dynamic document, which combines code, formatted text, math, and multimedia in a single document.

  • Jupyter is the current development that emcompasses multiple languages including Julia, Python, and R.

  • Julia uses Jupyter notebook through the IJulia.jl package.

  • In this course, you are required to write your homework reports using IJulia.

  • For each homework, you need to submit your IJulia notebook (.e.g, hw1.ipynb), html (e.g., hw1.html), along with all code and data that are necessary to reproduce the results.

  • You can start with the Jupyter notebook for the lectures.