30/05/2010
RVM (Ruby Version Manager) is a tool which lets you install and switch between multiple ruby versions. RVM has also something called Named Gem Sets. This is pretty cool because you can create many different gem sets for different types of apps. Here is how to do it (I assume you have rvm already installed if not check this out):
- go to your project folder and create new file called .rvmrc
- open .rvmrc and add rvm ruby-version@your-gem-set for example rvm ruby-1.9.1@railsgems
- close file and type: rvm gemset create your-gem-set (this will create new set)
- type gem list (you should see empty list with no gems installed)
It’s almost as you would start with a fresh system.
14/01/2010
I wrote simple dfs in ruby:
def dfs(node, value, queue)
return false if node.nil?
return true if node.data == value
queue.push node.right unless node.right.nil?
queue.push node.left unless node.left.nil?
dfs(queue.pop, value, queue)
end
for node:
class Node
attr_accessor :left, :right, :data
end
13/01/2010
This was covered multiple times already. I’ve created this little snippet to remember the difference between different types of variables in ruby:
class A
@@foo = "class variable of the class A"
@foo = "class instance variable of the class A"
def instance_method
@foo = "instance variable of the class A"
end
def self.class_method1
# class variables are visible to and shared by the instance and class methods
@@foo
end
def self.class_method2
# class instance variables are visible to and shared by the class methods
@foo
end
end
p A.new.instance_method # instance variable of the class A
p A.class_method1 # class variable of the class A
p A.class_method2 # class instance variable of the class A
class B < A
@@foo = "class variable of the class B"
@foo = "class instance variable of the class B"
end
p B.class_method1 # class variable in B
# class variable in A is overwritten by one in B !!!
p A.class_method1 # class variable in B
p B.class_method2 # class instance variable of the class B
# class instance variable in A is NOT overwritten by one in B !!!
p A.class_method2 # class instance variable of the class A
11/01/2010
Anemone is a pretty cool DSL used for web crawling. I used it with Hpricot to get a feeling for what’s possible. Below is a simple example which crawls and scrappes data from a popular polish real estate website otodom:
require 'rubygems'
require 'sanitize'
require 'anemone'
require 'open-uri'
require 'hpricot'
#otodom.pl
Anemone.crawl("http://otodom.pl/index.php?mod=search&act=searchResults&qid=46911208",
{:storage => Anemone::Storage.PStore("crawl1.pstore")}) do | anemone |
# filter out useless pages
anemone.focus_crawl do |page|
page.links.delete_if do |x|
(x.to_s =~ /mod=search&act=searchResults&qid=/).nil? and
(x.to_s =~ /[a-zA-Z]+-id[0-9]*\.html$/).nil?
end
end
# process details pages
anemone.on_pages_like(/[a-zA-Z]+-id[0-9]*\.html$/) do | page |
doc = Hpricot(page.doc)
price = doc.at("//strong[@id='offerPrice']")
location = doc.at("//dl[@class='stripeMe'] > dd")
desc = doc.at("//div[@id='offerDesc'] > p")
offer_no = doc.at("//div[@id='offerFoot'] p[@class='toLeft']/span/strong")
created_at = doc.at("//div[@id='offerFoot'] p[@class='toRight']/span/strong")
photos = doc.search("//div[@id='imageList']/p/a")
end
end
20/07/2009
Very often when looking at the code in rails plugins you can run into this:
module Taggable
def self.included(base)
base.extend(ClassMethods)
end
module module ClassMethods
#methods here
end
end
This is a part of a bigger pattern which is shown below:
module ModuleA
def self.included(base)
# add class methods from ModuleB
base.extend(ModuleB)
end
end
module ModuleB
def act_as_hello
p "hello from module B"
end
end
class ClassC
#class body here
end
# include moduleA in classC
ClassC.send(:include, ModuleA)
class ClassD < ClassC
act_as_hello
end
classD = ClassD.new
The pattern is used often when developing plugins with ActiveRecord. What we gain by inheriting from ClassC (class ClassD < ClassC) are instance methods from ModuleA. This is done by:
ClassC.send(:include, ModuleA)
Moreover since ModuleA is included in ClassC, ModuleA’s initializer def self.included(base) will be invoked at the time ModuleA is mixed with ClassC. The invocation will call base.extend(ModuleB). In this case base represents ClassC which will be extended by adding class methods from ModuleB. The ModuleA’s init method is shown again below:
def self.included(base)
# add class methods from ModuleB to ClassC
base.extend(ModuleB)
end
At the end our ClassD has now access to all class methods defined in ModuleB. act_as_hello will be called during ClassD initialization:
class ClassD < ClassC
act_as_hello
end
4/04/2009
Here are few links which helped me understand few ruby concepts: