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

From CDOT Wiki
Jump to: navigation, search
(Week 12, 13, 14)
(Week 12, 13, 14)
 
(2 intermediate revisions by the same user not shown)
Line 336: Line 336:
 
== Week 12, 13, 14 ==
 
== Week 12, 13, 14 ==
  
* The :9090 problem: https://twitter.com/brianloveswords/status/531865386527248384
+
* [https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 Initial Git Commit]
 +
 
 +
* The :9090 problem: '''"Convert :9090 into http://localhost:9090 automatically"'''
 +
** https://twitter.com/brianloveswords/status/531865386527248384
 
** Let's try and change web browsers to do this
 
** Let's try and change web browsers to do this
 
** Browser vendors probably won't take the change, but it's a great way to learn
 
** Browser vendors probably won't take the change, but it's a great way to learn
 
** Platform Change vs. Extensions
 
** Platform Change vs. Extensions
 +
** A clue http://christian.legnitto.com/blog/2014/05/05/firefox-29s-best-feature/
  
 
* Open Source Browsers
 
* Open Source Browsers
Line 346: Line 350:
 
*** [https://blog.mozilla.org/addons/2014/06/05/how-to-develop-firefox-extension/ Writing Extensions]
 
*** [https://blog.mozilla.org/addons/2014/06/05/how-to-develop-firefox-extension/ Writing Extensions]
 
*** [http://dxr.mozilla.org/mozilla-central/source/ Source Code Browser (DXR)]
 
*** [http://dxr.mozilla.org/mozilla-central/source/ Source Code Browser (DXR)]
** Chromium
+
** Chromium/Chrome
 
*** [https://chromium.googlesource.com/chromium/src.git Source Code]
 
*** [https://chromium.googlesource.com/chromium/src.git Source Code]
 
*** [http://www.chromium.org/developers/how-tos Dev Docs]
 
*** [http://www.chromium.org/developers/how-tos Dev Docs]
 
*** [http://www.chromium.org/developers/how-tos/build-instructions-windows Building on Windows with VS]
 
*** [http://www.chromium.org/developers/how-tos/build-instructions-windows Building on Windows with VS]
 
*** [http://dev.chromium.org/developers/how-tos/get-the-code Getting the Code]
 
*** [http://dev.chromium.org/developers/how-tos/get-the-code Getting the Code]
** Chrome (closed, but uses Chromium)
 
 
*** [https://developer.chrome.com/extensions/getstarted Building Chrome Extensions]
 
*** [https://developer.chrome.com/extensions/getstarted Building Chrome Extensions]
 +
** WebKit
 +
*** [https://www.webkit.org/ Main project page]
 +
*** [https://www.webkit.org/building/checkout.html Getting the code]
 +
*** [https://www.webkit.org/building/build.html Building the code]
 
** [https://konqueror.org/Konqueror Konqueror]
 
** [https://konqueror.org/Konqueror Konqueror]
 
*** [https://konqueror.org/investigatebug/ Fixing bugs]
 
*** [https://konqueror.org/investigatebug/ Fixing bugs]
Line 359: Line 366:
 
*** [http://lynx.isc.org/ Main site]
 
*** [http://lynx.isc.org/ Main site]
 
*** [http://lynx.isc.org/current/lynx_help/lynx_url_support.html URL Support in Lynx]
 
*** [http://lynx.isc.org/current/lynx_help/lynx_url_support.html URL Support in Lynx]
 +
 
'''TODO'''
 
'''TODO'''
 
* Pick a browser to work on
 
* Pick a browser to work on
 
* Get the code, setup a dev environment, build it
 
* Get the code, setup a dev environment, build it
 
* Write a blog post about the experience, with a screenshot of the build running
 
* Write a blog post about the experience, with a screenshot of the build running

Latest revision as of 11:29, 24 November 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

Weeks 5,6

  • 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
    • IRC usernames for Webmaker on the board:
      • k88hudson
      • thisandagain

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?

Week 7

TODO

  • Release 0.2 due Friday - blog post with details about your bug, how you fixed it, link to your pull request, etc.
  • Start reading more deeply about JS

Week 8, 9

TODO

  • Read the various articles linked in the class notes, blog about your reaction to what you're reading.
  • FSOSS 2014 Report due this Friday, Oct 31
  • Start work on your 0.3 release.
  • Read Brackets Issue 9529 for Wednesday

Week 10

TODO

  • Work on release 0.3, due November 14th.

Week 11

  • Designing for Participation
    • Question: "How to build a software production pipeline that can strategically benefit from a vibrant open source community?"
    • Tension between growing capacity vs increasing cost
    • Schedule driven, client-requirements driven, and open involvement
    • The role of partnerships, shared ownership, distributed control and responsibility

TODO

  • Start scoping your 0.4 release. Pick your bugs, follow up on review comments from previous bugs, etc.
  • Pay attention to your blogging. Remember, a blog post per week is what is expected. It can be about any of your work.

Week 12, 13, 14

TODO

  • Pick a browser to work on
  • Get the code, setup a dev environment, build it
  • Write a blog post about the experience, with a screenshot of the build running