MIT 6.S194 | Open Source Software Project Lab  

Debugging

Everybody knows the standard list of bugs that an Introduction to Programming textbook will teach you:

  • Off by one errors
  • Memory management bugs
  • Uninitialized variables
  • Unvalidated input
  • Null values
  • ... and so on

This lesson has two goals:

  • Fun puzzlers to get you thinking about more subtle errors that often happen
  • Use those puzzlers as an excuse to talk about general bug catching strategies

The languages and environments for the puzzles are intentionally varied to make sure that, for at least some exercises, you'll have to practice debugging outside your linguistic comfort zone.

The Lineup

Please pair up in groups of 3. Have at least one person with NodeJS and one person with Linux/Mac per group

  • When things don't go as expected

    ... Developing a hound's node for sniffing out errors, even when they're invisible.

  • Debugging distributed systems

    ... When code no longer executes serially

    • Exercise A Juggler's Dilemma (Javascript, NodeJS)
    • Exercise Who Am I? (Javascript)
    • Discussion: distributed systems, callbacks, multiple machines, distributed logging, timing
  • Defensive Programming

    ... "Offense wins games, defense wins championships"

Journal Question

At this point, all of you have been spelunking in fairly large codebase for a few weeks. You've skimmed code, read code, written code, compiled code, and used the grep and find commands more than you probably expected you would.

  • What are some specific debugging challenges particular to your project? Think about its project organization, code design, runtime architecture, test suites, etc.
  • Given that they exist, how could one or two of these challenges be mitigated by a developer on the project like you? What processes or techniques could you apply?
  • Could any of these challenges be eliminated alltogether? If so, what would the tradeoffs of that be?

Please submit your response by class time on each Monday. Here are the Journal guidelines and submission instructions.

Geek Cred

Monkey Patching (also known as duck puntching) refers to the process of modifying code while a program is running. It is both powerful, dangerous, and controversial. Monkey patching is one of the reasons Ruby on Rails is able to do so pmany "magical" things with its API. This is possible because the Ruby language allows object definitions to be modified at runtime.

The term, hilariously, comes from guerilla patching (sneaking code in at runtime like a military guerilla), which sounds like gorilla, which became monkey.

"Duck punching" has a similarly amusing etymology. Duck Typing ("if it walks like a duck, and talks like a duck, it is a duck") is a practice in which objects are dynamically typed based on their properties (variables and methods) rather than a static type assignment (e.g., `Duck d = new Duck()`). But say you have a cow, but wanted a duck. You can just "punch" the cow (at run time) with new code and force it to walk like a duck.


Class List

  1. Introduction (W 2/6)
  2. Bootup (M 2/11)
  3. Become a Git Master (W 2/13)
  4. Everything you ever wanted to know about Web Requests (T 2/19)
  5. Design Studio (W 2/20)
  6. Debugging (M 2/25)
  7. Design Studio (W 2/27)
  8. Open Source Business Models (M 3/3)
  9. Design Studio (W 3/6)
  10. Work Day (W 3/11)
  11. Design Studio (W 3/13)
  12. Quantifying Code (M 3/18)
  13. Design Studio (W 3/20)
  14. Spring Break (M 3/25 & 27)
  15. Quantifying Users (M 4/1)
  16. Work day (W 4/3)
  17. Remote Collaboration (M 4/8)
  18. Design Studio (W 4/10)
  19. No class - Patriot's Day (M 4/15)
  20. Design Studio (W 4/17)
  21. Work Day (M 4/22)
  22. Design Studio (W 4/24)
  23. No class - CHI (M 4/29 and W 5/1)
  24. Final Presentations (M 5/6)
  25. Final Presentations (W 5/8)
  26. No class - WWW (M 5/13 and W 5/15)
  27. *Note: Report due W 5/15*