一些关于前端、技术，和我的生活的文字

前端

技术

生活

关于我

进入NetlifyCMS

Spark1e的Github

前往Twitter

给spark1e发邮件

在博客中搜索……

windows10 UEFI引导修复

### nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument

已解决。遇到此问题是使用DigitalOcean的Ubuntu 18.04 Droplet,检查nginx运行状态 `service nginx status` 输出标题的错误, 参考[StackOverflow](https://stackoverflow.com/questions/42078674/nginx-service-failed-to-read-pid-from-file-run-nginx-pid-invalid-argument)解决，步骤(以下均使用root账户)：

- `mkdir /etc/systemd/system/nginx.service.d`
- `printf "[Service]\nExecStartPost=/bin/sleep 0.1\n" > /etc/systemd/system/nginx.service.d/override.conf`
- `systemctl daemon-reload`
- `systemctl restart nginx`

Nginx故障排除

> 跨域,一个说腻了的话题,今天遇到一个新的情况,单独拎出来说说;

## 情景再现

b.site有一个ajax请求a.site的某一个地址,post请求+自定义header(假设,header头为`X-Application-Token`),ok,妥妥的跨域,那么自然加上以下代码(以express.js为例):

```javascript
app.options('*', (req, res, next) => {
    res.header("Access-Control-Allow-Origin", "*")
    res.header("Access-Control-Allow-Headers", "X-Application-Token")
    // call the path service
})
app.post('/a-cors-request-path', (req, res) => {
    res.header("Access-Control-Allow-Origin", "*")
    res.header("Access-Control-Allow-Headers", "X-Application-Token")
    // call the path service
})
```

反复确认了相关配置已经设置好,但浏览器仍报错:

> Access to XMLHttpRequest at 'a.site' from origin 'b.site' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

## 排查

1. 返回说"not have HTTP ok status"

那么说明option请求没有返回200,打开postman发送请求尝试看看,成功返回...

1. 自己启动一个Express Server,尝试复现

已经能够确认,option不通过和状态码有关,那么为什么浏览器内非200,而postman发送option请求正常返回200 ?

打印headers,一口老血...

![cors-with-verify-header](https://cdn.arc-light.fun/BeGtIi/cors-with-verify-header.png)

## 结论

除了常见的跨域问题,也要考虑实现时的业务逻辑,比如本情境下,错误的在option中也调用相关服务验证了`X-Application-Token`,而option请求在浏览器内是不会携带额外的header信息的,这才导致了浏览器内 _not HTTP ok status_,而postman正常的原因.

## 额外

后来利用老的Microsoft Edge浏览器(Edge legacy)调试,发现会清楚的返回400 Bad Request,所以如果option请求能够返回精确的HTTP code,也会更利于开发人员排查问题,后续修改后完美解决.

跨域这个问题还得单独揪出来说一下

## 现象

```bash
sed: -e expression #1, char 24: unknown command: `.'
```

切换用户时（此用户是原来WSL2的默认账户），shell报以上错误。

考虑到是切换用户才导致的，因此怀疑`.zshrc (or .bashrc)`内有命令错误

## 移除未使用的命令

使用debug模式，尝试读取并执行.zshrc

> 如果不能确定当前.zshrc配置，请清理后再执行source！

```bash
source ~/.zshrc -x
```

果然，发现了新的错误：

```bash
compinit:501: no such file or directory: /usr/share/zsh/vendor-completions/_docker
```

这是由于复制时WSL2和WSL1在处理docker的方案上不同，导致自动补全的链接出现问题，移除WSL1容器内的docker自动补全

```bash
cd /usr/share/zsh/vendor-completions
# remove your deprecated auto-completions
```

再执行source，问题解决！

解决切换用户提示的sed报错

## 依然先说结论

UWP应用是一类特殊的应用，Windows会限制其在使用代理时使用127.0.0.1的回环地址，因此需要使用第三方工具开启回环代理或者修改注册表，考虑到修改注册表危险性较高且不便于操作，这里转载来自[Qv2ray](https://qv2ray.net/getting-started/step4.html#%E4%BD%BF%E7%94%A8%E7%B3%BB%E7%BB%9F%E4%BB%A3%E7%90%86)的解决方案。

## EnableLoopback

这是一个来自Fiddler的项目，用来调试UWP应用，也可以为我们简单的开启本地代理。

> Qv2ray给出的下载地址：[链接](https://qv2ray.net/EnableLoopback.zip)
> 上传到本站的地址：[链接](https://cdn.arc-light.fun/E2itoL/EnableLoopback.exe)

打开后在左侧的应用名称找到Microsoft Todo（或者其他的UWP应用名），勾选并点击"Save Changes"，即可开启127.0.0.1的本地代理权限。

![使用工具打开UWP的proxy](https://cdn.arc-light.fun/PSvgEE/enable-uwp-proxy.png)

有关于UWP应用联网的问题

## 如果你还没有被自动更新

你可以选择Fast Cycle或者使用Beta版尝鲜新Edge，这样的Edge版本不需要进行额外的操作，即可与旧版本兼容并存。

## 如果你已经通过Windows Update自动更新

那么就需要通过注册表修改使其并存。

首先找到注册表的这个位置：

`HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft`

在左侧的`Microsoft`项右键，选择“新建” > “项”，命名为EdgeUpdate。

在右侧窗口，右键，新建DWORD（32位）值，命名为`Allowsxs`，双击修改值为1（保持16进制不变）。

最终成果如图：![注册表最终修改](https://cdn.arc-light.fun/DD5JPL/dual-edge-reg.png)

## 如果操作完成后开始菜单仍找不到“Microsoft Edge 旧版”

在“设置” > “应用和功能”找到新版Edge，点击修改，（如果有卸载可以尝试卸载），再重新安装即可双版本共存。

![双版本共存](https://cdn.arc-light.fun/S3ReV0/dual-edge-final.png)

配置MS Edge双版本并行

> 如果英文能力还可以的同学可以直接移步 [官网文档](https://forestry.io/docs/welcome/)

## 原来的写博客方式

现在比较多的写博客模式是利用Github仓库，连接Github Page或者一些第三方服务如Netlify, Vercel(Now.sh)来进行部署，写好文章提交后的流程已经基本自动，而且大部分平台的服务都是免费的。

> 博主之前使用Vercel部署时，需要注意免费计划 **每个小时不能超过30次构建部署** 。

然而写博客主要是内容，那么书写平台就是一大问题，我们虽然可以用本地IDE（亦或是Code Server/VSCode Remote）这一类工具进行编写，但是未免仍不够轻量，如果是iPad这一类移动设备更是不方便，因而，我发现了这个基于Git的第三方编辑平台—— [Forestry.io](https://forestry.io)

## 快速上手

Forestry.io支持四种Git来源：Github, Gitlab, Bitbucket, Azure Devops。

一般作为博客我们使用Github，继续后会进入到Github的授权界面，授权即可。

> 默认的授权是读取Public库，如果你需要也可以在CMS左侧的Settings中选择授权Private仓库。

> 如果是Bitbucket和Azure Devops，可能需要更复杂的设置，我没有使用过，可以参考官方文档。

授权完成后，可以进入Dashboard，选择Add Site。

本篇以一个GatsbyJS的模板项目为例子，Hexo，Hugo，Jekyll官网上都有相关的例子可以参考。如果你是Hexo，请选择Other类别。然后点击Next。

![选择静态生成框架](https://cdn.arc-light.fun/ACvJrn/forestry-step1.png)

进入到“Select your git provider”界面，和原来一样，选择你的Git来源，这里我选择Github。

第三步就来到了仓库选择，直接选择你想要操作的仓库与分支，如果你不想让Forestry提交commit到master，请在此选择一个编辑分支。

![选择仓库与分支](https://cdn.arc-light.fun/px985W/forestry-step3.png)

导入完成，进入到CMS的主界面。

![CMS主界面](https://cdn.arc-light.fun/mrnxZc/forestry-step4.png)

## 简单设置

如同上面的CMS显示，我们只要将剩下三步配置完成即可。

### Set up sidebar

侧边栏是一些快捷入口，这里你可以配置三类：

![侧边栏配置](https://cdn.arc-light.fun/DzKWqf/forestry-setting1.png)

* 目录: 顾名思义，目录可以用作分类等场合，对应的，所有在分类下创建的文档都会进入到对应的目录下；
* 文档: 直接编辑某一篇文档，适合作为介绍页或者文档页的快捷入口；
* Heading: Heading是一个 **没有内容** 的侧边栏选项，适合作为分割线等等，来定制你的侧边栏；

这里添加一个Section，可以看到可以配置很多项，一般默认即可，如果不希望分类下额外存在目录，可以将创建内容改为Documents

![创建侧边栏](https://cdn.arc-light.fun/KEXWaw/forestry-setting2.png)

这里我们先不配置默认模板，先保存。

### Import Media

重头戏来了，之所以选择一个CMS，最重要的就是我们很多时候有上传图片的需求，但是无论是Git手动提交还是第三方工具上传，都费时费力，还需要手工粘贴图片的绝对地址。

而有了CMS，这一切都简化了。

![](https://cdn.arc-light.fun/ks36HG/forestry-setting3.png "配置媒体文件")

如图所示，可以支持四种图片管理方式，最普通的Git提交，第三方支持了Cloudinary和Amazon S3以及Netlify Large Media。

> Cloudinary可以免费试用，它是一个积分制的服务，如果你的博客流量较小，那么它的免费量其实足以；
>
> Amazon S3这里特别提一下，目前有很多VPS厂家会提供Object Storage，他们会提供类似S3的管理方式，但是咨询了Forestry.io的技术支持后，明确表示了 **目前支持的S3仅有Amazon，即你暂时无法通过配置其他域名来实现其他S3的配置** 。

如果配置顺利，在“可视化编辑器”内，你就可以点击这里实现上传直接插入文档中：

![](https://cdn.arc-light.fun/JatvkA/forestry-setting4.png "添加图片")

点击open后，会跳转到你的媒体库，上传即自动插入到文章中。

## 配置预览

Forestry.io支持在发布前进行预览，需要配置预览的相关命令，环境以Node.js为主，也可以进行自定义，本章内容建议详细参阅官方文档的 [配置页面](https://forestry.io/docs/previews/instant-previews/)

## 设置文章模板

这一章也是非常重要的，我们在前面的Section里可以设置默认模板，这就是为了方便统一类别下的文章格式一致(Front matter)，点击左侧的Front matter进入配置界面。

点击添加模板后，可以全新创建，也可以从已有的文章自动分析。

> 我自己使用时发现，文本编辑的识别率较好，如果是类似标签选择的则会识别错误，建议先导入，然后添加一篇新文章进行测试。

一般对于Markdown的博客写作，我们选择左侧的“Fields and big content area”。

![](https://cdn.arc-light.fun/Z721sM/forestry-setting5.png)

Forestry.io提供了一些Field选项，对于博客写作，它们可以与你的Front matter一一对应，通过交互实现配置Front matter，进而与你的博客主题（如Banner图，文章简介等等）比较好的对应，具体使用可以自己体验一下。

使用forestry.io管理你的博客

## 开篇先说结论

结论是：AX200在连接RM2100(Padavan)的5G 160Mhz无线信号时，出现跳ping（波动至250+）。

解决方案：设置RM2100的5G WiFi以20/40/80Mhz使用，目前跳ping得到缓解。

更新：使用了恩山的“啊Dee”的Padavan固件，稳定使用160Mhz，给一个[论坛链接](https://www.right.com.cn/forum/thread-4033492-1-1.html) 如果后续遇到新的问题会在本文中更新。

## 我的网络搭配

红米 AC2100主路由，刷入[C大的Padavan固件](https://github.com/chongshengB/rt-n56u/releases)，不开启任何插件的情况下，打开5G的20/40/80/160Mhz自动协商 ；

主机由于一居室的距离问题，因而加装了一个无线网卡（COMFAST AX200），测速和日常直播没有感受到速度问题，偶尔出现无法打开页面的情况，考虑到AC2100的CPU比较差，关闭了SmartDNS等插件。

而后，平时页面打开出现无法打开情况减少，但跳ping情况依然明显，在游戏(Insurgancy第三方服务器)内ping会几分钟内突然飙升至250左右，网页同时也速度极慢。

更新固件，修改信道等等方案都尝试后，决定降级到20/40/80Mhz自动协商，跳ping状况基本解决，不更改AX200配置的情况下，稳定在80Mhz传输。

## 后续更新驱动

希望后续能有稳定的AX200驱动能够支持ac模式下的160Mhz。不过目前来看各大第三方都不够稳定，个人使用C大的0604版还可以接受，地址上方自取。

目前来说，AC2100适合折腾人士，如果作为家里主路由的还不够稳定,刷入第三方后又不容易支持加速器等。

红米RM2100+AX200诡异跳ping问题

## Sentry是什么？

### 2021-05 更新

经过自己的反复部署，多VPS部署……仍认为9.2是最适合个人项目使用的版本，虽然已经不能和Github正常联动，但是整体资源和部署难度都比较低，而且也不会遇见大量的严重Bug。

## ==== 分割线 ====

> Sentry helps all software teams create the best software, faster.

Sentry是一个SaaS服务，提供了多种语言、多种环境的错误收集提示等自动化处理功能。

它的优势主要有以下几点：

* 接入简单，node & flutter都是在主入口几行搞定;
* 支持平台和语言极广，几乎涵盖了市面上常见的语言和框架，能够为整个开发团队提供错误收集能力;
* 支持扩展，能够快速扩展到Gitlab、Github、Trello、Slack等平台，国内也有非常好的支持，飞书等平台也有对应的助手或Bot能够方便的扩展到日常开发上;
* 支持私有部署（虽然有坑……），这一点是最为重要的，能够让小团队快速利用Docker和官方命令进行部署，极快地为开发赋能。

SaaS版本我也曾使用过，但是如果没有配置好或者网络环境一般，可能会付出比较高的成本（定时器未清除导致的报错会瞬间烧光你的免费额度……），因此强烈推荐私有部署，相关教程也比较丰富。

> getsentry: [Github](https://github.com/getsentry/onpremise)

> 飞书官方的Sentry助手，[文档](https://getfeishu.cn/hc/zh-cn/articles/360041217373-%E6%9C%BA%E5%99%A8%E4%BA%BA-%E5%A6%82%E4%BD%95%E5%9C%A8%E9%A3%9E%E4%B9%A6%E4%B8%AD%E9%85%8D%E7%BD%AE-Sentry-%E5%8A%A9%E6%89%8B-)，如果其他平台没有原生支持也可以使用Webhook等方式“曲线救国”。

## 简单说说私有部署

其实按照官方的仓库指导，很容易能够部署，只需要一些docker的基础知识并且能够利用docker-compose工具就可以运行起来，但是有很多细节比如Nginx反代Sentry，以及邮箱配置等还是需要对其他相关的东西有一些了解。

### 配置

官方推荐的配置为2400MB内存起步，但是可以通过修改[install.sh](https://github.com/getsentry/onpremise/blob/master/install.sh)，调整最低内存，可以完成安装，但是不保证运行效率，如果较大量的请求可能会导致内存100%。

    MIN_RAM=2400 # MB

### 一些运行设置

以邮件配置举例，目前版本(onpremise, Sentry 10.1.0.dev09b99a3b)如果希望配置生效首先需要找到sentry目录下的config.yml文件（如果没有说明是全新安装，可以从config.example.yml复制一份进行修改），利用环境变量先配置对应的参数。

更新配置后，执行以下命令：

```bash
# docker-compose.yml 目录下
docker-compose stop
docker-compose run --rm web upgrade
docker-compose up -d
```

如果相关程序启动成功，则可以到系统管理界面查看是否应用配置，并发送测试邮件。

### 更新版本

随着一些API的变更，官方会更新相应的版本，私有部署的可以通过执行以下命令来进行升级。

```bash
# 避免onpremise版本安装脚本问题，建议手工拉取最新镜像tag，同时将onpremise仓库升级到对应tag
# docker pull getsentry/sentry:xx.xx.xx && git checkout xx.xx.xx
docker-compose build && docker-compose run --rm web upgrade && docker-compose up -d
```

> 目前已知Github集成存在API被废弃，相关[链接](https://developer.github.com/changes/2020-04-15-replacing-create-installation-access-token-endpoint/) ，目前onpremise 10.0.0版本存在此问题，10.0.1未确认，官方修正于20.7.0，鉴于私有部署版本更新过于激进，暂时不进行升级等待10版本后续更新。

## 坑

私有部署依赖于Sentry和它的很多镜像，以及一些第三方镜像。由于Sentry 20的自建版本仍在 __非常积极地__ 开发迭代中，强烈推荐使用docker的原始源进行安装，成功率较高，如果使用镜像，可能存在Bug导致无法安装，需要注意。

强烈建议将postgres数据和sentry-data挂载到机器目录上，可以较好的保存持久化的信息。

## Sentry依赖的一堆容器，究竟做了什么？

这里强烈推荐看[官方开发博客](https://blog.sentry.io/)了解每一个组件背后的由来。


Sentry——一站式错误监控平台部署记录

## 直播内容

> 直播使用的PPT[Google文档地址, 需要科学上网](https://docs.google.com/presentation/d/1LHp-8hEtXEMSE1fd6YLAhYmtndQelQKbWlGggZKe4y8/edit#slide=id.g31e95ee831_0_92)

- 3.0 Beta特性介绍
	- 性能表现
    - “摇树”支持
    - Composition API
    - Fragment, Teleport, Suspense
    - 更好的TypeScript支持
    - 自定义Render
- 何时才能使用Vue 3.0（生态进度）
    
## 性能表现

### 重写V-dom实现

> 本节内容结合 [_vue-next-template-explorer.netlify.app_](https://vue-next-template-explorer.netlify.app/) 食用更佳。

2.0版本的的v-dom实现参考了[snabbdom](https://github.com/snabbdom/snabbdom)，加入了一部分Vue相关的特性属性如Static标记等。3.0大幅度修改了其实现，并对标记等进行了优化。

### Compiler-informed fast paths（个人理解：更快的编译/render路径）

> 本节内容结合 [_vue-next-template-explorer.netlify.app_](https://vue-next-template-explorer.netlify.app/) 食用更佳。

这一部分主要体现在最终的render函数上，利用上述工具，我们发现静态节点标记以及属性（绑定）被归为不同的部分，其中静态节点甚至可以通过开启提升来进行复用，未绑定的属性与进行了绑定的也可以直接标记出来，减少了对比与diff压力，从而得到更快的速度。

### 更高效的组件初始化

### 更新性能提高1.3～2倍

> 参考（下同）：based on benchmarks that simulates typical scenarios, may vary based on actual application.

### 2～3倍更快的SSR（服务端渲染）

SSR下，可以将静态节点作为Buffer的一部分直接推入最终的请求返回中，从而获得更快的速度。

## “摇树”Tree-shaking

> 本节内容结合 [_vue-next-template-explorer.netlify.app_](https://vue-next-template-explorer.netlify.app/) 食用更佳。

### 大部分可选特性目前可被“摇树”

在“next-template-explorer”中，如果你使用了例如v-on或者v-model等选项，可以在右侧清楚的发现对应选项通过摇树的方式单独打包进入最终的代码，相比于2.x版本需要包含完整runtime而言是非常大的优化。

### 最基本的HelloWorld示例打包大小约为13.5kb

> 如果选择只包含Composition API支持的模式，打包体积可以减小至11.75kb。

### 包含所有Runtime的打包体积约为22.5kb

## Fragment, Teleport, Suspense

### Fragment

碎片的概念有些类似于[React的Fragment概念](https://zh-hans.reactjs.org/docs/fragments.html)，Vue 3版本支持更多的使用方式，比如可以只有字符串，或者利用数组构成一段Fragment。

### Teleport(有译为：占位传递组件）

Teleport与[React的Portals概念](https://zh-hans.reactjs.org/docs/portals.html)类似。

> Portal 提供了一种将子节点渲染到存在于父组件以外的 DOM 节点的优秀的方案。

> 尤大在直播中提到，为何没有直接使用Portal来命名还有另外一个原因：Chrome的iframe“替代方案”——[Portal](https://www.chromestatus.com/feature/4828882419056640)

Teleport功能可以用来将部分组件代码传递到DOM树的其他位置，可以在很多场景下使用，比如窗口resize等，简单说明：

```javascript

<NestedComponent>
  <v-fragment target="#popup-target">
    <PopUp />
  </v-fragment>
</NestedComponent>

<div id="popup-target"></div>
```

### Suspense

同样的，其对应了[React的Suspense概念](https://zh-hans.reactjs.org/docs/concurrent-mode-suspense.html)，要注意的是，__当前Suspense特性在React中同样也是试验性功能，暂时不适合投入生产环境__ 。

React社区中有一些第三方库对其进行了实现，比如zeit.co推出的[swr库](https://github.com/zeit/swr)，主要是用于作为等待与实现异步，Suspense部分会进行等待，直到异步任务完成继续，非常适合用来实现loading态。

## 何时才能使用Vue 3.0（生态进度）

> 建议随时参考官方的[Vue-next仓库](https://github.com/vuejs/vue-next)，了解生态各部分的开发进展。

目前Vue 3.0已经进入了Beta版本，预计年中会推出可以投入生产的版本。

- Vue Router：已知会 __有部分API改动__ ，目前alpha阶段；
- Vuex：目前已知没有API改动，同样处于alpha阶段；
- Vetur：其作者预计在五月份会进行跟进开发工作；
- Nuxt：目前已经实现了demo版本，正在跟进中；
- vue-cli：目前实验性支持；

需要注意的是，Vue 3.0 __beta目前不支持IE11__，在未来会推出针对IE11的专用build，如果需要兼容则需要开启对应的开关，会在最终打包时加入部分的fallback策略。

## 2.x版本的未来

2.x版本会在3.0稳定后推出一个Minor版本，之后会进入为期18个月的LTS，LTS过后只进行安全修复不会做版本更新。这个版本会包括部分2.x版本可兼容的3.0新特性。

Spark1e

Category: all