A Waage Blog

As opposed to previous versions of Rails, Rails 3 namespaces your entire project according to your project name. As an example, notice that in your config/routes.rb file, the first line is:

ProjectName::Application.routes.draw do
...

This means that changing a project name involves changing a number of files to reference the new project name as well. Here’s a quick list of the standard files to change:

Rakefile
config.ru
config/application.rb
config/database.yml
config/environment.rb
config/environments/*.rb
config/initializers/secret_token.rb
config/initializers/session_store.rb
config/routes.rb

Besides these, it’s a good idea to also check all files in config/ and config/initializers/
If you want to be thorough, run this grep command in your project root, and you will get a list of all files that contain your old project name:

grep -Ri 'oldprojectame' * | cut -f1 -d':' | sort | uniq

I ran into a problem as I was trying to decode and parse the Facebook signed_request for their new Registration plugin (http://developers.facebook.com/docs/plugins/registration).

Folowing the PHP example, I attempted to decode and read the signed_request returned by Facebook. Unfortunately, it seemed like the decoded JSON returned was malformed! It was missing the end hash character “}”. This may not happen in all cases, but the reason is due to the padding in Base64 encoding (See Base64 for URLs in Wikipedia).

To account for the padding in Base64, I used the following helper method to do the base64_url_decode. Hope it helps someone else trying to base64 decode Facebook’s signed_request in Ruby on Rails!:

 def base64_url_decode(str)
   str += '=' * (4 - str.length.modulo(4))
   Base64.decode64(str.tr('-_','+/'))
 end

Notice there’s two things that must happen before decoding the string:

1. Pad the encoded string with “=”
2. Replace the character ‘-’ with ‘+’, and ‘_’ with ‘/’

I wish Facebook mentioned this clearly on their API !

It sounds easy, but I tried a lot of things before finding the solution I used.

I tried using:

`host 66.249.67.49` or
`nslookup 66.249.67.49`

These were fine, but it seems a bit hacky to use the shell. Also, it would require some sort of parsing to get the hostname that I want.

Browsing the web, I found a couple solutions that almost worked.

s = Socket.getaddrinfo('66.249.67.49',nil)
hostname = s[0][2]

This solution worked in IRB, worked in console, but for some reason would not work when I was running my mongrel server and trying to perform the exact same method call from a web-browser. ( I still don’t know why).

Digging around a bit more, I came up with this simple solution:

host = Resolv.new.getname('66.249.67.49')

Is it really that easy?? Give it a shot and let me know your thoughts !!

After spending a good couple hours + trying to figure out why my functional tests were failing when working with cookies, I came across a couple great resources for rails + testing cookies.

Here’s a good basic explanation of using cookies on Pluit solutions website. Then I came across the Robby on Rails blog that led me to understand (and misunderstand) the asssert_cookie plugin.

However, I was still having a lot of trouble figuring out why I was setting my @request.cookies['foo'] in my functional test, but later (in the same test method) checking for cookies['foo'] and not finding anything in the cookie jar!

I then tried setting cookies['foo'] in my controller test, but found that when I did a check for the existance of that cookie in my actual controller code, it was not there! I thought that I should be able to set up a cookie in a test and have my controller recognize it. This is true, however, not by setting cookies['foo'].

So… I opened up a blank controller and functional test and began testing out different combinations to find out exactly what was going on. I hope this little example helps to save someone else’s precious time. Here it goes…

This is the controller I will be referring to for my example tests:

========= controller
  def foo
    if cookies['oreo'] == 'yesitis'
      @info =  "Oreos are tasty"
    else
      @info = "Only Milk here"
    end
     render :nothing => true
  end

1. In your functional test, do not test for presence of a cookie after a get request to a particular action, unless the action you are testing specifically sets up that cookie. In other words, if your controller action is not setting the cookie, do not test for that cookie’s presence.

In the above controller, no cookies are ever being set. Therefore, testing for the presence of a cookie after the get request (in a test method) will return false.

In other words, the cookie is recognized by the controller, however, notice that cookies['oreo'] is nil after the get request:

  def test_oreo
    @request.cookies['oreo'] = CGI::Cookie.new("oreo", "yesitis")
    get :foo
    assert_equal({}, @response.cookies)
    assert_equal(nil, cookies['oreo'])
    #Assert cookie will be nil here so do not test it:
    #assert_cookie  reo
    puts assigns['info'] #"Oreos are tasty"
  end

Note:
1. After your get request, the @response.cookies will be empty
2. After your get request, cookies['oreo'] will still be nil.
3. After your get request, you cannot use assert_cookie because it will be nil

2. If your controller action expects a cookie to be there, you cannot set it up in your functional test by assigning:

The only way to set up your cookie for a subsequent request, so that your controller will see it is:

• @request.cookies['oreo'] = CGI::Cookies.new(’oreo’, true) (correct)

  #INCORRECT
  def test_oreo
    cookies['oreo'] = 'yesitis'
    get :foo
    puts assigns['info'] #"Only Milk here"
  end

#INCORRECT
  def test_oreo
    cookies['oreo'] =  CGI::Cookie.new("oreo", "yesitis")
    get :foo
    puts assigns['info'] #"Only Milk here"
  end

#INCORRECT
  def test_oreo
    @request.cookies['oreo'] = 'yesitis'
    get :foo
    puts assigns['info'] #"Only Milk here"
  end

The only way to set up your cookie in a functional test and have your controller recognize it.

#CORRECT
  def test_oreo
    @request.cookies['oreo'] = CGI::Cookie.new("oreo", "yesitis")
    get :foo
    puts assigns['info'] # Will print out "Oreos are tasty"
  end

3. Avoid the temptation to use symbols in your tests with cookies.

• cookies[:foo] -> BAD
• cookies['foo'] -> GOOD

4. Only use assert_cookie (plugin: see above for link) if you are testing that the controller action is creating a new cookie.

5. If you are testing multiple actions and redirects from one action to another action in the same controller, you do not need to set the cookie before each action, explicitly. The cookie will remain in the @request object that you created in the setup method of your test.

EXAMPLE TWO (Testing persistent cookies)
You DONT set up the cookie for each subsequent request.
It does “persist” throughout your test-method because you are
using the same @request object!!

========controller
  def foo
    if cookies['oreo'] == 'yesitis'
	puts "Foo has OREO"
    else
 	puts "Foo has NOTHING"
    end
      redirect_to :action => :bar
      return true
  end

  def bar
    if cookies['oreo'] == 'yesitis'
      puts "Oreos are tasty"
    else
      puts "Only Milk here"
    end
     render :nothing => true
  end

========= Test
  def test_oreo
   @request.cookies['oreo'] =  CGI::Cookie.new('oreo', "yesitis")
    get :foo    #OUTPUTS: Foo has OREO

    # COOKIE PERSISTS HERE!!
    # Don't need to explicitly set cookie again in the
    # @request.cookies object
    get :bar   #OUTPUTS: Oreos are tasty
  end

Hello World! (and a bit of intro)

I first created Qugstart during finals season in my 2nd year at Berkeley. Initially all I knew was PHP, and I barely knew it. Qugstart was a perfect way for me to waste my valuable study time, improve my PHP skills, while at the same time pick up some MySQL.

Well, Google has since pounced on the Qugstart idea, I have since graduated, and the combination of working full time, Cubase, and a sudden interest in Jazz piano have taken up most of my time. Thus, my poor Qugstart has not had much attention from me at all.

In the past year or so, I’ve been fortunate to meet Ruby and her friend Rails. Armed with a new blog, and a new confidence in my Rails skills, I have decided to re-vamp my entire site in Rails!

I hope that I can post regularly as I develop, so that I can share some of my new discoveries with the world out there.

As for now, Qugstart is in the process of a backend (member’s section) re-vamp.

Stay tuned!