DPS909 and OSD600 Fall 2014 Notes
Week 1
- Course introduction
- Question: What is Open Source? Why work on Open Source as a student?
- Success in this course requires:
- Willingness to be lost and not panic
- Curiosity
- Being driven, persistence
- Willingness to ask for help
- Willingness to give others help
- Independent learning
- Doing more, much more, than the bare minimum
- What are Seneca and Seneca students capable of accomplishing? Some examples
- Intro to open source
- 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
- Open/Closed Licenses
- Discussion of findings in license readings from week 1
- Case Study: Markdown and open licensing, open standards, forking, blogging, and Twitter
- Markdown 1.0.1 (2004)
- Markdown's license
- Markdown is used everywhere, by everyone
- Example: Markdown for documentation - https://github.com/antirez/redis-doc/pull/417
- calling out a maintainer (2009)
- call for standardization of Markdown (2012)
- failed attempt to standardize (2012)
- podcast of Gruber discussing Markdown
- a second attempt, Standard Markdown (2014)
- Standard Markdown rejected
- the difficulty with standardizing
- naming fallout
- a third attempt, Common Markdown (2014)
- ...and finally http://commonmark.org
- Winer's open email to Gruber, with parallels to RSS/Atom
- Discussion of Class Projects: enabling browser based cloud sharing
- Filer - https://github.com/js-platform/filer
- MakeDrive - https://github.com/mozilla/makedrive, http://blog.humphd.org/introducing-makedrive/
- Brackets - http://brackets.io/
- Nimble - https://github.com/mozilla/nimble.webmaker.org
- Appmaker - https://github.com/mozilla-appmaker/appmaker
- Mobile Appmaker - https://github.com/mozillafordevelopment/mobile-appmaker/
- 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
- Option 1 (for those new to open source):
- 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."
- Release 0.1 - Getting Started
- Case Study: implementing wc
- "%d %d %d %s\n", <newlines>, <words>, <bytes>, <file>
- Fork it - https://github.com/js-platform/filer
- Clone it - http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Cloning-an-Existing-Repository
- Setup Dev Environment - https://github.com/js-platform/filer/blob/develop/CONTRIBUTING.md
- Run the Tests - https://github.com/js-platform/filer/blob/develop/CONTRIBUTING.md#tests
-
grunt test
-
grunt test-browser
and browse to http://localhost:1234/tests/
-
- Find similar code - tests, code, docs
- Write Tests First
- Consider the cases we care about with wc
- Study how the cat tests work
- Study how other open source implementations work: wc.c
- Copy/Paste/Modify/
- Possible implementation
- Case Study: implementing wc
- 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.