darkbaby123 (陈璋)

[武汉] 巧议网络 - Elixir 后端工程师（长期招聘）

darkbaby123 — Fri, 10 Sep 2021 11:08:56 +0800

公司介绍

Choiceform 是领先的用户体验管理平台，集成专业的在线问卷设计与发布，数据收集与清洗，统计分析，数据可视化，报告生成与分享等专业功能，帮助企业赋能用户体验管理，驱动商业决策。

官网 https://www.choiceform.com 产品首页 https://dashboard.choiceform.com/login

团队介绍

我们是一个扁平的技术团队，使用 Elixir（一种基于 Erlang 的编程语言）开发后端服务有 5 年左右。我们的产品巧思 choiceform 是一个问卷平台，专注于企业级的数据收集和分析功能。目前我们需要更多的工程师加入，一起打造 BI 数据分析平台，有 Elixir/Erlang/Ruby 经验更好，没有也没关系。希望你是一个有热情，对代码有追求且务实的工程师。

目前我们刚在武汉成立新公司，开发团队正在建立中，欢迎热爱 Elixir 的同学联系。

公司地址

武汉市硚口区解放大道 626 号 K11-ATELIER-1602 室。二号线中山公园地铁站附近

职位和待遇

初中高都有，10-25K * 13 薪，有能力者可谈
五险一金
国家法定节假日，加班少

工作职责

参与并负责问卷系统的开发，维护，优化等工作
跟数据分析员沟通，站在产品层面思考解决方案

任职要求

熟悉任意后端开发语言 (Erlang/Ruby/Python/Go 更好) 和 web 框架，并愿意学习 Elixir 编程语言
具备软件设计和架构能力
常见的数据结构和算法知识
良好的编码风格，熟悉 TDD，持续集成等软件开发实践
具备一定的英语读写能力，平时倾向于阅读英文的技术文章
有数据分析领域的经历者优先，有 R 经验者优先

加分项

有 GitHub，Stackoverflow 有贡献，或对开源社区有贡献者优先
了解一门函数式编程语言经验者优先

联系方式

邮箱：david.chen@choiceform.com
微信：darkbaby123

[上海] 巧议网络科技有限公司招聘 Elixir 后端工程师 (25-45k)

darkbaby123 — Wed, 03 Mar 2021 14:44:30 +0800

公司介绍

官网 https://www.choiceform.com
产品首页 https://dashboard.choiceform.com/login

关于团队

我们是一个扁平的技术团队。采用前后端分离的方式开发产品。目前团队在扩张阶段，我们希望寻找一些合适的小伙伴来一起把产品做得更好。工作经验没太多要求，但希望你是一个对代码有追求且务实的工程师，并且热爱 Elixir。

我们同样招聘前端工程师，可直接联系 @nightire 或投递简历（邮箱见下）

要求

工作职责：

设计和开发问卷的数据分析和报告系统。
优化现有服务，定位系统瓶颈，提高性能和稳定性。

任职要求：

1 年以上后端开发经验，语言不限。能站在产品角度设计后端 API。
良好的编码风格，有写测试的习惯。
热爱 Elixir 语言和函数式编程。基本的数据结构和算法知识。
良好的英语阅读能力。
熟悉至少一种关系型数据库，我们使用 PostgreSQL，有其他非关系型数据库经验更好。

待遇

25-45k，13 薪，资深者可谈。
五险一金。
国家法定节假日，加班少。

公司地址

上海市黄浦区上海 K11 购物艺术中心 2811

联系方式

后端：david.chen@choiceform.com
前端：albert.yu@choiceform.com

或者直接加我微信 darkbaby123。

用 PostgreSQL 的 COPY 导入导出 CSV

darkbaby123 — Mon, 13 Feb 2017 00:15:00 +0800

TL;DR

原文来自我的博客。

无意中看到了一篇讲数据批量导入的文章，才注意到 PostgreSQL 的 COPY 命令。简而言之，它用来在文件和数据库之间复制数据，效率非常高，并且支持 CSV。

导出 CSV

以前做类似的事情都是用程序语言写，比如用程序读取数据库的数据，然后用 CSV 模块写入文件，当数据量大的时候还要控制不要一次读太多，比如一次读 5000 条，处理完再读 5000 条之类。

PostgreSQL 的 COPY TO 直接可以干这个事情，而且导出速度是非常快的。下面例子是把 products 表导出成 CSV：

COPY products
TO '/path/to/output.csv'
WITH csv;

可以导出指定的属性：

COPY products (name, price)
TO '/path/to/output.csv'
WITH csv;

也可以配合查询语句，比如最常见的 SELECT ：

COPY (
  SELECT name, category_name
  FROM products
  LEFT JOIN categories ON categories.id = products.category_id
)
TO '/path/to/output.csv'
WITH csv;

导入 CSV

跟上面的导出差不多，只是把 TO 换成 FROM ，举例：

COPY products
FROM '/path/to/input.csv'
WITH csv;

这个命令做导入是非常高效的，在开头那篇博客作者的测试中，COPY 只花了 INSERT 方案 1/3 的时间，而后者还用 prepare statement 优化过。

总结

COPY 还有一些其他配置，比如把输入输出源指定成 STDIN/STDOUT 和 shell 命令，或者指定 CSV 的 header 等等。这里不再赘述。数据库也有很多细节可挖，有些简单却非常实用。合理使用能大大提高效率。

参考资料

Friends Don’t Let Friends Use Loops

PostgreSQL: COPY

JavaScript ASI 机制详解

darkbaby123 — Sun, 06 Mar 2016 12:31:42 +0800

TL;DR

原文放在 SegmentFault

最近在清理 Pocket 的未读列表，看到了 An Open Letter to JavaScript Leaders Regarding Semicolons 才知道了 JavaScript 的 ASI，一种自动插入分号的机制。因为我是“省略分号风格”的支持者，之前也碰到过一次因为忽略分号产生的问题，所以对此比较重视，也特意多看了几份文档，但越看心里越模糊。并不是我记不住 ( 和 [ 前面记得加 ;” 这种结论，而是觉得看过的几篇文章跟 ECMAScript 标准描述的有点区别。直到最近反复琢磨才突然有了“原来如此”的想法，于是就有了此文。

这篇文章会用 ECMAScript 标准的 ASI 定义来解释它到底是如何运作的，我会尽量用平易近人的方法描述它，避免官方文档的晦涩。希望你跟我一样有收获。掌握 ASI 并不能够让你马上解决手头的问题，但能让你成为一个更好的 JavaScript 程序员。

什么是 ASI

按照 ECMAScript 标准，一些 特定语句（statement) 必须以分号结尾。分号代表这段语句的终止。但是有时候为了方便，这些分号是有可以省略的。这种情况下解释器会自己判断语句该在哪里终止。这种行为被叫做“自动插入分号”，简称 ASI (Automatic Semicolon Insertion) 。实际上分号并没有真的被插入，这只是个便于解释的形象说法。

这些特定的语句有：

空语句
let
const
import
export
变量赋值
表达式
debugger
continue
break
return
throw

下面这段是我 个人的理解，上面的定义同时也表示：

所有这些语句中的分号都是可以省略的。
除此之外其他的语句有两种情况，一是不需要分号的（比如 if 和函数定义），二是分号不能省略的（比如 for），稍后会详细介绍。

那么 ASI 如何知道在哪里插入分号呢？它会按照一些规则去判断。但在说规则之前，我们先了解一下 JS 是如何解析代码的。

Token

解析器在解析代码时，会把代码分成很多 token。一个 token 相当于一小段有特定意义的语法片段。看一个例子你就会明白：

var a = 12;

上面这段代码可以分成四个 token：

var 关键字
a 标识符
= 运算符
12 数字

除此之外，(，. 等都算 token，这里只是让你有个大概的概念，比如 12 整个是一个 token，而不是 1 和 2。字符串同理。

解释器在解析语句时会一个一个读入 token 尝试构成一个完整的语句 (statement)，直到碰到特定情况（比如语法规定的终止）才会认为这个语句结束了。记得上文提到的 变量赋值 这个语句必须以分号结尾么？这个例子中的终止符就是分号。用 token 构成语句的过程类似于正则里的贪婪匹配，解释器总是试图用尽可能多的 token 构成语句。

接下来是重点：任意 token 之间都可以插入一个或多个换行符 (Line Terminator) ，这完全不影响 JS 的解析，所以上面的代码可以写成下面这样（功能等价）：

var
a
=
// = 和 12 之间有两个换行符
12
;

这个特性可以让开发者通过增加代码的可读性，更灵活地组织语言风格。我们平时写的跨多行的数组，字符串拼接，和链式调用都属于这一类。不过在省略分号的风格中，这种解析特性会导致一些意外情况。

比如这个例子中，以 / 开头的正则会被理解成除法：

var a
  , b = 12
  , hi = 2
  , g = {exec: function() { return 3 }}

a = b
/hi/g.exec('hi')

console.log(a)
// 打印出 2, 因为代码会被解析成：
//   a = b / hi / g.exec('hi');
//   a = 12 / 2 / 3

事实上这并不是省略分号的风格的错误，而是开发者没有理解 JS 解释器的工作原理。如果你倾向省略分号的风格，那了解 ASI 是必修课。

ASI 规则

ECMAScript 标准定义的 ASI 包括 三条规则 和 两条例外。

三条规则是描述何时该自动插入分号：

解析器从左往右解析代码（读入 token），当碰到一个不能构成合法语句的 token 时，它会在以下几种情况中在该 token 之前插入分号，此时这个不合群的 token 被称为 offending token：
- 如果这个 token 跟上一个 token 之间有至少一个换行。
- 如果这个 token 是 }。
- 如果 前一个 token 是 )，它会试图把前面的 token 理解成 do...while 语句并插入分号。
当解析到文件末尾发现语法还是有问题，就会在文件末尾插入分号。
当解析时碰到 restricted production 的语法（比如 return），并且在 restricted production 规定的 [no LineTerminator here] 的地方发现换行，那么换行的地方就会被插入分号。

两条例外表示，就算符合上述规则，如果分号会被解析成下面的样子，它也不能被自动插入：

分号不能被解析成空语句。
分号不能被解析成 for 语句头部的两个分号之一。

你会发现这些规则相当晦涩，好像存心考你智商的，还有些坑爹的专有名词。不要紧，我们来看几个非常简单的例子，看完之后你就会明白所有这些东西的含义。

例子解析

第一个例子：换行

a
b

我们模拟一下解析器的思考过程，大概是这样的：解析器一个个读取 token，但读到第二个 token b 时它就发现没法构成合法的语句，然后它发现 b 和前面是有换行的，于是按照规则一（情况一），它在 b 之前插入分号变成 a\n;b，这样语句就合法了。然后继续处理，这时读到文件末了，b 还是不能构成合法的语句，这时候按照规则二，它在末尾插入分号，结束。最终结果是：

a
;b;

第二个例子：大括号

{ a } b

解析器仍然一个个读取 token，读到 token } 时发现 { a } 是不合法的，因为 a 是表达式，它必须以分号结尾。但当前 token 是 }，所以按照规则一（情况二），它在 } 前面插入分号变成 { a ;}，这句就通过了，然后继续处理，按照规则二给 b 加上分号，结束。最终结果是：

{ a ;} b;

顺带一提，也许有人会觉得 { a; }; 这样才更自然。但 {...} 属于块语句，而按照定义块语句是不需要分号结尾的，不管是不是在一行。因为块语句也被用在其他地方（比如函数定义），所以下面这种代码也是完全合法的，不需要任何分号：

function a() {} function b() {}

第三个例子：do while

这个是为了解释规则一（情况三），这是最绕的部分，代码如下：

do a; while(b) c

这个例子中解析到 token c 的时候就不对了。这里面既没有换行也没有 }，但 c 前面是 )，所以解析器把之前的 token 组成一个语句，并判断该语句是不是 do...while，结果正好是的！于是插入分号变成 do a; while(b) ;，最后给 c 加上分号，结束。最终结果为：

do a; while (b) ; c;

简单点说，do...while 后面的分号是会自动插入的。但如果其他以 ) 结尾的情况就不行了。规则一（情况三）就是为 do...while 量身定做的。

第四个例子：return

return
a

你一定知道 return 和返回值之间不能换行，因为上面代码会解析成：

return;
a;

但为什么不能换行？因为 return 语句就是一个 restricted production。这是什么意思？它是一组有严格限定的语法的统称，这些语法都是在某个地方不能换行的，不能换行的地方会被标注 [no LineTerminator here]。

比如 ECMAScript 的 return 语法定义如下：

return [no LineTerminator here] Expression ;

这表示 return 跟表达式之间是不允许换行的（但后面的表达式内部可以换行）。如果这个地方恰好有换行，ASI 就会自动插入分号，这就是规则三的含义。

刚才我们说了 restricted production 是一组语法的统称，它一共包含下面几个语法：

后缀的 ++ 和 --
return
continue
break
throw
ES6 箭头函数（参数和箭头之间不能换行）
yield

这些不用死记，因为按照常规书写习惯，几乎没人会这样换行的。顺带一提，continue 和 break 后面是可以接 label 的。但这不在本文讨论范围内，有兴趣可以自己探索。

第五个例子：后缀表达式

a
++
b

解析器读到 token ++ 时发现语句不合法，因为后缀表达式是不允许换行的，换句话说，换行的都不是后缀表达式。所以它只能按照规则一（情况一）在 ++ 前面加上分号来结束语句 a，然后继续执行，因为前缀表达式并不是 restricted production，所以 ++ 和 b 可以组成一条语句，然后按照规则二在末尾加上分号。最终结果为：

a
;++
b;

第六个例子：空语句

if (a)
else b

解释器解析到 token else 时发现不合法，本来按照规则一（情况一），它在应该加上分号变成 if (a)\n;，但这样 ; 就变成空语句了，所以按照例外一，这个分号不能加。程序在 else 处抛异常结束。Node.js 的运行结果：

else b
^^^^

SyntaxError: Unexpected token else

第七个例子：for

for (a; b
)

解析器读到 token ) 时发现不合法，本来换行可以自动插入分号，但按照例外二，不能为 for 头部自动插入分号，于是程序在 ) 处抛异常结束。Node.js 运行结果如下：

)
^

SyntaxError: Unexpected token )

如何手动测试 ASI

我们很难有办法去测试 ASI 是不是如预期那样工作的，只能看到代码最终执行结果是对是错。ASI 也没有手动打开或关掉去对比结果。但我们可以通过对比解析器生成的 tree 是否一致来判断 ASI 加的分号是不是跟我们预期的一致。这点可以用 Esprima 在线解析器完成。

拿这段代码举例子：

do a; while(b) c

Esprima 解析的 Syntax 如下所示（不需要看懂，记住大概样子就行）：

{
    "type": "Program",
    "body": [
        {
            "type": "DoWhileStatement",
            "body": {
                "type": "ExpressionStatement",
                "expression": {
                    "type": "Identifier",
                    "name": "a"
                }
            },
            "test": {
                "type": "Identifier",
                "name": "b"
            }
        },
        {
            "type": "ExpressionStatement",
            "expression": {
                "type": "Identifier",
                "name": "c"
            }
        }
    ],
    "sourceType": "script"
}

然后我们把加上分号的版本输入进去：

do a; while(b); c;

你会发现生成的 Syntax 是一致的。这说明解释器对这两段代码解析过程是一致的，我们并没有加入任何多余的分号。

然后试试这个有多余分号的版本：

do a; while(b); c;; // 结尾多一个分号

Esprima 结果：

{
    "type": "Program",
    "body": [
        {
            "type": "DoWhileStatement",
            "body": {
                "type": "ExpressionStatement",
                "expression": {
                    "type": "Identifier",
                    "name": "a"
                }
            },
            "test": {
                "type": "Identifier",
                "name": "b"
            }
        },
        {
            "type": "ExpressionStatement",
            "expression": {
                "type": "Identifier",
                "name": "c"
            }
        },
        {
            // 多出来一个空语句
            "type": "EmptyStatement"
        }
    ],
    "sourceType": "script"
}

你会发现多出来一条空语句，那么这个分号就是多余的。

结尾

如果看到这里，相信你对 ASI 和 JS 的解析机制已经有所了解。也许你会想“那我再也不省略分号了”，那我建议你看看参考资料里的链接。而且就我的经验，即使是分号的坚持者，少数地方也会无意识地使用 ASI。比如有时候忘了写分号，或者写迭代器中的单行函数时。下次我会说下对省略分号的风格的看法，和如何用 ESLint 保证代码风格的一致性。

参考资料

ECMAScript: ASI ECMAScript 标准定义。本文的概念和很多例子完全遵照它来写的。但也强烈建议你自己看看。

JavaScript Semicolon Insertion Everything you need to know 关于 ASI 的解释，略微学术化，讲得很详细，也很客观。

An Open Letter to JavaScript Leaders Regarding Semicolons NPM 作者对 ASI 和两种风格的看法，这篇更注重个人观点的表达。他是省略分号风格的倾向者。

Esprima: Parser 一个在线 JS 解析器。你可以输入一些语句来看看 token 都是什么。也可以通过 Tree 的变化来测试加不加分号的影响。

Phoenix render 迷思

darkbaby123 — Mon, 28 Dec 2015 11:36:08 +0800

前言

原文放在 SegmentFault 。

最近在学习用 Elixir 的 MVC 框架 Phoenix 写一个 Chatroom。有一个问题是在 channel 中渲染模板，虽然我用 Phoenix.View.render 方法顺利解决了。但这让我开始思考另外几个问题：

Phoenix 中有哪些 render 方法？
它们分别是干什么用的？
它们有内部联系吗？

render 的使用场景

在研究有哪些 render 方法之前，我们先看看 Phoenix 的几个使用 render 的场景。

在 controller 中使用 render ：

def foo(conn, _params) do
  render conn, "foo.html"
end

在 template 中使用 render ：

<!-- 渲染同一视图中的另一个模板 -->
<%= render "foo.html" %>
<%= render "foo.html", some_model: some_model %>

<!-- 渲染另外一个视图中的模板 -->
<%= render YourApp.OtherView, "bar.html" %>
<%= render YourApp.OtherView, "bar.html", some_model: some_model %>

在其他地方使用 render ，多用于 channel 或者 iex 调试：

Phoenix.View.render(YourApp.CustomView, "foo.html")

除了最后一个例子可以清楚地看到 render 方法来自 Phoenix.View 模块之外，其他几个地方的 render 都不知道出处。这些 render 来自哪里？

如果查一下 Phoenix 的文档，可以发现两个模块定义了 render 方法，它们是 Phoenix.Controller 和 Phoenix.View ，我们可以猜测前者为所有 controller 提供 render ，后者为所有 view 和 template 提供 render 。不过这还需要验证一下。

controller 的 render

先看看 controller，Phoenix 的 controller 定义非常简单：

defmodule YourApp.SomeController do
  use YourApp.Web, :controller
end

显然一个空的模块是没有实现 render 方法的，那关键就在 YourApp.Web 里。其实这个模块就在项目的 web/web.ex 文件里。大概像下面这样：

defmodule YourApp.Web do
  # def model ...

  def controller do
    quote do
      use Phoenix.Controller

      alias YourApp.Repo
      import Ecto
      import Ecto.Query, only: [from: 1, from: 2]

      import YourApp.Router.Helpers
      import YourApp.Gettext
    end
  end

  # def view ...
end

YourApp.Web 模块的职责是为其他模块加入一些通用的功能，基本上就是执行一些 alias, import, use。 controller 中的 use 那一行代码会调用 YourApp.Web 的 controller 方法，这里我们看到执行了 use Phoenix.Controller 。

先大致解释一下 use 。它是一个 Elixir 的 macro，一般用来为模块附加额外的特性。当模块 A use 模块 B 时，B 的 __using__ 回调会被调用，我们可以在里面写代码为模块 A 附加一些东西。

Phoenix.Controller 的 __using__ 大概如下所示，看不懂语法和 API 不要紧，明白意思就行：

defmacro __using__(opts) do
  quote bind_quoted: [opts: opts] do
    import Phoenix.Controller
    # ...
  end
end

这里我们可以看到 import Phoenix.Controller ，结合开头 controller 中的 use YourApp.Web, :controller ，其实 Phoenix.Controller 用这种形式被 import 到了所有 controller 中，这意味着 Phoenix.Controller 的所有公有方法都可以在 controller 内部使用，其中也包括 render 方法。注意这是 内部使用 ，像 YourApp.SomeController.render 这种调用是不可行的。

template 的 render

在 template 中调用 <%= render %> 应该属于哪个模块的呢？要回答这个问题，我们得先了解下 view 和 template 的关系。

Phoenix 的视图层分为两个部分：view 和 template，view 是一个 Elixir 模块，template 是一个 EEx 模板文件。一个 view 管理多个 template。举个例子，一个 YourApp.RoomView 下面可以定义 index.html ， show.html 等几个不同 template。要渲染 show.html ，我们可以用 Phoenix.View.render(YourApp.RoomView, "show.html") 。

template 本质上是一个函数，接收动态数据作为参数，组合静态内容并返回结果。对服务器端渲染而言，结果大多是一个字符串。我们经常使用的模板文件，实际上只是把静态内容存放在文件系统里而已。Phoenix 在编译期间会把 template 编译成函数放在 view 中。模板渲染最终会调用 view 中相应的函数。因此在 template 里调用的方法全都来自于 view。template 里的 <%= render %> 等于调用相对应的 view 的 render 方法。

一个典型的 view 定义如下：

defmodule YourApp.RoomView do
  use YourApp.Web, :view
end

跟 controller 非常类似的代码。具体源码追溯过程我就不写了，通过同样追溯方法我们最终可以在 Phoenix.View 的 __using__ 中看到同样的 import ，如下所示：

defmacro __using__(options) do
  # ...
  quote do
    import Phoenix.View
    use Phoenix.Template, root: ...
  end
end

看来 view 中的 render 方法应该来自于 Phoenix.View 。不过先别下结论，我们来对比一下方法签名。Phoenix.View.render 的方法签名是 render(module, template, assigns) ，注意其中有 三个参数，并且都是不能省略的 。

再回顾一下 template 中的 render ：

<!-- 渲染同一视图中的另一个模板 -->
<%= render "foo.html" %>
<%= render "foo.html", some_model: some_model %>

<!-- 渲染另外一个视图中的模板 -->
<%= render YourApp.OtherView, "bar.html" %>
<%= render YourApp.OtherView, "bar.html", some_model: some_model %>

可见这个 render 可以接受 一个到三个参数 。这跟 Phoenix.View 的 render 明显不一样。这是怎么回事？

答案在 Phoenix.Template 中。回顾一下上面的代码，Phoenix.View 的 __using__ 中还有一行 use Phoenix.Template ，让我们看看 Phoenix.Template 的 __using__ ：

defmacro __using__(options) do
  quote do
    @doc """
    Renders the given template locally.
    """
    def render(template, assigns \\ ${})

    def render(template, assigns) when is_list(assigns) do
      render(template, Enum.into(assigns, %{}))
    end

    def render(module, template) when is_atom(module) do
      Phoenix.View.render(module, template, %{})
    end

    # ...
  end
end

它居然为 view 定义了 render 方法！这下事情明白了，当我们在 template 中使用 render 时，如果传入一个或两个参数，其实我们调用的是 Phoenix.Template 为 view 生成的 render 方法；如果传入三个参数，则是调用 Phoenix.View 中的 render 方法。因为这个 render 方法是在 __using__ 中定义的，所以 Phoenix 文档是查不到的。

注：Elixir 允许为一个方法定义不同的变种，这些方法并不会互相覆盖。当方法被调用时 Elixir 会通过 pattern match 和 guard 自动去寻找最匹配的方法执行，合理利用可以省不少 if/else 。

有一点值得提醒，跟 Phoenix.View 的 import 不同，Phoenix.Template 是为 view 动态地定义方法（其实是编译期做的），而且这个方法是公有的。这意味着我们可以在其他模块里调用 YourApp.SomeView.render 去渲染 template。

view 的 render

这里想说的有两种，一是在 view 中调用 render ，二是在其他模块中调用 Phoenix.View.render 。

在 view 里面，Phoenix.View 的所有公有方法都可以使用。Phoenix.Template 给了 view 三个 render 方法，但没有把它自己 import 进去，所以它的方法是不能在 view 里直接用的。不过大部分情况下 Phoenix.View 提供的方法已经足够了。

在其他模块中，如果要渲染某个 template，我们其实有两种办法，它们是等价的：

Phoenix.View.render(YourApp.SomeView, "some_template.html")
YourApp.SomeView.render("some_template.html")

虽然第二种方式更简洁，但第一种方式，也就是 Phoenix.View.render 比较推荐，因为它可以设置 layout，而且也算是 view 渲染的标准入口函数。比如 Phoenix.Controller 的 render 内部调用的就是它，而且 Phoenix.View 的其他几个方法比如 render_to_iodata ，render_to_string 调用的也是它。源码追溯过程我就不放上来了，有兴趣的可以自己挖掘。

另外 Phoenix.View.render 渲染某个 view 的 template 的时候，它会在内部调用 view 的 render 方法（Phoenix.Template 提供的方法）。

小结

现在我们可以回答开篇的几个问题作为总结：

Phoenix 中有哪些 `render` 方法？

Phoenix 文档中可以查到两个 render 方法，但实际上有三个 render 方法，前两个在 Phoenix.Controller 和 Phoenix.View 中定义并被 import 到相应的模块中使用，第三个在 Phoenix.Template 的 __using__ 中被定义，并在编译时附加给 view。

它们分别是干什么用的？

Phoenix.Controller.render 在 controller 中使用，它关注的是内容协商，即根据客户端的要求来决定渲染类型（HTML/JSON/XML 等）。具体渲染细节会代理给 Phoenix.View.render 去处理。

Phoenix.View.render 可以算是通用的 view 渲染入口，既用在 view 和 template 中，也被其他需要渲染 view 的模块调用。比如 controller。它处理视图层的渲染细节。

Phoenix.Template 提供的 render 是作为 view 的 render 方法的补充，让 view 的 render 方法变得更灵活多变。

它们有内部联系吗？

Phoenix.Controller.render 内部会调用 Phoenix.View.render，Phoenix.View.render 内部会调用传入的 view 模块的 render 方法，而这个方法是 Phoenix.Template 为每个 view 生成的。

参考资料

Phoenix.Controller.render Phoenix.View.render Phoenix.Template Phoenix Guide: Views Content negotiation

这是我见过的最黑的事情……

darkbaby123 — Thu, 26 Nov 2015 10:02:03 +0800

事情的起因是 Dash 支持 Hex Docsets 了，我就去下了 Phoenix 和 Ecto 的文档，然后看到了有个包叫 Rails …… 文档里面写着：

A plug to make your Elixir/Phoenix applications performance more in line with Rails.

源码……

defmodule Rails do
  import Plug.Conn

  def init(options) do
    options
  end

  def call(conn, _opts) do
    rails_penalty = 500..1200 |> Enum.shuffle |> Enum.at(0)
    :timer.sleep(rails_penalty)
    conn
  end
end

BTW 这个包的版本号是 4.2 ……

怎么用：

plug Rails   # 如果嫌快了还可以多加几行

看来 Rails 的性能快跟 Emacs 的脚踏板一样变成群众喜闻乐见的标志性槽点了

Virtus 作者决定放弃项目了

darkbaby123 — Mon, 23 Nov 2015 09:57:09 +0800

原文 Virtus to be abandoned by its creator?

作者放弃该项目了，Virtus 还会继续维护，不过估计不会加功能了。目前处于找新的 maintainer 还没找到的情况。

另外大家对 Data mapper 模式怎么看？我了解过的 Lotus，ROM 和 Ecto 都采用这种方式（虽然细节处理各有不同）。不过感觉处理得最优雅的还是 Ecto，各个部件组合得足够灵活也不用写太多的额外代码。

更简单灵活地管理 Ruby 版本

darkbaby123 — Thu, 05 Nov 2015 23:44:56 +0800

原文贴在 SegmentFault ，有兴趣的可以过去瞄哈。

概述

这篇文章教你怎么用 ruby-install 和 chruby 这两个工具来管理和切换 Ruby 版本，相对 RVM 和 rbenv 来说这是一个更加轻量级且绿色环保的组合。

为什么不用 RVM 或者 rbenv

首先说明一点，切换 ruby-install 和 chruby 并不是因为它们有什么独一无二的特性。它们能做到的事情 RVM 和 rbenv 都可以做到。如果你用着现有的工具感觉良好，也没有尝鲜的打算，完全可以不换。

那我为什么要换？对我而言有几个原因：

我想用一个 Homebrew 可以管理和升级的工具。
最好是工具不升级也可以安装最新的 Ruby 版本。
功能和实现都很简单。因为我只需要安装和切换不同的 Ruby 版本，不需要其他的功能。

关于最后一点我想多说几句，最近一年我对软件的看法有些改变。对我而言好的软件最重要的是 简单够用 。我不想为用不到的功能买单，它们可能增加潜在的复杂度和维护成本。我也不喜欢软件为了达到功能做了太多 hack，这会影响它跟其他软件组合使用的轻松程度，进而影响未来替换它的轻松程度。我以前一直在用 RVM，这次本来准备换成 rbenv，但当我看了 rbenv 对 shim 的大堆解释后觉得这不是我想要的理想替代品。正好前几天同事推荐 chruby，@Hooopo 的这篇文章也让我觉得这应该是个不错的玩意（希望没拼错那几个 o），于是就果断删了 RVM 切换过去了。过程比我想得还要轻松许多。

使用 ruby-install & chruby

这其实是两个工具，ruby-install 只负责下载、编译和安装多个 Ruby 版本，chruby 负责切换。它们的名字就是命令行的名字，所以你需要用到两个命令（但都非常简单）。你可以点它们的名字去 Github 看 README.md。下面我只提供基本用法的例子（用的 Homebrew）：

安装 ruby-install

brew install ruby-install

安装指定 Ruby 版本

ruby-install ruby 2.2.3

安装 chruby

brew install chruby

切换 Ruby 版本

chruby ruby-2.2.3

然后在 .bashrc 或者 .bash_profile 里加入脚本（具体路径最好照官方说明来）。第一个脚本加载 chruby，第二个脚本控制自动切换（按 .ruby-version 文件）。

source /usr/local/opt/chruby/share/chruby/chruby.sh
source /usr/local/opt/chruby/share/chruby/auto.sh

关于默认 Ruby 版本，chruby 没有这种命令，但我们需要的只是“在适当的时候让 chruby 自动切换到指定版本” 。chruby 会从当前目录向上一层层地找 .ruby-version 文件，所以你只要把默认 Ruby 版本写在 ~/.ruby-version 里就可以了，以此类推，如果需要在任何目录下都能切换到默认版本，你可以考虑 /.ruby-version，我没这个需求，就没有尝试。

在命令提示符里显示 Ruby 版本

这几乎是 Ruby 开发的“刚需”了。我是自己写了个简单的脚本做到这点的。原理很简单，用 ruby --version 显示当前使用的版本，截取版本号再插入提示符就行了（修改 PS1 变量）。以我的 bash 举例子：

# 如果当前目录有 Gemfile 就显示 Ruby 版本；如果有 package.json 就显示 Node.js 版本，否则什么都不显示。
# 结果大概会显示成 ruby@2.2.3 或者 node@5.0.0
function env_version {
  if [ -e ./Gemfile ]; then
    # ruby 2.2.2p95 (2015-04-13..) -> 2.2.2p95 -> 2.2.2
    echo "ruby@$(ruby --version | awk '{print $2}' | awk -F'p' '{print $1}') ";
  elif [ -e ./package.json ]; then
    # v4.2.1 -> 4.2.1
    echo "node@$(node -v | awk -F'v' '{print $2}') ";
  else
    echo "";
  fi
}

# 用 $() 嵌入 env_version 的结果
PS1="$(env_version)"

我自己用的 PS1 变量显示了路径，Ruby/Node.js 版本，和 Git 分支名。感兴趣的可以参考我的 dotfile，最终效果大概如此：

~/workspace/my-project ruby@2.2.2 [staging] $

最后附带一点，如果不想频繁地敲 bundle exec xxx，可以看看文末链接的 Automating bundle exec 。这是一个简单的 alias 脚本。不过我在同事的 rbenv 环境上没试成功，不确定是不是受 rbenv 的 shim 影响。如果是的话，这也侧面证明了 less hack 的好处。

参考链接

Install Ruby The "Postmodern" Way Programmer's guide to choosing a Ruby version manager Automating bundle exec

JavaScript 原型系统的变迁，以及 ES6 class

darkbaby123 — Sun, 27 Sep 2015 17:39:19 +0800

概述

注：原文放在 SegmentFault 。如果你想看到更清晰的目录，可以去看原文。除此之外，本文不缺少任何内容。

JavaScript 的原型系统是最初就有的语言设计。但随着 ES 标准的进化和新特性的添加。它也一直在不停进化。这篇文章的目的就是梳理一下早期到 ES5 和现在 ES6，新特性的加入对原型系统的影响。

如果你对原型的理解还停留在 function + new 这个层面而不知道更深入的操作原型链的技巧，或者你想了解 ES6 class 的知识，相信本文会有所帮助。

这篇文章是我学习 You Don't Know JS 的副产品，推荐任何想系统性地学习 JavaScript 的人去阅读此书。

JavaScript 原型简述

很多人应该都对原型（prototype）不陌生。简单地说，JavaScript 是基于原型的语言。当我们调用一个对象的属性时，如果对象没有该属性，JavaScript 解释器就会从对象的原型对象上去找该属性，如果原型上也没有该属性，那就去找原型的原型。这种属性查找的方式被称为原型链（prototype chain）。

对象的原型是没有公开的属性名去访问的（下文再谈 __proto__ 属性）。以下为了方便称呼，我把一个对象内部对原型的引用称为 [[Prototype]]。

JavaScript 没有类的概念，原型链的设定就是少数能够让多个对象共享属性和方法，甚至模拟继承的方式。在 ES5 以前，如果我们想设置对象的 [[Prototype]]，只能通过 new 关键字，比如：

function User() {
  this._name = 'David'
}

User.prototype.getName = function() {
  return this._name
}

var user = new User()
user.getName()                  // "David"
user.hasOwnProperty('getName')  // false

当 User 函数被 new 关键字调用时，它就类似于一个构造函数，其生成的对象的 [[Prototype]] 会引用 User.prototype 。因为 User.prototype 也是一个对象，它的 [[Prototype]] 是 Object.prototype 。

一般我们对这种构造函数命名都会采用 CamelCase，并把它称呼为“类”，这不仅是为了跟 OOP 的理念保持一致，也是因为 JavaScript 的内建“类”也是这种命名。

由 SomeClass 生成的对象，其 [[Prototype]] 是 SomeClass.prototype。除了稍显繁琐，这套逻辑是可以自圆其说的，比如：

我们用 {..} 创建的对象的 [[Prototype]] 都是 Object.prototype，也是原型链的顶点。
数组的 [[Prototype]] 是 Array.prototype 。
字符串的 [[Prototype]] 是 String.prototype 。
Array.prototype 和 String.prototype 的 [[Prototype]] 是 Object.prototype 。

模拟继承

模拟继承是自定义原型链的典型使用场景。但如果用 new 的方式则比较麻烦。一种常见的解法是：子类的 prototype 等于父类的实例。这就涉及到定义子类的时候调用父类的构造函数。为了避免父类的构造函数在类定义过程中的潜在影响，我们一般会建造一个临时类去做代替父类 new 的过程。

function Parent() {}
function Child() {}

function createSubProto(proto) {
  // fn 在这里就是临时类
  var fn = function() {}
  fn.prototype = proto
  return new fn()
}

Child.prototype = createSubProto(Parent.prototype)
Child.prototype.constructor = Child

var child = new Child()
child instanceof Child   // true
child instanceof Parent  // true

ES5: 自由地操控原型链

既然原型链本质上只是建立对象之间的关联，那我们可不可以直接操作对象的 [[Prototype]] 呢？

在 ES5（准确的说是 5.1）之前，我们没有办法直接获取对象的原型，只能通过 [[Prototype]] 的 constructor。

var user = new User()
user.constructor.prototype          // User
user.hasOwnProperty('constructor')  // false

类可以通过 prototype 属性获取生成的对象的 [[Prototype]]。[[Prototype]] 里的 constructor 属性又会反过来引用函数本身。因为 user 的原型是 User.prototype ，它自然也能够通过 constructor 获取到 User 函数，进而获取到自己的 [[Prototype]]。比较绕是吧？

ES5.1 之后加了几个新的 API 帮助我们操作对象的 [[Prototype]]，自此以后 JavaScript 才真的有自由操控原型的能力。它们是：

Object.prototype.isPrototypeOf
Object.create
Object.getPrototypeOf
Object.setPrototypeOf

注：以上方法并不完全是 ES5.1 的，isPrototypeOf 是 ES3 就有的，setPrototypeOf 是 ES6 才有的。但它们的规范都在 ES6 中修改了一部分。

下面的例子里，Object.create 创建 child 对象，并把 [[Prototype]] 设置为 parent 对象。Object.getPrototypeOf 可以直接获取对象的 [[Prototype]]。isPrototypeOf 能够判断一个对象是否在另一个对象的原型链上。

var parent = {
  _name: 'David',
  getName: function() { return this._name },
}

var child = Object.create(parent)

Object.getPrototypeOf(child)           // parent
parent.isPrototypeOf(child)            // true
Object.prototype.isPrototypeOf(child)  // true
child instanceof Object                // true

既然有 Object.getPrototypeOf，自然也有 Object.setPrototypeOf 。这个函数可以修改任何对象的 [[Prototype]] ，包括内建类型。

var anotherParent = {
  name: 'Alex'
}

Object.setPrototypeOf(child, anotherParent)
Object.getPrototypeOf(child)  // anotherParent

// 修改数组的 [[Prototype]]
var a = []
Object.setPrototypeOf(a, anotherParent)
a instanceof Array        // false
Object.getPrototypeOf(a)  // anotherParent

灵活使用以上的几个方法，我们可以非常轻松地创建原型链，或者在已知原型链中插入自定义的对象，玩法只取决于想象力。我们以此修改一下上面的模拟继承的例子：

function Parent() {}
function Child() {}

Child.prototype = Object.create(Parent.prototype)
Child.prototype.constructor = Child

因为 Object.create(..) 传入的参数会作为 [[Prototype]] ，所以这里有一个有意思的小技巧。我们可以用 Object.create(null) 创建一个没有任何属性的对象。这个技巧适合做 proxy 对象，有点类似 Ruby 中的 BasicObject。

尴尬的私生子 proto

说到操作 [[Prototype]] 就不得不提 __proto__ 。这个属性是一个 getter/setter，可以用来获取和设置任意对象的 [[Prototype]] 。

child.__proto__           // equal to Object.getPrototypeOf(child)
child.__proto__ = parent  // equal to Object.setPrototypeOf(child, parent)

它本来不是 ES 的标准，无奈众多浏览器早早地都实现了这个属性，而且应用得还挺广泛的。到了 ES6 为了向下兼容性只好接纳它成为标准的一部分。这是典型的现实倒逼标准的例子。

看看 MDN 的描述都充满了怨念。

The use of proto is controversial, and has been discouraged. It was never originally included in the EcmaScript language spec, but modern browsers decided to implement it anyway. Only recently, the proto property has been standardized in the ECMAScript 6 language specification for web browsers to ensure compatibility, so will be supported into the future. It is deprecated in favor of Object.getPrototypeOf/Reflect.getPrototypeOf and Object.setPrototypeOf/Reflect.setPrototypeOf (though still, setting the [[Prototype]] of an object is a slow operation that should be avoided if performance is a concern).

__proto__ 是不被推荐的用法。大部分情况下我们仍然应该用 Object.getPrototypeOf 和 Object.setPrototypeOf 。什么是少数情况，待会再讲。

ES6: class 语法糖

不得不说开发者世界受 OO 的影响非常之深，虽然 ES5 给了我们足够灵活的 API，但是：

很多人还是倾向于用 class 来组织代码。
很多类库、框架创造了自己的 API 来实现 class 的功能。

产生这一现象的原因有很多，但事实如此。而且如果用别人的轮子，有些事是我们无法选择的。也许是看到了这一现象，ES6 时代终于有了 class 语法，有望统一各个类库和框架不一致的类实现方式。来看一个例子：

class User {
  constructor(firstName, lastName) {
    this.firstName = firstName
    this.lastName = lastName
  }

  fullName() {
    return `${this.firstName} ${this.lastName}`
  }
}

let user = new User('David', 'Chen')
user.fullName()  // David Chen

以上的类定义语法非常直观，它跟以下的 ES5 语法是一个意思：

function User(firstName, lastName) {
  this.firstName = firstName
  this.lastName = lastName
}

User.prototype.fullName = function() {
  return '' + this.firstName + this.lastName
}

ES6 并没有改变 JavaScript 基于原型的本质，只是在此之上提供了一些语法糖。class 就是其中之一。其他的还有 extends，super 和 static 。它们大多数都可以转换成等价的 ES5 语法。

我们来看看另一个继承的例子：

class Child extends Parent {
  constructor(firstName, lastName, age) {
    super(firstName, lastName)
    this.age = age
  }
}

其基本等价于：

function Child(firstName, lastName, age) {
  Parent.call(this, firstName, lastName)
  this.age = age
}

Child.prototype = Object.create(Parent.prototype)
Child.constructor = Child

无疑上面的例子更加直观，代码组织更加清晰。这也是加入新语法的目的。不过虽然新语法的本质还是基于原型的，但新加入的概念或多或少会引起一些连带的影响。

extends 继承内建类的能力

因为语言内部设计原因，我们没有办法自定义一个类来继承 JavaScript 的内建类的。继承类往往会有各种问题。ES6 的 extends 的最大的卖点，就是不仅可以继承自定义类，还可以继承 JavaScript 的内建类，比如这样：

class MyArray extends Array {
}

这种方式可以让开发者继承内建类的功能创造出符合自己想要的类。所有 Array 已有的属性和方法都会对继承类生效。这确实是个不错的诱惑，也是继承最大的吸引力。

但现实总是悲催的。extends 内建类会引发一些奇怪的问题，很多属性和方法没办法在继承类中正常工作。举个例子：

var a = new Array(1, 2, 3)
a.length  // 3

var b = new MyArray(1, 2, 3)
b.length  // 0

如果说语法糖可以用 Babel.js 这种 transpiler 去编译成 ES5 解决，扩充的 API 可以用 polyfill 解决，但是这种内建类的继承机制显然是需要浏览器支持的。而目前唯一支持这个特性的浏览器是………… Microsoft Edge。

好在这并不是什么致命的问题。大多数此类需求都可以用封装类去解决，无非是多写一点 wrapper API 而已。而且个人认为封装和组合反而是比继承更灵活的解决方案。

super 带来的新概念（坑？）

super 在 constructor 和普通方法里的不同

在 constructor 里面，super 的用法是 super(..)。它相当于一个函数，调用它等于调用父类的 constructor。但在普通方法里面，super 的用法是 super.prop 或者 super.method()。它相当于一个指向对象的 [[Prototype]] 的属性。这是 ES6 标准的规定。

class Parent {
  constructor(firstName, lastName) {
    this.firstName = firstName
    this.lastName = lastName
  }

  fullName() {
    return `${this.firstName} ${this.lastName}`
  }
}

class Child extends Parent {
  constructor(firstName, lastName, age) {
    super(firstName, lastName)
    this.age = age
  }

  fullName() {
    return `${super.fullName()} (${this.age})`
  }
}

注意：Babel.js 对方法里调用 super(..) 也能编译出正确的结果，但这应该是 Babel.js 的 bug，我们不该以此得出 super(..) 也可以在非 constructor 里用的结论。

super 在子类的 constructor 里必须先于 this 调用

如果写子类的 constructor 需要操作 this ，那么 super 必须先调用！这是 ES6 的规则。所以写子类的 constructor 时尽量把 super 写在第一行。

class Child extends Parent {
  constructor() {
    this.xxx()  // invalid
    super()
  }
}

super 是编译时确定，不是运行时确定

什么意思呢？先看代码：

class Child extends Parent {
  fullName() {
    super.fullName()
  }
}

以上代码中 fullName 方法的 ES5 等价代码是：

fullName() {
  Parent.prototype.fullName.call(this)
}

而不是

fullName() {
  Object.getPrototypeOf(this).fullName.call(this)
}

这就是 super 编译时确定的特性。不过为什么要这样设计？个人理解是，函数的 this 只有在运行时才能确定。因此在运行时根据 this 的原型链去获得上层方法并不太符合 class 的常规思维，在某些情况下更容易产生错误。比如 child.fullName.call(anotherObj) 。

super 对 static 的影响，和类的原型链

static 相当于类方法。因为编译时确定的特性，以下代码中：

class Child extends Parent {
  static findAll() {
    return super.findAll()
  }
}

findAll 的 ES5 等价代码是：

findAll() {
  return Parent.findAll()
}

static 貌似和原型链没关系，但这不妨碍我们讨论一个问题：类的原型链是怎样的？我没查到相关的资料，不过我们可以测试一下：

Object.getPrototypeOf(Child) === Parent             // true
Object.getPrototypeOf(Parent) === Object            // false
Object.getPrototypeOf(Parent) === Object.prototype  // false

proto = Object.getPrototypeOf(Parent)
typeof proto                             // function
proto.toString()                         // function () {}
proto === Object.getPrototypeOf(Object)  // true
proto === Object.getPrototypeOf(String)  // true

new proto()  //TypeError: function () {} is not a constructor

可见自定义类的话，子类的 [[Prototype]] 是父类，而所有顶层类的 [[Prototype]] 都是同一个函数对象，不管是内建类如 Object 还是自定义类如 Parent 。但这个函数是不能用 new 关键字初始化的。虽然这种设计没有 Ruby 的对象模型那么巧妙，不过也是能够自圆其说的。

直接定义 object 并设定 [[Prototype]]

除了通过 class 和 extends 的语法设定 [[Prototype]] 之外，现在定义对象也可以直接设定 [[Prototype]] 了。这就要用到 __proto__ 属性了。“定义对象并设置 [[Prototype]]”是唯一建议用 __proto__ 的地方。另外，另外注意 super 只有在 method() {} 这种语法下才能用。

let parent = {
  method1() { .. },
  method2() { .. },
}

let child = {
  __proto__: parent,

  // valid
  method1() {
    return super.method1()
  },

  // invalid
  method2: function() {
    return super.method2()
  },
}

总结

JavaScript 的原型是很有意思的设计，从某种程度上说它是更加纯粹的面向对象设计（而不是面向类的设计）。ES5 和 ES6 加入的 API 能更有效地操控原型链。语言层面支持的 class 也能让忠于类设计的开发者用更加统一的方式去设计类。虽然目前 class 仅仅提供了一些基本功能。但随着标准的进步，相信它还会扩充出更多的功能。

本文的主题是原型系统的变迁，所以并没有涉及 getter/setter 和 defineProperty 对原型链的影响。想系统地学习原型，你可以去看 You Don't Know JS: this & Object Prototypes 。

参考资料

You Don't Know JS: this & Object Prototypes You Don't Know JS: ES6 & Beyond Classes in ECMAScript 6 (final semantics) MDN: Object.prototype.proto

Service Object 整理和小结

darkbaby123 — Thu, 22 Jan 2015 17:57:32 +0800

TL;DR

这篇文章整理了 Service Object 的一套 Convention，用 PORO 结合 Rails 的功能完成了一个例子，并介绍了一些其他思路。

Why Service Object (Again)?

Service Object 已经不是一个新鲜话题了。从 7 Patterns to Refactor Fat ActiveRecord Models 开始就有不少人尝试照着这些 pattern 从 Rails 项目抽象出各种 object 进行解耦。这些 pattern 也催生了不少 gem，比如关注 policy 的 Pundit ，关注 form 的 Reform，关注 presenter 的……太多不举例了……

但 Service Object 却很少看到有相关的 gem，DHH 还跟别人讨论了大半天 service 的话题，看起来每个人对于 Service Object 的理解都有些差别。这是为什么？

我个人的理解是，Service Object 没有一个固定的形态，因为它完全就是业务逻辑的封装。

那讨论还有意义吗？有。因为我们需要它，需要更有效率地使用和讨论它。

Convention over Configuration

说到效率，就不得不提关于 Rails 的核心哲学 Convention over Configuration。如果你的理解仅仅是用 Convention 省去了配置，那并不是它的全部含义。

Convention 的另一层意义在于，它就是一个最佳实践的表现形式，Rails 本质上是一系列 web 开发中最佳实践的集合体。通过 Convention，Rails 开发者不仅可以避免为一些琐碎的事情费神，从而去处理真正需要关心的事情。更重要的是，遵循 Convention 的 Rails 项目都长得差不多，这使得 Rails 开发者的经验能够跨项目地重用。而且开发者互相交流起来天生就在一个频道上。We are on the same page !

但真正的项目千差万别，Rails 为我们做的毕竟有限，在没有 Convention 覆盖到的地方，开发者的理解就各有千秋了。Service Object 就是其中最典型的例子。有自己想法的人自然可以不拘泥于形式，但也有不少人在疑惑“怎么才算 Service Object”和“如何更好地实现 Service Object” ？

这篇文章推荐了一些 Service Object 的 Convention，来自这篇文章和这篇文章。

Service Object & Convention

简单的说，Service Object 是用对象来封装一段操作。通常情况下我们用它封装业务逻辑。关于什么情况下该使用 Service Object，7 patterns 里的话我觉得已经总结得很好了。

操作逻辑很复杂。
操作涉及到多个 model。
操作涉及到调用外部服务。
操作不是 model 该关注的逻辑（比如定时清理过期数据）。
操作涉及到一系列不同的具体实现（比如用 token 认证或者 password 认证），策略模式就是干这个的。

因为和业务逻辑比较接近，Service Object 通常用在 Controller 中，但也可以单独使用（比如在 job，console 或者其他 Service Object 中嵌套使用）。

Service Object 的一些简单的约定：

一个 Service Object 只做一件事。
每个 Service Object 一个文件，统一放在 app/services 目录下。
命名采用动作，比如 SignEstimate，而不是 EstimateSigner。
instance 级别实现两个接口，initialize 负责传入所有依赖，call 负责调用。
class 级别实现一个接口 call ，用于简单的实例化 Service Object 然后调用 call。
call 的返回值默认为 true/false ，也可以有更复杂的形式，比如 StatusObject。

以上这些只是约定，不是必须遵循的规范。比如你可以叫 SignEstimateService，把 call 改成 invoke，execute，perform 或者其他你喜欢的。但记住 如果没有特殊的理由，请让你的所有 Service Object 保持一致的约定 。

一个 Service Object 的例子：

# app/services/sign_estimate.rb
class SignEstimate
  def self.call(*args)
    new(*args).call
  end

  def initialize(estimate, params)
    @estimate = estimate,
    @params = params
  end

  def call
    # Do whatever you want
    # Return true/false
  end
end

如何使用它：

class EstimatesController
  # POST /estimates/:id/sign
  def sign
    @estimate = Estimate.find(params[:id])

    if SignEstimate.call(@estimate, estimate_params)
      # Do something like redirect
    else
      # Display errors
    end
  end
end

With Rails's help

Service Object 就是一个纯粹的 Ruby Object（PORO），但这不代表我们不能复用 Rails 已有的功能。我一直觉得为了开发便利，可以视情况增加 MVC 之外的层，但如果抛弃 Rails 已有的东西就本末倒置了，比如没必要为了建一个 Form Object 而把 Model 层的 validation 全部扔到 Form Object 里面去。

上个例子里的 SignEstimate 是我自己项目中的例子，实际使用时我会需要对 Estimate 这个 Model 做额外的 validation，但我不希望把这些逻辑放到 Model 层去，因为它们只有在 Sign 这个过程中有用。所以我会用到 ActiveModel。

另外，因为约定中每个 Service Object 中都有类方法 call 。我们可以把它单独抽出来变成一个 Concern。我比较喜欢用组合的方式，你也可以用继承来实现。

module Serviceable
  extend ActiveSupport::Concern

  class_methods do
    def call(*args)
      new(*args).call
    end
  end
end

class SignEstimate
  include Serviceable
  include ActiveModel::Model
  include ActionLoggable

  attr_reader :estimate

  delegate :signer_name,
           :sign_via,
           :signer_driver_lic,
           :signer_ssn,
           :errors,
           to: :estimate

  validates :signer_name, presence: true
  validates :sign_via, inclusion: { in: %w[driver_lic ssn] }
  validates :signer_driver_lic, presence: true, if: :sign_via_driver_lic?
  validates :signer_ssn, presence: true, if: :sign_via_ssn?

  def initialize(estimate, params)
    @estimate = estimate,
    @params = params
  end

  def call
    valid? && persist
  end

  private

  def persist
    @estimate.transaction do
      sign_estimate!
      close_sales_lead!
      transform_prospect_to_customer!
      copy_forms!
    end
    create_activity
    write_log('sign_est', resource: @estimate, operator: @estimate.assigned_to)
    true
  rescue ActiveRecord::RecordInvalid
    false
  end

  def sign_via_driver_lic?
    sign_via == 'driver_lic'
  end

  def sign_via_ssn?
    sign_via == 'ssn'
  end
end

有些方法是纯粹的业务逻辑，具体实现就不写了。这里我用了以下 Rails 的功能：

ActiveSupport::Concern 来抽离 Service Object 的公共接口。
ActiveModel::Model 来做校验，你也可以只要 ActiveModel::Validations。
delegate 方法来代理需要验证的字段和 errors 接口。这样添加的错误就自动给 @estimate 了。
ActionLoggable 是我自己写的 Concern，用来添加一些操作日志，生成报表用。

统一的约定可以方便抽离接口，PORO 可以方便我添加任何其他东西，不用考虑继承了什么类带来的 side effect。而且易于理解和修改。

Status Object as Return Value

这篇文章的作者也提到了返回值的约定。一个有意思的概念是，当需要返回的内容比较复杂时（操作失败返回错误信息），可以抽象出一个 Object 去封装返回值，这就是 Status Object。它定义了一个 success? 接口来判断操作是否成功，其他的信息就由各人自己 DIY 了。

class Success
  attr_reader :data

  def initialize(data)
    @data = data
  end
end

class Error
  attr_reader :error

  def initialize(error)
    @error = error
  end
end

你也可以用自己的方法来 one liner

Success = Struct(:data) { def success?; true; end }
Error = Struct(:error) { def success?; false; end }

怎么用呢：

def call
  if valid?
    # Dirty business logic...
    Success.new(@estimate)
  else
    Error.new("customized error message")
  end
end

我目前没有用到 Status Object 的必要，所以没有深入的例子。感兴趣的可以参考作者原文的例子，他在 AuthorizationError 里带了 code 和 message，方便 Controller 做针对性的操作。

Service Object 的构建很灵活，你可以想出最符合自己习惯的用法，形成约定。但记住 不要为了 pattern 而 pattern ，在满足要求的同时，尽量保持简单，重用 Rails 已有的功能，提高效率。

Testing

Service Object 的所有依赖都是在初始化的时候注入的，所以也可以很方便地使用 double 或者 Fake Object 来伪造对象，隔离依赖。

但根据我的实际经验，大部分 Service Object 都要跟 Model 层打交道， 建议这种情况下全部用真实的 Model 对象，不要 Mock/Stub 。

因为 Service Object 的存在必然会抽走一部分的 Model 逻辑。Model 中也许就只剩下比较简单的 validation, callback 和自定义方法了（比如关联保存 relationship，我不大喜欢 autosave）。这时候 Model 的 Unit Test 实际上是不足以保证数据库层面的功能正确的。如果 Service Object 都 Mock 了，那么保证功能的正确性就要靠 Integration Test 了。测试是为了保证系统稳定性的，为了一些速度降低稳定性不值得。

Another Way

刚才的 Service Object 是一种思路，但并不是没有其他的方法去抽离业务逻辑。这里是我在学习过程中看到的一些其他 gem。都可以达到相同的目的。我最终没用只是因为觉得这些 gem 的理念不太符合。不代表它们不好。

ActiveType

ActiveType 的理念是尽量利用 ActiveRecord 的 lifecycle，你可以写一个自己的 Object，但是像 Model 一样把逻辑封装进 validation 和 callback，从而让自定义的 Object 有和 ActiveRecord 一样的接口和使用方式。

这是我在 Growing Rails Applications in Practice 一书里看到的。里面提倡的一点就是把所有接口 CRUD 化，接口统一了之后就容易做更高层次的抽象。这个理念还是值得学习的。如果你没看过这本书，强烈建议看一看。

有人会疑惑为什么不用 ActiveModel 自己造？因为有太多的东西仍然在 ActiveRecord 里面。有些看似简单的需求很难实现，比如 save 之前调用你的 Object 的 validation 和内部的 Model 的 validation。如果你想自己写一个 Object 并沿袭 ActiveRecord 的接口，你需要做不少事情，但最终会发现自己仿造 ActiveRecord 写了一个 Object。可能还有各种问题……

上面的 Service Object 用 ActiveType 写，可能就是这个样子：

class SignEstimate < ActiveType::Record[Estimate]
  validates :signer_name, presence: true
  validates :sign_via, inclusion: { in: %w[driver_lic ssn] }
  validates :signer_driver_lic, :signer_state, presence: true, if: :sign_via_driver_lic?
  validates :signer_ssn, presence: true, if: :sign_via_ssn?

  before_save :set_sign_date
  after_save :close_sales_lead
  after_save :transform_prospect_to_customer
  after_save :copy_forms

  after_commit :create_activity, on: :update
  after_commit :write_log, on: :update

  after_rollback :clear_sign_info
end

这种 Service Object 在 Controller 中就跟 Model 一样用。喜不喜欢这种思路就见仁见智了。

Wisper

Wisper 是一个以 pub/sub 为理念的 gem，主张用 event + callback 的方式解耦。我是在搜索“为什么 Rails observer 被废掉了”的过程中偶然找到这个 gem 的。它同样可以用来解耦业务逻辑。

我个人不喜欢这种方式。因为有 callback 的代码很难被外层 Object 封装，比如官方的 Controller 例子很难抽象成统一的接口，进而使用 respond_with 。

不管怎么样，我想作为一个 900+ stars 的 gem 它还是很成功的。也许它是 observer 的一个很好的替代品。

Conclusions

Service Object 是 Rails 开发者回归 OO 方式思考的结果之一。它并不违反 Rails way，我们也没必要把任何操作都封装成 Service Object。解决方案通常是跟适用场景息息相关的，No silver bullet。作为 Rails 开发者，充分利用它的优势加上适当地拥抱变化，可以让人走的更远。

References

7 Patterns to Refactor Fat ActiveRecord Models

Gourmet Service Objects

Service objects in Rails will help you design clean and maintainable code. Here's how.

Object Oriented Rails – Writing better controllers

Twitter 上 DHH 关于 Service Object 的讨论

抛砖引玉，我的 2014 年度总结

darkbaby123 — Thu, 01 Jan 2015 22:36:36 +0800

转眼间一年又过去了，在新年的第一天，我按照惯例总结一下去年干了些什么，看看一年下来自己有哪些成长。这篇文章就算抛砖引玉啦，也祝大家新年快乐！

2014 年总的来说比较平淡，没什么大的波折，年初计划的事情，不出意外有一些没完成，好在同时也干了一些意料之外的事情，并且在我看来更有帮助，也算没白白浪费时间了。

按计划完成的事情

整理知识，丢弃不重要的和不需要的东西。
把 Ember 和前端技能从初级提升到中级。
获得了一些 hybrid app 的经验，实际参与了两个 hybrid app 项目，一个 PhoneGap/Cordova 一个 Ionic。
看完了几本 Ruby/JavaScript 有关的书。
玩完了两款很喜欢但一直没坚持的 iOS 游戏。

意料之外的完成的事情

娶了一个可爱的，值得爱的妞。
咖啡从提神工具上升到了爱好。
开始研究如何提升效率，用 Pocket 保存好的资源，用 OmniFocus 做 GTD, 用 Evernote 做笔记，用 Pomotodo 践行番茄工作法。
换了几个编辑器之后，最终换回 Vim，开始深入学习 Vim 和 Vimscript。
看完了一本技术无关的书，三体。

没有完成的事情

学另一门编程语言。
学习 iOS/Android 开发。
学几首英文歌。
积攒 StackOverflow 的 reputation。

心得总结

这是我回顾去年，最重要的几点心得。开始写的更多，但最终被我删了一半。减去不必要的东西，留下来的才更有价值。

关注最新的知识

多多引入获取信息的渠道，花点时间了解技术行业最新的发展，对扩展视野有很大的帮助。有些前沿知识，你不需要懂，但你要知道有这么个东西。以后碰到对应的问题，脑子里一下就会有几种大概的解决方案，而不是盲目地去 Google，甚至连个关键词都不知道。

我目前获取知识的主要来源是 Twitter，Feedly 和各种 email 订阅（比如 Ruby weekly，Ember weekly，Good UI 等）。 Twitter 纯粹被我当新闻客户端来用。优点是信息比较新，容易发掘相关的感兴趣的资源（别人转推），也容易获取到一些个人化的意见，比如 DHH 的各种犀利吐槽。Tom Dale 和 Yehuda 对 AngularJS/Ember.js 的讨论。这些信息不会出现在博客里，但含金量同样很高。

Twitter 上发现的好资源可以放到 Feedly 和 email 订阅，定期扫一下，筛选出需要的知识阅读就行。

但随着信息获取的日益便利，信息过载马上成为了更大的问题。Pocket 里面收藏的文章日益增多，Feedly 中未读条目越来越多，这时候就需要减负了。

减少关注方向，集中精力在需要的事情上

我们总有很多想要学的东西，想要完成的事情，但我们都不是超人，没有那么多时间精力。精力分散导致我尝试了很多事情，但都没到质变的程度。一年到头，感觉忙了很多，却少有拿得出来说的东西。所以想把事情做好，就要有所取舍。

减少关注方向，不但能让人集中更多的时间精力在少数的事情上。而且负担更少，相应的没完成的事情产生的自我否定感觉也更少。

时间会帮你筛选最重要的事情

制定的计划难免赶不上变化，有时是因为有更重要的事情要处理，有时是尝试一段时间后发现计划的事情对自己的帮助有限，有时是因为一些意料之外的情况。但一年下来，我发现还是完成了一些事情，并且不管计划内还是计划外，那些事情都是我最在意的。

不用为了没完成预定计划而自责，因为时间会逼迫你做选择，投入你最喜欢，最重要的事情，放弃价值较少的事情。

制定计划优先考虑需要的和喜欢的，否则容易变成空谈

接上条所说的，那为什么还需要计划呢？计划对我来说是一个大致的方向和一些我在新的一年期望达到的事情。它是愿景但非标准。

但制定计划也不能随便瞎扯淡，比如“变成高富帅迎娶白富美跨上人生巅峰”什么的。那怎么选择呢？我的想法是考虑需要的和喜欢的。需要往往代表我在某方面遇到了困难，这时候也许今天学的知识明天就能用上，这种“付出终有回报”的感觉会让人容易继续下去。至于做喜欢的事情，喜欢就是最大的动力，而且可以让人乐在其中，不会有种“迫不得已不得不做”的强迫感。

2015 年计划

今年我准备减少关注点，继续去年没有完成的一些事情，适当做一些新的尝试。

在 Hybrid app 的道路上更进一步。
在测试理论上更进一步。
学习一门和 Erlang 类似的语言（初步意向为 Elixir），Ruby 对人友好，并发性能稍差，Node.js 性能很好，但因为 JavaScript 本身的原因，callback 写起来比较蛋疼。希望新语言能提供一个新的思路。给 web 开发带来一些改变。
深入学习 Vim 和 Vimscript，提高效率。
积攒 StackOverflow 的 reputation。
看一本技术无关的书，暂定为狼图腾。
提升咖啡技能，学会享受和辨别不同的单品咖啡。
锻炼身体，保持健康。
英文博客。

如果你已经看到了这里，我衷心地感谢你的耐心。也非常希望能看到你的总结。一起分享，共同成长！

前段时间做的 web app 无意中符合了 Google Design 的要求

darkbaby123 — Thu, 26 Jun 2014 11:21:59 +0800

早上起来看了下 Google IO，发现 Google Design 这个网站，就看了看有啥东西。看到 Text fields 我就乐了。前段时间在做一个 web app，自己设计的界面居然无意中符合了一点要求。难道这就传说中的潮流不是去追的，是等的？

Google Design - text fields:

focus 后：

我的：

focus 后：

把红宝石拍扁了放在标题栏中间也许不错

darkbaby123 — Wed, 12 Feb 2014 22:17:51 +0800

既然都借鉴 Twitter 这么多了，中间的 Ruby China 字样也换成 Logo 算了吧？甚至可以做成平时暗色 hover 过去亮红色的效果。

Press Enter to Submit 背后的那些事

darkbaby123 — Mon, 10 Feb 2014 19:22:52 +0800

前言

这篇 blog 是从我的个人博客里转过来的，考虑到只贴前面一点内容加个 link 的方式有点不厚道，而且都 markdown 格式，复制粘贴也方便，就全部弄过来了。

最近碰到一些 form 提交的一些恼人问题，虽然最后把问题解决了，但对 form 如何响应 Enter 键提交的规律还是不够清楚。专门花时间研究了一下，就有了这篇文章。先看看以下几个问题，如果你也不能确定的解答以下问题，那么这篇文章就是为你准备的。

按下 Enter 后，form 的 submit 事件一定会触发吗？
按下 Enter 后，提交按钮的事件会触发吗？如果会，哪种提交按钮的事件才会触发？
输入框可以阻止 Enter 触发吗？如果能，该怎么做到？

前置准备

我在浏览器上做了一系列实验去比较彼此的差异。因为条件有限（懒），仅仅在 Mac 系统的 Chrome，Safari，和 iOS 的 Mobile Safari 上测试过。我想在 Firefox 上也不会有什么差别。IE …… 我们还是先忽略它吧。想了解更多浏览器兼容性的同学，最下面有篇国外文章，作者在各大浏览器上都测试过，可以看一下。

做实验之前，我们先看看要用到的几个 html 标签和事件。

第一类是 <form>，它可以响应 submit 事件，我们用任意方式提交 form 时都会触发，比如点击提交按钮（待会再说是哪种按钮），或者在某个输入框下按 Enter 键。

第二类是 <input type="text">。标准的输入框，它可以响应 keydown， keypress，和 keyup 事件。我们前期不会用到这些，尽量把事情简单化。

第三类是各种按钮，我们会用到三种按钮 <input type="button">，<input type="submit">，和 <button>。他们都能响应 click 事件。

大概就这些了，可以开始对比了。每次实验中我会把 html 和 js 片段（我用 CoffeeScript）写下来，因为太简单，就不特别说明怎么用了。

实验开始

1. 当 `<form>` 里仅含有一个 `<input type="text">` 时

<form id="form">
  <input type="text">
</form>

$('#form').on 'submit', ->
  console.log 'submit'
  false  # 最后 return false 以免页面刷新

按下 Enter，console 里打印出了 submit，说明 <form> 的 submit 事件被触发了。

2. 当 `<form>` 里含有两个 `<input type="text">` 时

<form id="form">
  <input type="text">
  <input type="text">
</form>

$('#form').on 'submit', -> console.log 'submit'; false

在任何一个输入框里按下 Enter， submit 事件都没有触发。

3. 当 `<form>` 里含有一个 `<input type="text"`>，和一个 `<input type="button">` 时

<form id="form">
  <input type="text">
  <input id="save" type="button" value="Save">
</form>

$('#form').on 'submit', -> console.log 'submit'; false
$('#save').on 'click', -> console.log 'save'

按下 Enter，只有 submit 事件触发；按下按钮，只有 click 事件触发。

4. 当 `<form>` 里含有一个 `<input type="text">`，和一个 `<input type="submit">` 时

<form id="form">
  <input type="text">
  <input id="save" type="submit" value="Save">
</form>

$('#form').on 'submit', -> console.log 'submit'; false
$('#save').on 'click', -> console.log 'save'

按下 Enter， click 事件先触发，然后是 submit 事件；按下按钮，结果相同。

5. 当 `<form>` 里含有一个 `<input type="text">`，和一个 `<button>` 时

<form id="form">
  <input type="text">
  <button id="save">Save</button>
</form>

$('#form').on 'submit', -> console.log 'submit'; false
$('#save').on 'click', -> console.log 'save'

按下 Enter， click 事件先触发，然后是 submit 事件；按下按钮，结果相同。

6. 当 `<form>` 里含有一个 `<input type="text">`，和两个 `<input type="submit">` 时

<form id="form">
  <input type="text">
  <input type="submit" id="save" value="Save">
  <input type="submit" id="cancel" value="Cancel">
</form>

$('#form').on 'submit', -> console.log 'submit'; false
$('#save').on 'click', -> console.log 'save'
$('#cancel').on 'click', -> console.log 'save'

按下 Enter，第一个按钮的 click 事件被触发，然后是 submit 事件. 按下任何一个按钮，该按钮的 click 事件被触发，然后是 submit 事件。

7. 当 `<form>` 里含有一个 `<input type="text">`，和两个 `<button>` 时

结果和第六个相同。

关于 form 的小结

经过以上几个实验，我们可以得出以下下结论：

按下 Enter 时，如果 <form> 要触发 submit 事件，要符合两种情况之一：只有一个输入框（可以没有提交按钮），或者至少有一个提交按钮。<input type="submit"> 和 <button> 都可以看成是提交按钮。jQuery 的 submit() API 也对此有所提及。
达到第一条触发 submit 的条件后，不管是按提交按钮，还是按下 Enter ，<form> 都会执行一样的流程：先触发按钮的 click 事件（如果有按钮），然后触发 submit 事件。这算是提交的标准流程。
但如果提交按钮有多个，<form> 会把第一个出现的按钮作为默认提交按钮，按下 Enter 触发 click 事件时，也只会触发这一个按钮的事件。想触发其他按钮的 click 事件，只能去手动点击。

这里有一个坑，一般情况下我们都不会去在一个 form 里写两个 <input type="submit">，但有可能会去写两个 <button> 。这种情况因为 <button> 就跟提交按钮无异。那怎么避免这种问题呢？我查了一下 button 的文档。原来它还有一个 type 属性，可以设置成 button， reset 和 submit 。但 submit 是默认值，所以 <input type="submit"> 等价于 <button type="submit">。如果要让它表现得像普通按钮，记得加上 type="button" 。

如果为提交按钮加入 preventDefault 呢？

我们知道有些 HTML 标签会有默认行为，很明显提交按钮的默认行为就是提交表单。如果这时候在提交按钮的 click 事件中使用 preventDefault，像这样：

$('#save').on 'click', (e) -> e.preventDefault()

那么不管是 Enter 还是直接点击，都不会触发 form 的 submit 事件了。

那如果为输入框加入 preventDefault 呢？

既然按钮可以 preventDefault，那么更进一步的想，对输入框使用 preventDefault 会发生什么事情？这个解释起来比按钮复杂一点，因为输入框可以响应 keydown， keypress，和 keyup 三个事件。

我们先来看看提交 form 时，这几个事件的执行顺序：

<form>
  <input type="text">
  <button>Save</button>
</form>

$('form').on 'submit', -> console.log 'submit'; false
$('input').on 'keydown', -> console.log 'keydown'
$('input').on 'keypress', -> console.log 'keypress'
$('input').on 'keyup', -> console.log 'keyup'
$('button').on 'click', -> console.log 'click'

按下 Enter 或者点击按钮，事件执行顺序为：

keydown
keypress
click
submit
keyup

从这里可以看到只有 keydown 和 keypress 触发在 click 之前，那么我们试试对这两个事件用一下 preventDefault。过程就不写了，结果如下：

当 keydown 加上 preventDefault 时， keypress， click， submit 都不会触发。当 keypress 加上 preventDefault 时， click 和 submit 都不会触发。

因此可知， keypress 使用 preventDefault 的效果是取消了 click，进而引发了 submit 也不会触发。而 keydown 则是因为取消了 keypress 导致没有触发 form 提交。

参考资料

MDN HTML button tag How Forms Submit When Pressing Enter jQuery API .submit()

一段 HTMLBars 的 slide

darkbaby123 — Sat, 25 Jan 2014 00:35:47 +0800

地址见这里：HTMLBars

HTMLBars 是基于 Handlebars 之上的一个模板引擎，它改用生成 dom 而非 string 的方式，在 Handlebars 的基础上提供更灵活语法，和更高的性能。目前这个玩意还在开发中。一旦完成，Ember 将用它替换 Handlebars。当然它也可以单独使用。

抄段例子更直观：

<!-- This is our ideal, right? -->
<div class="{{foo}}">{{bar}}</div>

<!-- but this is what we have to do in Ember today -->
<div {{bind-attr class="foo"}}>{{bar}}</div>

<!-- With HTMLBars, we get our ideal syntax! -->
<div class="{{foo}}">{{bar}}</div>

更多信息去看 slide 吧，如果对模板引擎的实现原理有兴趣，可以看看这篇 ARCHITECTURE

Ember 中的依赖注入

darkbaby123 — Mon, 16 Sep 2013 11:27:58 +0800

原文有点长，就直接贴个链接了。Ember 中的依赖注入

这篇文章是给略懂一点 Ember 的人看的。当然如果你懂 AngularJS 的依赖注入也行。国内玩 Ember 的实在是少。但这个框架确实不错。除了 Data 层之外的地方都做的比较完善了。这篇文章算是抛砖引玉吧。

Emblem - 用 slim 语法写 Ember 的 template

darkbaby123 — Wed, 03 Apr 2013 14:01:48 +0800

Ember 默认的 handlebars 还是类似 erb 风格的，平时 slim 写习惯了看着真不舒服。喜欢 haml，slim，jade？Emblem 来拯救你了！

看看首页就全明白了，网站都是标准的 slim 风格 http://emblemjs.com/ 对框架支持的很广泛，参见 Installation。当然首先就是 Rails 啦！直接装个 gem 了事～

赞美 Mina，实在太好用了，写点心得给还在纠结的同学

darkbaby123 — Wed, 20 Mar 2013 16:47:49 +0800

最近重构代码完成需要部署，想着最近几年受够了 Capistrano，也该换换新欢了，遂试了试 Mina。发现确实好用！

说下几点好处：

部署时生成的信息更简洁清楚

这个其实是我在意的一点，也是最烦 Capistrano 的一点，一个简单的部署任务，提示信息刷屏似的，混杂了一堆底层命令和 IP 地址，生怕你不知道脚本是在远程跑似的……因为信息太多，有时候出个 bug，想跟踪看看哪一步错了，都要仔细分辨下……

其实我想看的就是，部署几大步骤简单列出来，版本库迁出，symlink 配置文件，跑 bundle，编译 assets，重启服务器，某些步骤加一点额外信息就够了，没必要每个步骤都把细节全部列出来。

以下是从 Mina 部署的提示信息：

-----> Using RVM environment '1.9.3'
       Using /usr/local/rvm/gems/ruby-1.9.3-p392
-----> Creating a temporary build path
-----> Fetching new git commits
-----> Using git branch 'master'
       Cloning into '.'...
       done.
-----> Using this git commit

       User (5bf268b):
       > 重构项目

-----> Symlinking shared paths
-----> Installing gem dependencies using Bundler
       Using rake (10.0.3) 
       Using i18n (0.6.4) 
       Using multi_json (1.6.1) 
       ...
-----> Skipping asset precompilation
-----> Build finished
-----> Moving build to releases/13
-----> Updating the current symlink
-----> Launching
       .
-----> Done. Deployed v13
       Elapsed time: 8.00 seconds

是不是看着挺干净？该简洁的时候简洁，关键地方提示你一下，比如这次部署迁出的版本 commit 内容，assets 被 skip 掉了（因为没有改变），等等。实际显示在终端中的效果还有高亮哦。

部署变快了

据说两者原理不同，Mina 只用一个 ssh 连接，Capistrano 用多个，这个我就不提了。说下个人觉得影响速度的另外一点。

Capistrano 对编译 Rails 3 的 assets 非常蠢，每次部署都重新编译所有文件，当然你可以加一个 turbo-sprockets-rails3 去只编译改动过的文件。但 Mina 部署时会自动判断 assets 是否改动，对没有改动的文件直接使用老的编译版本，而且好像不需要单独的 gem 支持。

部署脚本简单，扩展性强

标准的部署脚本肯定不能满足各人的需求，大部分情况下都需要中途插入一些步骤，Capistrano 使用回调的形式：

after "deploy:create_symlink"
  run  "ln -sf #{shared_path}/config/mongoid.yml #{current_path}/config/mongoid.yml"
end

而 Mina 提倡你自己写：

task :deploy => :environment do
  deploy do
    # Put things that will set up an empty directory into a fully set-up
    # instance of your project.
    invoke :'git:clone'
    invoke :'deploy:link_shared_paths'

    # blablabla 想写些啥自己搞定吧

    invoke :'bundle:install'
    invoke :'rails:assets_precompile'

    to :launch do
      queue './script/unicorn upgrade'
    end
  end
end

谁更简单，这点见仁见智。但个人觉得 Mina 的方式更简单清晰，不仅一眼就可以看出整个部署流程要执行哪些任务，而且也方便你随意修改。Capistrano 中每次我要插入一些自定义任务时，都要先回忆一下它默认会跑哪几个任务，然后想想代码该放在那个任务的回调里，再想想是放 before 还是放 after……

支持 git submodule

用过 git submodule 的都知道要更新 submodule 要单独跑两个命令。这点我不知道 Capistrano 支不支持，不好评论，但 Mina 会在 clone 版本库的时候自动帮你把 git submodule init 和 git submodule update 两个命令跑了，省心。

小结

Mina 只是今天开始用了一下，也算不上熟悉，也许有些结论并不正确。但它给我的感觉，就是保持扩展性的同时，剪掉了 Capistrano 复杂的部分，变得简单清爽。如果你不喜欢 Capistrano 的复杂，Mina 会是个不错的选择。

CoffeeScript 支持 source maps 了，在浏览器中调试 CoffeeScript 已成为现实

darkbaby123 — Sat, 16 Mar 2013 21:49:58 +0800

CoffeeScript 1.6.1 版本的新功能之一，就是支持 source maps。

什么是 source maps？简单的说，它可以通过一定的方式，从编译/压缩后的 JavaScript 代码，找到对应的未编译/压缩的源文件。

这个技术就是用来调试用的，目前可以用在两个地方：

从压缩后的 JavaScript 代码找到未压缩的版本，让你在生产环境下调试时，不至于面对天书一样的 JavaScript 无从下手。
从编译后的 JavaScript 代码找到编译之前的 CoffeeScript 代码，不用你身体内置编译器了。

我们可以建一个简单的项目试试，如果你不想动手的话，看看代码和图片也足够明白了。

一个小实验

需要环境：Node.js, npm, 已安装 coffee-script 包，Google Chrome 最新版

先为项目建立一个文件夹叫 aaa。里面包含两个文件，a.coffee 和 a.html，原谅我起的名字吧～

a.coffee

window.hello = ->
  console.log 'Hello World'

a.html

<!DOCTYPE html>
<html>
  <head>
    <script type="text/javascript" src="a.js"></script>
  </head>
  <body></body>
</html>

然后在 aaa 目录下，执行 coffee 命令编译 a.coffee，带上参数 -m 用于生成 source maps 需要的文件。

Terminal

coffee -cm a.coffee

这会生成两个文件，a.js 和 a.map，来看看这个两个文件：

a.js

//@ sourceMappingURL=a.map
// Generated by CoffeeScript 1.6.1
(function() {

  window.hello = function() {
    return console.log('Hello World');
  };

}).call(this);

a.map

{
  "version": 3,
  "file": "a.js",
  "sourceRoot": "",
  "sources": [
    "a.coffee"
  ],
  "names": [],
  "mappings": ";;AAAA;CAAA;CAAA,CAAA,CAAe,EAAf,CAAM,GAAS;CACL,EAAR,IAAO,IAAP,EAAA;CADF,EAAe;CAAf"
}

a.js 自然是编译后的 JavaScript 文件，跟以前不同的是开头有两行注释。其中第一行就是告诉浏览器去找一个 map 文件 -- a.map。浏览器就会通过 a.map，把编译前后代的代码一一对应起来。a.map 中的 mappings 内容就是记录这段内容的，它会根据 a.coffee 的改变而改变。有兴趣的可以自行修改 a.coffee 尝试下。

项目到这里就搞完了。现在用浏览器实验下。

现在我们用 Google Chrome 打开 a.html。再打开 Inspector 工具。先点击右下角的齿轮图标打开 Settings，勾选 Enable source maps。

然后关闭 Settings，点击上面的 Sources 标签查看源代码，你会看到浏览器列出了 a.coffee 文件！

{% img /images/blog/sources_coffee.png %}

现在我们先打个断点，然后执行 hello 函数看看：

See ? It works !

小结

不难看出，要做到在浏览器中调试 CoffeeScript 代码，必须做到以下几点：

浏览器支持 source maps，目前我只知道 Google Chrome 支持，其他浏览器的情况未知。
JavaScript 文件中提供关于 map 文件的信息。这需要 CoffeeScript 编译时加上 -m 参数。
浏览器可以通过 url 获取到 coffee 文件和 map 文件。

也许因为这些原因，目前 Rails 项目里面还不能使用 source maps 直接调试 CoffeeScript 文件。好消息是 Sprocket 现在正在添加对 source maps 功能的支持，应该不久就会有结果。到时候用 Rails 的我们就又 high 啦。

另外，source maps 只是一个映射到源文件的技术，这就是说以后还可以利用这个技术在浏览器中看 SASS 和 LESS，说不定还可以通过 html 看 erb，slim 和 haml？前景可谓一片光明。

参考文档

CoffeeScript source maps CoffeeScript 官网的介绍。
Introduction to JavaScript Source Maps 介绍 source maps 技术，想深挖原理的可以看看。里面有个 demo，点击一段未压缩的 JavaScript 代码，可以看到该段代码对应源文件中的哪一行，非常 cool。
nettuts+ Source Maps 101

这篇文章讲的很细，包括从压缩的 JavaScript 映射到未压缩的版本，从 JavaScript 映射到 TypeScript（微软的预编译语言，更类似静态语言）等等。

JavaScript Source Map 详解阮一峰的博客，讲 source maps 原理。浅显易懂，并且很详细。

请问有哪些办法可以做性能测试？

darkbaby123 — Tue, 12 Mar 2013 15:45:03 +0800

我不知道这应该归类于性能测试还是压力测试，但需求大概是这样：

网站需要登录才能进去操作。
我想模拟多个用户同时登录网站进行操作，操作本身可以简单看成不停的发起指定的请求（不止一个）。
能写脚本来自定义行为就更好了，比如判断访问某 url 是否跳转了，等等。

原来是用 jmeter 来做这件事，但我觉得还是不大好用，配置挺麻烦，而且不够智能。请教下各位有没有什么先进点的办法？

darkbaby123 (陈璋)

[武汉] 巧议网络 - Elixir 后端工程师（长期招聘）

公司介绍

团队介绍

公司地址

职位和待遇

工作职责

任职要求

加分项

联系方式

[上海] 巧议网络科技有限公司 招聘 Elixir 后端工程师 (25-45k)

公司介绍

关于团队

要求

待遇

公司地址

联系方式

用 PostgreSQL 的 COPY 导入导出 CSV

TL;DR

导出 CSV

导入 CSV

总结

参考资料

JavaScript ASI 机制详解

TL;DR

什么是 ASI

Token

ASI 规则

例子解析

第一个例子：换行

第二个例子：大括号

第三个例子：do while

第四个例子：return

第五个例子：后缀表达式

第六个例子：空语句

第七个例子：for

如何手动测试 ASI

结尾

参考资料

Phoenix render 迷思

前言

render 的使用场景

controller 的 render

template 的 render

view 的 render

小结

Phoenix 中有哪些 render 方法？

它们分别是干什么用的？

它们有内部联系吗？

参考资料

这是我见过的最黑的事情……

Virtus 作者决定放弃项目了

更简单灵活地管理 Ruby 版本

概述

为什么不用 RVM 或者 rbenv

使用 ruby-install & chruby

在命令提示符里显示 Ruby 版本

参考链接

JavaScript 原型系统的变迁，以及 ES6 class

概述

JavaScript 原型简述

模拟继承

ES5: 自由地操控原型链

尴尬的私生子 proto

ES6: class 语法糖

extends 继承内建类的能力

super 带来的新概念（坑？）

super 在 constructor 和普通方法里的不同

super 在子类的 constructor 里必须先于 this 调用

super 是编译时确定，不是运行时确定

super 对 static 的影响，和类的原型链

直接定义 object 并设定 [[Prototype]]

总结

参考资料

Service Object 整理和小结

TL;DR

Why Service Object (Again)?

Convention over Configuration

Service Object & Convention

With Rails's help

[上海] 巧议网络科技有限公司招聘 Elixir 后端工程师 (25-45k)

Phoenix 中有哪些 `render` 方法？

1. 当 `<form>` 里仅含有一个 `<input type="text">` 时

2. 当 `<form>` 里含有两个 `<input type="text">` 时

3. 当 `<form>` 里含有一个 `<input type="text"`>，和一个 `<input type="button">` 时

4. 当 `<form>` 里含有一个 `<input type="text">`，和一个 `<input type="submit">` 时

5. 当 `<form>` 里含有一个 `<input type="text">`，和一个 `<button>` 时

6. 当 `<form>` 里含有一个 `<input type="text">`，和两个 `<input type="submit">` 时

7. 当 `<form>` 里含有一个 `<input type="text">`，和两个 `<button>` 时