Teaching Ruby

[codemage]

By special request.

I'm sure you could hook up with that as well if you really wanted to... but probably not, seeing as you're a mod et al.

[rizzix]

yea.. well your title confused me a bit.. cuz we already do have a supreme newbcake... i guess there's no harm in adding another one to our collection...


edit: oh wait nvm... i think you replaced him.. *gosh* you must feel special.

[codemage]

Special, as in Olympics. 8)

[wtd]

codemage wrote:

I'm not overly familiar with Ruby yet (one of my reasons for joining the board), but from the little I've done, I think the paradigm still fits.

This is long overdue, but here it is anyway...

Welcome aboard!

The paradigm fits, but only because of the flexibility of Ruby. It's good at hiding its true nature, even from the most experienced among us.

The good thing is that even as bamboozled as we've been by it, we can still use it to accomplish interesting things.

[wtd]

Aside from OOP, I see one of the most important subjects in Ruby being blocks. Blocks are phenomenally powerful, and used just about everywhere in Ruby.

Next on the list after that would be mix-ins.

[Cervantes]

Teach blocks before or after OOP?

They could be taught before, but it would would require that students learn how to write methods that use blocks. On the plus side, this would mean a good understanding of how blocks work; there wouldn't be anything 'magical' about them. On the down side, this could be quite the stumbling block.

Or, blocks could be taught after OOP. This would would allow blocks to be learned by using various blocks with various methods that are only available to the student once OO has been learned. This way might be easier, especially because by this time students would be more familiar with Ruby. On the down side, there might be a certain 'mystical nature' to blocks until they are fully uncovered, until students get to writing their own methods that use blocks.

I'd go with the latter.

[wtd]

If this appears to be a rip-off of anything previously said in this thread, it's because I've read it all carefully and appreciate your collective wisdom.

• History of computing and basic theory stuff. This has been done to death, and probably better than I an do it.
  
• Basic command-line stuff and understanding of file-systems.
  
• Installing Ruby.
  
• Look at the Ruby environment: "ruby" vs. "irb".
  
• Basic data types: Strings, ints, floats, boolean values. How these are represented in Ruby demoed in irb.
  
• Demonstrate simple output using "puts", "print" and "p". Explain differences between these.
  
• Variables. Talk of scope can wait until methods and classes. Do talk about constants.
  
• Simple input using "gets". Here we reach an impasse. "gets" gets the newline as well. The only way to get rid of it is to "chomp" the newline off. "gets.chomp" returns an input string sans newline.
  
• Conditionals. if/unless, else, elsif, and postfix versions of if/unless. Also cover "case" and the associated when/else.
  
• Iteration. for...in, while/until, loop. This would necessitate discussion of next/break. Talk about postfix use of while/until.
  
• Simple methods. Arguments/parameters. Talk about "return" but mention that it's rarely explicitly required.
  
  Talk about scope: the difference between local_variables and $global_variables. We're phenomenally lucky with Ruby that global variables must be explicitly denoted as such.
  
• Classes and objects. OOP theory. Encapsulation. Fortunately Ruby forces encapsulation. Implicit "self" context. How that context has to be explicit outside the class.
  
  Mention @instance variables.
  
  Mention that everything they've seen is an object.
  
  Pick splattered programmer brains up off the foor.
  
• Arrays/Hashes.
  
• Blocks. Funky iteration possibilities. "yield" keyword.
  

[codemage]

That's starting to look like something that (with links & formatting added) could become the Ruby Walkthrough v1.0

[Tony]

nice looking list wtd

don't think I can add (or change the order of) anything.

Just supply interesting assignments with a common theme help students relate previous lesson to the next one.

[wtd]

codemage wrote:

(with links & formatting added)

Heh. Yes, very much at the brainstorming phase.

[wtd]

Tony wrote:

Just supply interesting assignments with a common theme help students relate previous lesson to the next one.

That kind of thing is where I'm expecting help.

We can do it in an open kind of manner. One person posts an explanation of a subject and an exercise. Debate it until we all find it at least mildly acceptable, then another person comes up with the next bit of it.