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

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.

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!

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") %> 

I spent some time yesterday trying this out.
I am writing it here to save your time.

Here is the functional test’s code to check for a hyperlink with text “Back to Index” which links to the index action of the controller being tested.

link = find_tag :tag => "a", :content =>"Back to Inbox"
assert_equal @controller.url_for(:action => 'index', :only_path => true), link.attributes["href"]

It could have been done in a single assert_tag … but the statement becomes too long.

To prevent bots from Signing up on our application, we added a captcha to our User model. We used the validates_captcha plugin available at http://svn.2750flesk.com/validates_captcha/trunk

The plugin, selects text from a String array for the captcha challenges, so, Sur, my co-programmer, hacked the plugin a little to add random text and improved images.

After adding the plugin we realized that all our tests which validate the User model had started failing. Programmatcially a test case or a bot are not much different, they are both scripts.

Mocks to the rescue.

Here is what I wrote in a file named add_captcha_to_active_record.rb under test/mocks/test directory.

require File.expand_path(File.dirname(__FILE__) +
"/../../../vendor/plugins/validate_captcha/lib/add_captcha_to_active_record")

module AngryMidgetPluginsInc #:nodoc:

	module Validations #:nodoc:

		# module Captcha
		module Captcha #:nodoc:

			# module InstanceMethods
			module InstanceMethods #:nodoc:

			private

				def validate_captcha(options = {}) #:nodoc:

				end

			end

		end#module Captcha

	end#module Validations

end#module AngryMidgetPluginsInc

What I have done by adding this file is, I have asked the test scripts to use the validates_captcha method in /test/mocks/test/add_captcha_to_active_record.rb instead of the validates_captcha method in plugins/validate_captcha/lib/add_captcha_to_active_record.rb

Well actually Rails does all the magic, I just need to give the same file name as the one I want to mock and then define the method that I want to override.

The original validates_captcha method checks that the text entered on the signup screen is the same as that stored on the server. If these do not match it adds a validation error to the base class, the User class in our case.
In the mock validates_captcha method we just do nothing. So a validation error will never be added to the base class.

And now our tests are running and passing again.

I also noted the presence of a directory /test/mocks/development/ … well that means I can even mock classes in the development environment.
One of our application, connects to Paypal to make a payment and then returns back. During development we had commented out this code so that we are not sent to paypal everytime. Now I know how I can avoid commenting or changing the code by using mock objects.
I will be working on that soon and blog about my experiences here.

I was looking for information on how to expire an idle rails session in say n minutes of inactivity.

Here are some resources
http://antrover.com/blog/articles/2006/05/22/how-to-expire-a-session-in-rails

http://rails.techno-weenie.net/question/2006/5/1/how_to_change_session_time