Installing rbx-require-relative (0.0.5) Unfortunately, a fatal error has occurred.
Please report this error to the Bundler issue tracker at https://github.com/carlhuda/
bundler/issues so that we can fix it. Thanks!/Users/sjain/.rvm/rubies/ruby-1.9.2-p290/
lib/ruby/site_ruby/1.9.1/rubygems/ installer.rb:364:in `ensure_required_ruby_version_met':
rbx-require-relative requires Ruby version ~> 1.8.7. (Gem::InstallError)

This most likely happens because you are declaring a dependency on ruby-debug gem in your Gemfile.

group :development do
  gem 'ruby-debug'
end

With ruby 1.9, you need to update this with new gem name ruby-debug19.

group :development do
  gem 'ruby-debug19'
end

This will eliminate the dependency on rbx-require-relative and fix the issue.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

My takeaway:

Mac OS X applies .bash_profile and .profile only for Terminal.app environment and Apple’s technical documentation suggests using ~/.MacOSX/environment.plist for other applications. So, by default PATH value will differ for RubyMine and the console.

For managing the global environments, it also recommends a system preference pane app. This worked for me.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This is a documented gotcha with mocha. And also discussed here.

It happens when mocha gem is listed as library dependency inside rails app. The library gets loaded too soon. The fix is to load mocha after rails has booted up.

For rails < 3.0.0, this means removing -- config.gem 'mocha' -- entry from config/environment.rb and adding -- require 'mocha' -- at the bottom of test/test_helper.rb.

For rails >= 3.0.0, this means adding — :require => false — inside Gemfile entry as follows.

# Gemfile
group :test do
  gem 'mocha', :require => false
end

And then adding following line at the bottom of test/test_helper.rb:

# test_helper.rb
require 'mocha'

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

sudo port install tiff -macosx imagemagick +q8 +gs +wmf
sudo gem install rmagick

Reference: http://rmagick.rubyforge.org/install-osx.html

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Sooner or later, the need arises to assign default values to model attributes. In rails this is usually done in model’s after_initialize() with a new_record? guard.

Something like:

class User
  def after_initialize
    if new_record?
      self.country = "US"
    end
  end
end

This initializes the object with proper default so the UI form gets properly populated and the database gets proper default if user hasn’t overridden it.

Sometimes, you realize that you have (pre-existing?) objects in database that also need the same default if the current value is nil. In such case, you may modify your initializer like this:

class User
  def after_initialize
    self.country ||= "US"
  end
end

This works for both scenarios: User.new and User.find.

However, it introduces a behavior that may not be apparant immediately.

$ script/console
ree> User.find(u.id)
  User Load (0.9ms)   SELECT * FROM `users` WHERE (`users`.`id` = 1) 
ree> User.exists?(:id => u.id)
  RateSearch Load (0.6ms)   SELECT `users`.id FROM `users` WHERE (`users`.`id` = 1) LIMIT 1
ActiveRecord::MissingAttributeError: missing attribute: country
/[prj]/app/models/User.rb:3:in `after_initialize'

A closer look reveals that ActiveRecord tries to be smart and only fetch ‘id’ column when performing Model.exists? call.

Many people have tripped this and logged it as a bug. The report has been silently ignored, and I believe, for good/performance reasons.

So, what do we get around it? Here’s one way.

class User
  def after_initialize
    self.country ||= "US"
  rescue ActiveRecord::MissingAttributeError
    # this should only happen on Model.exists?() call. It can be safely ignored.
  end
end

As they say, it is not a bug, it is a feature.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

http://rubular.com/

Good one!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Ever wondered how to login as two different users at the same time? The situation manifests in any project where you want to be able to test a workflow involving several actors with different roles. The problem is that browsers allow only one login for a given domain at any one time. So, you are required to logout as current_user before logging in as another. One of the solution people use is install multiple browsers.

Solution: Multiple Browsers

So, lets say your favorite browser is firefox. And you also have IE7 installed by default on your windows machine. And you have a google chrome installed just so you can try out the new and blazing contribution by google. Most developers, I assume, more than a single browser installed on their system. Given this, you can login as different user in each browser.

This works but here is another solution that, as you will quickly realize, is better.

Solution: Multiple names for your “localhost”

Just update your /etc/hosts file to add more names for your local machine. Lets take a concrete example:

So, on a project, realted to mortgage industry, I have several actors like borrower, realtor, loan officer, mortgage-broker. I updated my /etc/hosts file (on linux) from this line:

127.0.0.1 localhost

to this:

127.0.0.1 localhost r lo mb b

With this above line, I can access my local application using following URLs:

http://r:3000 (for realtor)
http://lo:3000 (for loan officer)
http://b:3000 (for borrower)
http://mb:3000 (for mortage broker)

Now, I can open 4 tabs in a browser each with different URL and login as different users. Coupled this with password saving feature of browser, I don’t even have to type username/password for each user as long as I am disciplined about not cross-logging in as realtor inside borrower url (b:3000). Go ahead, leave yourself logged in and never logout!

This simple trick is better than multiple browser solution since it doesn’t require as many browser and you can have as many unique URLs as you want. And you are not limited to using this trick for local testing. If you have a staging server at http://staging.project.com that resolves to an IP, say, 192.1.2.3, you can repeat the same process:

# my /etc/hosts file
127.0.0.1 localhost r lo mb b
192.1.2.3 staging.project.com sr slo smb sb
# Now I can
# http://sr (staging realtor)
# http://slo (staging loan officer)
# you get the drill ...

There you go. Happy testing!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In my rails app, I had to do this to work around this.

We use haml rendering engine for our project and my form looks like this:

- remote_form_for @product_search, :url => product_searches_path, |
  :html => {:method => :post, :id => 'product_search_form'} do |form|

This generates a form like this:

  <form onsubmit="jQuery.ajax({data:jQuery.param(jQuery(this).serializeArray()) + '&amp;authenticity_token=' + encodeURIComponent('MlHm/z3dsdYtETKwtNnwQlojx1NIduLlWFMECbjntsM='), dataType:'script', type:'post', url:'/product_searches'}); return false;"
  method="post" id="product_search_form"
  class="product_search"
  action="/product_searches">

I was working with an ajax form but I believe the bug happens even with traditional form POST as reported by another user here.

So, I had to create an onSubmit javascript myself to fix the situation:

- semantic_form_for @product_search, :url => product_searches_path, |
  :html => {:method => :post, :id => 'product_search_form', |
  :onsubmit => "return jQuery.productSearchOnSubmit();"} do |form| |

(function($){
  $.productSearchOnSubmit = function() {
    if ($('#product_search_submit').attr('disabled')) {
    // do nothing
    } else {
      jQuery.ajax(
      {
        data: jQuery.param(jQuery('#product_search_form').serializeArray()) + '&authenticity_token=' +
        encodeURIComponent(form_authenticity_token),
        dataType:'script',
        type:'post',
        url:'/product_searches'
      });
    }
    return false;
  }
})(jQuery);

I also had to add global javascript variable for form_authenticity_token to make it available for javascript when performing submit.

%html{ :xmlns => "http://www.w3.org/1999/xhtml", :lang => "en", "xml:lang" => "en"}
  %head
    :javascript
      var form_authenticity_token = '#{form_authenticity_token}';

If you think, this is a bug too, please vote for a fix.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I ran into a different one today. In my case, I needed to set a few flashVars variables to pass to flex app (swf file) depending on presence of certain cookies. So, my test involved setting cookies on controller/request and then making sure they appear as flash variables. Here is what I did.

Test:

  should "render last_user_name and auth_token cookies as flashVars on new UserSession" do
    controller.request.cookies[:last_successful_username] = "vriuser1"
    controller.request.cookies[:auth_token] = "12345"
    get :new
    assert_equal "autoLogin=true&username=vriuser1", assigns(:flash_vars)
  end

Controller

  def new
    auth_token = cookies[:auth_token]
    last_username = cookies[:last_successful_username]
    @flash_vars = []
    @flash_vars << 'autoLogin=true' if auth_token
    @flash_vars << "username=#{last_username}" if (last_username)
    @flash_vars = @flash_vars.join("&")
    @user_session = UserSession.new
  end

Until I realized that setting cookies as symbols don’t work. Even though you can read cookies using symbolic-keys, you can’t set them as such in tests. I had to set them as strings.

  should "render last_user_name and auth_token cookies as flashVars on new UserSession" do
    controller.request.cookies['last_successful_username'] = "vriuser1"
    controller.request.cookies['auth_token'] = "12345"
    get :new
    assert_equal "autoLogin=true&username=vriuser1", assigns(:flash_vars)
  end

That did the trick!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.