独立开发，自由职业
写代码实现功能，基本是封闭问题。就是说，自己知道目标是什么、达到目标前有哪些问题或困难，然后一一解决便是。
而运营推广，是开放问题。目标不确定；达到可能的目标，又有无数种途径。对于开放性问题，以及流量运营，好像我不太擅长。需要做的选择取舍太多，多渠道追踪起来又很花时间。
并且，准备运营的素材，包括文案、图片、视频或动图等，也是非常花时间、花精力的。比如，如果图片中需要出现产品的界面，对于内容型产品，就要事先准备大量优秀的内容，以填充应用界面。最后，看起来是一张简单的图，背后却有大量的工作。如果是视频，要求则又高一个量级。
之前，我一直想，要是有人能帮我把运营推广给做起来，我专注于产品本身多好啊。一方面，这样的合作伙伴并不好找。另一方面，运营的过程，也是和用户深入交流的过程。这样关键的环节，也不能完全假他人之手，还是要自己花时间参与的。
花了两三天，实现了从微信读书中导入标注。使用自己的账户测试了一遍，感觉差不多，就发布上线了。
现实是，一个微信读书的重度用户，有几百本带标注的书。数据量一天，就暴露出程序的问题。比如，微信读书接口对并发请求的限制。
庆幸的是，虽然功能已经上线，但还没进行大规模宣传，影响还不大，来得及改进。发布后，下周初再宣传吧。
事情的起因是这样的，突然发现 Kindle for iOS 等客户端，之前是可以将标注通过 Email 以 html 附件的形式导出，现在却不行了。哎，Kindle 变得更加封闭了。
Kindle 如此傲娇，不想伺候了。换什么阅读工具呢？自然是已经买了会员的微信读书。
这又带来另一个问题：微信读书同样比较封闭，并没有接口可以导出标注；只能自己一本本书复杂纯文本的标注，然后想办法格式化再导入。关键，每次更新，都要这么手动操作一把，实在太烦了。
其实，技术上还是有条路可以绕的。微信读书肯定是有接口的，只是没有开放；核心的，是没有开放授权机制。怎么办呢？绕过去。微信读书网页版登录后，从浏览器中提取 Cookie；然后，通过 Cookie 完成授权，并调用接口以获取读书笔记。
有开源项目已经在这么干了。有了前人的工作，分析接口的工作就少了很多。到这时，技术可行性都已经通过了，只剩下堆代码实现功能了。
业务上，还有些繁琐的细节。比如，微信读书不只是商城里的书，还支持自己上传的 epub/txt 等格式的书、以及公众号的文章。不同类型的数据源，所产生的数据结构是不同的，需要分别适配，还要集成到统一的数据库中，费了一点心思。
堆了一天代码，主体功能已经跑通了。接下来，还需要完善业务、代码、交互上的细节。功能完成后，还要考虑一定规模内测以发现问题，以及发布、推广的事。哎，这么个功能，做出来还挺麻烦的。
事情是这样的，国外一个媒体联系到我，想要推广 Klib 的时候有点返佣。
这个，虽然目前 Klib 支持序列号，但还不支持 Affiliate 和 Coupon。本来想算了，放弃这个机会。后来想想，要么试下吧。
功能上，主要是这几部分：
比较了 Stripe、Paddle、Gumroad 等方式，包括功能支持、费率等因素，最后选择了 Paddle。其实是用了排除法：Stripe 不支持国内用户注册，Gumroad 有过随意封号的黑历史，直接不考虑了。
花了几个小时集成 Paddle，其实还是挺简单的。唯一的麻烦，是在创建 Affiliate 时，一定要有个自己网站的落地页。其实，我不太理解为什么一定要这么做。在我看来，直接在付费链接上加小尾巴，应该也是能实现的。不管怎样，我实现的落地页，是这样的：http://klib.me/pro/
序列号方面，只要上传一个文件，每行一个序列号即可。用户购买后，Paddle 会自动依次提取序列号并发送。需要提醒一点：Paddle 并不支持删除已经上传的序列号；所以，不要上传无效的序列号。如果已经上传了（比如像我），可以创建一个完全免费的 Coupon，然后用这个 Coupon 去消耗掉无效的序列号。
目前，由于还没有真实的付费，尚不清楚考虑到税之后实际收到钱的比例，以及提现到 PayPal 会不会再次收费。
总之，目前这个机制已经完全实现了。如果你有国外的软件推广渠道，欢迎联系我。具体的软件，推荐 Klib、iText、iPic。
BTC，突破 5 万美元。
突然觉得币价和房价很像。
至于涨的有没有道理、是否合理，还重要吗？