University of Toronto, Winter 2010

INF1006, Section 0103: Information Management for Software (an Information Workshop)

Basics | Schedule and Readings: 1, 2, 3, 4, 5, 6 | Assignments | Software | Bibliography

The Basics

Time and Place:Tuesdays, 9 am to noon, in Bissel Rm. 310 (first class in Rm. 417)
The Instructor: Yuri Takhteyev
Email:yuri.takhteyev at utoronto.ca
Please write from your utoronto email account and put "inf1006" in the subject of the message. Expect two business days turn around time. If you do not receive a reply within this period, please resend your message.
Office hours: 2-3 pm on Mondays or by appointment, iSouth, Rm 328
Students are encouraged to make use of office hours.
Telephone: 416 946 3809
Prerequisites: INF1001 and INF1003
The course welcomes students without prior technical experience beyond INF1003. Students without extensive technical experience may in fact find it easier to reflect on their encounter with the technical material. Students who are unsure whether they are prepared for this course, however, are encouraged to discuss their situation with the instructor as early as possible.

Course Description

While we often recognize software as a crucial tool of information management, we less often think of it as itself an object of information management: content that can be organized, archived, searched, accessed, read, referenced, and re-used. Software developers, however, work with software as exactly this kind of content, using techniques to manage it. Understanding their practices in regards to software-as-information can open up new perspectives on information management more broadly and may give us a glimpse of what might become the mainstream information management practices of tomorrow. After all, many of today’s information management tools were originally built by software developers to manage the information objects they themselves work with. We will dedicate much of our attention to understanding the informational properties of source code — the textual representation of software. We will compare source code to other forms of digital content, considering the difficulties arising from the source code’s dual nature as a technical artifact that must “work” and a text that can be read by human programmers. We will seek to understand a wide range of systems involved in management of software source code, from concrete technical tools (e.g., version-control applications) to social systems, such as, for examples, different approaches to licensing code and the different institutions that enable production of free / open source software.

Schedule and Readings

Since this is a short course, time is of essense.

All assigned readings are available either on the web or on Blackboard. Paper copies will likely also be available on reserve in the Inforum.

Joel Spolsky's essays are available in form of chapters in a book. However, all the essays can also be read on Spolsky's website:

The following two books are available in several formats (HTML, PDF) on their websites:

Assigned "readings" also include videos and software tools. We will approach them as interactive "texts" that can be read and discussed. In some cases I will suggest specific tasks that you can try to better understand how those tools work.

Please note that the readings vary substantial in length and difficulty. Some are fairly heavy. Others are just few pages long. Have a quick look at all the readings when you plan your week.

weekclassreadings/software/videos
1 Tuesday
Mar. 1

"Machines Whose Medium of Construction is Text"

Class slides are here.

Readings:

  • Downey 2010, ch. 1 ("The Way of the Program") and 2 ("Variables, Expressions, and Statements"), Appendix A ("Debugging")
  • Fogel 2006, ch. 3 (p. 38–39)
  • Spolsky 2004, ch. 3 and ch. 10

In-class software exercises:

  • Python
2 Tuesday
Mar. 8

Reading and Using Code

Readings:

Exercises (do at home, before class):

3 Tuesday
Mar. 15

Tracking Problems and Code

Readings:

  • Fogel 2006, ch. 3 (the rest of the chapter)
  • Rochkind 1975
  • Git Reference up to "Branching and Merging"
  • record.py revision history
  • Tatham 1999
  • PyMARC discussion group
  • PyMARC issue tracker
    • Issue #3

    Exercises (do at home, before class):

    4 Tuesday
    Mar. 22

    Code in the Commons

    Readings:

    Exercises (do at home, before class):

    5 Tuesday
    Mar. 29

    Code in the Commons: New Trends

    Readings:

    Exercises (do at home, before class):

    • TBA
    6 Tuesday
    Apr. 5
    Student presentations

    * Project paper due by 5pm on Saturday (April 9)

    Assignments and Grading

    Your grade will consist of three components:

     Grade componentPercentage of final course gradeType of assignment
     Class Participation25%individual
     Course Blog Participation25%individual
     The Final Paper50%group*

    (*Group members may recieve different grades for the course project.)

    Class Participation

    Your class participation grade will be based on your contribution to class discussion and exercises and will take into account both quantity and quality. Please note that participation does not mean attendance. Students who attend every class but never contribute to the discussion would get zero for class participation. (This is a University rule.)

    Course Blog Participation

    Each week of the class, including the first week, you should make 2 posts to the course blogs.

    The Final Paper

    The final assignment for the class is a paper that should be developed and written individually, in pairs or in groups of 3. Students should form their own groups and are encouraged to do this early in the course. Papers written jointly should be submitted together with a "statement of responsibilities" discussing each member's contribution. Please note that writing the paper together with another student (or two students) should not be seen as an opportunity to divide the work in half. Your statement of responsibilities therefore should not say "Alice wrote the first half, Bob wrote the second half." Rather, the goal of working together is allow the co-authors to engage in a dialog about the topic and each co-author will bear full responsible for all of the paper.

    Your paper should provide a deeper look at one of the topics discussed in the class, relating class material to larger issues in information studies. Good papers will likely incorporate sources beyond the assigned readings. (Papers without additional sources would bear the burden of the proof that nothing relevant has been written on the topic earlier.)

    The length of the paper should not exceed 4,000 words.

    You should start thinking about potential paper topics early in the course. On April 5 (week 6) you will make a presentation of your paper in class. You should plan to have a good draft of the paper by that point. The final version of the paper is due at 5 pm the following Saturday, April 9.

    Normally, students will be required to submit their course essays to TurnItIn for a review of textual similarity and detection of possible plagiarism. In doing so, students will allow their essays to be included as source documents in the Turnitin.com reference database, where they will be used solely for the purpose of detecting plagiarism. The terms that apply to the University's use of the Turnitin.com service are described on the Turnitin.com web site. Students who do not wish to use TurnItIn for submitting their work should approach the instructor to discuss alternative ways to establish the originality of the paper.

    Your final paper should be double-spaced, using a 12 point serif font (Times New Roman or similar). It should follow APA citation format. Additionally, please consult the following handout on proper use of citations: "Citing Wikipedia".

    Please do not forget to put your name in the upper right corner of the first page. I much prefer papers without a title page.

    Bibliography

    Downey, A.B. (2010) Think Python: How to Think Like a Computer Scientist. Green Tea Press. Available at http://www.greenteapress.com/thinkpython/html/index.html.

    Fogel, K. (2006) Producing Open Source Software. O'Reilly. Available at http://producingoss.com/.

    Knuth, D.E. (1984) "Literate Programming," The Computer Journal (British Computer Society), 27 (2), pp. 97–111.

    Krueger, C.W. (1992) "Software Reuse," ACM Computing Surveys (CSUR), 24 (2), pp. 131–183. Available at http://doi.acm.org/10.1145/130844.130856 (subscription required). ta McConnel, S. (2004) Code Complete: A Practical Handbook of Software Construction. Microsoft Press.

    Raymond, E. (2001). "The cathedral and the bazaar", in The cathedral and the bazaar: musings on Linux and open source by an accidental revolutionary. Sebastopol: O'Reilly. Available at http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

    Rochkind, M. J. (1975) "The Source Code Control System." IEEE Trans. on Software Engineering SE-1, 4, pp. 364-70.

    Spolsky, J. (2004) Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity. Apress.

    Stallman, R. (1985/1993) "The GNU Manifesto", http://www.gnu.org/gnu/manifesto.html

    Schwarz, M. and Y. Takhteyev (forthcoming) "Half a Century of Public Software Institutions: Open Source as a Solution to the Hold-Up Problem", Journal of Public Economic Theory. Available at http://takhteyev.org/papers/Schwarz-Takhteyev-2008.pdf

    Tatham, S. (1999/2008) "How to Report Bugs Effectively." Available at http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.

    Valid XHTML 1.0 Transitional