估计,也只有程序员才能理解,这句话的意思是:
「等我把这个版本发了,一起去吃饭」
今天,依然在赶 iText 开发的进度;其中,大部分时间都花在和功能无关的功能上:新用户引导、免费+内购模式。其实,我挺不愿意把时间花在这些地方。无奈,这些也都是一个成熟产品必备的功能。
明天,如果能有 10 小时完整的时间可以工作,应该就可以提交 iText 到 Mac App Store;够呛,争取吧。
独立开发,自由职业
估计,也只有程序员才能理解,这句话的意思是:
「等我把这个版本发了,一起去吃饭」
今天,依然在赶 iText 开发的进度;其中,大部分时间都花在和功能无关的功能上:新用户引导、免费+内购模式。其实,我挺不愿意把时间花在这些地方。无奈,这些也都是一个成熟产品必备的功能。
明天,如果能有 10 小时完整的时间可以工作,应该就可以提交 iText 到 Mac App Store;够呛,争取吧。
原计划周五晚上提交 iText 到 App Store,不过,看目前这架势,至少落后了 1.5 天。
落后了,心里肯定着急。可越着急,越容易出错、效率下降。可是,又怎么能不急呢?矛盾。
不过,好在 iText 识别结果的对话框优化的差不多了,晚上发出去的版本,也受到了用户的好评,这点还是开心的。
今天早点睡,明天早点起床代码。
今天重新设计了 iText 识别文本后的窗口,基本上一天的工作都和窗口有关:
还有很多事没做:
没想到,一个小小的程序、一个简单的窗口,有这么多事要做。
今天在改进 iText 上传前压缩大图的功能。
其中,百度、腾讯、Google 等各家 OCR 服务对上传的图片尺寸都有要求、也都要求对图片进行 base64 压缩。可这要求跟要求可就不同了。
服务 | 简易理解图片大小 | 实际可用大小 | 计算方式 |
---|---|---|---|
百度 | 4 MB | 1.5 MB | 4 / 2 / 1.3 = 1.5 MB |
腾讯 | 1 MB | 0.5 MB | 1 / 2 = 0.5 MB |
4 MB | 4 MB | 4 = 4 M |
为什么实际大小与简易理解大小不一致呢?
既然 base64 会带来计算上的麻烦,为什么不直接使用解压后的图片大小呢?没错,Google 就是这么干的。你无需考虑 base64 带来的尺寸增加,也无需考虑一个字符串到底占几个字节,只要原图是 4 MB 以下即可
从这一点上看,服务接口的素质(公司的节操)顺序为:
Google
> 腾讯
> 百度
我自己有写文章的习惯;尤其,发布一款产品后,我会写些长文,记录产品诞生的整个过程。例如,我之前写的:
这次,有朋友提:干嘛不在 GitChat 等类似的平台,开个 Live 或者文章付费阅读?我想想也是,既能带来点收入,还能增加点曝光,对自己的品牌建设也有一定的好处。
于是,就有了《如何独立开发一款 macOS 应用:从概念到上线》
在这场 Chat 中,我将详细为你介绍:
第一手、最新鲜的细节,仅此一家;
别的产品,你绝对无法了解这样的细节。
等你来。