播客及至音频节点的软肋：信息密度低、不能快进。

如果在高效时间听，浪费时间；
如果在低效时间听，很难有大的收获。

比如，听到一个知识点，要扩展了解，就需要先记录，然后有时间后再搜索。但如果是在低效时间（比如运动、打扫卫生、洗衣服时），是不方便记录或扩展研究的。

当然，还是有些办法规避这些缺点。比如在播客介绍中列出本集重点、相关链接、等等，虽不然完全解决，但还是能明显发送的。

恩，播客还是挺有意义的，毕竟总是有很多低效、又无法阅读的时间需要填充。

今天 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 能帮你解决吗？

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