DJI 前景广阔，是少有的，在用 Ruby 开发核心业务的大型企业，并且相关应用的请求量很高，有挑战。可惜，招的人数不多。 如果来了深圳，进不了 DJI，别灰心，还有很多其它公司可选，比如友好速搭 。

是计算密集型的任务吧？ 我们也是用 Golang 重写了部分 worker，其实用 Java、C# 之类重写也可以，都会比 Ruby 省资源。

#16 楼 @soulspirit1229 这个阶段，肯定有机会，不仅是期权，还有可能拿股权。

#14 楼 @duobei 幸会幸会，IaaS 和 PaaS 方面了解还不够，以后有机会，请多多指教。

#10 楼 @xlgwr 欢迎聊聊，在深圳可以见面聊，不在深圳可以电话聊。

#11 楼 @duobei 那次是我去分享的，你是云计算行业的？

#8 楼 @hrz3424 我们是允许短期远程工作的，但长期远程工作，目前还不行。

#6 楼 @jasl 我们会组队买门票。演讲就算了，没啥新的可说

#3 楼 @msg7086 有些人来得晚，走得也晚。

#50 楼 @yort_feng 哈哈，发网址来评估下。

#32 楼 @caiqinghua 自己开发。

#28 楼 @dapic 感谢反馈。这个功能已改进，预计下周更新。

#27 楼 @dapic 对于 SaaS，开放 API 来定制业务流程，比开源代码更重要。

#15 楼 @flowerwrong 主要有两种方式： 1）阈值算法 监测实际的数据，比如带宽、会话数量、平均负载等，设定上限，超过就 scale。 简单，容易实现，但是 scale 会滞后。 2）预测算法 实现比较复杂，但可以提前做 scale。在算法层面，可以做很多优化。在scryer-netflixs-predictive-auto-scaling，介绍了两种：FFT-Based Prediction，linear regression with clustered data points。

#23 楼 @ruby_sky 遇到问题了？请问是用什么设备和浏览器呢？

#20 楼 @dapic 我们的产品，最早就是基于 spree 开发，但实在不适合国内用，后来放弃，按国内主流电商业务，重新开发了，不如去试试，能帮你省不少心。

#47 楼 @mogodb shopify 用的就是 mysql，团队之前做项目，主要也是用 mysql。产品设计初期，就决定把热数据，都放在内存，性能问题无需考虑。在 DB 那层，更注重可靠和稳定，mysql 要达到同样目的，可能需要花更多时间。现在的 Pg 对 NoSql 支持很好，如果这时候选型，那更是 Pg 优先。

#45 楼 @mogodb 主要是 Pg 更可靠和稳定。http://www.zhihu.com/question/20010554

spree 很适合做欧美的电商项目。 最早我们做友好速搭，也是在 spree 上二次开发，但用户体验、业务逻辑等，不太适合国内电商。后来还是放弃 spree，从零开始自己开发了一套。 如果是做国内电商，不妨试试我们的产品，会帮你省很多事：https://youhaosuda.com/

QingCloud 硬盘事故，去年确实也遇到过一次，一部分原因，也是由于自己没及时改配置，后面一直很稳定。 我们用主机比较多，数据库、缓存、CDN 等都在 QingCloud 上自行部署，网络也是自行配置。 如果不需要配置复杂环境，只是需要一台云主机跑个网站，就考虑其它服务商，比如阿里云。

#12 楼 @cuterxy 看到 版主，好古老的词汇呀。

#42 楼 @gazeldx 我们 CEO 的指示是，如果公司倒闭就开源。

#15 楼 @lyfi2003 嗯，对的。我们现在就是判断登录失败次数，超过了才会用验证码。 图片验证码，只要人容易认出的，程序要读取都不难。 人类那么聪明，发明了 CAPTCHA 来识别人和机器，结果又发明识别技术让 CAPTCHA 成为软肋。 难怪马斯克警告大家，要防范人工智能。

#16 楼 @hooopo 哪里出了小问题？

#11 楼 @Peter 无关框架的，主要是自己造轮子，Golang 生成验证码和图片，Redis 存储数据，Ruby 验证数据。细节怎么做，看个人的了。 像我们是提供独立的域名，来呈现验证码，Server 端是 Golang 提供服务：//captcha.ibanquan.com； 前端脚本用 JSONP 获取验证码的 ID 和图片地址，这个请求返回后，后端的 Redis 就有 ID 和验证码 Value 了； 表单提交时，把用户输入的验证码，以及隐藏的验证码 ID 提交给 Ruby 后端； Ruby 里面，可以通过 ID 从 Redis 取出 Value，和用户输入的验证码匹配。

#8 楼 @lyfi2003 如果要自己实现，也不难，还可以更简单。

#9 楼 @flowerwrong 嗯，好的用户体验，都是这种模式了。我们也是这样。

#6 楼 @Rei 嗯，网银和支付类系统就是类似，登录失败超过一定次数，直接锁定账号。但对离钱有点远的账号，这么做太严厉。

@Rei @lyfi2003 其实，通过频率限制，体验不一定能更好。实际人工点击，频率可能都会很小。如果输错一次密码，告诉我 10 秒后才能再试，我会不开心。之前 QQ 邮箱，就限制邮箱的收件刷新频率，向他们抱怨过，已改进了。 通过频率检测 + 验证码，可以既提升体验又加强安全。

@lyfi2003 之前我也觉得验证码粗暴。csrf 对于前端，只是多一步，先 get 页面，然后找到 csrf 的 token 就可以发请求。客户端加密回传，前端脚本代码是暴露的，一旦加密方法被破解，也就等于没有了。

#1 楼 @Rei 通过频率检测，或黑白名单策略，还是不太可靠的。验证码是目前能想到的，最可靠的方案。 不过这个 gem 可以用来做预警，发现异常请求，就通知管理员。