Computer Science Canada :: View topic

require 'rexml/document'

document = REXML::Document.new <<END_BASIC_DOCUMENT
<?xml version="1.0" encoding="UTF-8"?>
<urlset
xmlns="http://www.google.com/schemas/sitemap/0.84"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.google.com/schemas/sitemap/0.84
http://www.google.com/schemas/sitemap/0.84/sitemap.xsd">
</urlset>
END_BASIC_DOCUMENT

puts "What is the site root URL? (http://www.example.com/)"
root_url = gets.chomp

Dir.new(Dir.pwd).reject { |filename| filename == '.' or filename == '..' }.each do |filename|
lastmod = File.mtime(filename).strftime("%Y-%m-%d")

puts "File: #{filename}"

puts "Would you like to include this page in the sitemap? (y, n)"
answer = gets.chomp

if answer == "y" or answer =~ /^ \s* $/x
puts "How often is this page changed?"
changefreq = gets.chomp

changefreq = "monthly" if changefreq =~ /^ \s* $/x

puts "How important is this page? (0.1 - 1.0)"
priority = gets.chomp

priority = "0.5" if priority =~ /^ \s* $/x

url_tag = document.root.add_element "url"

loc_tag = url_tag.add_element "loc"
loc_tag.text = "#{root_url}#{filename}"

lastmod_tag = url_tag.add_element "lastmod"
lastmod_tag.text = lastmod

changefreq_tag = url_tag.add_element "changefreq"
changefreq_tag.text = changefreq

priority_tag = url_tag.add_element "priority"
priority_tag.text = priority
end
end

File.open("sitemap.xml", "w") do |output_file|
document.write output_file, 1
end

Author:	wtd [ Mon Sep 19, 2005 12:03 pm ]
Post subject:	Teaching Ruby
One more time! So, since I started this topic before the roll-back, it's occurred to me that there are effectively two major approaches. You can either take a step-by-step approach of introducing various capabilities of Ruby, or you can just throw some code out and pick it apart. Though I'm a fan of the former, I'm beginning to think the former holds promise, since it has the potential to really grab attention, and to simultaneously address the question: "ok, that's great... can I do anything useful with it?"

Author:	Tony [ Mon Sep 19, 2005 12:33 pm ]
Post subject:
I'm in favour of step-by-step approach. Here's a line, here's what you can do with it. Now try something else with what you've learned last week's line. I think that midway you can then do something like you - "lets learn Objects" students - "oh noes! it's too difficult" you - "you've been using Objects since day one.. here's how" Bottom line -- control your urges to dive right into the technicalities, let students have their fun. Everything will be taught in due time.

Author:	Cervantes [ Mon Sep 19, 2005 3:37 pm ]
Post subject:
Step-by-step approach. I've no idea if you read what I posted or not, wtd, but it sounds like you did. I'll repost the order of things that I had suggested, in any case: puts variables gets if structures (could throw cases in here) methods (made by the programmer, not pre-made methods of various classes) (could throw arrays and hashes in here) Now you are free to teach Object-Orientation, and you need not have used it at all until this point. [edit] Well, you have used object orientation, as in calling the == method from the, for example, String class. But you don't introduce the == method that way, and it will be easier for the students.[/edit] wtd wrote: You can either take a step-by-step approach of introducing various capabilities of Ruby, or you can just throw some code out and pick it apart. Though I'm a fan of the former, I'm beginning to think the former holds promise, since it has the potential to really grab attention, and to simultaneously address the question: "ok, that's great... can I do anything useful with it?" I'm guessing that's supposed to say that you're a fan of the former, but beginning to see merit in the latter. Or is it the other way around?

Author:	[Gandalf] [ Mon Sep 19, 2005 3:45 pm ]
Post subject:
Both points have their advantages. The problem I see with letting the students have fun before technicalities is that they might later see no use in learning those specifics (objects, etc.) If you go into the hard stuff early on though, they might get discouraged, and they might think that there is no real use to all that. The one reason why Turing was pretty good in that aspect is that it allows you to do the visual, encouraging stuff fairly early on. A learning language should be able to encourage you to program and see the results, showing you how many possibilities there are.

Author:	Cervantes [ Mon Sep 19, 2005 7:09 pm ]
Post subject:
wtd wrote: I fear going through and doing things the step-by-step way simply be boring. It could be boring to those who understand programming already. Perhaps it would be slightly boring to those who have a natural grasp of programming, even if they have not programmed before (the highly logical type). But to the vast majority of beginner programmers, I believe the pace would not be too slow. wtd wrote: In talking to compsci.ca members privately about other languages, I've noticed that sometimes I can get interest by throwing out some code, getting a "WTF?!" response, then picking it apart so that they can see how, yes, it really does make sense. Indeed, but these are compsci.ca members. There is a big difference between the active compsci.ca members and beginner programmers. Things would be different if the students had some other programming experience, however...

Author:	Tony [ Mon Sep 19, 2005 9:10 pm ]
Post subject:
teaching a programming class is quite challanging as there will always be those few slow kids who just dont get it.. and a few that are bored because you're holding back for the masses..

Author:	[Gandalf] [ Mon Sep 19, 2005 9:26 pm ]
Post subject:
Isn't that the case in any class? That's why they should have seperate classes for the 'slow' kids and the faster ones, or else just have a low level somewhere at the beginning which allows the slow ones to learn the basics and find out if they want to continue in that direction.

Author:	wtd [ Mon Sep 19, 2005 10:56 pm ]
Post subject:
It's a very complicated subject, to put it mildly, with many schools of thought. The only thing I can think of to address the issue is to encourage students to dabble outside of class, and to try to identify the students who are really taking initiative and cut them a bit looser than the rest. Though you could perhaps bring those students back into the fold by saying, "ok, you're so far ahead.... why don't you share some of what you've learned with everyone else?"

Author:	codemage [ Fri Sep 23, 2005 11:56 am ]
Post subject:
The standard order things have usually been taught around here (the SW Ontario school of thought AFAIK) is: puts (& formatting) variables gets selection (if / case) loops + iteration arrays / hashes methods / routines recursion OOP When teaching non-programmers, it's best to work your way up. I'd leave objects until after the basics - there's a good chance that'll really throw off the 1st timers. If the class grasps the material quickly, you can go through the initial stuff quickly. I find that the advanced students work ahead without the need for additional motivation - but for some assignments I'll include bonus/challenge sections to keep them working at their potential. 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.

Author:	Cervantes [ Fri Sep 23, 2005 12:40 pm ]
Post subject:
The problem is that there's very little one can do in Ruby without seeing Object Orientation at work. Learning about arrays and hashes is almost useless if you don't take advantage of any of the associated methods. I would tend to teach OOP before getting into arrays and hashes and recursion. Get to OOP as soon as you can, so you can begin learning about the various class/instance methods, and blocks. Until OOP is taught, students are mostly hanging on by a thread, using a fraction of Ruby's power. That power needs to be unleashed at just the right time: when the students know enough to appreciate it, but not so late that students get bored before experiencing this power.

Author:	Tony [ Fri Sep 23, 2005 1:23 pm ]
Post subject:
though that's exactly the question. when should that power be introduced.

Author:	Cervantes [ Fri Sep 23, 2005 1:58 pm ]
Post subject:
After user-defined methods have been taught.

Author:	codemage [ Mon Sep 26, 2005 11:12 am ]
Post subject:
If you're teaching at the University level, then you should be more concerned with the theory of arrays, recursion, etc that their actual implementation in a particular language. It's quite typical to teach things in a way that make earlier teachings obsolete in practice. (Math teachers do this all the time in high school). It's the theory that sticks. That $0.02 said, I'm a complete newb at Ruby - so you'd be able to judge a lot better where the best tradeoff is. (You don't want to waste too much time on theory).

Author:	rizzix [ Mon Sep 26, 2005 4:22 pm ]
Post subject:
how in the world did you manage to get the title of "supreme newbcake of compsci"

Author:	codemage [ Wed Sep 28, 2005 7:58 am ]
Post subject:
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.

Author:	rizzix [ Wed Sep 28, 2005 8:46 am ]
Post subject:
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.

Author:	wtd [ Wed Sep 28, 2005 6:20 pm ]
Post subject:
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.

Author:	Tony [ Thu Sep 29, 2005 10:13 am ]
Post subject:
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.

Author:	wtd [ Thu Sep 29, 2005 11:25 am ]
Post subject:
codemage wrote: (with links & formatting added) Heh. Yes, very much at the brainstorming phase.

Author:	codemage [ Wed Sep 28, 2005 9:19 am ]
Post subject:
Special, as in Olympics. 8)

Author:	wtd [ Wed Sep 28, 2005 11:05 am ]
Post subject:
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.

Author:	wtd [ Wed Sep 28, 2005 4:27 pm ]
Post subject:
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.

Author:	Cervantes [ Wed Sep 28, 2005 5:29 pm ]
Post subject:
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.

Author:	codemage [ Thu Sep 29, 2005 8:01 am ]
Post subject:
That's starting to look like something that (with links & formatting added) could become the Ruby Walkthrough v1.0

Author:	wtd [ Sat Oct 01, 2005 2:05 pm ]
Post subject:
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.