Exploration Through Example

While I’m talking about Ruby in Emacs, here’s a handy emacs function I wrote way back when. Suppose you’ve just run a test and it’s failed. I’ve highlighted the location of the failing assertion below. If you navigate to that line and type ^h^h, you’ll jump to that line in the other window.

^h^h isn’t specific to either tests or shell-mode. It works anywhere there’s a line in Kernel#caller format.

Here’s the code:

(defun ruby-visit-source ()
  "If the current line contains text like '../src/program.rb:34', visit
that file in the other window and position point on that line."
  (interactive)
  (let* ((start-boundary (save-excursion (beginning-of-line) (point)))
         (regexp (concat "([ tnr"'([< {]|^)" ; non file chars or
                                                      ; effective
                                                      ; beginning of file
                         "(.+.rb):([0-9]+)")) ; file.rb:NNN
         (matchp (save-excursion
                  (end-of-line)
                  ;; if two matches on line, the second is most likely
                  ;; to be useful, so search backward.
                  (re-search-backward regexp start-boundary t))))
    (cond (matchp
           (let ((file (buffer-substring (match-beginning 2)
                                         (match-end 2)))
                 (line (buffer-substring (match-beginning 3)
                                         (match-end 3))))
             ; Windows: Find-file doesn't seem to work with Cygwin
             ; /// format or the odd /cygdrive// format
             (if (or (string-match “//(.)(.*)” file)
                     (string-match “/cygdrive/(.)(.*)” file))
                 (setq file
                       (concat (substring file
                                          (match-beginning 1)
                                          (match-end 1))
                               “:”
                               (substring file
                                          (match-beginning 2)
                                          (match-end 2)))))

             (find-file-other-window file)
             (goto-line (string-to-int line))))
          (t
           (error “No ruby location on line.”)))))

;; I bind the above to ^h^h, an odd choice, because that’s easy to
;; type after reaching the line with ^p or ^n.
(global-set-key “^h^h” ‘ruby-visit-source)    

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.

I am disgustingly overweight. I would so kick me out of bed for eating a cracker. Hence the return of graphing my weight, as you see above. The embarrassment of displaying my lack of discipline to intellects vast and cool and unsympathetic is apparently what motivates me best.

I’m too embarrassed to show the starting weight.

In my work with wevouchfor.org, I’ve been learning Rails. Rails is increasingly leaning toward REST. In REST, you’re encouraged to think of your site as containing piles of different kinds of resources. (Your database backend encourages the same thinking.) Rails makes implementing standard operations on those resources the path of least resistance. For example, tell Rails that one of your resources is an article, and—boom!—you immediately get these methods (from p. 410 of Agile Web Development with Rails):

Look in articles_controller.rb, and you’ll find a skeleton for the index method (produce a list of all the articles), the create method (to add a new article to the database), and so on.

Ah… working with ease. But is it the right work? In my case, this ease of work was one of the things that led me away from what I should have been concentrating on: who’s the most important user of the website, and what’s the most important thing she wants to do? As it turns out, it’s none of the REST operations. As I merrily filled in the blanks Rails gave me, I was not doing the most important thing first, and I think it likely that I was leaning toward a worse user experience.

Gojko Adzic has a nice summary of what Jeff Patton’s been saying recently about a way Agile projects fail.

My only quibble with Jeff’s description is that he distinguishes between “incremental” and “iterative” development. That has the same problem that’s bedeviled “verification and validation” for years: the common English words mean sort of the same thing, and the words begin with the same letter, so many people (me, Jeff himself when it comes to V&V) can’t remember the difference.

At SDTConf, I suggested that Jeff use “assembly” for “incremental” and “growth” for “iterative” (or is it the other way around?)

The Agile2008 submission system is now ready for use. The deadline is February 25th. However: we’re not gathering up submissions for one big review at the end. Instead, committee members and anyone else who wants to will post comments on a submission soon after it arrives. You can keep revising and improving your submission until the deadline.

At James Bach’s request: testing needs incisive and restless thinkers.

UPDATE: As requested in comments to the original posting, the context:

In the late 90’s and early 00’s, I was a vigorous proponent of the Context-Driven school of testing. As was typical of members of that school, I was intensely interested in test design, which I’d define as “thinking well about how to execute the app in order to fulfill the testing team’s goal.” (My favorite goal being to be “a service organization whose job is to reduce damaging uncertainty about the perceived state of the product.”) Also: people thinking well about anything deserve respect, more respect than testers got. So I was an advocate for the worth of tester as an identity.

Since then, especially since around 2003, my interests have drifted to the point where I now refer to myself as “having a testing slant” rather than “being a tester.” (And, more and more, I use the word “examples” rather than tests to remind myself that I’m not doing what I used to do.) I’ve also emphasized tendencies I’ve long had that didn’t come into play as much in my testing days. For example, I’m much more focused on harmony and trust and deferring to others than I used to be (although that tendency can be seen way back in 1998’s “Working effectively with developers“).

There’s a problem when someone who used to write exclusively about X stops. Does it mean that he repudiates X? Am I now happy if testers have low status? Do I think that testers who don’t code are useless? Do I think manual testing is rote work that doesn’t require incisive thought?

I could argue that I haven’t completely stopped writing. If you look at my recent test design links post, you’ll find links to a bunch of writings squarely in the context-driven tradition, and such linking signals approval. Still, it doesn’t hurt to be completely explicit, especially because (1) I write a lot about automated tests, (2) test automation comes with a lot of historical baggage and so is an emotionally charged topic, and (3) the early interactions between the Agile proponents and testers generated even more baggage because the Agile proponents often did act exactly like we testers were used to programmers acting: dismissive. Fortunately, that’s mostly corrected itself. But still… hurt feelings persist.

Because of all that, the original statement seemed useful.

An interesting commentary on the problem of global identifiers, via Michael Tsai. In a nutshell, global identifiers are for the benefit of the implementer, not the user. For many practical purposes, users care about many fewer people than implementers do, and they’re happy to identify those people idiosyncratically.

[…] this approach uses the social network to manage identity, by reducing the size of the problem space by about seven orders of magnitude. It’s perfectly feasible to keep track of the identity of a few hundred people using familiar attributes like names, faces and personal relationships: humans have been doing it for literally hundreds of thousands of years.

I myself am lukewarm on Facebook, but I’m finding Twitter oddly appealing for one of my jobs, keeping track of what interesting communities exist and where they’re going next. More on that later. (My twitter account.)

I had a thought at the Simple Design and Test conference.

“Simple” is an adjective, but there are different kinds of adjectives. For example, one might point at a can and say that the adjective “blue” applies to it. That use of the adjective is objectively true, at least in Richard Rorty’s sense: we use the adjective “objective” to describe those statements it’s pretty easy to get people to agree about. The harder it is to get people to agree, the more subjective the statement.

However, suppose the can contains iced coffee. I claim that the adjective “tasty” does not apply, but other people would disagree. Here’s an adjective that quite clearly depends not just on the object it labels but also on the person doing the labeling.

Finally, consider a bed labeled “comfortable”. To be more specific, suppose it’s a waterbed. A waterbed might be extremely comfortable for sleeping, but someone I trust tells me it wouldn’t be comfortable when making love, and I’m quite sure that no waterbed would be a comfortable platform for doing deadlifts. Here we have a case where the suitability of the adjective is bound up with both the person applying it and the activity they’re thinking about.

I claim that “simple”, when it comes to “design and test”, is most like the third category. In a way, when we say “that’s a simple design”, what we should be saying is “that design lets me do actions X, Y, and Z without friction and with ease.”

So: when we talk about what properties make, say, a design “simple,” we’re using shorthand: “I’ve noticed that property X is usually associated with designs that make activities A, B, and C easy.” The fact that we have a hard time getting people to recognize or desire simple designs suggests that we maybe ought to focus on understanding and explaining the activities over capturing the properties.

I’ve been growing a little disillusioned with my graphical workflow tests: implementing the test support code seems like a lot of work for little benefit. (It has nothing to do with the graphics—I’d have to write the same methods in a FitLibrary DoFixture or if I wrote the workflows directly in Ruby.)

So it was with a heavy sigh that I began to create this test:
Read the rest of this entry »