今天，在开发 Klib 应用内阅读模式时，突然想到可以在阅读模式下引导分享，实用且不打扰用户的功能，不错。

能想到这个点子，前提是在做这块的功能。保持手热，脑子一直浸淫在相关的逻辑中，才有可能冒出好的想法。

如果可能，挖个深坑。找个合适的项目，好好钻研较长的一段时间，做出精品。

今天，基本完成了 Klib 分享的技术总结，下个「周二早 8 点」的文章有着落了。

构思、码字、行文、排版、做图…前后花了 4 小时左右，真是花时间啊。

本次暂定免费发布，如果反响可以，之后会试试小密圈，并推迟在公开渠道发布。

不过，写文章这种事，看的是别人、收益的是自己。会做是一回事，能系统性总结出来、甚至能帮到别人，是另一回事。而且，也写的过程中，也是对方案的反思，会有意外的收获。坚持，用输出倒逼自己输入。

这两天遇到了 MySQL 一个很诡异的问题，Google 后打开了上百个页面，折腾了将近一天，也只是「绕过去」了，最终也只是模糊地了解了原因。

回头来看：真不划算。既浪费了时间，还坏了自己的精神头。

还是要 专注于核心业务，把核心业务以外的事情，全部「外包」

外包，就是交给更专业的人做，节约自己的时间。比如，对于 MySQL，可以找 AWS 这种专门提供数据库托管的服务，几分钟就可以创建一个强大的、全球的、高可靠、防攻击的数据库，这是个人花几个月也做不到的；而其成本，则相对低廉的多。

尤其对于独立开发者，个人精力非常有限，一定要用在最核心的、无法被替代的地方。对于 MySQL 这种基础性的工作，做差了，用户骂；做好了，用户根本不知道，也不会表扬；摆明了吃力不讨好的事。

再一次记住这个教训。

目前，已经完成了 Klib 分享的后端和前端部分，可距离发布产品，还有很多工作要做。

比如数据库，正常的读写好，还要处理异常的情况，比如防止 SQL 注入，防止恶意插入大量数据，等等。

再比如并发数，同时和多个组件关联，复杂度甚至是各组件相乘：

• MySQL
• SQLAlchemy
• gunicorn
• nginx

有高人指点就好。可要找到恰巧上面各项都懂、有时间、愿意帮忙的高手，太难了。

更靠谱的是，自己学习并解决。趁还不算老，多学点吧。

用了一段时间 Python，今天又开始切换至 Xcode + Swift，真的是感觉到：没有比较，就没有伤害。

一方面：

• 和解释型语言相比，编译型语言的编译时间，简直是在谋杀程序员
  • 尤其，Swift 的编译时间出名的慢
  • 再加上，每次编译都要签名；尝试了取消签名，但失败了，回头再折腾下
  • 当然，也是有好处是：不用像解释型语言一样，担心在运行时出现类型错误。当然，这一点是可以通过别的方法解决
• Xcode 的代码提示…Xcode 有代码提示吗？
• VS Code 可以像网页一样使用 Command +/- 来缩放，比 Xcode 用起来舒服

另一方面：

• 和 Xcode 相比，VS Code 的调试功能还是太弱了
• VS Code 在提交代码时，即时的修改竟然不会被提交

另外：

• Xcode 和 VS Code 的功能和快捷键有很大的不同，切换起来，要人格分裂了
  • 在 IDE 中使用 Git 查看代码不同时，Xcode 当前代码在左侧，VS Code 在右侧
• Swift 和 Python 语法上的不同，切换起来，要人格分裂了
• 现在用 13 寸的 MBP、还未外接显示器，多窗口调试时确实显小了，下一台一定要上 15 寸，除非有工作室 + 外接显示器

好在，今天完成了 Klib 分享的客户端主体部分，明天应该能完整搞定；争取再写一部分 Klib 分享的技术方案。