巨硬家编辑器`vscode`在打开大型项目时，无论启动速度还是补全速度都非常地拉胯，因此还是决定将主力编辑器切换为`neovim`，配置好后，搭配上`tmux`，在终端下的体验非常的丝滑。

这里我并没有从 0 开始进行配置，GitHub 上有很多不错的现成解决方案，这里我直接使用了[nvimdots](https://github.com/ayamir/nvimdots)方案。该方案使用[efm](https://github.com/mattn/efm-langserver)通用语言服务器作为格式化的解决方案，但是我觉得`efm`的配置还是太过零散，像`go`、`rust`都在自己官方内置的 LS 中自带了格式化工具，而`json`、`sh`等不自带的就需要交给`efm`来进行格式化，这样其实显得割裂，而操作起来还是比较繁琐，配置和修改都比较麻烦。

相比于`efm`, 这里我比较推荐的是[null-ls](https://github.com/jose-elias-alvarez/null-ls.nvim)，作为一个和`efm`功能相似的替代品，它支持更加统一的配置方案，无论是`go`、`rust`，还是`json`、`sh`等。它支持大部分主流语言的格式化方案，基本只需要进行很少的配置。所以，现在我的`neovim`格式化方案都统一交给`null-ls`来解决，不再考虑各种语言官方的 LS 是否自带格式化工具。此外，另一个比较吸引我的是，它可以轻松的配置多个格式化工具对文件进行链式格式化。对于`go`这种需要多个格式化工具的语言来说，在使用`null-ls`的方案下，可以轻松实现`gofumpt -> goimports -> golines`的链式格式化方案，不用手敲命令行，体验还是非常地不错。


使用null-ls来统一neovim的格式化方案

年末了，看见大家都在发年终总结，自己其实也想写一篇来着，但是下笔的时候实在是不知道如何描述今年所做的一些事情，感觉很多事情在没有结果的时候说出来就会变成笑话，也许2023年的时候会把今年所做的事情好好总结一下吧，今年是不太可能了。这篇无意义的文章就简单占个位置吧，至少代表2022我还活着。~~当然，也希望2023对我好一点吧~~

2022年终总结

[可扩展哈希](https://en.wikipedia.org/wiki/Extendible_hashing) 是一种动态散列方案，其中的目录和桶被用来散列数据。
对于静态哈希来说，可扩展哈希的优势在于，在扩容的时候，**不需要重新散列所有的数据，只需要重新散列一部分数据即可**。

> 静态哈希不等于不能扩容，只是扩容的时候需要重新散列所有的数据，并且需要重新寻找一个散列函数。

可扩展 hash 的大致架构如下图所示：

![可扩展hash架构](https://user-images.githubusercontent.com/55543743/205441868-9f312eae-0959-4905-8685-97cd0ffcff9c.png)

其中几个概念：

- 目录(direcotory)：用来存储桶指针的数组，其中目录的大小为 2^全局深度，全局深度初始为 1，每次扩容时，全局深度加 1，即目录大小翻倍。这里需要注意，目录中会有多个指针指向同一个桶。
- 桶(bucket)： 用来存储数据的数组，每个桶的大小**固定**，由参数进行指定，局部深度初始为 1，每次分裂时，该桶局部深度加 1。
- 全局深度(global depth)： 用来确定目录的大小，此外，全局深度还用来确定数据的散列地址。例如，全局深度为 1 时，数据的散列地址为 0 或 1，全局深度为 2 时，数据的散列地址为 00、01、10、11。
- 局部深度(local depth)：局部深度用来确定在桶溢出时候进行的操作：当局部深度小于全局深度时，进行桶的分裂，且桶的局部深度加 1；当局部深度等于全局深度时，进行目录的扩容和桶的分裂，且全局深度和局部深度都加 1。指向当前桶的指针的个数等于 2^(全局深度 - 局部深度)。
- 桶分裂：当桶溢出时，将桶中的数据重新散列到旧的桶和新的桶中。例如桶 A 已满，且 A 的局部深度为 1，溢出时，创建桶 A\*，局部深度为 2，且将桶 A 的深度也改为 2。~~然后将桶 A 中的数据重新散列到桶 A 和桶 A\*中~~。 这里更好的说法是，将桶 A 的数据进行重新散列。且散列的数据只会落在桶 A 和桶 A\*中，而不会落在其他桶中。
- 目录扩容：当全局深度增加时候，需要对目录进行扩容，即将目录的大小翻倍。且将新增加的目录的桶指针指向合适的桶。例如，当全局深度从 1 增加到 2 时，需要将目录的大小从 2 增加到 4，且将目录的第 2 个和第 3 个指针指向对应的桶 0 和桶 1。对应关系为: **遍历前一半目录索引，将其最高位从 0 变为 1 即可。公式为 dir[reverse_the_highest_bit(index)] = dir[index]**

## 流程

流程如下所示：

![流程](https://user-images.githubusercontent.com/55543743/205441887-ca3ff3e3-4348-4503-8c8f-0b72a1ca45b1.png)

找到对应的桶之后，可以进行查找/删除/增加等操作。

举个例子：

此时的状态为：全局深度 1，局部深度 1，key 为"qianxi", hash(key) = 114514。

按照流程，先对 key = qianxi 应用 hash 函数，得到 114514。然后，寻找对应的目录索引 dir_index = (114514 & ((1 << 全局深度) - 1)) = 0，得到索引 0，在按照目录中所存放的桶指针找到的目录项 0 所指向的桶，随后进行对应的操作。

## 举个栗子

查找和删除操作这里都不讲，着重讲讲插入操作。

预设：桶的大小为 2，hash(key) = key，待插入的 key 为 1-8。

首先的初始情况为：

![初始情况](https://user-images.githubusercontent.com/55543743/205441902-83c6e4ed-bda9-49f8-8d21-e9f805f0be79.png)

1. 插入 1，hash(1) = 1，dir_index = 1 & 1 = 1，所以插入到桶 1 中。
2. 插入 2，hash(2) = 10，dir_index = 10 & 1 = 0，所以插入到桶 0 中。
3. 插入 3，hash(3) = 11，dir_index = 11 & 1 = 1，所以插入到桶 1 中。
4. 插入 4，hash(4) = 100，dir_index = 100 & 1 = 0，所以插入到桶 0 中。

此时，桶 0 和桶 1 都已满，状态如下：

![阶段1](https://user-images.githubusercontent.com/55543743/205441908-11412e98-315c-47ba-8566-7ada36f13b06.png)

5. 插入 5，hash(5) = 101，dir_index = 101 & 1 = 1，所以插入到桶 1 中。

问题来了，桶 1 已经满了（桶的大小固定且在这里设定为 2），而且此时桶 1 的局部深度为 1，全局深度也为 1，这就代表着，没有多余的指针指向桶 1，所以你需要首先对目录进行扩容，扩容后的目录如下：

![第一次扩容](https://user-images.githubusercontent.com/55543743/205441912-fa3b0bab-2833-4c82-87c3-b4ebb88ed263.png)

注意到，此时的全局深度增加 1 之后为 2，而且，扩容增加之后的目录指向了桶 0 和桶 1。且此时，全局深度为 2，局部深度为 1，key 为 5，hash(key) = 5， 插入到桶 1 中。

扩容之后，桶 1 的局部深度 1 小于全局深度 2，这就意味着，有不止一个指针指向桶 1，所以，你仅仅需要对桶 1 进行分裂。首先，需要找到另一个指向桶 1 的目录项，这里就是目录项 3，将其指向一个新的空桶，然后，对目录项 1 所指向的桶进行分裂（别忘了加上新增的元素 5），即对 1、3、5 这些元素重新进行哈希：

- 插入 1，hash(1) = 1, dir_index = 1 & 11 = 1,所以插入到桶 01 中。
- 插入 3，hash(3) = 11, dir_index = 11 & 11 = 11 ，所以插入到桶 11 中。
- 插入 5，hash(5) = 101, dir_index = 101 & 11 = 01 ，所以插入到桶 01 中。

这样，就完成了桶的分裂，且没有桶溢出。

> 但是还个问题是？如何找到桶 1 的对分裂项桶 3 呢？假设桶 1 对应的分裂桶为桶 1\*。
> 思路是，此时桶 1 的本地深度为 1，设桶 1 的索引号为 index，则桶 1\*的目录索引号 index\* = (1 << local_depth) | index，代入数据可以得到 index\* = (1 << 1) | 1 = 3 = 11，所以桶 1\* 对应的目录项为 3(11)。

分裂之后的状态如下：

![分裂之后的状态](https://user-images.githubusercontent.com/55543743/205441932-3653da0b-bb6e-4a95-afcc-5152178da704.png)

别忘了对新的桶和分裂的桶进行局部深度的更新。

6. 插入 6，hash(6) = 110，dir_index = 110 & 11 = 10，所以插入到桶 10 中。

注意，此时，桶 10 的局部深度为 1，全局深度为 2，所以，此时只需要进行桶分裂，不需要对目录进行扩容。

所以步骤如上，对 2、4、6 进行重新哈希：

- 插入 2，hash(2) = 10，dir_index = 10 & 11 = 10，所以插入到桶 10 中。
- 插入 4，hash(4) = 100，dir_index = 100 & 11 = 00，所以插入到桶 00 中。
- 插入 6，hash(6) = 110，dir_index = 110 & 11 = 10，所以插入到桶 10 中。

插入完成，且更新对应的局部深度之后的状态如下：

![第二次分裂](https://user-images.githubusercontent.com/55543743/205441945-e06f4304-243a-4fff-a2be-a5cb35cbdd73.png)

7. 插入 7，hash(7) = 111，dir_index = 111 & 11 = 11，所以插入到桶 11 中。
8. 插入 8，hash(8) = 1000，dir_index = 1000 & 11 = 00，所以插入到桶 00 中。

全部插入完成之后的状态如下：

![全部插入完成之后的状态](https://user-images.githubusercontent.com/55543743/205441950-78907d24-8301-4489-9031-3d153479a007.png)

## 总结

所以，动态哈希的插入过程可以总结为：

1. 计算哈希值，得到目录项的索引号，从而找到对应的桶。
2. 如果目标桶可以直接插入，则直接插入。
3. 如果不能直接插入，如果此时桶的局部深度等于全局深度则进行4，否则 5。
4. 对目录进行扩容，然后将新增的目录项的桶指针指向对应的桶。
5. 对目标桶进行分裂，将该桶中的所有数据和代插入的新数据进行重新哈希，然后插入到对应的桶中。
6. 如果全部重新哈希之后插入成功，则完成插入，否则重复 2-5。

可扩展哈希

最近在使用 docker 的时候，即便是配置了国内的镜像，也还是慢的可怕。
而且国内的镜像源并不能实时同步镜像的最新版本，所以还是选择了国外的源 + 代理的方式。

## pull-time proxy

拉取镜像的时候，是使用`dockerd`守护进程。因此代理需要配置在`dockerd`环境，而这个环境是`systemd`负责，因此实际上是配置`systemd`代理。

```bash
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo touch /etc/systemd/system/docker.service.d/proxy.conf
```

添加下面的内容到`proxy.conf`文件中：

```txt
[Service]
Environment="HTTP_PROXY=http://ip:port/"
Environment="HTTPS_PROXY=http://ip:port/"
Environment="NO_PROXY=localhost,127.0.0.1"
```

> 这里的 ip 是你的代理 ip 一般是 localhost，port 则是你代理转发的端口。

## run-time proxy

运行容器的时候，如果你需要在容器内使用代理，则需要配置容器的代理。

这里有三种配置方法：

1. 容器运行时指定

```bash
docker run -e HTTP_PROXY=http://ip:port/ -e HTTPS_PROXY=http://ip:port/ -e NO_PROXY=localhost ...
```

这种方式的优点就是直接，但缺点就是每次启动容器都需要显示的设置。
为了解决这种情况，在 Docker 17.07 以上，可以使用配置 Docker 客户端的方式，即 2。

2. 客户端全局配置

在`~/.docker/config.json`中，加入以下内容：

```json
{
  "proxies": {
    "default": {
      "httpProxy": "http://ip:port",
      "httpsProxy": "http://ip:port",
      "noProxy": "localhost,127.0.0.0/8"
    }
  }
}
```

3. host 网络模式

如果你的容器使用的是 host 网络模式，那么容器内的网络就是宿主机的网络，因此可以直接使用宿主机的代理。

```bash
docker run --network host ...
```

> 上面的 ip 是 docker0 网卡的 ip，而不是容器内部的 ip。使用 ip addr show docker0 查看。

## build-time proxy

容器构建的时候，本质上也是启动了一个容器。

这里没找到配置文件的方法，只能使用环境变量的方式，但是参数略有不同。

```bash
docker build \
    --build-arg "HTTP_PROXY=http://ip:port/" \
    --build-arg "HTTPS_PROXY=http://ip:port/" \
    --build-arg "NO_PROXY=localhost,127.0.0.1" \
    ...
```

同样的，这里的 ip 也是`docker0`网卡的 ip。

> 构建过程中，更推荐使用 host 网络模式，因为这样可以直接使用宿主机的代理。

## 重启生效

~~重启计算机即可~~

`build-time` 代理是在执行前设置的，所以修改后，下次执行立即生效。`run-time` 代理的修改也是立即生效的，但是只针对以后启动的容器，对已经启动的容器无效。

`pull-time`代理的修改比较特殊，它实际上是改`systemd`的配置，因此需要重载`systemd`并重启`dockerd`才能生效。

```bash
sudo systemctl daemon-reload
sudo systemctl restart docker
```


docker-proxy

俗话说，工欲善其事，必先利其器。~~差生文具多罢了！~~

推荐一些能够提升效率的终端工具：

[yay](https://github.com/Jguer/yay): 又一个 aur helper，为什么不推荐`paru`，因为`yay`看起来更开心一些。

[zsh](https://github.com/zsh-users/zsh): 比`bash`更强的 shell。

[oh-my-zsh](https://github.com/ohmyzsh/ohmyzsh): 一个`zsh`的框架，自带许多插件和主题。

[starship](https://github.com/starship/starship): `zsh`的主题，但是更好看，而且更快。

[kitty](https://github.com/kovidgoyal/kitty): 一个 GPU 加速的终端，虽然的 python 写的，不用`alacritty`是因为它不支持连写。

[FiraCode](https://github.com/tonsky/FiraCode): 一个带连写的编程字体。

[git](https://git-scm.com/): 版本管理。

[hub](https://github.com/github/hub): 一个更好的`git`增强工具。

[cli](https://github.com/cli/cli): GitHub 官方的命令行工具，可以省去一些图形化操作。和`hub`有些功能重合。

[lazygit](https://github.com/jesseduffield/lazygit): 终端的`git`命令 UI。

[lazydocker](https://github.com/jesseduffield/lazydocker): 终端的`docker`命令 UI。

[degit](https://github.com/Rich-Harris/degit): 简单的`git`项目脚手架，能够清除仓库的提交历史。

[difftastic](https://github.com/Wilfred/difftastic): `git diff`命令的增强。

[ni](https://github.com/antfu/ni): 包管理工具卷上天，`ni`大一统。

[pnpm](https://github.com/pnpm/pnpm) : 更快、更快、还是他妈的更快。

[npm-check-updates](https://github.com/raineorshine/npm-check-updates): `package.json`的依赖更新工具。

[zoxide](https://github.com/ajeetdsouza/zoxide): `autojump`，但是是用`rust`写的。

[ranger](https://github.com/ranger/ranger): 一个终端的文件管理器。

[fzf](https://github.com/junegunn/fzf): 模糊查询。

[fzf-tab](https://github.com/Aloxaf/fzf-tab): 用 fzf 替换 zsh 的默认补全选择菜单。

[mcfly](https://github.com/cantino/mcfly): 更加友善的`zsh`历史命令搜索提示。

[neovim](https://github.com/neovim/neovim): `vim` fork 出来的终端编辑器，但是更 **powerful**。

[gvm](https://github.com/moovweb/gvm): `go` 多版本管理工具。

[fnm](https://github.com/Schniz/fnm): `node`多版本管理工具。

[tmux](https://github.com/tmux/tmux): 让你的`session`和终端分离。

[htop](https://github.com/hishamhm/htop): 更好的`top`命令。

[exa](https://github.com/ogham/exa): 更好的`ls`命令。

[duf](https://github.com/muesli/duf): 更好的`df`命令。

[ncdu](https://github.com/rofl0r/ncdu): 更好的`du`命令。

[tldr](https://github.com/tldr-pages/tldr): 太长不看。

[bottom](https://github.com/ClementTsang/bottom): 系统的各种运行时参数查看。

[neofetch](https://github.com/dylanaraps/neofetch): 系统参数查看。

[scc](https://github.com/boyter/scc): 项目代码行数查看。

[httpie](https://github.com/httpie/httpie): 或许是更好的`curl`？

[ripgrep](https://github.com/BurntSushi/ripgrep): 安息吧，`grep`。更好的正则查询过滤。

[golines](https://github.com/segmentio/golines): 限制你的`go`代码单行最大长度。

[gofumpt](https://github.com/mvdan/gofumpt): 更好的`gofmt`，完全和前者兼容。

[golangci-lint](https://github.com/golangci/golangci-lint): `go`的 lint 工具。

[eslint](https://eslint.org): 让你的`js`代码更加规范。

[vite](https://vitejs.dev/): f\*\*k `webpack`。

[tig](https://github.com/jonas/tig): 更好的`git log`查看器。

[gping](https://github.com/orf/gping): 带有可视化界面的`ping`。

[bat](https://github.com/sharkdp/bat): 更好的`cat`。

[act](https://github.com/nektos/act): 在本地运行你的GitHub Action。

[procs](https://github.com/dalance/procs): 更好的`ps`。

[sd](https://github.com/chmln/sd): 直观的查找和替换 CLI，更好的`sed`。
