Expertiza_Wiki - User contributions [en]

CSC 216/s08/wholesome discipline

2008-04-15T18:22:33Z

BenBerry: Summary of intentions

==A Primer on Eclipse==

Eclipse is a massively powerful tool for writing code, designed by and for power users. What this means is that the guts of operation are very open, and easy, one-click functionality is rare.

One of the consequences of this is the string of configuration screens to be navigated the first time a user boots up a fresh install of Eclipse. Asking tough and difficult questions, such as where the user's JDK ("My what?") is. To help correct this, we are making a video detailing some of the more arcane aspects of using Eclipse.

Not only will we be offering tips to help streamline installation and the initial configuration, but we will also show how to install a common plug-in, an extension of Eclipse built for that same power-using crowd.

CSC 216/s08/be cheerful

2008-04-03T18:22:41Z

BenBerry: Give me my table of contents back!

==That's what it's all about!==

===Overview===

In this active learning exercise, you can teach the value of superclassing and writing "don't repeat yourself" code to prevent error. When a programmer writes the same code twice, to do the same job, this increases logistical overhead and introduces more chances for error. But if he writes the code once and tells the classes that use it to look at the same piece of code, this can be handily eliminated. This is where inheritance comes in.

===How It's Done===

To model writing the code twice, and writing it once, you'll need two volunteers and an inside man -- you could do this yourself or delegate it. Your insider will instruct each of the two volunteers in how to do the hokey pokey. You can do this however you like: by word of mouth, by written instructions, whatever. But the one thing that you have to make sure is that one of the sets of instructions is ''wrong''. You'll see why in a second.

Now, have your two volunteers start dancing, strictly adhering to their instructions. Soon enough, they'll come out of sync, and you'll have your error. As you should reveal to the class at this time, this represents what happens when your two sections of code don't mesh perfectly, and the program breaks.

To fix this, you can use a super class that they will both take their instructions from. In this case, a nice Google video of a [http://video.google.com/videoplay?docid=-4742763335053216439 strange man doing the hokey pokey]. (This video will also be of use if your volunteers are a little too nervous: it's hard to be more ridiculous than that guy.) Once they've both received the same set of instructions, they can dance the hokey pokey in unison 'til the cows come home.

After a bit more dancing, bring it all together with a nice review of what each part of the exercise represents, and hopefully close with a laugh. If done right, this will leave a strong impression of the importance of not repeating code.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-04-03T18:21:48Z

BenBerry: Revision for second review. Hopefully clearer and better developed.

==That's what it's all about!==

===Overview===

In this active learning exercise, you can teach the value of superclassing and writing "don't repeat yourself" code to prevent error. When a programmer writes the same code twice, to do the same job, this increases logistical overhead and introduces more chances for error. But if he writes the code once and tells the classes that use it to look at the same piece of code, this can be handily eliminated. This is where inheritance comes in.

===How It's Done===

To model writing the code twice, and writing it once, you'll need two volunteers and an inside man -- you could do this yourself or delegate it. Your insider will instruct each of the two volunteers in how to do the hokey pokey. You can do this however you like: by word of mouth, by written instructions, whatever. But the one thing that you have to make sure is that one of the sets of instructions is ''wrong''. You'll see why in a second.

Now, have your two volunteers start dancing, strictly adhering to their instructions. Soon enough, they'll come out of sync, and you'll have your error. As you should reveal to the class at this time, this represents what happens when your two sections of code don't mesh perfectly, and the program breaks.

To fix this, you can use a super class that they will both take their instructions from. In this case, a nice Google video of a [http://video.google.com/videoplay?docid=-4742763335053216439 strange man doing the hokey pokey]. (This video will also be of use if your volunteers are a little too nervous: it's hard to be more ridiculous than that guy.) Once they've both received the same set of instructions, they can dance the hokey pokey in unison 'til the cows come home.

After a bit more dancing, bring it all together with a nice review of what each part of the exercise represents, and hopefully close with a laugh. If done right, this will leave a strong impression of the importance of not repeating code.

===References===http://video.google.com/videoplay?docid=-4742763335053216439
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-03-25T17:56:45Z

BenBerry: /* The script */

==That's what it's all about!==

===The problem===

Teach the value of superclassing and writing DRY code to prevent error.

===Participants===

3 group members: 1 programmer and 2 classes the he writes, played by volunteers

===Hokey Pokey Music/Video Candidates===

* http://video.google.com/videoplay?docid=-4742763335053216439
* http://video.google.com/videoplay?docid=8805519462208735145

===The script===

# The coder first creates two or more people classes that are supposed to do the Hokey Pokey, by telling them individually how to do the hokey pokey.
#* Because he has a bad memory, he forgets to tell one to "turn himself about" and to do the incorrect 2nd action.
# The "classes" dance the first 2 segments (right foot, left foot) and get it wrong.
# The coder decides to use superclassing and inheritance so that all of his people share the same instructions, so he shows the video.
# They dance the next 2 segments (right arm, left arm) right!
# The best part is that now that the coder has a superclass, I can extend HokeyPokey to as many classes as I want! Like... the whole class! ;)
# Those willing can watch the video and do the hokey pokey with us. :D
# Reiterate how this example applies to real programming.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]

CSC 216/s08/be cheerful

2008-03-25T17:54:04Z

BenBerry: Copy editing because I'm OCD

==That's what it's all about!==

===The problem===

Teach the value of superclassing and writing DRY code to prevent error.

===Participants===

3 group members: 1 programmer and 2 classes the he writes, played by volunteers

===Hokey Pokey Music/Video Candidates===

* http://video.google.com/videoplay?docid=-4742763335053216439
* http://video.google.com/videoplay?docid=8805519462208735145

===The script===

# The coder first creates two or more people classes that are supposed to do the Hokey Pokey, by telling them individually how to do the hokey pokey.
## Because he has a bad memory, he forgets to tell one to "turn himself about" and to do the incorrect 2nd action.
# The "classes" dance the first 2 segments (right foot, left foot) and get it wrong.
# The coder decides to use superclassing and inheritance so that all of his people share the same instructions, so he shows the video.
# They dance the next 2 segments (right arm, left arm) right!
# The best part is that now that the coder has a superclass, I can extend HokeyPokey to as many classes as I want! Like... the whole class! ;)
# Those willing can watch the video and do the hokey pokey with us. :D
# Reiterate how this example applies to real programming.

===References===
* [http://courses.ncsu.edu/csc216/lec/001/homework/le Learning activity assignment]