今天，集中处理了 Klib 从多个源导入时的数据合并问题。确实是复杂，脑子都不够用了。即使加上白板、Excel、纸笔，还只是大体弄清楚了。并没有完全实现，也就不知道是否遗漏了哪些逻辑。

感觉自己处理这种复杂逻辑的能力还有待加强。

• 一方面，大脑容易有限，同时思考复杂折逻辑，很容易有遗漏、错误。
• 另一方面，还没有找到很好的、帮助具象逻辑思考的外在媒介，相当于内存中的数据无法持久化到研究中，内存也就不能再存储别的东西。

处理逻辑的事，确实比较枯燥、也很容易累。今天就这样的吧，明天早起继续。

PS：骄傲的是：上述逻辑，用户几乎是不可知的。如果做到完美，用户完全不可知。这样就对了。

我的一张手机卡有个奇怪的问题：放在手机 A 中可以、在手机 B 中就是不行，能想到的办法就是补卡。可，一直拖着。近期，有缘由必须要换卡了，显得很仓促。

我的眼镜有磕损、且度数不够了，要换。可，一直拖着。近期，有缘由必须要换卡了，显得很仓促。

哎，做好重要、不紧急的事，怕是个人事务管理中最难、最容易被忽略的问题吧。

前几天，61 和微博在撕。其结果是，微博不再（至少在某些情况下）不再私处篡改用户的链接地址。

这几天，我在做 Klib 集成 Kindle 其它端笔记时，除了尽量在已有情况的约束下思考可能的的方案、改进体验，我还试图通过微博转发的方式，向亚马逊施压、请愿，希望他们能在中国区开放网页版的笔记管理。

虽然，我知道即使这样做，亚马逊做出调整的可能性微乎其微。但这不一样，至少我做出了努力，在努力让这个世界变得美好一点点。

这也强化了自己的认知：不只可以在现实的束缚下跳舞，还可以试着打破现实的束缚，带来更多的可能性；为自己、也为别人。

大公司在追求更大利润基数时，会放弃小需求，这可以理解。

可是，这些被放弃的需求，并不是没人需要。需求没有大小之分，对需要的人来说，总是非常需要的。

那么，怎么处理大公司与小需求的矛盾？可以试试 提高开放性，让更多中小玩家参与。

比如，对于 Amazon 这家巨无霸，电子书是很小的份额。而在 Kindle 电子书中，电子书的笔记管理更是小中之小。从求教到的 Amazon 前员工得知，在公司内部，这样的需求是排不上优先级的，这也是为什么只有美区才有笔记的网页版、并且一直很烂。并且，这也是为什么我开发 Klib、并且受大家欢迎的原因。

可是，小需求并不意味着没利润。比如，Clippings.io 这家服务，主打的就是能同步 Amazon 美区的笔记，并且收费 $1.99 每月。当然，这样的收益根本入不了 Amazon 的法眼，却能养活一个小团队。更关键的，这个需求的满足，会让 Amazon 自己的用户在使用 Kindle 阅读时，感觉更舒服。

所以，大公司提高开放性，甚至故意出让部分利润，让更多玩家参与进来，让自己的生态更完善，是对自己、第三方玩家、用户都好的多赢局面。

编程珠玑

笔记：

• 时间与空间
  • 时间换空间。对于可能被重用的中间计算结果，不存储、下次需要时重新计算。
  • 空间换时间。对于可能被重用的中间计算结果，存储、下次需要时不重新计算。
• 应用与底层
  • 举两个例子：
    • 应用型：学会使用 JSON 解析库；
    • 底层型：优化 JSON 解析库的效率；
  • 以目前我的状态，更适合向应用型发展。可以说是堆业务，这可以快速解决实际问题，由此带来的成就感，大于把搜索效率提高一倍这样的成果。
  • 当然，如果效率优化成为业务的核心时，还是会用户去优化底层。
  • 另外，感觉目前大多数产品、大多数开发者都处于应用型、堆业务的状态。这没什么不好，虽然应用型是建立在底层的基础上，但如果没有应用的失去，底层也不会自动发展的。