Problem: I faced this problem where in after a page is loaded I have to add certain input html elements in the form (which I had inside a table) using ajax. Only the elements that were loaded when the page rendered were getting posted, but not the ones added using ajax after the page was loaded. This can be frustrating to figure out why the elements which were loaded by default are getting posted but the elements which rendered after wards using AJAX are not.

My Theory: When a DOM is loaded, the input elements, which are rendered inside TABLE cells get hooked to the FORM automatically because they are rendered when the DOM got loaded. And when the form is posted, its not the table, but the input elements which are hooked to the form get posted. Now, if you are rendering some elements through ajax, then those elements get hooked up only to the TABLE (in case the FORM is inside the TABLE) and not to the form.

Solution: Shift the TABLE inside the FORM. So, that when you add more elements dynamically, it gets hooked to the form as well.

FORM
TABLE — WORKS

TABLE
FORM — NOT GOOD

We all know that the fixtures files in rails load by default in alphabetical order. And the records inside every single file again load in alphabetical order (not from top to bottom as you define in the fixture file). Considering that having database level constraints (foreign keys, primary keys etc) is advisable idea in spite of having the rails model level relations (belongs_to, has_many etc), loading fixtures in alphabetical order is the most stupid thing I can ever think of. Imagine you have Account and Employee models and employee has_many accounts. So you have an employee_id sitting as a foreign key in the accounts table. Now you want to load your fixtures (rake db:fixtures:load), for test purpose say, which was my requirement. Since ‘A’ comes before ‘E’ in alphabetical order, rails tries to load the addresses first and then the employees fixture file. Obviously this fails because of foreign key violations. Database raising errors is perfectly making sense here. So I looked around for something  which may solve this problem and found that there are solutions available given by some people. But what surprised me is that there is nothing that rails core provided for this.

Anyways, so for people who are into this kinda problem, here is the best one called ActiveFixture that I came across and wish that it would get included in the rails core someday.

Again there is something that may surprise you again. Its not that rails has been stupid all these days to leave us in such a situation. It might so happen that you may not do anything for ordering of the fixtures and still would not get any error although you have foreign key relationships in the database. The reason actually lies in the active record’s database (postgres, mysql sql-lite etc) adapters class. Here is how it goes. While loading the fixtures (I am giving postgres example, as I am using postgres for this project and found it there), rails calls the following method in ActiveRecord::ConnectionAdapters::PostgreSQLAdapter:

def supports_disable_referential_integrity?() #:nodoc:
version = query("SHOW server_version")[0][0].split('.')
(version[0].to_i >= 8 && version[1].to_i >= 1) ? true : false
rescue
return false
end

So this method says, that if you pgsql version is x.y.z, then if  x >= 8 and y >= 1, then it will be able to defer the referential integrity for you and you could load the data from fixtures into your database easily without taking care of the ordering and without facing any data integrity errors Unfortunately I, in my team, was using 9.y.z version of pgsql and all my collegues were on 8.1.4. So they were not getting any errors and I was frustated to know WHY.

Well the secret lies in the ConnectionAdapters for rails I don’t know if we should take it as an advantage, that rails is trying to do or not, but until we have something more intelligent to infer the order of loading the fixtures files from the relationships in the models, rather than defining the load order manually as mentioned here, I am happy that its saving me some time.

`bin_path’: can’t find executable rake for rake-0.8.7 (Gem::Exception)

Now the solution to get away from this bug as of this writing is that you will have to remove the rake.gemspec file from the “your_path_to\Ruby192\lib\ruby\gems\1.9.1\specifications” folder.

And you are good to go now. I do not have really too much time to dig into the matter as to why this might be happening, but it worked for me.

`method_missing_without_paginate’: undefined method `destroy_failed_jobs=’

This is because I have 2.0.3 version of delayed job… The configuration parameters have all been moved to Delayed::Worker now and thus the following works for version 2.x:

Delayed::Worker.destroy_failed_jobs = false
Delayed::Worker.sleep_delay = 60
Delayed::Worker.max_attempts = 3
Delayed::Worker.max_run_time = 5.minutes

or the following:

Delayed::Worker.destroy_failed_jobs = false
silence_warnings do
Delayed::Worker.const_set("MAX_ATTEMPTS", 3)
Delayed::Worker.const_set("MAX_RUN_TIME", 5.minutes)
end

instead of

Delayed::Job.destroy_failed_jobs = false
silence_warnings do
Delayed::Job.const_set("MAX_ATTEMPTS", 3)
Delayed::Job.const_set("MAX_RUN_TIME", 5.minutes)
end

Its very painful to have too many getters and setters in the class and to assign them manually when you create an object of that class or to have constructor which has those hundreds of params.

So, how do we achieve that. Well there are two ways.

1. The hacky way:

class Woo
attr_accessor :f_name, :l_name
def initialize(params)
#instance_eval &block
params.each do |key, value|
eval("self.#{key}= '#{value}'") if self.respond_to? "#{key}="
end
end
end
woo = Woo.new(:f_name => "first_name", :l_name => "last_name")

What we are doing here is that we are trying to assign these instance variables in an eval loop. So the constructor to the method just takes all your parameter hash and then tries to see if your class responds to that method setter (which it should as you have defined the att_accessors for those instance variable already), and then assigns them the corresponding value from the hash.

2. The cleaner way, but which hides what you have inside as attributes

require 'ostruct'
Class woo < OpenStruct
end
woo = Woo.new(:f_name => "first_name", :l_name => "last_name", any_no_of_craps...)


OpenStruct is nothing but another container like a hash in ruby which just gets better when it comes to serialization of these objects (which in my own case is a need)

Hope that helps a bit to someone!!

config.gem “capistrano”
config.gem ‘capistrano-ext’

In this case, you might get the error :

no such file to load — capistrano-ext
bla-bla-bla

All you need for your app to find the gem (I am assuming that you have already installed the gem by running the command : rake gem install capistrano-ext) is following:

config.gem “capistrano”
config.gem ‘capistrano-ext’, :lib => ‘capistrano’

If you are using Mocha and Shoulda both, then please load Mocha after you have loaded Shoulda. Like following:

config.gem “shoulda”, :lib => “shoulda”, :source => “http://gems.github.com”, :version => “>=2.11.3″
config.gem ‘mocha’

If you load Mocha before Shoulda, what happens is that Mocha gets crazy with the expectations. You might see your tests failing because of some weird expectations that are not set in the current failing test but were set somewhere else in some other test.

So, in a nut shell, Mocha starts keeping the expectations across tests instead of wiping them off after each test, as it is expected to do.

Then I happened to watch Dave Thomas’s video on metaprogramming as many as thrice to really sink in whats going on. It’s so dam! confusing in start, I must say. But once you sink in the fact is that even all the classes in ruby are instances of the type Class at the end of the day, it all starts making sense.

So lets see what is this:

To start with lets say we have a class Animal {}

Now if I say, Animal.class_eval { # some code here may be a method definition}, what this will do is induce methods on the instance’s of the class Animal. Yes you read right, it’s the instances of the class Animal who will get methods defined inside the class_eval block of a class and not the class Animal itself.

Why so… if at all like this, then why is this stupid naming convention there to confuse the learners anyways. Exactly this went just now through your mind, right? So it did through my mind when I read it for the first time. But think it like this. Who is the receiver of the class_eval here. Receiver is the class Animal. So the methods will go in Animal class. Now if the methods go in the class Animal, then obviously they are available to the instances of Animal. RIGHT?

Now look at the other one, Animal.instace_eval {# some code goes here may be some method definition}. Now where are these methods goign to go. Lets analyze this in a logical manner. Who is the receiver here. Receiver is instance Animal. So the methods should go to the instance Animal and not the class Animal. Now, as I said a little while ago, every class is an instance of class Class. And therefore, there methods will go in the metaclass Animal (Represented as A’). This, in terms of Dave Thomas, is called ghost class or anonymous class which we cannot instantiate but does come in to play when any class is evaluated as an instance.

The above things would be easily get cleared to those who are familiar with the go-one-step-right for methods in ruby funda!

So, for those who do not know this, I would recommend watch the Dae Thomas’s videos on metaprograming. For those who hae forgotten and need some hint, read the following:

Ruby simply says, that the instances are behaviors are kept side by side, the object (receiver of the method call) being on the left and the methods that can be called on it are on the right side of it.

a ->(instance methods go in one step right to) Animal -> (class methods go in one step right to) Animal’

Still confusing, then u have really forgotten, go and read more

Thanks for reading (I am really lazy in giving good graphical examples, I am sorry for that. But that you might find out in some good book )

Definition : “The phenomenon of a piece of code writing another piece of code on the fly at the run time is metaprograming”

Definition seems to be very simple, but the implementation is not that simple, at least for me

I am just introduced to this (metaprogramming) world. Learnt about it, because I started following Dave Thomas, the pragmatic programmer. I watched the seven videos presented by him about the ruby metaprgramming, mixins, bindings, lamda, procs etc. I would say the videos are worth watching and so is the book Agile web Development with Rails by him. It’s very well written !! I must say.

So, I got exited after the videos and the book and couldn’t stop myself from penning down a few words about, what made me mad the most :  “Metaprograming”.

To start with lemme ask you a question “Have you ever wondered how come the things like att_reader or attr_accessor allow you to access the attributes of a particular modle in Ruby?“. Although Ruby as a language says that all the attributes of a model are inherently private. For example, let’s say I have a class

class Vehicle
attr_accessor :no_of_wheels
def initialize(no_of_wheels)
@no_of_wheels = no_of_wheels
end
end

vehicle = Vehicle.new(2)
puts “The vehicle has #{vehicle.no_of_wheels} wheels”
vehicle.no_of_wheels = 4
puts “The vehicle has #{vehicle.no_of_wheels} wheels”

Running the above program gives you the following output :

The vehicle has 2 wheels
The vehicle has 4 wheels

How is that possible!!! If you are a JAVA guy (like me), you will definately start pulling your hair when this is working inspite of not finding any getter or setter defind for the same in the class hirarchy any where. What is this magic. How come I am not getting the error on accessing the private instance variable @no_of_wheels in the Vehicle class. Hmmm… thats insane.

Here is Metaprogramming coming to play. In fact, what just happened here is that as soon as you say attr_accessor :instance_var_name, ruby inserts the gettetrs and setters as two instance methods on the fly in the Vehicle class for you. so in effect that single line of code makes the ruby class look like this:

class Vehicle
def initialize(no_of_wheels)
@no_of_wheels = no_of_wheels
end
def no_of_wheels() #getter
@no_of_wheels
end
def no_of_wheels=(no_of_wheels) #setter
@no_of_wheels = no_of_wheels
end
end

So at the run time, the no_of_wheels is available on the instances of the Vehicle class!! This is metaprogramming!

Now this also doesn’t happen out of the thin air. The code for the attr_accessor is present in Module class an is implemented in such a way that it generates the getters and setters for you.

OK, let’s do this. Let’s write our own implementation of the attribuet accessors. You will find mostly this example lying around all over the internet and the reason is probably that this is the most simply explained and makes most sense as the ruby newbie’s, like me, already see a lot of’em lying around as soon as they start with this monster language.

So here we go. In this example I’ll try to open the class Module and add my attribute accessor to it. Let’s call our attribute accessor as : access_vars

class Module
def getter_setter_for(*vars)
vars.each do |var|
class_eval
“def #{var}”
“@#{var}”
“end”
“def #{m}=(val)”
“@#{m}” = val”
“end”
end
end
end

And now in our class we can just say :

class Vehicle
getter_setter_for :no_of_wheels
def initialize(no_of_wheels)
@no_of_wheels = no_of_wheels
end
end

And this will just get us the getters and setters inserted on the fly when the class is loaded.
So here, the one line of code getter_setter_for or attr_accessor can write code on the fly. This is what metaprograming is!!

That’s it.