还是看看各种 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 维护者显然更加务实， 不接受更换代码托管和证书。

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

有一台闲置的 mac，打算用来当作家里的网络代理服务器。有几个方案：

- （现状）在软路由里面安装 Clash，指定部分设备流量走 Clash，实现透明代理
- 缺点：手机电脑日常使用 Surge，只有路由器使用 Clash，需要额外维护一份 Clash 配置，麻烦

- 使用 Mac Surge 接管 DHCP，让流量走 Surge 过，实现透明代理
- 缺点：稳定性差，一旦 Mac 挂了，整个网络就瘫痪了

- 特定设备主动配置代理服务器为 Mac Surge
- 缺点：不是透明代理，可能部分设备无法设置 Proxy

- 在方案一的基础上，让 Clash 直接将所用流量通过 socks5 转发到 Mac Surge，Clash 当中只需要配置一条固定的 socks5 策略

目前来看，最后一个方案既能实现透明代理，又不会影响稳定性，还能实现全设备使用 Surge。

意识到这个模式，使用 iPhone 或者 AppleTV 替换 Mac 也可以实现。因为 AppleTV 不方便插网线，故选择了一台闲置的 iPhone12 搭配 lighting 以太网适配器进行测试。碰到两个问题：

lighting 接口理论带宽有 480Mbps，因为在一个接口上下载并转发，实际吞吐还得打 5 折。实际测试下载，最高下载速率只有 10MB/s，实在不够看。
有一个workaround，让iPhone同时接入Wifi，因为有线网卡和无线网卡是不一样的MAC地址，可以分配不同的IP，软路由侧对这两个 IP 负载均衡，那么就可以实现低延迟需求走有线，高带宽需求走无线。

因为经过一层转发，Surge无法识别请求来源设备了，所有来源地址都是软路由。之前使用 SRC-IP 来识别 XBOX 让游戏通通走低延迟的机场，现在没法实现了。

https://planetscale.com/docs/concepts/hobby-plan-deprecation-faq

PlanetScale 居然开始全面收费了，原来的免费实例会自动休眠。我有几个定时任务还在依赖 PlanetScale 的 MySQL，刚发现已经好些天没有成功运行了。研究了半天，我才发现是 Planetscale 的 DB 挂了，太无语了。

https://planetscale.com/blog/planetscale-forever

估计对于 PS 来说，云数据库 SaaS 业务增长基本到头了，再深入得横向扩展很多业务。倒不如砍掉营销和销售，保持一个收支平衡的状态，专注服务好当前的企业客户就好。

最近在写一个 TUI 的程序，深度使用了一下风很大的 bubbletea，锐评一下：

1. 易于构建大型复杂界面
将界面上每一个元素抽象为 model，拆分逻辑执行函数 Update 和视图渲染函数 View，在组件 Update 当中可以消费全局各种消息更新自身状态，View 当中专注渲染画面，很像 MVVM 架构。通过这种方式可以很容易创造出事件驱动的 UI 架构，对于构建复杂的交互程序很有帮助。

2. 存在界面刷新闪烁问题
可能因为封装比较浅，每一个组件渲染是输出字符串，框架视角下每次渲染是获取整个页面的字符串，很难做到根据变更区域按需要渲染，每次发生元素变更可能导致整行或者整页刷新，页面会闪烁一下，体验比较差。
对比我常用的 TUI 工具，在相同的terminal+shell下，zellij、lazygit、bottom 等，它们并有类似的情况。

手上的一个需求，需要保存一个巨型结构体到数据库当中，得选用一个序列化方式进行存储，需要尽可能保证数据体积小。

这个结构体当中最多的就是大量的 int64 数字，很显然这种情况下使用 protobuf 相比 json 有优势，如果再搭配上压缩算法就更极致了。

一顿折腾测试了下，发现 pb 数据体积确实远小于 json 序列化，但是两者经过 zstd 压缩之后，体积居然相差无几。

那不如直接 json + zstd 就好了，还省得定义 schema。

有了推理模型之后，工作中一些复杂算法代码，目前都是交给 LLM 去生成。深刻感受到，之前鼓吹了很久 TDD，在 AI 编码之后变得非常容易：
1. 根据描述，让 AI 生成一组事无巨细的 test cases。
2. 然后让 AI 生成具体代码逻辑就行，根本不需要 review 内部逻辑，单测出错了就让它一直改到对为止，必要的时候给点提示。
颇有产品经理使唤 QA 和 RD 的感觉。

看到 brew 终于有 Trae 的 cask 了，安装一个试试看。之前体验过AI生成生成前端的工具，但是从来没有尝试过生成一个正儿八经的小工具。今天试试看用 Trae builder 模式“复刻”了下我的一年前的写的小工具，可以用来计算免息分期的实际价值。

老版本 https://0apr.sorcererxw.com/

新版本 https://0apr-ai.sorcererxw.com/

整个开发过程全是 AI （Claude-3.5-sonnet），没有改过一行代码，看着效果还不错，甚至胜过我之前的版本

同时也供君品鉴AI写的代码：https://github.com/sorcererxw/0apr-ai

https://github.com/microsoft/typescript-go

微软选择使用 go 而非 rust 重写 tsc，这下前端圈又热闹了。

大多数的讨论都集中在为什么不选用 rust，这显然是最极致的选项。

从我的视角来看，相比当前的 tsc，使用 go 之类的编译语言重写后，可以显著的降低冷启动的时间，这对于 tsc 这类非持续运行的进程，这非常有帮助（ts 似乎没有走 lsp 这条路线)。

当然使用 rust 可能在冷启动、内存利用等各方面比 go 更优秀，但代价就是项目维护成本陡增，roi 不够突出。而大家诟病的 go 的 gc 机制影响性能，但可能没等 gc 运行，tsc 进程已经执行结束了。

当下重写前端工具链，大家倾向于无脑选 rust，似乎不选 rust 这个项目就没人关注，真是一种技术圈的迷思。既然老大哥做出不一样的选择，未来大家选择的时候，应该得衡量下是否 go 也是合适的选项。