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)!

Hyatt Place

I've been staying the last few days at the Hyatt Place at the Denver Tech Center. The Hyatt Place is a kind of scaled-down, upscale hotel. They have limited restaurant service, but then they decorate the place with very modern stuff, as you might see in a pretty modern house.

And it has a 42 inch LCD TV! The first I've seen at a hotel. The bad news is that it hums when it's on like old TVs. The channels were limited, the better to encourage people to get on-demand. I was too tired to watch anything so I didn't.

The new fangled thing is to have really nice faucets that gently arc, and to have arced shower poles that look so strong you could do pullups on them. Well, you could if they weren't 5 inches (ah, US standard measurements) from the ceiling, and if could, in this fitness-impaired day-and-age do even a single pullup. Oh Ah-nuld, where are you to encourage general fitness?

And, they have a shuttle service! They'll drive you for free around in a five mile radius, which is pretty sweet. All hotels should do this! Apparently, I missed the sports bar on the second floor. Oh well.

Much of this niceness has to do with a recent renovation of the hotel, and they've done amazingly well.

So, thumbs up to the Hyatt Place (not the Regency!) at the DTC. (DTC has way too many hotels with similar names, one near the other).

Anyway, they are showing one of these Rube Goldbergian contraption things with lots of flames and such, being more of a pyro's wet dream of a setup.

Day Two: Ruby Studio

Day 2 went better than Day 1, I thought. In particular, we spent an hour or so coding up a problem in the morning. Basically, it had to do with creating a "database" and being able to query from it.

I sat by a guy (I should remember his name, but don't) who was playing around with TextMate themes, so I thought I would do the same. The themes have to do with how the colors of the text and background look. The default is color on a white background. I prefer a darker background. The most popular one seems to be one called All Hallow's Eve, which is another name for Halloween. That one uses orange and black, not surprisingly. I ended up using a user-submitted them called RubyRobot, but replaced some of the colors with ones I liked better.

I'm getting a touch more proficient with TextMate. Alas, I have to learn it the hard way, which is to watch people do it, then ask "How did they do that?" and then check out the book on the topic. I realize James Edward Gray, who apparently prefers II over Jr, knows a lot of the ins and outs of TextMate, and this shows, in a demo he does on TextMate, referred to by one of the folks in the class.

Here's a link for the curious. The example he does is a bit sophisticated. However, with just two days of class, I'm more or less able to follow.

Of course, how much you follow something depends on how much you've seen. For example, today they talked about exceptions and closures. I've seen both before, and have used exceptions, and closures somewhat. The more you know about scoping, the better, because Ruby has some unusual ideas about scoping (at least, unusual to a Java programmer). Again, I've seen lots of programming languages, so these weren't surprising to me.

The one big difference I can see between Ruby and Python is Ruby's use of blocks. A block is something like a lambda expression, but it isn't an object (though, by using the keyword lambda, you can convert it to an object). I think it's awkward that it isn't a true lambda expression and that it isn't an object, but Dave Thomas claims that there is an efficiency reason for doing it this way (converting to and from Procs, the names given to these lambda objects, seems awkward, and the language could be conceptually simpler by not doing this).

Closures always give people headaches. In particular, they have no idea how they might use it. Then, it has some weirdness associated with it. However, I know about lambda calculus and lambda expressions, which, admittedly, puts me in the minority of most programmers.

I had intended for people to meet up afterwards, but apparently, this was not announced, and there wasn't huge interest. I know that part of the effectiveness of whether this works or not depends on really simple things. Does it get announced? Does it seem like there's a blessing for it? Are arrangements made so we have a place to meet and talk? Apparently, being so last minute, and being in a hotel, rather than in one's own building creates issues.

Oh, the hotel. Yeah, there's always an issue with hosting in a hotel. It seems only nice hotels bother with conference rooms and such and the ability to host an event. You rarely get a place that charges 100 bucks a night or so to have one of these things (to be fair, the event at Charlotte wasn't priced too badly). There's a sense that people should not host it at a place that's too cheap looking, especially if they plan to charge a bit for it.

For example, suppose there were a facility that could be rented. But then you'd have to deal with catering, and then transportation to the facility, and then if the place looked kinda crappy (say, it was held on a campus), then people might complain that it looks crappy, and how can they not host it at some place really swank? So it ends up that these things are held at nice hotels that charge an arm and a leg. Having said that, the place does look really nice.

I decided after the meeting to go to the bar area where they allegedly had something called "Beer:30" which starts at 5:30 PM each day. Apparently, despite this name, it's only a small sample. Being in Denver, I get to try beers I wouldn't ordinarily try. I've had Fat Tire two or three times since I've been here. I tried something called Golden Bull or some such. I'll have to look it up. It's sad you can't get this east of the Mississippi. I might get a chance to try one more tomorrow.

I went to the bar area, at a little after 5. The hotel I'm staying at has complimentary shuttle service for places nearby. However, the service only runs til 6. Presumably, they don't want you going out to dinner and doing late night stuff, or whatever. Still, it would be nice if they ran til 7.

So I was in a hurry to get drinks, then run back to the hotel. While sitting at the bar, a woman struck a conversation. In the past, I would probably have felt uncomfortable at the idea of talking to someone random. But then she mentioned she was in the class (goes to show you how many people I recognize). That made it easier to have a conversation. Then, a somewhat older guy sat between us, and that was kinda it for conversation. He talked a bit to her. He was from the Portland area, and they talked a bit about beers.

Tomorrow's the last day. I'll be cutting it close (perhaps too much) to get to my flight. The class ends at 4:30, the flight is just before 7, and it's about 30 minutes to get to the airport, with no traffic. 4:30 is like rush hour. The only good news is that I've been told the traffic to the airport isn't as crowded as other places. Another attendee is planning to drive his rental back, so I'll tag along with him. My hope is my flight is delayed like half an hour or so, so I can make it comfortably.

I'm not sure what's on the agenda for tomorrow. I'm a little surprised that we haven't done much with unit testing, as that seems big in the Ruby community. We've done it informally by just running code and seeing what happens.

Let's see what happens tomorrow.

I will say that I find a classroom setting much more conducive to the kind of learning I want to do (even if the folks seem to be ignoring my questions lately).

Day One: Ruby Studio

It first started out as a book, then a publishing company, and now they offer courses. The book was The Pragmatic Programmer written by Dave Thomas and Andy Hunt. The publishing company is called Pragmatic Programmers (or pragprog for short). The teaching arm is called Pragmatic Studio.

I decided to sign up for the inaugural (I didn't know it was inaugural until today) Ruby Studio. I had expected turnout to be somewhat low, but these things are tough to estimate. Although PragProg is tiny by most publishing standards, it's well known about by software developers that there might be 1000 eyes or more for each person who decides to attend.

The reason I thought it might not be SO well-attended is that it's an introductory course in Ruby, and most software developers would consider themselves savvy enough to teach themselves how to program a new language. Now, if this course were substantively cheaper and offered throughout the country, then maybe it'd drum up more interest, but then maybe not.

As it turns out, the class is reasonably full, at around 30-40 people attending it. The demographics are interesting. The class is almost 100% white (as far as I can tell). I'm the only Asian. There are no African Americans, nor other Asians. No Chinese, no Indians, no Koreans. To be fair, Asians make only 1-3% of the American populace, but also make a much larger percentage of the IT industry.

I'd say women make 10% of the attendees, which means there are 3-5 women, which, given Ruby/Rails is a bit higher than expected, but a pleasant turn out.

Dave started by asking the crowd where they came from, and what you see is a large (from my perspective) number of Web developers doing PHP, looking to switch, some QA and sysadmin types that don't code much, but want to use Ruby in their day-to-day work. Also, to my surprise, is the number of people who work on Rails that want to learn Ruby.

This feels like, to me, a J2EE person who wants to take a Java course to learn more Java. It almost sounds silly, since you'd expect any J2EE person to be proficient in Java in order to do basics. Having said that, maybe Rails is so easy to use, so easy to follow simple examples, that you can get by without knowing much Ruby.

Ruby is a funny contrast. On the one hand, given the number of non-developers (which is not to say non-programmers), people must perceive Ruby to be easy enough to use. And yet, folks like DHH do so much metaprogramming magic that most of the attendees (me included) would be shocked at how much you can do in Ruby that is dumbfoundingly difficult.

I won't get too much into the details of what we're doing. There's nothing especially magic about what we're doing, but one issue of interest is how do you teach a language to a wide variety of people? The second is, given that you have to teach uniform content (that is, you don't intend to specialize to each student), what do you teach?

Ruby Studio lasts 3 days, and intro courses are notoriously difficult to teach, because you have a lot of ground to cover. For example, we talked about gems, which is Ruby's way of installing libraries from RubyForge. These aren't official libraries like Java libraries but community donated libraries.

As a teacher of programming, issues like installation is always problematic because you'd want it to be as effortless as possible. One idea, problematic as it is, is to go to a webpage, and edit there. Everyone would use one official compiler, and the same development environment, no installation would be required, and so forth. Anytime, you have to start talking about installation, then you have to go into "Why do I have to install it?".

For example, when I taught "C", I didn't tell people to download "C", untar, and make it. Instead, students were given special accounts that already had "C" installed. I know. It's the nature of languages that they run locally on the machine, and that some installation has to be done, and there are distributions that are practically a double-click from installation away. I'm not saying it shouldn't be taught, because as much as it distracts from the purity of programming, it's also the current real world when it comes to programming.

Oh, wait, let me get to me, to be narcissistic for a moment. Why am I taking this course?

I've heard of Ruby for years now. Years. I knew about Ruby before RoR was even a glimmer in DHH's head. I have (or used to have) the original Pickaxe book (well, the First Edition, in any case). I had the rather excellent Learn Ruby in 21 Days. I would say I've heard of Ruby since 2001, shortly after books became available, and I'm sure I've heard of the language even before that.

Long ago, I had this idea in my head that I should learn a scripting language. But with a plethora of them out there, what do I pick? csh? bash? tcsh? Then, I realized scripting languages fall into two categories.

The original scripting languages were basically simple control flow on top of the native operating system commands. Thus, you had variables, if-then, loops, and functions built on top of calling OS calls like "ls" and "cd". This was all fine and dandy, but you couldn't do computer science kinds of things. Linked lists and trees? Hah!

In Windows-world, these are called batch files.

The problem with these scripting languages, other than syntax that is painful, is that they aren't particularly portable. For example, there are many variants of UNIX, and not all of them have the same options for "cp". So you write a script that uses some switch like "R", and it works on one UNIX setup, but not another. How annoying!

Perl came up with a weirdish idea. What if they reimplemented basic functions like directory movement, file manipulation, etc. as Perl functions? Then, they'd figure out how to port it everywhere, and remove some of the nasty variations from UNIX and Windows installation.

Despite its hideous syntax, Perl allowed you to code real data structures, and was a level beyond what most scripting languages. One could argue easily if there were no Perl, there might not be any Python or Ruby. Indeed, Matz was inspired to write Ruby because of Perl. One might also argue that were Perl not so hideous, there wouldn't be the comparatively niceness of Ruby/Python.

One could also argue that Perl didn't convince computer science types that it was a real language. Its nearly immediate embrace by UNIX sysadmin types, who many programmers oddly consider a subform of developer (to be fair, they aren't really developers, but usually, their knowledge of the system is amazing) put it in some enclave, and people didn't seriously think of Perl as a language people could learn for real. So, in a sense, Perl also retarded the acceptance of scripting languages as being acceptable for programmers.

Having said that, despite its horridness, people who didn't consider themselves programmers found themselves programming in Perl, and because people talk about Python and Ruby as better Perls, people who would otherwise find C# and Java completely intimidating, seem less averse to learning Ruby.

Anyway, back to me. I tried writing a little code in Perl, but to be honest, its weird treatment of arrays and scalars and hashes made it really painful to understand. The books weren't that much better, because Larry Wall tended to assume you groked his view of the world and that it was all easy, when it wasn't.

So I stopped learning Perl. Then, I started collecting books on Python, and books on Ruby. I'm a guy who's great in getting ready to do something, but not so great in doing it. I get books because I expect them to tell me the One True Way (TM) of doing coding. And, almost always, they disappoint greatly.

Part of the issue is avoiding the issue of editing, which I've decided is critical to learning any language.

Honestly, I don't like teaching myself to do much, even if it's the only pragmatic way to program. You can't find experts who want to explain how to code stuff up and let you pepper them with questions. I mean, I can do it, but most books aren't really prepared to teach you programming in this haphazard manner.

I find when I come home, I'm not in the mood to learn to program, then program.

The other problem I have, and it's one I've had forever, is that I want to know that I'm doing something in the "right way". I don't want to do it otherwise, if I'm not. That may seem unusual, but it's far more common than you'd imagine, and it's the one thing that a good programmer should never feel.

I used to teach programming, and you'd find more than one student who want to confirm everything they did was "right". Why? First, they didn't want to feel stupid. Second, they didn't want to "break" anything. Third, they didn't want to waste time. They didn't want to sit there, spend hours doing something, only to realize, they had it wrong! They feel embarrassed, and won't learn anymore.

Let's take this idea out of the realm of programming. Suppose I were to teach you tennis. Maybe you're reluctant. You're not good at sports. You aren't athletic. Already, you've completely psyched yourself out. You won't try particularly hard. If something goes wrong, you're ready to bail. This makes it very difficult to teach someone tennis when they feel they need to be successful right away.

In a sense, I'm that way when it comes to programming. Actually, let me explain this with another anecdote. I knew this guy who, in his mid 20s, decided to pick up tennis. He tried to learn it the best he could. Textbook strokes and so forth. He took lessons. He practiced. He had taken martial arts when he was young, so was sure there was a good way, if not One True Way.

Personally, I'm more of this mindset. I want to learn to program Ruby properly, and that seems difficult. To me, that means getting decent at the editor. I wanted to make an analogy with playing a musical instrument, but that's not quite right. When you play a musical instrument, it's important the notes be played correctly, with the correct pitch and tempo. I suppose a better analogy might be to write music down.

One person composing music might labor greatly trying to write down notes. But, perhaps if they tried some other way, they would get better results, with far less effort. Perhaps there's a device that would let you play chords on a piano, and it would translate that to notes on a page. That would make it far less tedious than, say, writing it on paper.

I don't know that the course will really cover that. Editing, as I said, is far too underrated a skill in programming.

So anyway, I thought about signing up back in December, because I figured, after years, I was still not making that much progress, and I really wanted to be taught in a classroom environment, which is the best kind of way of learning for me, because teachers have pre-digested the material. The way people teach a class is not the way they'd write a book (mostly due to the fact that many people want a book to eventually be a reference book).

A classroom setting has to hit the highlights, focus on important stuff. And for a three day course, they have to cover lots of ground.

The real problem, as I mentioned earlier, is that you can't be all things to all people. Since you can teach a course on an IDE, without learning about a programming language (an indication how complex IDEs have become), most courses like this spend very little time talking about editing.

Even if the course won't cover that (in favor of other topics), I think it's a win for me because it's making me do stuff I haven't done otherwise. I realize, for many people, it's that initial hump that's the toughest. It's like deciding to go dieting that first time. It's hard!

So even though I could buy a computer for the cost of this trip, or some other nice gadget, given my personality, this isn't such a bad way to get me to do things. Ideally, I would prefer someone teach it to me for free, but seems like no one ever wants to do that. So if you have to pay, it doesn't hurt to have guys who are pretty famous for doing that.

Let's see how tomorrow goes.