6.18 又买了一个新的腾讯云 VPS，本以为轻车熟路 10 分钟配置完毕，没想到搞了半小时，配置 gitee 的 jenkins 插件就 10 分钟，又翻了一遍gitee 插件文档，每次都要翻一遍这个文档。

这次画个图，争取下次 3 分钟搞定 —— 但画图花了半小时，哈哈！

Go 怎么调用 Python？或者说 Python 怎么嵌入到 Go？—— 我要研究明白。

• 方案 1：go -- RESTFul -- python
  • 需要用户起一个 python 进程的 http server 进程，并且定义 RESTFul API。
• 方案 2：go -- rpc -- python
  • 可用 grpc 或其他 rpc，也是需要单独启动一个 python 进程并开启 rpc server，go 中代码作为 rpc client。
• 方案 3：go -- cgo/内存共享 -- python(C-API)
  • python 的解释器绝大多数人都是使用官方的 CPython，内核和解释器是用 C 实现的，可以用 C 代码方便的调用。
  • go 又和 C 是天然搭档，通过标准库中的 cgo 组件可以无缝调用 C。
  • 此时 python core 作为动态库链接到 go 上。

RESTFul 和 RPC 都是网络调用方式，更适合高度解耦的场景，cgo 或直接内存共享则是效率优先。 —— 我打算先摸索一下方案 3。一通搜索，找到了一些好文章，再加上 10 天左右的实战摸索，总结以下要点：

下面依次展开描述图中 1、2、3：

VSCode 中换行分 2 个方面来说：

1. 显示换行：用户的文档中并不真的有 \r\n 这些换行字符，而只是看到被换行了。
2. 格式化换行：用户执行格式化命令（Ctrl-Shift-F或右鍵-formate...或F1-formate...）时 VSCode 或扩展在文档中指定位置插入 \r\n 之类的字符。

来看看 VSCode 中是如何配置这两种换行的。

继续前面的文章 github pages 部署 docusaurus 进行优化，需求：

1. Github Pages 与 jekyll 深度绑定，所以以前 wkevin/wkevin.github.io 上只有源码，但转用 Docusarurus 后需要自己维护 gh-pages 分支，几天下来还是让有强迫症的我感到不爽： git pull origin main 而不能简单的 git pull，否则 gh-pages 的内容会被 fetch 到本地。
2. 因为 Github Pages 不给免费账号的 private 库提供服务，所以我的 blog 源码都暴露了。

解决方案：源码、编译后的制品拆分成 2 个 repo，从源码 repo（A) 向制品 repo（B) 进行 deploy。

从 C、Python 等传统语言走过来的对类型都有“深刻”的理解，去掉枚举、列表、元祖、集合等组合型的，基础类型我整理了下表：

ts 比其他语言在某些方面好像简化了，比如用 number 代替各种数字型，但某些方面又好像复杂了很多，任意类型和无类型就弄出来 4 种，还搞出来 字面量类型 —— 这些变化，体现了 ts 语言设计者的权衡和用心，同时语言设计者也为用户扩展 ts 的 type 留下了一些语法，更是在 type 自定义、扩展这个方面与其他语言拉开了差异。

下面，从我一个刚入门不久的 ts 用户经历和感受，聊聊我最近对 TypeScript 中 Type 这几个字的理解。

又是一年一度公司晋级答辩的日子，我司只有晋升大级才评委现场答辩，小级只要积分够就自动晋升了。多年来我作评委看过很多人写的答辩稿，水平参差不齐，甚至可以说大部分都不是很合格。不是缺少关键元素、就是叙述方向有误。比如：

• 业绩从 3 年前写起
• 每个项目都是一句话带过
• 项目业绩的描述很像《项目需求说明》里的第一个章节，即：项目的成绩、优点、节省成本……
• 技能描述紧贴岗位技能要求写，甚至恨不得把岗位技能要求复述一遍
• 2 级升 3 级，3 升 4，从项目和技能方面文字叙述上拉不开差距

这些内容在我看来出现在晋级答辩中都不是很合适的，我这里有一些修改建议。

今天把 Blog 从 Jekyll 转到 Docusaurus 了，仍是部署到 github，部署过程记录一下。

部署大体可以有这么几种方案，我都试了一下，异同有了一定的理解：

最近学习使用 Midway 和 Tauri，忽然对网站是怎么做出来的来了兴趣，尤其是“侧边栏和 ToC 分列左右”特别喜欢，我多年来一直使用的 Docsify 总是 ToC 混入侧边栏，让我总有些别扭。

把 Midway 和 Tauri 的网站源码下载下来，发现都是基于同一个框架：Docusaurus，就花了一些时间研究，并且把公司团队的技术积累平台修改成此框架，感觉一下高大上起来了。

官方文档已经很详细了，我这里只能做一些小提示吧。

一直想用前后端技术栈做个跨平台（Win/Linux/macOS）的 APP，前几年了解过 Electron，到后来始终没有应用场景，就放下了，最近又掌握了一下最新情况：

前几天恰逢有个场景，就试了一下 Tauri，相比 Electron, Tauri 不会把 node 和 chromium 打包到最终 APP，所以最终构建出的版本会小很多，运行速度也快很多。

用了 2 天跑起来了一个基本的 APP，前端 Vite + VUE4 + Element-plus + TypeScript，后端 Rust，过程记录如下。

国内经常无法顺畅的连接 github，各类 git 操作都无法进行，但其实已经有团队做了 github 镜像站，比如下面要介绍的 2 个。