#6 楼 @hrz3424 我发现近期你在多个招聘贴下问是否提供远程工作，如果你真的想要一份远程工作，你可以在求职板块发一篇自荐贴。

#7 楼 @rei 补上原文出处，我觉得还是可以加精华，如何？

#7 楼 @poshboytl 我觉得 @flyerhzm 那期不算，必须再请一次，至于 @ashchan 得再请好几次才够。

@eastmoney 下次发帖请发送到招聘节点，标题需要符合论坛招聘版规要求，并且请不要招聘非 Ruby 相关的职位。

需要，你仍然需要配置一个 active_job 的 adapter，以及后台队列实现如 Sidekiq，否则如果系统没有检测到你配置的 adapter 的话，会从异步发送 fallback 到同步发送。

我发现一个问题，只列举了你想听到的嘉宾，但是没有涉及你想听到的内容或者话题，虽然这是一个看脸的时代，但是我们的 Podcast 是看不到脸的呀。

感觉按照这个单子做下去，可以做一年啊。

#24 楼 @flowerwrong 看起来是因为版权的原因，所以不支持的，用第三方泛用形的 podcast 工具订阅吧，iOS 上的 podcast，或者直接订阅 Teahour.fm 的 RSS 都可以。

由于 GarageBand 的 Bug，导致原来语音的最后几分钟丢失，刚刚重新导出并更新了新的语音文件，如果大家听到尾部发现问题，需要重新下载。

#3 楼 @poshboytl 这是我们录制 Teahour 以来，感觉最八卦，爆料最猛的一期。

FreeWheel 的 Ruby 技术团队在国内也算数一数二了，发动你们全部的技术人员渗透社区，然后想办法内推呀。

你到这里发帖还不如去云梯网站上提交工单来得快呢。

@greatghoul 你是一个好策划

#44 楼 @lyswjhh 我给你出个招，你去扫一下所有评论数超过 50 的招聘贴，看看人家的招聘贴是怎么形成话题以及评论热度的。

http://ruby.taobao.org

#42 楼 @lyswjhh 顶帖太频繁了，我们准备针对这个问题处理了。 频繁通过顶帖的方式，而非正常沟通的方式把招聘贴顶到首页已经成了论坛的一个问题。

#54 楼 @kgen 理论上仍然有可能会丢最后一秒的数据。

如果真的工伤了，有补助么？

#51 楼 @qhwa 我们其实还好，业务量没有那么大，还未碰到过 Redis 因为内存不足导致问题。┐（─__─）┌

这个坑从 Rails 诞生之日就一直存在，没有什么特别好的方法预防，只能通过测试来确保 callback 的行为符合预期。 等 Rails 5 发布后，callback 返回 false 就不会 halt 整个的 callback chain 了，必须显试调用 throw :abort 才行。 https://github.com/rails/rails/pull/17227

#48 楼 @sharpx 同意，特别是对那些抱残守缺，观念僵化的人来说，把 Redis 直接当数据库用，是很难想象的，更不要说接受了。

#46 楼 @rei 哦，明白了。

#43 楼 @rei 这三行代码我左看右看，都觉得是有需求且合理的呀。

#44 楼 @rei 关于 json 生成是否属于 view 层，应该是一个代码组织风格的问题。我的看法是目前 Rails 的 Action View 设计本身并非针对 API Only 的场景充分考虑，所以使用 view 层可能带来一部分额外开销。

我同意 @luikore 的看法，围绕 model 去序列化，而不依赖 Active View 层以及相关的 view helper，最近接触到的案例是用比 ActiveRecord 更轻量的 ORM 方案，比如直接用 ohm + Redis，让 Redis 直接担当 Database 的职责，这样单机处理能力上升一个台阶，在一个相对复杂压力比较大的场景下，单台服务器就撑得住。