guqing
毕生所求无它，爱与自由而已
Halo 通知机制 RFC
用户可以通过 Subscriber 来订阅自己感兴趣的事件，当事件触发时会收到通知： 当用户订阅到事件后会创建 Notificatioin, 它与通知方式（notifier）无关，recipient 为用户名，类似站内通知，如用户 guqing 订阅了评论事件那么当监听到评论事件时会创建一条记录可以在个人中心的通知列表看到一条通知消息。 NotifierDescriptor 自定义模型用于声明通知器，通过它来描述通知器的名称、描述和关联的 ExtensionDefinition 名称，让用户可以在用户界面知道通知器是什么以及它可以做什么, 还让 NotificationCenter 知道如何加载通知器和准备通知器需要的设置以发送通知。
使用 JavaScript 对图像进行量化并提取主要颜色
图像的颜色值量化 以下面的图片为例 它的色值分布为如下的图像 从上述 RGB 3D Scatter Plot 图如果将相似的颜色值归为一类可以看出图像大概有三种主色调蓝色、绿色和粉色： 如果我们从三簇中各选一个中心，如以 A、B、C三点表示 A(50, 150, 200)、B(240, 150, 200)、C(50, 100, 50) 并将每个数据点分配到最近的中心所在的簇中这个过程称之为聚类而这个中心称之为聚类中心，这样就可以得到 K 个以聚类中心为坐标的主色值。
社区例会 Vol.06 从零开始的 Halo 插件开发
在此期间，涉及了插件生命周期、如何使用自定义模型、自定义模型对象的生命周期介绍、如何使用自动生成的 API、如何创建自定义 API 等演示说明，并初步实现了以下功能： 通过 GitHub API 获取个人仓库信息； 创建自定义模型 Repository； 将 GitHub 仓库信息通过自定义 API 存储到 Repository 模型中； 通过 Repository 的自定义模型 API 列出数据； 参会人员对演示内容进行了提问和讨论，并提出了一些开发中的问题和建议，如： 开发体验有待优化，可以考虑在用户界面提供 Devtools 相关功能，仅在插件开发时用于对用户界面的自动刷新和插件热重载。
泛太湖游仙岛书事
三月四日，我来到了无锡市鼋头渚风景区游览了一番，太湖，这个千年古湖，如今依旧，它那澄澈的湖水、美丽的风景、壮阔的历史，让每一个到此游玩的人为之倾倒。 夕阳西下，天地渐昏，太湖波光粼粼，宛如水晶镶嵌，一片昏黄中透着淡淡的蓝色，犹如温柔而又坚韧的女子。 此刻，我置身于太湖仙岛湖边的看台，眼前是夕阳西下，远处湖面上还有几只海鸥在飞翔，一点点黑色的身影在天空中流转。 夕阳的余辉如此美丽，它在湖面上泛起了一片金色的光芒，而我则不禁陷入了对太湖的美丽深深的迷恋之中。
一款美观小巧的 Oh My Zsh 主题
特性： 箭头符号在命令正常执行时显示为 user color，输入执行错误后显示红色 目录提示符只会显示当前所在目录名，上级目录只显示首字母 在一个 Git 仓库时会显示分支名称和工作区状态，当工作区 clean 时分支名为绿色，dirty 时分支名为红色，还有勾、叉、星等具体的状态提示符 使用方式： cd ~/.oh-my-zsh/custom/themes 下载一下文件到此目录 vim ~/.zshrc 然后修改ZSH_THEME的值为ZSH_THEME="guqing" source ~/.zshrc 就完成啦🥳
Halo 2.0 如何开发一个插件 [WIP]
如果定义了这样的 Controller ，插件启动后会生成如下的 APIs 生成规则为 /api/{version}/plugins/{plugin-name}/{mapping-in-class}/{mapping-in-method} 其中: version：来自 @ApiVersion("v1alpha1") 的 value，详情参考：Halo plugin API composition plugin-name：值来自 plugin.yaml 中的 metadata.name 属性 mapping-in-class：来自标注在类上的 @RequestMapping("colors") mapping-in-method：来自标注在方法上的 @GetMapping 插件还允许使用 @Service、@Component 注解将其声明为一个 Spring Bean，便可通过依赖注入使用 Spring Bean，示例： resources：目录为插件资源目录 admin 目录下为插件前端打包后的产物存放目录，固定为 main.js 和 style.css 两个文件 extensions 存放自定义模型资源配置 plugin.yaml为插件描述配置 static 为静态资源示例目录 插件启动时会加载 extensions 目录的 yaml 保存到数据库，apple.yaml 为本项目自定义的模型的数据示例，当启用插件后调用 便可查询到 apple.yaml 中定义的记录 reverseProxy.yaml 为 Halo 中提供的模型，表示反向代理，允许插件配置规则代理到插件目录 它表示访问 GET /assets/{plugin-name}/static/** 时代理访问到插件的 resources/static 目录，本插件便可访问到一下静态资源 roleTemplate.yaml 文件中 kind: Role 表示插件允许提供角色模版，定义格式如下： 必须带有plugin.halo.run/role-template: "true" labels，表示该角色为角色模版，当用户启用插件后，创建角色或修改角色时会将其列在权限列表位置。
我们很激动的宣布 Halo 1.5.0 发布了
halo-dev/halo-admin#439 halo-dev/halo-admin#440 halo-dev/halo-admin#449 halo-dev/halo#1668 @ruibaby @guqing Content API 的评论列表接口不再返回 ipAddress 和 email 字段。 halo-dev/halo-admin#453 halo-dev/halo-admin#513 @ruibaby halo-dev/halo-admin 修改用于切换后台样式的 less 依赖 CDN 为 unpkg。
如何使用不同云厂商的服务器搭建 K3S 集群
在阅读本篇之前建议你先阅读 WireGuard 的Quickstart来了解它的概念，这将对接下来配置WireGuard十分重要: https://www.wireguard.com/quickstart/ 本篇以两台服务器为例信息如下: 集群节点类型 厂商 公网 IP 地址 内网 IP 地址 操作系统 master 腾讯云 42.xxx.xxx.60 172.17.16.4 CentOS Linux 7.9 node-1 qingcloud 139.xx.xx.46 10.190.19.38 CentOS Linux 7.9 首先会通过 WireGuard为两台机器创建一块虚拟网卡并指定虚拟 ip 形如： 最终信息如下： 安装WireGuard 在搭建跨云的 k3s 集群前，需要先把 WireGuard 安装好，WireGuard 对内核有要求，要升级到 5.15.2-1.el7.elrepo.x86_64以上 分别在Master(表示腾讯云的服务器在集群中作为master节点使用)和Node-1（表示QingCloud的服务器在集群中作为工作节点使用）执行如下命令以开启 IP 地址转发： 对两台服务器修改主机名称 修改 iptables 以允许NAT 对两台服务器都进行如下设置，添加 iptables 规则，允许本机的 NAT 转换，执行前需要将如下的192.168.1.1/24修改为在简介中决定设定的虚拟ip: 释意: wg0: 为虚拟网卡名称,两台服务器可以都叫wg0 192.168.1.1: 为虚拟 IP 地址段, Master设置为192.168.2.1, Node-1改为192.168.2.2 eth0: 为服务器的物理网卡 升级内核 配置好 iptables 只有升级内核以安装WireGuard，否则安装WireGuard时会出现如下错误: 在所有节点都执行如下操作： 载入公钥 升级安装 elrepo 载入 elrepo-kernel元数据 安装最新版本的内核 删除旧版本工具包 然后修改默认内核版本，首先查看当前实际启动顺序 查看内核插入顺序 设置默认启动, 将CentOS Linux (5.15.2-1.el7.elrepo.x86_64) 7 (Core)改为步骤6中列出的最新内核信息 重新创建内核配置 重启服务器 验证当前内核版本 安装WireGuard 在两台服务器都需要执行如下操作，安装流程非常简单，CentOS 内核更新到 5.15.2以上版本后，其中就已经包含了 WireGuard 的内核模块，只需要安装 wireguard-tools 包即可 配置 WireGuard wireguard-tools 包提供了我们所需的工具 wg 和 wg-quick，可以使用它们来分别完成手动部署和自动部署。