这块的内存是否归还给系统，取决于操作系统对于 malloc 的实现吧？Ruby 要背锅吗？

回复中那么多 好吧。 好吧，实在看不下去。

#4 楼 @rei 用 SendCloud 经过产品环境测试国内用户很稳定，Gmail 用户也可正常收件。

我在正文中添加了 4.22 补充 用来回答 @satzcoal 的问题。并把尝试使用 ASN 实际开发项目之后的小结汇报给 @billy

shotgun 当做开发环境的 server

#14 楼真相帝

好，支持，威武，有希望了！

#17 楼 @billy 我也觉得你这样好。只是在研究 Pub/Sub 的时候，有人建议把这个模式和 Service Object 结合到一起。我确实没有实践过这种结合法，不知道有什么坑。不过我今天就要踩踩看了，如果有新进展，我再 @ 你，并补充此文。

#15 楼 @billy 我是没看懂你在 #13 楼的回复。好像哪句都连不到一起。。。

我换个问法：注册用户触发发送邮件，你觉得写到哪里或者在哪调用发送邮件的方法好？

#13 楼 @billy 异步队列和 Pub/Sub 模式不冲突。我在另外一篇帖子中提到这个问题了：Pub/Sub 模式中具体怎么处理事件，是直接打印输入，还是扔到队列中都可以啊。像你说的发送邮件这种事情，扔到队列中是毫无二异的。

我再来描述一下这个场景：

1. 事件发布者广播：兄弟们，我要这注册了一个新人。
2. 订阅者收到广播：靠，又要发邮件了，邮差你把这封信发一下。
3. 邮差：扔到队列 (Sidekiq) 当中慢慢等着吧你。

这回理清了 Pub/Sub 和 Sidekiq 的关系了吗？

#11 楼 @billy 非功能性 也可以叫 非商业逻辑代码 比如 @huacnlee 说的那个情况。你可以读一下我附加的链接，有人也认为像 发送欢迎邮件 之类的不属于核心功能，可以用广播来发送。

归根结底它实现的功能就是大吼一嗓子：兄弟们，注意，我变形了！

至于其他人听到这声之后干啥，那就随便了。

#13 楼 @gazeldx 你肯定没注意到我在文章中提到了 #260 Messaging with Faye

对于 全局 listeners 只用在 initializer 里面定义，看起来集中化了，但对发布者而言，它完全不知道哪些类会响应消息，开发者自己也需要去一个一个排查才知道。 这个问题

发布 / 订阅模式的设计思路就是 发布者不知道哪些订阅者收到哪些消息。所以这个模式不适合做核心重要操作。我读的几篇关于 ASN 的例子也是拿来做日志，性能分析类事务。

对于代码的可维护性来说，我觉得不论全局还是局部。只要内部有个统一约定就好。我个人倾向结合 Service Object 用的时候还是局部订阅吧。就像你说的 报表，日志，统计 这些常规操作（非商业逻辑）放在全局订阅更好。

有些拿不准的，我也不乱回复了。等将来有新的实践经验再 @ 你，或坐等其他大神解答。

面向对象设计实践指南 2 - 设计具有单一职责的类

• OOD 的失败并非是编码技术的失败，实际上是视角的失败。
• 尝试用一句话来描述类。如果这种描述中出现“或、和、并”这样的字，那么这个类就具备了多种职责。

如果客户或产品给我的需求是：根据用户点击返回相应结果，而实际上让我做的是一个 Ruby China......细思恐极。

#1 楼 @Rei 用 Rails build-in 的一套，确实比引入一个新 gem 更好。我再读一下 ActiveSupport::Notifications 相关文章，稍后将心得补充成另外一篇帖子。

#2 楼 @rocLv 有《Growing Rails Applications in Practice》的版权吗？已经有完成度 70% 初稿了，但是没拿到授权。已发邮件，盼回复。

第一个坑：在缓存中设置一个 key 假如叫做 project-id-name，里面的值就是所有涉及到 project name 的其它缓存的 key。当 project name 改变的时候，取出这些 keys，依次删除或更新这些 keys 的内容。

第二个坑：参考 #45 的做法，在缓存 key 中引入 role。

:plus1:

好，支持，威武，有希望了。我马上回家写简历。

1. 薪水跟得上 -> 高低不能低于业内平均水平
2. 硬件跟得上 -> 电脑，键盘，桌椅等办公设备等舍得投入
3. 环境跟得上 -> 鼓励同事间技术交流和分享，也愿意投资让员工参加业内聚会
4. 福利跟得上 -> 不要 5 险 1 金，但好歹下午茶和零食得有点吧
5. 妹子 -> 这是什么鬼？公司的妹子多不多，质量好不好跟我有关吗？

没有年会

包邮书，还是包邮你自己？

我收了，怎么联系

Moom +1