Difference between revisions of "DPS909 & OSD600 Fall 2018"

From CDOT Wiki
Jump to: navigation, search
(→‎Week 11)
Line 340: Line 340:
  
 
== Week 11 ==
 
== Week 11 ==
 +
 +
* Continuous Integration
 +
** Lots of free-for-open-source services: [https://travis-ci.com/ TravisCI], [https://circleci.com/ CircleCI], [https://www.appveyor.com/ AppVeyor]
  
 
* Automating build, test, and deploy steps with Travis CI
 
* Automating build, test, and deploy steps with Travis CI

Revision as of 13:02, 17 November 2018

Week 1

  • Course introduction

Week 2

  • 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

Week 3

  • Consider Speaking and/or Attending the Free Software and Open Source Symposium (FSOSS).
  • 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

Week 4

  • 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

  • Merging with git
    • Where git branch splits histories apart, git merge brings them back together
    • Understanding DIFFs and Patch files
    • 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

  • 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

Week 7

  • Hacktoberfest Week 2
    • 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
  • Rebase Review and Demo

Week 8

  • Hacktoberfest 0.2 Due this Week (Wed Oct 31)
    • Finish all 5 Pull Requests + Blog Posts
    • Write a 6th and final Blog Post about all of your contributions. Include links to the Bugs you fixed and Pull Requests. Talk about what you learned, your growth through the experience, what went well, what you would do differently next time, and your reflections on Hacktoberfest in general.
    • Make sure all PRs and Blog Posts (including 6th conclusion post) are up at https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Student-Submissions
  • 0.3 and 0.4 Releases, Labs 5-10
    • Complete 3 larger PRs in external open source projects + 3 PRs in internal OSD/DPS open source run projects
    • For 0.3, follow a 2 + 1 pattern: either 2 external and 1 internal, or 2 internal and 1 external.
    • For 0.4, follow a 1 + 2 pattern: do the opposite of what you did in 0.3
    • Consider working on a project you began working with during Hacktoberfest, though you aren't limited to this.
    • PRs for 0.3 and 0.4 are about increasing quality vs quantity. You need to work on larger fixes/features than many of you did for Hacktoberfest. If you want to work on small bugs, you'll need to combine them together.
    • Each Monday, a blog post discussing your work from the previous week is due. Link to bugs you are working on, PRs or branches in progress, talk about what you learned, what you're still thinking about, and any plans you have for upcoming weeks.
    • You do not need to complete a PR every week for 0.3 and 0.4; though you will need to make progress each week in order to blog, and to stay on track.
  • Open Source Case Study: Redis
    • Redis (REmote DIctionary Server)
    • https://github.com/antirez/redis - ~175K lines of code
    • Cross-platform, high performance, in-memory, key/value, data structure database server. Written in mostly in C, as well as Tcl and Lua, with front-ends in just about every language and platform.
    • BSD 3-Clause
    • Started in 2009 by Salvatore Sanfilippo (antirez)
    • Since 2015, development has been sponsored by Redis Labs (see https://en.wikipedia.org/wiki/Redis_Labs)
    • Redis is among the most popular NoSQL databases in the world, and the most popular key/value store. It is used by everyone:
      • Twitter
      • Instagram
      • GitHub
      • StackOverflow
      • Pinterest
      • Snapchat
      • Shopify
      • AirBnB
      • Uber
      • Tumblr
      • Slack
      • Medium
      • Imgur
      • Kickstarter
    • Common Use Cases:
      • User Session Cache (e.g., reduce DB lookups for user info, shopping cart data)
      • Full Page Cache (e.g., by URL or route)
      • Queues (e.g., Message Queue, Worker Queue)
      • Counting (e.g., metrics, analytics)
      • Pub/Sub (e.g., chat systems, notifications)
    • Redis Tutorial and Walkthrough: https://try.redis.io/

Week 9

  • OSD & DPS909 Fall 2018 Release 0.3
  • OSD/DPS Fall 2018 Open Source Project Ideas
    • Make sure you have chosen your projects (both new and existing) and have either filed bugs, or found things to work on. Your blog (due today) should discuss and explain what you plan to do over the coming 3 weeks.
    • Spend the time in class talking with people about the projects, filing bugs, doing research, and figuring out your own ways to contribute.

Week 10

Week 11

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_%26_OSD600_Fall_2018&oldid=135951"