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
- Look around the code you're writing
- Look for similar patterns in other files
- Use
git blame
and Github Search, find and read commits that added similar code - 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.
- Read opensource.com article about Seneca and Open Source education--they are talking about you!
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
- Readings/Resources
- Download and Install git
- Git Reference
- Visual Git Reference
- Version Control by Example, online book
- Overview of Git Tutorials (many good ones)
- Videos
- Linus on the value of small patches. Learning to use git well requires learning to work in small units of work, and adding them up over time.
- TODO
- Learn git!: Watch video tutorials and Read chapter 3 of Pro Git, etc.
- Work on your 0.1 release. See the instructions on submitting.
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
- Starting Release 0.2
- Picking a bug
- Suggested Projects:
- Advanced Projects:
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.