卡瓦邦噶！ | 无法自制的人得不到自由。

Vim LSP 配置

Posted on 2019年11月4日 by laixintao 10 Comments

用了好几年的 YouCompleteMe，体验还是不错的，最爽的一点是能基于 Token 补全在当前 buffer 中作补全，任何语言用 Vim 就有一个“基本可用”的体验，即使写 git commit message 的时候也很好用。

但是最近玩一些神奇的东西，YouCompleteMe 如果没有支持这种语言的话，就没办法做到一个比较好的体验了。

对于一种语言，YouCompleteMe 都要去实现这种语言的支持，才能起作用。每增加一种语言，YouCompleteMe 都要增加一种工作量。不光 YouCompleteMe，像 Emacs，VS Code，都要去实现每一个语言的自动补全。这就形成了很大的浪费：每一种编辑器要去自己实现每一种语言。如果有人写了一个新的语言想要其他编辑器支持，需要一个一个实现编辑器的补全工具。

这就形成了一种交叉关系，假如有三个语言，三个编辑器存在，就需要9个补全的实现。

所以 VS Code 就提出了 “Language Server” （简称 LSP）这种先进的概念。这是一种 Client-Server 架构，每个语言实现自己的 Language Server，每个编辑器去实现自己对接 Language Server 的前端。这样一个语言只需要实现一次，就可以支持所有的编辑器。上面那种情况，只要有3个语言的补全实现+3个编辑器自己的 Language Server 实现就可以了。

其实 YouCompleteMe 也支持 LSP 的，但是配置上看起来资料比较少，像是不是支持的特别好，所以我索性放弃 YCM 了，转向了 vim-lsp。

配置 vim-lsp

这里以 Python 为例，介绍一下配置方法。

首先需要安装 Python 的 Language Server。推荐使用 pipx 安装。

$ pipx install python-language-server

1	$ pipx install python-language-server

然后修改 .vimrc 的配置修改，以下是一个最小化配置：

Plugin 'prabirshrestha/async.vim'
Plugin 'prabirshrestha/asyncomplete.vim'
Plugin 'prabirshrestha/vim-lsp'
Plugin 'prabirshrestha/asyncomplete-lsp.vim'

inoremap <expr> <Tab> pumvisible() ? "\<C-n>" : "\<Tab>"
inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"
inoremap <expr> <cr> pumvisible() ? "\<C-y>\<cr>" : "\<cr>"

if executable('pyls')
    au User lsp_setup call lsp#register_server({
        \ 'name': 'pyls',
        \ 'cmd': {server_info->['pyls']},
        \ 'whitelist': ['python'],
        \ })
endif

Plugin 'prabirshrestha/async.vim'

Plugin 'prabirshrestha/asyncomplete.vim'

Plugin 'prabirshrestha/vim-lsp'

Plugin 'prabirshrestha/asyncomplete-lsp.vim'

inoremap <expr> <Tab> pumvisible() ? "\<C-n>" : "\<Tab>"

inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"

inoremap <expr> <cr> pumvisible() ? "\<C-y>\<cr>" : "\<cr>"

if executable('pyls')

au User lsp_setup call lsp#register_server({

\ 'name': 'pyls',

\ 'cmd': {server_info->['pyls']},

\ 'whitelist': ['python'],

\ })

endif

安装的插件需要4个，下面分别介绍一下这四个是干什么用的。

async.vim

因为补全是支持 Vim 和 Neovim 的，async.vim 封装了两个 Vim Async 相关的接口。

asyncomplete.vim

利用 async.vim 做的补全，相当于一个补全引擎。（到这里是和 lsp 还没有什么事儿，配置的都是补全插件。）

这个补全只是负责补全引擎，具体的补全还是要交给依赖此引擎的实现。比如我们想要对路径进行自动补全，需要先安装这个插件，再安装基于此插件实现的路径补全插件，最后对补全引擎注册这个插件，才能使用。安装路径补全插件和注册的配置如下。

Plugin 'prabirshrestha/asyncomplete-file.vim'

au User asyncomplete_setup call asyncomplete#register_source(asyncomplete#sources#file#get_source_options({
    \ 'name': 'file',
    \ 'whitelist': ['*'],
    \ 'priority': 10,
    \ 'completor': function('asyncomplete#sources#file#completor')
    \ }))

Plugin 'prabirshrestha/asyncomplete-file.vim'

au User asyncomplete_setup call asyncomplete#register_source(asyncomplete#sources#file#get_source_options({

\ 'name': 'file',

\ 'whitelist': ['*'],

\ 'priority': 10,

\ 'completor': function('asyncomplete#sources#file#completor')

\ }))

还有很多挺有意思的补全，比如这个 tmux-completion，是基于 tmux 的窗口 buffer 来补全，在 vim 中抄写 tmux 里面的 git hash，URL 啥的挺有帮助。但是我没找到禁用它的方法，导致它会一直弹出来，太烦人了，就没用。

vim-lsp

是一个与 LSP 交互的插件，类似于一个 Vim 的 SDK。

asyncomplete-lsp

将 lsp 中的内容交给 asyncomplete 做补全。

后面的两个配置，一个是设置用 Tab 触发补全（判断补全窗口有没有打开，有打开的话就将tab键映射为补全选择键。

inoremap <expr> <Tab> pumvisible() ? "\<C-n>" : "\<Tab>"
inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"
inoremap <expr> <cr> pumvisible() ? "\<C-y>\<cr>" : "\<cr>"

inoremap <expr> <Tab> pumvisible() ? "\<C-n>" : "\<Tab>"

inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"

inoremap <expr> <cr> pumvisible() ? "\<C-y>\<cr>" : "\<cr>"

然后注册 Python 的 LSP。每一个 LSP 都需要注册。

if executable('pyls')
    " pip install python-language-server
    au User lsp_setup call lsp#register_server({
        \ 'name': 'pyls',
        \ 'cmd': {server_info->['pyls']},
        \ 'whitelist': ['python'],
        \ })
endif

if executable('pyls')

" pip install python-language-server

au User lsp_setup call lsp#register_server({

\ 'name': 'pyls',

\ 'cmd': {server_info->['pyls']},

\ 'whitelist': ['python'],

\ })

endif

效果如下:

配置好这些插件之后，再配置其他语言的 LSP 就简单多了。分成两步：

安装该语言的 LSP，这里有一个列表；
在 Vim 中注册该 LSP；

以 Bash 为例，我们首先按照仓库的介绍，安装该语言的 LSP：

$ npm i -g bash-language-server

1	$ npm i -g bash-language-server

然后在 .vimrc 中用以下配置注册：

if executable('bash-language-server')
  au User lsp_setup call lsp#register_server({
        \ 'name': 'bash-language-server',
        \ 'cmd': {server_info->[&shell, &shellcmdflag, 'bash-language-server start']},
        \ 'whitelist': ['sh'],
        \ })
endif

if executable('bash-language-server')

au User lsp_setup call lsp#register_server({

\ 'name': 'bash-language-server',

\ 'cmd': {server_info->[&shell, &shellcmdflag, 'bash-language-server start']},

\ 'whitelist': ['sh'],

\ })

endif

换成其他语言的话，只要将 cmd 换成 LSP 的启动命令，然后通过 whitelist 或者 blacklist 设置生效的文件类型就好了。

Snip 的支持

Language Server 支持补全一段代码模板，比如写 Elixir 的时候自动补全 defmodule 。但是 vim-lsp 本身是不支持的，snip 在 vim-lsp 中会补全成这个样子：

将这个片段正确的显示在 vim 中，并且支持跳转，需要通过插件来解析 Language Server 返回的片段。

这里又涉及到 N 多插件。首先你需要一个代码片段引擎，负责在 Vim 中生成片段，在片段中需要填写的字段中进行来回跳转，补全。之前在博客中介绍过 Ultisnips ，这里就以它为例。

除了 SirVer/ultisnips 本身，还要安装两个插件来将 LSP 中的 snip 补全到 vim 中来。总共需要安装的插件如下：

Plugin 'SirVer/ultisnips'
Plugin 'thomasfaingnaert/vim-lsp-snippets'
Plugin 'thomasfaingnaert/vim-lsp-ultisnips'

Plugin 'SirVer/ultisnips'

Plugin 'thomasfaingnaert/vim-lsp-snippets'

Plugin 'thomasfaingnaert/vim-lsp-ultisnips'

然后有一个小坑需要注意，Snip 必须确认选中才能展开，也就是菜单中将焦点移动到这个 Snip 上去之后，需要按 Ctrl + y 来展开。

但是这个快捷键可以更改，比如我换成了 Ctrl + o

inoremap <expr> <C-o> pumvisible() ? "\<C-y>" : "\<C-o>"

1	inoremap <expr> <C-o> pumvisible() ? "\<C-y>" : "\<C-o>"

单页应用的登陆验证方式

Posted on 2019年10月28日 by laixintao 6 Comments

前端流行的单页应用（SPA），带来了很多体验上的优化，也带来了很多问题。以往我们每点击一次鼠标，页面就会在后台生成一次，很多事情都会很简单。但是到了单页应用，相当于访问页面的时候只请求了页面一次，后面的数据、表单等都是通过 AJAX 的，页面的渲染由前端完成，给后端带来了很多挑战。

比如说登陆验证，传统的页面每次请求都会经过后端判断一下 Cookie 中携带的信息，如果用户没有登陆，就将用户重定向到一个登陆页面。

但是单页应用一般是页面先渲染出来，然后通过 API 访问后端，虽然鉴权方式还是通过访问 API 的时候携带 Cookie，但是用户将会先看到页面加载出来，然后访问 API 得到 403，跳转到登陆页面，体验就不太友好了。（应该是页面都渲染不出来，直接跳到登陆）。

今天用了一个方法，Nginx 配合后端的应用，来解决了这个问题。这篇文章来分享一下原理。

Before：

用户访问页面；
用户访问 API；
API 返回了 403；
用户跳转到登陆；

After：

用户访问页面；
页面判断用户没有登陆，返回302；
用户跳转到登陆；

之所以出现这个问题，因为采用了传统的单页应用部署方式，即前后端完全分离。Nginx 负责返回前端页面，应用只是一个 API 服务器。渲染页面这一步应用感知不到。

部署方式

要判断用户是否登录的话，就要让“返回前端HTML”这一步交给应用来做。（假如我们想保持 Nginx 不涉及业务逻辑的话。）有人可能认为这样会很慢，实际上返回HTML这一步是很快的，因为这个 HTML 很小，我们写的前端应用都作为 <link> <script> 等引用外部资源异步加载，而且这些静态资源一般都是有 CDN 的。

真正可能慢的地方是 URL 匹配。我们知道在单页应用中，你访问 /m/foo 和 /m/bar 都是完全相同的一个 HTML，只是前端应用通过 URL 的不同来帮你路由了。但是访问 /api/foo.json 的时候可能真正访问到了服务器。一般来说，什么时候是访问静态页面，什么时候是请求 API，我们是交给 Nginx 配置来处理的，因为 Nginx 是一个专业的 Web 服务器，URL 匹配的效率很高。虽然我没测试过，但是我觉得 Django/Spring 这种 Web 框架，匹配 URL 的速度肯定要比 Nginx 慢很多。

所以这里需要：

让应用判断用户是否登录，选择是返回 HTML 还是重定向到登录页面；
URL 匹配还是在 Nginx 做，如果是前端页面，那么 Nginx 就去掉 Path，直接 proxy_pass / 就可以了。那么应用这边只需要对 / 这个 Path 来返回一个 HTML；

Nginx 相关的配置如下：

server {
    listen              80 default_server;

    location ^~ / {
      rewrite /(.*) / break;
      proxy_pass  http://appserver;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-By $server_addr:$server_port;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header Connection "";
    }
}

server {

listen 80 default_server;

location ^~ / {

rewrite /(.*) / break;

proxy_pass http://appserver;

proxy_set_header Host $http_host;

proxy_set_header X-Forwarded-By $server_addr:$server_port;

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header Connection "";

}

表示正则 match 到 / 开头的话，就用 rewrite 指令去掉 / 后面的内容，将 URL 改写成 / 。然后 break 参数告诉 Nginx 停止处理其他的 rewrite，传给后端的 appserver 。注意这里我们的 rewrite 只是改写了传给应用的 Path，此时 Chrome 浏览器的 Path 还是完整的，所以我们这么做并不影响前端的路由。

后端的应用只要对 / 这个 Path 返回一个 HTML 就好啦。比如说用 Spring 的话，就这么写：

@Controller
public class HtmlRender {
    /**
     * 凡是页面请求一律返回此 vm，由前端处理页面路由
     * @return the string
     */
    @RequestMapping(value = "/", method = RequestMethod.GET)
    public String doGet() {
        return "app.vm";
    }
}

@Controller

public class HtmlRender {

/**

* 凡是页面请求一律返回此 vm，由前端处理页面路由

* @return the string

@RequestMapping(value = "/", method = RequestMethod.GET)

public String doGet() {

return "app.vm";

}

这个配置其实很灵活。如果你要 /a 是一个 app，/b 是另一个 app 的话，只要将 Nginx 配置替换成西面这样:

server {
    listen              80 default_server;

    location ^~ /a {
      rewrite /a/(.*) /a break;
      proxy_pass  http://appserver;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-By $server_addr:$server_port;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header Connection "";
    }
}

server {

listen 80 default_server;

location ^~ /a {

rewrite /a/(.*) /a break;

proxy_pass http://appserver;

proxy_set_header Host $http_host;

proxy_set_header X-Forwarded-By $server_addr:$server_port;

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header Connection "";

}

然后应用只渲染 /a 这个 Path 就好啦。

总结下原理就是：Nginx 负责去掉单页应用的 Path，替换成根目录，然后 App 负责判断用户是否登录，如果登录就返回根目录的 HTML，浏览器渲染出来页面。

登陆跳转问题

这里有一个小小的问题，就是后端应用将用户重定向到登陆的回收，会带上一个用户登陆完成之后回到的URL。比如用户访问的是 /hello/bar，那么我们希望用户登陆完成之后，直接跳转到 /hello/bar 。

但是因为 Nginx 将用户访问的 Path 给去掉了，应用认为用户访问的是 / ，那么用户登陆之后就看到的是首页，这样体验就不太好了。

解决这个问题，一开始我想用 cookie 记录下用户去登陆之前想访问的 URL （也是在传统网页时代，我们经常用的方法）。这样一来就要区分用户什么时候是想访问的 cookie 的 URL（应该重定向），什么时候就是想访问用户输入的 URL （不需要重定向）。还要注意什么时候应该设置 Cookie，什么时候不要设置 Cookie，什么时候清除Cookie。所以这个方案比较复杂。

搜索了一通之后，我发现 Nginx 是可以对代理后面的服务器返回的 Location Header 进行修改的。

比如我们 proxy_pass 到 appserver，appserver 返回了 302，带有 Location: /abc/de 的 Header，Nginx 可以将 Header 修改成 /foo/bar ，再返回给浏览器。

这个功能就是 proxy_redirect 指令。

配置如下：

server {
    listen              80 default_server;

    location ^~ /m {
      rewrite /m/(.*) /m break;
      proxy_pass  http://appserver;
      proxy_redirect ~*^(https?://[^/]+/)(.+) $1sourceUrl=http://$http_host$request_uri;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-By $server_addr:$server_port;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header Connection "";
    }
}

server {

listen 80 default_server;

location ^~ /m {

rewrite /m/(.*) /m break;

proxy_pass http://appserver;

proxy_redirect ~*^(https?://[^/]+/)(.+) $1sourceUrl=http://$http_host$request_uri;

proxy_set_header Host $http_host;

proxy_set_header X-Forwarded-By $server_addr:$server_port;

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header Connection "";

}

注意这里的第7行，如果应用返回了 Location Header，那么这里就会将应用返回的重定向目标，修改成第二个参数所表示的重定向目标。其中，$http_host 是用户请求的 URL 里面的 Host，$request_uri 是用户请求的原始的 Path。

这样，我们就有了和传统网页一致的登陆体验了。

杭州PyCon 2019 Slide: 《做Side Project的几个建议》

Posted on 2019年10月19日 by laixintao 2 Comments

Hi！最近太忙了，好久不曾更新博客。今天熬了个通宵，下午要去参加杭州 PyCon 做一个演讲。杭州的讲师比较难找，之前问敏哥能不能把我调整成快速演讲，因为最近没时间准备……大哥说不行。然后我就按照40分钟的演讲准备了。

然后最近看了杭州 PyCon 的官网，嗯，我是快速演讲。

你妹啊！

Anyway，来杭州的朋友，下午见！下面是我准备的 Slides。

Github：https://github.com/laixintao/side-project-slide

在线预览：https://gitpitch.com/laixintao/side-project-slide

GitPitch Presents: github/laixintao/side-project-slide

Modern Slide Decks for Developers on Linux, OSX, Windows 10. Present offline. Share online. Export to PPTX and PDF.

PS: IRedis 最近开发了很多令人激动的 Feature！感觉很快可以有一个能用（大部分命令能正常工作，还剩1/4左右的工作量）的版本了。

PPS: 最近和 David 录制了第7期捕蛇者说的博客，已经剪辑好了，很快会发布。其实上周就剪辑好了，laike9m 要求太高，花了一个周+1个通宵重剪。哭哭。

PyCon 2019演讲: Django Migration Under the Hood

Posted on 2019年9月21日 by laixintao 3 Comments

这是在 PyCON 2019 的分享，内容是 Django Migration 的用法、原理（没有非常深入），常见问题等。

在线播放 Slide 的地址：https://gitpitch.com/laixintao/django-migrations-under-the-hood

Slide 的源代码在 Github 上：https://github.com/laixintao/django-migrations-under-the-hood

如果这方面有问题的听众或者读者欢迎留言或邮件交流~

GitPitch Presents: github/laixintao/django-migrations-under-the-hood

Modern Slide Decks for Developers on Linux, OSX, Windows 10. Present offline. Share online. Export to PPTX and PDF.

坑爹的部署脚本

Posted on 2019年9月17日 by laixintao 7 Comments

我司在开发机器上部署最新版的代码需要用到一些陈年的脚本，经历以下3个步骤：

执行一个叫 mkview.sh 脚本，脚本运行之后会提示你输入 input 一个URL地址，就是你仓库分支的 gitlab 地址。然后这个脚本会去拉最新的代码分支；
执行一个叫 build.sh 的脚本，等待 3min；
执行一个脚 deploy.sh 的脚本，等待5min；

虽然说只有三步，但是太反人类了。首先必须 ssh 登陆执行，然后竟然是命令提示输入这种奇葩形式，而不是直接参数传入。另外这个竟然是传 URL 进去（然后脚本里面奇葩的再把 URL 解析成仓库名字，分支名字）。每次输入之间还要等待几分钟，烦的要死。

操作了几次就受不了了，所以就想办法简化这些步骤。

重写的尝试

首先尝试的是把这三个脚本合成一个，我来打开看看这里面都是什么妖魔鬼怪。结果一打开发现事情并不简单，这都是上千行的脚本（虽然我也不知道里面都写了些啥），然后中间还调用了一些 binary，里面掺杂着各种 xxx 已转岗，xxx 不再维护的注释。看了半天，我连哪里把 git 权限塞进去的都没找到，直接 clone 是不行的，这个脚本就有权限 clone。头大，我还是不去动他了。

上 Ansible

然后我就尝试用 Ansible 处理这三个操作。

处理 prompt

首先要解决的是那个蛋疼的 prompt 问题，毕竟我可不想每次都去拼 URL。搜索了一下，看起来只有这个 expect 模块能够解决终端提示输入的问题。看了一下，不出所料，实现其实是用的 pexpect 包，这个包我最近在开发终端工具 iredis 的时候用了很多。其实这个包坑也蛮多的，比如找不到预期输出的时候只能等待 Timeout。我猜大家都用这个是可能没有更好的选择吧。

因为这是 Ansible 在 remote 机器上的功能，所以需要给机器装上 pexpect。可我司机器 Python 版本是 2.6，没有自带pip……折腾一顿之后，总算是装上了 pexpect。

执行的时候，出现更加蛋疼的编码问题。好吧，看了一下，发现这个脚本把编码写死在脚本里面了。也太反人类了。

放弃这条路了。然后我想这个输入是从键盘输入进去的啊，也就意味着 stdin 输入进去就可以了。试了一下直接用下面这命令就可以：

printf 'user_input' | /bin/script

1	printf 'user_input' \| /bin/script

假设 /bin/script 需要用户输入的话，user_input 就会输入进去。

其实这个问题之前遇到过的，像 apt 这种东西要你确认的Y/n? 可以这样： yes | apt install htop ，yes 会一直输出 y 。当然也可以直接用 -y 选项，正常的脚本都会有这种选项的。

处理 Daemon 进程问题

花了我时间最多的，是一个 deploy.sh 那个操作。很神奇的是，我直接 ssh 跳上去执行，部署成功。

ssh myhost "deploy.sh"

1	ssh myhost "deploy.sh"

但是放在 Ansible 里面，一模一样的命令，就不行了。

- name: Deploy branch.
  command: "deploy.sh"

1 2	- name: Deploy branch. command: "deploy.sh"

shell command 不同的模块都试过了，换 bash deploy.sh 啥的来执行也试过，都不行。但是直接 ssh 去执行就可以。

Ansible 和 ssh 到底差在哪里呢？

想不出来，去问老师。

老师说：

-_-|| 看了一下，果然是 Ansible 退出的时候会清理一个 session group 的进程。

我试了下 Ansible 的 async 功能，好像还是没用，过段时间进程还是被杀掉的。最后直接暴力使用 setsid 重置进程组，父进程直接设置为1，就好了。命令是这么写的：

- name: Deploy branch.
  command: "setsid deploy.sh &"

1 2	- name: Deploy branch. command: "setsid deploy.sh &"

有关 setsid，nohup 和 disown 的区别，这篇文章写得很好，可以看下。

等等，这明明是 deploy.sh 脚本啊，部署的时候不应该把进程 id 啥的都给处理好吗？我都是在经历了些啥啊！

一	二	三	四	五	六	日
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30