If you have a lot of readings then Struct is the winner.

If you have equal read/write then Hash

And forget for OpenStruct

Here is why and how I benchmark all those methods



require 'benchmark'
n = 500000

puts "convertions"
Benchmark.bm do |x|
 x.report("to_i") { n.times do   ; "123456789".to_i; end }
 x.report("to_s") { n.times do   ; 1234567890.to_s; end }
 x.report("to_sym") { n.times do   ; 1234567890.to_sym; end }
end

user     system      total        real
to_i  0.310000   0.000000   0.310000 (  0.315844)
to_s  0.490000   0.000000   0.490000 (  0.490607)
to_sym  0.170000   0.000000   0.170000 (  0.171511)



Benchmark.bm(30) do |x|
 x.report("string.to_i == number") { n.times do   ; "123456789".to_i == 1234567890; end }
 x.report("number.to_s == string") { n.times do   ; 1234567890.to_s == '1234567890'; end }
 x.report("string.to_sym == string.to_sym") { n.times do   ; '1234567890'.to_sym == '1234567890'.to_sym; end }
 x.report("num.to_sym == string.to_sym") { n.times do   ; 1234567890.to_sym == '1234567890'.to_sym; end }
 x.report("number.sym == number.sym") { n.times do   ; 1234567890.to_sym == 1234567890.to_sym; end }
end

user     system      total        real
string.to_i == number           0.400000   0.000000   0.400000 (  0.401863)
number.to_s == string           0.740000   0.000000   0.740000 (  0.744603)
string.to_sym == string.to_sym  0.560000   0.000000   0.560000 (  0.574106)
num.to_sym == string.to_sym     0.460000   0.000000   0.460000 (  0.459292)
number.sym == number.sym        0.400000   0.000000   0.400000 (  0.399014)

Generating random string

ActiveSupport::SecureRandom.hex(16)

The first Rails framework was fast. then it become slow, big and the idea of convetion over configuration becomes more poisoned.

Currently to start with Rails you have to learn a lot of stuff which are added just now and is not sure how long they will stay.

Also Rails is not targeting the developers to be fast but is targeting to be the perfect framework.

The price for that is that almost a year and a half there is no new version while the they refactor it.

No goodies like scafolding, only enterprise stuff around.

That is my personal opinion on this framework.

As I like to say – you cant leave your followers without food for such long time.

The original code

<%= select(“city”,”kind”, t(:place_types).map.map!.each{|key, value| [value, key]}, {:include_blank => t(:chose), :selected => @city.kind}) %>

The bad code

t(:place_types).map.map!.each{|key, value| [value, key]}, {:include_blank => t(:chose), :selected => @city.kind})

the replacement

key_values = t(:place_types).collect{|key, value| [value.to_s, key.to_s, ]}

Rails.ouch.ouch.omg!

The idea of the Searchlogic is to save you time and give flexibility.

The first time I saw this gem  I was very excited about it.

With only a few lines of code an you have the whole search done. I have start using it.

Once I want to apply it to a complicated search. The problem was that I have to write more code and “patches” in order to keep the Searchlogic working….

So my advice is – don’t use such boosters if you can apply your own solution. There will be aways a time when you want to extend your search and you will loose a lot of time search how to do it with the 3rd party solution.

Do it yourself.

I have just finished one method and I was not happy with the code. Then I put a comment on top of the method “Far from perfect….”.

Then I read the class – it was ugly.

here is the before

def validate
 return if is_email == false
 found = InternetComunicatorType.find(:first, :conditions => {
 :is_email => true,
 })

 return unless found

 if found.id != id
 errors.add(:is_email, "We have already email type")
 return
 end
end

here is the after

def validate
  if is_email
    found = InternetComunicatorType.find(:first, :conditions => {
      :is_email => true,
    })

    if found and found.id != id
      errors.add(:is_email, "We have already email type")
    end
  end
end

The result is much far readable