#9 楼 @stephen 这个问题主要看微信对单页的支持功能，微信在 6.2 以上版本支持还可以，我在 八十二十 上使用，会遇到一些问题但都能按我提到的方法解决。

@yue @martin91 宣传以 RubyChina 此帖为入口，19wu 为报名通道~

#6 楼 @leiz_me 避免在 body 里面做 dom 操作，尽可能放在 JS 文件里处理。如果有时候不得不用 ( 比如某些第三方插件 ), 就按我文章里面的办...

#2 楼 @pinewong 你可以用 mina deploy -S 来查看一下具体的 git 命令，然后针对性执行一下，这样来查明原因。

if [ ! -d "/home/ruby/wblog/scm/objects" ]; then
  echo "-----> Cloning the Git repository"
  git clone "[email protected]:windy/wblog.git" "/home/ruby/wblog/scm" --bare
else
  echo "-----> Fetching new git commits"
  (cd "/home/ruby/wblog/scm" && git fetch "[email protected]:windy/wblog.git" "master:master" --force)
fi &&
echo "-----> Using git branch 'master'" &&
git clone "/home/ruby/wblog/scm" . --recursive --branch "master" &&

      echo "-----> Using this git commit" &&
      echo &&
      git rev-parse HEAD > .mina_git_revision &&
      git --no-pager log --format='%aN (%h):%n> %s' -n 1 &&
      rm -rf .git &&
      echo

类似于这样。

七牛 carrierwave 插件 https://github.com/huobazi/carrierwave-qiniu, 由 @huobazi 提供。

又拍 carrierwave 插件 https://github.com/nowa/carrierwave-upyun

完全没有必要自己再处理。

你到服务器上手动 git clone xx 试一下，应该就发现问题了。然后自行解决一下。

#2 楼 @hww 极易踩中

@nong mobx-react-native-template 还在进一步整理中，就被你拉出来了

Flux 非常繁琐，Redux 比较繁琐，Mobx 是中小项目的良药。尤其是 React Native 下。

用 next 来取代 return

Ruby 社区基本都是 Rack based 的 web 框架。

Node 也基本都是类 Rack based的。这种架构的好处是特别简单，很多插件可以复用，缺点是调用栈会很深。优化成本高。现在好像还没有成功的非 Rack 架构的 Ruby web 框架。

@peter 可以参考一下项目里的 composer.rb

一般直接用 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 不影响加载。