为何不考虑基于 systemd 的方案?
@huacnlee 好!
Ruby 2.3.3 已经发布了 2.3.2 发现功能有 Bug
最近面试了很多 Java 程序员,太刷新三观了。
共同特点就是 普遍连 Java 语法都不懂,问下 final
是干啥的可以倒下一片人。对于技术领域的知识,基本仅限于用过的框架,一离开框架就什么都不知道。我终于知道为什么很多 Java 站点都做得这么差了。
没有直播 不爽
@lgn21st 我现在特别喜欢 glide
很老的坑了 每次写这样的 callback 都对返回值小心翼翼
Costa 长期为 Shanghai Ruby Tuesday 免费提供场地,请各位到场的同学在 Costa 点杯饮料支持一下。
对啊 帖子太水
最近天天忙成狗
原来世界上有六种肤色啊
我觉得问题还是没解决 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 的效率可以大幅领先。
你后面的观点不是和我一样嘛。
明天就去南韩了 没法来。。
所以,在 HTTP/2 下,多次请求小文件(不用 server push)到底是不是比一次请求大文件更耗时?
在不考虑缓存的情况,也不考虑是否将不需要的文件打包进大文件的情况,也不考虑服务器处理的情况下,多次请求小文件和一次请求大文件的耗时在 HTTP/2 下应该是差不多的(小文件可能是差点,比如需要更多的发送 header,gzip 压缩多个小文件也不如压缩一个大文件,但这些差距应该不明显)。但是如果考虑进这些情况(即使没有 server push),我认为多次请求小文件在 HTTP/2 下优势明显,毕竟传输数据量减小,服务器虽然要处理多个请求,但是那些请求完全可以并发处理(HTTP/2 能在单连接的情况下并发大量请求),所以并不会消耗更多时间。
总的来说我的意思就是“通过 Nginx 就可以启用 HTTP / 2”是不够的,只能说看上去有点像,速度会有所提升,但是依然没有到达 HTTP/2 所能达到的高度(就像国内的 4G 网络,其实也没达到 4G 的网络的标准,比之前的 3G 肯定是快了很多,但依然不是真正的 4G,就酱)。
哦 对 确实不是一个问题
我看了那个文章,结合以前在 EMC 的经验,感觉作者将 Schema Migration 和 Data Migration 完完全全拆开肯定是不对的,当然 Rails 的做法本来也是不对的。这个问题的本质就是,都太不把 Migration 当回事了。
一般来说,一个 Migration 可能是这样的一个需求:如果是加 Column 同时赋予默认值,再设置一个 NOT NULL 约束,那么如果这几步一起做会导致整个数据库等待很长时间,期间表锁死(前提是已有的数据量很大),这显然是不合适的。因此比较好的做法是:
作者认为 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
我这里怎么没有这个问题?
刚刚下载 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 启用的 HTTP2 不是真正的 HTTP2,HTTP2 的重要功能都没办法用到。
Model.pluck(:id)
这是常识
@zhujinshou 最好的办法:移除 therubyracer,装一个 nodejs 即可。therubyracer 有严重的内存泄漏问题,不推荐使用(尤其是生产环境) 否则就是装上 libv8-dev,你是找不到 v8.h,根据 Debian 的包管理约定,装上 libv8-dev 就可以了。