• 为何不考虑基于 systemd 的方案?

  • @huacnlee 好!

  • Ruby 2.3.2 Released at 2016年11月21日

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

  • 程序员如何写简历和面试 at 2016年09月15日

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

  • 隔壁 #RubyKaigi 正在时 at 2016年09月08日

    没有直播 不爽

  • @lgn21st 我现在特别喜欢 glide

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

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

    👍

  • 对啊 帖子太水

  • 最近天天忙成狗

  • 原来世界上有六种肤色啊

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

  • 通过 Nginx 启用 HTTP/2 at 2016年05月09日

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

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

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

  • 通过 Nginx 启用 HTTP/2 at 2016年05月09日

    #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,就酱)。

  • 通过 Nginx 启用 HTTP/2 at 2016年05月08日

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

  • 通过 Nginx 启用 HTTP/2 at 2016年05月08日

    #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
    
  • 我这里怎么没有这个问题?

  • 通过 Nginx 启用 HTTP/2 at 2016年05月07日

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

  • 通过 Nginx 启用 HTTP/2 at 2016年05月06日

    #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
    
  • 通过 Nginx 启用 HTTP/2 at 2016年05月03日

    #8 楼 @steveltn

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

    这个就是回答

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

  • 通过 Nginx 启用 HTTP/2 at 2016年04月29日

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

  • Model.pluck(:id)

  • 这是常识

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