我用手机回的，漏了这个，不过懂 Nginx 配置的应该知道这个吧。。。或者 在 sudo nginx -t 的时候 也可以检测语法错误

我不会用 8000 端口（rails 不是推荐 3000 端口嘛），我也不会用 thin（puma 挺好的）

可以贴下新的 Nginx 配置 查下 8000 端口被谁使用，配置完 Nginx 要重启 Nginx

upstream athonna_servers{ server localhost:8000}加上这个试试

应该是 Nginx 没配对，你看见你仿照的文章中有这个
upstream rails_girls_site{ server localhost:3560; server localhost:3561; }

你了解这个的作用吗？你的 proxy_pass 那 的 athonna_servers 是怎么来的？觉得应该是这个东东你没配。另外 你可以尝试用 PUMA，也许实际工作中使用 PUMA 的机会比 thin 多

Ubuntu14.04

好像 aws 峰会是 26 号

单点登入

我司大概就是这样

简单的我把它当成了 转接口功能

知其然 与 知其所以然

最好把整体文档都看过 看源码也是极好的。只看别人写的使用教程 以后遇到坑你可能填不了

也许做网站不需要，做服务就需要。只会开车，车子哪出点毛病不知道，不算老司机

插件越多会慢吧？

数据库漏了常用的 redis 和 pg

actioncable 就挺好的。如果要更强一点的性能，用 socket.io 应该够用

才发现这是段子

要顶

https://github.com/plataformatec/devise/issues/2734

Thank you guys! I've been struggling for days with authenticity token failure in chrome (in firefox it worked properly). After adding "proxy_set_header X-Forwarded-Proto $scheme;" to nginx config the problem is solved. I might messed up the config file when setting up ssl. Big thanks!!

前两天升级到 Pro 版本，增加了付费视频功能。以前一直免费看 change 视频，现在买了一年 Pro 会员，送了三个月，希望 Pro 多分享优质视频

address 表和 user 表之间的关联有问题

之前也遇到了这个问题，然后自己写了个可以指定 order by field_column 的 find_in_batches。find_each 实际调用的是 find_in_batches。假设你的场景不是只有 1700+ 条记录，而是有 10w 条记录，你会怎么做？ 你的分析是对的，是由于 (send_logs.id > 245317804) ORDER BY send_logs.id 这里的 sql 使得 MySQL 没用你的索引 (那是联合索引吗) 而用了 primary 导致了问题。实际上是 ORDER BY，导致你的索引没被使用。record_date 应该是日期吧？如果 你的 ORDER BY record_date 也许就用到索引了

find_each 方法用于大量记录的批处理，记录数量很大以至于不能一次加载到内存，比如需要遍历全表记做数据处理

这里 如果你的查询是有多个条件，导致不能使用索引，而使用了 key: PRIMARY , 同样会有性能问题，导致每次的 find_each 查询即使是 limit 1000 也很慢很慢 踩过坑的路过

出现竞争错误的几率会有，但是很小，redis 的性能还是很强的。不可预测指的是什么？或者说你在担忧什么问题。原子操作无非 不是成功就是失败

存 redis，利用 redis 的原子性

小鸟已入前端坑吗

不转 go 吗？

好东西，立马装了

hashie

如果周围坐着的都是大神，环境差一点是可以接受的

同时注重理论 + Ruby + 刷刷题再加算法，平时还要上班。我是这样过来的。所以，你觉得时间太分散这点我没法同意，你计划给自己一年时间做这件事情，我觉得时间是足够的，就看决心够不够了