Day Three: Ruby Studio

One issue with holding any event in the early parts of the year is colds and coughs. I thought I had gotten over mine (I had a runny nose and cough over the weekend). Still, I was occasionally coughing, even throughout the week. Poor Chad seemed similarly afflicted, but managed to lecture on in any case.

I had originally thought, when the two would teach, that one would do the morning, and one would do the afternoon. Having taught before, I know it can be exhausting to have to go on for more than a few hours. Having said that, the alternating does allow one person to rest, while the other person talks, and they can fill in their opinions as the teaching goes on. In hindsight, teaching like this is better for the students.

Due to a scheduling snafu, the class moved from the room we were at the past two days, to this other room. The original room had two possibilities for layouts. Either three very wide rows, or more narrow rows. For teaching, I'm convinced that you want a wider layout. The further back a student is, the less likely they'll ask questions, and many of them are already reluctant to ask questions.

I tend to ask a lot of questions. Indeed, for every question I do ask, I could ask half a dozen others. I think asking questions is the best way to remain engaged as a student. Having said that, I know the guys were, after a while, avoiding picking on me, in favor of other students. Of course, there's a way to get around that, which I employed on Day 3. I simply piped up.

Actually, that's an interesting social phenomenon. In a classroom setting, students have been "taught" to raise their hands. But many people feel pretty silly doing that. It's a sign of deference. You are the one requesting help. The teacher acknowledges you (or not). This kind of conversation is unlike most normal conversation when people simply talk, and so I think many people don't like the idea of raising hands and prefer, instead, to just speak up.

I still give credit for the professionalism (otherwise) of answering questions.

Usually, teachers want students to ask questions, but much of that is because students don't want to ask questions, and teachers feel bad (sometimes) if students don't get it, so getting students to ask questions is tough, and teachers often have to prod students to do it.

Having said that, most teachers rarely see the flip side. That is, they rarely see students peppering them with questions. Teaching, at its best, is part one man act. That is, it's a performance. If you look at Al Gore's presentation for global warming, it's a one-man act. For him to make his points well, he doesn't really want to encourage questions (at least, not during the talk part of his presentations). Interaction would ruin the flow of what he wants to say.

On the flip side, even if teachers want students to ask questions, there are certain kinds of questions they want to hear. Let me go through the kinds of questions that teachers generally don't want to hear.

First, there are students who correct the professor all the time. Maybe they've written the wrong equation. Maybe they did the math step wrong. Maybe they made a blanket statement which really has some odd corner cases, and they don't mention it. While these corrections are important, teachers don't like it.

The reason? They make the teacher look kinda bad, or the student look rather pedantic. I believe students need to point out reasonable corrections, so I favor the students on this.

Although it's exceedingly rare, teachers don't like questions that are in outer space. These are things like "Do you think Ruby is a good language for creating artificially intelligent agents?". Or better "Can we combine Ruby with neural networks to make Star Trek's Data?". These questions are speculative, and totally odd. But, as I said, they rarely happen.

Teachers don't like questions where the students clearly know way too much. Ruby, for example, has an Enumerable class, which is a mixin that adds functionality to classes that support each and the spaceship operator. Such a generic solution to a container class often comes at a price. Your class may have far more efficient ways of handling certain methods. Blindly applying Enumerable means you're not paying attention to the runtime efficiency of its implementation.

Even though, in theory, many people have had computer science degrees (turns out, not true, many don't have such degrees), and that many people have had an algorithms course (many CS majors either haven't had it, or don't remember much of it), bringing up complexity theory considerations is often a problem.

It's not so much the people teaching it don't know it. This is a problem with the students not knowing it. It's not that it isn't important, but that properly discussing it would take too much time, and distract from the basics of the language.

Finally, I suppose, teachers don't like questions that don't make sense, but mostly, they are just puzzled when that happens. Often questions don't make sense because the students have a hard time formulating a good question. They know they are confused, but can't express those sentiments clearly. Fortunately, the older you get, the better you get at asking questions (for the most part).

What questions do teachers like? Certainly ones that ask for more clarification. Questions where the students come up with some idea they think is good, but actually isn't. (A question was asked whether a mixin should be smart enough to know what it's getting mixed into. The answer was no, that would defeat the purpose of a mixin, which is to generically add functionality).

Well, that was a long digression.

I'd say Day 3 was not nearly as good as Day 2, but it was important. We started off talking about I/O. It's interesting how recent languages seem to defer I/O until very late. By I/O, I mean everything from file manipulations, to socket communications. But what I really refer to reading input and printing output. Most languages tend to treat I/O in a uniform manner (everything is a file).

Most of the times, teachers introduce I/O early. However, in the case of Ruby, it makes a lot of sense to introduce it late. Unlike, say, Java, where I/O seems unnecessarily complex, or Haskell, where it's complex for a completely different reason, Ruby's I/O is not that bad, and resembles "C". And because it's reasonably straight-forward, there's no reason to cover it early. It looks a lot like other languages.

Instead, what makes Ruby unique (mostly) is its use of blocks. Even though blocks can be tough to get your head around, it is the central feature of Ruby that a good beginner needs to handle. It goes to the way Rubyists like to code. None of that loop stuff. Give me a block!

But given that blocks are tough to understand, it's good to defer that to Day 2, until you can get a lot more of the basics done, and give people a chance to use blocks.

So, Day 3 started with I/O.

Then, we moved to unit testing. Given the typical Rubyist is into TDD (test driven development), it was a little surprising to defer it this late, but then it makes sense to know enough programming before we start to test. So, again, a good decision to defer TDD til later.

Then, we went to some of the mechanics of the organizing Ruby code, and then, to look at various libraries. The content was primarily to understand Ruby as it's really used. They could have covered more heavy duty Ruby codes, like diving deep into the libraries to see some Ruby magic, but languages have gotten complex enough, that you have to worry about libraries and you have to worry about code organization. It isn't coding per se, it's about following conventions so other people can use your code. Again, good idea to defer to Day 3.

Day 2, therefore, was why people like to code in Ruby. Day 3 is about being a good Ruby citizen, and therefore, wasn't nearly as exciting.

I'd say, overall, the course covered a lot of material, and I got what I wanted out of it, which is to use Textmate, to do some TDD, and to understand more about Ruby. Three days is not a lot of time to master Ruby, but they covered a fair bit of material, which is good.

I'm sure there is a tradeoff. On the one hand, you want to tell people enough so they can be productive, but not so much that the language scares them. There are lots of people doing a lot of clever stuff in Ruby, and it requires a bit of thought to follow what's going on.

I also give major props to Dave and Chad. Dave's knowledge of Ruby (having written a book on it) is encyclopedic, and he's OCD enough to master all those tiny details and exceptions, and is a good teacher to boot. Dave's not as much in his element as he is when he gives a 20 minute talk, and is performing, but he's still awfully good at teaching.

Although we didn't have time for it (and it wouldn't have fit in the course), I would have liked to do some RSpec (which is a unit-test framework that looks like specifications).

Also, since many of the students work as developers (a real student couldn't afford the price to attend), there was some good advice. One student suggested I check out a Textmate tutorial given by James Edward Gray (the second). He wrote some particularly challenging code, but it was fun to read in the hotel, so I got a kick out of that. Another student sent me a Textmate cheat sheet, which is also good.

Afterwards, one of the students who had rented a van took me and another student to the airport, and that was nice. Too bad my flight got delayed and I didn't get back to my apartment til nearly 3 AM.

All in all, a good experience. I'd recommend it to anyone who can get their company to pay for it! :).

I'm currently watching Meatballs 2, and it is simply awful. I think ET was released somewhat earlier, and they put in an alien in it. The depths of cringe-inducing mediocrity. How did this ever make it to the screen? And typical 80s style clothing (remember the preppie look? the pastel clothes for women? guys that look like Scott Baio?)

Now, to do some more reading on Ruby (after some more sleep)!