The Irish Penguin

It happens to the best of us. We’ve coded our app go to deploy it and encounter some dispatch.fcgi issue. Today was the turn of

dispatch.fcgi error: undefined method `require_gem' for main:Object (NoMethodError)


Well way to troubleshoot and arrive at a solution is to actually run ./dispatch.fcgi. I didn’t know you could do this! It’s well handy! If you are on a remote server to which you don’t have ssh access then you can probably still run it as a cron job. Something like cd /path/to/my/app/public && ./dispatch.fcgi should do it. Remember that the dispatch.fcgi file is in the public directory of your application. The combination of running ./dispatch.fcgi and viewing the Rails log file revealed the useful error message above. Then a quick google search revealed that we need to change require_gem to simply gem (see here).

I had to change this in the dispatch.fcgi and then grepped the whole application directory for any instances of require_gem and changed them to gem too.

We came across a fabulous article on getting your RoR app to pull contacts from your Gmail account at Atlantic Domain Solutions: Import Gmail Contacts using Ruby on Rails. Kudos to Atlantic Domain Solutions! This is a really great article. The only slight issue is that it omitted a couple of details which may confuse the newbie - in particular, where does all the code in points 1, 2 and 3 go and how do the code snippets relate to each other.

So here’s a set of clarifications to the original article (a ‘meta-guide’ if you will), as we didn’t want to just rip off these nice folks source code. Thus read these clarifications in conjunction with the original Atlantic Domain Solutions guide.

We’ll assume that you know how to create a new rails app from scratch and create a controller. While you’re following this you can use localhost as your server (eg. the default localhost:3000).

Create yourself a controller called ImportedContacts

class ImportedContactsController < ApplicationController

    def authenticate
        # Put the code from point 1 in the Atlantic Domain Solutions article here.

        # Note:
        # Set the next_param to the follow on controller action. For example,
        # next_param = url_for(:action => 'authorise')
    end

    def authorise
        # Put the code from point 2 in the article here.

        # Note:
        # I changed some of the code as shown below...
        # if resp.code == "200"
        #     token = ''
        #     data.split.each do |str|
        #         if not (str =~ /Token=/).nil?
        #             token = str.gsub(/Token=/, '')
        #         end
        #     end
        #     redirect_to(:action => 'import', :token => token)
        # else
        #     redirect_to ('/')
        # end
    end

    def import
        # Put the code point 3 from the article here.

        # Some notes:
        # Put the line 'authsub_token = params[:token]' at around line 4 of this method
        # (just after the two requires). It was accidentally omitted in the original article.
        # I also changed the local variable 'contacts' to '@contacts' so that it is available to views
    end
end

To see the contacts after importing, I created a folder called ‘imported_contacts’ under app/views and placed the file import.rhtml in it, containing the following code.

<table>
  <%= @contacts.map { |c| "<tr><td>Name: #{c['name']}</td><td>Email: #{c['email']}</td></tr>" } %>
</table>

Ok! You should be ready to rock! Ensure that you are not logged into gmail and visit http://localhost:3000/imported_contacts/authenticate

You should be brought to a Google account login page. Login and you will be brought to the Google page for allowing third party access to the Google API. Click ‘Grant’ and you should be brought to your app’s import.rhtml page which should hopefully be displaying all your lovely contacts! Hurrah!

Ruby On Rails provides a few neat ways to serialise/deserialise objects to JSON. Out of the box you get the following approaches

SERIALISING

* json_string = a_house.to_json

DESERIALISING

* an_object = ActiveSupport::JSON.decode(json_string) # gives you an object of type Object
* a_house.from_json(json_string) # gives you an object of type House, note that a_house
                                             # is an instance of House

These are pretty straightforward and do exactly what they say on the tin. Of the deserialising methods, note that using ActiveSupport directly gives you an object of type Object so you may prefer the stronger typing of the second technique which gives you an actual House object.

Note: There’s been some great improvements to JSON support built right into Rails since Rails 2 has come around. For more info on this see here.

When things just aren’t enough…
There are times when you will want to override the default serialisation that Rails provides - such as if you want to do some object ‘flattening’ like including an attribute from an association on serialising. Now before proceeding check out the latest Rails 2 JSON support mentioned at the end of the previous section as this might make your life a lot easier. Otherwise, let’s press on with an example of DIY JSON handling.

Given a House object which has an associated Owner object, you might want to include the Owner’s name attribute when serialising a House.

House Class
- has address and value attributes
- has an associated Owner object

Owner Class
- has a name attribute

We’ll need to override the default to_json method on the House model.

class House::Base
  def to_json
    result = Hash.new

    self.class.content_columns.each do |column|
      if self.attributes.include?(column.name)
        result[column.name.to_sym] = self.send(column.name)
      end
    end

    if self.attributes.include?(column.name)
      result[:owner_name] = owner.name
    end

    result.to_json
  end
end

The above was partially taken from the howtogeneratejson page on the Rails wiki, which is has little bit more detail. Now all you need to do is call the a_house.to_json method and you get lots of lovely JSON which represents your model! One final note is that you may not want to override the default to_json method. If not, just call your method something else like to_custom_json. Also, there’s

This little article shows one way to model many-to-many relationships using a join table.

Obviously, The Penguin isn’t the first so here is an alternative good practical example which might give your good self an different perspective. Also this documentation has some more detailed information but doesn’t have a simple self contained example like below (and neglects to mention belongs_to in its primary example - at time of writing this).

Here goes. The following statements define our basic requirements.

* An order has many items
* An item has many orders
* We shall model this through a join table called order_items

orders     order_items    items
-----      ----------     ----
id         order_id        id
           item_id

Before we continue, please note that a massive massive thing to remember is that Order needs to have a has_many to the join table model AS WELL as a has_many (through the join table model) to Item. Also the join table model has a belongs_to for each model.

class Order < ActiveRecord::Base
has_many :order_lines #Don’t forget this line!
has_many :items, :through => :order_lines
end

class Item < ActiveRecord::Base
has_many :order_lines #Don’t forget this line!
has_many :orders, :through => :order_lines
end

class OrderLine < ActiveRecord::Base
belongs_to :order
belongs_to :item
end

Ok so that’s it folks! The Penguin has to admit that the above code hasn’t been run in a RoR interpreter so if has typo’s or smelly code please comment below.

One last thing is that if you’re going to try and present a RoR solution in an enterprise situation it is quite likely that the powers that be will want to see foreign key relationships in your database tables (note, this applies to all db relationships; not just man-to-many). These will give referential integrity to your associations. One very very handy and straightforward way to do this is using Red Hill’s foreign_key_migrations plugin. This really is great (it does pretty much all the hard work for you!) so it’s worth a serious look.

One gotcha with using foreign keys in Rails, is that the order in which test fixtures load becomes important. See Per Olesen’s post for tips on countering this. Other than that happy hacking and may the Rails Rise to Meet You!

Here’s the problem…

me@host:~$ sudo gem update
/usr/bin/gem:23: uninitialized constant Gem::GemRunner (NameError)

… which had us on the ropes more than on the rails for a while. Unusually googl’ing on this error provided no solutions.

What led to the situation was that we used the source install of rubygems on Ubuntu Gutsy (7.10) instead of using the rubygems in Ubuntu’s repository but then changed our mind and apt-getted the Ubuntu repository version. Surprise! Surprise! These 2 versions were conflicting a bit; leading to the above error. The workaround is pretty simple, just go to your /usr/local/lib section and delete the site_ruby directory (as this is the remnant of the rubygems source install and thus cause of the problem). This removes all the gems (that were downloaded by the original rubygems which we no longer want) off our system. Perhaps you want to simply move this directory first in case something goes wrong and you need to revert (eg. sudo mv /usr/local/lib/site_ruby /usr_local/lib/site_ruby_old).

Note: In case your not aware, /usr/local/* is the set of directories under which programs that you compile yourself get installed to by default. Generally the directories will start out pretty empty on a freshly installed Linux distro and then as you (if ever!) compile and install programs from source (eg. using ./configure && make && make install) then they end up under this directory. Also not that programs installed using apt-get (or via rpms on non-Debian systems) don’t get put here - they usually end up under the /usr/ directory itself (this varies a bit from distro to distro but what we’ve just outlined holds true for Ubuntu anyway).

Now, once your finished you should find that gem works. Do a ‘gem list’ and see if the above error is gone. If this doesn’t work you may need to ’sudo apt-get install rubygems’. Next up, we need to rebuild that gem directory that we deleted (site_ruby) with the apt-gotten rubygems (if apt-gotten is a real word!). To do this run

’sudo gem update’
’sudo gem update –system’

You will notice that the result of these commands means that /usr/local/lib/site_ruby is back and populated. This is where ruby likes to put it’s gem extensions. Finally reinstall rails with

’sudo gem install rails’

Hope this solution works for you! We’re still getting to grips with this rails stuff so if you find any glaring errors in this post please comment below to let us know.