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

From CDOT Wiki
Jump to: navigation, search
(→‎Week 2)
Line 94: Line 94:
 
** Sign-up for an [[2014 Open Source Project Case Study|Open Source Case Study]]
 
** Sign-up for an [[2014 Open Source Project Case Study|Open Source Case Study]]
 
** Write an introductory '''blog post''' about the case study project you chose, and the project that you will be researching.
 
** Write an introductory '''blog post''' about the case study project you chose, and the project that you will be researching.
 +
 +
== Week 3 ==
 +
 +
* Discussion of [http://www.firstmonday.org/ojs/index.php/fm/article/view/578/499 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."
 +
 +
* Release 0.1 - Getting Started
 +
** Case Study: implementing [http://pubs.opengroup.org/onlinepubs/7908799/xcu/wc.html wc]
 +
*** "%d %d %d %s\n", <newlines>, <words>, <bytes>, <file>
 +
*** '''Fork it''' - https://github.com/js-platform/filer
 +
*** '''Clone it'''
 +
*** '''Setup Dev Environment''' - https://github.com/js-platform/filer/blob/develop/CONTRIBUTING.md
 +
**** [http://nodejs.org/ node.js]
 +
**** <code>npm install</code>
 +
**** <code>npm install -g grunt-cli</code>
 +
*** '''Run the Tests''' - https://github.com/js-platform/filer/blob/develop/CONTRIBUTING.md#tests
 +
**** <code>grunt test</code>
 +
**** <code>grunt test-browser</code> and browse to http://localhost:1234/tests/
 +
*** '''Find similar code''' - tests, code, docs
 +
**** [https://github.com/js-platform/filer#cat sh.cat() docs]
 +
**** [https://github.com/js-platform/filer/search?q=.cat&type=Code sh.cat() code and tests]
 +
*** '''Write Tests First'''
 +
**** Consider the cases we care about with wc
 +
**** Study how the [https://github.com/js-platform/filer/blob/e9eae3549b1c95043d4a2c8ca5646e61ac17e37f/tests/spec/shell/cat.spec.js cat tests work]
 +
**** Copy/Paste/Modify/
 +
 +
* '''TODO'''
 +
** Install git http://git-scm.com/
 +
** Create a [https://github.com/ Github account] if you haven't already
 +
** Fork and clone Filer and start on Release 0.1 if you haven't already (due in 2 weeks).  Blog about your progress, what you learned, what you still need to learn
 +
** Read chapters 1 & 2 of [http://git-scm.com/book Pro Git], be ready to discuss next week.

Revision as of 11:01, 15 September 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."
  • TODO
    • Install git http://git-scm.com/
    • Create a Github account if you haven't already
    • Fork and clone Filer and start on Release 0.1 if you haven't already (due in 2 weeks). Blog about your progress, what you learned, what you still need to learn
    • Read chapters 1 & 2 of Pro Git, be ready to discuss next week.
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_and_OSD600_Fall_2014_Notes&oldid=105704"