kamiiyu (Vince Ho)

{今天: {Ruby: '24 岁', 我: '36 岁'}}

kamiiyu — Fri, 24 Feb 2017 23:48:17 +0800

低头猛赶稿，已经不知道是过了多少个凌晨 3 点了，只知道令人惭愧的进度。
Ruby 已经迎来 2.4 版本了，而手上的《Ruby 基础教程》第五版（对应 Ruby2.3）的稿件还有三分之一没完成。
凑巧某处提到 1993 年 2 月 24 日是 Ruby 的“诞生日”，才发现原来今天就是 Ruby24 岁生日！
回想 07 年知道 Ruby，11 年开始用 Ruby 至今，感慨万千。

“你以前搞 Java 的，为什么会想到转 Ruby 呢？”
“Ruby 很小众，不好招人吧！？”
“带过团队吗？”
“Ruby 性能不好啊！”
“Ruby 怎么那么慢？”
“Ruby 怎么会这样？”
“Ruby 怎么会那样？”
“Ruby……和 PHP 差不多？”
“Ruby……”
“哦，那还是不要用 Ruby 吧！”

已经过了血气方刚的年龄，已经“不敢”和人争辩。
听到，心里也就是咯噔一下，眉头皱一皱，然后……就过去了。

“因为 Ruby 会令你感到快乐，而且喜欢 Ruby 社区的氛围……”
“不好招，都是找 PHP 转的，或者……”
“带过，小团队，因为……”
“但开发效率高啊，而且现在硬件性能也好……”
“也还好吧，因为 Ruby 比较灵活，还有……”
“其实是那样的……”
“其实是这样的……”
“也……是啦，主要都是用来做网页的……”
“嗯……明白……说的也是……”
“也……不是……特别地……反对用 NodeJS，……都行……”

认识 Ruby 以前，转职时讲的是“……想换个环境、平台……”。
认识 Ruby 以后，讲的是“……因为公司不准备用 Ruby 了……”。

曾经背叛过。
现在也在想是否应该放弃。

为什么要坚持。
坚持的到底是什么。
……
还是用 Ruby 的时候才是最开心的。

感恩！
感谢！

Ruby!
Happy Birthday!

Ruby 程序员！
Happy Hacking!

浅谈 ActiveRecord 的 N + 1 查询问题

kamiiyu — Thu, 23 Feb 2017 00:04:09 +0800

ORM 框架的性能小坑

在使用 ActiveRecord 这样的 ORM 工具时，常会嵌套遍历 model。
例如，有两个 model，Post、Comment，关系是一对多。

class Post < ApplicationRecord
  has_many :comments
end

class Comment < ApplicationRecord
  belongs_to :post
end

总共有 4 个 post。

> Post.count
(0.1ms)  SELECT COUNT(*) FROM "posts"
=> 4

获取每个 post 的所有 comment，我们可以：

> Post.all.map{|post| post.comments}
  Post Load (0.3ms)  SELECT "posts".* FROM "posts"
  Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?  [["post_id", 1]]
  Comment Load (0.4ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?  [["post_id", 2]]
  Comment Load (0.6ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?  [["post_id", 3]]
  Comment Load (0.6ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?  [["post_id", 4]]

可以看到为了得到 4 条数据，我们执行了 5（4 + 1）次的查询，这就是所谓 N + 1 查询问题。

发现问题

除了凭经验外，有一些 gem 也可以帮助我们提早发现 N + 1 查询问题。
例如收费的New Relic，免费的Bullet。

解决问题

预加载

简单来说，就是提前加载 model 关系，让 ActiveRecord 预先加载所需要的数据。
ActiveRecord 提供了以下三个方法预加载。

includes
preload
eager_load

他们的区别可以参考这里或这里。
以最常用的includes方法为例。

> Post.includes(:comments).map{|post| post.comments}
  Post Load (0.2ms)  SELECT "posts".* FROM "posts"
  Comment Load (0.5ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3, 4)

得到的结果一样，但执行的查询只有两次。

傻瓜式预加载 (Goldiloader)

传统预加载的“问题”

includes方法的确很惊艳，但……

第一，代码不够优雅。
例如，假设我们现在想找的是 id 在 1 到 3 之间的 post 的 comment。
一般的我们的逻辑是，查找 id 在 1 到 3 之间的 post，获取各 post 的 comment 然后合并。
而预加载后的逻辑是，查找 id 在 1 到 3 之间的 post，关联 comment，再获取各 post 的 comment 然后合并。
总觉得有点冗余。

> Post.where(id: 1..3).includes(:comments).map{|post| post.comments}
  Post Load (0.5ms)  SELECT "posts".* FROM "posts" WHERE ("posts"."id" BETWEEN ? AND ?)  [["id", 1], ["id", 3]]
  Comment Load (0.5ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3)

第二，不符合 DRY。
既然我们都不喜欢 N + 1，那就应该从源头上杜绝，而不是每次查询时都要主动includes一次。

Goldiloader

懒癌程序员的救星Goldiloader——几乎完美的解决了以上两个问题。

gem 'goldiloader'

bundle install以后，就可以用最直接（傻瓜）的方式点点点……

> Post.where(id: 1..3).map{|post| post.comments}
  Post Load (0.2ms)  SELECT "posts".* FROM "posts" WHERE ("posts"."id" BETWEEN ? AND ?)  [["id", 1], ["id", 3]]
  Comment Load (0.3ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3)

auto_include

Goldiloader 默认自动加载所有关联数据，用auto_include: false可以方便地关闭自动加载。

class Post < ApplicationRecord
  has_many :comments, auto_include: false
end

fully_load

以下的方法比较特殊，如果关系已经加载了，则会直接返回已缓存的值，如果没被加载，则会通过 SQL 查询。

first
second
third
fourth
fifth
forty_two
last
size
ids_reader
empty?
exists?

假设现在我们需要获取每个 post 的最新的 comment。
但这不是我们想要的。

> Post.all.sum{|post| [post.id, post.comments.last&.content]}
  Post Load (0.1ms)  SELECT "posts".* FROM "posts"
  Comment Load (0.1ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."id" DESC LIMIT ?  [["post_id", 1], ["LIMIT", 1]]
  Comment Load (0.1ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."id" DESC LIMIT ?  [["post_id", 2], ["LIMIT", 1]]
  Comment Load (0.1ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."id" DESC LIMIT ?  [["post_id", 3], ["LIMIT", 1]]
  Comment Load (0.1ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."id" DESC LIMIT ?  [["post_id", 4], ["LIMIT", 1]]

添加选项full_load: true后，当调用上述方法时，Goldiloader 会强制自动加载所需的关系。

class Post < ApplicationRecord
  has_many :comments, fully_load: true
end

这才是我们想要的。

> Post.all.sum{|post| [post.id, post.comments.last&.content]}
  Post Load (0.3ms)  SELECT "posts".* FROM "posts"
  Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3, 4)

Goldiloader 也不是万能的

has_one 使用 SQL limit 时的隐患

Goldiloader 是 ActiveRecord 的衍生工具，所以 ActiveRecord 预加载的副作用也一并继承了。
现在我们自定义一个has_one关系，用以获取最新的一条 comment。

class Post < ApplicationRecord
  has_many :comments, fully_load: true
  has_one :latest_comment, -> { order(created_at: :desc) }, class_name: 'Comment'
end

遍历 post 获取最新的 comment。

> Post.all.map{|post| post.latest_comment}

不使用 Goldiloader 或者预加载时，每条 SQL 自动回加上limit 1。

Post Load (0.3ms)  SELECT "posts".* FROM "posts"
Comment Load (0.2ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."created_at" DESC LIMIT ?  [["post_id", 1], ["LIMIT", 1]]
Comment Load (0.2ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."created_at" DESC LIMIT ?  [["post_id", 2], ["LIMIT", 1]]
Comment Load (0.1ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."created_at" DESC LIMIT ?  [["post_id", 3], ["LIMIT", 1]]
Comment Load (0.1ms)  SELECT  "comments".* FROM "comments" WHERE "comments"."post_id" = ? ORDER BY "comments"."created_at" DESC LIMIT ?  [["post_id", 4], ["LIMIT", 1]]

使用 Goldiloader 或者预加载时，世界变清净了，但同时会有性能隐患，因为 post 的数据量可能非常大。

Post Load (0.5ms)  SELECT "posts".* FROM "posts"
Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3, 4) ORDER BY "comments"."created_at" DESC

其他限制

遇到以下的关系（方法），Goldiloader 会自动关闭自动预加载。

limit
offset
finder_sql
group (due to a Rails bug)
from (due to a Rails bug)
joins (only Rails 4.0/4.1 - due to a Rails bug)
uniq (only Rails 3.2 - due to a Rails bug)

本文结束之前

N + 1 查询问题是一个容易被忽略的问题。
发现解决它也不难，includes已经够用，Goldiloader 更是锦上添花，对新手足够友好。
不过对于我这种被 Rails“坑”习惯的斯德哥尔摩症候群患者来说，没有includes反而没安全感了>_<|||

参考文档

非动态，也非静态，Ruby 3 Typing 的第三条路

kamiiyu — Fri, 02 Dec 2016 11:31:40 +0800

Matz 在 2016 年的 Rubykaigi 里做了一个关于 Ruby3 Typing 的分享。
首先简单介绍一下什么是RubyKaigi。
Kaigi 就是日语【会議】的罗马字母写法，顾名思义也就是在日本举行的 RubyConf。
RubyKaigi 在 2006 年首次举行时的名字就是【日本 Ruby カンファレンス】（Japan Ruby Conference），由于容易与Ruby Central混淆，因此在 2007 年改名为【日本 Ruby 会議】，直到 2011 年停办。
2013 年大会重开，改名为【RubyKaigi】，并统一使用英语作为大会的官方名称。

今年的RubyKaigi2016在 9 月 8 号到 10 号京都举行。由于近水流台，有不少像 Matz 这样的 Ruby committer 参与分享，所以大会含金量非常高。
官网中以及发布了所有视频，希望以后有机会可以亲身去感受下。

大会的首个 Topic 是 Matz 的 Ruby3 Typing（油管直通车）

演讲者 Matz 就不多做介绍了。

官方没有提供在线版的 PPT，我把这个日语演讲“翻译”成以下的文字，为了保持文字通顺，稍微加工了一下。

Ruby3 Typing (Matz)

在 2010 年以来的新语言很多都是静态类型语言（Static Typed Languages），例如 TypeScript、Flow、Go、Swift 等等。
与之相比，Ruby 没有静态类型，又是上世纪 90 年代语言，所以有些人会说“Ruby is Dead”、“Rails is Dead”。

但技术有时候就像钟摆，有时候偏向一种技术，有时候又偏向另外一种技术，这是常有的事情。例如静态类型与动态类型“之争”。

1970s 到 1980s 左右，从 Smalltalk、lisp 摆到 Java、C++
接下来又从 Java 摆到 Ruby、JavaScript
到最近又从 Ruby、JavaScript 摆到 Swift、Go

那么未来 Swift、Go 又会摆到哪里去呢？未来 Ruby3 的类型又会有什么改变呢？

首先我们需要知道什么是 Ruby 的 type？对于动态类型语言来说，Class 不是类型。
另外在 Ruby 其中一个重要的原则就是Duck typing，也就是说对于一个 Ruby 对象来说，我们不关心她继承关系（inheritance），也不关心她的内部结构（structure），我们只关心她的行为（behaves）。

请看下面String IO的例子。

Ruby 版本的日志输出代码片段：

log(STDERR, "error!")

静态类型版本：

log(dst IO, mesg String)

Ruby StringIO版本：

sio = StringIO.new()
log(sio, "error!")
sio.string # => retrieve string

上面的StringIO例子在静态类型的世界行不通，因为StringIO没有与IO有共同的superclass或interface，所以无法通过编译。

Duck typing 使我们在开发的时候不需花时间研究各个 Class 间的关系，大大降低开发者的开发成本，而且扩展起来也更加灵活。
所以我们可以认为，在 Ruby 的 type 就是“Duck”。“Duck”不是 Java 那样的Nominal type，更不是 Class，它是一种被期待的行为。

“期待”只是存在于我们的脑子里面，很暧昧的想法，也正因此 Ruby 的 Type 可以很灵活，对比用 Class 来定义 Type 的方式会有很多限制。

对比 Nominal typing，我（Matz）更喜欢 Go 的 Interface，也就是Structural Subtyping这种方式。

在上面的例子中，上面三行定义一个包含Write方法的 interface LogDst，下面三行的 log 函数接受两个参数LogDst和字符串mesg。在这个函数里我们只需要LogDst有Write的行为（方法）就可以了，它可能是输出到 standard IO、String，或者其他什么地方，我们并不需要关心它的内部逻辑。
Structural Subtyping 和 Duck typing 同样保持很好的灵活性，当然我（Matz）还是更喜欢 Ruby 的 Duck Typing :-)。

DRY(Don't repeat yourself) 是 Ruby 另外一个重要原则。

为了避免不必要的重复，我们不会在程序写实际上不需要的东西，也就是说 Ruby 程序的运行不依赖于 type annotations，因此我们就不需要它们，甚至要去除它们。

但是 Dynamic Typing 也是存在不少不足的地方。

在程序运行时能发现错误
error message 不友好，信息量少，下面可能是我们最熟悉但又“莫名其妙”的错误信息
如果测试覆盖不够，可能会有预想不到的 typing error
缺少文档，像 Ruby 这样没有类型的语言写程序的时候非常爽，但读程序的时候就可能有困难了，所以有些人会写下面这样的注释

可能会有人吐槽，最终不还是要把类型写出来吗。。。
但。。。无论如何还是不想指定类型，绝对不想。。。（Matz 特别强调两次，全场都笑了）

因为这样会降低程序的灵活性，但为了以后的维护，我们又希望有可读性好的文档。
除了把类型信息像刚才那样写在注释外，还有另外一个做法是把他写在文档中。把类型写在文档里，但实际程序又不会做类型检查，到头来实际两边都没有讨好。
至少对 Ruby 来说 Type Annotation，Mixed/Gradual 都不是好主意。

正是因为还有以上种种问题，Ruby 还有很多改进的空间，

并且我们作为一个工程师应该要主动去解决这些问题。

有些人提出了 Static Typing with Type Inference的解决方案，但这个方案还是没能解决静态类型不够灵活的缺点。
又有人提出 Gradual Typing 或者 Optinal Typing 的解决方案，但这两种类型实际还是静态类型，因此灵活性这个问题还是没能得到解决。
Ruby 需要除上面以外其他的什么东西，一种像 Static Typing 这样进行类型检查，但又像 Duck Typing 这样灵活的类型。

暂且就把她叫做 Soft typing。

Soft typing 是一套用行为来定义的 Type System。

所谓行为就是一组的方法和参数数量、类型等。

回到刚才日志输出的例子，Go 版本的 interface 其实可以让程序自动生成，并且我们写程序的时候也不需要关心 interface(Type) 的名字 (取名字对有些人来说是件麻烦事)，

因此我们只可以忽略这些细节，专注于程序开发。（Happy Programming 的真谛）

例如，我们可以把 Type 信息搜集起来，就像放到数据库中一样。然后，我看可以从这个数据库中获取 Type 的定义和 Type 行为（方法）。
我们也这些 Type 信息看做是一种表达式（expression），

例如，我们可以检查当把 A 表达式赋值给 B 表达式时是否兼容。

我们也可以检查某个类型有没有对应的方法。

这样的做法也许并不能做到 100% 的类型检查，但还是比之前一点都没用要好。

如果找不到对应的类型信息，由于本来就是 dynamic typing，那么我们就退回到 dynamic typing 就可以了。

有两种方式实现 Soft typing。

一个是利用 ad-hoc type 的信息。
例如，有 a 表达式（也有可能是变量），我们期望她有 gsub，slice，map 三个方法，如果找不到有对应的 class 满足这个条件的，那就抛出错误信息。

但对于在运行时不断动态添加或修改的方法，这种检查方式就无能为力了。

另外一个是在运行时搜集类型信息，

特别是在测试的时候，

一般 Libray 或者 Gem 都会进行测试，那么我们可以在测试的同时，建立类型数据库。
这样我们就可以在发布 Gem 的同时，以某种方式一起创建和发布与之对应的类型数据库。

IDE 也可以利用这些 Type Database 的信息，让我们可以构造更加有效率、聪明的开发环境。
可惜的是在先阶段以上这些暂时都还只是构想，我们还不能用到。

所以让我们一起期待 Ruby3 吧！

最后，我们（Ruby committees）有一个很重要的信息传递给大家，我们是非常重视开发者的。

我们不会对 Dynamic typing 的“缺点“视而不见，或者叫开发者多做测试就了事，而是希望努力的改善 Ruby，让开发者有更好的开发体验。

关于 Ruby3 什么时候发布，目前还是不知道。。。

从 committee management 的角度来看，开源软件一般没有所谓的 dead line，也没有很明确的 road map，至少对于 Ruby 这个项目来说没有。但如果什么都没有又很难开展工作，因此我们对 Ruby3 的开发指定了 3 个目标。

就像当年美国登月一样，也是先定了一个困难、远大的目标，然后大家一起为之努力，最后成功。
那 Ruby3 的三个目标什么时候才能实现呢？我（Matz）希望在下一次的日本奥运会的时候。。。

虽然 Ruby3 还”遥遥无期“，但 Ruby 前进的脚步是不会停止的。

我们会一直不遗余力的帮助广大开发者在编程中找到乐趣--Happy Hacking！