lindsaar.net - Home

Always getting an invalid authenticity token error

2009-05-03T14:59:00Z

I had a Ruby on Rails app giving a bunch of invalid authenticity token errors. I spent a while hunting down the solution until I found this write up. Very useful.

This write up was by Peter De Berdt on one of the Ruby mailing lists, I am putting it here more for my own future (maybe) reference as it is a very good solution for the situation I was running into. The entire thread is at the ruby forum site

If you have a situation where you are getting invalid authenticity tokens and are doing strange things with forms on your website with file uploads etc, and can’t for some reason just use the authenticity form helper, then this solution worked for me and should work for you too.

The solution is pretty simple to be honest:

In your view layout file, add this to the <header> section:

123	<script type="text/javascript" charset="utf-8"> window._token = '<%= form_authenticity_token -%>';</script>

In application.js, add the following:

Ajax.Base.prototype.initialize = Ajax.Base.prototype.initialize.wrap(
   function(p, options){
     p(options);
     this.options.parameters = this.options.parameters || {};
     this.options.parameters.authenticity_token = window._token || '';
   }
);

It will automatically add the authenticity token to ALL ajax requests, even those you invoke from custom code (graceful degrading and/or even delegated events for example).

A similar solution for those swapping out Prototype with JQuery has been posted here

As for file uploaders, a normal field within a form (multipart=true) will be sent as part of the form (and isn’t an ajax request in the first place) and shouldn’t be a problem. If you are using ANY other “ajax” uploader, there’s more to it. I already posted several times on how to get SWFUpload to play nicely with Rails, an overview with links to the appropriate posts can be found here.

Windows ipconfig does not show anything

2009-01-06T13:30:00Z

I had a Windows XP system (service pack 2) that would only return “Windows IP configuration” and then nothing, no indication of network disconnection nothing, well, there’s a good fix for it.

The system wouldn’t pickup an IP address from DHCP, it was like it was just confused.

You can do the following at a CMD prompt to reset the network configurations:

12	C:\> netsh winsock reset catalogC:\> netsh int ip reset reset.log

The first line resets all the WINSOCK entries to their defaults, the second line resets all the TCP/IP entries to their defaults.

The first one will ask you to reboot, don’t. Do both commands and then reboot your system.

Once I did this, the computer got it’s DHCP address again quite happily.

blogLater

Mikel

FreeBSD rc scripts

2009-01-05T20:18:00Z

I’ve always wanted a concise practical guide to rc scripting in FreeBSD, well, here it is

How to monitor a logged in professional

2008-11-24T06:37:00Z

Sometimes you will need to get a professional to log into your system to help you out. You should watch what they do, and this is the easiest way I know.

I needed to get someone from a hardware company to log into one of our phone servers to help debug a problem, but I wasn’t just about to give them full carte blanche access to my server. Especially as it is behind a firewall.

I trust these guys somewhat, I mean, if they screw up, no more customer and hello to bad PR… but at the same time, you should always watch.

So, I went hunting around, and Screen is the best answer.

Get them to log into your system and type:

$ screen -S support

Then, from your shell:

$ screen -x support

And bam, you are both sharing the same screen.

Nice and simple.

Of course, this isn’t fool proof, and it only really lets you follow what the other guy is doing. But it is a hell of a lot better than sitting there blind listening on the phone to a few hundred key strokes wondering ‘what is he up to?’

blogLater

Mikel

TMail Moves to GIT

2008-11-22T16:35:00Z

Social networking here we come!

I have moved TMail onto GIT.

You can see it here

Please fork / patch / follow / help out :)

Mikel

Funny...

2008-11-20T22:39:00Z

Some people think that rails is getting bloated… but through the hard efforts of core committers, the fluff and fat is getting sliced and trimmed down like a Döner kebab spit at a turkish festival…

And here is the perfect example seen on Rails-Contrib on freenode last night:

GitHub142: rails: David Heinemeier Hansson 2-2-stable
SHA1-9d8cc60

[19:07] GitHub142: Reduced the number of literal aliases to the
range that has actually seen personal use. With the massive
savings in overhead, I was able to fit Array#fourty_two

Here’s the commit if you are interested…

blogLater

Mikel

How to reset a sequence with PostgreSQL

2008-11-02T19:47:00Z

I would think that

12	ALTER SEQUENCE sequence_name RESTART WITH (SELECT max(id) FROM table_name);

would work, but it doesn’t. Use:

SELECT SETVAL('sequence_name', (SELECT MAX(id) FROM table_name) + 1);

instead and you will be a lot more happier.

blogLater

Mikel

OpenBSD RAID and Temp Sensors on HP Proliant DL 360 and 380 Series

2008-11-01T20:17:00Z

I have a bunch of HP DL 360 and DL 380 servers that I run OpenBSD on as gateways. This is how to monitor their RAID drive status and temperature status…

What you need to do is enable the IPMI driver.

If you read the man page, the IPMI driver provides an API like interface to the hardware it is running on.

This means you can query sysctl to get data like this:

123	$ sysctl hw.sensorshw.sensors.acpitz0.temp0=8.35 degC (zone temperature)hw.sensors.ciss0.drive0=online (sd0), OK

If you then yank one of a mirror set you get:

12	$ sysctl hw.sensors.ciss0.drive0hw.sensors.ciss0.drive0=degraded (sd0), WARNING

If you then put a new drive back into the mirror set you get:

12	$ sysctl hw.sensors.ciss0.drive0hw.sensors.ciss0.drive0=rebuilding (sd0), WARNING

Once the system has rebuilt, you get:

12	$ sysctl hw.sensors.ciss0.drive0hw.sensors.ciss0.drive0=online (sd0), OK

Which is very useful and basic data needed for monitoring systems like Nagios.

There is a catch though, the IPMI driver is not enabled by default in OpenBSD GENERIC (at least at 4.4). To enable it, you have two options.

At boot time, you can enable it by doing:

>> OpenBSD BOOT 640/31744 k [1.29]
use ? for file list, or carriage return for defaults
use hd(1,a)/bsd to boot sd0 when sd0 is also installed
Boot: -c
Booting...
=======snip=======
User Kernel Config
UKC> enable ipmi
441 ipmi0 enabled
UKC> quit

This will then boot normally and if everything worked, you’ll have an operational system that you can type the above commands in to query the status of your RAID set.

If it won’t start, then reboot without doing anything and it will go back to the way it was before, then contact openbsd misc with a copy of your dmesg.

If it all worked, you’ll probably want to enable this feature permanently, to do this, use the config(8) utility like so:

# config -u -o /bsd.new -e /bsd
(tells you about the kernel)
Enter 'help' for information
ukc> enable ipmi
441 ipmi0 enabled
ukc> quit

This then will produce an output file /bsd.new which is your new kernel.

To install the new kernel, do something like this:

# cp /bsd /bsd-original && cp -f /bsd.new /bsd

And then you can reboot to an IPMI enabled system.

Enjoy.

Terminator - Timeout without Mercy

2008-09-11T10:40:00Z

If you have been following my posts on Ruby-Talk and Ruby on Rails and even RSpec mailing list (and who wouldn’t?! I mean, aside from my mother) then you would have noticed I have been banging my head against a brick wall on the subject of System calls not being handled by the Timeout libraries in Ruby…

I’ve done a lot of work with this. I mean a lot.

So I thought I would share.

It all starts with a basic requirement I have, which is to replicate a data set from one side of the planet to the other. This involves logging into a database server remotely using ActiveRecord across some encrypted VPNs, querying some tables, and then inside of a transaction, replicating down certain data on certain rows.

The solution I have works well, I can replicate about 2-5 rows per second across the link which is more than adequate (the dataset changes upto about 100 rows per minute). The problem is that occasionally, ActiveRecord’s link to the remote database will hit a snag, then Ruby will wait, and wait, and wait to Timeout…. This can take hours, and in fact, sometimes, it never does timeout, leaving a zombie process.

To avoid multiple replication problems, I have lock files which prevent further copies of the replicator firing up if it detects that one is already running.

So, in the end, I get stuck with several replicators “running”, all hung, all waiting for a link to come back that never will, and no replication happening. In the mean time, the rows are still changing and I am getting backlogged. Leave it for a day and you are 80,000 rows backlogged and people start asking questions and I start looking for old travel tickets that I had ‘forgotten about’.

But why does ruby do this?

Shouldn’t the Timeout library protect us from such evilness?

Well, yes and no. The problem is because ruby uses Green threads. Green threads mean that there is only one real Ruby process running on the server, and it “internally” makes other “threads” that it schedules within the main ruby process’ kernel time. Green threads are very efficient (they save a lot of context switching) but the problem is that if you get a System call that ‘blocks’, then the kernel will stop servicing your main ruby thread until your system call is complete, and THIS means that the little ‘Timeout.timeout(5) { my code }’ block you put in, will never get called…

And then you get a hang… forever.

I tried a couple of handlings, the first was the SystemTimer library by Philippe Hanrigou. This entry actually has a really good and simple example of what Green threads and blocking system calls mean. If you want to brush up, it is a good read.

But SystemTimer didn’t work. It uses alarm signals which could have some problems. But in my case, it didn’t work and I still got never ending timeouts.

So I asked again on the Ruby-Talk mailing list and Ara T. Howard came back with a quick script that created little homicidal external ruby processes to kill the ruby process I was in if it didn’t “make it” in time.

The approach was actually very clever, and it works!

What he did was go “We can’t be sure that the existing Ruby process will be able to nuke itself, so instead, lets start up another Ruby instance, running on it’s own, that has the PIDs of the ruby instance that spawned it, and if the time runs out, do a system based kill TERM on the pids.”

You could say that our little ruby processes have a license to kill. Literally.

So I implemented his idea, found a couple of problems, gave back some ideas, and he coded, I spec’d, tested and described and we released a brand new gem…

The Terminator.

You can get it with;

gem install terminator

Or grab the source code.

And how do you use it? Simple:

require 'terminator'
Terminator.terminate 1 do
  sleep 2
  puts "I'll never print"
end

This will never print because the terminator times out after 1 second, which is before the sleep of 2 seconds inside the block. This will raise a Terminator::Error, which you could catch and try again if you want.

This will always work. It is because we are starting a separate process of Ruby (which has some minor overhead) that waits the specified number of seconds and then just simple does a system kernel TERM on our misbehaving process.

Why should you use it?

Well, if you are making ANY calls to external web services, external databases, OpenID, Youtube, Google Maps… anything, then you should have a fail fast policy in place and time out rapidly if these fail. As these are external system calls, they will most likely not be caught by Ruby’s timeout.rb library… and that means that your application will just hang, waiting for the call that never comes back.

It is much better to go “Ok, 2 seconds are up, no response, let’s tell the user to try again in a minute” and render an appropriate message, than have the user frustratingly whack the reload button a few hundred more times wondering why your application is not responding.

So yes, I think you should use Terminator.

Besides, how many other gems do you know that have the method ‘plot_to_kill’ ?

blogLater

Mikel

Tip #28 - Separate the things that change from the things that stay the same

2008-07-13T11:21:00Z

When you are coding, you should try to separate out the things that change from the things that stay the same. This isn’t my idea, but it is worth tip’n here as I just saw a really good, simple example of this…

I first read about this concept in learning about Design Patterns. Then I also read it in Design Patterns in Ruby by Russ Olsen (good book by the way).

The basic concept is that if you can spot the few lines of code in your design that could change and move these out to a separate part of your code base, when a change comes along, you just have to change one small part of your app and you are done. You don’t have to dive through lots of classes fixing and correcting code everywhere to implement the change.

I recently ran into a good example of this, it is the Active Record Extensions by Zach Dennis

I use PostgreSQL, Zach’s Active Record extensions worked out of the box with PostgreSQL, but in the inefficient fail-safe manner, that is, it did bulk inserts by making one complete insert statement per row, which is per the SQL standard.

For MySQL, he had implemented the multiple insert method in SQL, which allows you to write on “INSERT INTO…” and give it an insert array of (in my case) 1000 rows. This cuts down on data transfer between the client and server. Especially when you are inserting a few hundred thousand rows.

I knew PostgreSQL also supported this, so I dove into the code base to find a way to implement.

Happily, I found that Zach had followed the above rule to the letter. To implement this, I had to modify one line in one file (to include a module) and copy about 20 lines into another file (the MySQL versions) and modify a few of those lines to suit PostgreSQL and I was done!

This was a good piece of code, a good example of the above and worth looking at for a Ruby on Rails intermediate type who wants to find out more about plugins and extending ActiveRecord.

Mikel

Fortune...

2008-07-08T02:57:00Z

I got his when I logged into one of my OpenBSD boxes today. Interestingly true…

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time”. Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile”.

-- Frederick Brooks, "The Mythical Man Month"

Examples of Behaviour Spec'n

2008-06-30T00:05:00Z

In my previous post (Spec Behaviour not Implementation) I went on a froth roll about why you should treat controller actions as black boxes. Here I give an all to common example of why this is good and how you can write specs that won’t break at the most trivial change.

class AddressesControler < ApplicationController
  def index
    @person = Person.find(params[:person_id])
    @addresses = Address.find_by_person_id(params[:person_id])
  end
end

Now obviously this should be refactored (we’ll get to that in a sec) but what are we doing here? We are assigning person to the view and the person’s addresses to the view.

Using a mocks and stubs, I might do something like this:

describe AddressesController do
  describe 'GET index' do

    it "should ask the Person model for a person" do
      @person = mock_model(Person)
      Person.should_receive(:find).with("1").and_return(@person)
      get :index, :person_id => 1
    end

    it "should assign a person to the view" do
      @person = mock_model(Person)
      Person.stub!(:find).and_return(@person)
      get :index, :person_id => 1
      assigns[:person].should == @person
    end
    
    it "should ask the Address model for the addresses" do
      Person.stub!(:find)
      @addrs = [mock_model(Address), mock_model(Address)]
      Address.should_receive(:find_by_person_id).with("1").and_return(@addrs)
      get :index, :person_id => 1
    end

    it "should assign the person's addresses to the view" do
      Person.stub!(:find)
      @addrs = [mock_model(Address), mock_model(Address)]
      Address.should_receive(:find_by_person_id).with("1").and_return(@addrs)
      get :index, :person_id => 1
      assigns[:addresses].should == @addrs
    end

  end
end

Now, no one would complain about that (except that it is not very dry), pretty straight forward. But I say, my fellow RSpecers, what are we doing poking around the internals of that controller? Why do we give two hoots from a behavioral viewpoint on HOW the controller goes about it’s business? Can’t we just assign the controller responsibility here?

Well, no, you say, I need to know it is getting the addresses properly!. Well, ok, let’s make one trivial change to one line of that controller and see how many specs break:

class AddressesControler < ApplicationController
  def index
    @person = Person.find(params[:id])
    @addresses = @person.addresses
  end
end

Now, you would agree with me that the external behaviour of that controller action has not changed, we are assigning the requested person to the view and we are assigning the person’s addresses to the view, but guess what, every one of our specs now fail Why!? Because we spec’d implementation details. We setup our stubs and mocks to provide data in only certain ways.

The first and second specs fail because @person is a mock model and gets an unexpected message :addresses, the second and third specs fail because we don’t return anything from the Person.find and so you then get nil.addresses which fails. Even if that didn’t fail, we then have a failing spec because the Address model is never called.

Evil. Madness. Insanity, but most importantly, lost time. Now you need to go and dig in, remember what that spec did, what you were trying to do and re-write the spec, hoping that you aren’t changing the required behaviour.

And what is worse, our behaviour driven development specs are failing when the behaviour didn’t change!

Now there is a lot to be said for mock objects and stub methods. They are useful and have their place, they definitely speed up spec execution time, but I think this whole thing of mock everything in the controllers to make the specs go faster is over rated.

I work in a development team. We user factory objects and real objects when we can get away with it. And our specs run slower. On an app that is about 50% done we have 1500 specs passing, and it takes about 70 seconds to run them. Not too bad. About half of them use real objects (from the database). Sure, if I went through and mocked and stubbed everything out and spent the time doing that, it might get down to 50 seconds, or maybe 40. But it is pretty rare that waiting for the test suite to pass is blocking my development time.

So, if we re-wrote the above spec using factories, we would get something like this:

describe AddressesController do
  describe 'GET index' do

    it "should assign the requested person to the view" do
      @person = Person.build_valid!(:id => 1)
      get :index, :person_id => 1
      assigns[:person].should == @person
    end

    it "should assign the person's addresses to the view" do
      @person = Person.build_valid!(:id => 1)
      @address = Address.build_valid(:person_id => @person.id)
      @person.addresses << @address
      get :index, :person_id => 1
      assigns[:addresses].should == [@address]
    end

  end
end

Now, even though we have reduced this down to two specs, in reality, that is all the behaviour our controller is showing. It has no error handling etc.

If there were decision path’s in the behaviour of the controller, I would stub these out to do what I wanted for the spec, like @person.stub!(:save).and_return(false) and the like.

One other thing that I often read is that you don’t want to do a spec like this because some other developer could go and change the underlying API on how person and address talk to each other or what constitutes a valid object.

Well, I work in a team and I humbly submit that:

(a) this doesn’t happen too often, especially if you are using factories, because if you change the valid requirements of a person, then you should also be updating the factory.

(b) I want to know if my controller broke because of an API change.

Anyway, that’s just how I do it, your mileage may vary.

blogLater

Mikel

Tip #27 - Spec a Behaviour, Not an Implementation

2008-06-28T03:42:00Z

This has been said a lot, and doesn’t really need repeating by someone like me, but, as this is a tips page, I should put it here.

What does this mean? Behaviour, not Implementation?

Well, it means, what is it you are expecting your code to achieve? What is the end product that your code is meant to do? What are the valid states your code can be in after it has finished executing?

The way I draw the line on this is, except for RARE cases, I only spec the public interface of a component. That is, the bits that the class is presenting out to the bad wide world as valid ways to communicate to it. If you do this, it means that later you can change your implementation of HOW you got something done without a bunch of specs failing.

The applies to controller specs.

You should really treat the insides of a controller as sacrosanct, you don’t really have any business hunting and poking around in there, each controller has a right to privacy, THEY HAVE RIGHTS TOO!...

Ok, maybe a bit carried away, but you might see what I mean in a sec:

def create
  @person = Person.new(params[:person])
  
  respond_to do |format|
    if @person.save
      flash[:notice] = 'Person was successfully created.'
      format.html { redirect_to(@person) }
      format.js
    else
      format.html { render :action => "new" }
      format.js
    end
  end
end

With this simple example, what is it we are actually trying to spec?

Well, what is the behaviour?

1. If it succeeds, then we should get a flash sent to the view telling us we were a good little user.

2. If it succeeds, then we’ll get sent to the person show page

3. If it succeeds and we did an XHR request, then we’ll get the create.js template

4. If it succeeds we should get a person instance assigned to the view that has been saved.

5. If it fails on a HTTP request, then we get the new template rendered

6. If it fails on an XHR request, then we’ll still get the create.js template

7. If it fails then we should get a person instance assigned to the view that has not been saved.

And that’s it.

You don’t want to get into what params are being assinged to the person model on the new action, you don’t want to get into if the person model receives the wrong number of values for the new action, or anything like that.

Why? Because what the model does with the params is really no business of the controller. It is not the controller’s responsibility. All the controller wants to know is “Did it save or not?”

In fact, I would argue that no where in your spec for the controller would you have ”@person.should_receive(:save).with(some_params).and_return(true)”, no, it is implementation detail, evil.

Ideally (though this is hard to achieve in practice) you want to try and treat each executable code block as a black box in terms of describing behaviour.

You want to know “If I feed it XYZ, then the result will be ABC”. You don’t want to get into ‘If I feed it XYZ, then I need to make sure it will do A through Z so that I can then test to see if it actually did ABC’

See the difference? The first viewpoint allows you to refactor away inside the discrete code block (the create action in this case), but the second requires your behaviour specification code know every minute detail about your code execution, and that my friends is about as brittle as a 10,000 line PHP page.

Use ‘shoulds’ for specifying behaviour and use ‘stubs’ for dictating code execution paths.

if you did that, your specs would look something like this:

describe "create action" do

  def doing_a_successful_save
    @person = mock_model(Person, :save => true, :new_record? => false)
    Person.stub!(:new).and_return(@person)
  end

  def doing_a_failed_save
    @person = mock_model(Person, :save => false, :new_record? => true)
    Person.stub!(:new).and_return(@person)
  end

  describe "successful request" do
    it "should flash a notice to the user that the create succeeded" do
      doing_a_successful_save
      post :create
      flash[:notice].should == "Person was successfully created."
    end
    
    it "should assign a person instance to the view" do
      doing_a_successful_save
      post :create
      assigns[:person].should == @person
    end
    
    it "should render the show template for HTTP Request" do
      doing_a_successful_save
      post :create
      response.should render_template('show')
    end
    
    it "should render the create template for XH Request" do
      doing_a_successful_save
      xhr :post, :create
      response.should render_template('create')
    end
    
    it "should assign a saved person instance to the view" do
      doing_a_successful_save
      post :create
      assigns[:person].should_not be_new_record
    end
  end

  describe "failed request" do
    it "should return the new template for HTTP Request" do
      doing_a_failed_save
      post :create
      response.should render_template('new')
    end
    
    it "should return the create template for Ajax Request" do
      doing_a_failed_save
      xhr :post, :create
      response.should render_template('create')
    end
    
    it "should not save the object" do
      doing_a_failed_save
      post :create
      assigns[:person].should be_new_record
    end
  end
  
end

BDD is a discipline. Getting your head around it really starts with understanding the basic underlying principles of WHY you are doing it.

BDD stands for Behaviour Driven Development. So stick with that and nothing more and you will find BDD a lot easier to get done.

blogLater,

Mikel

Tip #26 - Start Small

2008-06-27T10:18:00Z

If you are getting frustrated with RSpec, then you have probably skipped a gradient. Start smaller!

When I was trying to teach a co-worker how to write specs, I ran into a gradient problem. He was trying to write specs for an existing app and controller setup that had the usual create action in the controller, it also had a before filter checking logins and timezones, the controller action was simple enough, something like this:

def create
  @person = Person.new(params[:person])

  respond_to do |format|
    if @person.save
      flash[:notice] = 'Person was successfully created.'
      format.html { redirect_to(@person) }
      format.js
    else
      format.html { render :action => "new" }
      format.js
    end
  end
end

Now, if you are really starting out, don’t start with this. Start with something MUCH simpler… maybe like this:

12	def newend

That would be a good gradient :)

No, seriously, if you just “don’t get RSpec”, then you skipped a gradient or went past something you don’t understand. Go back to an earlier gradient and come forward again.

I can say without a doubt that the #1 problem that new RSpec users have is code that tries to do too much.

Let the code evolve step by step from NOTHING and then come forward, the RSpec webpage has it right when it says “take very small steps”.

The skipped gradient problem is hard enough for experienced RSpec coders trying to fix an existing broken spec, but for someone who hasn’t understood the basics of how RSpec works, it is simply a killer. You don’t want to be wondering if your use of response.should have_tag(‘div’, 2) is correct when all the specs are not working and you have red failing tests everywhere… “Thar b’ dragn’s thar matey!”

If you run into this problem, then go make a new scratch app and start specing it from the ground up, with minimal code generation.

Something like this:

baci:test mikel$ ./script/generate rspec_controller welcome 
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/welcome
      exists  spec/controllers/
      exists  spec/helpers/
      create  spec/views/welcome
      create  spec/controllers/welcome_controller_spec.rb
      create  spec/helpers/welcome_helper_spec.rb
      create  app/controllers/welcome_controller.rb
      create  app/helpers/welcome_helper.rb

Now go into the spec/controllers/welcome_controller_spec.rb and check it out:

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')

describe WelcomeController do

  #Delete this example and add some real ones
  it "should use WelcomeController" do
    controller.should be_an_instance_of(WelcomeController)
  end

end

Your standard RSpec template. This is good enough to start. We are going to build a welcome page here, so lets write our first spec:

describe "getting the home page of the site" do
  it "should be a success" do
    get :index
    response.should be_success
  end
end

And stop RIGHT THERE and run your specs, it will fail because no index action or template exists yet. Once it has failed, do the next smallest thing that could possibly pass. Write an empty index action:

1234	class WelcomeController < ApplicationController def index endend

And then run your specs, it will now pass. Good! Now you can start building on that stable datum of ‘it is passing now, if I add this one thing it should fail, then if I code this one thing, then it will pass again.’

While I am at it, ban the script/generate rspec_scaffold command from your development vocabulary until you know how to do every step in the code that the scaffold generates (and even then, the use is questionable). The great thing that the scaffold does is provide examples. If you are new to RSpec, you might be tempted to use the scaffold, I would recommend instead to make a scratch up, and use the scaffold there, and then use the code examples step by step in your own app building up your own specs.

This will give you a much broader understanding of how RSpec works.

Trying to spec some huge pre-existing code block as your introduction to RSpec is not impossible, but it is a pretty steep gradient and will result in more hair loss than passing specs.

blogLater

Mikel

Tip #25 - Logging is your friend...

2008-06-26T10:16:00Z

Sometimes when you need someone to just look over your code and figure out what the heck is going on, you can turn to your best coding friend, this friend sits away in the log directory carefully collecting data waiting for your beck and call…

Watch your log files.

This should sort of be obvious, but I know several people (including yours truly) who have been bitten by this one.

When you are running your specifications, keep a ‘tail -f log/test.log’ running. If you are on Windows and can’t do this, then either install cygwin so that you can, or make your system dual boot with Ubuntu or something so you can.

The logs will tell you a huge amount about what your app is trying to do when. This is especially true if you get a controller spec response along the lines of:

1)
'PeopleController handling GET /people should render index template' FAILED
expected "index", got nil
./spec/controllers/people_controller_spec.rb:54:
script/spec:4:

2)
'PeopleController handling GET /people/new should render new template' FAILED
expected "new", got nil
./spec/controllers/people_controller_spec.rb:60:
script/spec:4:

I expected the new template, but got nil… not very helpful…

But in the logs, the truth appears:

Processing PeopleController#index (for 0.0.0.0 at 2008-06-25 09:15:28) [GET]
  Session ID: 
  Parameters: {"action"=>"index", "controller"=>"people"}
Filter chain halted as [:must_login] rendered_or_redirected.
Completed in <snip> | 200 OK [http://test.host/people]

Processing PeopleController#index (for 0.0.0.0 at 2008-06-25 09:15:28) [GET]
  Session ID: 
  Parameters: {"action"=>"new", "controller"=>"people"}
Filter chain halted as [:must_login] rendered_or_redirected.
Completed in <snip> | 200 OK [http://test.host/people]

Ahh! Filter chain halted as the must_login method returned false! So we forgot to log in before we went to try and get the controller action.

Simple example, I know… but aren’t all the good tips simple?

Mikel