To those who may have had a similar error, this post is for you.

So your rvm is up to date. And now you have to roll with ruby 1.9.2.

In my previous post, I went through how I got around a ruby 1.8.7 install error. And that error had to do with readline.

Well, if you ran

rvm install 1.9.2

And go the following error:

ruby-1.9.2-p0 - #fetching
ruby-1.9.2-p0 - #downloading ruby-1.9.2-p0, this may take a while depending on your connection...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 8296k  100 8296k    0     0  23037      0  0:06:08  0:06:08 --:--:--  8643
ruby-1.9.2-p0 - #extracting ruby-1.9.2-p0 to /Users/jasonn/.rvm/src/ruby-1.9.2-p0
ruby-1.9.2-p0 - #extracted to /Users/jasonn/.rvm/src/ruby-1.9.2-p0
ruby-1.9.2-p0 - #configuring
ruby-1.9.2-p0 - #compiling
Error running 'make ', please read /Users/jasonn/.rvm/log/ruby-1.9.2-p0/make.log
There has been an error while running make. Halting the installation.

If you examine the make.log file, the last few lines may show the following:

compiling readline
gcc -I. -I../../.ext/include/x86_64-darwin10.5.0 -I../.././include -I../.././ext/readline -DRUBY_EXTCONF_H=\"extconf.h\" -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE   -fno-common -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -fno-common -pipe  -o readline.o -c readline.c
readline.c: In function ‘username_completion_proc_call’:
readline.c:1292: error: ‘rl_username_completion_function’ undeclared (first use in this function)
readline.c:1292: error: (Each undeclared identifier is reported only once
readline.c:1292: error: for each function it appears in.)
make[1]: *** [readline.o] Error 1
make: *** [mkmain.sh] Error 1

Fortunately, this is exactly the same problem as before. All you need to do is tell the compiler where the readline library is. If you setup is similar to what I indicated in my previous post, then all you have to do to install 1.9.2 is:

rvm install 1.9.2 -C --with-readline-dir=/usr/local

If you’re on Rails3, and using mongodb, it makes a lot of sense to use the mongoid gem. Why? Because mongoid hooks neatly into the ActiveModel framework which was made possible when Rails3 came along.

So if you’re like me, and was wondering how to do custom validation on a field, it turns out that it is simply a matter of adding logic to the validate block like so…

class MyModel
   include Mongoid::Document

   validate do
      errors.add(:atttribute, message) if attribute_is_invalid?
   end

end

You might be tempted to start hacking a string message in your errors collection, but there’s good reason to externalise your error messages to a separate locale.yml file. The sooner you start externalizing them, the easier it will be later to support other languages. So how do you generate an appropriate i18n message?

On first go, you might think that the easiest way is to use:

I18n.t('mode.attribute.error')

However, this doesn’t quite fit how other ActiveModel errors are namespaced. Typically, they follow the following convention:


en-us.activemodel.errors.models.[MODEL].attributes.[ATTRIBUTE].[ERROR]


As I was looking to an answer to this question, I stumbled on ActiveModel::Errors.generate_message(). It looks like all you need to do is to meet the following signature:

generate_message(attribute, type = :invalid, options = {})

So this transforms the above validate block into something like this:

class MyModel
   include Mongoid::Document

   validate do
      errors.add(:atttribute, errors.generate_message(:attribute, :error)) if attribute_is_invalid?
   end

end

Hopefully this will help somebody else out there to save some time trying to crack this nut.

I’ve just been through the paces of putting a Heroku app which uses the Mongoid gem and connecting it to MongoHQ, a SaaS MongoDB service provider.

Since this is relatively new, Heroku and MongoHQ have very little “official” documentation. So this post is a collection of various “learnings” and experiences that I have found across the internet. Hopefully it will help you out if you’re intending to do the same.

Step 1: Add the Heroku MongoHQ Addon

As per http://docs.heroku.com/mongohq, the first thing you need to do is add the MongoHQ addon. To do this, you can either use the Heroku web interface or run the following command

heroku addons:add mongohq:free

Once you do this, a brand new MongoDB database is automatically created. In addition, the MONGOHQ_URL environment parameter will also be set, which contains the connection string that is used to access your MongoDB instance hosted by MongoHQ.

Step 2: (optional) Configure MongoHQ’s MongoDB Remote Connection

NOTE: the following instructions came from:
http://support.mongohq.com/discussions/community-tips/2-logging-in-to-mongohq-for-heroku-users

MongoHQ provides a simple way to view and manage MongoDB instances. So to use what they offer, you will need to “Add a Remote Connection”, and populate that with the MONGOHQ_URL connection string. This is entirely optional, but the web interface is a very neat way to view, manage and see your MongoDB instance.

To do this, first extract the MONGOHQ_URL connection string. Run

heroku config --long --app <app_name>

Where –app <app_name> is entirely optional but may be required depending on your setup.

What you see is a list of environment variables, and one of them should be the “MONGOHQ_URL” value. Copy it.

Then, in MongoHQ (http://www.mongohq.com), after creating an account, you can “Add a Remote Connection”. You will need to provide:

1. A name (call it anything you like)
2. A URI (this should be the value provided by the “MONGOHQ_URL” connection string)

After creating the link, you should be able to navigate and see what’s in the mongodb instance. Importantly, the application shows how much space the database is taking up, which makes it easier to monitor your database size/growth. This latter point is important given that MongoHQ doesn’t currently (2010.12.30) support email alerts to tell you if your DB is getting close to the maximum size permitted by your current plan. Once you do hit that limit, the support documentation indicates that writes will begin failing.

Step 3: Configure Mongoid In Rails 3

Over at http://mongoid.org/docs/installation/, you will find fairly clear instructions for getting Mongoid going. However, at the time of writing, there are few things I have found that you will need to do.

The first is that the Gemfile instructions specify bson_ext version of 1.1.2. At the time of writing (2010.12.30), I found out that the mongo gem (which is a dependency of mongoid) had already moved to 1.1.5. The bson_ext and mongo gem must match in version… so enter the following instead:

gem "mongoid", "2.0.0.beta.20"
gem "bson_ext", "1.1.5"

Then configure mongoid in your rails by running

rails generate mongoid:config

This will create a file under config/mongoid.yml.

Now, there are a couple of gotchas here. There’s a stackoverflow post which details some problems in getting mongoid to run under the Heroku + MongoHQ stack. Basically, if you specify host in your mongoid.yml file, it overrides the value you specify as uri.

So my example mongoid.yml configuration looks like this…

defaults: &defaults
  allow_dynamic_fields: true
  parameterize_keys: true
  persist_in_safe_mode: true
  raise_not_found_error: true
  reconnect_time: 3
  use_object_ids: true

development:
  < <: *defaults
  host: localhost
  database: myapp_development

test:
  <<: *defaults
  host: localhost
  database: myapp_test

# set these environment variables on your prod server
production:
  <<: *defaults
  uri: <%= ENV['MONGOHQ_URL'] %>

The key point of note is that host is specified for the development and test environments. For production, set the uri value with the ‘MONGOHQ_URL’ parameter.

Step 4: Test, Test, Test

The simplest way to test this, is to run

rails generate scaffold User email:string

If you have mongodb installed locally, then fire up your rails app, and check that the user resource can be added, deleted, modified and listed.

Then add everything and deploy directly to Heroku to see if everything is ok.

After this great big hack, you’re free to go back to the land of TDD/BDD and resume the normal course of development.

Late last week, some of the Common Vision guys had the opportunity to attend YOW Melbourne 2010. For those of you who may not know, YOW is a Developer Conference, hosted by Developers for Developers. It is a meeting of minds in the Development community that spans a number of disciplines and subject areas.

Judging by the numbers in attendance, YOW 2010 in Melbourne was a huge hit. Not only was there an all-star lineup of guest speakers, including Rod Johnson from Spring, Erik Meijer from Microsoft (architect of LINQ), Corey Haines, J. B. Rainsberger, Guy Steele, Oren Eini (of Rhino.Mocks and NHibernate optimisation fame), Michael T. Nygard and Mary and Tom Poppendieck, but the event was heavily attended by the who’s who of the Melbourne Software Development scene.

The topics presented were wide and varied. Some were case studies, others were instructional and even some were entertaining.

Of particular note was a talk delivered by Richard P. Gabriel and Guy Steele – who created a mosaic survey across 50 computing languages (entitled “50 in 50″ which you can see on the JAOO blog). Their composition was entertaining, witty and down right nerdy.

Much thanks goes to the conference organisers and speakers and even attendees. It was a great event, and one which we hope will continue in many years to come.