Difference between revisions of "DPS909 and OSD600 Fall 2014 Notes"

From CDOT Wiki
Jump to: navigation, search
(Week 5)
(Week 5)
Line 236: Line 236:
 
* Join the irc channel(s) for the project you'll be joining
 
* Join the irc channel(s) for the project you'll be joining
 
* Read the [http://ericsink.com/vcbe/html/git_example.html chapter on git] in "Version Control by Example." Continue to build your knowledge of, and experience with git.
 
* Read the [http://ericsink.com/vcbe/html/git_example.html chapter on git] in "Version Control by Example." Continue to build your knowledge of, and experience with git.
 +
* Find a bug to work on for Release 0.2 and blog about the bug. What is it? How will you approach fixing it? What do you need to learn?

Revision as of 09:03, 1 October 2014

Week 1

  • TODO
    • Create an account on this wiki for yourself (note: requires manual creation)
    • Add your info to the Fall 2014 Open Source Students page.
    • Create a blog (wordpress or blogspot or whatever) and create a feed category or tag called "open source"
    • Read the Blog Guidelines for instructions on how to use your blog in the course
    • Add your blog feed and info to the Open Source@Seneca Planet List so that it appears in the OpenSource@Seneca Planet
    • Pick one Closed and one Open license/EULA, and read them from start to finish. Pick 3 things that struck you, blog about it and your reactions to the readings this week.
    • Begin learning how to use IRC for communication. We'll cover this in detail next week, but it's better to get started early.

Week 2

  • Release 0.1
    • Option 1 (for those new to open source):
      • Implement du in Filer
      • You will learn git, github, JavaScript, node.js, npm, Filer, code review
      • You must fix the bug yourself and have it reviewed by another student *and* review another student's implementation (i.e., do a pull request against another student's fork, and vice versa)
    • Option 2 (for those with more experience):
      • Find and fix a bug in one of the projects listed above which is of an equal size to Option 1
      • Releases 0.2, 0.3, and 0.4 will be like Option 2 for everyone
  • TODO
    • Sign-up for a case study and begin researching and immersing yourself - 2014 Open Source Project Case Study
    • Reading for Wednesday's class: The Cathedral and the Bazaar. Please be prepared to discuss next class.
    • Figure out which option you will do for Release 0.1 and begin working on it.
    • Sign-up for an Open Source Case Study
    • Write an introductory blog post about the case study project you chose, and the project that you will be researching.

Week 3

  • Discussion of The Cathedral and the Bazaar
    • "The Linux community seems to resemble a great babbling bazaar"
    • "Linus Torvald's style of development - Release early. Release often. And listen to your customers."
    • "Every good work of software starts by scratching a developer's personal itch."
    • "Good programmers know what to write. Great ones know what to rewrite (and reuse)."
    • "Plan to throw one away; you will, anyhow (Fred Brooks)"
    • "You often don't really understand the problem until after the first time you implement a solution."
    • "When you lose interest in a program, your last duty is to hand it off to a competent successor."
    • "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."
    • Linus' Law: "Given enough eyeballs, all bugs are shallow." or "Debugging is parallelizable" and "More users find more bugs...because adding more users adds more different ways of stressing the program."
    • "Somebody finds the problem...and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge."
      • In the cathedral-view bugs are "tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals."
      • "In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena - or, at least, that they turn shallow pretty quick when exposed to a thousand eager co-developers pounding on every single new release."
    • "If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource."

Week 4

  • Introducing Git
    • Client Server (SVN) and Distributed (Git)
    • Snapshots vs. versioned files.
    • Checksums, SHA-1
    • File States:
      • Untracked (not known to git)
      • Tracked: modified, staged, committed
    • The staging area
  • Basic Git Commands and Concepts
    • git help <command>
    • git init
    • git clone
    • git add
    • git commit, git commit -m, git commit -a
    • git rm
    • git mv
    • git status
    • git log
    • git diff, git diff --staged
    • .gitignore
    • Branches
      • HEAD, master
      • git checkout, git checkout -b
      • git branch, git branch -a, git branch -d, git branch --merged, git branch --contains
      • git merge
      • git rebase
    • Remotes
      • origin, origin/branch
      • git remote
      • git remote add
      • git fetch
      • git pull
      • git push
    • Github, Pull Requests

Week 5

  • Continuing with Git
    • branches
    • remotes
    • workflows
  • Connecting with Communities on irc
    • Moznet (irc.mozilla.org)
    • Freenode
    • irccloud - https://www.irccloud.com/
    • Recommended Channels
      • #filer (moznet)
      • #makedrive (moznet)
      • #appmaker (moznet)
      • #brackets (freenode)
  • Guest Lecture on Wednesday with Mozilla's Kate Hudson @k88hudson
    • Discussion of Webmaker Mobile projects
    • How to get started setting it up, contributing, finding good bugs
    • How she got started in open source, and what it's like to work full time

TODO

  • Continue blogging at least once per week, write about your work on your bugs, things you're learning, issues you have, etc.
  • Pick a project and find bug(s) to work on for release 0.2
  • Join the irc channel(s) for the project you'll be joining
  • Read the chapter on git in "Version Control by Example." Continue to build your knowledge of, and experience with git.
  • Find a bug to work on for Release 0.2 and blog about the bug. What is it? How will you approach fixing it? What do you need to learn?