loss-zz

这两个话题都是一个很大的话题，本不应由我这个对ruby或rails都半通不通的人来说，昨晚看到了@keakon 这篇文章 你该选择Ruby on Rails吗？ ，发觉似乎大部分人对它们误解都比较大，所以我在这稍微说下个人见解

大部分语言，静态的动态的，其实都更偏向于机器语言，是人类对机器说话，目的是让我们的话能让机器懂得。
而ruby，大家都知道它似乎很「自由」，一个函数可以有多个别名，比如得到 Array 的长度，有size，length甚至count，很多人费解为什么非得安上那么多别名，一个不就好？但如果以人类语言的「语境」来理解这个，就相当明了，以之前我的一段关于Notifications实现的代码为例子
def notifs_count self.notifs.count end
以上是说得到未读提醒计数，用self.notifs.size或者self.notifs.length都可以得到一样的结果，但却没count那么符合人类的「语境」。可以说ruby的自由，最大的目的是为了让语言看起来更像「人」说的语言，比如这一段代码

loss-zz

#-----数据库schema
#attachable 为虚拟属性，为兼容以后的私信notif之类的
create_table :notifications do |t|
  t.belongs_to :user
  t.references :attachable, :polymorphic => true
  t.text       :content
  t.timestamps
end
add_index :notifications, :user_id
add_index :notifications, [:attachable_id, :attachable_type]

loss-zz

class Post < ActiveRecord::Base
  belongs_to :user
  belongs_to :topic, :counter_cache => true, :touch => :last_updated_at

  scope :major, where(:major=>true)
  scope :reply, where(:major=>false)

  validates_presence_of :body

  after_create  :update_cached_fields

loss-zz

# encoding: utf-8
class Topic < ActiveRecord::Base
  include Redis::Objects

  #Redis::Objects
  counter :hits #利用redis存储点击

  belongs_to :user
  belongs_to :node

loss-zz

module ApplicationHelper
  include Twitter::Extractor

  def auto_text_link(text)
    usernames = extract_mentioned_screen_names(text).uniq
    usernames.each do |username|
       text.gsub!("@#{username}","@<a href=\"#\">#{username}</a>")
    end

    auto_link(text, :urls, :rel => "nofollow", :target => "_blank")

loss-zz

# encoding: UTF-8
# This file is auto-generated from the current state of the database. Instead
# of editing this file, please use the migrations feature of Active Record to
# incrementally modify your database, and then regenerate this schema definition.
#
# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).