@musicx 我担心出另外的问题，先不折腾。

我昨天也遇到这个问题，查看官方论坛发现有两个帖子讲到了。

- https://discussion.evernote.com/topic/78806-evernote-603-on-mac-extremely-slow/
- https://discussion.evernote.com/topic/78900-note-content-still-not-showing-up/

我也按照工作人员的提示，登出，清理数据，都不行，最后重启一下，就好了。这个事情很扯的点在于需要重启Mac。

更早用的是Snowman ☃

这些只是OSX上使用到的开源代码，有部分是苹果自己开发并开源出来的。大部分都是大路货，Unix Like上的标配。

42

夜间开车最重要的是淡定

@Totoria
@Henrybsbhp

唉，看来时不时会卡是个普遍问题，内存占用也比 10.9 多，跑不到几天 Swap 就上去了。现在至少两天重启一次。

@stonegong 你们招了好久吧？业务发展这么快？

@roamlog 你简直就是人肉优惠消息收集器

在Twitter上关注 https://twitter.com/roamlog 他经常会发各种优惠，降价信息

@zwl2828 开玩笑吧，Yosemite里就那么几种简单的，这货强大很多。但话说回来，其实大部分人没那么复杂的需求。

Pub/Sub模式比较常见的应用还是解耦两个系统吧，比如我有两个程序，可能是不同编程语言构建的，可能是在不同的机器上运行的，那么利用这个模式，可以比较简单地实现这两个程序之间的通讯。

消息队列，就是用来解耦系统的，以消息生产者和消息消费者的角色来定义两个系统。

举个例子，假如V2EX有个徽章的功能，当你抢沙发超过10次时，能获得一个「抢沙发小能手」的徽章。那么一般来说，代码会这么写，先创建这条回复，然后检查是否为该主题的第一个回复，如果是，对用户抢到沙发次数加1，最后判断用户抢到沙发次数是否大于10次，如果是则发放徽章。

那么，当回复里包含的逻辑越多时（比如还要通知被回复者），回复这个功能的代码会越复杂。此时如果我们采用消息队列，那么可以只是简单地创建回复记录，然后**发布一个回复被创建的消息**到消息队列。而检查是否发放徽章的**消息订阅程序**，会收到前面创建的这条消息，然后去做相应的检查逻辑。

通过这样解耦，添加回复这块代码会变得清晰，因为这里只负责创建这条记录，并发布这个消息出去，无须关心还有哪些逻辑。而处理剩下逻辑的部分，也相当清晰，因为一个消息订阅者只处理一个逻辑。单一的逻辑非常容易进行单元测试，但是这样同时会让系统分离成好多部分，变得复杂，故只有当你的逻辑相当复杂，并且需要提高扩展性，获得更好的性能的时候才会用到这个模式。

不知道这个例子是否清楚，希望能帮你理解。

@tylr 他的14个Demo App都是什么？可以透露一下吗？

如果熟悉在Command line使用Git，不要使用`-m`，而是在Commit的时候加上`-v`，这样在编辑Commit Message时先往下走，把代码再认真看一遍，看好了再写Commit Message。

这是我一直以来的习惯。