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.

Here is my take away:

  # returns [class, count] tuples for all active records in the heap 
  def ar_space 
    GC.start 
    h = Hash.new(0) 
    ObjectSpace.each_object do |o| 
      next if o.__id__ == self.__id__ 
      next unless ActiveRecord::Base === o 
      h[o.class.to_s] += 1 
    end 
    return h.sort{|a,b| -(a[1]<=>b[1])} 
  end

Nifty little snippet to fetch number of active record objects on heap. I am guessing, incorporating this as Controller after_filter can help with cost of each request..

No related posts.

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

Deploy at Will!

At the first RailsConf I had the pleasure of hearing Martin Fowler deliver an amazing keynote. He made some apt metaphors regarding agile development that I will now paraphrase and mangle.

Imagine you’re tasked with building a computer controlled gun that can accurately hit a target about 50 meters distant. That is the only requirement. One way to do this is to build a complex machine that measures every possible variable (wind, elevation, temperature, etc.) before the shot and then takes aim and shoots. Another approach is to build a simple machine that fires rapidly and can detect where each shot hits. It then uses this information to adjust the aim of the next shot, quickly homing in on the target a little at a time.

The difference between these two approaches is to realize that bullets are cheap. By the time the former group has perfected their wind detection instrument, you’ll have finished your simple weapon and already hit the target.

In the world of web development, the target is your ideal offering, the bullets are your site deploys, and your customers provide the feedback mechanism. The first year of a web offering is a magical one. Your customers are most likely early adopters and love to see new features roll out every few weeks. If this results in a little bit of downtime, they’ll easily forgive you, as long as those features are sweet. In the early days of GitHub, we’d deploy up to ten times in one afternoon, always inching closer to that target.

Make good use of that first year, because once the big important customers start rolling in, you have to be a lot more careful about hitting one of them with a stray bullet. Later in the game, downtime and botched deploys are money lost and you have to rely more on building instruments to predict where you should aim.

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.

Between 0.9.26, RC and final 1.0 release, bundler went thru some heavy changes with respect to command line options it supports. Luckily, twitter, forum and blogs kept everybody in the loop.

The blogs, however, became obsolete quickly and even blog posts few months old don’t work with latest version of bundler. We came across this issue that kept is in a loop for a while.

Snow Leopard changed a few things with ruby and mysql gem when it came out. Most mysql installation issues are hammered out by now and are well documented.

Before you jump and execute following commands, make sure that you indeed have 64 bit mysql and 64 bit ruby on your machine. (If not, these instructions may not apply to your need).

$ file `which ruby`
/Users/xxx/ruby/bin/ruby: Mach-O 64-bit executable x86_64
$ file `which mysql`
/usr/local/mysql/bin/mysql: Mach-O 64-bit executable x86_64

Both installations should be Mach-O 64-bit x86_64 architecture.

In summary, installing mysql gem requires 2 things:

• Specifying architecture flags: ARCHFLAGS=”-arch x86_64″
• Specify location of mysql_config to compile agains: –with-mysql-config=/usr/local/mysql/bin/mysql_config

Prior to bundler, this is what you would do on snow-leopard to install mysql:

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

With bundler, there is no command line option that I could find that I can pass to “bundle install” command. Having been in the loop around bundler, I knew that such OS specific options don’t go in Gemfile and have to be specified in user specific files such as ~/.bundle/config file. The official website for gem-bundler doesn’t have any mention of this (is it because we need to keep things simple for people just getting upto speed with bundler?).

Bundler has a feature which allow specifying build options as documented here. So, I did this:

$ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config

This updated my ~/.bundle/config with proper information that it will need for “bundle install” command. It make sense to keep this in ~/ folder and not my project folder since it applies only to my environment and it applies to all projects on this machine.

With this, doing “bundle install” still doesn’t install mysql properly. Comparing this to the pre-bundler command, it solves one issue. The ARCHFLAGS still need to be available for “bundle install”. With some leap of faith, I set an environment variable to this effect:

$ export ARCHFLAGS="-arch x86_64"
# should this go in my .bash_profile (so that mysql installs fine always, for all projects?
# And I don't have to remember to set this each time I do a fresh bundle install.

And voila, “bundle install” installs mysql correctly.

Bundler is stable now and is making everybody’s life much much easier. It isn’t changing as fast and so this blog post won’t be obsolete too soon

No related posts.

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

1. ERB is similar to it pre-decessor and hence easier to learn. Compared to JSP etc. ERB is similar, you still see lots of HTML tag with interleaved ruby (or Java). Although verbose, it is closer to how your HTML would finally look like.
2. If your team has a dedicated HTML programmer (Designer as we may call them). These folks are very good at plain HTML and don’t want the trouble of converting files and having all the plumbing around when working. It is not efficient for them.

Despite this, I see Haml as valid alternative for following reasons:

• Its been 2 days since I started using Haml. Obviously, I have yet to higher gain productivity but tools like html2haml help a lot with the transition. I am beginning to see that I am not far behind, in terms of productivity, compared to ERb already.
• Especially if you don’t have a dedicated Designer/HTML programmer on your team, haml gives you another shot at productivity.
• I am not sure if this is a good idea but you can have both on the same project, but it sure does work. In fact, you can even have layouts, partials and your main page in different templating engine. Atleast, it lowers the barrier to get started.
• Haml gets ugly when there is too much html nesting. This is a good thing since it encourages breaking your view into partials and making it modular.
• Haml also promotes better view design by making divs/ids/classes most concise. If you are still using tables a lot, you may find yourself using divs with haml.

Try it out. It’s not that bad.

Enjoy!

No related posts.

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

Great stuff. Enjoy!

No related posts.

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