混沌周刊 #13 | 当个做题家

大家好,又来到了新一期的《混沌周刊》。因为身体原因,上周没有太多时间更新。到目前为止,已经欠更四期了,希望这个数字不会越来越大。

Apple在上周发出了新一年发布会的邀请函。还是由于疫情原因,只能在线上举办。如果没有意外,Apple这次的新发布会主角将会是传言中的iPhone 13,巧合的是,本期刚好也是第13期。每年各种发布会前,都会有各类媒体对Apple将要发布的产品做预测。不过,除了好奇ProMotion在iPhone上将会有什么特别体验之外,好像我们能期待的东西也确实不太多。iPhone也许真的渐渐成为Apple产品线中最无趣的那个1。所以我们就不多聊了。有意思的其实是,他们的Twitter首页只会有一条,或者没有内容,在各大品牌中实属很独特的做法

✏️ 不如做题

做题家」一词早已有之,但去年方才随着「内卷」在大学生和社会人中火起来。其本意乃嘲讽应试教育体系下深信「书中自有黄金屋」的一批人,当走向社会面临多元化且不公平的评价体系时,表现出的手足无措。这种批评实在说来轻巧。「做题获得一切」的价值观,对于身处学生时代的人,尤其是身边人皆有相似信仰时,实在太有吸引力了。踏入工作后,我们时常走向这一价值观的反面,摈弃一切做题、理论,和深刻的学习,以绝对的实用主义取而代之。

但做题这件事,还是有特别意义的。做题考试的本质,是将宽泛的考核标准,量化为一套高度可执行的方法。在这种方法下,学习的每个阶段都能够得到快速且明确的反馈。我们不再一定需要博古通今的精英教授引路。因此基于做题的学习路径,是自学者的福音。

你有多久没有在OJ上做过编程题了呢?或许可以打开LeetCode,做几道题,找回纯粹的做编程题的感觉。这种反馈真切而又及时。编程是需要手感的。如果你是奥运冠军,那么可能不太需要某些基础的健身训练。但我们不是,而且随着年龄增长,会意识到自己可能终其一生都无法达到那种境界。但没关系。做一个普通人,有时候很难;但超越普通人,有时候也会很简单。

说起LeetCode,不妨再稍微总结一下它的三种难度:

  • Easy题目多数不会涉及某些具体的算法,多数是写一个适应各种边界条件的逻辑正确的程序,适合练习编程手感;
  • Medium题目往往是针对某类数据结构和算法的练习,因此它其实不一定比Easy难,但这些数据结构和技巧都应该是合格工程师应该掌握的;
  • Hard难度也未必比Medium难,之所以叫Hard是因为可能还需要某些特定知识(比如自动机),或者在实现上有一些复杂度。很多题目会前后构成一个系列,从Easy到Hard,很像常规面试中的follow-up,对大脑也是种锻炼。

Anyway,有时候转变思维,当半天做题家,好像也不错,是吧?

👊 Apple vs. Epic

这桩案子目前有了初步判决。双方都有得有失,但总的来说Apple赢得更多:

  • App Store不构成垄断,iOS平台可以继续保持App Store的独占渠道;
  • App Store可以继续保持30%的分成;
  • Epic Games需要向Apple支付之前因没有通过IAP通道而「欠」Apple的三百多万美元;
  • Apple不能阻止开发者通过其它渠道向用户提供交易。

Epic对判决表示不服,要求上诉。如上一期聊到的,强制IAP渠道的逐步瓦解,应该是趋势了。

🤖 对生产力软件的进一步思考

在过往的几期中,我曾经提到对生产力工具2 未来方向的一些设想。技术的发展方向是个螺旋。几十年前成熟的GUI编程理念,换身行头便又成了Web前端圈热衷的宠儿。Web App的出现的确方便了生活,但它们也有不少问题。有同步就必然有隐私风险。我们需要的不仅是更流畅的Native界面,还有站在用户角度,对数据的完全控制。

但凡大一些的科技公司,对员工数据安全的要求都非常严格:哪些网络平台不能在工作中使用,哪些平台不能用于存储工作资料,都会是反复强调的要求。但目前流行的这些软件,普遍对此考虑甚少,通常是登录某个账号才能使用,然后一个本地数据库和账号的云端数据库持续同步。(例子:Microsoft To-Do)在这种情况下,软件的数据库不仅不对用户直接可见,用户也无法控制数据的存储方式。

我们能否借用电子邮件中的概念,把数据划分成多个独立的数据源,分开存储,然后在显示的时候合并到一起?比如用户可能有某部分资料不需要同步,就将其移动到一个单独的本地数据库;而剩下的大部分资料,会持续地和云端(比如CloudKit,或者自建服务)同步。这些资料在显示时就像邮件客户端中「所有收件箱」一样合并在一起。这样做的好处有:

  • 由于不同数据源的存储格式相同,因此我可以随时把一个数据源中的部分数据移到另一个数据源;
  • 数据同步的核心动作是push而不是fetch,主体在本地,所以将一个数据源切换到另一个同步源也会非常容易;
  • 本地和同步数据库可以并存,不会造成数据安全风险。

不过,这种模式并不会增加额外的商业利益。只能期待有某种可复用的开源架构帮助实现这一切了。

在未来的更新里,我们还会继续聊到这些发展方向上的思考。如果对你有启发,或者存在不同意见,欢迎评论:)

📰 网事趣闻

  • Programming Idioms. 很有创意的一个网站,列出了各种常见的代码片段(比如,将一个整数转换为16进制字符串),并包含了大量不同语言的实现。
  • DHH说,Rails 7将会给JavaScript带来三个很好的答案。在Rails 7中,Webpacker(Rails对Webpack的封装)将会被更轻量的方案替换掉。天下苦Webpack久矣了吗?
  • 开源协议的新方向:PolyForm协议(日文)。我简单搜索了一下,发现中文世界提到这个新许可证的内容还很少。简言之,PolyForm是一组不同等级的新开源许可证,核心理念是不再强调传统意义上「绝对的自由」,而是对一些方面作出限制,比如只对小公司或非商业用途有效。感兴趣的朋友,可以结合本刊第五期了解这些新许可证诞生的背景。
  • Apple暂停了此前备受争议的客户端照片扫描计划
  • 一段介绍UTF-8/UTF-16/UTF-32等编码格式的内容。实际上,这是一组介绍如何在工作中(编程、数据库、操作系统)和Unicode打交道的文档,推荐阅读。
    • 关于UTF-8,大家已经很熟悉了,即一种兼容ASCII的变长字符编码。
    • 对UTF-16,简要总结:UTF-16最初尝试用2字节编码每个字符。Unicode最初计划的编码范围是0-0xFFFF,2字节可以完整表示。但后来这个范围扩展到了0-0x10FFFF,2字节已无法完整容纳。因此UTF-16也可能是变长的。需要两个单位表示0x100000-0x10FFFF的情况被称作代理对 (surrogate pair)。
    • UTF-32用4字节表示每个字符,因此依然可以保证每个字符都能对应到某个单独的单位。
  • 在Modern C++的潮流(最新的标准是C++20)之外,也有人提出反对的声音:或许我们的C++代码应该保守一点,至少不应该使用5年内通过的标准。

这一期就到这里,那我们下期再见吧!

1 在国内,也许还可以加上一条——售后最差的那个。
2 生产力工具的外延很大。其实只要能让你工作和生活效率有提高的软件都可以叫做生产力工具。不过通常提到这个概念时,指的往往是诸如日程提醒、笔记写作等工具。


发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注