If small children are going to wake me up early, I might as well post links.

• Refinery – Another entry in the Rails CMS sweepstakes.
• Make your shoulda tests faster with fast_context – Pratik offers a technique for speeding up shoulda if your setups are bulky.
• CouchDB-Lucene, CouchDBX, and CouchRest – Not my cup of tea but perhaps yours.

Scooter and I stuffed our craws with a delicious medley of lobster ‘n’ sirloin last night, which got me thinking. Surf ‘n’ Turf is a catchy menu item and all, but what else did that enterprising restauranteur cross off the list before he coined the phrase (on a napkin, no doubt) back in 1967? Why didn’t he go with:

hay ‘n’ bay
cowbell ‘n’ shell
straw ‘n’ claw
pet ‘n’ wet
bovine ‘n’ brine
calf ‘n’ bath
steak ‘n’ lake
Bessie ‘n’ the sea
cultivated land ‘n’ sand
oxtail ‘n’ shrimp cocktail
rumination ‘n’ crustacean
beef ‘n’ reef
grill ‘n’ krill
cud ‘n’ mud

I’m just saying.

If your place of employment is still considering whether to allow languages besides Java and C++ in-house, I believe the area of unit testing can be a great place to start experimenting and having fun. JRuby in particular is a great way to blend the scalability of the JVM with the concise expressiveness of Ruby. If you want to try it out in a test environment before writing a full blown application in JRuby on Rails, for example, I’ll be discussing some JRuby test tools that you can use to boost your TDD experience. Perhaps your boss will come to appreciate the readability of the code and encourage more use of JRuby in the future.

In my last post, I mentioned how you can *measure* the quality of your code. That is a great technique for finding specific trouble spots in your code; you might have duplicated code, you might have an over-complicated algorithm, or you could simply perform the same task with fewer branches and fewer lines of code with a new design.

After you take the time to generate these metrics, you need to be able to make use of the data. Some people get defensive about what the metrics might say about their code. This is a common reaction among junior software developers. I have noticed that people tend to warm up to constructive criticism with more experience. The only way to improve your understanding of programming and to develop yourself as a professional is to understand what you are doing wrong, and then take steps to improve those areas.

Think of these metrics as a set of huge neon arrows pointing at some of the most problematic areas of your code base. Perhaps you as an individual understand some really clever technique in your code, but imagine if you needed to explain it in a code review or make changes to it 6 or 9 months from now. Would you really still understand it? Could it be written better? Are the code metrics knocking on your door to ask you to revise it? If so, it is a good idea to make sure you don’t break anything else when trying to improve that part of the code.

If you and your team have adopted TDD or BDD and have stuck to it on your greenfield project, then you are in great shape. You have some benchmarks in place to measure processing time, you may have clearly defined requirements, and you know when one of your acceptance tests will fail. You probably have a huge set of tests, with 80% code coverage. That’s how the world would work if it was perfect…. Wait, this doesn’t match your situation? Unfortunately, this is another point at which teams get defensive. “There wasn’t enough time when we started the project.” “TDD is unrealistic and too dogmatic. I’m more _agile_ and I need to be able to change my code quickly.” (Have you ever noticed the word “agile” is often used incorrectly, and has become a buzz word?) To truly be agile, you need to both be able to change your code to adapt to new requirements or make optimizations, and at the same time ensure you are not introducing a new bug in the process.

Whether you and your team are in the first camp (continuous integration with critical code covered) or in the second camp (no tests, just “production” testing)… or somewhere in-between, there are some great tools available to you to improve your testing experience.

Test::Unit
The xUnit tool had its beginnings with Smalltalk, and seems to be the most ubiquitous testing tool across developers from different generations and languages. It involves creating a set of test suites consisting of test cases. Each test case is a large set of methods beginning with test_, and each test method is supposed to focus on a particular aspect of your code. Here is an example that tests an instance of an Amounts class. The amounts instance acts as an accumulator that can be queried for average “win” (positive) values, “loss” (negative) values and total

require 'test/unit'

class AmountsTest < Test::Unit::TestCase
  def setup
     @amounts = Amounts.new
  end

  def test_something
     @amounts.clear
     assert_equal( 0, @amounts.total )
     assert_equal( 0, @amounts.average_win )
     assert_equal( 0, @amounts.average_loss )
     assert_equal( 0, @amounts.average )
     assert_equal( 0, @amounts.average { |value| value % 2 == 0 } )
  end

  def test_with_one_negative_amount
     @amounts.clear
     @amounts.add( -5 )
     # perform more assertions...
  end

   def test_with_one_positive_amount
     @amounts.clear
     @amounts.add( 2 )
     # perform more assertions...
   end

   def test_with_multiple_positive_amounts
     @amounts.clear
     @amounts.add( 3 )
     @amounts.add( 2 )
     # perform more assersions...
   end

   def test_with_multiple_negative_amounts
     @amounts.clear
     @amounts.add( -7 )
     @amounts.add( -2 )
     # perform more assersions...
   end

   def test_with_multiple_mixed_posistive_and_negative_amounts
     @amounts.clear
     @amounts.add( -8 )
     @amounts.add( 5 )
     @amounts.add( 2 )
     @amounts.add( -1 )
     @amounts.add( 13 )
     # perform more assertions
   end

   # this is beginning to get tedious...
end

Every test method is able to share a tiny setup method, but each test must make sure it is working with an empty version of itself by clearing out the instance before setting up some data in the instance it is testing with. This almost makes the initial setup method useless, as it would be just as easy to simply recreate the instance every time. Also note how it begins to get fairly tedious to write code to clear out the instance and add more values to the @amounts object in each test. You could write helper methods to set up your data, but then you run the risk of losing connascence of location, and the test data could become too separated from the test itself.

Another thing that is lacking is the elegance of a DSL for testing. All these steps involved in setting up an object and running static-like assertions against results. It does the job of testing for accuracy, but this solution doesn’t really do a great job of telling the user of the API (or just yourself 6 months down the road) why it behaves the way it does. If you agree, you are not alone. Many other developers have noticed this shortfall and have longed for something better.

Along came RSpec, a gem that allows Ruby/JRuby developers to use a DSL for describing examples of the expected behavior of the domain object. You can get started with it by

gem install spec

. The documentation for RSpec includes a basic example of a scenario between you and a customer, and how that could be translated into a DSL based test with RSpec:

#You: Describe an account when it is first created.
#Customer: It should have a balance of $0.

describe Account, "when first created" do
  before(:all) do
      @account = Account.new(:balance=>0)
  end

  before(:each) do
      @account.balance = 0
  end

  it "should have a balance of $0" do
     @account.balance.should == 0
  end

  # ...
end

RSpec also introduces what appears to be its own syntax to testing, which is sort of a controversial concept in the testing. Do you really want to confuse other developers by using an unfamiliar set of test functions, when they already have enough to worry about when they are trying to learn your codebase?

When RSpec sees ‘be_’ in a matcher (after ’should’), it looks for a method with a name that follows ‘be_’ and has a ‘?’ at the end. In this case ‘be_lower_case’ makes RSpec look for a method called ‘lower_case?’ and calls it. That is clever, but I actually find that syntactic sugar to be a little distracting. By using clever tricks like this, it can make your tests read more like human language, but ask yourself this: Do you want to test your API, or do you want to test the code that is testing your code? When your test breaks as a result of a code change, it is better to spend time on testing the code and not worrying that it might be that your test is the ‘thing’ that is broken.

Don’t get me wrong; RSpec is a great tool and gets us closer to BDD, but I think it tries to go one step too far with the matchers. Domain experts don’t speak in ‘plain english’, like the purist BDD evangelists would like. As PragDave explained, they speak jargon, a specialized set of vocabulary used by industry experts to communicate in whatever language they know. It seems a bit strange to attempt writing tests in almost_but_not_quite_english directly_in the(code). It makes me think too much about the language of testing rather than the code I am testing.

So is there a happy medium? I think that there is. On my quest to find a great set of tools for testing, I came across Thoughtbot’s Shoulda. Forgetting about some of the nice helper methods for integrating with Rails and ActiveRecord, I simply wanted to use Shoulda for creating extremely readable (and easily writable) unit tests in a DSL style format. Shoulda consists of test macros, assertions, and helpers added on to the Test::Unit framework. It‘s fully compatible with your existing tests, and requires no retooling to use.

sudo gem install thoughtbot-shoulda --source=http://gems.github.com

One of the really cool (and highly pragmatic) features of Shoulda is its use of nested contexts. To quote (Prag)Dave Thomas, “the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. And shoulda keeps track of it all, so I get very natural error messages if an assertion fails.”

class UserTest < Test::Unit::TestCase
    context "A User instance" do
      setup do
        @user = User.find(:first)
      end

      should "return its full name" do
        assert_equal 'John Doe', @user.full_name
      end

      context "with a profile" do
        setup do
          @user.profile = Profile.find(:first)
        end

        should "return true when sent #has_profile?" do
          assert @user.has_profile?
        end
      end
    end
  end

Produces the following test methods:

“test: A User instance should return its full name.”
“test: A User instance with a profile should return true when sent #has_profile?.”

The example above was ripped right off from the Shoulda website for a quick, clear example of what is going on. I thought Shoulda’s readability and simplicity just blended well with how my mind works, but really, the choice is yours. I think the fact that it also blends seamlessly with test/unit is a huge plus. You can combine it with regular test cases if you’d like (but why would you, other than to be backwards compatible?).

Conclusion
In the end, what seems to work really well for me and my team is a best-of-all-worlds approach. Test/Unit is a very recognizable test framework that developers with diverse language backgrounds are all familiar with, so it seems like a natural starting point. Plenty of tools are available to automate the running of those tests in a continuous integration environment and visually reporting the results of passed/failed tests in an automated way. I should note that RSpec also has ways of hooking up into automated tools, but it does require a (very small) additional step, usually a Rake task to hook into.

I love the way Shoulda works seamlessly with test/unit, and makes test cases more readable and understandable. A killer feature of Shoulda is the concept of nested contexts, which keeps your tests extremely DRY, and allows you to read the contexts almost as if they were full sentences that describe an entire use case of your application.
Finally, I really like having the ability to use the “should” method from RSpec, but only in a way that keeps the test code extremely readable (and writable). In the end, whatever frameworks and libraries you choose to use (and choose not to use) will help you improve your code style, your coding accuracy, and your ability to communicate the intention of your code among other individuals.

Remember, every test you spend time writing today will save you time in the future. Each test you write is like a little guardian, protecting you from mistakes made by others, and even mistakes made by yourself. The initial work is definitely worth the effort involved. If you are looking to gain respect from your peers in your profession, you owe it to yourself and those around you to treat your profession with respect and hone your craft by your pursuit of continuous improvement of your code and of yourself.

Full Example Mixing Test/Unit, RSpec and Shoulda

class AmountsTest < Test::Unit::TestCase
  # instance_methods "<<", "average", "average_loss", "average_win", "description", "size", "success_rate", "total"
  context "An Amounts instance" do
    setup do
      @description = "B"
      @amounts = Prices::Amounts.new(@description)
    end

    should "describe itself" do
      @amounts.description.should == @description
    end

    should "have a total of 0 when first created." do
      @amounts.total.should == 0
    end

    should "have a size of 0 when first created." do
      @amounts.size.should == 0
    end

    context " after adding an amount that is positive " do
      setup do
        @single_amount = 4
        @amounts << @single_amount
      end

      should " have a total equal to the single amount." do
        @amounts.total.should == @single_amount
      end

      should " have an average win equal to the single amount." do
        @amounts.average_win.should == @single_amount
      end

      should " have an average loss equal to 0." do
        @amounts.average_loss.should == 0
      end

      should " have a success rate of 100% " do
        @amounts.success_rate == 100
      end

      should "have a size of 1." do
        @amounts.size.should == 1
      end

      should "have a total of single_amount." do
        @amounts.total.should == @single_amount
      end

      context " and adding another amount that is negative " do
        setup do
          @another_amount = -3
          @amounts << @another_amount
        end

        should " not have a total equal to the other amount. " do
          @amounts.total.should_not == @another_amount
        end

        should " have a total equal to the single_amount and another_amount. " do
          @amounts.total.should == (@single_amount + @another_amount)
        end

        should " have an average_win of the first single_amount " do
          @amounts.average_win.should == @single_amount
        end

        should " have an average_loss of another_amount " do
          @amounts.average_loss.should == @another_amount
        end

        should " have a success rate of 50%" do
          @amounts.success_rate.should == 50
        end

        should " have an average( any_not_nil ) of (single_amount + another_amount)/2.0" do
          @amounts.average { |any_not_nil| any_not_nil}.should ==
                                        ( (@single_amount + @another_amount) / 2.0 )
        end

        should "have a size of 2." do
          @amounts.size.should == 2
        end

      end
    end
  end
end

Source: http://railstips.org/2009/4/20/how-to-add-simple-permissions-into-your-simple-app-also-thoughtbot-rules

user = User.new
user.email? # => false
user.email = 'foobar@foobar.com'
user.email? # => true

user.admin? # => false
user.admin = true
user.admin? # => true

module Permissions
  def changeable_by?(other_user)
    return false if other_user.nil?
    user == other_user || other_user.admin?
  end
end

class Score < ActiveRecord::Base
  include Permissions
end

class Photo < ActiveRecord::Base
  include Permissions
end

class User < ActiveRecord::Base
  include Permissions
end

<%- if score.changeable_by?(current_user) -%>
  <li class="actions">
    <%= link_to 'Edit', edit_score_url(score) %>
    <%= link_to 'Delete', score, :method => :delete %>
  </li>
<%- end -%>

class ScoresController < ApplicationController
  before_filter :authorize,  nly => [:edit, :update, :destroy]

  private
    def authorize
      unless @score.changeable_by?(current_user)
        render :text => 'Unauthorized', :status => :unauthorized
      end
    end
end

class ActiveSupport::TestCase
  def self.should_have_permissions(factory)
    should "know who has permission to change it" do
      object     = Factory(factory)
      admin      = Factory(:admin)
      other_user = Factory(:user)
      object.changeable_by?(other_user).should be(false)
      object.changeable_by?(object.user).should be(true)
      object.changeable_by?(admin).should be(true)
      object.changeable_by?(nil).should be(false)
    end
  end
end

class ScoreTest < ActiveSupport::TestCase
  should_have_permissions :score
end

class ScoresControllerTest < ActionController::TestCase
  context "A regular user" do
    setup do
      @user = Factory(:email_confirmed_user)
      sign_in_as @user
    end

    context "on GET to :edit" do
      context "for own score" do
        setup do
          @score = Factory(:score, :user => @user)
          get :edit, :id => @score.id
        end

        should_respond_with :success
      end

      context "for another user's score" do
        setup do
          @score = Factory(:score)
          get :edit, :id => @score.id
        end

        should_respond_with :unauthorized
      end
    end
  end

  context "An admin user" do
    setup do
      @admin = Factory(:admin)
      sign_in_as @admin
    end

    context "on GET to :edit" do
      context "for own score" do
        setup do
          @score = Factory(:score, :user => @admin)
          get :edit, :id => @score.id
        end

        should_respond_with :success
      end

      context "for another user's score" do
        setup do
          @score = Factory(:score)
          get :edit, :id => @score.id
        end

        should_respond_with :success
      end
    end
  end
end

has_attached_file :image,
  :styles => {:thumb => '100>', :full => '480>'},
  :default_style => :full,
  :convert_options => {:all => '-rotate 270 -strip'}

Source: http://www.thoughtbot.com/projects/shoulda/

Installation

sudo gem install thoughtbot-shoulda --source=http://gems.github.com

Usage

Context Helpers

Stop killing your fingers with all of those underscores… Name your tests with plain sentences!

class UserTest < Test::Unit
  context "A User instance" do
    setup do
      @user = User.find(:first)
    end

    should "return its full name" do
      assert_equal 'John Doe', @user.full_name
    end

    context "with a profile" do
      setup do
        @user.profile = Profile.find(:first)
      end

      should "return true when sent #has_profile?" do
        assert @user.has_profile?
      end
    end
  end
end

Produces the following test methods:

"test: A User instance should return its full name."
"test: A User instance with a profile should return true when sent #has_profile?."

So readable!

ActiveRecord Tests

Quick macro tests for your ActiveRecord associations and validations:

class PostTest < Test::Unit::TestCase
  should_belong_to :user
  should_have_many :tags, :through => :taggings

  should_require_unique_attributes :title
  should_require_attributes :body, :message => /wtf/
  should_require_attributes :title
  should_only_allow_numeric_values_for :user_id
end

class UserTest < Test::Unit::TestCase
  should_have_many :posts

  should_not_allow_values_for :email, "blah", "b lah"
  should_allow_values_for :email, "a@b.com", "asdf@asdf.com"
  should_ensure_length_in_range :email, 1..100
  should_ensure_value_in_range :age, 1..100
  should_protect_attributes :password
end

Makes TDD so much easier.

Controller Tests

Macros to test the most common controller patterns…

context "on GET to :show for first record" do
  setup do
    get :show, :id => 1
  end

  should_assign_to :user
  should_respond_with :success
  should_render_template :show
  should_not_set_the_flash

  should "do something else really cool" do
    assert_equal 1, assigns(:user).id
  end
end

Helpful Assertions

More to come here, but have fun with what’s there.

assert_same_elements([:a, :b, :c], [:c, :a, :b])
assert_contains(['a', '1'], /\d/)
assert_contains(['a', '1'], 'a')

It’s rare to come across a company that produces eyewear so unique and forward-thinking and have them not be from NYC/Paris/Tokyo/Etc. Denver, CO based, Shoulda Eyewear produces the finest of spectacles handcrafted from solid wood and available in a wide-vareity of designs ($300-$500). Classic wayfarer models all the way to what is pictured here. Check out Shoulda’s gallery for more. And if you don’t find anything there, the company prides itself on creating custom designs based on your specifications.

End of the month, hooray. If you’re not madly rushing to meet deadlines, you might enjoy some of these links.

What to write. What to tell. What to share. Gather my thoughts. Put the words together. Put the sentences together. Create a story out of the words and the sentences. Or write an allegory. Or maybe a poem.

The thing is; I am so bored and empty that none of my stories are close to be put in words. I could tell you about the places I have traveled to. I could tell you about all the places I have ran away to. I could tell you about the endless green fields and the villages on Turkey’s Black Sea coast I have been dreaming about for ages. I could tell you about how it feels to fly coast to coast  above my emotional landscapes, not knowing where to touch down. I could tell you about the beauty that lies in between the opposites that/who never meet. I could tell you about ice cream breaks. I could tell you about my friend who had an emotional breakdown the other day and ended up doing an oil painting of me. I could tell you about how much it made me miss him. I could tell you about the abandoned, silent island. I could tell you about happiness. I could tell you about misunderstandings. I could tell you about evening sun. I could tell you I am amazed by the way Siri Hustvedt manages to put everything in words, even the things you did not know you thought about. I could tell you about getting on trains. I could tell you about getting off trains. I could tell you about how people manage to pass each other, not knowing when to get on and off the train. I could tell you that we all should be handed with road maps and time schedules, just so we don’t get caught by fate when we stumble on our way. I could tell you how much I romanticize Lucy’s mom who used to sit awake all night in the dark smoking cigarettes and listening to jazz records. I could tell you that I love to do the exact same thing, because it makes me calm and happy, not sad and lonely, like Lucy’s mom must have felt. I could tell you how good it feels it sit in a park listening to the sound of a city. I could tell you that I need something to ease me through the minefield of becoming too cynical. I could tell you about my best friend who thinks I have already become too cynical.

I would tell you about the strange, little things that have happened lately if I only knew how.

Well, what do you know, I did manage to write something after all. Better than nothing, I would say.

Hey

Det var ÈN deilig dag på skolen i dag… Studietid (leksetid), Kunst og håndverk to timer, time uten noen lærer pga. mangel på vikarer, og en siste time med dramatisering… Så det var ikke stor stress!

Men det er deilig da, i og med at vi hadde en såppass slappe-av helg denne uka… Vi hadde fri torsdag og fredag og halve onsdag pga. eksamen… Som jeg fikk 5+ på!

Akkurat nå har jeg stått og danset med headset på hodet, og jeg tenker å lage en ny koreografi…
Denne gangen til “Should’ve let you go” av Keyshia Cole… Jeg ELSKER sangen, så mye følelser

Hva syns du? Jeg tror det blir bra

Men nå skal jeg legge meg!
Jeg som hadde målet å legge seg før 00:00 på hverdagene… HM…

Oh, and…Rails 2.3 RC2. Go forth and test.

It was a pretty busy weekend in the Rails world (and other spots that I hang out online).

Well, after joining the Rails Activists and the creation of ActionRails, I can finally complete my trifecta of Big Announcements for the year: I’m co-authoring Rails 3 In Action, to be published by Manning late this year. UPDATE: No, as it turns out, I’m not. For various reasons, I’ve dropped out of that book project.

Webrat is library to write acceptance tests for ruby web applications. I also like shoulda for its context. However using the two in conjunction has been little fun. I wanted to multiple sessions testing. Following is the code I used to get it done using shoulda and webrat. It might turn out to be useful example for some.

require File.dirname(__FILE__) + '/../test_helper'

class UserStories  'some@one.com'
      fill_in "password", :with => "idunno"
      click_button
      assert_equal '/session', path
    end
  end

  context 'A User' do
    setup do
      visit "login"
      assert_response :success
      fill_in "email",:with => users(:tom).email
      fill_in "password", :with => "123456"
      click_button
      assert_equal '/profile', path
    end

    should 'be able to login with valid email and password' do
      visit 'forums/new'
      assert_response :success
    end
  end

end

Have I mentioned lately that we’re available for hire? Well, we are.

Its been a while since I have been using shoulda and its pretty awesome addition to your rails TDD artilery. Of what little I have known of  it has helped me to write my own first shoulda macro.

Here it is

module ThoughtBot
  module Shoulda
    module Controller
      module Macros
        # :section test macro
        # macro creating test asserting that actions requiring login are redirected to login
        def should_request_login(action, params = {}, method = :get)
          context "#{method.to_s.upcase} on #{action.to_s} " do
            setup do
              case method
              when :get
                get action, params
              when :post
                post action, params
              when :put
                put action, params
              when :delete
                delete action, params
              end
            end
            should "should redirect to login" do
              assert_response :redirect
              assert_redirected_to new_session_path
            end
          end
        end
      end
    end
  end
end

I am working on few more. May be I may post them sometime later.

Looking forward to a Monday of massive code merges. If “looking forward” is the right word for it.

Courtenay started it, stating that his team stopped using rSpec, saying

We wasted a day or two (three, maybe four developers) which equates to several thousand dollars in wasteage. It was also really infuriating — the culmination of a few years of frustration of rSpec’s weirdnesses.

They left rspec and used rr, context, and matchy instead. Many other favorite library proposed in the comments.

Josh Susser compared rSpec with shoulda and test/spec in his The Great Test Framework Dance Off.

David Chelimsky responded and stated that some of Josh’s criticism was true, but

What Josh didn’t know at the time, and this is definitely worthy of a ding for us not documenting things well enough, is rspec’s simple_matcher method that let’s you create simple matchers in just a few lines. Here’s the example in test/unit from Josh’s talk:

def assert_sorted(actual, message=nil, &block)
expected = actual.sort(&block)
assert_equal expected, actual, “Order is wrong:”
end
assert_sorted(tags) { |a,b| a.name b.name }

And here’s the same thing with simple_matcher:
def be_sorted
simple_matcher(“a sorted list”) {|actual| actual.sort == actual}
end
[1,2,3].should be_sorted

Dan Croak from Toughtbot fame spoke up also, criticizing another BDD tool, Shoulda, stating that, like rspec, it adds complexity to achieve virtually no result, comparing it to test/unit that is already included in Ruby core library, faster, and simpler.

Later, Pat Maddox refutes it, stating that sometimes a tool is not just a tool. That is, TDD / BDD does do something important. Making him keeping his responsibility

It is my responsibility to keep existing code working, to improve existing code to make it more maintainable, and to write new code that functions and is maintainable. The best way I’ve found to do this is to do TDD. It’s not the only way, of course, just like GTD isn’t the only system for managing your workload. But it’s proven to be pretty damn effective.

“CSI: Crime Scene Investigation” brings back the miniature killer to the screen in an episode called “Woulda, Coulda, Shoulda”. One of the most notorious killers who produces the biggest mystery for the CSI team, Natalie Davis aka The Miniature Killer is being decided on her fate when Grissom is called to testify at the competency hearing of her.

Also, the murder of a mother and her young child appears to be connected to a suspect in a CSI investigation from over a decade ago. The murdered woman was once married to a man who went for a killing spree. “The West Wing” Joshua Malina guest stars in the November 20 episode.

On other news, it has been announced through a press release that Laurence Fishburne will enter the show as well-known criminal pathologist Dr. Raymond Langston in the December 11 episode which is called “19 Down”. In the episode, the team will discover a link between a new murder and the infamous “Dick and Jane Killer”. Fishburne is added to the cast in preparation of short-handedness the quarter will experience when William Petersen who plays Gil Grissom quits the show the end of this year.

Download CSI: “Woulda, Coulda, Shoulda” Free

OpenID is pretty well established as a login infrastructure, but a topic often ignored is correctly letting the user change his saved OpenID. Don’t just save the text they enter! Verify that they’ve entered their valid OpenID.

The user model needs to pass this test:

should_have_db_column :new_openid_identity, :type => 'string'

The view on /account/edit needs to pass this test:

context "logged in" do
  setup { session[:user_id] = Factory(:user).id }

  context "GET to edit" do
    setup { get :edit }

    should "have a form for their OpenID info" do
      assert_select 'form[action=?][method=post]', openid_path do
        assert_select 'input[type=hidden][name=_method][value=put]'
        assert_select 'input[type=text][name=?]',
                      'user[new_openid_identity]'
        assert_select 'input[type=submit]'
      end
    end
  end
end

And, most importantly, the OpenidsController needs to pass the test suite in gist 23084.

(All these tests assume FactoryGirl and Shoulda; re-write in RSpec or PyUnit or whatever as you see fit.)

You’ve heard the phrase before. I could have done this. He should have done that. I would’ve finished but . .

Well baby – talk’s cheap. I’m trying to get rid of the should and the could. Better to deal with reality and what is instead of making up a thousand and one excuses for yourself and those around you. Your actions and the actions of others are reality. Sure you could work out, and you probably should work out. But unless you take action and get off the couch you can could and should forever.

This week’s column on Singe Minded Women is on becoming aware of all the could’a, should’a, would’a in your daily dialogue (spoken and unspoken). Check it out and give it a try.

http://blogs.singlemindedwomen.com/?cat=1594

 

Test All The Fucking Time é o título de uma Lightning Talk que Brian Liles fez na Ruby Hoedown 2008.

São apenas 12 minutos, onde a mensagem principal é: Test All The Fucking Time!

Vale a pena assitir!

Menu: Chipotle-stuffed turkey burgers * sweet potato oven fries with chipotle ketchup * sauteed spinach

Burgers
Ground turkey
Sea salt
Garlic
Chipotle peppers in adobo

Mix pack of ground turkey with sea salt and garlic. Shape into patties; cut in half horizontally and place a small chipotle in the center. Grill until done. During last few minutes. add reduced-fat Mexican cheese on top to melt.

Fries:
Cook sweet potato oven fries according to package (I used Alexia frozen ones; 425 for 20 minutes).

Chipotle ketchup:
Chop two chipotle peppers in small bowl; add some of adobe sauce. Mix with tomato ketchup to taste; add 2 tsp balsamic vinegar.

Spinach:
Heat 2 T olive oil in large non-stick skillet/wok, on high. Add baby spinach; saute until wilted. Grind sea salt and garlic over.

Would I make it again?
Not quite the same way. The chipotle was too hot, though M liked it a lot. I might stuff cheese with the chipotle. I might just use the chipotle ketchup and leave out the pepper entirely. I’d also wanted to make a jicama-Granny Smith slaw or other salad, but ran out of time and energy. Big afternoon at work, pretty tired. So glad to sleep in in the morning.

__________________________________________________________________________

Vendredi 13 juin 2008

Sun 93 – Sparks 98

Etincelantes

Sidney Spencer plante un trois points à 1’18 de la fin de la prolongation auquel Kiesha Brown ajoute 4 lancers francs et une interception et les Sparks de Los Angeles s’imposent 98-93 face à la meilleure équipe de ce début de saison 2008.

Brown égalise son record de passes décisives en carrière avec 11 réalisations tandis que Lisa Leslie atomise la raquette du Sun de Connecticut avec 22 points et 10 rebonds. Le cinq majeur est à nouveau très prolifique. DeLisha Milton-Jones marque 20 points bien suivie par Marie Ferdinand-Harris et ses 19 unités (record en saison). LAS jump à 6-2 et remporte leur 4^ème succès lors des 5 dernières rencontres. « Mes coéquipières sont à créditer pour mes 11 passes » insiste Brown, « elles ont rentré leurs shoots. Nous savions que nous aurions l’avantage sur le Sun à l’intérieur. Nous en avons bien profité grâce à nos joueuses poste bas (Leslie, Jones et Candace Parker) […] C’était juste une question d’ambition et d’exécution. »

Pourtant le Sun à tout fait pour résister malgré son désavantage de taille. Lindsay Whalen marque 20 points et attrape 7 rebonds et 4 interceptions. Mais tous leurs efforts la série de 5 victoires consécutives prend fin (8-2). Asjha Jones et Tamika Whitmore ont chacune ajouté 18 points. « Contrairement à notre match contre Phœnix et notre prolongation contre Indiana, nous n’avons pas perdu notre basket en fin de rencontre » analyse coach Cooper en conférence de presse, « ça a été très important pour nous. »

Pourtant Connecticut accusait déjà 14 points de retard dans le premier quart temps. Le Sun est revenu à 93-91 avant que Spencer rentre un trois points pour les locales et les fasse virer en tête d’un point. « Candace (17 points, 9 rebonds et 4 passes) a placé un bon écran et DeLisha m’a trouvée » déclare Spencer, « elles [Sun] faisaient attention à Parker donc elles ont mis un peu de temps à faire leur rotation défensive et à me couvrir. Le tir était totalement ouvert. » Puis Brown vole un ballon à 22.9 secondes du buzzer, reçoit une faute de Whalen et rentre ses deux pénalités (18.9 secondes à jouer). Milton-Jones touche et dévie ensuite un rebond des mains de Whitmore. Brown reçoit deux nouveaux lancers francs qu’elle convertit (0.7 secondes à jouer). « C’est l’un de ces matches où l’on évite les « woulda, coulda, shoulda » avoue Mike Thibault, coach des leaders à l’est, « les filles doivent comprendre que les petits détails sont de grandes choses. Je n’ai pas aimé nos séquences défensives vers la fin du match. »

Fortes d’un nouveau succès de rang après la victoire face au Shock de Détroit, LAS apparaît de nouveau comme un favoris au titre suprême. Rendez-vous ce week-end pour une visite dans la capitale californienne pour en découdre avec un ennemis intime : les Monarchs.

Scoreboard à la fin du match

Médias

Versus Sun

Retrouvez les photos du match dans le forum en Cliquant ici

La vidéo du jour

Candace Parker Has the Best Rookie Debut in WNBA History

Prochain rendez-vous Samedi 14 juin
Sparks @ Monarchs

Srces: CL/NBA/Espn/LAT

“Why can’t America realize that falling in love with Kobe doesn’t mean breaking up with Michael?” Rick Reilly

__________________________________________________________________________