DPS909 & OSD600 Fall 2018

Week 1

• Course introduction
  • DPS909
  • OSD600
  • How to be successful in this course

• Releases
  • 4 releases, some with multiple bugs/PRs required
  • Chance to work on real code, real projects
  • Big learning curve, lots of time required
  • Amazing chance to gain experience, network, build your skills and resume

• Discussion/Readings
  • Copyright (Copyright in Canada video)
    • IANAL
    • Who created it, "owns" it.
    • Set of exclusive rights granted to the work's creator
    • "The right to copy," to produce or reproduce a work or substantial portion thereof
    • Copyright is automatic when a work is created, you don't have to register it.
    • Copyright in Canada
    • Copyright Guide
    • In a software project, there can be many copyright holders (e.g., many contributors), or all contributors may assign their copyright to the project (e.g., CLA, which we'll cover later)
  • What is Open Source?
    • The Open Source Definition
  • Microsoft buys GitHub for 7.5 Billion - "We're all in on open source"
  • Julia Evans, "How to teach yourself hard things"

• Slack
  • https://seneca-open-source.slack.com
  • Slack, Getting Started
  • Tour the Slack app

• First open technologies and projects we'll be using:
  • node.js
  • node fs module docs
  • filer
  • mocha

Week 2

• Release 0.1 Overview
  • Due Friday Sept 28th
  • node.js
  • node fs module vs. filer
  • synchronous vs. asynchronous functions in JavaScript
  • node's callback function pattern vs. Promises

• Licenses
  • Rights, privileges, responsibilities, etc. applicable to someone other than the work's creator
  • "Terms and Conditions"
  • These must be granted by a copyright holder

• No License
  • What can you do with code you find that has no license?
  • what can I, can't I do?

• Public Domain
  • SQLite, which is now used by literally everybody, see http://www.sqlite.org/famous.html
  • Unlicense

• BSD License
  • Family of Licenses, including 2-Clause BSD, 3-Clause BSD (aka New BDS), 4-Clause BSD
  • "Why you should use a BSD style license for your Open Source Project"
  • BSD Licenses code is usually compatible with other open/closed code, when you want to mix them.
  • Example software projects licensed under the BSD License:
    • Many Google Projects, including V8, Chromium, Go
    • D3.js
    • Django
    • nginx
    • Vi
    • Facebook uses a modified version of the 3-Clause BSD they call [BSD + Patents license]. This has been controversial
      • BSD + Patent
      • PATENTS in React
      • https://code.facebook.com/posts/112130496157735/explaining-react-s-license/
  • Summary:
    • You need to retain the license and copyright notice
    • You can use it commercially or non-commercially (privately)
    • You can distribute it freely
    • You can modify it freely

• Open Source and Code Reading
  • Deep Dive on the node fs module by Safia Abdalla
  • fs.truncate()
    • node.js source for truncate
    • Search results in nodejs/node's test/* directory for JavaScript files including 'truncate'
    • Code Coverage for fs.truncate
    • Filer source for truncate
    • Filer tests for truncate

• Lab 1

Week 3

• Consider Speaking and/or Attending the Free Software and Open Source Symposium (FSOSS).

• Introducing git and GitHub

• Readings/Resources
  • Courses on Lynda
    • Git Essential Training
    • Up and Running with Git and GitHub
  • Books
    • Pro Git
    • Version Control by Example, online book
  • References
    • Git Reference
    • Visual Git Reference
    • Overview of Git Tutorials (many good ones)
    • Github documentation
    • GitHub Desktop

• Filing and Fixing a bug: a cookbook approach
  • set up git and GitHub
    • https://help.github.com/ has lots of great articles to help you. You can also view video guides or read the printed guides
    • setup your username in git
    • setup your email address in git
    • specify which editor git should use, for example you can use vscode
    • setup line endings (CRLF vs. LF) in git
    • setup ssh keys for GitHub
  • In GitHub, create a fork of the repo you want to work on
  • On your computer, clone your forked repo
  • On your computer, add a remote named "upstream" for the original repo (vs. your fork)
  • On GitHub, find or create an Issue for the change you want to make
  • On your computer, create and checkout a branch for your work, e.g., issue-1234 for Issue #1234
  • On your computer, make code changes, test them, add, and commit on your branch. Repeat as necessary.
  • On your computer, push your changes (commits) to your fork (origin)
  • On GitHub, create a Pull Request for your changes to get sent to the upstream repo
  • On your computer, fix any problems pointed out by your reviewer(s), add the file(s), commit, and push again to update your pull request

• Real world examples:
  • Filing, Fixing a bug in Filer
  • Adding a new Feature, Tests, and Docs to Filer - support node's new recursive fs.mkdir in Filer

• Lab 2

Week 4

• Learning Licenses: MIT
  • MIT License
  • The MIT License, Line by Line
  • One of the most widely used licenses in Open Source
  • Like the BSD License, nothing about patents (created before software was patentable in the US)
  • Example software projects licensed under the BSD License:
    • ExpressJS
    • Ruby on Rails
    • AngularJS
    • Atom, Electron
    • Bootstrap
    • node.js
    • Phaser
    • PuTTY
    • Socket.IO

• More Git
  • Git Walkthrough Part I
  • Git Walkthrough Part II
  • Some basic git commands you should make sure you know how to use:
    • git clone - clone an existing repository (i.e., one you've forked on GitHub)
    • git status - check what's happening with your repo, working directory, branch info
    • git add - add a file, files, or folder(s) of file(s)
    • git commit - commit changes in the staging area
    • git log - look back at existing commits
    • git diff - look at the difference between what's in the working directory and staging area, or between two commits
    • git rm - remove a file
    • git mv - move or rename a file
    • git reset - update the staging area, and perhaps working directory, with files from another commit (e.g., HEAD)
    • git checkout - switch to a branch or commit, or create, or get files from a branch/commit

Week 5

• Release 0.2: Hacktoberfest
  • For Tuesday October 9th (Lab 3)
    • First (of 5) PR completed with a Blog Post
    • Submit via https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Student-Submissions
  • Add projects that you think are good for other students to https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Interesting-Open-Source-Projects

• Merging with git
  • Where git branch splits histories apart, git merge brings them back together
  • Understanding DIFFs and Patch files
    • git diff, git show, git log -p, etc. to show DIFFs
    • Pull Requests also have links to get the raw .diff and .patch
    • How to read a DIFF file
  • Types of Merges: Fast Forward, Recursive Merges are the most common
    • --ff-only to force a fast-forward (only the branch pointer is moved, no new commit is created)
    • 3-way merges: two branch commits with a common ancestor (new commit is created with multiple parents)
    • Can have any number of parents though: one of the larges is a 66 commit octopus merge in the Linux kernel
  • How to merge
    • start with a clean working directory
      • commit your work if you can; or
      • stash (git stash list, git stash show, git stash pop)
    • checkout the branch you want to merge into
    • git merge branch_to_merge_into_this_branch
  • Various flags and commands to know:
    • git merge --squash
    • git merge --abort
    • git merge --continue
    • git branch -d
  • Merge Conflicts
    • Conflict markers <<<<<<<<<, =============, >>>>>>>>>>>>
  • Doing big merges in git

Week 6

• Hacktoberfest Updates
  • Add any interesting projects you find/work on to this list on the wiki
  • Update your Info on the submissions wiki page by Monday:
    • Add your Name beside your GitHub username
    • New Pull Request
    • New Blog Post
    • Any Issues you're working on
  • Week 1 Summary

• git rebase branch
  • Replay commits on a new base branch/commit
  • Process goes like this:
    • git finds a common ancestor commit of the branch you're on, and the one you're rebasing onto
    • git calculates DIFFs for each, saves them to disk
    • git checks out the commit you want to branch onto, and begins to replay those diffs one by one
    • if there is a merge conflict, the rebase pauses so you can fix things
    • use git rebase --continue or git rebase --abort to move forward after such a pause
    • use git rebase --skip to ignore the current commit and keep going
  • Never rebase commits that are shared publicly in another repo. Only do it on commits you own locally (e.g., a topic branch you are working on)
  • Don't use rebase to get rid of commits in a public branch, use git revert commit-sha instead to apply an inverse commit
  • If you rebase a branch you've pushed (e.g., for a pull request), when you push, use git push origin branch-name -f (f means force and will overwrite)
  • git rebase -i for interactive rebase
    • shows a script of all commits in reverse order (order they will be replayed). You can hand edit this to remove, re-order, or combine commits
  • You can squash on the same branch by rebasing on HEAD~n where n is how many commits back from HEAD to go

• PRs needing a Rebase
  • https://github.com/filerjs/filer/pull/496
  • https://github.com/filerjs/filer/pull/437
  • https://github.com/filerjs/filer/pull/439
  • https://github.com/filerjs/filer/pull/468
  • https://github.com/filerjs/filer/pull/545