.

Simple Mistake - Almost Triggers A Lot Of Work

Currently I’m grinding through the process of translating my old unit tests on a project into much nicer Rspec tests. Over all it has been a good experience. Especially since I caught some things in the process that the old tests didn’t cover.

So I started on new controller and I wrote something like this:

describe "My Cool Test" do
before(:each) do
@obj = String.new
puts "Hello"
@obj.should_receive(:stupid_method).once
end
it "should do something"
it "should do something else"
it "should not do this"
end

The object never calls stupid_method so it should fail the expectation right?

Well it turns out that although the begin is executed - because all of the examples are pending! If you run the above code you’ll see “Hello” several times - but no error.

Now add in the following example:

it "should be empty" do
@obj.should == ""
end

You’ll get:

Spec::Mocks::MockExpectationError in ' My Cool Test should be empty'
Mock 'String' expected :stupid_method with (any args) once, but received it 0 times

So there you go - (And don’t worry I submitted a bug)

You may be wondering why I said triggers a lot of work - well I’m currently using the Rspec mock library. I was very close to switching to mocha - which would have meant modifying a heck of a lot of tests.


Ruby Idiom

I saw this in the RSpec code while I was writing tests today:


[self.errors.on(attribute)].flatten.compact

It struck me as a very concise way to handle the case where it is either a scalar or an array (assuming you don’t care if the returned array is nested). It might get you out of some gymnastics trying to account for both cases.


Gnome autotest Notifications

I’ve been watching some Peepcode stuff this weekend and I’m officially jealous of the Growl support. It turns out I’m not the only one. After surfing around for a while I found this :

ikhono.net: Gnome autotest Notifications

I had to update the regex to handle a change in the output of Rspec - but otherwise it works like a charm. (I also modified it to change the tray icon to the same icon it displays on the status update).

Here are my changes:

Autotest.add_hook :initialize do |at|
@notify = Notification.new
end

Autotest.add_hook :ran_command do |at|
results = at.results.flatten.join("\n")

unless results.nil?
output = results.match(/(\d+)\sexample[s]?,\s(\d+)\sfailure[s]?,\s(\d+)\spending/)
unless output
output = results.match(/(\d+)\sexample[s]?,\s(\d+)\sfailure[s]?/)
end

failures = 0
pending = 0
test_results = “”
if output
test_results = output[0]
failures = output[2].to_i
if output[3]
pending = output[3].to_i
end
end

if failures > 0
@notify.failed(”Tests Failed”, test_results)
elsif pending > 0
@notify.pending(”Tests Pending”, output)
else
unless at.tainted
@notify.passed(”All Tests Passed”, test_results)
else
@notify.passed(”Tests Passed”, test_results)
end
end
end
end


Reloadable Plugins

I been spending a lot of time lately in the land of plugins for Rails. I’m in the process of overhauling a bunch of GUI helpers I wrote a long time ago. One thing that was slowly driving me crazy is that every time I make a change I had to restart the web server to get it to reload everything in development. My old tricks for reloadability just didn’t seem to work.

I had looked for a solution before but came up empty handed. This time I hit pay dirt. Turns out you have to add some small bit of code to you environment.rb and you get reloadability back. Now I can get down to some business.

spotstory » Upgrading to Rails 1.2

Ok. I need to reload my plugins. Bleh. Further, this has to happen in environment.rb, not in environments/development.rb. Bleh.

# Array of plugins with Application model dependencies.
reloadable_plugins = ["acts_as_commentable"]
# Force these plugins to reload, avoiding stale object references.
reloadable_plugins.each do |plugin_name|
reloadable_path = RAILS_ROOT “/vendor/plugins/#{plugin_name}/lib”
Dependencies.load_once_paths.delete(reloadable_path)
end


Ruby-prof

looks like they’ve overhauled the ruby profiler. There is even a short guide to using it to profile Rails code.

Seems like perfect timing since I’ve been struggling lately with some Ruby based scripts that are used to move data around taking forever and a day….

How to Profile Your Rails Application


RailsConf 2007

It has been a bit of a zoo lately so I forgot to post about this. They added a new track to RailsConf and my presentation got accepted. You can see me speak on May 18.

RailsConf 2007 • May 17, 2007 - May 20, 2007 • Portland, Oregon


Erlectricity

This is not how it was supposed to be!

I wasn’t supposed to be able to buy a Prag book on Erlang!

Now they’ve given me access to Ruby from Erlang….

Educate. Liberate. - Erlectricity: Hi Ruby, I’m Erlang.

Armageddon is coming!


Dr Nic » “Reads -> slaves, writes -> master” plugin

Dr Nic » “Reads -> slaves, writes -> master” plugin

I’m excited this is one of those features that I thought I would end up having to cobble together. Now by the time the project I’m working on needs this kind of scaling the kinks should be worked out.


Offline Sucks - no - Offline Is The Future

You get to decide:


You’re not on a fucking plane (and if you are, it doesn’t matter)!

The idea of offline web applications is getting an undue amount of attention. Which is bizarre when you look at how availability of connectivity is ever increasing. EVDO cards, city-wide wifis, iPhones, Blackberry’s. There are so many ways to get online these days that the excitement for offline is truly puzzling

Joyeur: Joyeur: Joyent Slingshot

Joyent Slingshot allows developers to deploy Rails applications that work the same online and offline (with synchronization) and with drag into and out of the application just like a standard desktop application.

Personally, I think it has a lot more to do with the nature of the app. Some applications lose almost all meaning when you aren’t on the internet already. On the other hand, not being able to get to my ToDo list to add something I just thought of because I don’t have connectivity breaks my GTD mojo..

I’m going to keep following the offline stuff - especially if they get it to work so that you don’t have to jump through a lot of hoops to get it up and sync’d easily.


A Use for class << self

A while ago I posted

class << self
  def find_all
    code_goes_here
  end  def destroy_all
    code_goes_here
  end
end

or you can write

def self.find_all
    code_goes_here
end
def self.destroy_all
    code_goes_here
end

I said that these two versions are functionally the same and that I ended up preferring the second form because it was easier to tell you are working on a class method. Turns out there is a difference.

Jay Fields answered this a while ago - but I just found it here

Basically if you use the first form - Ruby will honor your private/protected tags but in the second you would have to resort to something like this

class<<self;self;end.send :protected, :find_all :destroy_all

or


class << self
protected :find_all,:destroy_all
end

This isn’t the end of the world since I end up putting my private/protected stuff at the bottom of the file (Since that makes it easier to find out what is protected/private than sprinkling it into the code) but could be a gotcha if you didn’t know about the need for the extra code.


    You are currently browsing the Economy Size Geek weblog archives for the 'Ruby' category.
    Previous Entries »
    Categories
    Archives

    .