Jonathan.inspect

RubyGems mirror update

My RubyGems mirror just got an update :

• switch to rubygems 1.9.5 0.9.5
• index generation

If all goes well, it should be compatible with older rubygems versions and give a significantly boost to those using rubygems >= 1.9.5. 0.9.5

RSpec and Inline RJS

Rails give us the ability to write inline RJS via render :update syntax, as in :

render :update do |page|
  page['addressPreviewStatus'].update 'Address Not Found'
end

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 :update do |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.

Now here is the solution :

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

Leopard Spaces Tips

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”.

Javascript BDD (2)

Just a quick add-on on my previous post, I found there was already a nice BDD framework for javascript : JSSpec.

Go see the demo page, it looks really nice.

Javascript BDD

It was a long time since I delved into Scriptaculous subversion repository. This morning I was browsing it to find out what’s coming for next versions (seems 2.0 is not so far away) and had a good surprise : it seems they add BDD to their test framework.

I must admit my last try to use TDD for my Javascripts do not last long and this is a great reason to try again but this time BDD-Style.

To give you a little overview of what it looks like here’s a snippet extracted from the specs for the BDD framework itself :

Test.context("BDD-style testing",{
  
  setup: function() {
    ...
  },
  
  teardown: function() {
    ...
  },
  
  'should provide extensions to tie in isSomething and respondsTo object methods': function(){
    ...

    testObj.shouldBe('nice');
    testObj.shouldNotBe('broken');
    
    testObj.shouldRespondTo('isNice');
    testObj.shouldRespondTo('isBroken');
  },
  
  'should automatically add extensions to strings': function(){
    'a'.shouldEqual('a');
    'a'.shouldNotEqual('b');
    'a'.shouldNotBeNull();
    'a'.shouldBeA(String);
  }
}

If you’re using RSpec it should (woot!) looks familiar.

Git 1.5.3 : submodule

Here’s another new functionality introduce in Git 1.5.3 : submodule.

Submodules allows you to manage subparts of a project in different git repositories and reference them in a “superproject” repository.

You can see it as an equivalent to Subversion “externals”.

A simple usage exemple (in your “superproject” root) :

git submodule add http://mygitdomain.tld/my_sub_project
git submodule init
git submodule update

1. This will add the remote my_sub_project as an entry in .gitmodules and a directory named my_sub_project in your “superproject”.
2. Then initialize all modules added, this means add them to .git/config
3. And finally clone and checkout the different modules in their respective directories (created by the git submodule add command)

[Update – 2007/12/05]

I forgot to add you should not work directly with the “superproject” git repository besides adding more submodules.

You should clone the “superproject” git repository first and then the submodule part will be usable.

git clone superproject superprojectcloned
cd superprojectcloned
git submodule init
git submodule update

and work from “superprojectcloned” repository.

Then when you want to include the last versions of the submodules, issue :

git submodule status
git submodule update

1. status, gives you an overview of the submodules state.
2. update, fetch the latest version and reference the sha1 associated.

Git 1.5.3 : stash

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 :

1. Pulling into a dirty tree

1. Interrupted workflow (this one talk to me so much)

(t)csh and dircolors problem

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.

[Windows reminder] Registry editor

Windows+r (shortcut to ‘Run’ window)

regedit