#3 楼 @lululau 我指的是邮箱的密码. 要是给人 demo 的话，git comment 至少写的好点吧

一年 Go，很少有人能到达吧，Go 还是比较好上手的，现学也可以

README 里的邮箱的密码居然可以直接登陆

不错，连团队名字都有了

你可以试试用 chef，你这种需求最合适了

全栈很火啊

我也支持用 vagrant，就算中间出问题直接重新开一个

试过了 Redmine，Pivotal Tracker, Trello, Track, 最后还是 JIRA 好用 有 Agile Board，有 issue tracking，两者结合的很好，和 bitbucket 集成也不错，很多用到的 service 都对 JIRA 有很好的集成

胡皓同学充满了正能量，靠谱的公司赶快带走

docker 只是一个 Linux Container, 底下的操作系统还是一个，每个 docker 事例其实就是一个进程 不像 vagrant 是一个系统级别的，虚拟出整个操作系统及硬件

docker 更轻量些，启动一个 docker 实例就是几秒钟的事情 目前通过 Linux 内核也能控制 CPU 优先级，内存使用

对开发来说，比如你需要一个 Redis，直接启动一个别人写好的 Redis 的 Image，几秒钟就能提供一个 Redis 服务

#8 楼 @greatghoul 被点名了，家里阳台上摆了一台，边看 iPad 边跑步，可以坚持半小时以上，比淡出出去跑步有意思，而且健康很多。时间灵活，想什么时候跑就什么时候跑，像我这样远程工作的配一个跑步机很有必要

对于上面说的减脂，目前没坚持下来不敢说，但是长时间的有氧运动，至少半小时，听说减脂效果不错，跑步机可以测心率，保持在 180 - 年龄，是减脂的最佳运动强度

Elasticsearch 的好处在于方便的聚合，实时查询， 关系，嵌套查询都是弱项

比较好的做法是，数据还是存在关系型数据库或者 Nosql，需要统计的原始数据可以整理后存入 Elasticsearch

你可以先着重后台逻辑部分，这样有助于你学习 Rails 本身，前端的部分像 @Rei 说的，有很多现成的 css 框架

好东西，很详细

是不是项目目录下指定了 ruby 版本 .ruby-version

估算不准确的最重要的原因是 scope 不清晰，对难度估算不准确 尽量把任务分割，越小越准确，而且每个小任务最后多余的部分加起来就成了整个任务 buffer 时间

worker=1 PID:2349 timeout (31s > 30s), killing 超时进程被自动关闭了

papertrail 的搜索不是很好用，而且数据量上去有点贵 尝试过 https://www.splunkstorm.com, 功能很强大但是使用起来有点复杂，最近又免费了，可以尝试一下 现在准备折腾 http://logstash.net，基于 Elasticsearch

需要熟悉一下吧，我现在一直用着

#1 楼 @raecoo

看过一篇文章，同时使用两个 server，redirect 慢的 IO 多的 request 到 puma，其他的 redirect 到 unicorn

#15 楼 @lulalala 确实已经可以了啊

看一下 unicorn 的 log，是不是有 timeout kill 的情况

#1 楼 @Rei 假设任务不涉及 IO，sidekiq 也不会太好吧，多个 thread 反而会阻塞任务

@huacnlee 原来 8 个进程，现在 puma 两个进程，怀疑能否达到原来的请求数量，毕竟 thread 只是在 IO 的时候有作用，反而如果很多请求 (假设 CPU 计算比较多) 进入 thread 反而互相影响，导致进入 thread 的 request 响应时间比以前还要长，如果按照 puma 也起 8 个进程来看消耗的内存也不一定比 unicorn 少

https://dl.dropboxusercontent.com/s/0r295452bkjpduv/rspec-talk.pdf?token_hash=AAElao5GsdYP98QWa5MiP2h5ceZaCLE-jfJ0D3Dhec0WUA&dl=1 我刚转的 pdf 版的