Another Rails Conf Talk Released

I'm loving ScribleStudio's coverage of the RailsConf2006 Keynotes.

One of the questions to the Rails core team was 'do you guys hate fixtures?' or something like that. I was amazed that they too dislike them. DHH summed it up well... to paraphrase.. Fixtures shouldn't be shared across tests, but they are so hard to set up that you end up doing it anyway, which doesn't scale. The cost of making fixtures needs to be lowered. They didn't have any ideas how to do this.

This make me recall my suggestion from a few days ago... instead of fixtures, define an object mother (some class that can generate test data for you given some criteria) and dependency injection or some other terse mechanism to specify your context for your test.

Looking at the way rSpec is going, this maybe the best condender for this sort of thing. I'll keep thinking about it. Keep tuned to see any further developments.

... and as always feel free to leave comments

DSLs in Ruby

There are two approaches to writing DLSs, Internal and External to the implementation language.

With internal DSLs the ruby parser is used (eg. ActiveRecord). It is surprising just how much you can personalise your language and still remain within the syntax of ruby.

see 'Creating DLSs In Ruby'

External languages require you to write a parser. This sounds hard, but there are a few libraries available that simplify the process. Check out multi and sexp gems.

see 'If It's Not Nailed Down, Steal It'

More on BDD

Dave Astel gave a talk on BDD for Google.
check it out...

Introduction to BDD (Behaviour Driven Development)

BDD is an evolutino of TDD. Those that are doing TDD correctly are aware they are writing in code small specification documents. The code is then written to meet the specification, then the code is checked automatically against the specification using a tool that understands both documents. To call these specifications tests is backwards, as there is nothing to test at the point they are written. More importantly as tests they have an implied scope (unit tests test methods on classes one at a time). If you write specifications instead, then a different scope seem far more appropriate (eg. In context X these things should be true.)

When I first heard about this concept the implementations of frameworks were nothing more than Nunit and Junit with the names changed. Looking at rSpec however things have come along well. Yet again Ruby lends itself well to creating a DSL. In this case for code specification.

Here is an example from rSpec's "RSpec on Rails".

context "The Person model" do
  fixtures :people, :animals

  setup do
    # fixtures are setup before this
  end

  specify "should find an existing person" do
    person = Person.find(1)

    person.should_equal people(:lachie)
    person.name.should_equal 'Lachie'
  end
  
  specify "should have animals" do
    people(:lachie).should_have(2).animals
  end
  
  teardown do
    # fixtures are torn down after this
  end
end

I love it!

Check out Dave Astel's great introduction to BDD.

SVN Berkley DB Lock

The server's drive got full and that broke subversion last night. The Berkeley databases got locked and wouldn't unlock. I couldn't do an svn recover \repository\path as it wouldn't release the lock.

Finally I realised all I needed to do was reset the svnserver service.
I lost a good hour of my life looking for solutions, hopefully you won't have to.

xUnit with a twist

Imagine nUnit coupled with Object Mother and dependency injection.

You would be able to write a test and specify the test objects you wish to manipulate by adding parameters to the method.

[Test]
public void adding_a_task_to_a_project_causes_the_tasks_predicted_start_date_to_be_set( IProject mockProject, Task washCloths )
{
// ... test stuff as normal
}

Parameters with the name 'mockX' could cause mock instances to be created. 'washCloths' would be an example of a named instance, so a specific instance of task would be created in a known state. 'anyProject' could return a simple project instance.

Just a thought... but I like it.

Now there is no excuse not to try Ruby!

Check out http://tryruby.hobix.com

It's a ruby interactive tutorial in a browser (thanks to 'why the lucky stiff')

Buildix: Development Infastructure in an instant

Check out Buildix.

Subversion, Cruise Control, Tracs all preinstalled and running from a KNOPPIX disk.

IDEA: Bleeping Media Player

"Cutting out the Naughty Bits Ruled Illegal" on slashdot today refers to a case where people were creating DVDs of special edits of films with the sex scenes, bad language, etc. cut and swapping them for original dvds.

Personally I feel there is a market for a device (or initially media player) that can gain access to bleep tracks for movies, cd's etc and use them to (at runtime) modify the output of the player.

So imagine... you buy your daughter a new music cd. You have previously configured her player to her age group. When the player gets to track 6 (which unknown to you contains the f word) it blanks the word (or play some substitute mp3 to patch it) . In a DVD with explicit content it could blur the screen, or cut the scene or whatever.

The community could create the patch-tracks and make them downloadable for each media... by default the player could dissallow anything not on the list.

This would only work for youngsters that are not able to buy their own player, but those are the ones you would want this for anyway.

It doesn't infringe copywright or anything, so all legal. :) It solves the same problem.

OSX keyboard shortcuts

Here's a list of keyboard shortcuts for OSx.

I was looking for 'Cycle to next windows of same application' which turned out to be Control + `

New MacBook

I recently got a new MacBook (duel core OSX).. so far I am loving it!. It's so much faster than my old PC laptop (which wasn't that quick anyway, so thats not saying much). In other words, all the Rails stuff generators etc run in seconds (or fractions there of) not minutes. I am getting used the different window paradigm. Learning the new key mapping seems the hurdle. I used to use linux back at uni (in 1994) so terminal is like an old friend. I love the software installation process (drag things from mounted drives to the applications directory). it is so light! I can hardly feel I am carrying it around. My old laptop powersupply probably weighed the same as my macbook. Things I would change are:

The mouse sometimes seems to freeze for a second after switching application. The screen is wide, but small, so the text is tiny. I think i would have appreciated getting the Pro with the larger screen. The macbook doesn't have enough space for my hands to rest while I type so my palms get a bit sore resting in the sharp corner the edge of the machine presents when open.

Another big win is knowing that if I shut the mac, no matter what is running it will hibernate. With windows if I had a browser open or webrick running it somtimes failed to hibernate. This meant I had to sit there attempting to hibernate it and killing processes till it worked. Not ideal.

Oh and battery life! My laptop was down to about 1hr before it died. The macbook lasts abount 3 to 4 hours, so thats a big improvement.

All in all, I am very happy with it.

Rails Hint: Database changes from script/console

You can make database changes from script/console like this...

ActiveRecord::Schema.define do 
  drop_table :follies 
end