Skip to content

Configuring delayed_job 2.x

October 6, 2010

I was configuring the delayed job and I got problems like :

`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

Advertisements

Awesome date time plugin

September 24, 2010

After a long time, I have seen such a great datetime picker for rails. “Awesome” is just not the word for it 😀

Ruby Class with Mass assignable attributes

September 23, 2010

Well, this is very weired again, but it seems ruby class does not allow me to have mass assignable attributes as you could do with the ActiveRecord models using attr_accessible or attr_accessor.

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!!

no such file to load — capistrano-ext

September 22, 2010

If you are using capistrano and capistrano-ext together, please note that the following line in you environment.rb might not be sufficient:

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’

Mocha should be loaded after Shoulda with rails 2.3

September 22, 2010

Well, this one really drove me crazy. So I decided to finally pen it down. May this help somebody else in future. This might not be very new, but really crazy stuff.

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&#8221;, :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.

class_eval and instance_eval

June 1, 2009

Hey guys this is the most amazing and funny thing I have learnt in my life time. I started laughing like anything when I learnt how this behaves and things started going over my head for some time 🙂

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 🙂 )

Ruby Metaprograming

May 25, 2009

The very hot and controversial topic I would say in the dynamic language world is Metaprograming. I am saying controversial, coz if not used properly it may lead to too many magics happening all across your application and it might become a nightmare to maintain it.

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.