一般直接用 redis 来共享多进程数据。redis 可保证原子读与写。

@vincentjiang #2 楼 @seaify 已由国外友人提供了一些英文支持，现已支持英文版。

#80 楼 @grantbb

#4 楼 @didme 在 js 里初始化 wx 时开启 debug 模式，慢慢调吧。

@didme 模拟器不支持微信支付的测试，需要用自己手机来测试。

#72 楼 @sefier 你怎么实践都可以。我这里采用 figaro 达成一样的效果即可。而且布署时也提供了最佳实践. #75 楼 @grantbb 这里只提供一种 rspec 测试方案，不适合就不要选了。建议用 rails5 自带的生成器，已经很符合你的口味了~

Ruby or Rails? You Scored: 9 / 10 Ranking: Ruby expert!

#69 楼 @gazeldx 嗯，基本同意，但 simple_form 替换成本很低，很适合写后台用，所以还是可以接受的。

赞，已经注册百分之八十公司： https://ruby-china.org/80percent

#66 楼 @alvin2ye 对于配置文件，安全仅有一点：不要提交任何敏感信息到服务端。所以 rails-template 是添加了一个 config/application.yml.example, 随后由开发者自行复制一份为 config/application.yml, 而此文件在 git 中是忽略的。这是 rails-template 的集成方式。

在不同的生产环境，config/application.yml 由发布者在 mina setup 时自行配置即可。rails-template 在随后的发布过程自动软链接它，保证每次新的发布使用同一份配置。简明清晰的流程。

dotenv 建议开发者提交一些配置到 .env, 和提交 .env.production 之类的，不是配置的最安全做法，只要你提交过敏感，一旦源代码泄漏，就有黑客能轻易攻击你。所以我说安全性会降低。我在上述的解决方式中是一种简明清楚的手段。这也是很多开源项目类似的手法，例如 ruby-china.

相对来说，我会选择简明，安全的手法去集成。于是使用了 figaro

#64 楼 @alvin2ye 两个差不多，相对来说， figaro 更安全。rails-template 集成的方式更安全。

#26 楼 @zhangsm 嗯 有可能会 现在还不确定 其实我们希望定位为纯工具 作者反而可以仍然使用原的渠道而利用八十二十来发布付费文章。这里我们还不确认。

#24 楼 @zhangsm 好问题。既然是用来写作需要付费的文章的工具，当然是写 "有价值的" 文章。所以：

1. 作者觉得有价值，才会写这篇文章
2. 读者觉得有价值，才会购买这篇文章

八十二十目前只是工具，跟百分之八十公司没有关系。

#21 楼 @vman #22 楼 @fuyang 谢谢支持

#57 楼 @perect 你可以选择集成 cancancan 或 pundit. 看自己需求。关于你提的加注释的方式，我倒觉得有时间把 wiki 完善一下更好更清晰。已经列在 README 的 TODOLIST 里了。

#55 楼 @qx devise 不会集成，已经考虑过了。 simple_form 早就集成了，不多说了。至于 slim 是见人见智的事，不再调整了。@ashchan 谢谢你的经验分享。

#61 楼 @debugger 可一并去掉 application.yml 与 application.yml.example 中的配置与 config/initializers 中的即可 :)

#52 楼 @samport #53 楼 @ashchan 明显是高的，slim 让你少码很多无效代码就够了。反过来说，混写 html 与 js 是个 bad smell 的事情，避免掉，如果实在避免不了，那就当前文件用 erb, 混用 slim 与 erb 不是什么问题。

#49 楼 @hww 好主意，考虑中： clearance issue

ActionCable 不影响加载。

#2 楼 @huacnlee 早上更新 rails 5 的时候发现的，作者已经合入了，还合了我的 PR

#42 楼 @seaify 看起来还不够完善。不过很轻。

#40 楼 @pzgz 是的，所以我在一开头就说它是 "固执" 的。正如 @martin91 所说，rails-template 是选择困难症患者的良药。我觉得没必要在这里纠结这个高大上的 "思想". 如果有好的 gem 方案集成建议，我们为何不探讨技术呢？

#38 楼 @pzgz 恰恰相反，这个模板是为非初级工程师设定的。当然可以依靠这个思路搞自己的项目模板。但 rails-template 的目的就是选择一套 "最好" 的组件。避免选择症。所以选择 gem 会仔细考虑：

1. 非常必须的 gem 才会被考虑
2. 有类似选择时选择尽可能简单易懂的那一个
3. 最多应用的

换言之，它很 "固执", 但够快速，有时候会强推作者的经验，会有偏见。但绝不坑你。更适合中级工程师想进一步改进项目构建之用。我觉得是符合 rails 的一贯思想的中国开发者版。

#32 楼 @martin91 好东西啊，不过就不默认集成了，需要的话自行加。这一套差不多够了

#7 楼 @huacnlee 已经添加了 simple_form, bootstrap 暂时用 3. 一是 simple_form 对其支持还要改进，也等它正式版出来。

#28 楼 @freefishz 欢迎使用 :) 有问题找我，我尽快解决~ #29 楼 @vincentjiang 这个是小招 :)

#25 楼 @holysoros 好建议，先记下！

#21 楼 @huobazi 又拍的 backend 端可以用 qiniu :)

#16 楼 @lazybios 嗯 起初我也一直用的这个 rails-composer, 不仅选项多，处理完依然有不少组件要改。所以才动手搞了本帖这个项目。

#17 楼 @rdongxie 是的。