Bundler is a tool for managing installed libraries on a ruby project. It comes bundled with rails 3 but can be used standalone without rails.
Bundler tries to fix issues with having to manage your gems(and their related dependencies and versions) in a clean way. In doing so it allows you to work on your application and not have to worry about dependencies sucking the life out of your releases.

Off late I have been working on an application that vendorizes its gems and packages them while shipping the application. Since this application is also been built in the traditional way(rails 2) I was looking to use bundler with it to do the vendorization. Turns out bundler supports such a use case.

For a packaged application bundler allows you to freeze the gems and unpack them in the
location of your choosing. This path can then be added to your application to load all the
frozen gems. The following command with the path set to the location you would like to unpack your gems allows you to use bundler to vendorize gems.

   bundle install --path vendor/bundle

You can then add these gems to your application as you would for vendorized gems.

Bundler with rvm and gemsets

One of the popular opinions is to just use bundler and ditch gemsets. I tend to use both gemsets and bundler to my advantage. This helps especially when I am working on multiple applications and when I am not online all the time. I ensure that my bundle is upto date before I go offline and then can work on my apps when I am offline by switching gemsets. Sometimes I tend to have multiple gemsets built when I am working on changing or experimenting with gems.

That way I do not have conflicts when I am using one version of rake for a ruby 1.8.7 application while my other ruby 1.9.3 application uses the latest and greatest rake gem.

Cleaning your gems before using bundler

Bundler allows you to install and update a set of gems based on the Gemfile. But it is not obvious how you would set up an application that has local gems installed to start using bundler. To start you need to delete all gems from the current gems. Having a clean workspace allows bundler to install gems from Gemfile without conflicts and can prevent a lot of confusion when multiple versions of a gem being installed side by side.

Here is a snippet that will allow you to clean your gemset.

   Delete all gems from gemset

   gem list | cut -d ' ' -f1 | xargs gem uninstall -aIx

In most cases this will work. But rake seems to be installed as part of the global gemset. So the above command will delete all gems till rake and then abort. To skip deleting rake change the above script as follows

   gem list | cut -d ' ' -f1 | ack -v 'rake' | xargs gem uninstall -aIx

(ack is further reading if you don’t already know what it does.)

Recently I was trying to host git repository from an already existing(non-bare) repository. I
was looking for a solution that does not force me to create a bare repository and does not
require me to install apache or some such webserver on my machine.

I found a wonderful tool written by Scott Chacon called grack. grack is a git server on top of rack. Its elegance is in its design. It consists of few hundred lines of a rack middleware(awesome!) and a 6-8 line config file that allows you to host any repository over http. Setting it up on a local
machine was really easy. Even hosting multiple repositories is trivial.

I discovered one quirk when my server was not accessible, was due to binding it specifically to 127.0.0.1.
Avoid this and bind to the hostname instead.

Many thanks to Scott Chacon, Github, Rack and Ruby for keeping it so simple.

Returned from Ruby Kaigi last weekend. The conference was held in Tsukuba International Convention Center and attended much of the enthusiastic ruby community(including Matz, Chad Fowler, Charles Nutter, Yehuda Katz et al). Had a blast presenting ‘Rocking the Enterprise with Ruby’.

Of all the sessions I could attend I liked Matz keynote focusing on the direction of Ruby 2.0. Especially the focus on mix-ins, issues with module mixins and list of ancestors. Class-boxes also looked a very interesting concept. Makes me want to use ruby 2.0 now. Based on the timeline discussed it is on track to be released sometime in 2011. (Ruby 2.0)

I also liked the treatment of metaprogramming handed out by Paolo ‘Nusco’ Perrotta. A delightful presenter who can draw great illustrations as well as explain the issues in ruby programming very well. His message ‘Look at source code from projects to learn what they are doing’. Also, he concluded that what works in Ruby works because of its design(metaprogramming, mixins) may not work in Java/C#. So when you come to ruby you may have to change the way you think.

Very enthusiastic response to lightning talks(in fact entries to lightning talks were closed even before the start of the conference).
Youngest ruby programmer(Shota Fukumori @sora_h) who wants to change ruby internals with his gem ‘few’ and babushka by Ben Hoskings were my favourites.(Lightning Talks)

The conference was organised very well, with an unofficial and official party on Friday and Saturday. Thanks to everyone who worked to make this a success.

(RubyKaigi 2010 Staff (by Naoto Takai))

Uploading the beta version of the presentation for today’s ruby kaigi talk.

Rocking the Enterprise with Ruby(Keynote)

Rocking the Enterprise with Ruby(PowerPoint)

Be virtually there!

One of the projects I worked on recently consisted of a number of applications interacting with each other over REST. These applications were written with an intention to obtain loose-coupling between them.

While writing more controller actions I noticed something that we were doing repeatedly – anytime one particular model changed in the domain it caused a ripple effect of making us change all the consumers in the application suite. These models were all exposed across applications by using ActiveResource. ActiveResource forced us to change every one of the model/model manifestations in the application.

The main intent of the decoupling effort was to help us change these applications almost independently of each other. These applications were supposed to only depend on the exposed interfaces. What ActiveResource did was forced us to tightly-couple them and a single change caused a ripple effect.

So my question is ‘Is ActiveResource an oxymoron?’ – Especially considering the fact that Active means really simple but strong coupling. Active does apply nicely to a database record and eases development by getting out of the way. But in case of lightly or ideally decoupled applications does the Active make sense? – Probably not. So if you want to expose objects and their behaviours over the wire maybe ActiveResource is not such a good idea.

While working on my mac and trying to use giternal I ran into ‘no such file to load —rubygems’. While I had been using ruby apps on the machine for a while, without any issues and with all the installed gems, this seemed weird.

I tried using the irb and check if

irb> require ‘rubygems’

would work. But I got the same error. I was using the default mac version of the ruby installation that is installed at ‘/System/Library/Frameworks/Ruby.framework…..’ and did verify that rubygems was installed and that rubygems.rb was also present.

On further investigation I found that the default ruby that was run on the command line was 1.8.7 when I expected 1.8.6.
It appears that my path contained ‘/opt/local/bin’ before ‘/usr/bin’ which made the 1.8.7 version of ruby default and thus clobbered all by 1.8.6 settings and lost rubygems.

To fix this I moved ‘opt/local/bin’ to be after ‘/usr/bin’ in my $PATH and voila everything works again.

I have also been meaning to try RVM – maybe its time to give it a shot since my personal projects are on 1.8.7 and I have jruby as well as 1.8.6 installed on my mac.

Seacucumber was a project that was a tool we used on a previous rails project. My friends Mike Ward and <a href= “http://www.peterryan.net/”>Peter Ryan opensourced it some time back. It was dormant for awhile since it worked great with prototype. Another thing was that it looked and behaved very similar to Dr. Nic’s javascript testing that you can download for rails. Recently I was on a project where we used jquery and we did not have anything to run javascript tests and break the build on failure.

So I revived seacucumber development and added jquery support to it. I had to modify jquery test runner to postback results as prototype does. So if you need a tool to automate your javascript testing you should use seacucumber. It has been moved to github. Feel free to download it, fork it and use it. Let me know what you would like added to this tool.

I have moved my personal blog from blogspot to github pages. Dr. Nic and Mojombo helped me do it with Jekyll.

My old blog on blogger will still be available with all the posts and comments.
http://betarelease.blogspot.com