cisolarix (cisolarix)

请教 ?z 中的问号运算符的用法

cisolarix — Tue, 04 Nov 2014 14:16:02 +0800

今天看 ActiveModel::Validations 部分的文档，发现了这样的用法：

由于第一眼没见过问号这么个用法，于是在 irb 里测试了一番，并搜索一番，得出结论：

?z 就相当于 "z"

于是，问题来了，如果 ?z 与 "z" 是一样的作用，用前者有什么其他优势吗？

Rails 中用 RabbitMQ 做消息队列 [译]

cisolarix — Wed, 29 Oct 2014 10:44:02 +0800

一年前，我曾写过我们的一个仪表板程序以及如何使用 Faye 延迟消息（现已打包成 gem）来解决性能问题。

从最开始，我们就选择了面向服务的架构，事实证明这也是我们做过的最棒的决定。套件（到写这篇文章时止已有 8 个应用）中的每一个程序都只负责业务的一部分。仪表板程序用来显示其他应用的信息给用户。

不过，这并不是全部。这个项目最重要的特性之一就是可以在应用之间导入、导出数据。而且，这要求在各应用之间互相提供读写接口，我们需要处理网状结构，而不仅是星型结构。

特性与用户的同步增长导致了许多性能问题。应用间的连接都通过 HTTP API 以“我要某某某”这种方式进行，套件开始变得缓慢。

我们考虑过重新设计架构，减少依赖，但是由于每个应用的核心功能都是独立且精心设计过的，所以实际上能提升的空间很有限。并且，以后我们还可能将一些功能抽出来，变成新的应用。

一个武断的解决方法是：

我们只要采用 HTTP 缓存就可以了其实不然。

HTTP cache 的最大问题就是最大生命周期。系统中有两种场景下使用缓存：

用户执行了某种操作，跳到其它的应用中且希望能看到更新之后的数据
用户来到仪表板，希望看到数据的当前状态（这些状态可能已经数天未变了）

几乎没法用定长时间来确定资源需要被缓存多久。如果时间太短，请求就会太多，尽管数据可能压根没变过。如果时间太长，我们可能会收到成堆的用户邮件，抱怨系统没有运行，其实只是因为他们看到的是未及时更新的数据。

缓存的出发点是为了提升性能，不是为了破坏用户体验。

那么我们该怎么办？

答案是：回到架构。

消息传递是解决之道

面向对象的编程原则推崇告诉，而不是问的模式。如果我们将之引申到架构的高度，解决思路就自然出现了。

无需让消费者每次问生产者要资源，我们让生产者告诉消费者发生了什么变化。

废话少说，我们上手实战用 RabbitMQ 消息系统来代替老旧的 HTTP API 吧。

RabbitMQ 是什么

RabbitMQ 是实现了 AMQP 协议的开源消息中介、队列系统，由 Erlang 写就。信息标签包括：

管用的消息系统

这一点我发现是确实没错。

要了解 RabbitMQ 能做什么，我们得看看示例拓扑图。

我们将采用发布/订阅拓扑，并采用多个 fanout 交换与队列。

安装 RabbitMQ

这个部分因操作系统而异。RabbitMQ 的官网有许多指南供参考。如果恰巧你的系统是 Mac OS X，且安装了 Homebrew，你只需：

brew install rabbitmq

用以下命令启动：

/usr/local/opt/rabbitmq/sbin/rabbitmq-server

启动 rabbitmq-server 之后，就可以通过http://localhost:15672 来访问管理界面。默认用户是 guest，密码也是 guest。管理界面很有用。后面的小节我们会展开涉及一些。

简单的架构：博客的仪表板

想像两个应用：一个带博文的博客应用，一个显示最近 5 条博文的仪表板程序。仪表板应用无需向博客应用的 HTTP API 索要最近的博文，我们让博客应用主动说出每一个最新发布的博文。

上图中：

Blog - 用 SQL 数据库的典型 Rails 应用
P - RabbitMQ 生产者
X - RabbitMQ 交换
Queue - RabbitMQ 队列
C - RabbitMQ 消费者
Dashboard - 用 Redis 的 Rails 应用

博客应用中的博文在创建后，会让生产者向交换发出一条消息。交换将消息放入队列。然后，连接到此队列的消费者会抓取这条消息，并更新仪表板的 Redis 缓存。尽管听起来有点复杂，但借助强大的 Ruby 库，我们其实只需很少的工作。

博文发布者

首先，创建基本的博文脚手架

rails new blog
cd blog
bundle
rails generate scaffold post title:string body:text
rake db:migrate
rails server

管理博文的地址在： http://localhost:3000/posts

现在，我们需创建一个 RabbitMQ 生产者。我们称之为发布者。我们将使用 bunny 这个超易用的 RabbitMQ Ruby 客户端。

Gemfile 中加入以下代码：

# blog/Gemfile
gem "bunny"

并运行 bundle install. 下面实现我们的发布者：

# blog/app/services/publisher.rb
class Publisher
  # In order to publish message we need a exchange name.
  # Note that RabbitMQ does not care about the payload -
  # we will be using JSON-encoded strings
  def self.publish(exchange, message = {})
    # grab the fanout exchange
    x = channel.fanout("blog.#{exchange}")
    # and simply publish message
    x.publish(message.to_json)
  end

  def self.channel
    @channel ||= connection.create_channel
  end

  # We are using default settings here
  # The `Bunny.new(...)` is a place to
  # put any specific RabbitMQ settings
  # like host or port
  def self.connection
    @connection ||= Bunny.new.tap do |c|
      c.start
    end
  end
end

现在，每条博文创建后，我们都要调用 Publisher.publish。

# blog/app/controllers/posts_controller.rb
class PostsController < ApplicationController
  # ...

  def create
    @post = Post.new(post_params)

    if @post.save
      # Publish post data
      Publisher.publish("posts", @post.attributes)

      redirect_to @post, notice: 'Post was successfully created.'
    else
      render :new
    end
  end

  # ...
end

就是这样。进行下面的操作前，别忘了重启 Rails 服务器。现在可以创建一条新的博文，来到 RabbitMQ 管理界面，选择“Exchanges”, 选择 blog.posts，可以看到下图：

往下滚动页面，我们可以发现此交换没有绑定。

也就是发送到此交换的消息没有去往任何地方。

现在我们需在交换与仪表板应用间建立一个队列，以便消费者更新其本地缓存。

需要留心持久性： RabbitMQ 发布/订阅示例中使用了按需创建的随机队列。这种方案在某些情况下很好，但是在我们这里并不很适用。假使出于未知原因，我们的仪表板应用挂掉了，这个临时队列就会被删除，其中发自博客应用的消息就再也不会到达仪表板应用了。这就是为什么我们需要一个静态的可持续的队列来保存消息，以便仪表板应用断线并重新连接后也能收到之前的所有消息。

仪表板消费者

如果你比较熟悉 Sidekiq 或 Resque，下面的内容就很容易。还有一个特别棒的 Ruby 库用来处理 RabbitMQ 消息队列里的消息。这个工具由 @jondot 开发，名叫 sneakers（作者博客）。

我们来创建仪表板应用：

rails new dashboard
cd dashboard

添加一些 gems：

# dashboard/Gemfile
gem 'redis-rails'
gem 'redis-namespace'
gem 'sneakers'

运行 bundle install. Redis 和 sneakers 都需要设置一番：

设置 Redis

# dashboard/config/initializers/redis.rb
$redis = Redis::Namespace.new("dashboard:#{Rails.env}", redis: Redis.new)

设置 Sneakers

# dashboard/Rakefile

# load sneakers tasks
require 'sneakers/tasks'

Rails.application.load_tasks
# dashboard/config/initializers/sneakers.rb
Sneakers.configure({})
Sneakers.logger.level = Logger::INFO # the default DEBUG is too noisy

仪表板视图

仪表板需要视图来查看是否工作正常。

# dashboard/app/controllers/home_controller.rb
class HomeController < ApplicationController
  def index
    @posts = RecentPosts.list
  end
end

# dashboard/app/views/home/index.html.erb
<h2>Recently updated posts</h2>

<table>
  <thead>
    <tr>
      <th>Title</th>
    </tr>
  </thead>

  <tbody>
    <% @posts.each do |post| %>
      <tr>
        <td><%= post[:title] %></td>
      </tr>
    <% end %>
  </tbody>
</table>

# dashboard/config/routes.rb
Rails.application.routes.draw do
  root to: "home#index"
end

工人

最后，我们来建立 sneakers 工人。你可能已经注意到了，这与 sidekiq 的工人很像。

# dashboard/app/workers/posts_worker.rb
class PostsWorker
  include Sneakers::Worker
  # This worker will connect to "dashboard.posts" queue
  # env is set to nil since by default the actuall queue name would be
  # "dashboard.posts_development"
  from_queue "dashboard.posts", env: nil

  # work method receives message payload in raw format
  # in our case it is JSON encoded string
  # which we can pass to RecentPosts service without
  # changes
  def work(raw_post)
    RecentPosts.push(raw_post)
    ack! # we need to let queue know that message was received
  end
end

就是这样，仪表板应用已经就绪。要启用工人，运行：

WORKERS=PostsWorker rake sneakers:run

在 RabbitMQ 管理页面，我们可以看到 dashboard.posts 队列已经创建

现在，如果你新发布一条博文的话，在 blog.posts 交换中就会出现一条消息，但 dashboard.posts 队列依然是空的。为什么呢？因为我们需要在交换与队列间建立一个绑定。

全部联系到一起

我们需责成 blog.posts 交换将收到的消息发送给 dashboard.posts 队列。尽管这个操作可以在 RabbitMQ 管理页面完成，但是我们最好将此操作做成可被自动执行（比如，部署时自动执行）的配置文件的形式。我们还是使用 bunny 库：

# config/Rakefile
namespace :rabbitmq do
  desc "Setup routing"
  task :setup do
    require "bunny"

    conn = Bunny.new
    conn.start

    ch = conn.create_channel

    # get or create exchange
    x = ch.fanout("blog.posts")

    # get or create queue (note the durable setting)
    queue = ch.queue("dashboard.posts", durable: true)

    # bind queue to exchange
    queue.bind("blog.posts")

    conn.close
  end
end

运行：

rake rabbitmq:setup

在 RabbitMQ 管理页面查看 blog.posts 交换的绑定。

这下，每个新建的博文，都会被作为消息发送到 blog.posts 交换中去，然后路由到 dashboard.posts 队列，被 PostsWorker 读取到，再由 RecentPosts 服务放进 redis。

复杂架构

上面的示例演示了如何连接两个应用。现实世界里，应用间的连接可就复杂多了。请看下图：

与上一示例比，有如下不同：

Blog 现在发布多条信息到多个交换
Dashboard 从多个队列获取消息
Admin 另外一个应用，同时兼任生产者与消费者
Exchange ↔ Queue 绑定复杂多了 - 可能是一对多（blog.posts）或多对一（*.page_views）
Admin 用 SQL 取代了 redis 的消费者应用

我们过一遍其中几个点

缓存存储

为缓存选择合适的存储是个很宽泛的话题。我只举几个例子。

页面访问统计

另一个使用 redis 的地方是获取页面访问统计。用 INCR, INCRBY 或 HINCR，很容易原子性地增长计数器，而无需顾虑竞争条件。猛击这儿来看示例。

带过滤与排序的结构化缓存

当然，redis 也不是银弹。有时我们也需要对缓存进行过滤或排序。这种情况下，我们可以创建一个普通的 SQL 数据库模型，并在其中存储必要的信息。见 Admin 应用中存储博文的示例，用到了 Blog::Post 模型与 Blog::PostsWorker。

Exchange ↔ Queue 绑定

复杂的架构需要复杂的绑定。幸运的是，我们可以用上面示例中的方法来解决。我们只需修改下启动任务：

# config/Rakefile
namespace :rabbitmq do
  desc "Setup routing"
  task :setup do
    require "bunny"

    conn = Bunny.new
    conn.start

    ch = conn.create_channel

    # connect one exchange to multiple queues
    x = ch.fanout("blog.posts")
    ch.queue("dashboard.posts", durable: true).bind("blog.posts")
    ch.queue("admin.posts", durable: true).bind("blog.posts")

    # connect mutliple exchanges to the same queue
    x = ch.fanout("admin.page_views")
    ch.queue("dashboard.page_views", durable: true).bind("admin.page_views")

    x = ch.fanout("blog.page_views")
    ch.queue("dashboard.page_views", durable: true).bind("blog.page_views")

    conn.close
  end
end

结语

RabbitMQ 处理复杂的面向服务的系统有很大的潜能。用可持续的队列，我们可以在一部分应用挂掉的时候，依然可以保持数据的一致性。对于仪表板式的应用，用户依然可以访问缓存过的数据，即使下层应用挂掉的时候。

与不断地访问 API 相比，消息传递性能提升明显。速度，持续性与可用性都有提高。理论上，我们放弃一些临时的一致性和实时数据更新。然而大多数情况下，我们发现用户在应用间访问时，缓存已经得到更新，最新的数据也是可用的。

可用的示例程序托管在此。

求助，有没有方法快速递格式化以下代码?

cisolarix — Sat, 27 Sep 2014 10:23:15 +0800

这是格式化之前的代码：

class CreateStudents < ActiveRecord::Migration
  def change
    create_table :students, :comment => "学生信息表" do |t|
      t.string :number, :comment => "学号"
      t.string :name, :comment => "姓名"
      t.date :birthday, :comment => "生日"
      t.string :gender, :comment => "性别"
      t.string :id_type, :comment => "证件类型"
      t.string :id_number, :comment => "证件号码"
      t.string :country, :comment => "国别"
      t.string :nation, :comment => "民族"
      t.string :birth_place, :comment => "籍贯"
      t.string :political_status, :comment => "政治面貌"
      t.string :education_level, :comment => "培养层次"
      t.string :enroll_method, :comment => "入学方式"
      t.date :enrolled_at, :comment => "入学时间"
      t.string :charge_type, :comment => "收费类别"
      t.string :enrolled_year, :comment => "学籍年度"
      t.string :enrolled_place, :comment => "生源所在地"
      t.string :bank_card_number, :comment => "银行卡号"
      t.string :bank_account_number,  :comment => "银行账号"
      t.boolean :is_active_duty, :default => false, :comment => "是否现役军人"
      t.boolean :is_equivalent_degree, :default => false, :comment => "是否同等学历"
      t.boolean :is_on_record, :default => true, :comment => "是否在籍"
      t.boolean :is_at_school, :default => true, :comment => "是否在校"

      t.timestamps
    end
  end
end

这是格式化之后的代码：

class CreateStudents < ActiveRecord::Migration
  def change
    create_table :students, :comment => "学生信息表" do |t|
      t.string  :number,               :comment => "学号"
      t.string  :name,                 :comment => "姓名"
      t.date    :birthday,             :comment => "生日"
      t.string  :gender,               :comment => "性别"
      t.string  :id_type,              :comment => "证件类型"
      t.string  :id_number,            :comment => "证件号码"
      t.string  :country,              :comment => "国别"
      t.string  :nation,               :comment => "民族"
      t.string  :birth_place,          :comment => "籍贯"
      t.string  :political_status,     :comment => "政治面貌"
      t.string  :education_level,      :comment => "培养层次"
      t.string  :enroll_method,        :comment => "入学方式"
      t.date    :enrolled_at,          :comment => "入学时间"
      t.string  :charge_type,          :comment => "收费类别"
      t.string  :enrolled_year,        :comment => "学籍年度"
      t.string  :enrolled_place,       :comment => "生源所在地"
      t.string  :bank_card_number,     :comment => "银行卡号"
      t.string  :bank_account_number,  :comment => "银行账号"
      t.boolean :is_active_duty,       :default => false,  :comment => "是否现役军人"
      t.boolean :is_equivalent_degree, :default => false,  :comment => "是否同等学历"
      t.boolean :is_on_record,         :default => true,   :comment => "是否在籍"
      t.boolean :is_at_school,         :default => true,   :comment => "是否在校"

      t.timestamps
    end
  end
end

Action mailer 的 reply-to 是不是有问题？

cisolarix — Fri, 20 Sep 2013 22:12:19 +0800

RT.

用 action mailer 以 smtp 的方式通过 mailgun 发送。但是收到邮件之后回复的时候，回复地址不能正确识别。还是看图吧。

这是代码。

这是 gmail 中查看源文件的结果（在 qq 邮箱里也是同样的结果）

看，回复地址用的是 from 的那个地址，并不是 reply-to 的那个地址。

我看人家正常的回复地址那个地方是 reply-to，而我的是 Reply-To[] 。

PS：我的 Rails 版本是 4

订阅了 users 页面几乎所有的 RSS feed

cisolarix — Sun, 28 Jul 2013 19:55:44 +0800

Google Reader 关闭之后，先后试用了几家提供订阅服务的网站，感觉都不是很喜欢。正好试用 NetNewsWire, 就将 0http://ruby-china.org/users 页面中所有人都订阅了。当然，是指提供了 feed 的诸位。有空慢慢拜读各位大作。

Nitrous 在维护中？

cisolarix — Fri, 12 Jul 2013 10:42:04 +0800

如图，我选的是东亚的节点，不知道是所有的节点都维护还是怎么的。

thoughtbot 的按月付费好贵啊

cisolarix — Fri, 10 May 2013 11:56:05 +0800

比 codeschool, teamtreehouse, tutsplus, frontendmasters 等等要贵一大截。99 刀一个月。有没有人尝试过？

PS: 忘了附上链接了。thoughtbot learn

这么好的重构文章不转怎么行？记 tower.im 的一次重构

cisolarix — Fri, 03 May 2013 12:10:07 +0800

2013.05.01 by @zchar

原链接 http://blog.mycolorway.com/2013/05/01/tower-refactor/

Tower.im上线已经快半年了，这半年来我们团队小步快跑，为 tower 增加了许多新的功能，使它渐渐完善起来，在这个过程中，tower 的代码量也逐渐增加，随着时间的流逝，系统中积淀的糟糕的代码渐渐增多，于是趁着节假日的到来，花了些时间对代码做了部分重构，在这里记录下来，和大家分享。

我们知道，重构代码，目的是为了对内让代码变得更精简，提高阅读性和可维护性，而对外不改变旧有的功能，所以首先应该分拆重构任务，一步步执行，不要想一次到位，其次，是通过测试用例保护重构过程，确保重构以后的代码仍然能正常工作。

明确了目标和方法后，我们就可以进入具体的重构阶段了。Tower.im 使用 Ruby on Rails 这个 MVC 的 Web 框架开发，在代码的组织形式上，Rails 社区比较推崇‘Skinny Controller, Fat Model’，因此，这次的代码重构主要在 Controller 层和 Model 层进行。

我们来看一个具体的例子。在 Tower 中，像任务、讨论、文档、文件这样的基础资源，都对应着自己的 Controller，比如任务对应着 todos_controller，讨论对应 messages_controller，这些 controllers 里面定义着一些接口方法，比如对这些基础资源进行增删改等等。在旧有代码中，最复杂的一个方法是为这些基础资源添加评论。这个方法的名称叫 comment，让我们看看老的代码长什么样：

def comment
  @message = @project.messages.active.find_by_guid(params[:muid])
  return render_404 if @message.blank?

  content = params[:comment_content]
  if 1 == paras['_wysihtml5_mode'].to_i
    content.gsub! '

', '

'
    content = Sanitize.clean(content, Sanitize::Config::BASIC)
  else
    content = Sanitize.clean(content).gsub(/[\n\r]{1,2}/, '')
  end 

  if 20000 &lt; content.bytesize
    render json: { errors: [{msg: '内容最多支持 5000 字，太长了保存不了哦',
      target: :comment_content}]}, status: 500
    return
  end 

  attach_guids = params[:attach_guids].present? ? \
    params[:attach_guids].split(',') : [] 

  if content.blank?
    if attach_guids.empty?
      render json: {erros: [{msg: '没有输入内容哦',
        target: :comment_content}]}, status: 500
      return
    else
      pic_count = 0
      filenames = attach_guids.map do |guid|
        ta = current_member.tmp_attachments.find_by_guid(guid)
        pic_count += 1 if ta.content_type.starts_with?('image/')
        ta.name
      end

      content = ((0 &lt; pic_count ? "[#{pic_count}P]" : "") + \
        filenames.join(', ')).truncate(200)
    end
  end 

  @message.cc_members = params[:cc_guids].respond_to?(:split) ?\
    params[:cc_guids].split(',') : []
  @message.last_commentator = current_member
  @message.last_comment_at = DateTime.now
  @message.last_conn_guid = live_conn_guid
  @message.save! 

  comment = @message.comments.create(content: content,
    creator: current_member, last_conn_guid: live_conn_guid) 

  if attach_guids.any?
    tmp_file_dir = "#{::Rails.root.join('files', 'tmp')}"
    attach_guids.each_with_index do |guid, index|
      ta = current_member.tmp_attachments.find_by_guid(guid)
      tmp_file_path = File.join(tmp_file_dir, "#{ta.guid}")
      tmp_file = File.open(tmp_file_path, 'r') 

      comment.attachments.create(team: current_team, attachtarget: @project,
        creator: current_member, byte_size: ta.byte_size,
        content_type: ta.content_type, name: ta.name, file: tmp_file, position: index)
    end
  end 

  comment.reload
  comment.create_event_add(current_member)
  comment.send_new_comment_emails(current_member) 

  @message.reload 

  render json: {
    guid: comment.guid,
    html: render_to_string(
      partial: 'comments/comment',
      locals: {comment: comment}
    )
  }
end

是不是快崩溃了？这么长的代码，既难以阅读，也难以维护，必须重构。先让我们看看重构以后的结果：

def comment
  return render_404 unless @message.is_active?

  content, cc_members, attach_guids = comment_params
  comment = @message.create_comment(content, current_member,
    live_conn_guid, attach_guids, cc_members)

  render json: {
    guid: comment.guid,
    html: render_to_string(
      partial: 'comments/comment',
      locals: { comment: comment }
    )
  }
end

是不是好多了？我理解的重构的核心口诀是“拆”，把复杂代码中的逻辑进一步细分、拆散，放到它应该属于的地方。在拆的过程中，应该考虑到复用，那些拆出来的逻辑应该最大程度的和其它代码共享，达到 DRY 的目的。具体对于 comment 这个接口来说，我们做了如下的几个重构的步骤：

在 controller 中使用 before_filter 注入全局对象

在 comment 方法的第一行，可以看到我们通过 find_by_guid 方法获取了 @message 对象，虽然只是一行代码，但是考虑到整个 messages_controller 里面，绝大多数方法都会复用它，所以可以在 controller 里面定义一个 before_filter 方法，来为需要的接口注入 @message 对象：

before_filter :load_message_instance, only: [:comment]

only 后面可以指定这个 controller 里面有哪些方法是通过 load_message_instance 来注入 @message 变量，接下来，只需要在 messages_controller 里面定义一个 load_message_instance 的 private method 就可以了：

private

  def load_message_instance
    @message = @project.messages.find_by_guid! params.fetch :muid
  end

这样首先通过 before_filter，DRY 掉了 controller 里面绝大多数方法重复的一行代码，虽然看上去微不足道，但是随着 controller 的扩展，积少成多，能让你的代码保持精简。

使用 params helpers 封装评论所需参数

我们知道，controller 中的方法很多时候只是做一个“中转”：接收 http 请求，获取 GET/POST 参数，对参数进行处理后，交由 model 层对数据进行操作，最后将数据经过某种方式的 render 后，返还给浏览器。而在这个中转过程中，我们有大量的操作是在对请求参数做处理，比如在旧版本的 comment 方法中，我们对评论内容进行了过滤，对抄送的成员和附件进行了参数组装，这些操作其实可以放在一个 helper 方法里面来完成，而且考虑到除了 messages_controller 外，其它资源对象的 comment 方法其实在最开始都会对参数进行同样的处理，所以我们可以直接把对 comment 方法的 params 处理封装成一个 application_helper 方法：

def comment_params
  cc_members = params[:cc_members].respond_to? (:split) ? \
    params[:cc_guids].split(',') : []
  attach_guids = params[:attach_guids].present? ? \
    params[:attach_guids].split(',') :[]
  content = get_safe_content(params[:comment_content],
                             1 == params['_wysihtml5_mode'].to_i,
                             attach_guids)

  [content, cc_members, attach_guids]
end

可以看到，这个在 application_helper 中的方法，实际上只是对三个 POST 参数进行了相应的处理，最后以数组的形式返回，而这个 comment_params 方法中，又有一次小的重构，即通过 get_safe_content 方法对复杂的 content 进行处理，实际上这里仍然可以继续优化下去，不过就目前为止，已经足够了。这样，在 messages_controller 里面，我们通过数组的连续赋值特性，就可以一行代码获取数据层实际上需要的数据了：

content, cc_members, attach_guids = comment_params

哇，这样又精简掉了一大堆丑陋的代码。

将模型验证放进模型中

细心的童鞋应该会发现，重构后的代码里面没有任何的错误处理，是我们去掉了这部分代码么？实际上并没有，在 Rails 里面，对数据的合法性验证往往是放在 model 层去处理的，controller 只需要“中转”，没必要去判断。Rails 的 model 类往往会使用一系列的 validators 来对数据进行合法性验证，比如旧有代码里面，我们需要对 content 的长度和是否为空进行判断，其实只需要在 comment 的 model 里，用一个 validates 语句就能搞定：

validates :content,
          presence: { message: "没有输入内容哦" },
          length: { maximum: 20000,
                    too_long: "内容最多支持 5000 字，太长了保存不了哦" }

这样，当 content 本身为空，或者超过长度限制的时候，model 会直接 raise 错误信息，当然，更进一步的，你还可以把错误信息本身放到 I18n 里面，全站复用。

这个改动涉及到 Rails 框架本身的习惯，你当然也可以在 controller 层去做数据验证，但是使用 model 层自己的 validates，才是在正确的地点，做正确的事情。

使用 Concerns 抽象模型结构

最后，是这次优化的重头戏。Rails 社区虽然提倡‘Skinny Controller, Fat Model’，但在实际开发中，太 fat 的 model 层也是很让人头疼的，所以我们引入了 Concerns 机制来对模型层进一步做抽象。关于 Concerns，大家可以参考 DHH 的这篇文章：Put chubby models on a diet with concerns。

对于 tower 来说，基础资源都可以被评论，这个意思是指，每个基础资源的模型都 has_many comments，每个基础资源的模型都有一个 cc_members 字段保存着当前的抄送成员的 id 数组，在 model 中也有一系列的方法来实现对 cc_members 的操作，这些代码其实大部分都可以重用，而且它们都从侧面反映出一个实时，就是基础资源模型本身，应该是一个 commentable 的抽象。因此，我们可以使用 concerns 实现这个抽象：

module Extensions
  module Commentable
    extend ActiveSupport::Concern

    included do
      has_many: comments, as: :commentable, dependent: :delete_all
      belongs_to :last_commentator, class_name: :Member
    end

    def create_comment(content, creator, live_conn_guid, attach_guids, cc_members)
      # 具体代码省略
    end

    def cc_members= (guids)
      # 具体代码省略
    end

    def cc_members
      # 具体代码省略
    end

    def cc_member_add(member)
      # 具体代码省略
    end
  end
end

可以看到，在这个 Commentable 里面，我们抽出了所有 Commentable 对象所应该具有的关系，并且创建了一系列的方法供基础资源使用，这些方法不是接口方法，它们不仅定义了方法名称和参数，还实际提供相应的功能，在完成了这个 concern 以后，我们就可以通过 Module Mixin 的方法，把这个 commentable concern 混入所有基础资源模型里面了：

class Message &lt; ActiveRecord::Base
  include Extensions::Commentable
end

这样，我们只需要在 @message 这个资源对象上调用 create_comment 方法，传入合适的参数，就能完成创建评论的操作了，核心还是，让 model 层去做关于数据的处理，controller 只需要做中间的中转即可。

Concerns 非常强大，在 Tower 中，像回收站 (trashable)、星标 (starable) 等很多功能，都能通过 Concerns 来做抽象，让代码保持简洁。在 Rails4 中，Concerns 也被默认加载，算是众望所归吧。

总结

以上就是对 Tower.im 的一次简单的代码优化，当然，可以做的还有很多，不过目前这个 comment 方法已经可以让人轻松理解，我们的重构目的达到。

再总结一下优化过程：在 Tower 里面拆分任务，小步改进（把复杂的代码先从方法中剥离出来，放到它应该放在的地方），跑通测试，然后循环往复。

最后推荐大家一个网站：Code Climate，如果你的项目也使用 Rails 框架，可以把代码放到上面跑一跑，看看最后是个什么级别的呢？

参考文档

1、重构 Rails 项目之最佳实践 2、A Refactor Session for Re-education in ThoughtWorks 3、Put chubby models on a diet with concerns 4、7 Patterns to Refactor Fat ActiveRecord Models

Padrino 最新的版本是不是变化很大啊？

cisolarix — Fri, 05 Apr 2013 16:36:46 +0800

Padrino 最新发布的 0.11.0 的版本改动感觉好多啊。PageDown 往下翻了 2.5 屏之多。

详见： http://www.padrinorb.com/changes

看到彩程设计的 Tower 正式上线了。

cisolarix — Mon, 26 Nov 2012 13:34:21 +0800

赶紧注册了。还在熟悉当中。。。

PS：邮件通知服务好像用的是 mailgun 的。

jQuery v1.8.2 官方说 minified 的版本是 32kB，为啥我下载下来之后发现时 92kB 呢？

cisolarix — Mon, 15 Oct 2012 18:23:52 +0800

RT。暂时未截图，如果需要，可以补上。

请教一个 jQuery 从 twitter 抓取最近 5 条推文的诡异问题

cisolarix — Mon, 15 Oct 2012 12:15:43 +0800

昨天学习 http://book.douban.com/subject/10569608/ 这本书的第六章，章后最后一题要求用 jQuery 从 twitter 上抓取最近的 5 条推文，并显示在 div#dictionary 区域。我一开始用的是 getJSON 方法。代码如下： $(function(){ var url = "https://api.twitter.com/1/statuses/user_timeline.json? screen_name=cisolarix&count=5"; $.getJSON(url + "?callback=?", function(data){ var html = ''; $.each(data, function(idx, value){ html += '

' + value.text +''; html += '' + value.created_at + ''; }); $('#dictionary').html(html); }).error(function(){ console.log('error'); }); });

但是始终在控制台打印 error 信息。在 chrome 的 developer tool --> network 中能看到请求的回复 status 是 200. 直接将请求 url 复制到 chrome 中也是可以正常得到 json 数据的，只是推文条数为 3 条（初步怀疑是 twitter 做了限制）。

上面的方法测试未果后，用 $.ajax() 方法测试，代码如下: $(function(){ $.ajax('https://api.twitter.com/1/statuses/user_timeline.json', { crossDomain: true, data: { screen_name: 'cisolarix', count: 5 }, dataType: 'jsonp' }).done(function (tweets) { var html = ''; $.each(tweets, function(idx, value){ html += '

' + value.text +''; html += '' + value.created_at + ''; }); $('#dictionary').html(html); }); });

这次就可以正常显示推文了，尽管还是三条。我想请教的是，为啥 getJSON 方法在这种情境下不能得到 json 数据？提前谢谢各位。

PS：我使用的 jQuery 版本为：v1.6.2 PS again: 上面的代码段不知道如何跟正文区别显示。

Progmatic 的 Ruby 教程团购集结号

cisolarix — Thu, 13 Sep 2012 09:38:07 +0800

团购Progmatic 的 Ruby 教程的想法来自与这个帖子的讨论。

但是鉴于 199 刀的价格对于我们天朝小民有点小贵。所以希望大家一起团购，共同学习，共同进步。

@ted 已经表示愿意参加团购

昨天买了 codeschool 一个月的课程

cisolarix — Fri, 07 Sep 2012 19:53:36 +0800

RT，第一个月是 20 刀，据说以后每个月是 25 刀。主要有练习，这个挺吸引我的。

cisolarix (cisolarix)

请教 ?z 中的问号运算符的用法

Rails 中用 RabbitMQ 做消息队列 [译]

消息传递是解决之道

RabbitMQ 是什么

安装 RabbitMQ

简单的架构：博客的仪表板

博文发布者

仪表板消费者

设置 Redis

设置 Sneakers

最近博文服务

仪表板视图

工人

全部联系到一起

复杂架构

缓存存储

最近博文

页面访问统计

带过滤与排序的结构化缓存

Exchange ↔ Queue 绑定

结语

求助，有没有方法快速递格式化以下代码?

Action mailer 的 reply-to 是不是有问题？

订阅了 users 页面几乎所有的 RSS feed

Nitrous 在维护中？

thoughtbot 的按月付费好贵啊

这么好的重构文章不转怎么行？记 tower.im 的一次重构

Padrino 最新的版本是不是变化很大啊？

看到彩程设计的 Tower 正式上线了。

jQuery v1.8.2 官方说 minified 的版本是 32kB，为啥我下载下来之后发现时 92kB 呢？

请教一个 jQuery 从 twitter 抓取最近 5 条推文的诡异问题

Progmatic 的 Ruby 教程团购集结号

昨天买了 codeschool 一个月的课程

cisolarix (cisolarix)

请教 ?z 中的问号运算符的用法

Rails 中用 RabbitMQ 做消息队列 [译]

消息传递是解决之道

RabbitMQ 是什么

安装 RabbitMQ

简单的架构：博客的仪表板

博文发布者

仪表板消费者

设置 Redis

设置 Sneakers

最近博文服务

仪表板视图

工人

全部联系到一起

复杂架构

缓存存储

最近博文

页面访问统计

带过滤与排序的结构化缓存

Exchange ↔ Queue 绑定

结语

求助，有没有方法快速递格式化以下代码?

Action mailer 的 reply-to 是不是有问题？

订阅了 users 页面几乎所有的 RSS feed

Nitrous 在维护中？

thoughtbot 的按月付费好贵啊

这么好的重构文章不转怎么行？ 记 tower.im 的一次重构

Padrino 最新的版本是不是变化很大啊？

看到彩程设计的 Tower 正式上线了。

jQuery v1.8.2 官方说 minified 的版本是 32kB，为啥我下载下来之后发现时 92kB 呢？

请教一个 jQuery 从 twitter 抓取最近 5 条推文的诡异问题

Progmatic 的 Ruby 教程团购集结号

昨天买了 codeschool 一个月的课程

这么好的重构文章不转怎么行？记 tower.im 的一次重构