rvm do

I’ve been using rvm for many years, and love it.  Yes, I know that it rewrites simple commands, such as “ruby” and “gem”, so that I can use lots of different Ruby versions.  Yes, I know that it can be overkill for certain situations.  And yes, I know that rbenv is preferred by many.

But I’ve been using rvm for a long time, and I find it works very well for my needs.  I can (and do) have many different versions of Ruby running on my computer, and having access to all of them at once is terrific.

I tend to be obsessive about updating Ruby gems on my systems, and I’m sure I’m not the only Rubyist who runs “gem update -V” (and yes, I love the “verbose” option) at least once per day.  Updating gems never removes the old versions, and if you’re using Bundler in your Rails or Sinatra application, then it doesn’t really matter how many versions you have on your system.  (And yes, I know that willy-nilly updating all gems on my system is probably not wise.  If only that were the most foolish thing I do…)

The thing is, when I update gems, I do so in a particular version of Ruby.  So even though I’m always running “gem update -V”, I never quite remember which versions of Ruby have the latest gems, and which haven’t been updated in a while.  There is, of course, a clear correlation between the frequency with which I use a Ruby version and the freshness of the gems for that version on my system.  But I sometimes find myself having to update gems in a version of Ruby that I haven’t used in a while.

So you can imagine my delight when I discovered “rvm do”.  This is an rvm command that lets you execute a command in any or all of the Ruby versions installed on your system.  It basically switches to the Ruby version and then executes the requested shell command — so you’re not executing a Ruby program in each separate version, but rather you’re executing a command-line program once for each version of Ruby installed.  You can think of it as executing the same shell command once for each installed version, prefaced by “rvm VERSION_NUMBER”.

So, how can I ensure that all of the gems, for all versions of Ruby, are up to date?  Very simply, I write:

rvm all do gem update -V

And if I want to check out some Ruby code, and see how it runs in all of the versions on my system, I can say

rvm all do ruby test.rb

If I just want to see the difference between doing something in 1.8, 1.9, 2.0, and 2.1 (without all of the patchlevels for 1.9.3), then I can just say:

rvm 1.8.7,1.9.3,2.0,2.1  do ruby test.rb

I’m already loving this feature, and can easily imagine cases — such as when teaching Ruby programming, and trying to show them the differences between versions — when this will be quite handy.

Announcing: Teaching to Code, a community of programming instructors

In the wake of my last blog post, I’ve been thinking a great deal about the practice of teaching, and specifically the practice of teaching programming.  I’ve realized that while instruction in programming is increasingly popular and important, the people engaged in such instruction aren’t comparing notes, learning from one another, or generally working to improve the trade.

I’ve decided to try to change that.  I’ve created a new site, Teaching to Code, a discussion forum aimed at anyone who teaches programming to others.  Whether you teach in person, produce screencasts, or lecture at the university level, I’m sure that there are techniques, ideas, and suggestions that you can share with other people, and which can help to improve the craft of teaching programming.

It’s true that many of us in this community are commercial instructors.  As a result, there will undoubtedly be some overlap and competition among the people who participate.  I’m optimistic that we can balance these competitive instincts and realities with the goal that we all (presumably) have, namely to improve our students’ knowledge and understanding of programming in general, and of the technologies we teach in particular.

In addition to general discussion on a variety of topics, I’m also aiming to have a monthly book/journal club.  Each month, we’ll discuss a book, journal article, or blog post (or even a video, I guess) that can inform and improve our teaching.  Some of the initial suggestions will come from readings I’ve had in graduate school; there were a number of papers that have really influenced my thinking, and that I believe will be interesting and useful for others, too.  But I know that I’ve only read a minority of things written on this subject, and would be delighted to read and then discuss these items, as well.

If you’re a programming instructor of any sort, please join us!  Contribute to the fledgling discussion, and suggest how we can make it better.  If there is something that you feel could help you, or improve your teaching, then you can either ask on the forum or e-mail me at reuven@lerner.co.il.  Either way, I hope that Teaching to Code will become a community of practice for programming instructors worldwide, helping teachers and students alike.

Teaching and acting (or, why I don’t plan to sell recorded classes in the near future)

Several weeks ago, my wife and I saw a wonderful play at our local theater in Modi’in  (“Mother Courage and Her Children“).  At the end, the actors came out to receive their richly deserved applause.  Three times, the actors came out, took their bows, and were warmly applauded by the audience.  We loved their performance — but just as importantly, they loved performing, and they loved to see and hear the reactions from the audience, both during and after the play.

I’m sure that some or all of these actors have worked in television and the movies; Israel is a small country, and it’s hard for me to believe that actors can decide only to work in a single medium.  But I’ve often heard that actors prefer to work on stage, because they can have a connection with the audience.  When they say something funny, sad, or upsetting, they can feel (and even hear) the audience’s reaction.

But while we often hear about TV and movie stars making many millions of dollars off of their work, it’s less common for stage actors to make that kind of money.  That’s because when you act on stage, you’re by definition limiting your audience to the number of people who can fit in a theater.  Even the largest theaters aren’t going to hold more than a few hundred seats; by contrast, even a semi-successful TV show or movie will get tens or hundreds of thousands of viewers on a given night.  (And yes, TV and film have many more expenses than plays do — but the fact remains that you can scale up the number of TV and film viewers much more easily than you can a play.  Plus, movies and TV can both be shown in reruns.)

Another difference is the effort that you need to put into a stage production, as opposed to a TV program or a movie: In the former case, you need to perform each and every night.  In the latter, you record your performance once — and yes, it’ll probably require multiple takes — and then it can be shown any number of times in the future.  You can even be acting on stage while your TV show is broadcast.  Or more than one of your movies can be shown simultaneously, in thousands of cities around the world.

What does this have to do with me?  And why have I been thinking about this so much over the last few weeks, since seeing that play?

While I’m a software developer and consultant, I also spend a not-insignificant time teaching people: In any given week, I will give 2-4 full days of classes in Python, Ruby, Ruby on Rails, PostgreSQL, and Git, with other classes likely to come in the next few months.

I’m starting to dip my toes into the waters of teaching online, and hope to do it increasingly frequently over the coming months and years.  But unlike most online programming courses currently being offered, I intend to make most or all of my courses real-time, live, and in person.

This has some obvious disadvantages: It means that people will need to be available during the precise hours that I’m teaching. It means that the course will have to be higher in price than a pre-recorded video course, because I cannot amortize my time investment over many different purchases and viewings.  And it means that the course is limited in size; I cannot imagine teaching more than 10 people online, just as I won’t teach an in-person class with more than 20 people.

Given all of these disadvantages, why would I prefer to do things this way, live and in person?

The answer, in a word, is: Interactions.

I’m finishing my PhD in Learning Sciences, and if there’s anything that I have gained from my studies and research, it’s that personal interactions are the key to deep learning. That’s why my research is all about online collaboration; I deeply believe that it’s easiest and best to learn when you speak with, ask questions of, challenge, and collaborate with others, ideally when you’re trying to solve a problem.

I’m not saying that it’s impossible to learn on your own; I certainly spend enough hours each week watching screencasts and lectures, and reading blog posts, to demonstrate that it’s possible, pleasurable, and beneficial to learn in these ways. But if you want to understand a subject deeply, then you should communicate somehow with other people.

That’s one of the reasons why pair programming is so helpful, improving both the resulting software and the programmers who engage in the pairing. That’s why open source is so successful — because in a high-quality open-source project, you’ll have people constantly interacting, discussing, arguing, and finally agreeing on the best way to do things. And that’s why I constantly encourage participants in my classes to work together when they’re working on the exercises that I ask them to solve: Talking to someone else will help you to learn better, more quickly, and more deeply.

I thus believe that attending an in-person class offers many advantages over seeing a recorded screencast or lecture, not because the content is necessarily better, but because you have the opportunity to ask questions, to interact with the teacher, to clarify points that weren’t obvious the first time around, and to ask how you might be able to integrate the lectures into your existing work environment.

So for the students, an in-person class is a huge win.  What do I get out of it?  Why do I prefer to teach in person?

To answer that, I return to the topic with which I started this post, namely actors who prefer to work on stage, rather than on TV and in movies. When I give a course, it’s almost like I’m putting on a one-man show. Just as actors can give the same performance night after night without getting bored, I can give the same “introduction to Python” course dozens of times a year without tiring of it.  (And yes, I do constantly update my course materials — but even so, the class has stayed largely the same for some time.)  I’m putting on a show, albeit an interactive and educational one, and while I put on the same show time after time, I don’t get tired of it.

And the reason that I don’t get tired of it? Those same interactions, which are so beneficial to the students’ learning and progress, are good for me, as the instructor.  They keep me on my toes, allow me to know what is working (and what isn’t), provide me with an opportunity to dive more deeply into a subject that is of particular interest to the participants, and assure me that the topics I’m covering are useful and important for the people taking my class.

I live and work in Israel, and one of the things that I love about teaching Israelis is that I’m almost guaranteed to be challenged and questioned at nearly ever turn. Israelis are, by nature, antagonistic toward authority.  As a result, my lectures are constantly interrupted by questions, challenges, and requests for proof.

I have grown so accustomed to this way of things, that it once backfired on me: Years ago, I gave a one-day course in the US that ended at lunchtime — it turns out that the Americans were very polite and quiet, and didn’t ask any questions, allowing me to get through an entire day’s worth of material in just half of the time.  I have since learned to make cultural adjustments to the number of slides I prepare for a given day, depending on where I will be teaching!

When I look at stage actors, and see them giving the same performance that they have given an untold number of times in the past, I now understand where they’re coming from. For them, each night gives them a chance to expose a new audience to the ideas that they’re trying to get across through their characters and dialogue.  And yes, they could do that in a movie — but then they would be missing the interactions that they have with the audience, which provide a sense of excitement that’s hard to match.

Does this mean that I won’t ever record screencasts or lectures?  No, I’m sure that I will do that at some point, and I already have some ideas for doing so. But they’ll be fundamentally different from the courses that I teach, complementing the full-length courses, rather than replacing them. At the end of the day, I get a great deal of satisfaction from lecturing and teaching, both because I see that people are learning (and thus gaining a useful skill), and because my interactions with them are so precious to me, as an instructor.