Exploration Through Example

Eugene Wallingford wrote a depressing post two months ago. (Note: to find the article, you’ll have to scroll down.)

I occasionally write about how students these days don’t want to program. Not only don’t they want to do it for a living, they don’t even want to learn how. I have seen this manifested in a virtual disappearance of non-majors from our intro courses[…]

Eugene point to a post from Mark Guzdial:

Mike is running a trial section of 140 students. The day that he introduced the programming aspect, a dozen students applied to drop the course. Note that: nearly 10% of the enrollment. They had to talk to Mike to drop, because of the trial nature of the section, and the common reason was that they didn’t want to do any programming in Physics.[…] Students dislike programming so much that they are dropping a required course[…]

This trend is important to me for two reasons.

1. I’ve written a book, Everyday Scripting with Ruby, to help non-programmers learn to script. That book’s outsold expectations, but I have an anecdotal impression it’s not because testers (its primary audience) are swarming to pick it up. Rather, it’s because other audiences are. (Good thing we changed the name away from Scripting for Testers.) And I’m writing another book on using Ruby to script your Mac.

2. I’ve completely failed to entice my children into learning programming. A Squeak summer camp: nix. Programming a Lego Robotics robot (in the Lego visual language or Ruby): nix. They find it boring. There are many more immediately gratifying things to do with the computer, the “wow!” factor of even game-oriented programming doesn’t compete with what you can find easily on the net, and Sims 2 and Civ IV are better at satisfying the need to compulsively twiddle with something for long periods of time.

I’ve delayed writing about this for so long because I find myself without anything useful to say. But at least you now have the links.

On the agile-testing list, I answered this question:

So for the first time in many, many years I’m not in a test management position, and I’m writing tests, automating them, etc. We’re using a tool called soapUI to automate our web services testing–it’s a handy tool, supports Groovy scripting which allows me to go directly to the DB to validate the results of a given method, etc. One feature of soapUI is centralized test scripts; I can create helper scripts to do a bunch of stuff–basically, I write the Groovy code I need to validate something and then I often find I’m moving it into a helper function, refactoring, etc.. My question is, how do you know the right balance between just mashing up the automation (ie, writing a script as an embeded test script) vs. creating the helper function and calling it?

Bret Pettichord suggested I blog my answer, so here it is:

I use these ideas and recommend them as a not-bad place to start:

1. At the end of every half-day or full-day of on-task work (depending on my mood), I’ll spend a half an hour cleaning up something ugly I’ve encountered.

2. I’ll periodically ask myself “Is it getting easier to write tests?” If it’s not, I know I should slow down and spend more effort writing helper code. I know from experience what it feels like when I’ve got good test support infrastructure—how easy writing tests can be—so I know what to shoot for.

3. I have this ideal that there should be no words in a test that are not directly about the purpose of the test. So: unless what the test tests is the process of logging in, there should be no code like:
   
create_user "sam", "password"
login "sam", "password"
...


   Instead, the test should say something shorter:
   
using_logged_in_user "sam"
...


   That tends to push you toward more and smarter helper functions.

   Unsurprisingly, I often fall short of that ideal. But if I revisit a test and have any trouble at all figuring out what it’s actually testing, I use that as a prod to make the extra effort.

What was something of a breakthrough for me was realizing that I don’t have to get it right at this precise moment. Especially at the beginning, when you don’t have much test infrastructure, stopping every twelve seconds to write that helper function you ought to have completely throws you out of the flow of what you’re trying to accomplish. I’ve gotten used to writing the wrong code, then fixing it up later: maybe at the end of the task, maybe not until I stumble across the ugliness again.

I’ve decided to use the Intellij IDEA Ruby plugin as my Ruby IDE when working on larger projects and use Aquamacs Emacs for quick work. I think you should all buy IDEA too, so that they are encouraged to make it as good a Ruby editor as it is a Java editor.

Some people use Emacs for large projects. I’m handicapped in doing that because I have an unusually bad short-term memory. So I will often want two or three windows of code plus one shell/test window open. Or at least, I will want wicked fast ways of switching to recently used files. I’ve never found an Emacs workflow that makes having more than two visible buffers comfortable. And Emacs has a more cumbersome way of flipping to recent files than IDEA, plus it doesn’t have the convenient navigational sidebar of modern tools.

I should note that my Emacs skills froze more than a decade ago, so I may be unaware of today’s goodness. In fact, looking in my .emacs file, I see this:

(setq shell-mode-hook '(lambda () (my-shell-setup) (setq mode-line-format (list "%b--" 'default-directory "---%M---%3p---%[(%m: %s)%]%-")) (local-set-key "^j" 'shell-send-input) ; stupid Bridge box ))

The “stupid Bridge box” is a terminal concentrator from around 1987.

I tried TextMate for a couple of months. I approve of the idea, but in practice I had two problems. There’s something about the logic of the key combinations that doesn’t work for me. The way similar commands are organized into related key groups (variants of key modifiers) will not stick in my head, so I was constantly trying control-shift-meta-cokebottle, getting the wrong result, trying shift-control-cokebottle, etc. (And one of the wrong key combinations I often picked—I forget which—made a not-obvious change to the file that would surprise me next time I ran the tests.) Also, the seams kept showing: globalish commands that don’t work because I’m in the sidebar not a source file, the way my tabs kept filling up with files that I’d never intentionally visited, and the like. And the current lack of window splitting is a deal-killer.

I gave NetBeans a shorter trial, and I can’t remember why I didn’t like it.

IDEA has the advantage that I use it for Java, so many of my reflexes carry over. And I always found it had some of that mystical goodness that originally made me prefer Ruby to Python: when I guessed at how something would work, most often I was right.

Still: besides the fact that an upgrade cost me USD 149 (5 euros), it has some disadvantages.

• The Ruby plugin is beta. I haven’t found too many bugs, but features are incomplete. It’s missing many of TextMate’s nice little Rails features. (But at least you don’t have to install a hack to rerun the last test from anywhere you are.)

• Because it’s a Ruby IDE wedged into a Java IDE, it may be confusing for people unfamiliar with Java (and, perhaps, Java in IDEA). For example, the General Preferences has these entries: Project JDK (”Ruby SDK 1.8.6″), Project Language Level (irrelevant for Ruby, but on my machine I could choose 1.3, 1.4, or 5.0), and Project Compiler Output (irrelevant).
  (Project setup doesn’t push Java in your face quite that much.)

• The worst is that it sometimes decides to spend a lot of memory and CPU doing something. When my pokey little MacBook (1.83Ghz, 2G memory) is trying to drive both its screen and a 24 inch external monitor, Time Machine has decided to kick in, and I’ve got various other things running (like Safari, which also likes to suck down CPU while doing nothing visible), IDEA can get slow. I’ll end up typing faster than it can echo characters.

Despite those things, I find IDEA somehow hits a sweet spot where I’m actually working with the code, not the editor (the old ready-to-hand vs. present-to-hand distinction). With other tools, I felt more friction.

When I was first courting Dawn, she taught me two surgeons’ mottos:

Get in, get done, get out

Minimize time, trash, and trauma

(”Trash”, here, is foreign material introduced into the body.)

I’ve been fond of repeating these, but I now realize the first one is bad advice for programmers. It should be:

Get in, get done, improve, get out

You see, while a surgeon is in there fixing one problem, she might also fix another one she discovers, but there’s not really any practice like refactoring. Maybe there ought to be, since your body is a gross kludge, but there isn’t.

The un-amended version of the motto puts too much weight on time and will almost certainly lead to a slow decay of the code.

The second motto, then, should be something like:

Minimize time and trauma,
but don’t forget to pick up any trash lying around

Not nearly so catchy.

Agile 2008 will be arranged around the metaphor of a music festival. There will be a main stage for the big-draw speakers, the larger tutorials for novices, etc.

I was asked to do a stage about testing that wouldn’t help shunt people into silos. (It shouldn’t be “the testing mini-conference”.) I decided the stage would take seriously the usefulness of explicit, concrete examples—executable or no—in the thinking about, construction, and post-construction investigation of software-ish things. Hence the logo:

(more…)

I like reading the Unclutterer site, in more of an aspirational than practical way. Inspired by their survey of reader workspaces, I present mine. I’ve recently finished optimizing its physical and musical environment with four decent to excellent products. If you crave pampering your proprioception and hearing, read on.

(more…)

Jason Gorman:

Contrary to - well - pretty much the entire software industry, I don’t believe that a software architect is someone who designs software. I believe that a software architect is someone who recognises a good software design when he sees one.

A Rails homage to the “I’m a Mac” commercials (via /\ndy)

The Wall Street Journal published an editorial containing this graph:

In what possible universe could you honestly fit that curve to that data? Who could, without shame, publish a curve that goes around the bulk of the data? One that goes through an obvious outlier? (Tukey’s brilliant and eccentric Exploratory Data Analysis counsels us to understand outliers before worrying about the “central tendency”. I wonder if the anonymous editorialist wondered what might be special about Norway? Perhaps a particular natural resource, drilled from under the ocean? If only there were a tool one could use to find information about that resource’s contribution to Norway’s GDP or any special tax rate applied to it!)

But, self-doubting liberal that I am, I can’t only conclude that unsigned Wall Street Journal editorials are written by people whose preferences and loyalties have made them—to use the precise academic terminology—bullshitters, people to whom the truth is completely irrelevant. I have to wonder to what degree I do the same thing, to what degree my own comfort and self-interest has led me to push back against the whole post-Agile thing, despite my respect for Jonathan Kohl and Jason Gorman.

Fortunately, I have morphing software to play with, so I can cut self-reflection short.

Hat tip to Economist’s View

Suppose you’re a person with a bad short-term memory doing test-driven design. (You’d be me.) You’d want to have both the test source and corresponding product code source visible at the same time, and probably several other files as well. Here’s a mockup of such a configuration:

To this novice user, TextMate doesn’t seem like it wants you to be doing that. For example, apple-t doesn’t remember visits to separate windows, so when I want to visit “that file I was just in”, I have to remember whether it was in a tab or a window and use either apple-t or apple-`. But the reason I have separate windows is I have no memory for such things.

However, I’m early enough in the Emacs->TextMate switch that I’m sure I’m missing many things. How do you use TextMate on big screens? I couldn’t find stories on the web, so perhaps this blog entry can help the next person searching “textmate big screen” or “textmate cinema display”. Even better, I’ll make screencasts of tricks and put them on the TextMate wiki.