Previous code will update the content of tag with “addressPreviewStatus” id with ‘Address Not Found’.

But how can we spec that out ? I needed to search a little as there seems to be very little examples.

First in rails there is a special assertion assert_select_rjs, merged from the assert_select plugin, it let you test your RJS with a syntax similar to RJS itself.
RSpecOnRails has a special matcher wrapping assert_select_rjs : has_rjs.

You can use it on response to specify what should be generated, for exemple you can :

# Specify response should contains an update or insert of some kind
response.should have_rjs
# Specify response should contains an update or insert for the tag with given id
response.should have_rjs('id')
# Specify response should contains a specific update, insert, etc. for the given tag
response.should have_rjs(:replace, 'id')

You get the point. Now, a nice syntax allows you to write RJS this way :

render :updatedo |page|
page['id'].update('replacement text')
end

So my first try was to use :

response.should have_rjs(:update, 'id', 'replacement text')

but this fail miserably with an error Unknown RJS statement type update. I tried different syntax but none worked.

Finally browsing through source of assert_select_rjs I found what I was looking for. When using this syntax you should use one of :chained_replace or :chained_replace_html depending what you want to test :replace or :update.

Here’s a quick tips for those of you using Leopard Spaces functionnality. If you want to move a window from one “space” to another simply drag the window to the right/left/top or bottom edge of the screen (depending to which “space” you want to put it in) just like if wanted to put it out of the screen and wait a second.

Spaces should automaticaly switch to the next “space” and the window still be under your cursor. Drop it there or reiterate to move it to another “space”.

I installed this monday Git 1.5.3 and discovered a new functionality I find worth sharing : stash.

Basically, stash grab your current uncommitted changes and put them away until you want to reapply them. Git documentation for git-stash lists two examples where this comes in handy :

Pulling into a dirty tree

I’m sure you already had the nightmare it is that you started working on a new functionality when a change you need appears in the upstream repository. Your current changes conflicting with the upstream’s ones git pull does not work. Here come the stash, simply issue a git stash (or git-stash, with an optional description message as you can have multiple stashes), then git pull to include the upstream changes and finally git stash apply to re-integrate your latest stashed modifications.

Interrupted workflow (this one talk to me so much)

You’re working hard on some new kick-ass features when someone (your boss / client) come in and want this immediate fix in what it call a critical bug. One solution is to commit your changes to a new branch, correct the fix, commit it, rebase the new branch to the head with the fix, and then merge back the changes. I’m sure you already see the power of stash in such cases. No more in a hurry branches and commits, simply stash your changes, correct the bug, and reapply the stashed changes.

I encountered a little problem today, I use macports version of coreutils which gives me access to gnu versions of some commands (for full list : sudo port contents coreutils | grep /bin). My problem is related to one of those I’m using in my bashrc to color my shell : dircolors (gdircolors in macports).

This little commands allows you to generate LS_COLORS values (as the name seems to imply, it’s used by ls command) from a config file (~/.dir_colors in my case). I confidently modified this file today and was welcomed by a nice csh: Unknown colorls variable `su'.
It turns out there are an incompatibility between LS_COLORS generated by current version of dircolors in coreutils and (t)csh : tcsh treat LS_COLORS as a magic environment variable, which means it is parsed for its own use in ls builtin command.

The culprits in my .dir_colors file was :

#SETUID 37;41 # file that is setuid (u+s)
#SETGID 30;43 # file that is setgid (g+s)
#STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w)
#OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
#STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable

As you can see a simple fix is to comment them out.

In fact I’m not sure why I see those errors poping up, as I’m using bash ans it’s now the default in MacOSX.