发表于 | 分类于

没错，就是内购。

好端端的一个产品，非得加各种让人难受的限制，以期让用户付费升级，这真是非常低劣的玩法。

不止在于表面的交互，代码里也得加各种奇怪的逻辑。写这样的代码，就感觉是在浪费生命。

如果以后我足够知名、强硬了，一定会摒弃免费 + 内购这种模式，直接上付费下载，或者免费 + 捐赠，或者直接订阅。

要是能把时间都花在纯粹有价值的事上，多好啊。

发表于 | 分类于

前两天一位创业程序员，被前女友逼得跳楼的消息，火爆了网络。

其中一个观察的视角是，这位程序员情商太低，不然不会走到跳楼的地步。虽然很无情，但我基本是认同这个说法的。

但，我又不是很认同这种现状。也即，一位程序员，即便是位天才程序员，也需要在情商、社交等等编程之外的领域，不至于太差，才能在社会上「活」下去。这样的「活」，对人的要求未免太高了。

相比之下，可能生物界的进化更充分些。比如，我问什么动物跑得最快，多数人才能回答出来是猎豹。对，猎豹正是这一招鲜，让它得以生存，且博得美名。正是因为一招鲜就可以活下去，它就可以尽可能地向这方向进化，包括身体的各个部分。反之，如果自然环境同时需要它像羚羊一样有耐力，那它一定抓不到羚羊，甚至饿死。

当然，猎豹肯定不止奔跑这一项技能，还需要伪装等等技能，但这只是个例子。我相信，随着进化的加深，某些能力会进一步加强，而其它能力会进一步退化。关键的，这一进一退，能让它更从容地适应自然。

对应于人类社会，我想道理是相通的。现在我们还经常听到「全栈」、「综合能力」等等词汇，但我觉得这是人类进化不够充分的体现。一方面，可能今后更多的能力会变成基本技能，就像呼吸一样不会被人提起。另一方面，一招鲜会更有市场。

还有个角度，从人类整体而言，并不需要一堆能力平平的通才，而需要一个个在某方面极其突出的专才。这样，累加起来的能力总和才最大。比如，不需要一堆有爱因斯坦 99% 的能力、但又会长跑的科学家，而更需要 100%、甚至 200% 的爱因斯坦。

发表于 | 分类于

在 iPaste 数据结构中，有个很重要的环节：压缩数据（即剪贴板内容）；鬼使神差的，竟然一直没有做。在准备发 Beta 2 时，做吧。

简单了解下后，发现Apple 内置了 libcompression library 压缩库。而且，也有一些使用 Swift 的封装，比如 NSData-Compression 和 DataCompression；我使用了后者，不过应该差不多。

进一步，这个库中包含了 4 种压缩算法：

  • LZFSE
  • LZ4
  • LZMA
  • ZLIB

如何选择呢？苹果也给出了官方建议：

Choice of Compression Algorithm:

  • Use LZ4 if speed is critical, and you are willing to sacrifice compression ratio to achieve it.
  • Use LZMA if compression ratio is critical, and you are willing to sacrifice speed to achieve it. Note that - LZMA is an order of magnitude slower for both compression and decompression than other choices.
  • Otherwise, if speed and compression are more or less equally important, use LZFSE unless you require interoperability with non-Apple devices. If you do require interoperability with non-Apple devices, use ZLIB.
  • LZFSE is faster than ZLIB, and generally achieves a better compression ratio. However, it is slower than LZ4 and does not compress as well as LZMA, so you will still want to use LZ4 if speed is critical or LZMA if compression ratio is critical.

简单的说：

**- LZMA 压缩效果最好

  • LZ4 压缩速度最快
  • LZFSE 是苹果自己开发的、综合表现好
  • ZLIB 应该被 LZFSE 取代**

当然，不能道听途说，我也拿自己的实践数据测试了一把：

最后，我选择了苹果自己的 LZFSE 压缩算法。

除了压缩本身，还有件很重要的事：兼容已有的、未压缩的数据。事实上也还算好做，关键是有一点：如果数据未压缩，解压是无法得到有效数据。这一点可以用于区分数据是否压缩，而暂时不用添加 v1/v2 这样的数据结构版本号。

再次得到教训：优先做数据结构相关的事情。等数据结构做完善、做稳定了，UI、业务逻辑等内容，随意换。

发表于 | 分类于

上午搞定了 Today Extension 剩余部分，最喜欢的就是上图中的切换列表的交互。至少我是没在别的应用中见到，这个微微的创新，让我有些开心。

下午搞定了目前已知的较严重的问题，以目前的状态，基本可以发 Beta 2 了，预计在下周，苹果发布会之前。

接下来最麻烦的就是内购模式了，想了好几种模式，也跟用户深入讨论过，依然没有确定。哎，收个钱，咋就这么难？