{ :from => Delhi, :about => everything }

Ok, so we had been shouting ourselves hoarse, claiming that Rails is all about developer productivity and joy. So is that all about it?, huh!, was the normal reaction. But isn’t that a big enough reason. Not for many people though.

Yes, we accept that there are some pain points, like hosting Rails applications at shared hosts. No we don’t need those in production, but don’t you wish it was easier to deploy a rails app for a quick review with a client (a client who can’t run it on his own machine). Yes php scores there, just throw the code on the server and you are done. Why do I still run this blog on wordpress and not typo or mephisto? The big reason is that it’s easy to let just apache handle everything.

But things might change soon with the launch of passenger aka modrails.

And the other classic allegation against Rails has been performance. Remember the discussion between JDD and DHH about CPU cycles vs. developer cycles. We are definitely headed in the direction of lesser CPU cycles for our Rails app. Rails2 made some advances towards that and with Ruby1.9 and YARV and Rubinium, we have high expectations. Also you have heard about Ruby Enterprise Edition , haven’t you?

So things might change, when people try to figure out the fastest web language or framwework , the next time around.

I and those around me here, are generally biased towards rails. Ruby makes us happy. For us the pleasure points in Rails were always far more than the pain points. The basic Rails principles of DRY and Convention Over Configuration clicked with us. Ruby’s and Rail’s simplicity and beauty clicked with us. We did not need hosting on shared hosts. We could work with Rails caching to improve performance. No wonder we were one of the early adopters of Rails in India. But today, I would like to thank the critics whose untiring rants have moved Rails in the direction of being much more than what is was a couple of years ago.

Some of those changes have been in rails, but more have been around it. If you would have noticed, most of these development are not in rails as such, but in the ruby ecosystem.

Rails provides developer productivity and joy; ease of deployment; and ever-improving performance. And no, now you don’t need to go back to Java. We knew it, I am just repeating it for you.

Extrapolate this one year old graph for yourself.

So what is your reason for not having rail-ed yet?

Update: Charles Nutter has a post on upcoming Ruby implementations here

Tags: ruby on rails, rails

PuneRuby Guru Satish Talim recently posted about Companies in India he would recommend for Rails development. Vinsol is mentioned among the companies he recommends in his post.

Obviously makes me feel proud.

Thanks Satish.

Tags: ruby on rails india

Here are the sessions I plan to attend at RailsConf2007.

http://myconfplan.com/users/mjuneja/conferences/RailsConf2007

Thanks DrNic for the cool app 8-)

Tags: rails, ruby on rails, railsconf

Build you own Ruby on Rails web application is a book specially written for people wanting to start exploring rails. It is being pitched as the “ultimate beginners guide to Rails” by sitepoint.
So if you have been appreciating Rails from outside, get hold of this book and jump right it. Start experiencing the joy of Ruby on Rails programming in hours, if not minutes.

This book is also an exteremely useful resource for companies who want to train developers on Rails.

Thanks Jamis, for the review which made me look at this book. Now that a new rails book is coming out almost every fortnight, it’s getting difficuilt to keep track.
Also there is this gem hidden in Jamis’ review : never use a plugin you would not be able to write yourself. We have learnt it the hard way and I am sure so have many other Rails developers.

Tags: ruby on rails, rails, book

Believe me! The scene is much hotter than what I had anticipated a few months back.

Good to see so many companies and developers jumping ( or wanting to jump) onto Rails/Ruby from other frameworks and languages.
This means increased competition for us. But it could also be consolidation time for the small agile Rails teams in this area to join hands to increase their offering.

Talking about demand; yesterday, I received a job offer from a “Big Indian Outsourcing company”.
The lady who called me read this blog, but probably didn’t read “technopreneur” written on the top.
So when I told her that I was running a company myself, there was dead silence for a couple of seconds.
Then she asked me, if I could give references of any Rails programmers.

I told her that If I came across good people, I’ll hire them and I’ll pass on the others to her.
Fair enough. Right!

Tags: railsindia, rails, ruby, rails in india, ruby on rails

Following the dynamic fixture example from most of the rail’s books and tutorials available out there… you would be tempted to add something like this to the top of your fixture. ( this example is particularly relevant to the users fixture for use with the LoginEngine)

and then you would use this constant in your fixture somewhere… like maybe

   salt: <%= SALT %>   salted_password: <%= LoginEngine::AuthenticatedUser.salted_password     (SALT, LoginEngine::AuthenticatedUser.hashed('secret'))%> 

This is good for a single use of this fixture. But if more than one unit tests or functional tests load this fixture, you will start getting a warning “already initialize constant SALT” for all but the first use of the fixture.
Though it is just a warning, I did not find a mention of this in any of the books/tutorials.

Just a small check for an already defined constant will fix this warning.

 <% SALT = "nacl" unless self.class.const_defined?("SALT") %> 

Tags: dynamic fixtures, fixtures