
在 Github 找到的 Final Cut Pro Trial [下载直链]，以及[试用续期方法]。

试用版和正式版的[区别]：

> Final Cut Pro Additional Content, which includes over 1300 royalty-free sound effects for use in your projects, isn’t available in the Final Cut Pro trial. The trial is fully-functional otherwise.

Final Cut Pro Trial 下载地址和续期方法


删除一个数字的小数部分，仅保留整数部分，有几种方法：

```js
const num = 10.5;
console.log(Math.trunc(num));
console.log(Math.floor(num));
console.log(num | 0);
console.log(~~num);
console.log(parseInt(num));
```

对于 bitwise 运算，数字会被转换为 two's complement 的形式，这时小数部分都会被忽略，所以 `num | 0` 和 `~~num` 都会返回整数部分。

---

相关文章：

- [js 的 setTimeout 支持的最大值](/note/202306080734)：这里提到 js 使用 32-bit 或 64-bit 的二进制存储数字，可以表示整数和负数，注意和 two's complement 的区别，js 不是用 two's complement 的形式存储数字，只是在执行 bitwise 运算时才会把数字理解为 two's complement 的形式；
- [~-10 为什么等于 9](/note/202306060903)：这里解释了如何把一个数字转换为 two's complement 的形式；

删除一个数字的小数部分，仅保留整数部分，有几种方法，对于 bitwise 运算，数字会被转换为 two's complement 的形式，这时小数部分都会被忽略，所以 `num | 0` 和 `~~num` 都会返回整数部分。

~~10.5 为什么等于 10


在 Node.js 中执行以下代码：

```js
setTimeout(() => {
	console.log('test')
}, 2147483647 + 1);
```

会提示：

```sh
(node:17462) TimeoutOverflowWarning: 2147483648 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
```

因为 js 的 single precision number 是用 32-bit 表示的，最大能表示 2147483647，不到 22 亿，`setTimeout` 只支持 32-bit 数字，如果给它提供了一个更大的数字，会一律视为 1，这会导致 `setTimeout()` 马上超时。

js 还有一个 `Number.MAX_SAFE_INTEGER` 变量，它的值是 `9007199254740991`，超过 9000 万亿，这是 js 的 double precision number 的最大值，采用 64-bit 表示，是最大的安全整数。

超过 `Number.MAX_SAFE_INTEGER` 的数字不能使用 `Number` 对象，而是用 `BigInt`，`BigInt` 的最大值取决于电脑的内存，如果内存无限大，`BigInt` 就没有最大值，或者说最大值就是无限。

之所以有 single precision 和 double precision 的区别，根据 stackoverflow 的[一个回答]和[另一个回答]，是为了更准确地表示 floating point number。所谓的 floating point number，其实就是小数，floating point 是小数点。

在 single precision number 中，小数点后只能精确到 7-8 位，而 double precision number 可以精确到 15-16 位，是 single 的两倍，即 double，这才是 double 的意思，而不是因为 64 是 32 的两倍。

---

相关文章：

- [~-10 为什么等于 9](/note/202306060903)：执行 bitwise 运算时，js 是把数字理解为 two's complement 形式再去执行运算，two's complement 不能表示小数；
- [\~~10.5 为什么等于 10](/note/202306080935)：因为 two's complement 会忽略小数部分；

js 的 setTimeout 支持的最大值是 2147483647，因为 js 的 single precision number 是用 32-bit 表示的，最大能表示 2147483647。

js 的 setTimeout 支持的最大值是 2147483647，为什么？

js 的 setTimeout 支持的最大值


[DoS] 是 denial of service 的缩写，意思是服务不可用。DoS 攻击是从攻击的目的或意图这个角度来命名的，意思是为了让对方的服务不可用而发起的攻击。

一个很出名的词是 DDoS，它是 distributed denial of service 的缩写，意思是分布式的 DoS 攻击。

这里说的是 ReDoS，意思是基于 Regex 发起的攻击。为了方便理解，我让 ChatGPT 给出一个 ReDoS 攻击的例子，当然我有所改动：

```js
import timespand from "time-span";
const end = timespand();
const input = 'a'.repeat(30)+'b'
const regex = /^(a+)+$/;
const match = regex.test(input);
console.log(match) //结果是 false
console.log(end()) //在我的 Apple M1 Pro 电脑上耗时 35s
```

上面这段代码，在我的 Apple M1 Pro 电脑上执行，耗时长达 35 秒。

假设你的应用有一个输入框，你的后端使用 `/^(a+)+$/` 对用户的输入进行正则处理，然后攻击者输入了 `aaa...(一共30个a)...aaab` ，那攻击者就会让你的服务卡住 35 秒。

如果攻击者输入了更多的 a，比如 10000 个，那你的后端可能会卡住很长很长时间，导致无法向正常用户提供服务，于是攻击者达成了他的 ReDoS 攻击。

所以作为开发者，要注意小心写书你的正则法则，像例子中的 nested repetition operators 是需要避免的，例如可以改为 `/^(a{1,10})+$/`，确保了 a 的数量不能超过 10 个。

另一种应对方法是，当发现正则处理耗时太久时，就直接让它超时：[sindresorhus/super-regex]

一种更好的做法是使用 [uhop/node-re2] 创建正则对象，不使用 Node.js 内置的正则引擎。

把例子中的 `const regex = /^(a+)+$/` 改为以下代码就没问题了：

```js
import RE2 from "re2";
const regex = new RE2(/^(a+)+$/)
```

这里说的是 ReDoS，意思是基于 Regex 发起的攻击。为了方便理解，我让 ChatGPT 给出一个 ReDoS 攻击的例子。你可以使用 re2 避免这种攻击，或使用 super-regex 让攻击超时。

ReDoS：通过 Regex 进行的 DoS 攻击

ReDoS：Regex DoS 攻击


[function-timeout] 是一个可以使同步函数支持超时的 npm 库，实现原理是把函数放在 [`node:vm`] 中执行，因为 `vm.Script()` 返回的 script 对象就支持传入 [`timeout`] 选项。

vm 是 virtual machine 的缩写，意思是在 Node.js 中创建一个虚拟环境，用来执行不希望在主环境中执行的代码。

创建一个 `script` 对象：

```js
const script = new vm.Script('returnValue = function_()');
```

`vm.Script()` 接收一个字符串，这个字符串就是即将要在 vm 中运行的代码，具体到上面这个例子，就是要在 vm 执行 `returnValue = function_()` 这段代码，即把 `function_()` 返回的结果赋值给 `returnValue` 变量。

那 `function_` 是什么东东？它是在哪里被定义的？

`function_` 是定义在 vm 的 context 中的，`context` 是一个重要概念，它本身就是 Node.js 的重要概念，所以也是 vm 的重要概念。

> All JavaScript executed within Node.js runs within the scope of a "context".

写一个 context 对象，在这个 context 中定义 script 需要用到的变量，这里只有 `function_`：

```js
const context = {
		function_: () => function_(...arguments_),
	};
```


然后执行 script，`runInNewContext` 意思是在新的 context 中执行代码，但需要告诉它 context 是哪个，另外正如开头所说的，它支持传入超时时间：

```js
script.runInNewContext(context, {timeout});
```

如果执行超时，Node.js 会抛出 `ERR_SCRIPT_EXECUTION_TIMEOUT` 错误码。

那怎么获得 `returnValue` 的值呢？`returnValue` 也是通过 context 获取：

```js
context.returnValue;
```



function-timeout 是一个可以使同步函数支持超时的 npm 库，实现原理是把函数放在 node:vm 中执行，因为 vm.Script() 返回的 script 对象就支持传入 timeout 选项。

读源码学编程：function-timeout

看源码：function-timeout


ANSI 是美国国家标准协会（American National Standards Institute）的简称，ANSI escape codes 是用来控制终端中的光标位置、文字颜色、字体样式等信息的字符串，因为它总是以 escape 字符为开头，所以叫 escape codes。

格式是 `\033[XXXm`，其中 `\033` 就是 escape 字符，`XXX` 是一个以 `;` 分隔的字符串，用来控制终端的显示，支持的各种字符可以参考 stackoverflow 的[这个问答]。

例如：

```sh
echo "\033[1;5;31m科技微讯"
echo "\033[3;4;6;40;37m科技微讯"
```

![](ansi_escape_codes.gif)

开源社区有两个 npm package 可以让你方便地生成所需的 escape codes：

- [sindresorhus/ansi-escapes]
- [chalk/ansi-styles]

[chalk/ansi-regex] 提供了一个匹配所有 ANSI escape codes 的正则法则。

ANSI 是美国国家标准协会（American National Standards Institute）的简称，ANSI escape codes 是用来控制终端中的光标位置、文字颜色、字体样式等信息的字符串，因为它总是以 escape 字符为开头，所以叫 escape codes。

什么是 ANSI escape codes


在 Github 上看到[一句话]：

> `~-` is the bitwise way to perform a `- 1` operation.

所以 `~-10` 就是 10 - 1 = 9。

为什么呢？

首先 `-10` 是一体的，`~-10` 表示对 `-10` 执行 `~` 运算。

`10` 的二进制数字是 `1010`，因为它是正数，所以在前面加 0，变成 `01010`。

`-10` 是在 `10` 的基础上把所有数字 revert 一次，`10101`，再加一，`10110`。

最后 `~-10` 就是 `01001`，`parseInt('01001',2)` 得到 9。

在 js 中，bitwise 运算是把数字转换为 [two's complement] 的形式后再执行的运算，把 -10 转换为 two's complement 的形式的步骤：

1. 先获得 -10 所对应的正数，即 10 的二进制数字，`(10).toString(2) = 1010`；
2. 因为 10 是正数，所以在最左边的位置增加 0，`01010`，因为在 two's complement 中，使用最左边的那位数字表示正数或负数，1 是负数，0 是正数；
3. 对这个二进制数字的每一位进行 revert，`10101`；
4. 因为是负数，所以还要在 `10101` 的基础上加 1，`10110`，这就是 10 的 two's complement 形式；

注意 bitwise operator 只适用于整数，不适用于小数。在 c++ 中对小数执行 bitwise operator [会报错]%3B)，在 js 中虽然不会报错，但会忽略小数部分。

```js
const result = ~-10.5;
console.log(result) //9
```

---

相关文章：

- [js 的 setTimeout 支持的最大值](/note/202306080734)：这里提到 js 使用 32-bit 或 64-bit 的二进制存储数字，可以表示整数和负数，注意和 two's complement 的区别，js 不是用 two's complement 的形式存储数字，只是在执行 bitwise 运算时才会把数字理解为 two's complement 的形式；
- [\~~10.5 为什么等于 10](/note/202306080935)：因为 two's complement 会忽略小数部分；

`-10` 是一体的，`~-10` 表示对 `-10` 执行 `~` 运算。

~-10 为什么等于 9：~- 运算符分析

~-10 为什么等于 9


微信 Mac 版貌似从 3.7.1.9 开始，点击对话中的链接，会使用微信内置的浏览器打开网页，虽然内置浏览器从这个版本开始支持多 tab 显示和切换，但使用体验还是远远比不上 Chrome、Edge 啊。

如果你想改用电脑浏览器打开链接，只需在微信的搜索框输入 `:recover`，然后从弹出的对话框中勾选 `使用默认浏览器打开链接` 选项即可。

![](recover.png)

如果你想改用电脑浏览器打开链接，只需在微信的搜索框输入 `:recover`，然后从弹出的对话框中勾选 `使用默认浏览器打开链接` 选项即可。

微信 Mac 版打开链接：取消内置浏览器改用电脑浏览器

Mac 微信打开链接：取消内置浏览器改用电脑浏览器

我打算通过看源码提高自己的编程水平，现在有一个问题是，我怎么找到这些源码？

去哪里找，这个问题可以认为是有标准答案的，答案就是 Github。

而怎么找，是一个没有标准答案的问题，一个好的开始是使用 Github 的[高级搜索]。

这里用搜索微信小程序为例，因为微信小程序的开发者基本上都是国人，学习资料不够丰富，我希望可以通过阅读别人的源码提高自己的小程序水平。

接下来用这条链接作为例子分享搜索方法：

[https://github.com/search?type=repositories&q=微信小程序+in:name,description,topics,readme+size:<20+size:>10+pushed:>2023-01-01+created>2023-01-01+stars:>10+is:public+archived:false]

分析：

- `type=repositories` 表示搜索的是 repo；
- `q=` 直至最后，都表示搜索的筛选指标，不同指标之间用 `+` 相隔：
	- `微信小程序` 就是本次搜索的关键词；
	- `in:name,description,topics,readme` 表示在哪些地方搜索 `微信小程序` 这个关键词，这里我分别写了 repo 的名称、描述、topic、README，默认不包括 README，但我觉得如果 README 中含有 `微信小程序` 这个关键词，那它大概率是一个和微信小程序有关的项目，所以我额外加上 README；
	- `size:<20` 表示 repo 的体积小于 20KB，刚开始看源码建议从小项目看起，如果你想要小于 1MB，那写成 `size:<1000`；
	- `size:>10` 表示 repo 的体积要大于 10KB，体积太小可能没什么值得看的；
	- `pushed:>2023-01-01` 表示 repo 上一次 `git push` 的日期，即上一次更新日期，一个人时间精力有限，优先阅读还活跃的 repo；
	- `created>2023-01-01` 表示 repo 的创建日期，小程序 API 迭代速度还是比较快的，阅读新 repo 可以学习到新的写法；
	- `stars:>10` 表示 star 数量要大于 10，大部份个人项目可能根本没有 star，但他们的代码大概率有可取之处，所以这里设置一个低数值可能更好；
	- `is:public` 表示 repo 公开，这是必选项；
	- `archived:false` 选择那些没有归档的 repo；

提高编程水平，除了读源码之外，还可以积极参与开源项目的代码贡献。你可以使用 `good-first-issues`、`help-wanted-issues` 这两个指标找出那些欢迎贡献代码的 repo。

比如下面这条链接，搜索 `javascript`，找出那些 `good-first-issues` 大于 2 的 repo：

[https://github.com/search?q=javascript+good-first-issues:>2&type=repositories]

[更多例子]：

- **[is:issue is:open label:beginner]**：`beginner`；
- **[is:issue is:open label:easy]**：`easy`；
- **[is:issue is:open label:first-timers-only]**：`first-timers-only`；
- **[is:issue is:open label:good-first-bug]**：`good-first-bug`；
- **[is:issue is:open label:"good first issue"]**：`good first issue`；
- **[is:issue is:open label:starter]**：`startr`；
- **[is:issue is:open label:up-for-grabs]**：`up-for-grabs`；

最后补充一点，你可以向优秀的开源开发者学习，阅读他们的源码，例如 [Sindre Sorhus]，他的 [sindresorhus/amas] 这个 repo 列举了部分优秀开发者。

---

相关文章：

- [Searching for repositories - GitHub Docs]

我打算通过看源码提高自己的编程水平，现在有一个问题是，我怎么找到这些源码？ 去哪里找，这个问题可以认为是有标准答案的，答案就是 Github。 而怎么找，是一个没有标准答案的问题，一个好的开始是使用 Github 的高级搜索。

如何使用 Github 的高级搜索，提高自己的编程水平？

善用 Github 高级搜索，提升自己的编程水平

看了一下 sindresorhus 的反馈表格，发现两个我没用过的服务。

- [Formcarry]：在线表格工具，在 `<form>` 的 `action` 属性绑定 Formcarry 提供的链接，用户提交表格后会把信息 `POST` 到 Formcarry，Formcarry 会把信息再通过邮件等途径通知你；
- [reCAPTCHA]：发现可疑用户行为时展示安全验证；

看了一下 sindresorhus 的反馈表格，发现两个我没用过的服务，分别是 Formcarry、reCAPTCHA。

sindresorhus 博客的 feedback 表格


[`browserify`] 是一个打包工具，即 bundler，主要用途是把 CommonJS 模块打包给浏览器使用。浏览器本身不支持 CommonJS，bundler 可以把 CommonJS 转换为它支持的格式。

`browserify` 其实也可以用于为 Node.js 打包代码，我尝试用 `browserify` 打包了一个部署在华为云函数的项目，把打包后的 `index.js` 重新部署到华为 fg，可以正常运行，当然这是一个很简单的函数，我不确定在复杂项目下，`browserify` 还能不能正常使用。

`browserify` 可以打包第三方 npm 依赖，但这个依赖[必须是] CommonJS module，不能是 ES Module，而且这个依赖的 `package.json` 需要有 `main` 字段，如果没有 `main` 只有 `exports` 字段，打包的时候可以会提示找不到模块。

不过 `browserify` 支持插件，例如 [`esmify`] 这款插件增加了对 ES Module 的支持，[`tsify`] 这款插件支持打包 Typescript 代码。

---

相关文章：

- [使用 esbuild 打包压缩云函数代码](/note/202212131726)


browserify 是一个打包工具，即 bundler，主要用途是把 CommonJS 模块打包给浏览器使用。浏览器本身不支持 CommonJS，bundler 可以把浏览器不支持的代码语法转换为它支持的语法。

使用 browserify 打包云函数


**untildify**

[untildify] 用来把 `~/Desktop` 转换为 `/Users/keke/Desktop`，而 [tildify] 则反过来。

`untildify` 容易理解，通过 `os.homedir()` 获取 tilde 所代表的路径，然后替换即可，但需要注意一些 corner case，例如要支持 Windows 系统下的 `\` 路径分隔符（现在的 Windows 也支持 `/`），要支持 `~` 等，更完整的 corner case 可以看项目的 [test.js]。

`untildify` 的 `test.js` 用到一款叫 [rewire] 的库，它和 `require` 读音很似，事实上用法也完全一样，除了一个区别：

> rewire acts exactly like require. With just one difference: Your module will now export a special setter and getter for private variables.

`untildify` 在 `test.js` 中使用 `rewire` 更改了 `untildify` 中的 `homeDirectory` 变量的值，以测试不同情况下的表现。`rewire` 已经[不怎么维护]了，但 jest 支持类似的 [mock]，虽然用起来没有 `rewire` 那么简单和直观。


**tildify**

[tildify] 和 `untildify` 作用相反。它用到了两个我很少用的属性或方法： 

- [`path.normalize()`]：在这里主要用来转换 `.` 和 `..`；
- [`path.sep`]：在不同的系统下可能不同（主要是 Windwos 系统），所以不能直接使用 `/`；

untildify 用来把 `~/Desktop` 转换为 `/Users/keke/Desktop`，而 tildify 则反过来。

读源码学编程：untildify、tildify

看源码：untildify、tildify


[npmlint] 是一个用来检查 `package.json` 文件的工具，它会按照最佳实践告诉你 `package.json` 是否缺少一些字段，或哪些字段的值不合适等。

在你需要 lint 的 package 目录中使用 `npmlint`，`npmlint` 会通过 `findup-sync` 从当前目录及其父目录中寻找最近的那个 `package.json` 文件，如果找到了就读取这个 json 文件，然后对它的字段进行分析。

作者在 [rules] 文件夹中定义了一些规则，默认会依据这些规则分析 `package.json`，用户也可以提供自定义规则。

有一个规则叫 `missing-package-props`，这里列出了一些建议字段，如果发现你的 `package.json` 没有，就会在检查结果中告诉你缺少了哪些字段。

```json
const recommendedProps = [
	'name',
	'version',
	'description',
	'keywords',
	'author',
	'main',
	'files',
	'repository',
	'engines'
];
```

其他一些规则：

- 使用 `node-semver` 判断 `version` 字段的值是否 valid；
- 如果有 typescript 代码，会看看 `scripts` 字段是否有子字段 `prepublish`，因为 ts 代码需要先 compile 为 js 代码，如果存在 `dependencies.typescript` 字段，还会提醒你 `typescript` 应该安装为 `devDependency` 而不是 `dependency`；
- 如果缺少 `scripts.test` 会提醒你加上测试；

`npmlint` 还有一个 [reporters] 文件夹，其实就是定义检测结果的输出格式和内容。用户可以指定自定义的 reporter，这个 reporter 可以是一个 npm 库。如果你提供了一个 npm 库给 `get-reporter.js` 函数，那它会使用 [`resolve`] 定位这个 npm 库所在的位置，并 `require` 进来。

这个项目用了几个我没用过的库：

- `findup-sync`：在当前目录或其父目录，定位最近的某个文件，并返回这个文件的路径；
- `glob`：使用 [glob pattern](/note/202211020923) 匹配文件；
- `resolve`：提供 npm 库的名称，返回这个库入口文件的路径；
- `semver`：判断 `version` 字段是否符合要求；
- `update-notifier`：提醒升级 npm 库；
- `sudo-block`：提醒用户要用 root 权限执行命令；

---

相关文章：

- [Node.js 两种模块方案：require、import 的区别和语法](/note/202211182226)：ESM 没有 `require.resolve`，可以用 [`import.meta.resolve`]；

npmlint 是一个用来检查 `package.json` 文件的工具，它会按照最佳实践告诉你 `package.json` 是否缺少一些字段，或哪些字段的值不合适等。

读源码学编程：npmlint

看源码：npmlint


[12366 纳税服务平台客服]，点击右侧的报表填写，然后按照提示输入你希望填写的报表，最后你会获得一个详细的填写指南。

![](tutorial.png)

如果找不到你想填写的申报表，还可以用 Google 搜索，例如搜索[《职工薪酬支出及纳税调整明细表》]：

![](search.png)

12366 纳税服务平台客服，点击右侧的报表填写，然后按照提示输入你希望填写的报表，最后你会获得一个详细的填写指南。

个人或企业税务申报官方指南，来自 12366 纳税服务平台

个人或企业税务申报官方指南

[website-popup] 是一个针对 mac 电脑的项目，它会调用 `automator` 命令打开一个网页。

它有两个依赖，分别是 [temp-write]、[execa]。

使用 `automator` 命令打开一个网页的方法是：

```sh
automator -i https://kejiweixun.com <wflow文件地址>
```

`-i` 表示 `input`，接收一个 url 字符串，然后执行 wflow。wflow 文件可以通过 Automator 应用导出。`website-popup` 提取了一个 [wflow 文件]，这个文件里的长宽可以调整网页打开的大小。

`website-popup` 不会直接修改项目中的 [wflow 文件]的长宽，而是使用 `temp-write` 把修改后的内容写入到 macOS 的 `/var/folders` 文件夹中，`/var/folders` 是 macOS 系统自动生成的文件夹，专门用来暂存缓存文件。在 node.js 下可以通过 `os.tmpdir()` 查看

在 Node.js 中执行 cli 命令首先想到的是 `child_process`，但这里用的是一个第三方库 `execa`，后续在另一篇笔记记录 `execa` 的看源码笔记。

website-popup 是一个针对 mac 电脑的项目，它会调用 automator 命令打开一个网页。 它有两个依赖，分别是 temp-write、execa。

读源码学编程：website-popup

看源码：website-popup


[comment-regex] 用来获取一个 regex 对象，这个 regex 对象可以用来判断一段 js 代码是否包含 comment，或把 comment 提取出来。

它的 `package.json` 使用了 [`exports`] 字段，而不是 `main` 或 `browser` 字段，这是 Node.js 定义的内容，npm 官方文档没有 `exports`。建议总是增加 `main`，不是所有工具都支持 `exports`，例如 `browserify` 会[提示找不到 module]，如果这个 module 没有 `main` 字段的话。

这个项目使用了一个我不熟悉的概念，[non-capturing group]，其格式是：`(?:pattern)`。

non-capturing group 相对应的自然就是 capturing group，他们的区别是：对于括号中的内容，是否可以通过 `$1`、`$2` 这是特定写法重新获取它们。

```js
const nonCapturingRegex = /(?:a)/
const capturingRegex = /(a)/
const r1 = 'apple'.replace(nonCapturingRegex, '$1') //$1pple
const r2 = 'apple'.replace(capturingRegex, '$1') //apple
```

---

相关文章：

- [Regex 的 lookbehind 和 lookahead](/note/202011302318)

comment-regex 用来获取一个 regex 对象，这个 regex 对象可以用来判断一段 js 代码是否包含 comment，或把 comment 提取出来，其中涉及到 non-capturing group 正则表达式。

读源码学编程：comment-regex

看源码：comment-regex


[`has-generator`] 是一个用来判断当前环境下是否支持 Javascript 的 generator function 的小工具，支持 Node.js 环境和浏览器环境。

它的 [`package.json`] 没有 [`main`] 字段，而是使用 [`browser`] 字段声明入口文件。`main` 省略时，Node.js 下会默认 `index.js` 为入口文件。

浏览器下判断是否支持 generator function 的方法是直接创建一个 generator function，如果不报错，就判断为支持，如果报错就不支持。通常我们不会使用 `new Function()` 去创建一个函数，但这里用的就是这种方法。`new Function()` 可以接收多个参数，除了最后一个参数，其他参数都是所创建函数的所能接收的参数名称，而[最后一个参数]就是要返回的内容，所有参数都是字符串，例如：

```js
const generatorFn = new Function('return function * () {}');
```


`has-generator` 是一个用来判断当前环境下是否支持 Javascript 的 generator function 的小工具，支持 Node.js 环境和浏览器环境。

读源码学编程：has-generator

看源码：has-generator


[bower-name-cli] 是一个 cli 工具，用来查询 bower 中是否存在某个 package name。

bower 曾经是一个很热门的前端 package manager，npm 曾经主要用于后端包管理，不过 2016 年中 bower 开发者就开始 [deprecate bower] 了，建议开发者使用 npm、yarn 等工具。

依赖：

```json
{
  "dependencies": {
    "bower-name": "^2.0.0",
    "log-symbols": "^1.0.2",
    "meow": "^3.4.2"
  },
  "devDependencies": {
    "ava": "*",
    "pify": "^2.2.0",
    "xo": "*"
  },
}
```

`bower-name-cli` 其实是 [`bower-name`] 的 cli 版。

执行文件 [`cli.js`] 顶部有一行 `shebang`：

```sh
#!/usr/bin/env node
```

它的作用是可以让这个文件在终端通过 `./cli.js` 执行，不需要 `node ./cli.js`。

在 macOS 终端执行 `env` 命令可以看到系统的所有环境变量，其中就包括 `PATH` 变量，执行 `./cli.js` 时，系统会从 `PATH` 确定 `node` 的路径。

从 [test.js] 可以看到如何在 node.js 代码中执行一个 js 文件：用的是 `child_process.execFile()`，因为 `cli.js` 加了 shebang，所以可以直接把这个文件的路径传入 `execFile()` 去执行。

cli 工具的 `package.json` 都有一个 [`bin`] 字段，`bower-name-cli` [也不例外]。

`bower-name` 是 `bower-name-cli` 的基础，它其实只是向 bower 的 API 发起一个请求，确定是否存在某个 package。请求方法是 `HEAD`，它只会返回 `headers`，不会返回 `body`。`bower-name` 根据 status code 来判断是否存在某个 package，它不关注 body，所以不需要用 `GET`，而且 `HEAD` 通常比 `GET` 更快。

---

相关文章：

- [关于 macOS 的 PATH](/note/202305160959)：关于 `$PATH` 这个变量；
- [如何用 Node.js 写一个 CLI 工具](/note/202212032219)

`bower-name` 是 `bower-name-cli` 的基础，它其实只是向 bower 的 API 发起一个请求，确定 bower 是否存在某个 package。

读源码学编程：bower-name-cli

看源码：bower-name-cli

在 macOS 下，Obsidian 的常用快捷键如下。

界面操作类：

- `⌘ ,`：打开设置菜单；
- `⌘ P`：打开命令面板；
- `⌘ O`：打开搜索面板；
- `⌘ W`：关闭当前 tab；
- `⌘ ⇧ T`：重新打开上一个被关闭的 tab；
- `⌘ ⇧ N`：在右侧新建笔记；
- `⇧ Enter`：支持内部链接或网页链接，会打开这个链接；
- `⌘ Enter`：同上，区别是会在新 tab 打开这个链接，如果打开的是网页链接则没有区别；
- `⌘ F`：搜索当前笔记；
- `⌘ ⌥ F`：搜索并替换当前笔记；
- `⌘ ⇧ F`：搜索所有笔记；
- `⌘ <数字>`：当选中左侧面板时，切换顶部的功能；选中编辑窗口时，切换 tab；选中右侧面板时，切换顶部的功能；
- `⌘ <把光标放在文件管理器的某个文件上>`：弹出浮动窗口显示这个文件的内容；

笔记编辑类：

- `⌘ E`：打开一个笔记之后，在 editing 和 reading 模式切换；
- `⌘ L`：把一行内容变成 checklist，即在前面自动添加 `- [ ]` 或 `1. [ ]`，如果已经是 checklist，那会 check 它或 uncheck 它；
- `⌘ K`：输入 Markdown Link，即输入 `[]()`，不支持输入时实时搜索，想搜索可以输入 `[[`；
- `⌘ B`：字体加粗；
- `⌘ I`：字体倾斜；
- `⌘ /`：添加评论；
- `⌘ D`：删除当前段落；

以上都是 Obsidian 1.3.4 默认支持的快捷键，我个人还额外增加了以下快捷键：

- `⌥ ↑`：把光标所在的段落往上移动一个段落的位置；
- `⌥ ↓`：把光标所在的段落往下移动一个段落的位置；
- `⌘ [`：打开或关闭左边的文件目录面板；
- `⌘ ]`：打开或关闭右边的侧边面板；

在 macOS 下，Obsidian 的常用快捷键如下，分为界面操作类、笔记编辑类。

常用 Obsidian 快捷键


一些概念：

- commit：提交
- repository，repo：仓库
- working directory：工作区
- checkout：检出
- staging area、staging index、index：暂存区、索引区
- working area、working tree：工作区
- SHA：每个 commit 的编码
- branch：分支

首先要知道查询文档的方法：在 bash 输入 `git help [keyword]`，例如 `git help add`，就可以看到这个命令的使用说明。另外，查询配置信息需要这样：`git config --list --show-origin`。

推荐两篇学习文章：

- [git tutorial]
- [gitcore tutorial]

以下是我的学习笔记。

HEAD、branch、tag 都是 reference，HEAD 指向 branch 或 tag 或 sha，如果指向 tag 和 sha，那就是 detached head，`.git/HEAD` 这个文件记录了当前的 head 是哪个。从 `.git/refs/heads/` 这个文件夹来看，每个 branch 都有一个 HEAD，你 checkout 到哪个 branch，那这个 branch 的 HEAD 就生效。如果是 detached head，那所有 branch 的 head 都不生效。

这篇文章对理解 HEAD、branch、tag 很有帮助：[Git Internals]。

可以通过 `echo [SHA] > .git/HEAD` 修改 HEAD 指向哪里，效果和 `git reset` 类似，所以 `git reset` 主要改变 HEAD 这个文件。

repo 里面的任一文件有 4 种状态：untracked、unmodified、modified、staged。除了 `git add`，所有 git 命令对 untracked 文件无效。

git 就是对比，在 git 的世界中，万物皆对比。用对比的思维理解 git，而不要用文件的流动性（变化性）去理解。例如 working dir 和 staged area 对比，如果有差异，`git status` 就会用红色表示出来，`git diff` 看的是红色的细节。staged area 和 commit area 对比，如果有差异，`git status` 就会用绿色表示，绿色表示 staged area 和 working dir  一样，但和 commit area 不一样，`git diff --staged` 看的是绿色的细节。

`git reset` 也是对比的过程，默认的 `--mixed` 重置 commit area 和 staged area，这时候 `git status`，git 会把 working dir 和 staged 进行对比，差异显示为红色。`--soft` 只重置 commit area，所以 staged area 和 commit area 有差异，用绿色表示。`--hard` 会同时恢复 3 个 area。详情可看 `git reset -h`。

搭配 github 中使用 git：

- git remote：查看本地 repo 在 github 的所有远程 repo，即这个本地 repo 被上传到哪些 github repo；
- git remote show origin：可以看到 origin 这个 repo 的详细信息；
- git remote rename [旧名称] [新名称]：重命名，例如本来是 origin 的，改为 newOrigin；
- git remote add [名称] [URL]：创建远程 repo 的方法，通常叫 origin，url 就是远程 repo 的 url；
- git remote -v：查看远程 repo 的 url 是什么，包括 fetch 也就是下载的 url，push 也就是上传的 url，`-v` 是 `--verbose` 的缩写；
- git push origin main：把本地的 main 分支，上传至远程的 origin，这里用 origin 指代 url，`origin` 可省略，因为这是默认值；
- git push origin [tagName]：默认情况下，git push 不会把 tag 上传到 github，需要主动 push，如果要 push 所有 tag ，可以用 `git push origin --tags`，`origin` 可省略，因为这是默认值；
- git pull origin main：从远程 origin 这里，把 main 分支最新的内容下载到本地，更新本地的分支，`origin` 可省略，因为这是默认值；
- github 的 fork：相当于在 github clone 别人的 repo，如果 fork 之后从自己的账户 clone 到本地，那这个 remote 就是自己的 remote，而不是原始 remote，而且你通常对原始的 remote 无写入权；
- upstream/main：如果你 fork 了一个项目，然后从你的 repo 把这个项目 clone 到本地，那这个本地项目的 remote origin 就是你自己的 repo，如果你想从原始 repo 更新你的本地项目，需要手动 `git remote add [名称] [url]`，其中名称习惯叫 `upstream` 而不是 `origin`；
- 注意 main、origin/main 两个分支的区别，当有 remote 参与时，本地 commit 可能会出现 2 个 branch，main、origin/main 不一致时就会出现，他们的关系可能有四种：ahead、behind、up-to-date、out of sync；
- git rebase：变基，比较少用；
- github 的 pull request：相当于远程 merge，以 branch 的方式进行 request，所以最好的做法是，这个 branch 的名称可以反映这个 request 的 topic。当然，在提交 request 的时候，你可以起标题，说明等。本地 merge，如果是快进合并，不会产生新的 commit，但是在 github 接受 pull request 产生的 merge，肯定会产生新的 commit；

开源项目大概是这样进行的，以 deno 为例：ry 发布 deno，其他人可以 fork 它的项目，fork 了之后再 clone 到自己的电脑，发现 bug 或者加入新功能等，需要更改代码，那就建一个新 branch，改代码再通过这个 branch push 到自己的 repo，然后在自己的 repo 那里发起 pull request。可以向原作者 pull request，在创建 pull request 时，github 会提醒你的代码是否和最新的原作代码有冲突，如果有，你可以 add 原始的 remote，也就是 upstream/main，把代码 fetch 下来 diff，根据需要把 main、upstream/main merge 起来，再 push 更新你的 main、origin/main，然后重新提交 pull request

branch 在实际应用中往往可以分为两类：long running branch 、topic branch。pull request 通常是 topic branch。

一些 git 命令：

- git init：初始化 git 仓库，自动生成 .git 文件夹；
- git clone：下载仓库；
- git status：状态；
- git log：默认显示 SHA、作者、日期、消息，只能看到 branch 的 commit，不在 branch 的 commit 看不到，例如 detached head；
- git log --oneline：只显示 sha；
- git log -2、git log --since=2,weeks：显示哪些 log；
- git log --stat：显示每条 commit 那些文件发生了改变；
- git log [branch 名称]：查看某个 branch 的 log；
- git log -p：显示这些改变都是什么，也可以写作 --patch；
- git log [SHA]：可以从该 SHA 开始，倒翻去看；
- git log --follow [文件名称]：看这个文件的历史变化，包括重命名；
- git show：显示最新 commit 的详细变化。它和 git diff 的重要区别是，git show 只会显示该 commit 相对其父 commit 的变化，例如两个分支 merge 之后，有点难区分某个 commit 的父 commit 是什么，这时用 `git show [SHA]` 就可以默认比较该 commit 相对其父 commit 的变化；
- git show [SHA]：显示该 SHA 的详细变化，可以和 `-p`、`--stat`、`-w`（空格） 等一起使用；
- git add：把变化从工作目录转移到暂存区，后面可以跟具体文件名称，也可以加 `.`；
- git add --patch：如果一个文件有多个改变，你希望把这些改变分拆开多个 commit 提交，可以用这个命令；
- git rm --cached [文件]：可以把文件移出 staging area，可接受多个文件，也就是变成 untracked，文件继续保留在硬盘；
- git rm [文件]：把文件从 working dir 删除，同时从 staging area 删除，也就是从硬盘上删除，`rm` 不会把文件从 staging area 中删除；
- git mv [名称 1] [名称 2]：在 repo 中对被 tracked 的文件用 `mv` 重命名要小心，因为 git 会把重命名理解为 3 个步骤，删了原来那个，新建文件，这个文件没有被 tracked。所以可以用 git rm 这个命令重命名，一次性完成三个步骤，相关笔记：[Git 如何重命名文件和文件夹](/note/202209201016)；
- git diff：和 `git log -p` 一样。后面可以加两个 SHA，这样就是比较两个 commit 的变化，如果不加任何 SHA，就是比较 staging area 和 working dir 两者之间的区别。如果要比较 staging area 和 commit 之间的变化，需要 `--staged`；
- git diff --staged：参考上一条；
- git commit：提交；
- git commit -a：跳过 add 到 staged，直接从 working dir 到 commit；
- git commit -m：提交说明不要超过 60 个字符；
- git tag -a v1.0：表示创建一个带注释的 tag，如果没有 -a 就不带注释，git show v1.0 可以查看这个 tag 的内容。tag 不会移动。不带注释的 tag 类似 branch，带注释的 tag 类似 commit，因为带注释的 tag 会生成一个新的 sha 值，只不过 log 不会显示这个 sha 值。可以在 .git/refs/tags/ 查看；
- git tag：列出所有标签
- git tag -d v1.0：删除标签
- git tag -a v1.0 [SHA]：如果后面加 SHA，表示给指定 commit 加标签，如果没加 SHA 就表示给最新的 commit 加标签；
- git branch：显示所有分支，`--merge` 可以显示那些已经 merge 的分支  `--no-merge` 反之；
- git branch -v ：可以查看所有 branch 最新一个 commit，`-v` 是 `--verbose` 的缩写；
- git branch [名称]：创建分支。注意分支的可读性，是指这个分支顺藤摸瓜可以 log 到哪些 commit，不是所有 commit 都可以通过这个分支 log 到，有些 commit 可能所有分支都 log 不到；
- git checkout [分支名称]：切换分支；
- git checkout [SHA]：切换 sha；
- git checkout [tag]：切换 tag；
- git checkout [文件名称]：撤销该文件 staged 之后的修改，相当于用 staged 的状态覆盖未 staged 的状态
- git reset HEAD [文件名]：用该文件在 commit 的状态覆盖 staged 的状态，覆盖后相当于该文件在 staged 中和其在 commit 中无变化。又因为 reset 默认不覆盖 working dir，所以该文件在 working dir 中无影响，所以表现出该文件未 staged；
- git branch [名称] [SHA]：表示创建分支，并指向 sha 这个 commit；
- git branch -d [名称]：删除分支，注意删除分支是指删除分支这个标志，这个分支的 commit 至少短时间内并不会被删除。如果分支删除之前 merge 入了另一个分支，那这个被删除的分支的所有 commit 都可以通过另一个分支的 log 查看，并且不会被删除。如果没有 merge 就删除分支，那这个分支的所有 commit 不能通过 log 查看，但在一定时间之后（默认 30 还是 90 天）会被删除，删除前只能通过 `git reflog` 查看。当然就可以 checkout SHA 回到这个 commit；
- git merge [分支名称]：把分支合并过来，合并分为快进合并、普通合并。checkout 在 a 分支，再 merge，那 merge 之后的新 commit 所在的分支也叫 a。快进合并不会产生新的 commit，只不过 HEAD 的位置变了，具体来说就是往前移动了，普通合并很定会产生新的 commit；
- git mergetool：要先执行 git merge ，如果有冲突才可以用 mergetool，要先设置：`git config --global merge.tool vimdiff3`；
- git commit --amend：更新最近的一个 commit；
- git revert [SHA]：还原 commit，会创建一个新 commit；
- git reflog：可以查看被 reset 后、30 天内的 commit；

其他：

- HEAD 当前 commit，HEAD^ 上一个 commit，也可以用 HEAD~ HEAD~ 表示；
- HEAD^^、HEAD~2 表示上上个 commit；
- HEAD^^^、HEAD~3 表示上上上个 commit；
- ^、~ 的区别是，合并分支后的 commit 有两个父 commit，HEAD^ 表示当前所在分支的父 commit，HEAD^1 表示被合并过来的分支的父 commit，~ 没有这个功能。

关于 `git checkout`、`git reset`、`git restore`、`git revert` 的区别，可以看 stackoverflow 的[这个问答]，它们都有后悔药的作用。如果要恢复一个文件，建议用 `git restore`，它是在 git 2.23 新加的功能，功能上是 `git checkout` 的子集，更安全。

Git 学习笔记：如何搭配 GitHub 使用，一些常用命令

Git 学习笔记


以下四张图应该汇总了 Final Cut Pro 最常用的一些快捷键：

![](final_cut_pro_shortcut_1.png)
![](final_cut_pro_shortcut_2.png)
![](final_cut_pro_shortcut_3.png)
![](final_cut_pro_shortcut_4.png)

以下四张图应该汇总了 Final Cut Pro 最常用的一些快捷键

常用 Final Cut Pro 快捷键


[turbosquid]

有收费的，也有免费的，很多素材，甚至有[裸体女性]的 3D 模型，还对身体各个部位进行了细分。

turbosquid，有收费的，也有免费的，很多素材，甚至有裸体女性的 3D 模型，还对身体各个部位进行了细分。

一个可以下载免费 3D 模型的网站


日本文字的构成：只有三种，分别是汉字、假名（平假名、片假名）、罗马字。

**关于汉字**

日本的汉字并不都是中国的汉字，有一些日本人称为汉字的字，并不是中国的汉字，尤其是那些日本人自己创造出来的汉字，中国人根本看不懂，日本人把这些自己造的汉字叫“国字”。

另外，中国汉字、日语汉字即使形状完全一样，意思也可能完全不一样，当然也有完全一样的。

日语汉字的发音有两种，音读、训读。音读，顾名思义，就是用中国古汉语的声音去朗读，例如日文“山水”和中文“山水”的读音很像。而训读，就是沿用日本自己的发音。

有趣的是，日本中同一个汉字可能有多种发音，例如日文“森林”中的“森” 字的读音，和日本“森”单独读的读音不一样。

**关于假名**

假名，意思是“假借”回来的“字”，从汉字借回来的字，所以有时候会说中文是真名。“名”意思是“文字”。

平假名中的“平”表示“平易简单”，从汉字复杂的草书简化而成。

片假名中的“片”表示“片面，不完整”，只取汉字的一部分，来自汉字的楷书。

片假名主要用在外来语、拟声拟态词、动植物名称等。主要用来和平假名进行区分。片假名有 “突出、强调” 作用，有时候本应该用平假名写的，但有些人用片假名写。

**关于罗马字**

使用拉丁字母表示日语发音，国际化。招牌、广告、输入文字。


日本文字的构成：只有三种，分别是汉字、假名（平假名、片假名）、罗马字。

日语文字的构成：汉字、假名、罗马字


Unicode 11.0 有 137,374 characters，有 1,114,112 个 code points，最常用的 BMP 有 65,536 个 code points。

一些概念：

- codespace：1,114,112（0 ~ 10FFFF）
- codepoint：通常用一个 16 进制数字表示，为了表明这个数字是 unicode 的 code point，通常还会在前面加 U+。character 通过 code point 指代，所以 character 也可以用 `U+数字` 表示，例如字母 A 是 `U+0041`。
- encoded character
- encoding form：UTF-8、UTF-16 等，character encoding forms refer to integral data units in memory or in APIs, and byte order is irrele- vant; character encoding schemes refer to byte-serialized data, as for streaming I/O or in file storage, and byte order must be specified or determinable.
- encoding schemes：In the Unicode Standard, the specifications of the distinct types of byte serializations to be used with Unicode data are known as Unicode encoding schemes.
- unicode string：A Unicode string data type is simply an ordered sequence of code units.
- planes: 把 code space 划分成十多个 planes，每个 plane 包括 64k 个 code point，有趣的是，把每个 code point 编码都写成 5 个 16 位数字的话 ( 不足 5 位前面用 0 补充 )，那开头的那个非 0 数字就表示第几 plane，最后的 4 个数字表示这个 code point 位于这个 plane 的什么位置。第 0 plane 也叫 BMP，第 1 plane 也叫 SMP，第 2 个 plane 也叫 SIP，包含那些很少用的没有放在 BMP 的 CJK 文字，也包括一些常用的广东话文字。
- blocks: BMP 有大概 6.5 万个 character，这些都是最常用的 character，这些 character 又可以划分为大概 290 个类别，这些类别叫 block，这只是粗略的划分。
- combining character: In Unicode, combining characters are divided into two categories: spacing and non-spacing. Spacing combining characters are characters that have a visible width and are used to create ligatures and other complex characters. Non-spacing combining characters are characters that have no visible width and are used to modify the appearance of other characters.

UTF-8、UTF-16，这里的 8 和 16 不是 8 进制、16 进制的意思，意思 8 比特、16 比特的意思。UTF-8 的 code unit 是 8 比特，UTF-16 的 code unit 是 16 比特。因为 1 byte = 8 bits，所以 UTF-8 一个 code unit 就是 1 byte，UTF-16 的 1 个 code unit 就是 2 个 bytes。

计算机处理数据的方式，是处理那些固定长度的数字单元，这个长度通常是 8、16、32 等，又因为计算机只能识别 0、1 这种 binary digit，所以处理数据的方式就是 8 个或 16 个 binary digit，即 8bit 或 16bit 等。

code point 是一个 16 进制数字，为了让计算机处理这些 code point，需要把这些 16 进制数字转换成计算机可以识别的固定长度的 binary digit。

例如 004E 这个 code point，如何让计算机识别处理呢？分为两个步骤，首先转换成 binary digit，也就是 2 进制数字，结果是 1001110，接着思考把 1001110 转换成计算机习惯处理的固定宽度数字，如果转换成 8 个宽度的 binary digit，只需在前面加 0 凑够 8 位宽度只可，即写成 01001110。如果转换成计算机习惯处理的另一种固定宽度数字，比如 16 位，那就要在前面补充更多的 0，最后写成：0000000001001110。

当然不是所有 code point 都要补充这么多零，code point 的范围是从 0 到 10FFFF，对于最大的 code point 10FFFF，先转换成 2 进制的 binary digit，也就是 bit 数字，为：000100001111111111111111。再把它转换成 8 进制的固定宽度 binary digit，就变成：00010000   11111111  11111111。

需要注意的是，转换之后的数字，还不能被称为 UTF-8 编码，因为一些关键原因，UTF-8 需要在这些 code point 的 2 进制数字前面加一些前缀。
下图 xxxx 这些就是 code point 的 2 进制版本，对于前面提到的 004E，它的 2 进制数字就是 UTF-8 编码数字。而对于那些超过 1 个 code unit 的 code point，其 UTF-8 编码要加前缀。例如  10FFFF，它的 2 进制数字要填进 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 这里。

![](unicode.png)

如果是 UTF-16，超过 1 个 code unit 的 UTF-16 编码这样写：
110110xxxxxxxxxx 110111xxxxxxxxxx。

不直接把 code point 的 2 进制数字当作 UTF-8 或 UTF-16，是为了避免所谓的 self-synchronization。看[这个问题]：为什么 UTF 要浪费几个 bit 的空间用于编码。

从 UTF-8 第一个字节的前面几个 bit，就可以马上判断这个 UTF-8 编码一共由多少个字节构成。

---

相关文章：

- [What is UTF-8?]
- [mathiasbynens/emoji-regex]
- [node-unicode/node-unicode-data]

这篇文章介绍 Unicode 的多个基本概念，例如 code space、code point、encode form 等，着重理解 Unicode 的 UTF8、UTF16 编码方式。

Unicode 编码学习笔记


当你对自己的博客或网站的访问速度不满意时，雅虎的这篇文章很值得一读：[Best Practices for Speeding Up Your Web Site]

这篇文章列了一个详细的清单，你可以逐条核对你有哪些做得不好的，尝试优化做得不好的地方，看看网站速度是否有所提升。清单的部分内容如下：

1. 减少 http 请求数量
2. 使用 CDN
3. 使用 expres 或 cache-control 标头
4. gzip 压缩
5. 把 css 放在 html 文档的 HEAD, 这样 “看” 上去加载得更快点
6. 把 js 放在 html 文档的底部, 因为 js 会 block 并行加载
7. 避免使用 css expressions
8. 把 js 和 css 文件放在外部, 即 external, 方便 cache
9. 减少 dns 查询次数
10. 压缩 js 和 css 文件体积大小
11. 避免重定向, 包括 301 和 302 等
12. 避免出现重复的 js 文件
13. 配置 etags

雅虎这篇文章对每一条内容都有详细解释。

另一篇值得参考的文章是：[Making Instagram.com faster]


当你对自己的博客或网站的访问速度不满意时，建议阅读雅虎的这篇文章，文章列了一个详细的清单，你可以逐条核对你有哪些做得不好的，尝试优化做得不好的地方，看看网站速度是否有所提升。

提高网站访问速度的最佳方法


印象笔记我用了超过十年，但它越来越不好用了，所以我想从印象笔记中迁出来。

以前印象笔记可以把笔记导出为 `.enex` 文件，这种文件可以方便地导入到其他笔记软件，例如 OneNote、Notion 等，但不知从何时开始，印象笔记中国版取消了 `.enex` 导出，现在只能导出 HTML。其目的也很明显，就是提高你的迁移成本，阻止你迁移到其他平台。

有人开发了 [html2notion]，可以让你把 HTML 导入到 Notion，但它[不支持导入图片]等文件。

幸好，开源社区有一个叫 [evernote-backup] 的项目，可以把你在印象笔记中国版或 EverNote 的所有笔记都下载下来，且支持导出 `.enex`。

我认为没有哪一款笔记软件可以一直广受欢迎，总有一天它也会像 EverNote 那样衰落，所以我这次没有把笔记导入到其他笔记软件，而是使用一款叫 [Yarle] 的开源软件把所有笔记转换为 Markdown 文件，并把它们都扔进网盘，让网盘去帮我备份、同步。

Yarle 转换的 Markdown 文件可能会把链接转换为 `WikiLinks`，即 `![[image.png]]` 这种双括号的格式，但标准 Markdown 语法不支持 WikiLinks，如果要把 WikiLinks 转换为标准 Markdown 的链接格式，可以使用 [Obsidian Link Converter] 这款插件。

前面提到备份和同步笔记可以通过 OneNote，至于写笔记、搜索笔记、整理笔记，我用 Obsidian。

我这种做法不一定适合你，因为我对丰富的排版没有需求，我喜欢用最基本的格式写笔记；我也很少在手机上写笔记，简单的随想我都发到微信，如果需要，我才会整理成笔记。

不过我有时候需要通过手机查阅、搜索我的笔记，把笔记放在网盘后就不太方便了。解决方法可以参考我这个博客的笔记栏目以及搜索功能，即写一个只有自己才能访问的简单网页，用于展示、搜索你的 Markdown 内容。另一种方案是使用 Obsidian 的手机应用，但它需要你把 Markdown 文件都放在 iCloud Drive。

以前印象笔记官方客户端可以把笔记导出为 `.enex` 文件，但现在只能导出 HTMl 了，但我们可以使用一款叫 evernote-backup 第三方开源软件导出 `.enex` 文件。

从印象笔记中国版导出 .enex 的方法


可以先了解一下 fly.io 提供的[免费额度]，按量付费，需要添加信用卡，注意需要在 Organization - Billing 处，把 Plan 改为 Hobby Plan，而不是 Hobby Plan Preview 或其他 Plan。

什么是 Tailscale 呢？你可以去它的[官网]了解，少数派的[一篇文章]是这样介绍 Tailscale 的：

> Tailscale 属于一种虚拟组网工具，基于 WireGuard。他能帮助我们把安装了 Tailscale 服务的机器，都放到同一个局域网。

简单地说，我们可以在 Mac、iPhone、Windows 等设备都安装上 Tailscale，经过简单的配置，这些设备就能组成一个局域网，即使不是在同一个 Wi-Fi 下也可以互相访问对方的文件。你当然也可以把 Tailscale 安装在 fly.io 的虚拟主机上，这样你的手机或电脑就可以和这部虚拟主机组成局域网。

Tailscale 还支持所谓的 exit node：

> An exit node in Tailscale is a device or network that is used to route all of your internet traffic.

Github [有一个项目]手把手教你如何在 fly.io 的主机上部署 Tailscale，并把该主机设置为 exit node，从而把你的手机、电脑的流量都路由到这个主机上，我试了一下，速度还不错。如果你已经购买了其他虚拟主机，也可以把 Tailscale 部署到你的主机上，不一定是 fly.io。

fly.io 支持很多 [region]，如果你想知道哪个 region 在你所在的位置延迟最低，可以看[这个帖子]，或打开帖子提到的[这个网页]，查看页面底部的区域，不过这个网页没有列出所有 region。

Tailscale 可能会通过它的 DERP node 中转你的网络，即你的网络不是直接从你的设备到 fly.io 的主机，而是从你的设备到 Tailscale 的 DERP node，再从 DERP node 到 fly.io 的主机，这样速度可能就有点慢了。

在安装了 Tailscale 应用的电脑上执行 [`tailscale status`] 命令，如果返回的信息提示 [`relay`]，说明你的网络经过了 DERP node，如果显示 `direct`，那你就是直连 fly.io。

你在网络上可能会看到 “Tailscale 打洞” 这个词，英文说法是 UDP hole punching，上面提到的项目[支持] UDP hole punching，这是之所以能 `direct` 的原因。

Github 有一个项目手把手教你如何在 fly.io 的主机上部署 Tailscale，并把该主机设置为 exit node，从而把你的手机、电脑的流量都路由到这个主机。

在 fly.io 上部署 Tailscale


在微信小程序上使用 [`map`] 组件，并在组件上绑定 `bindmarkertap` 函数，如果点击某个 marker 后，`bindmarkertap` 函数调用有延迟，可能是页面的 `disableScroll` 设为 `true` 所导致的，把它删了或改为 `false` 即可避免延迟。

我没有在网上找到对 `bindmarkertap` 调用延迟的讨论，于是花了不少时间 debug，所以在这里记下来，希望能帮到一些人。

在微信小程序上使用 map 组件，并在组件上绑定 bindmarkertap 函数，如果点击某个 marker 后，bindmarkertap 函数调用有延迟，可能是页面的 disableScroll 设为 true 所导致的，把它删了或改为 false 即可避免延迟。

微信小程序 map 组件 bindmarkertap 延迟的问题


关键是怎样把安装的第三方依赖和用户写的代码打包在一起。华为文档建议把[依赖]和用户[代码]分开打包上传，依赖作为层绑定到函数，我觉得有点麻烦。因为腾讯云和华为云函数很类似，所以可以参考腾讯云的部署方式，根据腾讯的[文档]，依赖其实不需要做特别处理，可以直接和用户代码文件一起打包。

以下是一个例子：

- 创建一个文件夹，并 `cd` 入这个文件夹；
- 执行 `python3 -m venv .venv` 创建虚拟环境；
- 执行 `source './.venv/bin/activate'` 激活该虚拟环境；
- 执行 `pip3 install requests==2.30.0 urllib3==1.26.2` 安装所需的库；
- 在文件夹中增加 `index.py` 文件，并写入代码：

```python
import requests
import json

def handler(event, context):
    response = requests.get("https://jsonplaceholder.typicode.com/posts/1")
    response_json = response.json()
    print(json.dumps(response_json, indent=4))
    return response_json
```

- 执行下面这条命令把安装的所有库复制到 `./packages` 文件夹中，正如前面所说，安装的依赖不需要特别处理，可以和用户代码一起打包，所以我把这些依赖从虚拟环境中复制出来并放在 `index.py` 旁边；

```sh
cp -r ./.venv/lib/python3.9/site-packages ./packages
```

- 执行下面这条命令把用户代码以及 `./packages` 文件夹全部打包在一起，这条命令会忽略所有隐藏文件，所以 `.venv` 会被忽略；

```sh
zip -rq code.zip *
```

- 另一种做法是不把依赖从 `.venv` 中复制出来，而是直接打包 `.venv`，这时需要把上面这行命令的 `*` 改为 `.`：

```sh
zip -rq code.zip .
```

- 把生成的 `code.zip` 上传到华为云函数即可，可以通过华为云网页后台手动上传，也可以用云函数的 [API 上传]，还可以用华为的 [CLI 工具上传]；

---

相关文章：

- [部署 Python 代码到阿里云函数](/note/202305161730)


华为文档建议把依赖和用户代码分开打包上传，依赖作为层绑定到函数，我觉得有点麻烦，根据腾讯的文档，依赖其实不需要做特别处理，可以直接和用户代码文件一起打包。

部署 Python 代码到华为云函数


- 电脑[安装 Serverless Devs 和 Docker]；
- [配置 Serverless Devs]；
- 执行 `s` 创建一个 Python 函数模板，在模板的基础上写代码、安装依赖；
- 如果想在本地测试代码，事件函数可以执行 `s invoke`，HTTP 函数可执行 `s start`，后者需要打开 Docker；
- 把代码部署到云函数前，需要考虑怎样把依赖也部署上去；
- 如果使用 `venv` 管理虚拟环境，则需要先执行 `pip3 freeze > requirements.txt` 生成依赖列表，`requirements.txt` 文件要放在 `code` 文件夹内；
- 接着执行 `s build --use-docker` [安装依赖]，执行完成后，依赖会被安装到 `.s/build/artifacts/` 目录下，如果本地电脑的 Python 版本和云函数的 Python 版本一样，执行 `s build` 应该也可以；
- 最后执行 `s deploy` 部署到云函数；

---

相关文章：

- [部署 Python 代码到华为云函数](/note/202305171151)


这篇文章分享如何使用 Serverless Devs 在本地电脑测试 Python 函数，并把它部署到阿里云函数。

部署 Python 代码到阿里云函数

这篇文章是关于 macOS 的 PATH 都位于哪些文件中，以及如何设置 PATH。

PATH 的作用是当我在终端输入一个命令时，告诉系统应该从哪里寻找这个命令。如果没有 PATH，那我们就需要输入命令的完整路径，有了 PATH，我们只需要输入命令的名称即可，系统会从 PATH 搜索这个命令的具体位置。

首先看看都有哪些 PATH。

```sh
echo $PATH
```

`$PATH` 是一个变量，这个命令会列出所有当前用户可以使用的 PATH，列出的顺序[似乎反映]了当你执行一个命令时，会依次从哪个 PATH 搜索这个命令。

那 `$PATH` 这个变量的值是怎么得来的呢？换言之，PATH 是在哪里被定义的呢？

对于系统级别的 PATH，是通过 `/etc/paths` 这个文件定义的。

```sh
cat /etc/paths
```

这个命令会列出系统级别的 PATH，所有用户都可以使用。

我的电脑会返回：

```text
/usr/local/bin
/System/Cryptexes/App/usr/bin
/usr/bin
/bin
/usr/sbin
/sbin
```

其中 `/usr/bin` 不允许手动修改，要改就改 [`/usr/local/bin`]。例如添加 vscode 的 [`code` 命令]，就是添加到 `/usr/local/bin`。

除了 `/etc/paths` 这个文件，你还可以在 `.bashrc`、`.bash_profile`、`.zshrc`、`.zprofile` 这四个文件中找到 PATH，这四个文件到位于 `~` 路径中，由此也可以推断这些文件定义的 PATH 都是用户级别的 PATH。

- Catalina 之前：系统默认使用 bash，所以 PATH 在 `~/.bashrc`、`~/.bash_profile`；
- Catalina 及之后：系统默认使用 zsh，所以 PATH 在 `~/.zshrc`、`~/.zprofile`；

其中 `~/.zprofile` 和 `~/.zshrc` 的区别如下，图表来自 Google Bard：

![](zsh-compare.png)

如果你的 macOS 安装了 Homebrew，你应该会在 `~/.zprofile` [而不是](<>) `~/.zshrc` 看到 Homebrew 的 PATH。

如果要临时添加一个 PATH，只需要在终端输入：

```sh
export PATH=$PATH:/path/to/directory
```

这条命令的格式初看起来有点奇怪，其实不然：`export PATH` 表示导出一个变量，这个变量的值是 `$PATH:/path/to/directory`，`:` 是不同 PATH 之间的分隔符，你可以从 `echo $PATH` 确认这一点，所以上面这条命令的意思是 `export` 新的 PATH 变量，其值是在之前的 PATH 基础上添加 `/path/to/directory`。

如果希望永久添加一个 PATH，可以把上面这行内容添加到 `~/.zshrc` 或 `~/.zprofile` 文件中。

---

- [看源码：bower-name-cli](/note/202305300855)：提到可以通过 `env` 查看所有变量，包括 `$PATH`；

这篇文章分享 macOS 如何设置 PATH，以及 PATH 都位于哪些文件中，都是在哪些文件中定义的。

关于 macOS 的 PATH


想在通知中心增加地震订阅，地震发生后通知用户发生地点、时间、强度等信息。

简单调查了一下，可以从以下渠道获取地震信息：

- [中国地震局]
- [中国地震台网]
- [成都高新减灾研究所]的[手机软件]

观察了一下，四川泸定在 2023-05-12 09:04:44 发生的一次轻微地震（3.2 级），减灾所 APP 09:07 向我推送了地震通知，地震网、地震局的网站一个小时后还没有刊登这条消息，之后我没有再关注，所以不确定有多大的延迟。

减灾所的 APP 有地震预警功能，[地震预警]是指：

> 地震已经(在震中)发生，但震灾区尚未感到破坏性地震波时，震灾区收到对即将到来的破坏性地震波的警告信号。


想在通知中心增加地震订阅，地震发生后通知用户发生地点、时间、强度等信息。简单调查了一下，可以从以下渠道获取地震信息：地震局、地震台网、成都高新减灾研究所开发的手机应用。

关于地震监测的简单调查


[通知中心] 最近增加了语音创建待办提醒的功能，实现方法是使用 [jieba] 中文分词库。

jieba 原作是一个 python 库，社区衍生出了很多[其他语言的版本]，jieba 的 README 提到的 Node.js 版是 [nodejieba]，它是基于 C++ 的 [cppjieba] 实现的。

cppjieba 默认的分词模式和原作 jieba 有一个很大的不同：cppjieba 会把每一个数字或英文字母[单独进行拆分]，而 jieba 默认不会。要想避免这个现象，cppjieba 需要开启 HMM 模式，而 jieba 不需要。开启 HMM 模式可能会分出字典没有的词，这不符合我的使用场景。基于 cppjieba 的 nodejieba 也存在一样的问题。

幸好 Node.js 的 jieba 还有另一个版本，即 [`@node-rs/jieba`]，它是基于 jieba 的 Rust 版 [`jieba-rs`] 开发的，作者都是 [messense]，messense 另一个更知名的作品是 [aliyundrive-webdav]，我在[之前的文章](/blog/how-to-install-aliyundrive-webdav-on-ac86u)分享过 aliyundrive-webdav 的使用。

`@node-rs/jieba` 的使用更接近原作 jieba，通知中心用的就是它。公众号可以自动把用户的语音转换为文字，通知中心收到文字后，使用 `@node-rs/jieba` 对其进行分词，接着对各词语进行逐一判断，从中提炼出时间、事情两项关键信息，最后就能获得结构化的数据。


在 Node.js 下建议使用 @node-rs/jieba 进行中文分词，这是通知中心的语音创建待办功能的实现方法。

jieba 中文分词，Node.js 建议使用 @node-rs/jieba

jieba 中文分词


Y Combinator 的 [Startup School] 系列有很多值得学习、思考的话题，例如 [How to Build An MVP]。

MVP 是 minimal viable product 的简称，最小可行产品。

MVP 的关键是要快，尽快把一个可以用（而不是好用）的产品交到用户手中，从用户的反馈学习接下来怎么做，快速发布，快速迭代，不要担心用户不喜欢你的产品，那些愿意使用 MVP 的人都是 early adopter，他们对产品的宽容度更高，你的产品是真的能解决他们的需求，否则他们不会用你的 MVP，既然用了你的 MVP，就不需要担心产品不完美而吓跑用户。

有些人觉得自己从一开始就知道一个完美的产品是怎样的，于是花大量时间去写，直到产品达到他认为的完美状态，这并不是理智的做法。

倾听用户的反馈往往比发布产品之前做的用户调查、竞品分析更好。坐在办公室，看到的都是问题；走出去调研，看到的都是方法。不要想太多，尽快把产品交到用户手中，MVP 做得很烂，有损失吗？没有。第一批用户之所以愿意向你反馈，不是因为你的 MVP 很好用，相反，就是因为不够好用，但是他们有一个切切实实的问题需要解决，而你的产品可以解决这个问题。

后来成为独角兽的 MVP 通常都有三个共同点：

- 在很短的时间内写出第一个 MVP，几周而不是几个月，然后快速发布出去；
- 功能很简单；
- 只面向很少的一部份用户，做一个只有 100 人很喜欢你的产品，远远好于做一个有 1000 个人觉得还行的产品，尤其是 MVP；

Airbnb 的 MVP 没有支付功能，没有地图视图，只能出租一张床，只在举办大型会议的城市里短暂运营，会议结束就在这个城市下线，最初的想法很简单，就是让人们以很低的价格短暂地找一个可以睡觉的床位，其实就是共享床位。

Twitch 的 MVP 是创始人自己写了一个网站，这个网站只有一个网页，网站域名以自己的名字命名，justin.tv，页面内容只是 24 小时直播自己在寝室的活动，现在的 twitch 可以说完全不同。

Stripe 的 MVP 有很多需要人工完成的 papework。

MVP is built for customers who have their hair on fire.

当用户的头发烧起来了，旁边是一个可以解决你的问题的人，但他的解决方法是卖一块砖头给你，只有这一种解决方法，没有水，不要奢望，只有砖头，你说用户买不买？用户会买。

水就好比是一款好产品，砖头就是 MVP，它不是一款好产品，但它可以用，用户可以用它扑灭头上的火。你先把它交给用户，用户这时候会买单，你后续再去快速优化，把它变成水，以后的用户就可以用上你的好产品。

写一款可以满足用户迫切需要的 MVP，或者说，为那些有燃眉之急的用户写 MVP，找到这部分用户，其他不急的用户暂时不要理会。

用户擅长告诉你他的痛苦，但他们不知道这个痛苦怎么解决。你去了解他的痛苦之后，给他一个 MVP，问他，这样可以解决你的问题了吗？

打造 MVP 的几个建议：

- 给自己一个 deadline，不要把“写好了就发布”作为自己的 deadline，要明确具体的时间范围；
- 功能不要贪多，不要贪完美，把真正需要的功能写下来，写完就发布；
- 认真看你写下来的功能清单，思考这些功是有燃眉之急的用户真正需要的吗？删除 MVP 不必要的功能；
- 不要爱上你的 MVP，MVP 永远是不完美甚至是简陋的，不要爱上 MVP，一开始就预料到可能会在以后把它改得天翻地覆；


Y Combinator 的 Startup School 系列有很多值得学习、思考的话题，例如 How to Build An MVP，如何写一个 MVP。

How to Build An MVP，如何写一个 MVP？

How to Build An MVP

[lunrjs]，pure JavaScript-based、client side，原理是所谓的 inverted index，即[倒挂索引]、反向索引，关于 inverted index 的简单科普可以看[这篇文章]。

简单点说，在你希望使用全文搜索的页面引入 lunrjs，然后把这个页面的内容都传入 lunrjs，让它生成一个 inverted index，搜索的时候，就是调用 lunrjs 搜索这个 inverted index。生成索引、对索引进行搜索，都是在浏览器进行。这意味着如果你想搜索一个博客的所有文章，你就需要先让浏览器把所有文章都请求下来，并在浏览器对所有文章建立倒挂索引，所以 lunrjs 不太适合大博客。如果你只是想搜索当前页面的内容，lunrjs 无疑是适合的，因为当前页面的内容已经打开了，例如[这个页面]。

Elasticsearch 是全文搜索的大玩家之一，[它也是基于]倒挂检索实现全文搜索的，不过它是提前生成检索并保存在服务器，而不是让浏览器即时生成，这也意味着用户每一次检索都要发起网络请求。

Algolia 和 Elasticsearch 是同一类产品，此外还有 [ZincSearch]、[meilisearch]。lunrjs [自称]类似 [Solr]，但体积小得多、没那么聪明，而且 Solr 和 Elasticsearch 一样是服务端搜索。lunrjs 没有自称类似 Elasticsearch 或 Algolia，因为后两者的功能更丰富，应用场景也更广泛，可能就像飞机和汽车的区别吧，都是交通工具，但差异很大。

有网站一开始用 lunrjs，后来改用 Elasticsearch，可以打开[这篇文章]看看它的理由。

[tinysearch] 也是一个客户端全文搜索工具，作者不是很喜欢 lunrjs 使用 js 去做索引生成和搜索的工作，他觉得静态博客应该尽量少 js，而且 js 也慢，于是他用 rust 写了 tinysearch，打包成 WebAssembly 在浏览器运行。

另外 lunrjs 的索引数据结构是倒挂索引，而 tinysearch 用的是所谓的 Bloom Filter，[这篇文章]描述了为什么用 Bloom Filter 而不是 Inverted Index 去索引文章，主要原因还是希望可以降低发送到浏览器的数据体积。尽管如此，tinysearch 作者表示每篇文章大概会生成 4KB 的索引，1000 篇文章就大概要生成 4MB 的索引，gzip 后会小一些，但还是太大了，所以作者表示 tinysearch 只适合小博客。

[stork] 是另一个使用 WebAssembly 的静态博客全文搜索工具。

[Fuse.js] 也是比较多人使用的客户端全文搜索工具，它也是基于 inverted index，它的主要特色是模糊搜索，即 fuzzy search，但[可能]会给出不精确的结果。[μFuzzy] 是另一个模糊搜索工具。

虽然 lunr.js、tinysearch、fuse.js 的本意都是客户端搜索，但你完全可以把它们用在后端，用它们生成索引，前端搜索时发起网络请求，后端用它们从索引中搜索内容，最后返回匹配的结果。

不是很清楚以上搜索对中文的支持，[有人说](<>) meilisearch 对中文友好，它是服务端搜索，有人[建议] 10TB 的内容也用它去做搜索。

对于服务端搜索，如果文章都保存在数据库，其实也可以直接[搜索数据库]。

---

相关文章：

- [文档搜索 ripgrep 如何使用](/note/202105041145)

静态博客全文搜索可以使用 lunr.js、tinysearch、stork、fuse.js 等纯客户端工具，但它们到只适合中小型的内容不是很多的博客，对于大型博客还是需要使用服务端搜索，例如 Elasticsearch、meilisearch 等。

静态博客全文搜索简单调查：有哪些开源库？它们的优缺点是什么？

静态博客全文搜索简单调查

JWT 是 Json Web Token（以下简称 token） 的简称，阿里云函数目前公测 [JWT 认证]方式。

## JWT 简单科普

JWT 是一段字符串，由三部分组成，分别是 Header、Payload、Signature，中间用 `.` 隔开，即：

```text
xxxxx.yyyyy.zzzzz
```

其中 Header 格式固定，就是下面这样的：

```json
{
 "alg": "HS256", //加密算法，可以是 "RS256" 等
 "typ": "JWT" //固定不变
}
```

Payload 规定了多个[固定的字段]，例如 [`exp`] 字段表示 token 的过期时间，除了固定字段外，开发者可以根据需求自行添加其他字段。

```json
{
 "sub": "1234567890", //固定字段，subject identifier
 "iat": 1516239022, //固定字段，issued at，令牌的颁发时间
 "name": "John Doe", //开发者添加的字段
 "admin": true //开发者添加的字段
}
```

注意上面的 `xxxxx`、`yyyyy` 不是 json 字符串，而 Header、Payload 是，所以要用 Base64Url 把它们转换为更干净的字符串才能拼接在一起。Base64Url 是 base64 的衍生版，因为 base64 有少数字符不适合在 url 使用，例如 `+`、`/`，Base64Url 可以避免生成这些字符。

第三部分，即 Signature，是对 Header、Payload 的签名，签名算法在 Header 规定，签名密钥由开发者自行生成，对于 node.js，可以[这样快速生成]：

```js
const key = require("crypto").randomBytes(64).toString("hex");
```

不过阿里云函数的 JWT 认证要求使用一种叫 JWK（Json Web Key）的签名密钥，所以上面这种密钥不能填入阿里云函数的设置页。JWK 密钥生成方式有很多，比如可以用 [mkjwk.org] 在线生成。

JWT、JWK 是[同一套体系](<>)下的两个概念：

![JOSE](jose.jpg)

当你确认了 Header、Payload 并获得了一个签名密钥，就可以生成 Json Web Token（JWT）了，开源社区有[很多库]可以帮助你生成 JWT，例如 [jsonwebtoken]，你也可以把这三个信息粘贴到 [JWT Debugger] 快速生成 JWT，方便测试。

在 JWT Debugger 顶部选择签名算法，阿里云函数的文档使用 RS256 作为例子，这是一种非对称加密算法，相对 HS256 等对称加密更安全，所以建议选择 RS256。在 Debugger 下方的 Private、Public key 输入框，可以看到 JWT 支持使用多种密钥生成，其中就包括 JWK。

![](jwt_debugger_key.png)

## 云函数开启 JWT 认证

JWT 认证适用于 HTTP 触发器，调用方发起 HTTP 请求时需要携带 Json Web Token 参数，函数触发器会先对 token 进行验证，验证通过了才会执行函数。

![JWT 认证流程](jwt_process.png)

前面已经讲了 token 的生成方式，但这里还有一个问题：token 由谁提供？token 是一个敏感参数，不能在前端生成，只能放在后端，而且 token 必须有时效性，最好尽量短。所以开发者可以设立一个独立的接口，让前端传入一些参数（例如用户名和密码）换取 token。这是一种方式，具体采用什么方式应该根据具体的业务场景决定。

> 向客户颁发 token 的形式由用户根据具体的业务场景决定，可以将颁发 token 的功能部署到生产环境，配置成普通 API 后由访问者通过用户名密码获得，也可以直接在本地环境生成 token 后，直接拷贝给指定用户使用。[出处]

以下是阿里云 fc 开启 JWT 认证的[操作步骤]：

![阿里云函数 JWT 设置界面](fc_jwt_config.png)

1. 为函数开启 HTTP 触发器，在认证方式处选择“JWT 认证”；
2. 接着填写“JWKS”，JWKS 是 JWK Set 的简称，即一组 JWK，JWK 前面已经讲过，就是密钥，对于非对称加密，这里填写的是公钥，私钥用于后端生成 token；
3. 在“JWT Token 配置”处，告诉函数 token 将放在哪里发起请求？默认放在 header 的 Authentication 字段且使用 `Bearer` 前缀，建议 Bearer 后加一个空格，即 `Authentication: "Bearer ${token}"`，你也可以放在 url query 发起请求，前面已经说过，token 经过 Base64Url 处理，可以安全地放在 url；
4. 接着填写“JWT Claim 转换”，JWT Claim 就是 JWT 声明，Payload 的每个字段就是一个 Claim，转换的意思是把 Payload 中的某个叫 A 的字段转换（映射、改名）为 B 并作为参数传递给函数，如果你的函数不关注 Payload 中的数据，可以忽略这个项目；

在阿里云函数中，我们不需要对调用方发送过来的 token 进行验证，因为 HTTP 触发器帮我们做了。如果你希望自己实现 token 的验证，也可以使用前面提到的各种库实现。

## 结合 refresh_token 使用

JWT 最好设置较短的有效时间，过期后可以使用 refresh_token 获取新的 JWT。关于 refresh_token 的作用，可以看 stack overflow 的[这个提问]，以及这个 [Youtube 视频]。

---

相关文章：

- [你可能没那么了解 JWT]：这篇文章可以帮助我们对 JWT 等相关概念有较为系统的了解；
- [阿里云 OSS 和 CDN 简单使用笔记](/note/202303250828/)：阿里云 OSS 的签名方法；

JWT 是 Json Web Token 的简称，阿里云函数目前公测 JWT 认证方式，阿里云函数的 JWT 认证要求使用一种叫 JWK（Json Web Key）的签名密钥，这篇文章分享如何设置 JWT 认证。

阿里云函数开启 JWT 认证


很多好看的 APP 图标，包括 macOS、iOS、watchOS 三个平台的应用图标，用于学习、借鉴。作者在 2019 年[分享]了他是如何收集这些图标以及如何压缩这些图标的体积，事实上我是先看到他这篇文章，才知道这三个网站。

- [macOS APP]
- [iOS APP]
- [watchOS APP]

---

相关文章：

- [关于 Apple Clip Code](/note/202012220944/)
- [Apple Watch 的通知图标有些圆有些方](/note/202104051808/)


很多好看的 APP 图标，包括 macOS、iOS、watchOS 三个平台的应用图标，用于学习、借鉴。

很多好看的 APP 图标


## 图片本地处理

macOS 下大多数人会推荐 [ImageOptim]，对于 Windows 电脑，ImageOptim [推荐]使用 [pinga]，如果是 Linux，则推荐 [Trimage]。

以上三款软件都整合了多种开源图片压缩算法，可以实现无损、有损压缩，支持压缩 jpg、png、svg、gif 等格式的图片。

ImageOptim 还提供了 HTTP API 供用户调用以压缩图片，只[在后端使用]是免费的，我试了一下，在国内网络使用可能有点慢，有时会超时出错。

ImageOptim 压缩 png 如果觉得慢，[可以停用] PNGOUT、Zopfli 算法。

pinga [有一个页面]对比了多个无损 png 压缩算法的效率和速度，另一个开发者也[对比]了多个无损 png 压缩算法的效率和速度，同时加上了有损的 pngquant。

从测试结果来看，不同无损压缩算法的速度可能差异很大，但压缩的体积可能差异不大。另外，如果很在乎速度，可以用 pngquant，它比有损压缩快得多，虽然画质会有所下降。ImageOptim 开启有损压缩后，也会使用 pngquant。

以上是免费的图片压缩软件，付费的也有不少，例如 [ppduck]。

以上都是客户端软件，网页软件也有不少，例如 [Squoosh]、[Recompressor]，其中 Squoosh 是谷歌出品，但它一次只能选择一张图片，Recompressor 可以选择多张图片进行压缩。它们都是在浏览器本地压缩图片，不会上传到服务器。这类网页工具往往使用 WebAssembly 技术。

一个付费网页压缩软件：[compressor]。

另一个使用 WebAssembly 处理图片的网页工具是 [photon]，但它不是一款图片压缩工具。

## PDF 本地处理

WebAssembly 也经常用来处理 PDF：

- [localpdf]：合并 PDF、压缩 PDF、PDF 加水印、提取 PDF 中的内容；
- [WASM-PDF-Combiner]：合并 PDF；
- [lookscanned]：使 PDF 看上起像被打印出来的；

使用 WebAssembly 的一个好处是可以让文件处理在浏览器本地进行，无需上传到服务器，不仅速度更快，还可以打消用户对自身数据安全的顾虑。

当然，即使不使用 WebAssembly，在浏览器本地处理 PDF 有时也能获得比较好的体验：

- [pdf-pages]：从 PDF 中提取页面、添加空白页面、复制页面、调整页面顺序；
- [pdf-unspread]：有些 PDF 页面是横向的，分成左右两边，分别显示两页内容，这个工具可以把左右两边的内容拆分为两个 PDF 页面；
- [mobius-print]：把普通的 PDF 文件页面，按照 Möbius printing 方法进行重新排序，方便进行双面打印；

以上三个小工具使用 [pdf-lib] 而不是 WebAssembly，也可以获得不错的本地体验，作者[也尝试了] [PDF.js]，但效果不好。

---

相关文章：

- [如何压缩 PDF 文件：imagemagick、Ghostscript](/blog/compress-pdf-file-using-ghostscript-or-imagemagick)


本地图片处理，macOS 推荐使用 ImageOptim，Windows 推荐使用 pinga，网页工具推荐 Recompressor。借助 WebAssembly 技术，可以在浏览器本地对 PDF 进行较复杂的处理，不使用 WebAssembly 也可以使用 pdf-lib 对 PDF 进行简单的本地处理。

本地图片压缩、PDF 处理工具简单调查


[通知中心]的每日天气预报通知使用的是和风天气的 API，但从 2022 年 11 月开始，和风的免费额度[大幅下降]，从原来每天 5 万次请求[下降至] 1000 次，而且 2023/04/13 这一天通知中心发起的大部份请求都响应超时，这不得不让我考虑放弃使用和风 API。

简单调查了一下目前可用的部分免费天气 API：

- [和风天气]：已确定弃用；
- [彩云天气]：免费额度包括每天 1000 次调用，QPS 为 8，支持未来两天逐小时天气预报；
- [心知天气]；免费用户无调用次数的限制，但 QPS 只有 1；
- [高德地图]：个人[免费] 0.5 万/天，企业[免费] 30 万/天（1000QPS），返回的数据很简单，没有逐小时的天气数据，只区分白天和晚上，只有天气、气温、风向风力三个指标，只支持中国大陆、香港澳门，不支持台湾；
- [百度地图]：个人[免费] 0.5 万次/天（30QPS），企业[免费] 30 万次/天（100QPS），返回的数据和高德基本相同，也区分夜间白天，只有天气、风力风向、气温三个指标，但它免费额度包含一定量的海外天气查询，这是高德没有的，另外收费版支持经纬度查询；
- [中国气象数据网]：国家队，但只有 7 天免费试用期；
- [OpenWeather]：免费额度包括每月 100 万次调用，支持未来五天每三个小时的天气预报，支持空气污染指数查询；
- [weatherapi]：免费额度也是 100 万次/月，支持未来三天每小时的天气预报，支持空气质量指数查询；
- [Accu Weather]：免费额度每天只有 50 次请求；
- [wttr]：它不是空气服务提供商，是一个开源项目，但提供了 API 调用获取天气信息，不支持逐小时天气预报，但区分早上、中午、傍晚、夜间，支持未来三天预报，每天有数千万次请求，但它其实也是调用其他天气服务的 API，而且偶尔会因为超限而[无法使用]，wttr 只用了一个 [data source]，但[不清楚]它具体用的是哪个；

如果不想付费，以上天气 API 其实只有高德（或百度）、OpenWeather 可选，其他 API 的调用次数或 QPS 限制太多，不适合通知中心的使用场景。和风突然大幅降低免费额度让我对彩云、心知也缺少安全感。通知中心的天气通知主要是让用户对今天的天气有一个总体的判断，例如今天是晴还是雨，今天是冷还是热，对逐小时的数据需求不大，同时我不确定 OpenWeather 在国内网络的稳定性如何，所以我考虑百度或高德，我导航用高德地图，所以就用高德 API 吧。如果对台湾或海外天气有需求，应该用百度。不确定高德和百度在开发体验上的区别。

高德或百度天气 API 有一个比较大的问题：只能依据 adcode 查询天气，而不是经纬度。有些面积比较大的行政区域共用同一个 adcode，例如整个东莞市都是 441900，没有细分的 adcode，而东莞面积并不小，这意味着东莞的天气预报信息可能不会很准确。再比如若羌县，中国面积最大的县，相当于两个浙江省，整个县的 adcode 都是 652824，高德地图依据 652824 返回的天气信息恐怕无法反映整个若羌县的天气情况。有些面积很小的行政区域，例如澳门，反而细分了多个 adcode，从天气角度来看没有必要。

如果接受付费，和风天气是[按量计费]，天气 API 30 万次以内 0.001 元/次，如果一个月调用 10 万次（平均一天 3333 次），费用是 100 元，有点贵。心知天气免费套餐就已经是无限调用，但 QPS 只有 1，要想把 QPS 提高到 1 以上，至少需要 [599 的套餐]，如果不需要实时天气信息，心知的免费套餐就够用，因为数据可以缓存起来，另外免费不支持商用。彩云对个人开发者而言[是最贵的]，1200 元/月的个人套餐每天有 5 万次调用，QPS 只有 8，不过彩云支持分钟级天气预报，这是一个很好的功能。

---

相关文章：

- [高德天气现象表]
- [和风天气图标]


和风天气 API 免费额度大幅下降，而且稳定性下降明显，在调查了市面上多款免费天气 API 后，我决定改用高德地图的天气 API。

免费天气 API 简单调查：有哪些免费天气 API？它们的优缺点是什么？

免费天气 API 简单调查


OpenAI CEO Sam Altman 四年前写的一篇文章，[How To Be Successful]。

Sam 写这篇文章的依据是他观察过的几千名创业者，以及在他的工作和创业过程中对这个问题的思考：是什么使得一个人赚取了巨额财富或创造了一些了不起的东西？

Sam 认为这些取得巨大成功的人往往具备以下特质，或者说，如果你想取得巨大成功，Sam 认为你需要做到以下 13 点：

1. Compound yourself
2. Have almost too much self-belief
3. Learn to think independently
4. Get good at “sales”
5. Make it easy to take risks
6. Focus
7. Work hard
8. Be bold
9. Be willful
10. Be hard to compete with
11. Build a network

Sam 对每一点都展开了详细的说明，这篇文章值得反复阅读。


OpenAI CEO Sam Altman 四年前写的一篇文章，How To Be Successful，Sam 认为这些取得巨大成功的人往往具备以下特质，或者说，如果你想取得巨大成功，Sam 认为你需要做到以下 13 点。

如何获得成功，获得巨大成功的人具备的特质

如何获得成功

这篇笔记有助于我们搞清楚 Apple Silicon 电脑如何正确地使用 Docker Desktop。

2019 年 4 月，Docker Desktop [开始支持](<>) ARM 镜像和容器的开发，这意味着开发者可以在 x86/amd64 电脑上创建和运行 ARM 镜像，这是通过 QEMU emulation 实现的。当时 Apple Silicon 还没有发布，所以反过来，能不能在 ARM 电脑上创建和运行 x86/amd64 镜像还不知道。

![](docker-qemu-diagram.png)

2020 年 11 月，第一款搭载 Apple Silicon 的电脑[发布]，这是一部 MacBook Air。当时 Docker Desktop 无法在 M1 电脑运行，打开时会[提示] CPU 架构不兼容。

一个月后，即 2020 年 12 月，Docker Desktop [发布]第一个适配 Apple Silicon 的版本，除了把代码编译为原生 ARM 代码之外，还把 HyperKit（如上图） 替换成苹果的 [Virtualization Framework]，这是一个用来创建并管理 Linux VM 的框架，Linux VM 其实就是容器的运行环境。

> In macOS 13 and later on Mac computers with Apple silicon chips, the Virtualization framework supports Rosetta in ARM Linux virtual machines (VMs). [出处]

这个版本的 Docker Desktop [支持]在 ARM 电脑上创建和运行 x86/amd64 镜像，就像 2019 年开始支持的在 x86/amd64 电脑上创建和运行 ARM 镜像，只是反过来了。虽然 Docker Desktop 使用了 Virtualization 框架，但它依然使用 QEMU 转译 x86/amd64 代码，而不是 Rosetta。QEMU 并不完美，有时会导致容器在运行中崩溃。Docker 官方在 [Known issues for Mac with Apple silicon] 这个页面中表示：

> Attempts to run Intel-based containers on Apple silicon machines under emulation can crash as qemu sometimes fails to run the container. [出处]

所以 Docker 表示，在 ARM 电脑上运行容器，尽量运行 ARM 容器，而不是通过 emulation 运行 x86/amd64 容器，如果你的镜像需要发布出去给其他开发者使用，建议针对 x86/amd64、ARM 分别发布一个版本：

> We recommend running ARM64 containers on Apple silicon machines whenever possible, and encouraging container authors to produce ARM64, or multi-arch, versions of their containers. [出处]

`docker build` 使用 `--platform` 参数可生成对应平台的镜像，`docker run` 也有 `--platform` 参数，通常和 `docker build` 同步。

```bash
# 没有使用 --platform 参数，生成的镜像平台和 Dockerfile 中的 FROM 指令有关
# 如果 FROM 后的 --platform= 参数是 amd64，build 后的镜像也是 amd64，如果是 ARM，build 后也是 ARM
docker build -t image_name:image_tag .
# 创建一个 ARM 镜像
docker build --platform=linux/arm64 -t image_name:image_tag .
# 创建一个 amd64 镜像
docker build --platform=linux/amd64 -t image_name:image_tag .
```

如果你的 docker 镜像是部署到 x86/amd64 服务器，而本地电脑是 Apple Silicon，那在 build 的时候可以针对两个平台分别 build 一个版本，本地测试时运行 ARM 版本，部署到服务器时则选择 amd64 的版本。

一年后，即 2021 年 12 月，Docker Desktop 4.3.0 发布，这个版本[不再强求]电脑安装 Rosetta 2，在此之前[要先安装] Rosetta 2。这里的 Rosetta 是用来转译 Docker Desktop 客户端的，而不是用来转译容器。

又过了大约一年，即 2023 年 1 月，Docker Desktop v4.16 发布，[新增] Rosetta for x86/amd64 emulation，这时终于支持使用 Rosetta 而不是 QEMU 转译 x86/amd64 应用了。有些 x86/amd64 容器在 QEMU 下无法正常运行，开启 Rosetta 就可以了，比如 [Crawlee](<(/blog/introduction-to-crawlee-and-how-to-deploy-it-to-serverless-function)>)，再比如 [mssql-docker]。

截至到 v4.17.1，这个功能还在开发中，默认关闭，需要用户[手动开启]。

![](docker-emulation.jpg)

上面这个图表描述了 Docker Desktop 分别在 Apple Silicon 和 x86 电脑运行的模式。

---

相关文章：

- [我常用的 docker 和 docker-compose 命令](/blog/frequently-used-docker-command)

这篇文章整理了 Docker Desktop 对 Apple Silicon 支持的适配过程，目前 Docker Desktop 已经支持通过 Rosetta 把 VM 中的 x86/amd64 代码转译为 ARM 代码，在这之前是 QEMU，而 Rosetta 无论是性能还是兼容性都被 QEMU 更好。

Docker 对 Apple Silicon 的支持

简单记录一下阿里云对象存储和 CDN 的使用。

从 2022-10-26 开始，小程序和公众号[没有任何 API](/blog/wechat-miniprogram-get-userinfo-without-popup-authentication/) 可以获取用户的微信头像和微信昵称（除了旧版基础库），对于小程序，微信提供了所谓的头像昵称填写能力，让用户主动提供头像和昵称。这意味着开发者不能继续使用位于微信服务器的用户头像（这是免费的），而是需要把用户上传的头像保存到自已的服务器中（增加了开发者服务器费用）。

我的做法是把头像上传到 OSS，并使用阿里 CDN 加速。

## 费用

[OSS 费用]主要包括：

1. 存储费：0.12 元/GB/月；
2. 外网出流量：00:00-08:00（闲时）0.25 元/GB、8:00-24:00（忙时）0.50 元/GB；
3. 调用次数：0.01 元/万次；
4. CDN 回源流出流量：0.15 元/GB；

前三项费用是使用 OSS 就肯定会产生的，因为我还用了 CDN，所以还会有 CDN 回源流量费用。OSS 还有数据处理、传输加速、DDoS 防护、跨区复制流量等功能，但这些功能不用不收费。

CDN 默认只收取流量费，10TB 以内、中国内地价格是 0.24 元/GB，这个价格大概只有 OSS 流量的一半。由于小程序不支持 http 连接，而 CDN 开启 https 访问需要按照调用次数额外付费，价格是 0.05 元/万次，是 OSS 调用次数的 5 倍。

**2023-04-14 更新**：虽然小程序的 API 不支持 https，但在 `<image>` 组件上可以使用 http 链接，所以可以不开启阿里云 CDN 的 https，省下 https 调用费。

EMAS 的云存储比 OSS 更便宜，用量、调用次数价格一样，但是流量价格打了四折左右，且默认开启 CDN，但它功能过于简单，例如文件链接随机生成从而无法根据文件名拼接它的链接、不支持批量增删管理、不能用文件夹分类文件等等，所以我没有使用 EMAS 的云存储。

## 使用

阿里官方提供了从[小程序直传文件到 OSS] 的步骤。直传有两种[签名方法]：

- 服务端签名：服务端根据你的阿里云账号 accessKeyId、accessKeySecret 的生成签名，并设置签名的有效期，前端请求服务端获取签名，然后携带签名上传图片；
- 客户端签名：签名由客户端生成，但生成方式不是根据你的阿里云账号 accessKeyId、accessKeySecret，因为这两个都是敏感数据，不能放在前端，而是根据 STS 临时访问凭证生成签名，那 STS 临时访问凭证从哪里获取？也要建立一个后端服务，这个后端服务根据你的阿里云账号 accessKeyId、accessKeySecret 生成 STS 临时凭证，并设置有效期，返回给前端使用；

无论是后端生成签名，还是前端使用临时访问凭证生成签名，都是短期有效的，这样可以增加 OSS 的安全性。另外我还通过 Referer 白名单设置了防盗链。CDN 也是。

我把 CDN 缓存过期时间设置为最长的 3 年，因为 OSS 支持在 PutObject 等操作发生时，自动刷新 CDN 缓存。

---

相关文章：

- [阿里云函数开启 JWT 认证](/note/202304221717/)

在小程序中，开发者不能继续使用位于微信服务器的用户头像（这是免费的），而是需要把用户上传的头像保存到自已的服务器中（增加了开发者服务器费用）。 我的做法是把头像上传到 OSS，并使用阿里 CDN 加速。阿里官方提供了从小程序直传文件到 OSS 的教程。

阿里云 OSS 和 CDN 简单使用笔记


**2023-03-30 开始**：微信公众号模板消息[不再展示备注]、不再支持自定义颜色、不再显示表情符号。

**2023-03-20 更新**：微信[再发公告]，把新政策开始执行的时间从 2023-03-30 改为 2023-05-04，并且新增不再显示首行内容的规则。

**2023-05-04 更新**：微信[第三次发公告]，新增模板消息内的每一行内容字数不能超过 20 的限制。

## 问题描述

公众号开发[文档显示]，模板消息的内容不能超过 200 字符：

> 模板内容长度不能超过 200 个字符，且必须有至少 10 个固定文字或标点。

在实际的开发中，如果发送的模板消息字符数超过 200，模板消息依然可以正常发送，只是超过的那部分会显示为省略号，因为“备注”显示在最后，所以自动省略不是一个问题：

![](template_1.png)

但在新的规则下，“备注”不再显示，所以我们需要把信息挪到“服务时间”之前的位置，比如“服务状态”，此时超字数会导致服务时间被自动省略，这是一个问题：

![](template_2.png)

为了解决这个问题，需要精确计算“服务状态”的字数，如果超字数，在发送模板消息之前就把超出的部分修改为省略号，如下：

![](template_3.png)

后来模板消息又增加了 20 个字的限制，于是服务状态可以展示的字数大幅减少，下图的省略号是微信自动添加：

![](template_20_limit.png)

有趣的是，如果是连续的英文数字，虽然多了 20 个字的限制，但可显示的字数似乎并没有减少，如下所示，“服务状态”可以一直显示，甚至挤占了“服务时间”的显示空间：

![](template_4.png)

现在的问题是，这 200 个字、20 个字是怎么计算的？

## 20 个字的计算方法

我还不知道 20 个字是按什么标准计算的，但这 20 个字的字，和 200 个字的字，计算方法有很大不同。

简单观察了一下，20 个字的计算有以下规律：

- 所有字符加起来不超过 200 字依然成立；
- 显示的 20 个字不包括自动添加的省略号；
- 空格、中英文标点符号算一个字；
- 一个汉字、连续数字、连续英文单词、连续的数字和英文组合都算一个字，例如“hello123”算一个字，“我们”算两个字；

连续的数字、英文字母被视为一个字，所以上图的“服务状态”字数其实只有 1，小于 20 个字的限制，按道理可以完全显示出来。但同时，因为所有项目的字符加起来超过了 200 字，所以它并不能显示完整，还侵占了“服务时间”的显示。

那 200 个字的限制又是怎么计算的呢？

## 200 个字的计算方法

200 个字的计算方法如下：

```js
const string = "Hello 🌎!";
//[...string] 会变成：[ 'H',  'e', 'l', 'l',  'o', ' ', '🌎', '!' ]
const wordCount = [...string].length; //8
```

注意是 `[...string].length` 而不是 `string.length`，因为 🌎 的字数是 1，但它的 `length` 是 2：

```js
const string = "Hello 🌎!";
const length = string.length; //9
```

顺便提一下，`string.length` 是计算一段字符以 UTF-16 编码的长度，如果要计算其 UTF-8 的长度（即字节数），则是：

```js
const string = "Hello 🌎!";
//node.js
const length = Buffer.byteLength(string); //11
//browser、node.js
const _length = new TextEncoder().encode(string).length; //11
```

ChatGPT 告诉我，一个 ASCII 字符就是一个字节，一个 Latin-1 Supplement 字符是 2 个字节，其他 BMP 字符是 3 个字节，非 BMP 字符都是 4 个字节：

> 1 byte for ASCII, 2 bytes for Latin-1 Supplement, 3 bytes for other BMP characters, 4 bytes for non-BMP characters.

如果要从一段字符中，获取前 N 个字：

```js
const N = 7;
const string = "Hello 🌎!";
const str = [...string].slice(0, N).join(""); //Hello 🌎
```

注意不能使用 `string.slice()`，因为它也是基于 UTF-16 进行 `slice` 的，正如前面所说，🌎 由两个 UTF-16 编码组成，如果只 `slice` 了其中一个，会出现乱码：

```js
const N = 7;
const string = "Hello 🌎!";
const str = string.slice(0, N); //Hello �
```

理解了以上内容，我们就可以计算在不自动省略的情况下，“服务状态”的字数是多少，并把一段过长的文字裁切成刚刚可以放进模板消息的字符串：

```js
const first = "本通知由您主动订阅，如无需通知，请取消订阅";
const keyword1 = "测试测试";
const keyword3 = "2023-03-24 19:00:00";
const totalLengthAllowed = 200;
const currentLength = (first + keyword1 + keyword3).length;
const keyword2LengthAllowed = totalLengthAllowed - currentLength;
const longString = Array.from({ length: 100 })
  .fill(`科技微讯😃通知中心`)
  .join("");

const keyword2 =
  [...longString].length > keyword2LengthAllowed
    ? [...longString].slice(0, keyword2LengthAllowed - 3).join("") + "..."
    : longString;

console.log(keyword2); //keyword2 刚好可以避免自动省略
```

## 总结

公众号模板消息有 2 条字数限制措施：

- 每个字段的字数不能超过 20；
- 所有字段的总字数不能超过 200；

以上两个字数的计算方法不一样，20 个字的限制会把英文单词、连续的数字等看成了一个字，而 200 个字的限制则会把单个数字、单个字母（不是单词）都看成了一个字。

因为超过 200 可能会导致最后一个字段完全显示省略号，所以建议对第二条规则进行处理，例如确保服务时间、服务类型都显示完整，然后计算出服务状态最多可以显示多少个字符，如果字数超了就在代码中把多出的用省略号替代。

做了以上这一步之后，在通知中心的使用情景下，我可以不对服务状态的字数是否超 20 字进行判断，因为我不知道这里的 20 字的具体明确的计算方法，而且微信会自动把多出的字符替换为省略号，不需要担心它会挤压其他信息。


精确计算微信公众号模板消息字数限制，避免字符串被自动省略，计算字符数量的关键是要算上模板标题的字数。

精确计算微信公众号模板消息字数限制


[Brick Experiment Channel] 是一个在 Youtube 发布原创乐高制作视频的频道，目前有 301 万订阅。2022 年 11 月，该频道博主在他的博客分享了他做 Youtube 将近五年来的[详细收入数据]。

我摘录了以下部分数据，数据截至到 2022 年 10 月：

- 2017 年 12 月开始成为一名 Youtuber，2018 年 6 月加入 Youtube 的广告分成计划；
- 截至到 2022 年 10 月有 290 万粉丝（现在已经超过 300 万）；
- 上传了 65 个视频，平均制作时间为 100 小时；
- 总收入 66.4 万美金，全部是来自 Youtube 广告分成，没有粉丝打赏等其他收益，换算为人民币大概是 460 万，平均月入 8.6 万，平均时薪 90 美元，约 620 人民币；
- 总播放 7.05 亿次，平均每个视频 1080 万播放，平均长度是 8 分钟，点击率是 5.9%，平均视频收益 1.02 万美金，约 7.03 万人民币；
- 平均 [RPM]（千次播放收益）为 0.94 美元，过去五年虽然有波动，但总体稳定保持在这个数；

RPM 在不同国家和地区之间差异很大，最低和最高之间有近 10 倍的差异，澳大利亚、美国、英国这些发达国家最高，最低的两个国家是土耳其、印度。博主表示，如果有一天 RPM 突然下降得比较多，通常是因为那天印度人看得比较多；

他的视频生命周期很长，新视频发布后两个星期内播放次数增加较快，之后增速有所下降，但总体上依然会平稳增加，一年后每天新增播放量竟然和发布两周后差不多，RPM 也是。对这位博主来说，生产一个视频就像把自已的付出存进了银行，每天都可以收到**稳定**的利息，随着产出视频的增加，每天收到的利息也会增加。

流量几乎全部来自 Youtube 内部，其中 91.5% 的播放来自观众的 Youtube 主页，只有 1.2% 来自 Youtube 搜索。外部流量从比例来看极少，只贡献了 0.5% 的播放，其中 11.7% 来自谷歌搜索，11% 来自 Reddit。

作者把详细数据都通过 Excel 表格[共享出来了]，Hacker News [网友的讨论]。

能赚到钱的是少数，能赚到很多钱的更是少数。这位博主统计了 100 位拥有 1 万粉丝以上的乐高博主，他们平均从业 9 年，平均 47 万粉丝，平均上传 504 个视频，平均累计 2080 万播放，如果按照 RPM 为 1 计算，他们平均每月收益 1800 美金，约 12400 人民币。

---

相关文章：

- [写博客还能赚钱吗？](/note/202008151513/)
- [Youtube 赚钱最多的网红](/note/202012261610/)
- [Mr Beast 一个月超过 10 亿播放](/note/202104111319/)
- [怎样剪出 Vox 那种视频](/note/202105050917/)
- [制作视频推荐使用这些免费工具](/note/202302241428/)


Brick Experiment Channel 是一个在 Youtube 发布原创乐高制作视频的频道，目前有 301 万订阅。2022 年 11 月，该频道博主在他的博客分享了他做 Youtube 将近五年来的详细收入数据。

Youtube 大博主详细收入数据


三个可以申请免费子域名的服务：

- [eu.org]：从 1996 年开始提供免费子域名；
- [is-a.dev]：位于 Github 的一个项目，申请方式是向该项目提 PR；
- [is-an.app]：同 is-a.dev；


三个可以申请免费子域名的服务：eu.org、is-a.dev、is-an.app

申请免费的子域名

[出处]

在网页增加一个视频，视频 source 是一段 base64 字符串，它是一个 2.4kb 大小、16x16 像素、只有两帧黑色画面的视频，你可以把这段 base64 字符串[转换为视频]。

```html
<video
 id="test-video"
 muted
 preload
 loop
 autoplay
 playsinline
 webkit-playsinline
>
 <source
 src="data:video/mp4;base64,AAAAIGZ0eXBtcDQyAAACAG1wNDJpc28yYXZjMW1wNDEAAANObW9vdgAAAGxtdmhkAAAAAOA5QnjgOUJ4AAAD6AAAAEMAAQAAAQAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAmt0cmFrAAAAXHRraGQAAAAD4DlCeOA5QngAAAABAAAAAAAAAEMAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAABAAAAAACAAAAAgAAAAAAAkZWR0cwAAABxlbHN0AAAAAAAAAAEAAABDAAAAAAABAAAAAAHjbWRpYQAAACBtZGhkAAAAAOA5QnjgOUJ4AAFfkAAAF3BVxAAAAAAALWhkbHIAAAAAAAAAAHZpZGUAAAAAAAAAAAAAAABWaWRlb0hhbmRsZXIAAAABjm1pbmYAAAAUdm1oZAAAAAEAAAAAAAAAAAAAACRkaW5mAAAAHGRyZWYAAAAAAAAAAQAAAAx1cmwgAAAAAQAAAU5zdGJsAAAAznN0c2QAAAAAAAAAAQAAAL5hdmMxAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAACAAIABIAAAASAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGP//AAAAMWF2Y0MBTUAo/+EAGWdNQCjspLYC1BgYGQAAAwABAAK/IA8YMZYBAAVo6uEyyAAAABNjb2xybmNseAAGAAYABgAAAAAQcGFzcAAAAAEAAAABAAAAFGJ0cnQAAAAAAAF1IAABdSAAAAAYc3R0cwAAAAAAAAABAAAAAgAAC7gAAAAUc3RzcwAAAAAAAAABAAAAAQAAABxzdHNjAAAAAAAAAAEAAAABAAAAAgAAAAEAAAAcc3RzegAAAAAAAAAAAAAAAgAAAxAAAAAMAAAAFHN0Y28AAAAAAAAAAQAAA34AAABvdWR0YQAAAGdtZXRhAAAAAAAAACFoZGxyAAAAAAAAAABtZGlyYXBwbAAAAAAAAAAAAAAAADppbHN0AAAAMql0b28AAAAqZGF0YQAAAAEAAAAASGFuZEJyYWtlIDEuNi4xIDIwMjMwMTIyMDAAAAAIZnJlZQAAAyRtZGF0AAAC9AYF///w3EXpvebZSLeWLNgg2SPu73gyNjQgLSBjb3JlIDE2NCByMzEwMCBlZDBmN2E2IC0gSC4yNjQvTVBFRy00IEFWQyBjb2RlYyAtIENvcHlsZWZ0IDIwMDMtMjAyMiAtIGh0dHA6Ly93d3cudmlkZW9sYW4ub3JnL3gyNjQuaHRtbCAtIG9wdGlvbnM6IGNhYmFjPTEgcmVmPTIgZGVibG9jaz0xOjA6MCBhbmFseXNlPTB4MToweDExMSBtZT1oZXggc3VibWU9NiBwc3k9MSBwc3lfcmQ9MS4wMDowLjAwIG1peGVkX3JlZj0xIG1lX3JhbmdlPTE2IGNocm9tYV9tZT0xIHRyZWxsaXM9MSA4eDhkY3Q9MCBjcW09MCBkZWFkem9uZT0yMSwxMSBmYXN0X3Bza2lwPTEgY2hyb21hX3FwX29mZnNldD0tMiB0aHJlYWRzPTEgbG9va2FoZWFkX3RocmVhZHM9MSBzbGljZWRfdGhyZWFkcz0wIG5yPTAgZGVjaW1hdGU9MSBpbnRlcmxhY2VkPTAgYmx1cmF5X2NvbXBhdD0wIGNvbnN0cmFpbmVkX2ludHJhPTAgYmZyYW1lcz0zIGJfcHlyYW1pZD0yIGJfYWRhcHQ9MSBiX2JpYXM9MCBkaXJlY3Q9MSB3ZWlnaHRiPTEgb3Blbl9nb3A9MCB3ZWlnaHRwPTEga2V5aW50PTMwMCBrZXlpbnRfbWluPTMwIHNjZW5lY3V0PTQwIGludHJhX3JlZnJlc2g9MCByY19sb29rYWhlYWQ9MzAgcmM9Y3JmIG1idHJlZT0xIGNyZj0yMi4wIHFjb21wPTAuNjAgcXBtaW49MCBxcG1heD02OSBxcHN0ZXA9NCB2YnZfbWF4cmF0ZT0yMDAwMCB2YnZfYnVmc2l6ZT0yNTAwMCBjcmZfbWF4PTAuMCBuYWxfaHJkPW5vbmUgZmlsbGVyPTAgaXBfcmF0aW89MS40MCBhcT0xOjEuMDAAgAAAABRliIQAK//+9q78yyt0fpUs1YVPgQAAAAhBmiFsQn/+Vg=="
 />
</video>
```

接着在这个页面增加一段 js 代码，用来判断这个视频是否自动播放，如果自动播放，则说明手机没有开启省电模式，如果没有自动播放，可以判断手机开启了省电模式：

```js
const testVideo = document.getElementById("test-video");

testVideo.addEventListener("canplaythrough", (event) => {
 if (testVideo.paused) {
 window.lowPowerMode = true;
 } else {
 window.lowPowerMode = false;
 }
 testVideo.remove();
});
```

在网页增加一个视频，视频 source 是一段 base64 字符串，它是一个 2.4kb 大小、16x16 像素、只有两帧黑色画面的视频。判断这个视频是否自动播放，如果自动播放，则说明手机没有开启省电模式，如果没有自动播放，可以判断手机开启了省电模式。

用一个 2.4KB 的视频判断用户的手机是否开启省电模式


**2023-03-24 补充**：最近涌现了一堆使用 OpenAI API 的工具或项目，变化太快，以下部分内容可能很快就会过时。

[cursor.so] 一个基于 GPT-4 的代码编辑器，让 AI 协助你写代码，这还是一款早期产品，目前免费，内置了聊天模式，聊天模式本意是用来聊代码，但其实可以聊任何话题，相当于免费使用 GPT-4。

Github 推出的 [Github Copilot Labs] 类似 cursor，不同于 [Github Copilot] 只是提供 Code Suggestions，Github Copilot Labs 目前可以向你解释一段代码是做什么的，可以把代码翻译为其他语言，可以用自然语言告诉它根据你的需求写代码，可以为代码写测试等。

[bloop.ai] 也是一款利用 GPT-4 帮助开发者写代码的软件，但它的定位不是代码编辑器，更多的是一款代码阅读器，看源码的好帮手，它支持使用自然语言搜索代码。Understand your codebase with GPT-4 and Semantic Code Search。

[N46Whisper]：利用 OpenAI 的 Whisper 模型把视频中的语音转换为文字，然后利用 OpenAI 的 GPT 模型把文字翻译为其他语言，例如中文，这个项目对提高字幕组的效率很有帮助。Whisper 其实也有翻译功能，但目前仅支持转换为英文。Whisper 模型对算力要求较高，大多数家用电脑不达标，可以把视频上传到谷歌网盘，[代码运行在谷歌 Colab]，Colab 的免费额度就能提供足够的运算能力。

[generate-subtitles] 是另一个类似的项目，利用 Whisper 把视频或音频中的对话提取为文字，但接着它用 LibreTranslate 而不是 GPT 翻译提取的文字。

[Stable Diffusion]、[DALL-E]、[Midjourney] 是目前知名的利用 AI 生成图片的工具，用户输入一段文字，描述你希望得到一张什么图片，它就会按照你的要求凭空产生一张图片，画质往往很好，其中 DALL-E 是 OpenAI 旗下产品。

[OpenAI Cookbook]：The OpenAI Cookbook shares example code for accomplishing common tasks with the OpenAI API. 这里收集了一些使用 OpenAI 的 API 的例子，可以理解为做题集，不仅仅是 GPT 的题集，还有 OpenAI 的其他模型，例如 Embeddings、DALL-E。

[MyShell]：一个 telegram 英文语音聊天机器人，体验很不错，会巧妙地和你展开话题，冷场的完全反义词，不仅可以练英文，还可以学习沟通技巧，但是它[不是基于 GPT 写的]，用的是免费的 Bing Chat，嗯，这貌似是[逆向] [New Bing] 基于 GPT 的聊天接口。MyShell 的机器人之所以这么擅长聊天，Prompt 是关键。

ChatGPT 出来后，Prompt Engineering 变成了一项学问，网上出现了很多相关文章和分享，例如 [Learn Prompting]、[Learning Prompt]、[ChatGPT3-Free-Prompt-List]、[Jailbreak Chat]、[neatprompts]、[Awesome ChatGPT Prompts]，这些都是 Prompt 的好例子、学习资料、使用技巧分享。

有人基于 [Awesome ChatGPT Prompts] 做了一个 [ChatGPT Prompt Generator]，作者把 Awesome ChatGPT Prompts 分享的 `Act as xxx` 类的 Prompt 放入 BART 模型进行训练，在这个模型的加持下，生成器就会根据你提供的关键词，按照 `Act as xxx` 的格式生成一个完整的 prompt。

有人把 Prompt Generator 生成的 Prompt 叫做 AI Prompt。类似的 Prompt Generator 很多，针对 Midjourney 的有 [Midjourney Prompt Generator]，这个生成器是作者基于用户发给 Midjourney 的 [250k 条 Prompt] 用 GPT-2 [训练出来的模型]制作的，这个生成器知道什么 Prompt 可以让 Midjourney 生成好看的图片，你只需要往生成器输入一些关键词，它就会生成一些完整的 Prompt。

BTW，根据 OpenAI 的开发文档，一个好的 Prompt 是这样的：

> Showing, not just telling, is often the secret to a good prompt. [出处]

OpenAI 官方也在一篇文章中给出了具体的[最佳实践指引]，一共有 8 点。

用来生成图片的 Prompt [可以卖]，如果这个 Prompt 可以生成好看的图片的话，有趣的是这个网站的作者就是是 [Tinyprojects] 的作者。有人觉得卖 Prompt 很搞笑，所以这个人收集了一些[免费的图片 Prompt]。

Prompt 对塑造 AI 的性格、能力是至关重要的，但维护 Prompt 有点麻烦。

GPT 虽然可以理解用户的上下文，但单次能理解的字数有限，例如 GPT-3.5 系列模型最高支持 4096 个 token，GPT-4 默认支持 8192（最高支持 32768），这意味着如果字数超了，你就需要重开一个新对话，或者清空聊天记录，然后你又要从头开始输入你的 prompt。有时候我们为了微调 AI 的性格或能力使之达到最优，这需要调整 Prompt 的某些用词，如果每次都要重新复制整个 Prompt，修改，再粘贴回对话框，这显然不符合程序员的风格。

市面上有一些可以帮助开发者维护 Prompt 的工具，例如 [everyprompt]，开发者提前定义一些 Prompt，这些 Prompt 可以内置一些变量（[这篇文章]很好地解释了这种模式），Prompt 可以被部署成函数并能通过 HTTP 被外部服务调用，函数可接收参数，这些参数接着被传入 Prompt 的变量，everyprompt 再把这个新 Prompt 传给 OpenAI 获取响应，这个过程向我们展示了如何开发基于 Prompt 的 API，开发者不需要写一行代码。[steamship]、[promptable.ai] 也提供了类似的服务。

可以把 OpenAI 的 API 整合到各种服务中，例如有人整合进 [Github issue]，用户提交的每一条 issue 都会被 AI 回复；有人[整合进论坛]，用户发起一个帖子，就会有 AI 回帖，双方可以一直互动下去；有人用它来[搜索你的 kindle 笔记]；有人用把它自动[给代码写文档]，用户可以[用自然语言查询文档]；有人开发了一个 [Figma 插件]，用自然语言画原型图；有人用它来[写 git commit]。最后，有人整理了 [600+ 款 AI 相关的网站]。


人们围绕 OpenAI GPT 开发的有趣项目，例如基于 GPT-4 开发的代码编辑器、代码阅读器、字幕提取并翻译工具、图像 AI 工具，还有很多围绕如何写一个好 Prompt 这个主题展开的项目，例如 Prompt Generator、Prompt API 等。

人们围绕 OpenAI GPT 开发的有趣项目

我写的微信小程序“通知中心”有一个打卡通知的功能，里面的项目支持纵向拖拽排序，是使用 wxs 实现的。具体来说，是在列表每一个项目的 `touchstart`、`touchmove`、`touchend` 事件中绑定来自 wxs 的事件处理函数，在事件函数中依据滑动的位置实时改变列表项目中的 css 属性（`transform`、`transition`），从而使之产生被拖动且有动画的效果。把事件函数写在 wxs 这种做法确实流畅，但 wxs 写起来有点麻烦，我也很少写，不利于我后续维护。

![](drag-sort-wxs.gif)

最近看到被称为光神的博主写的《[手写一个性能较好的拖拽排序]》，启发到我了，启发点主要是拖动时不实时修改列表中的项目，而是修改它的替身。具体点说，把被拖动项目复制一个替身出来，把替身设为 `position: fixed`，拖动时，列表中的项目都不动，只改变替身的位置，当替身到达某个临界点需要列表中的项目挪开时，才改变列表中项目的位置，无论是位置的改变还是改变时的动画，都通过 css 实现。

博主的例子同时支持纵向、水平两个方向的拖拽，且支持动画：

![](drag-sort-example.gif)

我看了博主的文章后改写了通知中心的拖拽排序功能，为了便于后续维护，没有增加动画效果，拖动过程中也不会实时调整项目位置，当松手时，再对位置进行**替换**：

![](drag-sort-replace.gif)

光神的对写一个性能较好的拖拽排序的流程总结：

> pointerdown 的时候 clone 一个新元素，pointermove 的时候改变它的 translate3d 来实现拖拽，pointerup 的时候删掉它。 
> 通过 getBoundingClientRect 取出每个元素的位置，pointermove 的时候判断指针在哪个元素，然后通过 translate3d 移动前后位置之间的元素，还要设置 transition 的过渡效果。 
> 最后 pointerup 的时候通过 insertBefore 完成元素移动，也就是排序的效果。 
> 自始至终，我们只改变了一次 dom 顺序，拖拽过程中只是设置了 translate 位置，这种实现方式性能会比较好。

把被拖动的项目复制一个出来并设为 `position: fixed`，拖动时，列表中的项目都不动，只改变复制项目的位置，当完成拖动后隐藏复制项目，并最终更改列表中的项目，在拖动中看到的位置改变、动画都是通过 css 实现的。

写一个性能较好的拖拽排序

写 typescript 的过程中我也遇到了 `Index signature is missing in type xxxx` 报错，不知道哪里出问题，直到我无意间把类型声明从 interface 改为 type alias，报错消失。

为什么会这样？谷歌找到 Typescript Github repo 的一个 [issue]，开发者在这里解释了出现这个报错的原因。

举个例子：

```typescript
//定义一个 index interface
interface Test {
 [key: string]: string;
}
//用 interface 的方法定义一个类型
interface Value1 {
 name: string;
}
//用 type alias 定义一个类型，看起来和前面一个是一样的
type Value2 = { name: string };

//声明两个变量，分别使用第二、第三个类型
const value_1: Value1 = { name: "科技微讯" };
const value_2: Value2 = { name: "科技微讯" };

//声明一个变量，使用第一个 index interface
let test: Test;

//报错：Index signature for type 'string' is missing in type 'MyInterface'.
//即 Value1 缺少了 Test 的 [key: string]: string;
test = value_1;
//type alias 正常，即 Value2 不会被报错缺少 Test 的 [key: string]: string;
test = value_2;
```

之所以会这样，[是因为]：

> Just to fill people in, this behavior is currently by design. Because interfaces can be augmented by additional declarations but type aliases can't, it's "safer" (heavy quotes on that one) to infer an implicit index signature for type aliases than for interfaces. But we'll consider doing it for interfaces as well if that seems to make sense

上面这段话是 2017 年的，后续不断有开发者反映这个问题，但一直到 2022 年[作者表示]这一表现没有发生改变，以后也不会：

> This has not changed. 
> Changing the behavior at this point would honestly be an incredibly disruptive breaking change without much concrete upside. For clarity, I'm going to close and lock this - interfaces should declare an explicit index signature if they intend to be indexed.

简单点说，这是 typescript 的一个特性，之所以 interface 会报错而 type alias 不会，是因为 interface 可以多次声明，多次声明会合并成一个：

```typescript
interface MyInterface {
 name: string;
}
interface MyInterface {
 age: number;
}
const people: MyInterface = {
 name: "tom",
 age: 10,
};
```

因为可以多次声明，所以 interface 不应该自动 `infer an implicit index signature`，即如果一个 interface 没有 `[key: string]: string;`，typescript 不会自动给它 infer 一个。你想想，如果自动 infer 了会怎样？答案是会和后续多次声明冲突，例如：

```typescript
//假设 Tom 会被 infer an implicit index signature
interface Tom {
 name: string;
}
const tom: Tom = {
 name: "tom",
};
interface Test {
 [key: string]: string;
}

//那这里就会把 Test 的 [key: string]: string; infer 给 Tom
const test: Test = tom;

//相当于 Tom 变成了：
// interface Tom {
// name: string;
// [key: string]: string;
// }

//这样的话，当我们重复声明 Tom 时，就会报错，
//因为 age: number 和 [key: string]: string; 冲突
interface Tom {
 age: number;
}

//当然了，事实上重复用 interface 声明 Tom 并不会报错，
//因为 Tom 并不会被 infer [key: string]: string;
```

解决这个问题的方法有几种，回到刚开始的例子，既然报错是说 `Value1` 缺少 `Index signature`，那就给它加一个吧，如果现在还不确定其他 key 是什么类型，可以指定 index signature 为 any 或 unknown：

```typescript
interface Value1 {
 name: string;
 //增加：
 [key: string]: any;
 //或者：
 //[key: string]: unknown
}
```

另一种方法是改用 type alias 声明 `Value1`：

```typescript
type Value1 = {
 name: string;
};
```

因为 type alias 不能像 interface 那样可以重复声明，所以 type alias 会被 `infer an implicit index signature`：

```typescript
//当我们这样：
test = value_1;
//Value1 其实被 infer 成这样了：
type Value1 = {
 name: string;
 [key: string]: string;
};
//所以 Test 和 Value1 就不会冲突
```

写 typescript 的过程中我也遇到了 `Index signature is missing in type xxxx` 报错，不知道哪里出问题，直到我无意间把类型声明从 interface 改为 type alias，报错消失。

Typescript 报错 index signature is missing 的原因和解决方法


`Date.now()` 拿到的时间是基于设备时间计算出来的，如果两部手机设置的系统时间不一样，那在两部手机上分别执行 `Date.now()` 会拿到不一样的值。

有些用户会把手机的时间故意调快几分钟，所以我们在设计代码时，应该默认不信任 `Date.now()` 的值，尤其是后端需要和前端保持时间同步的情况。

一种解决方法是前后端均从同一个源头（Single source of truth）获取时间值，网上找到以下两个 API，淘宝的，可获取当前时间戳：

- [http://api.m.taobao.com/rest/api3.do?api=mtop.common.getTimestamp]
- [http://acs.m.taobao.com/gw/mtop.common.getTimestamp/]

国外也有这样的服务，但没那么快：

- [http://worldclockapi.com/api/json/utc/now]
- [https://currentmillis.com/time/minutes-since-unix-epoch.php]


`Date.now()` 拿到的时间是基于设备时间计算出来的，如果两部手机设置的系统时间不一样，那在两部手机上分别执行 `Date.now()` 会拿到不一样的值，一种解决方法是前后端均从同一个源头获取时间值，例如淘宝服务器的时间戳。