PLoP 2007 final call

                        CALL FOR PARTICIPATION (final)

    14th Conference on Pattern Languages of Programs (PLoP 2007)

      September 5-8, 2007 - Monticello, Illinois, USA
                   http://hillside.net/plop/2007/

                *Early Registration till 19th August*
        http://hillside.net/plop/2007/index.php?nav=registration

Read the rest of this entry »

Programmer products

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.

Office with Boots
Read the rest of this entry »

Caring about software, public goods games, and our present state

Jason Gorman wants people to pledge that they care about software and that they’ll act on that caring. An impressive roster of people have signed the pledge. So why do I feel discouraged? It’s because of this:

[I pledge to] Offer moral and practical support to those who care as much as I do to help them do the right thing

What does that mean? How will it play out?
Read the rest of this entry »

Functional testing tools workshop

Agile Alliance Functional Testing Tools Visioning Workshop
Call for Participation
Dates: October 11 - 12, 2007
Times: 8 AM - 5 PM
Location: Portland, Oregon
Venue: Kennedy School

Description
The primary purpose of this workshop is to discuss cutting-edge advancements in and envision possibilities for the future of automated functional testing tools.

This is a small, peer-driven, invitation-only conference in the tradition of LAWST, AWTA, and the like. The content comes from the participants, and we expect all participants to take an active role. We’re seeking participants who have interest and experience in creating and/or using automated functional testing tools/frameworks on Agile projects.

This workshop is sponsored by the Agile Alliance Functional Testing Tools Program. The mission of this program is to advance the state of the art of automated functional testing tools used by Agile teams to automate customer-facing tests.

There is no cost to participate. Participants will be responsible for their own travel expenses. (However, we do have limited grant money available to be used at the discretion of the organizers to subsidize travel expenses. If you would like to be considered for a travel grant, please include your request, including amount needed, in your Request for Invitation.)
Read the rest of this entry »

Fluid.rb 1.0.1 released

Class Fluid provides dynamically scoped (”fluid”) variables modeled after those of Common Lisp. It also gives you a convenient way to reversibly change the values of globals.

Fluid variables are useful when you want to pass information among related classes and methods without passing arguments all over the place, but you also want something a little more controlled than globals. They’re not useful all that often, but they come in handy once in a while.

The documentation (rdoc) gives more explanation and examples, such as the code that produces this amazing, never-before-seen feat of prettyprinting:

What is working software?

A tester is delivered supposedly-finished code that has nothing ready to test:

Half the functionality of a new feature has been introduced - the other half has not yet been completed. However the developers say this is working software because what was handed over works. But it’s no use to a beta customer site - can’t really show it to a user - can’t really test it as there is no flow. It’s a bit like saying a car ‘works’ when it has no back axle but please test away anyway because the front wheels are fine. Is there a definition of ‘working software’ anywhere?

I answer:

My definition: a feature is working if some person somewhere would be willing to pay more for the software with the feature than she would for the software without it.

Another way of putting it: at the end of every iteration, you should be able to sell the software for more money than you could at the beginning.

Sounds like your feature isn’t working.

As Chet Hendrickson pointed out in the thread, the trick is getting good at breaking Grand Ideas down into bite-sized chunks that can be implemented quickly but still do something useful. That can be hard to learn, but I’ve been impressed when I see it done well—impressed enough that I’ve come to the working assumption that it’s always possible. If you can’t see how to do it, that just means you don’t have enough experience and haven’t learned enough tricks of the trade.

Steve Gordon added:

If stories are split architecturally (horizontally), then the “working software” is quite like what you describe. If stories are sliced vertically (i.e., it does work end-to-end, but only for a few scenarios), then it is more useful for testing, feedback, and validating the architecture. Vertical slicing is what is recommended, but developers tend to think in components, so it is much easier for them to split stories into one for each component instead of figuring out which scenario (sometimes, a trivial one) they could actually do end-to-end through all the components within a single iteration.

In my experience, defining small stories is one of the toughest things for the product director to learn. Building an architecturally coherent system in small slices is one of the toughest things for programmers to learn.

As Jeff Patton has pointed out, there are dangers to small slices: it can be tricky to make everything hang together into a coherent, usable system. (See his span planning, for example.) Perhaps incorrectly, I emphasize getting good enough to be dangerous.

Everyday Scripting utilities at Rubyforge

Everyday Scripting with Ruby comes with a library, anachronistically called s4t-utils. It’s mainly used behind the scenes to simplify working with scripts, but it also has a pile of utilities I use frequently.

By putting s4t-utils in a script’s third-party folder, a script writer can hand out her script as a single zip file and not force people to install different bits and pieces. (Rubygems handles collecting and installing multiple bits, but (1) using gems would require my scripters to make gems, and (2) they’d also have to run a local gem server for their local gems.)

However, if you’re making gems anyway (like I’m doing these days), s4t-utils might as well be another gem your gem depends on. So s4t-utils is now available from Rubyforge and thus via gem install --remote s4t-utils.

This version has a few small additions. It also has documentation of the general-purpose utilities.

Quicksilver notetaker

For any number of purposes (exploratory testing, writing bug reports, getting examples for user’s manuals), I would like the following plugin to Quicksilver. It would be somewhat similar to the iGTD plugin.

  • Invoke Quicksilver with its keystroke. Type ‘.’ to start writing a note. Write the note, strike one or a few keys to send it to the notetaker. The notetaker appends it to the open document.

  • Invoke Quicksilver. With a few keystrokes, cause it to Grab a snapshot of the topmost window and append it to the document. (So the document handler has to be something that can handle pasted images. Note: if it matters, Pages will paste the image when you put an image on the clipboard and hit Paste. Word and OpenOffice give you the URL in that case. To get the image, you have to Paste Special. In either case, it would probably be best to use a different pasteboard than the one ⌘S uses.)

How hard could it be?

Test planning documents

I’m going to start copying my replies to questions on agile-testing here.

I am interested in hearing how people that don’t think a Test Strategy should exist go about answering the following questions and when they do it. […]

  • Number of testers required—including what skills they need (i.e. (Performance, Security, Domain Knowledge, Technical Knowledge) and where they will come from (current employee’s, contractors etc)

  • Environments, especially for new projects. What is going to be needed, how much will it cost, when will it be required. (Some hardware can take 6-8 weeks to source)

  • Data—what data will be used, where will it come from, privacy concerns

  • External/Dependant requirements—for example will real users be involved in UAT/Usability Testing? When will they be involved? (If it is “general” public this needs time to organise, if they are in another country/offsite do you want someone to be there to monitor/oversee what they are doing). Is a usability lab going to be used? Does the product need to be benchmarked by an external company? When? etc.

  • Software/Tools—if anything needs to be purchased this should be highlighted.

Read the rest of this entry »

Stand and deliver! - a hug

This is bizarre.

The Guests Were Enjoying French Wine and Cheese on a Capitol Hill Patio. When a Gunman Burst In, the Would-Be Robbery Took an Unusual Turn.