为何不考虑基于 systemd 的方案？

@huacnlee 好！

Ruby 2.3.3 已经发布了 2.3.2 发现功能有 Bug

最近面试了很多 Java 程序员，太刷新三观了。 共同特点就是 普遍连 Java 语法都不懂，问下 final 是干啥的可以倒下一片人。对于技术领域的知识，基本仅限于用过的框架，一离开框架就什么都不知道。我终于知道为什么很多 Java 站点都做得这么差了。

没有直播 不爽

@lgn21st 我现在特别喜欢 glide

很老的坑了 每次写这样的 callback 都对返回值小心翼翼

Costa 长期为 Shanghai Ruby Tuesday 免费提供场地，请各位到场的同学在 Costa 点杯饮料支持一下。

对啊 帖子太水

最近天天忙成狗

原来世界上有六种肤色啊

这个女程序员绝对是传奇 http://jingxuan.guokr.com/pick/18251/?from=timeline&isappinstalled=1

我觉得问题还是没解决 503 错误仍然不稳定的出现（即使第一次下载正确第二次依然 503，显然没有动用到缓存）暂时切换到 ruby.taobao.org

#31 楼 @steveltn 我认为你对 server push 理解有误，assets pipeline 是将多个 response 内容合并为一个 response 发出，response body 在没有完全下载完毕前无法使用。而 server push 是将多个 response 一起返回，只要一个 response 下载完毕，其 body 部分就已经可以处理，其它部分继续下载即可。所以只要当 html 部分下载后，浏览器就可以开始处理，当处理完毕后准备下载 JS 和 CSS 文件的时候，这些文件都差不多已经下载完毕了。这使得 server push 的效率可以大幅领先。

你后面的观点不是和我一样嘛。

明天就去南韩了 没法来。。

#28 楼 @steveltn

所以，在 HTTP/2 下，多次请求小文件（不用 server push）到底是不是比一次请求大文件更耗时？

在不考虑缓存的情况，也不考虑是否将不需要的文件打包进大文件的情况，也不考虑服务器处理的情况下，多次请求小文件和一次请求大文件的耗时在 HTTP／2 下应该是差不多的（小文件可能是差点，比如需要更多的发送 header，gzip 压缩多个小文件也不如压缩一个大文件，但这些差距应该不明显）。但是如果考虑进这些情况（即使没有 server push），我认为多次请求小文件在 HTTP／2 下优势明显，毕竟传输数据量减小，服务器虽然要处理多个请求，但是那些请求完全可以并发处理（HTTP／2 能在单连接的情况下并发大量请求），所以并不会消耗更多时间。

总的来说我的意思就是“通过 Nginx 就可以启用 HTTP / 2”是不够的，只能说看上去有点像，速度会有所提升，但是依然没有到达 HTTP／2 所能达到的高度（就像国内的 4G 网络，其实也没达到 4G 的网络的标准，比之前的 3G 肯定是快了很多，但依然不是真正的 4G，就酱）。

#26 楼 @steveltn 确实不需要啊。HTTP／2 最大的特点就在于 在这个协议下，大量单个小文件和一个大文件在传输时负载没什么区别，但是大量小文件 cache 容易，开发也方便，不需要加载暂时用不到的文件，所以优势就体现出来了。

#23 楼 @steveltn 加载小文件的时间开销不止有传输时间啊 HTML 传输过来以后要解析，才能获取到要加载的小文件的地址，JS 可能还要执行才能获取到依赖的其它 JS 文件的地址，服务器收到了静态文件的请求也要处理，这些都要时间啊。如果他们还在解析的时候，所有的文件就已经主动推送完毕了，不是就节省了很多时间嘛。

#2 楼 @hooopo

哦 对 确实不是一个问题

我看了那个文章，结合以前在 EMC 的经验，感觉作者将 Schema Migration 和 Data Migration 完完全全拆开肯定是不对的，当然 Rails 的做法本来也是不对的。这个问题的本质就是，都太不把 Migration 当回事了。

一般来说，一个 Migration 可能是这样的一个需求：如果是加 Column 同时赋予默认值，再设置一个 NOT NULL 约束，那么如果这几步一起做会导致整个数据库等待很长时间，期间表锁死（前提是已有的数据量很大），这显然是不合适的。因此比较好的做法是：

1. 添加 Column，但没有默认值，这样会快很多。
2. 完成之后，再给 Column 设置默认值，这样新的数据在这个 Column 上就有默认值了，之前的旧数据依然没有。
3. App 代码中已经可以开始使用这个新 Column，但必须能处理旧的数据，也就是该 Column 为 nil 的情况。
4. Data Migration 开始，为所有已有数据对该 Column 设值，这一过程通常很长，需要脚本满足可以随时暂停重启的需求（这样白天高峰期可以不 migrate）。
5. Data Migration 结束后，添加 NOT NULL 约束，所有 Column 现在都有值。
6. App 代码中移除对旧数据的处理逻辑。

作者认为 migration 需要很长时间这个说法肯定是正确的，现有的 migration 代码没有测试也确实不好。但是作者将 Schema Migration 和 Data Migration 完全拆开这个做法肯定不对，事实上，从上面的例子中可以发现，Schema Migration，Data Migration 和 App 代码相互依赖，我恨不得把 App 代码的迁移也写在 Migration 里（否则就要记得去更新代码然后重新部署），怎么可能将其分离？

所以我觉得 Rails 可能的改进点是，多段 migration，例如

class SplitNameMigration < ActiveRecord::Migration
  change 'phrase 1: migration schema' do
    # add column
    # set default value for new data
  end

  change 'phrase 2: data migration', transaction: false do
    up do
      # migrate data one by one
    end
    down do
      # rollback data one by one
    end
  end

  change 'phrase 3: migration schema again' do
    # set 'not null' for the column
  end

这个改进要求 Rails 支持 migration 存在多段并且要在数据库中记录当前 migrate 到了第几段，第二段中的 transaction: false 表示执行这段 migration 时不要自动添加 transaction，脚本自行处理 transaction，避免在中间暂停时之前迁移的数据 rollback。

当然这个改进依然不够，因为一般来说总是等 rake db:migrate 执行完毕后才启动 Rails server，但不可能等待 data migration 全部结束后才启动 Rails server，可能的做法是，在 phrase 1 结束后就自动让 Rails Server 启动，而在 Phrase 3 结束后自动控制 git 版本让它 checkout 出一个包含了对该 column 的 presence 做检查同时移除旧代码的处理逻辑的新版本然后再重启 Rails Server 就比较好了。当然这对 migration 的要求好像太高了？

我平时一直是用 reversible 做 migration 的，效果很好

class SplitNameMigration < ActiveRecord::Migration
  def change
    add_column :users, :first_name, :string
    add_column :users, :last_name, :string

    reversible do |dir|
      User.reset_column_information
      User.all.each do |u|
        dir.up   { u.first_name, u.last_name = u.full_name.split(' ') }
        dir.down { u.full_name = "#{u.first_name} #{u.last_name}" }
        u.save
      end
    end

    revert { add_column :users, :full_name, :string }
  end
end

我这里怎么没有这个问题？

#21 楼 @steveltn 帮倒忙是指，本来将所有资源打包在一起就是因为建立 HTTP／1.1 新连接效率低下，一旦用 HTTP／2 就没有这个问题，反而打包的两个缺陷体现了出来，一个是明明暂时不需要用到的资源也被下载，浪费了网络，二是缓存颗粒度变大，命中率下降。 如果不用 Assets Pipeline（的打包特性），前端的代码就要发生变化，比如说应该使用 requirejs 这样的库来并发加载大量小型 JS 文件，Rails 也应该对此提供 helper。 Server Push 不用，HTTP／2 就有一半好处你没有体会到了。

#19 楼 @steveltn 主要体现在两点，1. 现有的诸多基于 HTTP／1.1 而设计的优化特性必须被废除，在 HTTP／2 下，它们不仅起不到优化的作用，反而还在帮倒忙，一个显而易见的例子就是 Assets Pipeline，还有例如于将多个图标合成一张图片的技术，长链接也是。2. 另外就是 HTTP／2 的 Server Push，需要 app 端主动告知服务器端即将推送给客户端的数据。

#7 楼 @huacnlee 又开始出问题了

Fetching source index from https://gems.ruby-china.org/
Network error while fetching
https://gems-ruby-china.b0.upaiyun.com/quick/Marshal.4.8/actionmailer-4.2.5.2.gemspec.rz

@huacnlee

刚刚下载 unf_ext 这个 gem 也出现了错误

gem install unf_ext -v '0.0.7.2' --verbose
Getting SRV record failed: DNS result has no information for _rubygems._tcp.gems.ruby-china.org
HEAD https://gems.ruby-china.org/api/v1/dependencies
200 OK
GET https://gems.ruby-china.org/api/v1/dependencies?gems=unf_ext
200 OK
Getting SRV record failed: DNS result has no information for _rubygems._tcp.gems.ruby-china.org
Downloading gem unf_ext-0.0.7.2.gem
GET https://gems.ruby-china.org/gems/unf_ext-0.0.7.2.gem
302 Moved Temporarily
GET https://gems-ruby-china.b0.upaiyun.com/gems/unf_ext-0.0.7.2.gem
Fetching: unf_ext-0.0.7.2.gem (100%)
200 OK
ERROR:  Error installing unf_ext:
    invalid gem: package is corrupt, exception while verifying: undefined method `size' for nil:NilClass (NoMethodError) in /root/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/cache/unf_ext-0.0.7.2.gem

#8 楼 @steveltn

然而 Rails 和 nginx 之间还是 HTTP/1.1

这个就是回答

HTTP/2 的功能远远多于 1.1，因此 Rails 不为 HTTP/2 做优化，或者你的应用不为 HTTP/2 做优化，就不能被认为是真正用了 HTTP/2（还增加各种调试负担和测试负担）。

一直感觉通过 Nginx 启用的 HTTP2 不是真正的 HTTP2，HTTP2 的重要功能都没办法用到。

Model.pluck(:id)

这是常识

@zhujinshou 最好的办法：移除 therubyracer，装一个 nodejs 即可。therubyracer 有严重的内存泄漏问题，不推荐使用（尤其是生产环境） 否则就是装上 libv8-dev，你是找不到 v8.h，根据 Debian 的包管理约定，装上 libv8-dev 就可以了。