为什么要操作 DOM 呢？Turbolinks 的用法就是回到传统的 request/response cycle，每次把整个 body 替换掉呀。

不管你实际用不用 Rails，都应该学一下它，尤其是它背后的设计思想。

谢谢各位。暂时决定先用 ActionCable 来实现一个原型了。如果遇到性能问题再往 Ejabberd 迁移。

#15 楼 @sunfjun 这个东西的主要意义不是免费，而是自动化。

安利一下自己的 HTTPS-PORTAL，差不多就是这些东西，不过包装成 Docker container 适合和 docker 部署的 app 一起使用。

#33 楼 @ibachue 哦，我没想到这一层。server push 实际上做到了下载和处理的并行化，这点打包是做不到的。 我明白你的观点，但你字里行间让我感觉你认为不完全的 HTTP/2 开启了没有意义，这是我表示反对的地方。

#29 楼 @ibachue

我的意思是如果“多次请求小文件和一次请求大文件的耗时在 HTTP／2 (without out server push) 下应该是差不多的”，那么通过 server push 来减少 request 数量的提升就不明显。因为 server push 实际上就相当于一个更聪明、粒度更细的、缓存 overhead 比较小的把多个小 request 合并成一个大 request 的方法。

我的观点 Nginx 启用的 HTTP/2 虽然没有达到 HTTP/2 的最大性能，但是以最小的配置达到了显著的性能提升，比没有强。

#27 楼 @ibachue 可能是我理解不对，但是你这句话和你上一条回复好像矛盾了。 所以，在 HTTP/2 下，多次请求小文件（不用 server push）到底是不是比一次请求大文件更耗时？

我认为是这样的，HTTP/2 下，多次请求小文件也是更耗时的。对此，比较优秀的解决方法是用 server push。但是如果 app 端还不支持，用 assets pipeline 打包也比什么都不做好。启用 Nginx 上的 HTTP/2 只需要改动两三行 Nginx 配置，是目前最方便的提升性能的方法。而且在这种状态下，assets pipeline 打包依然比不打好。以后如果方便或有精力，当然可以换掉 assets pipeline 的打包，换用 server push。

#24 楼 @ibachue 那如果用 requirejs 加载大量小型 js 文件难道不需要吗？Asset pipeline 的打包不是可以节省这部分时间么？ 虽然有 overhead，但统计上并不严重。

#22 楼 @ibachue 如果在 HTTP/2 下，加载大量小文件所花的时间开销很小，可以忽略的话，那么为什么还需要用 server push 把这些文件预先 push 过来呢？

#20 楼 @ibachue 部分 assets pipeline 的功能和 sprites 不再需要了，但是我不觉得留着它们会帮倒忙。 Server push 可以先不用。

我认为 HTTP/2 主要的功能：压缩和节省 TCP 通道的作用是可以马上使用的。我试验下来在 Nginx 上启用 HTTP/2 后速度提升立竿见影。

至于 Rails 和 Nginx 之间的通信还是 HTTP 1.1，本来在同一主机上 TCP 握手就很快，性能瓶颈不在这里。

#13 楼 @ibachue

这些优化是指什么呢？ HTTP2 的主要优点不就是可以把多个请求放在一个 TCP connection 中，并且提供压缩么？这并不需要 app 端做任何改变，Nginx 里 enable 不就行了？

#1 楼 @ibachue 怎么说？

#2 楼 @martin91 我用这个小工具来管理耗时很长的 shell 命令。先 alias 成 notify。

some command ; notify 完成了提醒一下 some command && notify 成功的话提醒一下 some command || notify 失败的话提醒一下

不过 Windows 现在支持 Linux binary 了，这个情况可能就快改变了吧！

#1 楼 @nightire 是不是说 package.json 其实相当于 Gemfile.lock。而实际上不存在对应 Gemfile 的文件？

我们还是没有找到方便的 zero downtime deploy 的办法。

对于不需要这个特性的项目，docker-compose 已经做的不错了。我们的 测试 和 QA 环境是用 docker-compose 部署的。GitHub 上代码一旦更新，会 trigger DockerHub 的 autobuild，然后 compose 就可以引用了。

我们还有一个 compose 文件，提供了完整的 development dependency。在 docker 里面开发 Rails 项目还是有点麻烦，但是我们的 development compose 包含了所有的依赖，比如 PG、redis、elasticsearch 和我们自己的 micro service 等。新人搭建开发环境非常快速。

Staging 和 production 是用 Ansible 来 provision 的，Ansible playbook 一跑，然后就可以直接 cap deploy 了。还挺好用的。

看 log 去。碰到问题不要猜。

我们刚实现了基于 websocket 的 push notification…… 请问 Ruby-China 的 push 是如何实现的？

#31 楼 @alex 嗯，这个 scenario 确实有道理。我再仔细想想。

#29 楼 @alex 比如升级某个 gem 的版本？

另一个问题是，本来就用版本管理工具就能解决的问题，需要污染代码逻辑来解决，得不偿失。用 feature branch 的话，经常 rebase master 就可以了，merge 时并不会有大冲突。

#26 楼 @alex 不是所有 feature 都可以 toggle 啊。

#24 楼 @alex 可是在 truck 上进行开发的话，如果我在本地开始开发一个 new feature，由于要保证 master 可部署，所以我在该 feature 开发完成之前也完全无法 push 到 master 不是么。那么，它如何能防止 long lived branch 的产生呢？

非常讽刺的，我目前在做的项目有相反的问题。logicless view 与非常 thin 的 controllers，复杂的 models；测试用例过多甚至有重复；code review 流程过于繁琐；不愿依赖 gem 而是宁愿手写徒增负担…… 导致整个开发进度缓慢。

#44 楼 @academus 注册 githuber 时给我明文发送了默认密码，我希望那不是明文保存的吧？

我在原帖下面回复了，不过看这里讨论比较多，还是放到这里来吧：

我想问下如何才能做到不同的人同时在 master 上进行开发。毕竟任何人一旦把代码 clone 到本地，本地 master 和 origin/master 就形成了两个不同的 branch。当你在本地 master 上开发完毕想 push 到 origin/master 时，别人的代码说不定已经 push 进来了。这时候你的本地 master 就相当于一个 feature branch，只是换了一个名字而已。

#1 楼 @hxh1246996371 客户端还称不上特别好用，不过配好后就不用管了。

全 SSL 会影响一点点，开了 HTTP2 后会好不少，不用特别担心吧。

这是一件很坑的事情，MySQL 的默认语言是瑞典语！因为这是一个瑞典人无聊时开发的，连起名字都很随意——他的大女儿叫 My ……

他小女儿叫什么呢？Maria！

我觉得 Angular 是成也双向绑定，败也双向绑定。 双向绑定好处不多说了，大家都知道，写代码确实可以方便很多。 坏处就是整个页面的加载逻辑不再是“面向过程”的了，更接近一个反馈环。一些页面元素依赖另一些页面元素，并在不断调整平衡。页面并没有一个执行完 js 达到稳定的状态，而是不停地检查各个变量之间的关系。我们在用的时候确实为此碰到了一些很麻烦的问题，主要是第三方服务方面的。

另外我个人觉得 Angular 在前端再建立一整套 MVC 并没有什么必要。听说 React 很不错，但是我们现在用着 Angular 了，换起来比较麻烦。

We are an international company. Our site comes with two copies, one globally and on in China. While we hosted our global sites on Heroku/EC2/S3, we had to use a VPS in China because we couldn't find a Heroku equivalent. The VPS provider we chose was GrandCloud（盛大云）. Combined with their own cloud storage solution (S3 equivalent), it worked pretty well. We hired someone on taobao to help us with 备案。