Posts Tagged ‘ruby’

rake 带参数就这么做

Posted: May 17, 2011 in Ruby
Tags: ,
task :t1, :a1, :a2, :needs => [:t2, :t3] do |t, args|
  args.with_defaults(:a1 => 'default_1 in task t1', :a2 => 'default_2 in task t1')
  puts args

task :t2, :a1, :a2 do |t, args|
  args.with_defaults(:a1 => 'default_1 in task t2', :a2 => 'default_2 in task t2')
  puts "this is t2"
  puts args

task :t3, :a1, :a2 do |t, args|
  args.with_defaults(:a1 => 'default_1 in task t3', :a2 => 'default_2 in task t3')
  puts "this is t3"

可以执行rake t1[1,2]或者rake t1试试

Single table inheritance in Rails3

Posted: March 18, 2011 in Rails
Tags: ,

Active Record allows inheritance by storing the name of the class in a column that by default is named “type” (can be changed by overwriting Base.inheritance_column). This means that an inheritance looking like this:

class Company < ActiveRecord::Base; end
class Firm < Company; end
class Client < Company; end
class PriorityClient < Client; end

When you do Firm.create(:name => “37signals”), this record will be saved in the companies table with type = “Firm”. You can then fetch this row again using Company.where(:name => ’37signals’).first and it will return a Firm object.

If you don’t have a type column defined in your table, single-table inheritance won’t be triggered. In that case, it’ll work just like normal subclasses with no special magic for differentiating between them or reloading the right type with find.

Note, all the attributes for all the cases are kept in the same table. Read more: singleTableInheritance

Just some notes after reading “Eloquent Ruby” chapter two.

  • use unless in place of if not
  • use until in place of while not

You should think that do sth in the unless or until block unless/until condition is true.

Use each, Not for

Case statements use the === operator to do the comparisons. Since classes use === to identify instances of themselves, you can use a case statement to switch on the class of an object. And you can use a case statement to detect a regular expression match.

only false and nil are treated as false, you should avoid testing for truth by testing for specific values.

@first_name ||= '' shorter than @first_name = '' unless @first_name

Just some notes after reading “Eloquent Ruby” chapter one.


use two spaces per indent


There are good reasons for adding comments to your code, the best being to explain how to use your software masterpiece. These kinds of “how to” comments should focus on exactly that: how to use the thing. Don’t explain why you wrote it, the algorithm that it uses, or how you got it to run faster than fast. Just tell me how to use the thing and remember that examples are always welcome.

Sometimes it’s also wise to include a “how it works” explanation of particularly complicated bits of code. Again, keep this kind of explanation separate from the “how to”.

The occasional in-line comment can also help.

Remember, good code is like a good joke: It needs no explanation.

Camels for Classes, Snakes Everywhere Else

  • Almost everything in this context means methods, arguments, and variables, including instance variables use snake case.
  • Class names are camel case.
  • Constants use all uppercase, punctuated by underscores.


both in method definitions and calls surround parenthess.

don’t surround parenthess:

  • conditions in control statements
  • defining or calling a method with no parameters
  • puts, instance_of?, and your right feeling

Look set.rb in your ruby lib path for more ruby conventions.


  • end the name of a method that answers a yes/no or true/false question with a question mark
  • reserve ! to adorn the names of methods that do something unexpected, or perhaps a bit dangerous

My vpn sp have twelve ip, so I want to choose the best ip.

#!/usr/bin/env ruby
#coding: utf-8

ping_count = 10

servers = (1..12) { |el| "us#{'%03d' % el}" }

results = []

servers.each_with_index do |el, i|
  r = `ping -q -c #{ping_count} #{el}`
  puts "processing: #{'%2.2f%' % ((i+1)/12.0*100)}" if i < 11

  #The ping utility returns an exit status of zero 
  #if at least one response was heard from the specified host;
  #a status of two if the transmission was successful but no responses were received;
  packet_loss = r.scan(/d+.d+(?=%)/)[0]
  avg = r.scan(/d+.d*(?=/)/)[1]
  results << [el, [packet_loss.to_f, avg.to_f]] if $?.exitstatus == 0

puts "finished!"

puts results.min { |x, y| x[1][0] <=> y[1][0] and x[1][1] <=> y[1][1] }

Beware of RSpec’s before :all

Posted: March 14, 2011 in Ruby
Tags: , ,

When you add data in an RSpec before :all, it’s not inside the transactions RSpec places around each test. rake spec clears the database before running all the specs, but the data created in before :all will hang around after it runs. This introduces an order dependency between specs. A spec that assumes the database (or one table) is empty will run fine if it runs before the before :all, but can fail if it runs after. Your specs can start failing just because you reorganized them, which changed their run order.