connect server 支持 HTTP GET 了，只需要设置幂等级别为无副作用，就会自动为对应 method 配置 GET router。

service ElizaService {
rpc Say(stream SayRequest) returns (SayResponse) {
option idempotency_level = NO_SIDE_EFFECTS;
}
}

idempotency_level 是 protobuf 内置的 method 属性，分为 unknown/idempotent/no_side_effects，后两者都是幂等的意思。

在 RPC 场景中，只要是幂等就代表 Client 端可以安全地重试 RPC 调用，至于是否有副作用指导意义不强。

但是放到 http restful 接口上，GET 往往就等价于无副作用，以此判断是否支持 HTTP GET 还是比较合理且巧妙的。

https://github.com/bufbuild/connect-go/releases/tag/v1.7.0

之前使用 mackup 把 mac 上的各种配置文件备份到 icloud 了，今天发现 icloud 中的 mackup 目录被错误删除了，在 icloud 上使用文件恢复也找不到……然后 icloud 默默同步文件把本地版本也给删除了，各类配置都是软链接到 icloud 目录的，导致本地所有配置都没了

现在看着唯一一个还开着的加载了之前 .zshrc 的 zsh，再犹豫要不要放弃恢复重新配置一份 .zshrc，积累了几年的配置全都没了😩

周末倒腾了一下 Surge5 新加入的 Ponte 组网能力。相比一直在使用的 Tailscale 有一个明显的优势，就是不需要自己搭建 DERP 中转服务器了，可以直接使用机场作为中转服务器。

我是用的香港节点作为中转，在公司访问家中mac延迟稳定低于 100ms。因为机场往往是不限速的，使用 VNC 开远程桌面也不需要压缩画质。

通过一些简单的规则就可以实现在外访问家中内网服务：
HOME = select, DIRECT, DEVICE:mymac
IP-CIDR,192.168.50.0/24,HOME

反过来，也可以在家直接通过公司的 mac 作为跳板访问公司内网，非常方便。

昨晚折腾了一晚上的 jetbrains gateway，想着用 goland 远程开发。

整体体验下来就是烂，各种功能和插件需要区分 Host 和 Client，有些插件需要两侧同时安装才能使用，心智负担很高；很多插件本身就是面向客户端模式设计的，在这种前后端分离模式下根本没法使用。

性能的话倒是可以接受，开个 golang 的 monorepo，8c16g 的开发机，索引的时候会打满 CPU，平峰期差不多占用 2c8g。

总的来说，我宁愿使用 neovim 来远程开发，各种体验至少是原生的。

最终返璞归真，在 Github 上开了个仓库存了各种配置文件，clone 到本地手动 ln -s 创建软链接。

这类不是天天都要变动的配置文件，确实没有必要用 icloud 之类云盘实时同步。
分享下重写的 .zshrc，用在我的多个 macos/linux 环境下，使用 Github Action 从我的配置仓库当中自动同步到 Gist，https://gist.github.com/sorcererxw/238f7068c18ba148337f32f9a08d0dbd

mac（尤其是 intel 的），在唤醒之后常常会碰到 kernal_task 跑满 CPU 的情况，猜测是得把缓存到磁盘的数据读回到内存中，期间会非常卡。 https://discussions.apple.com/thread/5497235
各种办法都试了，效果都不明显。现在找到一个不错的办法，就是开个终端，执行 caffeinate -s，只要我不中止这个进程，系统完全不会休眠，这样就避免了唤醒的问题。

早上尝试在家通过 Surge 作为跳板访问公司内网，发现规则模式下怎么都访问不通。
发现所有请求都直接使用了 Final 的兜底规则，通过机场去访问了公司内网，那肯定是不通的呀，光 DNS 就没法成功（需要使用内网 DNS）。

研究了半天，发现原来是因为自己在内网规则前加了一个 IP-CIDR 规则，整体规则如下的：

IP-CIDR,10.0.0.0/8,PROXY
DOMAIN-SUFFIX,company.org,COMPANY
FINAL,PROXY,dns-failed

根据 Surge 文档所说：在进行规则判定时，Surge 自上往下依次尝试匹配每条规则，如果遇到了一条 IP 类型的规则，那么 Surge 将进行 DNS 解析后再进行匹配。

1. 当处理内网请求的时候，先碰到了 IP-CIDR 规则，当场开始 DNS 查询域名的地址，但是内网 DNS 本地显然访问不通，最后解析失败。
2. 根据 dns-failed 规则使用了 FINAL 的 PROXY 策略，选择了使用机场兜底。

最后把 IP-CIDR 规则移到下方之后，就解决了问题。老实说这个设定确实蛮坑的......

最近工作上有一个需求，处理一批数据，需要各种展开分析统计数值，原始数据量非常庞大，笛卡尔积一下大概是每小时要处理 10^15 条数据。因为数据规模实在太大了，完全没法在线实时统计，只能离线慢慢算。

开个 Spark 定时调度任务，每小时跑一次上个小时的数据，单次计算上千核+几TB内存还要跑几十分钟。

作为后端开发，一直只实现各种实时计算，对于各种计算成本精打细算，很少接触离线数据分析。

哪里见过这种场景，一段 SQL 丢进去，就是无脑暴力跑，太震撼了。

最近把自建的 umami 从 1.x 升级到 2.x。根据文档，顺利地升级了 postgres 当中的表结构和数据，但是 2.x 的实例起来之后，一直都无法读取数据库中的数据，看了眼日志，大概是 prisma 处理数据报错了。
无奈，尝试把旧数据清空，原来的报错倒是没了，但是网页上报的数据一直没有正确消费写入。
累了，也懒得回退到 1.x，不太想继续用 umami。

还是看看各种 analytics SaaS 吧。除了 Google Analytics，几乎所有类似的服务，价格都不算便宜，Vercel/Cloudflare 之类的都是 20刀一个月，单纯只是网站数据统计的话，感觉意义不是很大，毕竟流量不大，自建 umami 之类的一个月成本也就2刀以内。

对于我来说，更大的痛点其实是服务端的可观测性，自建一套 prometheus/Influxdb + grafana 维护起来蛮麻烦的。所以打算找个原生支持 OpenTelemetry 的 Analytics SaaS，我直接将前端后端数据都通过 OpenTelemetry 打通接入。
最最理想的状态，是能够把 log/metrics/trace/alert 全部依赖一个平台接入。

找了一圈，要不是价格很贵，要不功能不完善，要就不兼容 OpenTelemetry。

想想也是，这类数据统计一旦统计的数据维度多一点，很容易出现统计数据的流量是业务流量好几倍的放大现象。工作中也在维护一个统计服务，也是整个系统的成本怪兽。也能理解为什么各类数据统计 SaaS 这么贵。

【新产品介绍】OpenObserve 是 Rust 开发的一站式 Logs, Metrics, Traces 可观测产品，去年该团队开发了 ElasticSearch 轻量级替代品 zincsearch 迅速获得 15000+ star，并获得 460 万美金种子轮融资，后来转型专注于新的可观测产品 ZincObserve，最近改名为 OpenObserve。
https://openobserve.ai/

忽然想到，使用类似 Protocol Buffers（protobuf）或者 Thrift 这样的 IDL 声明接口，往往允许修改字段名称，只要保证不修改字段类型和序号，保证数据结构内存结构一致，就不会出现客户端和服务器不一致而冲突的情况。

但如果通过 grpc-gateway 或者 Connect 这样的框架，基于 protobuf，来与前端通过 JSON 而非二进制数据做数据交互，就是另一种情况。在这种情况下，可以随便修改序号，但是绝不能修改字段名称。

如果同时兼容 JSON 和二进制（原生 grpc）两种数据传输，那么就意味着这个 IDL 上的一个字段也不能更改。本质上，这是由于两种模式使用不同的字段索引方式造成的。

为了 SEO，用 Telegram API 同步了本频道的内容，展示在我的主页上，后续通过 Google 就能搜索本频道内容了。

https://sorcererxw.com/thoughts

https://blog.cloudflare.com/cloudflare-snippets-alpha/

有点意思，Cloudflare 的 Snippets，可以套在 API 前面做一些轻量的业务逻辑，有点 API Gateway 的意思。
只不过奇怪为啥不直接叫 middleware 或者 interceptor，更加符合常识。

几周前，我给自己的服务加上构建通知能力：CI/CD完成后，用Telegram Bot给我通知。今天我把这个 bot 设置为 mute 了，因为往往是积压了很多未读消息，我都懒得看......

其实是很奇怪的心理：
- 完全不发通知吧，根本不知道部署状况
- 只发送部署失败的通知，没收到消息也不能保证肯定成功了，搞不好连 CI/CD 流程都没触发
- 全部都发吧，有效信息比例太低了，看都懒得看

https://www.recursive.design/
太喜欢 Recursive 这款可变字体了。

作为 UI 字体，我最喜欢的一点是，固定 font-family（sans/mono）的情况下，调整字重，字体宽度不受影响。在前端开发的时候，如果我们 hover 的时候调整对应元素的 font-weight，往往会出现抖动，需要使用 shadow 来替换 font-weight 来实现相同的效果。如果使用 Recursive 就能很优雅地避免这个问题。

因为支持 monospace 的变种，目前我也使用 Recursive 作为我的代码编辑器的字体，非常好看。

最终还是自己整了一套 OpenTelemetry 系统，使用 Otelcol 统一收集上报数据，使用 Prometheus 存 metrics，Tempo 存 trace。最终所有数据在 Grafana 上统一查看，也可以在 Grafana 实现报警的能力。

考虑 PaaS（Railway） 已经提供了免费的日志存储，就不再自己维护了，只需要保证日志当中包含 trace id，方便关联追溯即可。

所有组件都只用 Docker 部署了单实例，除了 Prometheus 占用了内存比较高，整体开销不大，相比购买第三方的 SaaS 服务，比较合算。

试着使用 GPT4 把博客的内容国际化了一下，半个月下来，Google 搜索展示量有了明显的上涨。

因为所有内容是富文本，甚至是 markdown 超集，想要翻译并保留格式必然要定义一些 DSL，这个时候就不得不依赖下 GPT4 较强的逻辑推理能力，保证输出的结果可靠性。

不过调试过程中，反复调整 prompt，GPT4 的开销太高了，有点吃不消。还是等后面 GPT4 turbo 放开使用了，考虑自动监控内容变更，自动更新翻译内容。

https://blog.jetbrains.com/go/2024/01/18/goland-2024-1-eap-program-and-roadmap/

Goland 2024.1 Beta 更新了，日志上明确提升了性能和 remote dev 稳定性。

今天使用 Gateway 连接了开发机新版的 Goland，整体流畅度相比 2023.3 确实明显提升。之前版本在切换文件或者打开 UI 组件的时候经常会有明显的掉帧，在新版上少了很多类似的情况。

确实可堪一用了，终于不需要使用 VSCode Remote 了。

不过性能开销似乎没啥提升，32c64g 的开发机日常是 20% CPU load + 90% 的内存占用。。。

最近退订了Github两项付费订阅：GitHub Pro($4/m) 和 GitHub Copilot（$10/m)

GitHub Pro：
一开始订阅诉求是更多的 Codespaces 的单位时间额度，临时开发一些东西可以直接云端编码。
但是用着用着发现机器配置很不灵活，2C8G 和4C16G 的机器只有 32GB 磁盘空间，大一点的仓库下载一下依赖就占满了并禁止磁盘写入了。
如果想要更大的空间，8C32GB 的机器起步开始提供 64GB 的磁盘空间，这样一来 CPU 单位时间配额马上就用完了。
目前使用 Gitpod 了，无法选择 region，网络连接不如 Codespaces，但是配置足够用，实际开发体验可以接受。

GitHub Copilot：
大模型代码补全也发展好几年了，在大多数场景下，各类竞品完全能够提供不输 Copilot 的体验。
促成我寻找替代品的关键是，在远程开发模式下，Copilot 插件总是无法稳定使用 vscode 或者 goland 的 proxy 配置，导致国内的开发机无法正常补全代码。
目前转向使用 Codeium 了，提示速度、质量都非常好，还在代码内行内提供了一些预先配置好的 prompts 用来快速修复错误/重构/注释，功能上更加丰富。

https://github.com/valkey-io/valkey/issues/18

看到 Linux 基金会分叉了 Redis 建立了 Valkey，想起前几天另外一个 Redis 分叉 Redict，好奇两个分叉是什么关系，特地去搜了下。

看到这个 issue，Redict 维护者疯狂推销他们的许可证以及 FOSS 协作工具，尝试合并两个开发者社区。而 Valkey 维护者显然更加务实， 不接受更换代码托管和证书。

管窥开源社区的政治生态，挺有意思的。