《Rails Tutorial》这本书吃透 60%~70% 的时候就可以了。

想要达到这个程度，需要把书里面的例子先重复做几遍，然后举一反三做点扩展的功能。

继续请教：保证开发环境和生产环境的一致性，解决的又是什么问题呢？

我的理解，这样做，通过保证开发与生产环境库、变量一致的手段，既方便了测试与调试，也降低了代码部署失败的风险，从而降低了运维成本，并为高级自动化的手段提供了更多可能。

说到部署，我用过 Git Hook，Capistrano 和 Docker 来部署 Rails 应用。最近确实产生了一个疑问：如果我不拆微服务，那么用 Docker 部署 Rails 的优势和成本究竟有哪些？

我只想要平静的生活

贴一下我项目里相关的配置：

deploy.rb

set :bundle_bins, %w(gem rake rails sidekiq sidekiqctl)

set :puma_rackup, -> { File.join(current_path, 'config.ru') }
set :puma_state, -> { "#{shared_path}/tmp/pids/puma.state" }
set :puma_pid, -> { "#{shared_path}/tmp/pids/puma.pid" }
set :puma_bind, -> { "unix://#{shared_path}/tmp/sockets/puma.sock" }
set :puma_conf, -> { "#{shared_path}/puma.rb" }
set :puma_access_log, -> { "#{shared_path}/log/puma.log" }
set :puma_error_log, -> { "#{shared_path}/log/puma.err.log" }
set :puma_role, :app
set :puma_env, -> { fetch(:rack_env, fetch(:rails_env, 'production')) }
set :puma_threads, [4, 16]
set :puma_workers, 4
set :puma_worker_timeout, 30
set :puma_init_active_record, true
set :puma_preload_app, true
set :puma_prune_bundler, true

namespace :puma do
  desc 'Create Directories for Puma Pids and Socket'
  task :make_dirs do
    on roles(:app) do
      execute "mkdir #{shared_path}/tmp/sockets -p"
      execute "mkdir #{shared_path}/tmp/pids -p"
    end
  end

  before :start, :make_dirs
end

Capfile

require 'capistrano/rvm'
require 'capistrano/bundler'
require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'
require 'capistrano/scm/git'
install_plugin Capistrano::SCM::Git

# Plugins
require 'capistrano/safe_deploy_to'
require 'capistrano/puma'
require 'capistrano/puma/nginx'
require 'capistrano/faster_assets'
require 'capistrano/sidekiq'
require 'sshkit/sudo'

你可以对照检查一下

恩恩是啊。所以我才说是滚雪球，就是有了核心业务，越滚越大的意思。

刚才摸索着配置好了阿里云的 CDN，发现比国内其他同类产品好用太多。

根本不用这么复杂，只要能把握住技术的商业价值就有足够的机会盘活生意，接下来就是滚雪球、搞增长的事情；生意越盘越大，自然能吸引到优秀的人来加入。

然而能做到这一点的 CEO 还是太少了，所谓“技术的商业价值”，如国内 BAT 等公司、国外微软、谷歌和雅虎等公司才是把这一点发挥的淋漓尽致。

哈哈巧了，除了 Ruby 那几本书，其他的我不是正在读就是已经读过。

非常赞同。

CEO 会直接决定一个因素，公司发展的驱动力，是技术还是业务；进而造成两方面影响，研发结构与产品品味。

如果是传统公司，IT 仅做业务支持，也就无所谓；如果是技术公司，这会直接影响到公司的命。

.......

够大

大哥语法错了... =。=

要不去 FLAG 感受一下。。

英文的没有问题啊～ 我先拜读、学习一下。

这样需要配别的什么东西一起用吧，否则谁来处理前端资源优化、压缩的任务呢？

我实在不想折腾前端，能省则省。

Turbolinks 的事件处理

不能好好的写$(document).on('ready', function() {})，要写成page: change，后来又改成page: load，最近升级到 Rails5，还要改写成turbolinks: load。

然而前端是我的弱项，从一个坑跳到另一个坑里，天知道我经历了什么……

当然，告诉了。

我一路自学 Rails，看到这个东西的时候就知道不能用。。

感谢！

我之前写的确实不对，这次受教了。

我先去参考一下 Homeland 的 Dockerfile。

嗯那就是我道行还不够深，先把 Dockerfile 写对了，再考虑用进去。

容器部署的调度工具我也是昨天才想到这个问题，脑子里转了一圈发现周围没什么好用的。至于提升运维能力，这得看公司发展，我自己心很大，但这不是我一厢情愿就能做成的事情。

没有，只是用 Puma 起了多线程。

是我没讲清楚。 我目前不用 Docker 是有原因的：

1. 微服务的拆分与持续维护的成本，在我看来是不可估量的。
2. 每次 Build image，会在 image 内部重新 bundle install，就有可能引起依赖软件的版本变化，就有可能引入未知的新的 bug，且排查成本较高。而这种 bug 在常规开发/部署的方式中几乎不存在，即使有也能很快定位到问题。
3. 在企业中不能脱离人员架构讲技术。我可以自己用起来 Docker，但总有人不是那么熟练；不论是培训、技术转型还是后期维护都会有成本，这种成本现阶段是完全不必要的。

docker 也有 docker 的成本，业务没那么复杂的时候，Docker 有点大材小用。

上面那段 nginx 的配置在 development 环境中如何体现？

难免扣除了印象分，今后共事会带有先入为主的看法。

公司缺人呗，想着有 x 年经验即使没什么出彩的也不会太差，没想到坑了。

Rails Guide 里有很清楚地讲到这两个用法的区别和使用场景。

然而提示了。