你的下一个应用，未必是程序

一、程序的谢幕与应用的崛起

在我接受电脑启蒙的时候，Windows 98 还是国内装机的主流。对当时的我来说，系统里最有魅力的莫过于「开始」下的「程序」（Programs）菜单。IE 浏览器、Office、画图——「程序」菜单就像一个包罗万象的百宝箱，里面的每个「程序」都是值得探索的宝藏。随着系统升级到 Windows XP，「程序」变成了「所有程序」（All Programs），MSN、Movie Maker 等新花样也加入其中。

「程序」的使命终结于 Windows 8。这代颇为激进的系统不仅取消了开始菜单，代之以磁贴风格的开始屏幕，也用「所有应用」（All apps）取代了「所有程序」。不仅如此，系统各处涉及「程序」的措辞，都被查找替换似地「升级」成了更时髦的「应用」。Windows 8 折戟后，微软在 Windows 10 中有所收敛，把开始菜单等传统设计还给了用户，但「程序」一词却留在了历史中，只在控制面板等残留的旧组件中才能看到了。

从「所有程序」到「所有应用」
从「所有程序」到「所有应用」

留心观察，「应用」取代「程序」之势并不只发生于 Windows 系统中，在其他科技语境以至日常沟通中都是如此。但如果要考究「应用」与「程序」（以及另一个相近概念「软件」）究竟有什么区别，似乎也很难给出一个准确的答案。

不妨先看看词典和百科怎么说。概括而言：

  • 程序（program）：是可以被计算机执行的一系列编码指令。
  • 软件（software）：是计算机系统中的非物理部分，包括程序、库（library）及相关的数据、文档、媒体等。
  • 应用（application，常缩写为 app）：是「应用软件」的简称，指用于执行特定任务的软件，与「系统软件」相区别。

可见，尽管常被混用，三个概念的侧重仍是各有不同的。「软件」强调「非物理」的属性，可以指可执行的代码、也可以指不用于执行的文档等；其中可执行、用于完成实际任务的才是「应用」。另一方面，「程序」强调代码的可执行性，也未必直接面向用户；一个应用可能是由无数个只具有抽象功能的程序模块组成的。

再看辈份，《牛津英语词典》中，三个单词的在计算机领域的最早例句分别见于 1946 年（program）、1959 年（application）和 1960 年（software），相隔不远。就连让人感觉更时髦的缩写「app」也年届不惑。1981 年，就有科技公司雇主在《Computerworld》杂志（已停刊）的招聘版上刊发广告…

用自定义属性功能管理 Word 文档中的「待定内容」

在使用 Word 制作合同等格式文本的过程中，经常会需要处理一些「待定内容」，例如签署方的全称、签署日期等。对此，常见的处理方法是用「[*]」、下划线等方式做标记，等确认后再填上。

这种方法是有很多缺陷的。如果待定内容很多，逐个输入这些「标记」和事后查找替换都很麻烦，而且容易遗漏（更别提它们真的很丑）。有什么办法可以更方便地插入、管理和更新这些待定内容呢？换种问法，Word 文档中有没有什么合适的地方存放这些信息呢？

Word 文档的「属性」（properties）功能就是这样一个理想的容器。

提到 Word 文档属性，我们一般会想到创建日期、修改日期这些文件系统属性，或者作者、标题这些文档标准属性。但实际上，Word 也支持用户创建「自定义属性」，其名称和值都可以自由设定。不仅如此，Word 还提供了专门的文档属性设置界面，相当于附赠了「待定信息管理器」的功能。

进一步想到，域（Field）功能可以读取文档属性的值、插入到正文中，并且具有自动更新的特性；两者结合，就是我们需要的解决方案。

假定我们正在起草一份协议，其中甲乙双方的名称和签署日期都是待定的，并且将在协议中反复出现。我们先尝试手动将这些信息添加为自定义属性，然后通过域插入到文档中。

首先，单击「文件」>「信息」>「属性」>「高级属性」（对于 Mac，单击「文件」>「属性」），然后切换到「自定义」选项卡。

然后，在「名称」框中，为自定义属性键入一个名称。例如，对于甲乙双方的名称，可以分别命名为「partyA」「partyB」等；对于签署日期，可以命名为「ExeDate」。

接着，在「类型」列表中选择数据的类型，然后在「值」框中输入属性的值。例如，甲乙方的名称应该是文本，而签署日期应该选为日期。

需要注意，日期类型的数据必须以系统当前区域设置对应的日期格式输入。对于简体中文系统，这个格式一般是 yyyy-MM-dd（形如 2021-01-10），而英文系统则一般是 M/d/yyyy（形如 1/10/2021）。如果你不能确定，可以到 Windows 系统的「设置」>「时间和语言」>「地区」下的「地区格式」，或 macOS 的「系统偏好设置」>「语言和地区」中查看。

接下来，我们通过域将自定义属性插入到正文中。点击「插入」>「域」，然后在弹出的对话框中选择 DocProperty 域，并在域代码输入框中通过 DOCPROPERTY "自定义属性名称"…

Mac 迁移指南

引言

苹果今年为 Mac 产品线带来了不少有意义的更新。适逢年末，不少人可能已经有了升级换新的计划。

但在享受新机带来的喜悦同时，还有一件不得不做的麻烦事——数据迁移。尽管听起来只是初始设置中的一个步骤，但数据迁移的效果很大程度上影响到新机的使用体验和之后的工作效率，因此须加重视。苹果官方有一些指导教程，包括出售、赠送或折抵 Mac 前应该执行的步骤，如何将内容迁移到一台新的 Mac 等，但都略嫌简略，不足以解决迁移过程中的很多常见疑问。

对此，本文准备结合自己几次迁移的经验，从可选途径、考虑因素和具体步骤等方面介绍在 Mac 间迁移数据的方法，希望能为有此需要的读者提供帮助。

由于本文较长，为查阅方便，文中涉及的关键步骤如下图所示（或下载 PDF 版）：

一、可选途径

（一）使用「迁移助理」工具

作为系统内置和官方推荐的工具，迁移助理是大多数情况下最简单、效果最好的迁移方式。

迁移助理
迁移助理

迁移助理的使用方式很多样：既可以作为初次开机时「设置助理」的一个步骤运行，也可以在完成初始设置、进入系统后单独运行；迁移数据的来源可以是另一台通过雷电、USB 或无线网络等方式连接的 Mac，也可以是外置磁盘上的 macOS 安装或时间机器备份。

但是，和大多数苹果系统的内置功能类似，迁移助理同样具有简洁度有余、灵活性和信息量不足的缺点。在迁移范围的选择上，除了少数几个语焉不详的选项，用户并没有太多定制的空间，迁移过程中显示的进度条和时间预测也基本属于娱乐性质。

此外，迁移助理能否成功运行有一定运气成分，在 MacRumors …

在 M1 芯片 Mac 上使用 Homebrew

Homebrew 是 Mac 上管理软件包的最实用工具之一。但截至目前，它还没有对搭载 Apple silicon 的新 Mac 机型完成适配。根据维护者在 GitHub 上发布的说明，Homebrew 正在积极适配新架构的过程中，但目前还面临一些较大障碍，如缺少基于 ARM 架构的持续集成框架、很多软件包依赖的框架或编译器（go、gcc、qt）未适配等。

但是，Homebrew 目前在新 Mac 上仍然是可用的，并且已经发布了原生支持 ARM 架构的试验性版本。本文总结我在设置过程中探索出可行、相对实用的做法。

概括而言：

  • 在不同路径分别安装针对 X86 和 ARM 架构的两个 Homebrew 版本；
  • 优先使用 ARM 版 Homebrew
…

译文 | 雪埋

（本文原载于《纽约时报杂志》2020 年 11 月 8 日刊，题为 Snowed Under，作者为 Sam Anderson。）

"插图/Najeebah Al-Ghadban"

在 2020 年求生，意味着活在两个相互矛盾的时间线里。一边是没完没了的现实。「喂！喂！喂！喂！喂！」2020 不停地冲着我们的脸喊道，像个不在乎人感受的恶霸教练。然而，我们又感到正被拖入历史的深渊。我们现在度过的阶段，显然应该写进公民生活课本中最悲惨的章节。受苦受难的同时，我们也意识到自己的喘息和崩溃，会在事情消停后的未来成为有心人归档、研究的对象。我们因而感到如此错位。我们变成了活化石，自视也已成古物，但痛苦不知为何还是纷至沓来。

上个月间，我把同一段爆款视频从头看到尾、从尾看到头，当作应对痛苦之道。这不是一段竞选广告，也不是当红议员志得意满的精华剪辑。恰恰相反，这是一段旧日法国人打雪仗的简短剪辑。它是 2020 年我最喜欢的电影，是一份短小精悍的佳作，精准地提炼出我们当下的骚乱，更重要的是，也反映出困惑我们的时间错位感。

这段录像由卢米埃尔兄弟于 1897 年在里昂拍摄，他们是世界上最早的一批电影摄制人。自然，原版录像是黑白的，而且因为帧率低而卡卡顿顿。不过，这场雪仗视频最近被做成了全彩流畅版，重制效果惊人的现代化。

视频展示了 52 秒的欢快厮杀：群龙无首的老派法国人捏紧雪球，互相砸向对方的脸，力道惊人。尽管很难在这样的混乱局面中数清人头，画面中差不多能看出 15 个人：男人穿着西装、戴着帽子，女人的衣袖又长又宽、裙子外面套着围裙。参战者隔街而站，路边行道树耸立；但没过多久，他们就已糊成一团。这就好像是超级英雄电影结尾的大战场景——一场精编细排的大混战，一支表现毁灭的芭蕾舞。参战者转身、躲闪、弯腰装填弹药；时而组成联军，旋又解散；雪球迸，人首隐，勇士仆。

如果你跟我一样，愿意下半辈子里翻来覆去地观看这场雪仗，就会发现一些与众不同的角色。

画面左下角，一个留着粗黑胡子的壮实男人打出了胜之不武的一球：一发从近距离全速掷出的猛击，差点命中预定目标——一个忙着望向另一边的瘦子。瘦子转过身来，抡起左臂，痛打大个子的大腿。

从那以后，两人就陷入了野蛮而欢脱的搏斗。他们多次捡起雪球掷向对方，但最终，或许是被彼此迸发的同性相争本能所控制，大个子蹒跚向前冲去，扑向瘦子，就像熊扑向一只鹿。但他再次扑了个空：瘦子侧撤一步，咧嘴一笑，把大个子推倒在雪地里。大个子一跃而起，像个留胡子的雪地僵尸，又开始从背后向瘦子投出雪球。

我最喜欢的角色、也是这段视频中最接近主角地位的，是一个戴着礼帽的男人。他的大衣长到裹住双腿，宛如悬空巫师的长袍。这打扮仿佛刚从银行家的会议上走出来，但他却放下身段，急切而兴奋地投身这场孩子气的街头大战中。

与其他基本伫立原地的参战者不同，礼帽男的活动地盘大得惊人——像个没签球队的球员，四处大摇大摆，移动缓慢但不失轻盈，在人群中钻进钻出，横越马路，随兴所至，胡乱出击，不走寻常路地侧臂掷出一球。他砸的多，被砸的似乎也一样多。到视频结尾，黑色大衣已沾满粉雪，雪球撞击的痕迹在上面像弹痕一样清晰可见。

那辆自行车也值得一说。这是全场最残忍的时刻，整群人都丧失了集体理智。视频一开头，就能看见一个人骑车靠近：最初占据很小画面，然后一秒秒放大，斜向高速掠入战局。还没接近人群，远射炮就开始向他开火。但他不为所动，继续骑他的车。等他到场，所有各自为战的派别都联手起来，以他为目标，极其精准地投出一阵弹雨。骑手的臂部、脸部、背部、颈部都受到重创。然而，他还是踏车前行，弓着背，长腿踩得飞快——像一个坚忍的英雄，一心要冲出暴乱，抵达安全的彼岸。

但他没能冲出去。负弹过多的骑手跌落在地，像个散架的玩具。

他四脚朝天，帽子倒杵雪中。还没能起身，就又被炮击，还有人打算偷走他的车——但骑手站了起来，抢回车跳上去，弃帽子不顾，踏车原路撤退，一路吃下雪球的狙击。这是关于徒劳无功、宏愿受阻的尖锐一课——匹夫的远见怎样毁于众人骤然的失智。

中景距离外，两个男人站在街灯边，一动不动地观看着这场骚乱，宛如贝克特（20 …

Apple Watch 指针表盘 —— The Missing Manual

尽管 Apple Watch 的各个表盘总体延续了苹果软件上手即用的家族特征，但其中仍然存在简洁与复杂的风格之分。特别是有几个包含多种子表盘、刻度的指针表盘，其功能和用途并不是一目了然的。

遗憾的是，或许是为了把更多笔墨留给健康检测、运动记录这些「智能」味更浓的功能，Apple Watch 官方使用手册的「表盘与功能」章节非常粗略，只是以流水账形式列举了表盘的造型和功能，具体操作方法则都留给用户自己脑补。而网上的 Apple Watch 和 watchOS 评测虽然数量繁多，但也基本都对表盘一笔带过，或者照抄苹果在发布会和文案中的描述。

作为一个缺少机械表背景知识的用户，我对 Apple Watch 中的复杂表盘一直是一知半解的，watchOS 近来新增的正计时、GMT 等表盘更是让我一头雾水。在向使用手册和评测文章求助无门后，我只好走上了自学之路。以下就是我的自学笔记，希望对同样困惑于 Apple Watch 复杂表盘具体用法的读者有所帮助。

计时码表（Chronograph）

计时码表是 Apple Watch 最早的内建表盘之一，其布局在机械表中也属常见设计，但 Apple Watch 的版本仍然借助数字化的优势提供了更多灵活性。

默认状态下：

  • 外圈刻度、时针和分针与常规表盘相同；
  • 秒针静止，始终指向 12 点方向；
  • 两个小表盘中，12 点钟方向的表盘静止，6 点钟方向的表盘指示当前分钟的秒数。

轻按表盘右上角的按钮，表盘将进入…

开源、可定制的网页批注工具——Hypothesis

引言

俗话说「不动笔墨不读书」，但在网络阅读的场景下，给「笔墨」找到合适的电子替代物并不容易。尽管市面上存在不少批注网页文章的解决方案，但仔细想来，似乎很少有哪个工具能较好地同时满足以下几个要求：

  • 跨平台：电子阅读的场景非常宽泛，理想的工具应当在各个平台上都能使用。
  • 可溯源：批注内容往往需要和原始上下文结合才便于理解。因此，理想的工具不仅应该记录批注的内容，还应该能追溯到批注在原始文本中的位置。
  • 可迁移：批注的主要意义在于事后参考引用。为此，理想的工具应当允许将数据以通用格式导出，最好还能提供 API 以便对接其他工具和实现自动化。

究其原因，上述目标在网页环境下中并不容易达成，甚至是相互矛盾的：不同平台的功能和交互逻辑各异，很难开发出通用的解决方案；网页文本很不稳定，其内容和格式经常随着编辑、改版而变化。因此，为实现跨平台和可溯源，大多数产品都选择了牺牲可迁移性，以私有格式存储批注数据，并且批注的对象往往并非原始网页，而是其经过优化和重排版后的「替身」。

Instapaper 等主流工具一般是在创建的网页「替身」上实现批注

不过，今年早些时候，我偶然发现了一个名为 Hypothesis 的工具。这是一个开源项目，注册和使用完全免费，收入主要通过为教育行业定制 LMS（学习管理系统）支撑。

与 Pocket、Instapaper 等知名服务相比，Hypothesis 给我的最初印象是其貌不扬、界面简陋，且上手门槛较高。但在熟悉操作后，我发现它正是一个能较好兼顾上述三个理想特性的工具。

概括而言，Hypothesis 实现这些特性的方式是：

  • 跨平台：Hypothesis 没有客户端，其功能主要通过小书签（bookmarklet）访问。打开任何网页后点击该书签，就可以加载 Hypothesis 的代码、启用批注，回避了针对各个平台安装专用客户端的麻烦。此外，它还提供了一个代理入口 https://via.hypothes.is/，通过该入口访问网页后可以直接开始批注。
  • 可溯源：Hypothesis 在批注时不仅会记录批注内容，而且会通过多种方式记录批注在原文中的位置（下文将会详细解释），这使得即便网页内容发生较大变化，它仍然能准确定位。
  • 可迁移：Hypothesis 提供了完善的 API，可以结构化地导出所有批注数据。此外，Hypothesis API
…

让人在尽调中心情好一点的命令行小工具

如题，目前能想到的，可能不定期更新。

tree

场景：对方扔过来一坨文件，老板问，他们都提供了啥？

错误的做法：一个个点开看。

好一点的做法：tree /path/to/LDD_docs -N

输出：

.
├── 1、股权
│   ├── 母公司
│   │   ├── 公司章程.pdf
│   │   ├── 营业执照.pdf
│   │   ├── 工商调档单2019.rar
│   │   └── 组织架构图.pdf
…
├── 2、业务和合同
│   ├── 2020年
│   │   ├──
…

小议超链接的规范使用

超链接是互联网最突出的功能之一，添加超链接也是所有网络用户需要掌握的基本功。

然而，「会用」超链接并不等于能「用好」超链接。或许是因为操作太过容易，我们在添加超链接的时候往往颇为随意，而不会仔细考虑做成超链接的内容和地址是否合理。

回想一下，你是否遇到过下面这样的超链接用法，或者自己这样用过：

  1. 将操作指示作为链接文本：「点击这里」「查看相关信息」「🔗」
  2. 将网址作为链接文本：http://example.com/
  3. 为连续的词语添加超链接作为列举手段：「苹果在过去几个月和开发者可谓 冲 突 不 断。」
  4. 将一长串话作为链接文本。

这些用法都是值得商榷的。

超链接的正确用法并不是个新话题。早在 2004 年，谷歌工程师 Jed Hartman 就撰文讨论过链接文本的合理用法；上面列举的几种不当用例正是来源于该文。

一些开发文档也涉及了这个问题。谷歌的《开发文档风格指南》（Developer Documentation Style Guide）就为此专设一节，并指出链接文本应该「描述读者点击链接后将会看到的内容」，如被引文档的标题或对其内容的描述。Mozilla 维护的 MDN 文档库也讨论了「链接最佳实践」（link best …

The “Big Tech” Congressional Hearing: Things to Know

引言

美国东部时间 7 月 29 日下午，一场题为「调查亚马逊、苹果、Facebook 和谷歌的支配地位」、持续五个半小时的听证会在美国社会的广泛关注下召开。

这次听证会最吸引眼球之处当然在于其「豪华阵容」。美国四家科技巨头的 CEO——亚马逊的贝索斯（Jeff Bezos）、苹果的库克（Tim Cook）、Facebook 的扎克伯格（Mark Zuckerberg）和谷歌的皮采（Sunder Pichai）罕见地汇集一堂（尽管是通过远程视频），接受立法机关的问询。

不过，针对这场听证会，现有报道似乎更多着墨于议员与 CEO 的交锋、曝光的垄断「实锤」（smoking gun）等细节片段，而对于举办听证的前因后果着墨不多；同时，中文网络上也暂时没有看到较为详细的报道。为此，本文准备以问答的形式，就本次发布会的性质、背景、内容和影响等方面作出个人角度的分析，供有兴趣的读者参考。

一、听证会是由谁举办的？

举办本次听证会的是美国众议院的反垄断、商业和行政法子委员会（Subcommittee on Antitrust, Commercial and Administrative Law）。

美国国会参众两院均将其立法、监督等职能分配给下辖的若干委员会，以提高运行效率、负责专门工作，并发挥议员在不同领域的专业经验。目前，参议院有 21 个常设委员会，众议院有 20 个常设委员会。委员会内部又可进一步分出子委员会。本次举行听证的反垄断子委员会，就是隶属于众议院司法委员会（House Committee on the Judiciary）的子委员会。

众议院委员会的成员在程序上由众议院全体会议指派，但实际上由两党各自选派，并往往最终取决于议员的个人选择。大多数委员会的席位分配与两党在众议院的席位比例接近。目前的反垄断子委员会由 …