Difference between revisions of "DPS909 & OSD600 Fall 2017"

From CDOT Wiki
Jump to: navigation, search
(→‎Week 10)
Line 339: Line 339:
  
 
** Discussion:
 
** Discussion:
−
** Why read source code at all?
+
*** Why read source code at all?
−
** Imagine having to fix a bug in a multi-million line program, where do you start?
+
*** Imagine having to fix a bug in a multi-million line program, where do you start?
−
** Top-down, bottom-up, something else?
+
*** Top-down, bottom-up, something else?
−
** Is adding a feature different from fixing a bug?
+
*** Is adding a feature different from fixing a bug?
  
−
** Goal Oriented
+
* 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
 
** Build system and Tests play a role in helping you do experiments
 
*** Experiments (can you "break" the code?)
 
*** Experiments (can you "break" the code?)
 
*** Tests as Documentation (can you alter a test in order to get the tests to fail?)
 
*** 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
 
** "Reading" by Search vs. Linear Progression
 
** Source Code Indexers
 
** Source Code Indexers

Revision as of 20:41, 11 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)
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_%26_OSD600_Fall_2017&oldid=129763"