过来支持一下咱深圳靠谱的团队。

跟 @chrisloong 有很多次交流了，友好速搭是非常踏实的团队，电商 SaaS 方向也是一个以后很可能爆发的好方向。有想法来深圳的朋友也可以找他们聊聊看。

DRb 分布式解决之道 [https://ruby-china.org/topics/5550], 之前写过的一个文章。

DRb 也没那么简单，但主要的问题是 Ruby 很少被用来写分布式的应用，Ruby 优点在于快速实现，分布式讲究的是稳定与效率，个人感觉还是语言适用度的问题。

DRb 会强制你只能用 Ruby 对象来远程传递，这样就全部要用 Ruby 做了。

@ihuche

@jasl

:plus1:

@duobei 有义务帮助 Ruby 圈子，也帮助靠谱的东家

可以看一下 lina, Rails + jbuilder 下的 API 生成方案，也许能有所收获

@lgn21st 要处理下这个哥们 xsstestxss

@caiqinghua 可以用 <%= xx %> 来实现，也可以用 ajax 来取。xx 可以用对应的 controller 中取。

@aidewoode 你可以直接问创始人 @caiqinghua

@lgn21st 看下是否合规:) @caiqinghua

@duobei 好活动！多谢提醒:)

@linjunzhugg 嗯，这是 Rails Reload 的机制，你应该把整个代码放在 initializers 里或者 lib 里。

#18 楼 @kewin 你不想看就可以忽略招聘节点就好了。招聘多说明 Ruby 圈子在快速发展，是个好兆头。

#29 楼 @kevinclcn #30 楼 @suupic 回滚直接用 ln -s current ../realease/xx, 然后重启 rails container 就可以了。

如果有数据也需要回滚，那需要单独写个 task, 但这种情况非常少。

#26 楼 @lgn21st 也能支持，我当时的结论是，最好的办法也是把 rails container 独立出来，这时用 passenger 还是 unicorn 都可以了。布署难度也就相当了。unicorn 热布署很吸引人:)

#23 楼 @lgn21st 我经常会布署一些小站，挂在一起方便，这才用 nginx + unicorn 布署很多小站。要是主要用来运营的，就要像你说的，分开布署会更靠谱。

#13 楼 @springwq 压压招聘贴的经:)

#22 楼 @peter 你这个设计还行，但

1. 丢掉了支持细化权限的 scope 的情况。
2. 把权限写死了，不够灵活。

对于很多情况，像你这样子就够了。不用基于角色。

#16 楼 @lgn21st 一个 nginx 反代多个 rails app 的话，unicorn 还是方便点。不过现在 puma 也很好哈。

#12 楼 @dddd1919 是直接与 current 目录的 path 一一对应的，这些建立软链接的命令都可以在 mina 的源码很容易找到。如果需求不满足，就可以自己写。

#2 楼 @huobazi 可以试试自己写一个对应的 task fix 一下。

#17 楼 @gazeldx 这跟需求有关，很多时候不用设计 roles. 直接基于资源来设计的系统适合于管理用户不多的情况。如果管理者很多，每一次创建管理者都要去选各种资源，这个就麻烦了，以后也无法统一调整权限。

本篇是讲基于角色的权限系统，所以就不多说不基于 roles 的权限设计了。

#4 楼 @quakewang 结论非常中肯，对于小规模应用来说，mina 很方便易用。对于它的相关插件，关注的人不多，成熟度还不够，有时候需要自己去折腾。

对于 mina-unicorn 重启的问题，我的解决方式与 @saberma 一致：在 unicorn 里面加上一个

before_exec do |server| # fix hot restart Gemfile
  ENV["BUNDLE_GEMFILE"] = "#{app_path}/Gemfile"
end

#8 楼 @a167651202 可以试试 mina-unicorn, 用热启动的方式就好了。

前几天已经看过了，赞个。

Growth Hack 概念在中文里还不火，不过有一期 teahour 有交流到： http://teahour.fm/2015/01/29/growth-hacking-in-strikingly.html

:plus1:

#15 楼 @killyfreedom 我觉得你没理解，在处理一些精细化权限 ( scope ) 时，必须查数据库，如何放得 redis?

@peter @killyfreedom 本质上 resources 已经存到内存了，比你两个说的存到 redis 与 yml 更好用 ( 支持 block 式的 scope 检查 )

#12 楼 @flowerwrong 比如一个用户列表，每个用户都会检查是否有修改权限。这样，cancan 就只能一个个查询了。

#4 楼 @killyfreedom 这个方案跟 cancan 是一致的，无法解决 N+1 查询问题。但可以用 N+1 查询的解决方案去尝试处理下。

#6 楼 @kayakjiang resources 基本只会加，不会减，所以写在文件里修改更方便，也只能程序员去定义资源。

如果你想完全自主控制 ( 比如在 UI 上 ) 资源创建，可将其放在数据库，但还要仔细设计支持 scope 的资源约束。