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

From CDOT Wiki
Jump to: navigation, search
(Introduction)
Line 1: Line 1:
== Introduction ==
+
== Week 1 ==
  
 
* Course introduction
 
* Course introduction
Line 44: Line 44:
 
** 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.
 
** 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|IRC]] for communication.  We'll cover this in detail next week, but it's better to get started early.
 
** Begin learning how to use [[Irc|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
 +
*** [http://daringfireball.net/projects/markdown/ Markdown 1.0.1 (2004)]
 +
*** [http://daringfireball.net/projects/markdown/license Markdown's license]
 +
*** [http://en.wikipedia.org/wiki/Markdown Markdown is used everywhere, by everyone]
 +
*** [http://blog.codinghorror.com/responsible-open-source-code-parenting/ calling out a maintainer (2009)]
 +
*** [http://blog.codinghorror.com/the-future-of-markdown/ call for standardization of Markdown (2012)]
 +
*** [http://rumproarious.com/2012/10/29/markdown-the-spec/ failed attempt to standardize (2012)]
 +
*** [https://twitter.com/gruber/status/507590050880561153 podcast of Gruber discussing Markdown]
 +
*** [http://blog.codinghorror.com/standard-flavored-markdown/ a second attempt, Standard Markdown (2014)]
 +
*** [https://twitter.com/markdown Standard Markdown rejected]
 +
*** [http://spinhalf.net/omg-markdown/ the difficulty with standardizing]
 +
*** [https://twitter.com/codinghorror/status/507680549712838656 naming fallout]
 +
*** [http://blog.codinghorror.com/standard-markdown-is-now-common-markdown/ a third attempt, Common Markdown (2014)]
 +
 +
* Discussion of Class Projects
 +
** Filer
 +
** MakeDrive
 +
** Brackets, Nimble
 +
** Appmaker
 +
** Mobile Appmaker
 +
 +
* Release 0.1
 +
** [https://github.com/js-platform/filer/issues/277 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)
 +
 +
* '''TODO'''
 +
** Sign-up for a case study and begin researching and immersing yourself - [[2014 Open Source Project Case Study]]
 +
** Reading: [http://www.firstmonday.org/ojs/index.php/fm/article/view/578/499 The Cathedral and the Bazaar]

Revision as of 12:48, 5 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

  • Discussion of Class Projects
    • Filer
    • MakeDrive
    • Brackets, Nimble
    • Appmaker
    • Mobile Appmaker
  • Release 0.1
    • 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)