The intersection of development and UI is an area I've got some interest in. Arena just shared this amazing article about a team's experience merging Agile project management with User Research and testing.

User Research as a Commodity (part 3 of 7) by Tim Kieschnick

Here (below the fold) are some of the things in the article I found eye-opening.

Good Scrum diagram. Suitable for XP too (replace "sprint" with "iteration" and "daily scrum" with "daily standup").

Courtesy of Mountain Goat Software

Courtesy of Steve C and Alex Tabarrok

There is no "W" in "team"

Writing and Testing JavaScript-Heavy Web 2.0 Apps with JSUnit

Alex Chaffee & Edward Hieatt (presented by Alex Chaffee and Brian Takita)

JsUnit

Edward Hieatt (presented by Alex Chaffee)

CI for the Web 2.0 Guy or Gal

Chad Woolley

Full-stack web app testing with Selenium and Rails

Alex Chaffee and Brian Takita

Here's an RSpec trick I discovered yesterday. Sometimes when you're writing a test you want to loop over some precondition data. But if you do a loop inside your test (or spec), then all the cases will be subsumed in a single test method (or "it" block). This means you'll have the following problems:

• The first case to fail will cause the rest of the cases not to run. It'd be nice to see them all in a single test run.
• You won't take advantage of RSpec's cool self-documenting trick of labeling each it block with a full description of the failure, and it'll be harder to debug which case failed.
• If you're calling into Rails (e.g. in a View spec), you'll only be able to call certain methods -- especially render -- once per test method. That means that you simply can't use a loop inside a method to collapse redundant tests into a single block.

Ruby to the rescue! Instead of looping inside your it block, loop outside your it block.

1. Introductions. Anybody new? Any guests in the room?
2. Help! Anybody need assistance?
3. Neat! Interesting things we want to share.
4. Status. Only if there's time -- project or individual reports.

(Based on Standup 2.0.)

Brian Takita and Alex Chaffee gave a presentation at the SDForum Silicon Valley Ruby Conference over the weekend, entitled Full-stack web app testing with Selenium and Rails. We're going to do it again at Agile 2007 (and we'll have an extra half-hour next time, so we'll have time to do some interactive pairing with some hapless audience member).

Here are the slides, courtesy of SlideShare:

| View | Upload your own

I just gave a talk at the Web 2.0 Expo with Leslie Chicoine of Satisfaction. We shared our insights into the challenge of integrating foundational design methods (interaction design, usability design, interface design, interaction design) into a team doing Agile development (rapid releases, week-long iterations, high feedback and communication). It was a lot of fun! The room was packed, the energy was high, and they laughed at our jokes!

Here are the slides:

You can also see the slides here at SlideShare. Let me know what you think!

Mark and I were just waxing poetic about how great it is to delete code, especially code you just wrote. We pity the attitude of people who think deleting code is somehow wrong -- they feel so guilty that they won't even delete it right off, they just comment it out, and then check it in... We came up with the following simile:

Writing code is circling your way around a solution, like a dog on the hunt. When you're done, the final solution is going to be a lot smaller than your original perimeter.

This reminds me (Alex) of my favorite quote about writing: "Murder your darlings," said by Sir Arthur Quiller-Couch... or was it..?

We're experimenting with running our Capistrano deploy onto a Mac Mini. Note that this is Capistrano running Net::SSH running ssh protocol and spawing a remote shell in which we execute commands. Unfortunately, the remote process can't find the svn binary. Even though running echo $SHELL returns /bin/bash, it's not executing any of the startup scripts we know about (~/.bashrc, ~/.bash_profile, /etc/environment, /etc/profile, etc.), and the PATH is remaining the boring standard one (/usr/bin:/bin:/usr/sbin:/sbin). Damon says there's a setting inside the sshd config that might help...

UPDATE: this was solved by setting

PermitUserEnvironment yes

in /etc/sshd_config, and then setting

PATH=/bin:/sbin:/user/sbin:/usr/local/bin:/usr/local/sbin:/opt/local/bin:/user/local/mysql-standard-5.0.24-osx10.4-i686/bin

in ~/.ssh/environment

Apparently the Rails rules for pluralizing controller names has changed. Recently the tendency seems to be to use plural names for RESTful controllers (e.g. GET /projects/42) rather than singular names for traditional controllers (/project/show/42). Is this intentional? Is it a new convention, or a change to the old one, or a violation?

We're having a Brown Bag today on Ruby Foo, covering many strange and wonderful topics, including class methods, singleton classes, lexical scoping, and the lambda calculus. And why the sea is boiling hot, and whether pigs have wings.

Words of wisdom: when you're modeling currency, don't use floats. This is a bad idea in the long run since floats might store $2.50 as 2.50000001. See Coda Hale's dollars_and_cents plugin. Ian adds: "Database tables for currency should be of type decimal. (e.g. amount DECIMAL(10,2)) This turns into a BigDecimal in your AR object, which is a bit of a pain, since it doesn't act exactly like a regular number. We talked about mixing in some methods into BigDecimal, to make it behave more like a regular numeric type. It feels weird coming from a Java background, and normal coming from a Smalltalk background. I'm curious what people's thoughts are on it."

Today is the Group Hug for our latest release of Tracker. Get ready to try to kill Tracker with love!

We like RSpec, and are ready to upgrade to the new version. There's a new style for the DSL; the old and new dialects will live side-by-side for a while but we should convert to use the new one soon.

Daylight Saving Time is coming up, and already it's causing some of our tests to fail: we had code that calculated the number of days between two dates. Turns out the implementation assumed that every day has 24 hours in it. Not so! March 11, for instance, will have 23 hours, and November 4 will have 25. That's in the US; see here for other countries.