为家人做选择时,在能力范围内,选择最好的。
不然,各种努力,又为了啥呢?把钱花在这个地方,不是最有价值的吗?
独立开发,自由职业
为家人做选择时,在能力范围内,选择最好的。
不然,各种努力,又为了啥呢?把钱花在这个地方,不是最有价值的吗?
Klib 中有个「分享」功能,就是把自己某本书的标注分享成网页,比如 这篇
从开发的角度,这个功能很复杂,有单独维护一个服务器,接收来自 Klib 的分享、取消分享、更新分享内容、权限管理,还要考虑 CDN 分发、分发内容的及时更新,等等。
截止目前,从性价比来看,这个功能并不高。收益一般,维护成本很高;只要有 1 位用户在使用,就要保持这个服务 100% 在线。时间长了,当对服务端的代码不熟悉时,一旦有问题,就要花很多时间来修复。
当初,自己是为了学习 Python 后端开发,并尝试下分享,才上的这个功能。从学习的角度,这是好的。而从产品的角度,则很难说。
不过,反过来,如果总是做很简单的功能,且不说长期对自己的成长不利,即便从产品、从商业角度,也缺乏必要的护城河,很容易「被致敬」。而如果分享功能正巧很多人在用、带来很多收益,这个相对复杂的功能,就一定程度充当护城河,不那么容易被抄袭。
初期,可以「取巧」,用最小的代价,换取最大的收益。
而随着自己的成长,需要考虑壁垒,需要「守正」;用不断提高的门槛,保护自己的领地。
本来,今天挺好的:新版 iText 审核通过,Klib 的暗色模式也实现完毕。可,无意间发现之前填下的一个大坑,心情顿时跌入谷底。
之前的代码中,用哈希值作为 key 值…
哎,我怎么会写出这样的代码…
哈希,主要是确定不同,而不是确定唯一性。换句话说,哈希主要是为了毕竟 2 个值是否不同(当然,极低概率下,哈希相同的 2 个值,可能也是不同的);而同一个原始值的哈希值,是很有可能变动的。比如,操作系统升级、Swift 运行环境升级等等因素,都有可能让基于 Swift 编写的哈希值变更。
主要的麻烦是,产品已经发出去了。要升级,必须保证已有用户的已有数据不受影响,这个挑战是非常大的。还好当时自己在数据库中冗余保留了原始数据,还有机会根据原始数据重新生成有唯一性的值,比如 MD5 值。
哎,再骂一次当年的自己,怎么那么年轻…
昨晚,苹果更新了几乎除 iPhone 之外的产品线。
外界质疑苹果创新乏力,苹果用 Amazing 否认;
外界批评苹果赚取暴力,苹果笑而不语。
恩,公司是你的,你确实可以为所欲为。
可是,苹果什么时候开新产品线呢?
1995 年,乔布斯在接受采访时曾说:“毁灭苹果的不是增长,而是他们变得非常贪婪。”
搞了很久的 js/node 开发后,现在开始更新基于 Swift 的项目,感觉很吃力;尤其 Swift 版本间差别很大。
很不喜欢这样的感觉。坚决收窄技术面,目前暂定为基于 js/node 的后端,并稍微涵盖前端。
最重要的是解决问题的能力。而解决问题,需要趁手的工具。工具无论好坏,重要的是趁手、效率高,拿起来就能干活,而不是边干活、边搜索工具怎么用,这太 Low 了。