Authorplatyhsu

译文 | 雪埋

(本文原载于《纽约时报杂志》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)的子委员会。

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

你说的框是什么框——理解 PDF 中的五种页面边界

最近工作中,我经常遇到需要裁剪 PDF 页面的情况。例如,收到的扫描版 PDF 文件不是标准的 A4 尺寸,而是有些多余的白边需要裁掉。

过去偶尔需要裁剪 PDF 时,我一般会通过 macOS 自带的预览 app 实现:用标记工具栏中的「矩形选择」工具选中要保留的范围,然后按 ⌘K 就完成了裁剪。(PDF Expert 也有类似功能。)因为步骤简单,我也没有多做研究。

这周,因为裁剪 PDF 时需要更精确地控制尺寸,我第一次尝试用 Acrobat 完成裁剪操作。结果,第一步就被卡住了:Acrobat 的裁剪界面(「设置页面框」对话框)选项繁多,甚至还要求选择将裁剪范围应用到哪个「框」上:裁剪框、作品框、裁切框还是出血框?

放过我……
放过我……

拜托,我就想裁个文件,你搞这么多框框是几个意思?

抱怨归抱怨,为了饭碗,还是有必要花时间研究一下。Acrobat 在使用手册中描述了「设置页面框」功能,并介绍了几种边框的区别,但仍然不够详尽。因此,还是有必要直接翻翻 PDF 格式的「辞海」——Adobe 以 PDF 格式标准为基础、补充自家实现细节的《PDF

WWDC 2020——关于 Mac 未来的半成品答卷

引言

一届形态空前的 WWDC 在不久前落下了帷幕。尽管被迫迁移到了线上,但今年 WWDC 的水准和信息量都被广泛认为更胜以往,现有的各个系统都获得了不同程度的优化改进。

不过,要论本届 WWDC 上最受关注的主角,恐怕还是 Mac 平台——架构迁移、框架更新、设计换代,苹果可谓从里到外为它换上了新装。对于刚刚走出「键盘门」阴影不久、仍在因软件质量下滑备受诟病的 Mac 平台,这不可不谓一针强心剂和一场及时雨。

Mac 平台是本届 WWDC 当之无愧的主角
Mac 平台是本届 WWDC 当之无愧的主角

然而,「新」的并不总是「好」的。过去两周,在浏览相关讲座、文档和社群反馈后,我的体会是:本届 WWDC 上针对 Mac 的大量更新固然令人兴奋,但仍然留下了很多不确定因素,并不足以解决 Mac 平台近年面临的问题。尽管表达出了充分的诚意,但在 Mac 平台的发展问题上,苹果在 WWDC 2020 上只交出了一张「半成品」式的答卷。

架构

首先不得不提的,自然是今年 Keynote 主题演讲上的压轴大戏——经过漫长猜测和期待的铺垫,苹果终于在 15 年之后再次更换 Mac 的硬件架构,从基于 Intel 处理器的 x86 …

用 Shell 脚本制作签字页

在我目前的工作中,一项常见但繁琐的任务就是制作文件的「签字页」。具体而言,这项任务包含如下步骤:

  1. 将 Word 格式的交易文件导出为 PDF 格式;
  2. 逐页提取 PDF 版中的签字页部分;
  3. 将单页签字页按照类似于 合同名称_SigPage_01_签署方名称.pdf 的格式重命名。
「签字页」
「签字页」

这些步骤本身都毫无难度,但逐个操作下来仍然麻烦且易错。特别是对于那些文件数量和签署方数量都动辄十几二十个的大型交易,制作签字页对体力、眼力和脑力都是挑战。

显然,这就给通过自动化来「偷懒」创造了很强的动机。

上述步骤中,第 1 步是最容易通过工具来省事的:有大把的图形界面软件(例如 Acrobat、WPS 等)可以批量将 Word 文件转换为 PDF,只要一股脑地选中需要转换的原始文件,等待转换完成即可。如果偏好使用命令行,还可以使用 docx2pdf(Windows 和 macOS 通用)、DocToOfficeToPDF(只适用于 Windows)等工具进一步方便批量操作。

但之后的两个步骤——分割页面和重命名——才是最耗费精力、却又不太可能找到现成的工具的。

之前,我虽然一直有 DIY 一个自动化方案的想法,但总是因为时间有限和自己懒等原因未能实现。但在今天又一次被制作签字页的任务羞辱之后,我终于决心长痛不如短痛,花了一个下午把这个想法付诸实践,而成果就是下面这段(简陋难看的)shell 脚本 sigpgs.sh:…

Word 文档导出为 PDF 时出现额外脚注

昨天在把一个合同从 Word 版本导出为 PDF 的时候,发现导出的 PDF 版总是会在页脚处多出一串代码(形如 XY&Z\12345.67),但在 Word 中并不能看到任何对应的文字。

打印时页脚自动出现的编号(文件内容和代码都是我乱编的)
打印时页脚自动出现的编号(文件内容和代码都是我乱编的)

虽然暂时不知道这串代码的意思,但看外观像是某种格式的文件编号。于是首先尝试搜索其中的字母部分 XY&Z,发现是某个律所的简称(全称类似 Xenos, Yanko & Zais, LLP)。

看来,这串字符确实是文件编号。剩下的问题就是它是如何出现的,以及怎么去掉。

考虑到文件编号只在导出成 PDF 时才出现,而导出 PDF 的操作基本相当于打印,便联想到 Word 中域功能的特性——打印时自动更新页眉和页脚中的域。于是再次进入脚注编辑界面并按 Option-F9 显示域代码,果然看到这串隐形文件编号的对应位置有一个域,代码为 { DOCPROPERTY"SWDocID" }

查阅 …