An annual production of 4,000 unit will be up by late 2012. Great! Oh, just in case you’re worried about security, listen to Deborah Blackwell, spokeswomen of Hyperion: 

“Like you don’t open a double-A battery, you just plug [the reactor] in … You don’t ever open it or mess with it.”

Right, just don’t mess with it! Deborah, ever watched a malicious 7 year old while not opening a double-A battery just to find out what’s in there?

But i guess they will solve that easily by only allowing people with an nuclear reactor license to install the hot tub in their homes. As that already works so well to keep hand guns in the rightful hands. The hands of the god loving people, in the land of the brave and the free.

have fun

Technorati Tags: clean, nuclear, power, USA, climate

%w{ff00ff 00ff00}.map{|a|a.scan(/../).map{|b|b.hex}}.inject{|c,d|(0...c.size).each{|i|c[i]+=d[i]};c}.map{|e|"%02x"%(e>>1)}.join

#121 character solution by schmidt(http://www.nach-vorne.de)
%w{ff00ff 00ff00}.map{|a|a.scan(/../).map{|b|b.hex}}.inject{|c,d|c.size.times{|i|c[i]+=d[i]};c}.map{|e|"%0x"%(e>>1)}.join

assert_raise(StandardError) { @blog.find_post(:postid => 123456789) }

to generally check for any kind of trouble bubbling up but it was not working as expected. Instead i got nasty Failure reports:

1) Failure:
test_find_post(XMLRPCTest) [mylib.rb:83]:
<StandardError> exception expected but was
Class: <XMLRPC::FaultException>
Message: <"Sorry, no such post.">

I suspected XMLRPCTest::FaultException to maybe not beeing derived from StandardError, but that was not the case. A look in the ruby documentation and the ruby-talk thread confirmed:

assert_raise(*args) {|| ...} is checking for the EXCACT exception type only!

How was it for you?

On the ruby-talk mailing list there was a little discussion about this topic and i pretty much agree with all the +1 sayers on the list. Edwin Fine propsed adding his own assert_raise_s method the Assertions class. You easily get into muddy waters with opening standard ruby classes for some duck-typing but reverting to:

assert_raise(XMLRPC::FaultException) { @blog.find_post(:postid => 123456789) }

was not an option. This would expose way to much implementation detail to this very high level coding of the very first tests so early in the project. So I was using the source, as yoda said and found another solution for me.

Modules as base class arguments to assert_raises

After i read Edwin’s post i checked the source for def assert_raise and learned that this method is actually checking for some kind of exception base class. The argument to assert_raise is an array of exception types. assert_raise does partition this types into Class and Module.

The assertion_raise checks for Class types is exact, but the Module is not(can’t be). They are checked with an is_a? condition – there can’t be no object instance of module type or course.

My original test therefor simply fails because StandardError is not a Module but a class. The XMLRPC::FaultException implementation is not mine but it is bubbling through my lib which i’m testing and this is precisly the condition i want to write tests for.

“Module tagged” exceptions and assert_raises_kind_of

First i wrote an empty tagging module for lib to tag all Errors and exceptions coming from my lib:

module MyLib
    module Error; end
end

Now i can tag all exception from some deeper laying code with my Error module:

begin
    ...
rescue => e # errors bubbling from the underworld
        # tag it
    class << e; include MyLib::Error; end 
        # throw it
    raise e
end

Voila, and now i can write:

assert_raise(BlogMist::Error) { @blog.find_post(:postid => 123456789) }

and finally got what i wanted but you’re milage may vary. Basically this gives me a way to create some kind of folksonomy of errors coming from my library. Don’t know yet where this might lead me, but hey, ruby is the best for protoyping and playing around!

Don’t be lazy!

Testing for error base classes instead of pricise error handling is not to make you lazy! As discussed on the forum thread it is to start with tests early on and being able to refine error condition testing over time.

Technorati tag: ruby, ducktyping, assert_raise, test-first,

what’s there more left to say? As steffen already posted on our company/product blog he managed to shoot the man himself! David(of ruby on rails fame) in front of our foto-foo webcam snapshot solution. This is best practice par excellence, right there, on location, from there to internet with no inbetween. That is foto-foo: no files, no upload, no hazzle, and, Thanks! David! You are the man, have a good time over there at the rails conf in portland and hope to see you all back in berlin in september!

cheers

Technorati Tags: rails, dhh, foto-foo, idmedia

Now that our island emerged from the deep waters of californian virtuallity we are just a couple of days away from opening our space there. I hope for  a  lekker housewarming party next week. creating tomorrow and stay tuned! 

Technorati Tags: idmedia secondlife webcam streaming avatar

arerrgh, das kann ich aus verstaendlichen gruenden natuerlich nicht unerwaehnt lassen. Ich habe schon lange aufgehoert mich ueber diese leute vom fernsehn zu wundern.