今天 iKindle 公开体验，收获了首批种子用户，初步反馈还是可以的。

接下来，就有两个可能的方向：

1. 继续维持原来的方向：专注于 Kindle 设备的笔记管理。
   • 优点是，因为专注，可以做的更便捷、高效。
   • 缺点是，这注定是一个无比小、无比细分的领域。说的直白一些，几乎无法带来什么收入，几乎是个纯情怀产品。
2. 扩大 iKindle 的应用领域
   • 比如，支持多看、微信阅读等更多格式笔记，成为用户统一的阅读笔记中心。
   • 这会大大增加产品的复杂度，不仅是需求与交互上的，还是技术上的。

目前来看，还是坚持原来的方向，先做好 Kindle 本身的优化，再考虑可能的扩展；情怀就情怀吧。

iKindle 是什么？

iKindle 是管理 Kindle 中标注、笔记的工具，macOS 平台。

俗话说，「不动笔墨不读书」；在 Kindle 上看书时，也会积累很多笔记。如果任由这些笔记流失、或蒙灰，实在是太浪费精华了。怎么办呢？试试 iKindle 吧。

管理，从导入开始

将你的 Kindle 连接到 Mac 电脑上，选择 Kindle 目录，「开始导入」即可一键导入。

原生交互，未打开、已熟练

考虑了好几版交互，最后参考了系统原生应用「提醒事项」。非常契合 Kindle 笔记管理，也方便大家快速上手、避免学习新交互所浪费的时间。

最近使用了开源库 AES256CBC，还是挺方便的：封装了最常使用的 AES 加密方式，还创造式了自定义 iv，值得称赞。

美中不足的是，这库还不成熟，在 macOS 和 Ubuntu 中均有闪退的情况。之前遇到闪退时，自己解决了问题；现在又遇到了闪退。

问题是，当初自己临时解决问题，并没有合并到 AES256CBC 的官方代码中。主要原因是怕花时间。毕竟自己随意改改，代码要求可以不高。但 要拿出手，就要拿得出手，这就要对问题深入理解、打磨代码。而在做项目期间，通常是没这个时间的。而等项目结束、有时间了，又懒得弄了。

当初的放松，导致现在的问题：自己相当于另建了一个分支，之后自己再修改，就要手动处理自己的分支和官方分支的合并情况，而这又增加了新的时间成本。

所以，如果当初稍微再花点时间，将自己的修改提交到官方主分支上，能：

• 帮助改进官方库，帮助其他用户
• 逼迫自己对问题深入了解、打磨自己的代码
• 避免维持不同分支的麻烦
• 从这个层面提高自己的影响力

看来，虽然花了点时间，但好处多多；恩，以后要多多向开源库提交自己的修改。

相信很多开发者都是 面向 Google 编程：遇到问题，搜索解决方案；继续遇到问题，如此反复。

对于比较粗浅的问题，这样做确实是可以的。但对于更底层、更复杂的问题，就不是搜索能解决的了。需要的是耐心的研究，花时间研究。并且，要相信很多的问题的复杂度是超出目前自己的能力范围，或者说是时间允许的能力范围。

比如，对于你目前的产品，如果在线人数、业务量翻倍、10 倍、100 倍、乃至更多倍，你目前的程序设计还能支撑吗？你知道怎么解决吗？你觉得 Google 能帮你解决吗？

当然，这并不是说让大家都去研究底层，实用主义也挺好的。只是说，大家在用实用主义编程时，要对程序有敬畏之心。

感觉，自己的焦虑多数来自于自己无法做的事，或者是自己无法掌控的事。

坏消息是，大多数事自己都做不了、或无法掌控；
好消息是，这样的事，做一件、少一件。

虽无法掌控，但毕竟还是可以影响的。进一步，说是事，但其实还是做事的人。这样，问题就演化为如何驱动一个人朝着自己期望的方向做事？

因势利导。

不同的人，能驱动他的东西是不一样的，比如：

• 权利。比如事业单位体系中的小职员，最能驱动他的就是领导的一句话，然后就是纪律、督查。
• 钱。这种没什么的好说的；如果觉得跟解决的问题相比，花的钱并不算多，那就用钱砸呗。
• 成就感、虚荣心。一个褒义、一个贬义，但实际的意思差不多的。比如对方就是助人为乐、乐善好施的主。

说是能说很多，但其实我在这方面很不擅长，也并不想做这样的事，比如管理、驱动手做事。与其驱动一个人做事，不如找个不需要驱动的人合作。