https://github.com/phusion/traveling-ruby

这是 Passenger 团队做的打包工具，不知为什么停止更新了。

个人没活路。公司接入支付宝和微信两个就行了。

脚本里做了太多事。

jekyll

别用小众的工具

@ 这么多人是求屏蔽么？

两个建议让部署更轻松：

1. 用源里的 ruby，避免处理 path 问题，ubuntu 16.04 源里的 ruby 已经是 2.3。
2. 用 cap 而不是 mina，mina 不支持多机部署和角色区分，扩展有问题。

Ruby 元编程

https://github.com/chloerei/active_service

SVN 也不是不能用。

我觉得楼主应聘应届产品的还不到可以给程序员简历提建议的程度。

可能有 bug，可以到 GitHub 提 PR。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

order by rand()

这不是解决，这是欺骗浏览器，会产生漏洞…

webpack 开个 proxy 转发。

第一次写出来的实用程序就是爬虫，后来一直对爬虫没兴趣，因为不想做一个基于爬别人的数据的应用。

Python 能做的 Ruby 也能做，Python 也有 GIL ，Python 跟 Ruby 一样慢。

要说 Ruby 缺什么，就是缺对某个领域感兴趣又能把项目完成度做得很高的人。

schema.rb 带来的好处：

1. 更快的 db setup。
2. 一目了然的数据库模式。
3. 及早发现冲突。
4. 符合约定，易于上手。

没有 schema.rb 带来的问题：

1. db:migrate 越来越慢，影响开发和 CI。
2. 需要在本地跑一遍 migration 才能看数据库模式。
3. 发现冲突的时机延后到 CI 或更晚。
4. 违反约定，让人迷惑。

如果这不能说服楼主，我感觉也没什么办法阻止楼主干傻事了。

去掉 scheme 后，明显劣势是没有地方看当前数据库有什么表和字段了。当然，可以学 discourse 那样把 schema 导到 model 注释里，等于丢掉自带的东西引入一个依赖。

我找到 discourse 为什么不 check-in schema.rb 的讨论 https://meta.discourse.org/t/schema-rb-vs-migrations/14983

他们似乎基于这两个理由

1. schema.rb 不能用 db 的本地特性

这时候应该用 structure.sql。

2. schema.rb/structure.sql 依赖于开发的本地数据库，可能会 check-in 不合版本的修改

开发环境和生产环境应该一致，用 docker 来维护。

至于开发者提交了坏的 structure.sql，应该提交者自己 review 和上游开发者 review，而不是大家都没有一个完整版的 schema，同时期待线上不会出问题。

schema.rb 有冲突不处理，ignore 掉冲突就消失了吗？

设想有一个 table：

create_table :users do |t|
  t.string :name

  t.timestamps
end

这时分出两个分支，同时对 :name 进行修改：

# branch-1
rename_column :users, :name, :display_name

# branch-2
rename_column :users, :name, :full_name

如果有 schema.rb，在合并的时候会当即发现有冲突，两个分支都对 schema.rb 的同一行进行了修改，需要立即处理冲突。

如果没有 schema.rb，冲突会延后到执行 migration 的时候。如果有 CI 它会报异常，如果没有 CI，源码没有冲突，那就要拉下来 migration 的时候才发现冲突，此时代码已经被 merge 了。

schema.rb 能让冲突更早发现，更容易处理。

我就见过一个项目重跑 migrate 之后和线上数据库 schema 不一致，不知道过程做了什么，也没有把 schema.rb 加到 git 里，开发一直基于错误的 schema 做然后上线出问题，最后把线上的 schema 导出重新加回。schema 有冲突就应该当即解决冲突。

现在 homeland 没有 ignore db/schema.rb https://github.com/ruby-china/homeland/blob/master/.gitignore

运行 migration 的时间不是取决于表数而是 migration 的数量，看看 discourse 的 migration 把字段改了又改，重跑一次不会很浪费时间吗？ https://github.com/discourse/discourse/tree/master/db/migrate

discourse 不算好的 Rails 范例，创始人用 .net 的风格编码，用前后端分离，不是遵循 Rails 最佳实践的项目。

要，用来看当前有什么字段。

喜欢逻辑和模版分离可以用 Ember.js。

现在趋势是逻辑、模版和样式放在一起，预编译成 JavaScript 然后以组件为单位 import。

有，点进个人页面。

http://guides.rubygems.org/

去看看前端社区关于 server side render 的讨论，你就会怀疑前后端分离是为了什么。

至少 Github 就是这么发展起来的。

现在不是流行 microservice 么，每个 service 可以是单体应用也可以是更多 seivice 组合，关键是你不用关心 service 是怎么实现。

纯血前端社区心态才是封闭，非 JavaScript 实现不用，非 client side 不用，结果现在要搞 server side render 和同构。相比之下 Rails 拥抱 webpack 才是开放。

https://github.com/ruby-china/the-rails-doctrine/blob/master/README.md#%E9%87%8D%E8%A7%86%E6%95%B4%E5%90%88%E7%B3%BB%E7%BB%9F

Rails 默认用啥我就用啥。

redis 也是远程调用，细粒度的缓存是否有用还要实测。