The Viamentis Blog

Boy, this cetainly was a surprise. I’ve been watching rather intently the recent uptick in animosity between Merb and Rails. Merb started out great, promising a stripped-down Rails and thread-safety to boot. But in the end, Merb’s claimed thread safety didn’t actually pan out, and it lacked the polish that Rails has when it comes to programmer-friendliness. Plus, with the addition of Rails ‘Metal’, it’s become very easy to chuck action controller altogether for request processing and directly hook up a resource-intensive task.

So, more and more, Rails was eating into Merb territory, and not surprisingly so. It’s the same story with products – “faster X”, “cleaner Y” and “easier Z” are always doubtful propositions in the long run because those X,Y or Z will catch up to you, and your raison d’etre is no longer there. But not just that – I found Merb and Rails are very similar in their structure, and very complementary goals. So it only makes sense that they merge.

What I would think is more interesting, or worth learning as opposed to spending time over Merb is even more bare-bones frameworks like Sinatra. It has a uncanny resemblance to Web.py, and that is a good thing. It’s not always that you start out to write an MVC web app. Recently things have been getting very interesting in the Ruby world, with Github being the center of all this spurt of innovation. Exciting times in Rubyland, as always.

Now, this is interesting. I tried jQuery a while back, and have been looking for an excuse to use it in one of our projects. Since Rails is so closely married to Prototype, it’s not so easy having two different js frameworks to maintain. Until now. jRails looks interesting, promises to be a drop-in replacement for Prototype.js. Now things should get exciting.

I have been observing the developments in the RoR world with quite some interest lately. I think there are a few very significant improvements – the most important being the availability of mod_rails. The installation and setup is almost a no-brainer. I still remember the amount of pain it took to get Rails up and running in Apache2. And all the varying combinations of “best setups” offered – Apache (1.3), Lighttpd, LiteSpeed, Nginx, and finally, we’re back to Apache2. It’s about time. I think this will give a big boost to Rails adoption.  I really like that I can run multiple Rails apps on a single server with just a vhost setup, instead of mucking around with mod_proxy.

Next, I’ve been reading about Slicehost quite a bit, and I thought I should give it a shot. So we setup our staging server there, just to give it a shot. I ended up being very impressed – especially, I really like articles.slicehost.com – amazingly detailed and clear-cut source for setting up Rails apps on Slicehost. And pretty up-to-date too. I just finished setting up a Rails app on a Hardy Heron slice with the site’s help. I still remember the hoops we had to jump through to get the ‘perfect setup’ done on a vps. Really, the kids have it so easy these days.

Since Rails is single threaded and can’t handle multiple requests at a time , when I need such functionality I was helpless.Then I came to know about BackgrounDRb a ruby library which will help us to make “RAILS” handle multiple requests at the same time.To make use of this library is pretty simple. Following steps will help you to do so.BackgrounDRb depends on chronic and packet gems. Thus lets get started by installing these two gems first

sudo gem install chronic packet

Now we are ready to install backgroundrb , for this we need to do

script/plugin install svn://rubyforge.org//var/svn/backgroundrb

Now backgroundrb plugin is installed on our application, now set it up using the command

rake backgroundrb:setup :this will create three files on our application

creates a config file backgroundrb.yml in config directory of your rails application.
Creates RAILS_ROOT/lib/workers directory for keeping BackgrounDRb workers in one place.
Creates RAILS_ROOT/test/bdrb_test_helper.rb as a test helper for your workers

How this helps to balance the load is very interesting. Here we have one class called “worker“. Using this worker class we can make our time-consuming tasks run in the background of application, instead of running in controller.Now we can create our worker using the command

./script/generate worker <classname> which will generate your worker class and there you can write your time taking process.

Now we can invoke the worker on request using

MiddleMan.new_worker :class => :name_of_your_worker, :args => {arguments to pass}

Before you start your web server do start backgroundrb, you can start and stop this by

./script/backgroundrb/start
./script/backgroundrb/stop

Now our app will act as multi threaded. Try an example given below

Let me first thank my colleague Mr.Unni for his code on “downloading the song from YouTube using a ruby script”, I am borrowing few parts of it. So in the sample app you can download a song from YouTube using the URL of that particular song. Here Backgroundrb plays well to download multiple songs at same time by running it on background. Run this app on clicking the link below:
Download and run me