Difference between revisions of "DPS909 & OSD600 Fall 2017"

From CDOT Wiki
Jump to: navigation, search
(→‎Week 2)
m (→‎Week 5)
 
(43 intermediate revisions by 2 users not shown)
Line 64: Line 64:
 
** [https://www.ic.gc.ca/eic/site/cipointernet-internetopic.nsf/eng/wr03719.html Copyright in Canada]
 
** [https://www.ic.gc.ca/eic/site/cipointernet-internetopic.nsf/eng/wr03719.html Copyright in Canada]
 
** [https://www.ic.gc.ca/eic/site/cipointernet-internetopic.nsf/eng/h_wr02281.html Copyright Guide]
 
** [https://www.ic.gc.ca/eic/site/cipointernet-internetopic.nsf/eng/h_wr02281.html Copyright Guide]
−
** Copyright lasts the life of the author + 50 years
 
 
** 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., [https://en.wikipedia.org/wiki/Contributor_License_Agreement CLA], which we'll cover later)
 
** 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., [https://en.wikipedia.org/wiki/Contributor_License_Agreement CLA], which we'll cover later)
  
Line 71: Line 70:
 
** "Terms and Conditions"
 
** "Terms and Conditions"
 
** These must be granted by a copyright holder   
 
** These must be granted by a copyright holder   
 +
 +
* No License
 +
** What can you do with code you find that has no license?
 +
** [https://choosealicense.com/no-license/ what can I, can't I do?]
  
 
* Public Domain
 
* Public Domain
 
** [http://www.sqlite.org/copyright.html SQLite], which is now used by literally everybody, see http://www.sqlite.org/famous.html
 
** [http://www.sqlite.org/copyright.html SQLite], which is now used by literally everybody, see http://www.sqlite.org/famous.html
 
** [http://unlicense.org/ Unlicense]
 
** [http://unlicense.org/ Unlicense]
−
 
−
* No License
 
−
** What can you do with code you find that has no license?
 
−
** [https://choosealicense.com/no-license/ what can I, can't I do?]
 
  
 
* Consider some proprietary/closed End User License Agreements (EULA)
 
* Consider some proprietary/closed End User License Agreements (EULA)
Line 111: Line 110:
 
*** You can use it commercially or non-commercially (privately)
 
*** You can use it commercially or non-commercially (privately)
 
*** You can distribute it freely
 
*** You can distribute it freely
−
*** You an modify it freely
+
*** You can modify it freely
 +
 
 +
* [[DPS909/OSD600 Fall 2017 Lab 2 | Lab 2]]
 +
 
 +
== Week 3 ==
 +
 
 +
* Learning Licenses: MIT
 +
** [https://opensource.org/licenses/MIT MIT License]
 +
** 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:
 +
*** [http://rubyonrails.org/ Ruby on Rails]
 +
*** [https://aframe.io/ A-Frame]
 +
*** [https://angularjs.org/ AngularJS]
 +
*** [https://atom.io/ Atom], [https://electron.atom.io/ Electron]
 +
*** [http://getbootstrap.com/ Bootstrap]
 +
*** [http://brackets.io/ Brackets]
 +
*** [http://jquery.com/ jQuery]
 +
*** [https://nodejs.org/ node.js]
 +
*** [https://github.com/photonstorm/phaser Phaser]
 +
*** [https://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY]
 +
*** [https://socket.io/ Socket.IO]
 +
 
 +
* What is a bug?
 +
** Unit of Work in Open Source
 +
** Many projects have [https://twitter.com/orta/status/908757672845070336?s=03 lots of bugs]
 +
** Steps To Reproduce (STR)
 +
** Metadata (OS, versions, other context)
 +
** Issue vs. Pull Request
 +
** Labels
 +
 
 +
** Let's look at some bugs
 +
*** [https://github.com/aframevr/aframe/issues A-Frame Issues on GitHub]
 +
*** [https://github.com/mozilla/thimble.mozilla.org/issues Thimble Issues on GitHub]
 +
*** [https://bugzilla.mozilla.org/ Mozilla's Bugzilla]
 +
*** [https://github.com/mozilla/ Mozilla ORG on GitHub]
 +
** Some interesting example bugs:
 +
*** [https://github.com/salomonelli/best-resume-ever/issues/54 Internationalize Best Resume Ever]
 +
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=1379442 An example of a good-first-bug in DevTools]
 +
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=1400148 Recent Firefox fix for nsCursor(-1)]
 +
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=1396794 Dead code removal in FlacFrameParser::DecodeHeaderBlock]
 +
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=38437 Hostile bugs filed by angry users]. cf. [https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Bug Etiquette], [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines Bug Writing Guidelines]
 +
*** [http://blog.humphd.org/why-good-first-bugs-often-arent/ Dealing with the iPhone X "notch" in CSS standard], see [http://stephenradford.me/removing-the-white-bars-in-safari-on-iphone-x/ examples]
 +
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=765645 RESOLVED WONTFIX]
 +
** [http://blog.humphd.org/fixing-a-bug-in-tensorboard/ Bug Triage].  [https://github.com/facebook/react/issues/10738 Example bug that needs Triage].
 +
 
 +
** "Good First Bug"
 +
*** [http://blog.humphd.org/why-good-first-bugs-often-arent/ The good and bad of "Good First Bug"]
 +
*** Mozilla GitHub ORG [https://github.com/search?q=org%3Amozilla+label%3Agood-first-bug&state=open&type=Issues&utf8=%E2%9C%93 good-first-bug] and [https://github.com/search?q=org%3Amozilla+label%3Agood-first-bug&state=open&type=Issues&utf8=%E2%9C%93 goodfirstbug] and [https://github.com/search?q=org%3Amozilla+label%3Agood-first-bug&state=open&type=Issues&utf8=%E2%9C%93 "good first bug"]
 +
*** [http://bugs.firefox-dev.tools/?easy&tool=all Mozilla DevTools "easy" Issues]
 +
*** [https://www.joshmatthews.net/bugsahoy/?unowned=1&simple=1 Bugs Ahoy! unowned, simple bugs from Bugzilla]
 +
*** [https://bugzilla.mozilla.org/buglist.cgi?keywords=good-first-bug%2C%20&keywords_type=allwords&resolution=---&emailtype1=substring&query_format=advanced&emailassigned_to1=1&email1=nobody Mozilla Bugzilla Unassigned Good First Bugs] 
 +
 
 +
* '''Write a Blog post''': read [https://opensource.org/licenses/MIT MIT License] followed by [https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html The MIT License, Line by Line], and blog about '''3 things''' you learned or found interesting, which perhaps differed from what you understood in your own reading of the license.
 +
* [[DPS909/OSD600 Fall 2017 Lab 3 | Lab 3]]
 +
 
 +
== Week 4 ==
 +
 
 +
* Facebook, React, Apache, BSD+Patents, MIT
 +
** https://www.theregister.co.uk/2017/07/17/apache_says_no_to_facebook_code_libraries/
 +
** https://ma.tt/2017/09/on-react-and-wordpress/
 +
** https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/
 +
** https://ma.tt/2017/09/facebook-dropping-patent-clause/amp/
 +
 
 +
* Mozilla
 +
** Started in 1998 by former Netscape employees, see [https://www.youtube.com/watch?v=4Q7FTjhvZ7Y Code Rush] documentary
 +
** [https://opensource.org/licenses/MPL-2.0 Mozilla Public License (MPL)] ([https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2) in plain English])
 +
** [https://www.mozilla.org/en-US/about/manifesto/ Mozilla Manifesto]
 +
** [https://developer.mozilla.org/ MDN]
 +
** [https://bugzilla.mozilla.org/ Bugzilla]
 +
** [https://github.com/mozilla/ Mozilla@GitHub]
 +
 
 +
* [[DPS909/OSD600_0.1_Release|0.1 Release]]
 +
* [[DPS909/OSD600 Fall 2017 Lab 4 | Lab 4]]
 +
 
 +
== Week 5 ==
 +
 
 +
* Register for [http://fsoss.ca FSOSS 2017] at table outside CS office at lunch time.  $25 per student, includes lunch + swag.
 +
 
 +
* 0.1 Release
 +
** Advice: '''you''' have to make things happen
 +
** If you don't have your bugs assigned yet, please come see me, talk to me on Slack, or email me ASAP.
 +
** Make sure you have reached out to the community around your bugs (irc, Slack, Mattermost, GitHub, mailing list, etc.)
 +
** Please add all your bugs/pull requests to [[DPS909 & OSD600 Fall 2017 Bug List]]
 +
*** Help one another, learn from one another, inspire one another: [http://www.danepstein.ca/its-time-to-fix-open-source-bugs/ Dan Epstein], [https://michaelpierreblog.wordpress.com/2017/09/29/the-search-for-bugs-and-contribution-to-the-open-source-community/ Michael Pierre], [https://medium.com/seanprashad/first-contact-a28cfe776840 Sean Prashad], [http://assmith2017.blogspot.com/2017/10/bugs-on-open-source.html Azusa Shimazaki], [http://mylyfeincode.blogspot.com/2017/09/finding-bug-is-harder-than-you-think.html Jiel Selmani]
 +
 
 +
* Learning Licenses: GPL
 +
** [https://www.gnu.org/philosophy/free-sw.en.html Free Software], [http://www.fsf.org/ FSF], [https://www.gnu.org/ GNU]
 +
** [https://www.gnu.org/licenses/copyleft.en.html Copyleft], compare to permissive licenses like BSD, MIT
 +
*** "Copyleft thus uses copyright law to accomplish the opposite of its usual purpose: instead of imposing restrictions, it grants rights to other people, in a way that ensures the rights cannot subsequently be taken away." [https://en.wikipedia.org/wiki/GNU_General_Public_License Wikipedia]
 +
** [https://opensource.org/licenses/gpl-license GPL License]
 +
*** [https://opensource.org/licenses/GPL-2.0 GPL-2.0] ([https://tldrlegal.com/license/gnu-general-public-license-v2 in plain English])
 +
*** [https://opensource.org/licenses/GPL-3.0 GPL-3.0] ([https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) in plain English]
 +
** Key Ideas
 +
*** Free to use, modify (see below), redistribute, study, copy
 +
*** Binary distributions must also make source code available (e.g., [https://www.linksys.com/us/support-article?articleNum=114663 Linksys], [https://github.com/edent/BMW-OpenSource BMW])
 +
*** You can modify GPL code and not publish your changes. But if you release your modified binary, you must make source available.
 +
*** You can sell GPL licensed code, and so can anyone else.
 +
*** You can't sublicense GPL code: it has to stay GPL
 +
*** GPL3 is more compatible with other open licenses than GPL2
 +
** Example software projects licensed under the GPL Licenses:
 +
*** [https://www.audacityteam.org/ Audacity]
 +
*** [https://www.drupal.org/ Drupal]
 +
*** [https://www.gnu.org/software/emacs/ emacs]
 +
*** [https://www.kernel.org/ Linux Kernel]
 +
*** [https://gcc.gnu.org/ gcc]
 +
*** [https://notepad-plus-plus.org/ Notepad++]
 +
*** [https://wordpress.org/ WordPress]
 +
*** [https://git-scm.com/ git]
 +
 
 +
* '''Introducing [http://git-scm.com/ git]'''
 +
** [[DPS909 & OSD600 Fall 2017 - Git Walkthrough | Git Walkthrough - Basics]]
 +
 
 +
* '''Readings/Resources'''
 +
** Courses on [http://www.senecacollege.ca/lynda/ Lynda]
 +
*** [https://www.lynda.com/Git-tutorials/Git-Essential-Training/100222-2.html?srchtrk=index%3a0%0alinktypeid%3a2%0aq%3agit%0apage%3a1%0as%3arelevance%0asa%3atrue%0aproducttypeid%3a2 Git Essential Training]
 +
*** [https://www.lynda.com/Git-tutorials/Up-Running-Git-GitHub/409275-2.html?srchtrk=index%3a0%0alinktypeid%3a2%0aq%3agit%0apage%3a1%0as%3arelevance%0asa%3atrue%0aproducttypeid%3a2 Up and Running with Git and GitHub]
 +
** Books
 +
*** [http://git-scm.com/book Pro Git]
 +
*** [http://www.ericsink.com/vcbe/index.html Version Control by Example, online book]
 +
** References
 +
*** [http://gitref.org/ Git Reference]
 +
*** [http://marklodato.github.com/visual-git-guide/index-en.html Visual Git Reference]
 +
*** [http://sixrevisions.com/resources/git-tutorials-beginners/ Overview of Git Tutorials (many good ones)]
 +
*** [http://help.github.com/ Github documentation]
 +
*** [https://desktop.github.com/ GitHub Desktop]
 +
 
 +
* [[DPS909/OSD600 Fall 2017 Lab 5 | Lab 5]]
 +
 
 +
== Week 6 ==
 +
 
 +
* Register for [http://fsoss.ca FSOSS 2017] at table outside CS office at lunch time.  $25 per student, includes lunch + swag.
 +
 
 +
* '''0.1 Release due in a few weeks (Oct 20)'''
 +
** Please add all your bugs/pull requests to [[DPS909 & OSD600 Fall 2017 Bug List]]
 +
** Work on your bugs, ask for help, help each other.  Don't wait for things to happen, make them happen.
 +
 
 +
* '''Git and GitHub Workflow'''
 +
 
 +
# '''Fork''' the project's repo.  We'll refer to this as the '''upstream''' repo.
 +
# '''Clone''' your '''Fork''''ed repo locally.  We'll refer to this as your '''origin''' (see below). <code>git clone <git-url></code>
 +
# '''Add''' a '''remote''' for the '''upstream''' repo: <code>git remote add upstream <git-url></code>
 +
# Confirm your remotes (you will need '''origin''' and '''upstream'''): <code>git remote -v</code>
 +
# '''Setup''' your dev environment (e.g., <code>npm install</code>, <code>pip install ...</code>, build, etc.).
 +
# '''Switch''' to your '''master''' branch: <code>git checkout master</code>
 +
# '''Update''' your '''master''' branch with what's on the '''upstream''' repo's '''master''': <code>git pull upstream master</code>
 +
# '''Create''' a '''branch''' (sometimes called a '''Topic Branch''') for your current work.  Every bug, every experiment, everything you do gets its own branch: <code>git checkout -b branch-name master</code>
 +
# '''Fix''' your code, '''add''' and '''commit''' your work on your topic '''branch''': <code>git commit -m "Fixing ..."</code>
 +
# '''Push''' your '''branch''' to your '''origin''': <code>git push origin <branch-name></code>
 +
# '''Create''' a '''Pull Request''' (PR) against the '''upstream''' repo on GitHub.  If you're fixing a bug (e.g., Issue 1234) say that in the description: <code>Fixing #1234: ...</code>.  Make sure you write a nice description of the fix, and how to test/confirm it.
 +
# '''Fix''' any issues you hear back from reviewers by editing your branch, '''add''', '''commit''', and '''push''' again to the same branch on your origin: <code>git push origin <branch-name></code>.  Your changes will get added to the pull request
 +
# '''Communicate''' with the reviewers and let them know what you've done: <code>I fixed x, y, and z.  Please review this again</code>.
 +
# '''Repeat''' until you fix all the issues they find in your code.
 +
# Once they '''merge''' your branch, you can go back to your '''master''' and '''pull''' in those changes.  You won't ever merge into '''master''' manually.
 +
 
 +
* [[DPS909/OSD600 Fall 2017 Lab 6/7 | Lab 6/7]]
 +
 
 +
== Week 7, 8, 9 ==
 +
 
 +
* '''Changes to Semester'''
 +
** Removal of Release 0.3 from Graded Work. You will only be expected to complete two releases instead of three: 0.1 and 0.2.
 +
** Grading will now be as follows:
 +
*** Release 0.1 - 35% (up from 25%)
 +
*** Release 0.2 - 35% (up from 25%)
 +
*** Blog - 15% (no change)
 +
*** Labs - 15% (up from 10%)
 +
** Due Dates
 +
*** Release 0.1 due by Tues Nov 28
 +
*** Release 0.2 and any outstanding Labs due by midnight Fri Jan 5th
 +
** Revised Class schedule:
 +
*** Tues Dec 19, final in-class session together
 +
*** Thurs Dec 21, final on-line lab
 +
*** Jan 2-5, no formal class time together.  Complete outstanding labs, release work.  I'll be available online only via Slack, Email, GitHub, etc.
 +
 
 +
* '''TODO'''
 +
** Complete and Submit [[DPS909/OSD600_0.1_Release|0.1 Release]] by next Tues Nov 28th.
 +
** Update [[DPS909 & OSD600 Fall 2017 Bug List]] with any new bugs you've done since we were apart
 +
** Start thinking about/taking to Dave about what you'll do for your second release.  We'll discuss next week.
 +
 
 +
* Three Questions:
 +
** '''What's a victory you've had already?'''  Bug you fixed? Project you contributed to? Tech you mastered?  Something you learned that used to be hard?
 +
** '''What's something you're finding tricky?''' Something we should cover in class? Something you have to do for a bug, a tool that you don't fully understand, an issue with some process?
 +
** '''What's an open source goal you have for yourself before the end of term?'''  Project you want to contribute to?  Technique you want to master?  Community you want to join?  Something you want to learn/accomplish?
 +
 
 +
* Continuous Integration (CI)
 +
** Automate and Test everything
 +
** Have bots integrate, verify, and test all parts of a project every time you make a change.  For both large and small changes.
 +
** Revert changes that "break the build"
 +
** Produce "nightly" or "staging" style build artifacts the community can test against
 +
** Automate deployment tasks per commit
 +
** Make it less painful for a large community to work on the same code without sacrificing stability.
 +
 
 +
* Open Source CI
 +
** Most projects use one of [https://travis-ci.com/ TravisCI], [https://circleci.com/ CircleCI], [https://www.appveyor.com/ AppVeyor], etc.
 +
** https://twitter.com/kelseyhightower/status/932654629648719872 - there is no one right way to do this, just a million variations you'll encounter in the wild.
 +
** Free for Open Source Projects
 +
** Integrates with GitHub, build per commit or pull request, reports back to GitHub PRs.
 +
** Used for Building, Testing, Linting, and Deployment
 +
 
 +
* TravisCI
 +
** See [https://docs.travis-ci.com/user/getting-started/ Getting Started] and [https://docs.travis-ci.com/user/for-beginners/ Core Concepts]
 +
** You need an automated setup, build, and test system for your project.
 +
** Create an Account with TravisCI and Enable an Integration for your GitHub repo.
 +
** TravisCI is configured for a project via a ''travis.yml'' file
 +
** The ''travis.yml'' file tells TravisCI how to setup a virtual container to build/test your code, and which steps to use in order to determine if things are working
 +
** Example 1: Thimble
 +
*** https://github.com/mozilla/thimble.mozilla.org/blob/master/.travis.yml
 +
*** https://github.com/mozilla/brackets/blob/master/.travis.yml
 +
*** https://travis-ci.org/mozilla/thimble.mozilla.org
 +
*** https://travis-ci.org/mozilla/brackets
 +
*** https://bramble.mofostaging.net/en-US/
 +
** Example 2: Activity Stream
 +
*** https://github.com/mozilla/activity-stream/blob/master/.travis.yml
 +
*** https://travis-ci.org/mozilla/activity-stream
 +
** Example 3: Firefox JavaScript Debugger
 +
*** https://github.com/devtools-html/debugger.html/blob/master/.travis.yml
 +
*** https://travis-ci.org/devtools-html/debugger.html
 +
 
 +
* [[DPS909/OSD600 Fall 2017 Lab 8 | Lab 8]]
 +
* [[DPS909/OSD600 Fall 2017 Lab 9 | Lab 9]]
 +
* [[DPS909/OSD600 Fall 2017 Lab 10 | Lab 10]]
 +
* [[DPS909/OSD600 Fall 2017 Release 0.2 | Release 0.2]]
 +
* [https://github.com/humphd/learn-travis Learn Travis Walkthrough repo]
 +
 
 +
== Week 10 ==
 +
 
 +
* '''Code Reading'''
 +
 
 +
** Discussion:
 +
*** Why read source code at all?
 +
*** Imagine having to fix a bug in a multi-million line program, where do you start?
 +
*** Top-down, bottom-up, something else?
 +
*** Is adding a feature different from fixing a bug?
 +
 
 +
* DOs and DON'Ts
 +
** DO approach things with optimism.  You can do this, don't start by being overwhelmed
 +
** DON'T get bogged down in details (at first)
 +
** DO open a million tabs, skim through things fast, start to narrow your focus
 +
** DON'T try to understand everything
 +
** DO formulate questions: questions to research in the code (who calls this? where is this defined?), questions to ask devs
 +
** DON'T be afraid to start down different paths in parallel.  Walk away when you get frustrated, come at it again from a new angle
 +
 
 +
** Goal Oriented vs. For Enjoyment
 +
** Build system and Tests play a role in helping you do experiments
 +
*** Experiments (can you "break" the code?)
 +
*** Tests as Documentation (can you alter a test in order to get the tests to fail?)
 +
** Debuggers, Breakpoints, Logging, even <code>printf</code> are your friends
 +
** "Reading" by Search vs. Linear Progression
 +
** Source Code Indexers
 +
** Find "footholds" for climbing by looking at parallel bugs (same component, similar feature design, bugs in similar code)
 +
 
 +
** Source Code Archaeology
 +
** Closed Bugs/PRs/Issues help us understand a package of changes, why they happened, which files/lines were changed, who was involved, and when they happened.
 +
** History of a file
 +
** History of a Line: "blame" (e.g., <code>git blame</code>)
 +
** Parallel Implementations (e.g., competing projects, implementations in other languages, forked projects)
 +
 
 +
* Open Source Browsers
 +
** '''WebKit''': [https://trac.webkit.org/browser WebKit Trac], [https://bugs.webkit.org/ Bugzilla]
 +
** '''Chromium''': [https://cs.chromium.org/ Search] or [https://chromium.googlesource.com/chromium/src.git Browse], [https://bugs.chromium.org/p/chromium/issues/list Bugs]
 +
** '''Mozilla''': [https://dxr.mozilla.org/mozilla-central/source/ Mozilla DXR], [https://bugzilla.mozilla.org/ Bugzilla]
 +
 
 +
* Case Studies
 +
** <code>document.cookie</code>: [https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie MDN docs]
 +
** <code>text_transform: capitalize</code>: [https://drafts.csswg.org/css-text-3/#text-transform CSS spec for text-transform]
 +
** <code>video.volume = newVolume;</code>: [https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/volume MDN docs], [https://html.spec.whatwg.org/#dom-media-volume HTML Spec on media volume]
 +
 
 +
* [[DPS909/OSD600 Fall 2017 Lab 11 | Lab 11]]
 +
 
 +
== Week 11 ==
 +
 
 +
* git loose ends
 +
** merge vs. squash.  What they do, when to use, when not to, common workflows
 +
** squashing example with https://github.com/mozilla/brackets/pull/900
 +
** rebase example with merge conflict https://github.com/mozilla/brackets/pull/850
 +
** cherry-pick example with upstream fixes https://github.com/adobe/brackets/commit/baf964e123a5b0a8c34ef3dc58e657c2c75d7b7e,  https://github.com/adobe/brackets/commit/f08ef99dc9b1384bc72ae42c5e17d20254d18ed6
 +
 
 +
* Discussions
 +
** [https://twitter.com/dan_abramov/status/936427676579004416?s=03 Open Source and Work Opportunities]
 +
** [https://twitter.com/search?src=typd&q=%22looking%20glass%22%20firefox Looking Glass] and the [https://www.cnet.com/news/mozilla-backpedals-after-mr-robot-firefox-misstep/?ftag=COS-05-10aaa0g reaction], and [https://blog.mozilla.org/firefox/update-looking-glass-add/ response]
 +
 
 +
* Finally, we return to our first question:
 +
** "What is open source?"
 +
** What do you think now?
 +
** How has your answer stayed the same/changed?
 +
** What are your next steps in open source now that you've gotten started?
 +
** [https://github.com/blog/2480-github-s-technology-predictions-for-2018 GitHub's 2018 predictions]:
 +
 
 +
<pre>
 +
Open source will keep climbing the stack
  
−
* Lab 2 - will be done online, and will involve compiling Firefox from source. Details will be posted later this week.
+
A decade ago, Linux was a big deal. Now it’s standard. Back in the day, companies like Amazon, Google, and Microsoft were forced to build their own, proprietary tools because no other software existed to meet their needs. Many of these frameworks have since been open sourced—and other open source technologies, like Kubernetes, are becoming integral to developers' workflows. This shift is changing what companies are investing in, making open source software traditional software's biggest competitor.
 +
</pre>

Latest revision as of 22:08, 30 December 2017

Resources for DPS909 & OSD600

Week 1

  • Some questions:
    • What brought you to this course?
    • When you hear "open source," what comes to mind?
    • On a scale from 1 (not at all) to 5 (very)...
      • How comfortable are you working with technology you've never seen before?
      • How likely are you to stick with a problem when it gets hard to solve?
      • How curious are you about how things work?
      • How likely are you to ask for help when you get stuck?
      • How likely are you to pause your own work in order to help someone else who is stuck?
      • How comfortable are you as a writer?
      • How self-motivated are you?
      • How self-directed are you?
  • How to have Success in this course:
    • Willingness to be lost and not panic
    • Willingness to put yourself out there, jump in
    • Curiosity
    • Being driven, persistence
    • Willingness to ask for help
    • Willingness to give others help
    • Independent learning
    • Doing more than the bare minimum
  • Mozilla
    • Browsers (Firefox, Servo)
    • Languages (JavaScript, C++, Node, Python, Rust, CSS, HTML, ...)
    • Tools (Dev Tools, DXR, build systems, automation)
    • QA, Automated Tests
    • Extensions
    • Localization
    • Documentation
    • Accessibility
    • Teaching and Learning (Thimble)
    • Web technology

Week 2

  • Let's talk about Copyright and Open Source Licenses
      • IANAL: "I Am Not A Lawyer"
      • We're going to explore licensing from the POV of a developer participating in open projects
  • Copyright
    • 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)
  • 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

  • What is a bug?
    • Unit of Work in Open Source
    • Many projects have lots of bugs
    • Steps To Reproduce (STR)
    • Metadata (OS, versions, other context)
    • Issue vs. Pull Request
    • Labels

Week 4

Week 5

  • Register for FSOSS 2017 at table outside CS office at lunch time. $25 per student, includes lunch + swag.
  • Learning Licenses: GPL
    • Free Software, FSF, GNU
    • Copyleft, compare to permissive licenses like BSD, MIT
      • "Copyleft thus uses copyright law to accomplish the opposite of its usual purpose: instead of imposing restrictions, it grants rights to other people, in a way that ensures the rights cannot subsequently be taken away." Wikipedia
    • GPL License
    • Key Ideas
      • Free to use, modify (see below), redistribute, study, copy
      • Binary distributions must also make source code available (e.g., Linksys, BMW)
      • You can modify GPL code and not publish your changes. But if you release your modified binary, you must make source available.
      • You can sell GPL licensed code, and so can anyone else.
      • You can't sublicense GPL code: it has to stay GPL
      • GPL3 is more compatible with other open licenses than GPL2
    • Example software projects licensed under the GPL Licenses:

Week 6

  • Register for FSOSS 2017 at table outside CS office at lunch time. $25 per student, includes lunch + swag.
  • 0.1 Release due in a few weeks (Oct 20)
    • Please add all your bugs/pull requests to DPS909 & OSD600 Fall 2017 Bug List
    • Work on your bugs, ask for help, help each other. Don't wait for things to happen, make them happen.
  • Git and GitHub Workflow
  1. Fork the project's repo. We'll refer to this as the upstream repo.
  2. Clone your Fork'ed repo locally. We'll refer to this as your origin (see below). git clone <git-url>
  3. Add a remote for the upstream repo: git remote add upstream <git-url>
  4. Confirm your remotes (you will need origin and upstream): git remote -v
  5. Setup your dev environment (e.g., npm install, pip install ..., build, etc.).
  6. Switch to your master branch: git checkout master
  7. Update your master branch with what's on the upstream repo's master: git pull upstream master
  8. Create a branch (sometimes called a Topic Branch) for your current work. Every bug, every experiment, everything you do gets its own branch: git checkout -b branch-name master
  9. Fix your code, add and commit your work on your topic branch: git commit -m "Fixing ..."
  10. Push your branch to your origin: git push origin <branch-name>
  11. Create a Pull Request (PR) against the upstream repo on GitHub. If you're fixing a bug (e.g., Issue 1234) say that in the description: Fixing #1234: .... Make sure you write a nice description of the fix, and how to test/confirm it.
  12. Fix any issues you hear back from reviewers by editing your branch, add, commit, and push again to the same branch on your origin: git push origin <branch-name>. Your changes will get added to the pull request
  13. Communicate with the reviewers and let them know what you've done: I fixed x, y, and z. Please review this again.
  14. Repeat until you fix all the issues they find in your code.
  15. Once they merge your branch, you can go back to your master and pull in those changes. You won't ever merge into master manually.

Week 7, 8, 9

  • Changes to Semester
    • Removal of Release 0.3 from Graded Work. You will only be expected to complete two releases instead of three: 0.1 and 0.2.
    • Grading will now be as follows:
      • Release 0.1 - 35% (up from 25%)
      • Release 0.2 - 35% (up from 25%)
      • Blog - 15% (no change)
      • Labs - 15% (up from 10%)
    • Due Dates
      • Release 0.1 due by Tues Nov 28
      • Release 0.2 and any outstanding Labs due by midnight Fri Jan 5th
    • Revised Class schedule:
      • Tues Dec 19, final in-class session together
      • Thurs Dec 21, final on-line lab
      • Jan 2-5, no formal class time together. Complete outstanding labs, release work. I'll be available online only via Slack, Email, GitHub, etc.
  • TODO
    • Complete and Submit 0.1 Release by next Tues Nov 28th.
    • Update DPS909 & OSD600 Fall 2017 Bug List with any new bugs you've done since we were apart
    • Start thinking about/taking to Dave about what you'll do for your second release. We'll discuss next week.
  • Three Questions:
    • What's a victory you've had already? Bug you fixed? Project you contributed to? Tech you mastered? Something you learned that used to be hard?
    • What's something you're finding tricky? Something we should cover in class? Something you have to do for a bug, a tool that you don't fully understand, an issue with some process?
    • What's an open source goal you have for yourself before the end of term? Project you want to contribute to? Technique you want to master? Community you want to join? Something you want to learn/accomplish?
  • Continuous Integration (CI)
    • Automate and Test everything
    • Have bots integrate, verify, and test all parts of a project every time you make a change. For both large and small changes.
    • Revert changes that "break the build"
    • Produce "nightly" or "staging" style build artifacts the community can test against
    • Automate deployment tasks per commit
    • Make it less painful for a large community to work on the same code without sacrificing stability.

Week 10

  • Code Reading
    • Discussion:
      • Why read source code at all?
      • Imagine having to fix a bug in a multi-million line program, where do you start?
      • Top-down, bottom-up, something else?
      • Is adding a feature different from fixing a bug?
  • DOs and DON'Ts
    • DO approach things with optimism. You can do this, don't start by being overwhelmed
    • DON'T get bogged down in details (at first)
    • DO open a million tabs, skim through things fast, start to narrow your focus
    • DON'T try to understand everything
    • DO formulate questions: questions to research in the code (who calls this? where is this defined?), questions to ask devs
    • DON'T be afraid to start down different paths in parallel. Walk away when you get frustrated, come at it again from a new angle
    • Goal Oriented vs. For Enjoyment
    • Build system and Tests play a role in helping you do experiments
      • Experiments (can you "break" the code?)
      • Tests as Documentation (can you alter a test in order to get the tests to fail?)
    • Debuggers, Breakpoints, Logging, even printf are your friends
    • "Reading" by Search vs. Linear Progression
    • Source Code Indexers
    • Find "footholds" for climbing by looking at parallel bugs (same component, similar feature design, bugs in similar code)
    • Source Code Archaeology
    • Closed Bugs/PRs/Issues help us understand a package of changes, why they happened, which files/lines were changed, who was involved, and when they happened.
    • History of a file
    • History of a Line: "blame" (e.g., git blame)
    • Parallel Implementations (e.g., competing projects, implementations in other languages, forked projects)

Week 11

  • Finally, we return to our first question:
    • "What is open source?"
    • What do you think now?
    • How has your answer stayed the same/changed?
    • What are your next steps in open source now that you've gotten started?
    • GitHub's 2018 predictions:
Open source will keep climbing the stack

A decade ago, Linux was a big deal. Now it’s standard. Back in the day, companies like Amazon, Google, and Microsoft were forced to build their own, proprietary tools because no other software existed to meet their needs. Many of these frameworks have since been open sourced—and other open source technologies, like Kubernetes, are becoming integral to developers' workflows. This shift is changing what companies are investing in, making open source software traditional software's biggest competitor.
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_%26_OSD600_Fall_2017&oldid=130379"