Exploration Through Example

Some questions on the submission process for Agile 2008, passed along by an Example stage committee member.

What the heck is a “stage” anyway?

I am thinking of a stage as a “conference within a conference.” It’s like a stage at a large music festival, where there’s a particular physical location where you might go to hear blues. (Plug here for Karen Carroll.) Buy a pass to the music festival and you can wander among the stages, seeing what you like. Or you might decide to hang out at a particular stage with people who share your particular obsession.

The “stage producers” have a lot of leeway in how they organize their own particular stage. That’s why the answers below should be considered specific to our stage.

How will the submissions be reviewed? What constitutes a good submission?

The first stage reviews will be public, on the submission website. The purpose of the website is to help the submitter hone the submission into its best possible form.

After submissions are closed, I’m planning to have something similar to what’s done at many software conferences:

1. Everyone votes on the submissions she’s read, using a four point scale:
   A: I will champion this submission (argue vigorously for its inclusion).
   B: I support this submission, but it wouldn’t break my heart were it not included.
   C. I think this submission should be rejected, but I could live with it being accepted.
   D. You have got to be kidding! Accept this?

   Most submissions will have a near consensus. The interesting cases are those where you get one A and four C’s (or A’s and D’s).

2. It’s possible that the number of clear accepts fits exactly within the space boundaries we have. More likely, we’ll need to make some choices. These get made in a phone conference. The structure of the conference depends on the submissions and how they match up with our available space. Here’s one possible scenario:

   We have five open slots. There are also five interesting disagreements. We discuss them. In two cases, the negative votes agree to accept. In one, we decide that we’ll provisionally accept if the proposer adds some particular improvement.

   Now we need three other cases (two definite accepts, one if the provisional accept falls through). People propose sessions from among the pool of ones that no one’s either strongly for or strongly against. Which sessions do they propose? Probably it depends on how they stack up against the already-accepted sessions: does a not-yet-accepted session complement or nicely contrast with one we’ve already got?

What keeps this from being a popularity contest, where only the most well-known names get accepted?

All of you reviewers do. The visibility of the submission process should help. If some Big Name writes a sketchy submission that displays no effort (which happens more than I’d like) and we accept it, the shame of it will follow us the rest of our lives.

There is an argument for accepting Big Names: it draws attendees to the conference, some attendees (especially first-timers) are more likely to listen to them, and it gets people who most likely are Big Names for a reason to the conference, where they can wander the hallways dispensing wisdom. Since this stage is for an oddball topic where there are no big names, that argument does not apply to us.

How will the sessions be compensated? Do they all get the same
compensation?

This is supposed to be on the website (there’s text saying so), but I couldn’t find it. Bug has been reported. Here’s what was once the correct information:

2. Here's the compensation for speakers, it's still based on session type.
  * Tutorial/Discovery session: 90 min: USD 250, up to 2 free
registrations, 5 night hotel, 1 room ; 180 min: USD 500, up to 2 free
registrations, 5 night hotel, 1 room
  * Experience Report/Research Paper: 1 free registration
  * Panel: moderator: free registration, 5 night hotel; panelists: free
    registration
  * Main Stage presenters (formerly known as talking heads): USD 700, free
    registration, 5 night hotel, 1 room
  * Free registrations and free hotel nights are non-transferable and
non-accumulatable.

This does not cover “other.” Compensation for other will be handled case-by-case. Here’s the way I think about it:

1. Things that are normal for conferences (presentations) get one free registration.

2. Things that require substantial extra work or require special expertise in crowd management or are popular enough that they will help sell the conference get free registrations and some amount of hotel rooms and money.

3. Panels get compensation way in excess of the effort required. But they’re popular among attendees, so they’re worth paying for.

How complete should a proposal be when I first submit it? What’s
considered to be “complete”?

It should be complete enough to entice a modestly public-spirited committee member or interested reader to take the time to write helpful suggestions.

“Complete for final consideration” means that every idea you (the submitter) have for improving the session or improving your argument for the session seems like more trouble than it’s worth.

That sounds like I’m being flippant, but I’m not. I don’t think completeness is something you can know a priori. You construct what completeness means by moving toward completion.

A more helpful answer might be this: does the submission describe enough that a reader can imagine what it would be like to attend that session? what they can (best case) leave with?

What’s the definition of the various “session types” - Demonstration, Experience report, Panel, Talk, Tutorial, Workshop? Does my submission have to be one of these?

Here are my understandings:

• A demonstration is where you show an audience something. The thing is traditionally a tool in use. (”Here’s how Watir works.”) It can also be a demonstration of a technique. (”Watch as I use session-based testing on this here app.”)

• An experience report is the result of some personal experience over an extended period of time (most typically a complete project). The goal is that the audience understands what happened and what the presenter learned, and that they can map that experience onto their own.

• Panel is a moderator plus N people, all sitting on the stage at once. What happens then is up to the moderator. Typically the moderator explains the topic, then each of the N people says something about it. Then the moderator may ask provoking questions, and the panelists talk about them. Typically questions are taken from the audience, and the panelists try to say something interesting and profound.

• A talk is a presentation like a demonstration or experience report, but it doesn’t fall into one of those categories. Like them, audience participation is usually limited to questions after the talk.

• A tutorial is a longer session where the presenter is someone specially qualified to teach a particular topic (preferably both an expert in the topic and with considerable experience teaching). Tutorials usually have some “experiential” component where people practice what has just been explained. Participants come to a tutorial to learn, in some detail, what someone else already knows.

• A workshop (aka Discovery Session) is organized by someone who thinks not enough is known about a particular topic and wants to do something about it. So, in contrast to a tutorial, there’s not the metaphor of knowledge flowing out of a teacher’s mind into the minds of a pile of students. There is a group of more-or-less peers creating new knowledge. Sometimes this is through some form of structured discussion. But there’s often an experiential component: a lot of learning by doing.

I am personally most interested in workshops and experience reports.

[The] consensus [of people she was speaking to] was that this year’s process heavily favors previous presenters, more so than in other years. They felt the lack of definition of sessions, lack of criteria by which sessions will be reviewed, and wide reviewership makes this year’s game nothing but a popularity contest; new folks need not apply.

Now that I think about it, what I see is a bias toward regular conference goers more than regular presenters. I think the (implicit) persona is someone who’s been to conferences and has had one of these reactions:

1. Why did no one talk about X? I guess I’ll have to do it.

2. I know as much about Y as anyone who presented. I guess there’s an audience for what I know.

3. I’ve got this fuzzy idea about Z. As far as I can tell, everyone’s fuzzy about Z. But at least there will be thoughtfully fuzzy people in Toronto next year - I need some mechanism to get them together so that we can figure this thing out better.

Whether a particular stage turns into a popularity contest depends on two things:

1. Do people just vote on proposals or do they make helpful comments?

2. Does the selection committee pay more than passing attention to the votes, or do they spend time reading and thinking about the comment threads to reach an informed opinion?

I don’t think our stage will.

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 begun work in earnest on Ruby Scripting for Leopard. I’d like to assemble an audience who can review drafts and tell me what people like them need. I’ve set up a mailing list.

The one sentence description of the book is “How to do anything AppleScript can, but in Ruby.” That is, the main focus will be using Ruby to control other apps like Mail or Safari. It’ll also show you how to write code that makes use of Mac framework features (like sending Growl notifications and putting controllers for your scripts in the status bar). It won’t be your definitive guide to RubyCocoa, though. Most likely I won’t talk about Xcode or Interface Builder at all.

The book will assume no experience scripting Macs (or anything else). I’d like some helpers who fit that category, but also people with lots of experience.

Readers should know Ruby, but I haven’t decided how much. Certainly you needn’t be an expert. Anyone who knows Ruby to the level of my earlier Everyday Scripting with Ruby is definitely in the audience.

Thanks.

I wanted to write a script that used Growl to notify a user. That user could click on the Growl sidle-up, and that would make the script do something. It took me a while to figure out callbacks from Growl to the originating app, so I thought I’d write it down.
(more…)

A transcript of an OOPSLA talk: Table of contents

A post by Clarke Ching finally nudged me to finish this Latour series. Here’s the key excerpt:

The bad news is that I think we are about to fuck it all up because (according to my jaded view of the world) we - the agile community - are focusing on the wrong things. We are focusing on optimising our technical skills (the bits we are naturally good at), but we are ignoring the skills we really need to foster within our community. What are these skills? I’d like to call them marketing and sales skills, but I think they’ll be better received if I call them “influencing” skills.

I’d like to disagree in the sense that I think things are even worse. Latour shows how.
(more…)

Maintenance & Optimization download

Folic Acid containing products.

Mouse Drivers download

Video Forum

Photoshop Plugins & Filters download

Zydos pharmaceutical products

Firefox Add-ons & Plugins download

Video Forum

Video Forum

Video Forum

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.