停更几年的 Wikipedia 增强插件 Wikiwand 最近 更新了2.0版本 。除了更现代化的 UI 设计，还增加一个基于 GPT-3 的 TLDR 模式，假设读者是儿童来让 AI 总结词条。用了几周，刷Wikipedia堪称享受了。

前几天对信用卡账单的时候，惊讶地发现上个月 MongoDB Atlas 托管数据库扣了将近 200 刀。可能是因为上个月部署了些 cronjob，对数据库用量比较大。但几个小服务产生这么高的消费还是不能接受的。

想着 MongoDB Atlas 是用不起了。但暂时找不到 MongoDB 托管的替代品，试着在 Railway 上起了台 MongoDB 托管实例。把老数据 dump 过去并重启了所有相关服务，完成迁移也就十分钟。

刚看了一眼 Railway 的 Usage 统计，根据每分钟的 CPU/MEM 的平均用量，预估了当月费用，一个月不超过 5 刀 🫠 （比根据读写次数计费划算多了）。

不过如之前所说，Railway 对数据库的可用性没有强的保证，也没有显式的数据备份解决方案。打算先用 Github Action 写个定时 dump 数据库保存到 S3 的脚本，临时先用着。

https://mastodon.social/@simevidas/109919980697679274
虽然符合预期，但还是很好笑

之前通过 DHCP，把全家的所有设备的网关指向软路由（openclash），从而实现翻墙。不过最近发现 homekit 的稳定性不太好，家居中枢经常掉线。想了一下大概是 openclash 连接代理服务器本身稳定性不够。

于是在路由器上通过 dnsmasq，调整了 DHCP 配置，只将部分设备的网关指向软路由。考虑 homekit 本身可能也有翻墙需要，故两个家居中枢，一个（homepod）留在了墙内，一个（apple tv）开启了翻墙。

这样一来，整体稳定多了。

发现自己各种后端服务部署有点混乱，在 Vercel、Railway、Digital Ocean 等 PaaS 上都有部署，对应了不一样的羊毛使用场景。但是发现服务间互相调用会非常麻烦，代码里面需要关心目标服务的具体位置，维护成本和心智负担都不小。

于是写了个“服务发现”机制。使用一个服务发现服务 Discovery Service，通过 Vercel、Railway、Digital Ocean 的 API，不断拉取部署相应平台上部署信息，并存储下来。然后每一个服务会定时从 Discovery 上获取全量的服务列表，然后根据服务的唯一标识映射获取对应的公网地址。这样以来只要保证在 PaaS 上部署服务并暴露公网，客户端就能通过服务名称直接访问。

最近要在 Redis 上做一个超大 QPS 的指标统计功能。考虑到重试幂等，没法直接用 INCR 来累加。于是想用 Set 结构存储，用 SCARD 查总量。这就涉及到占用过大的存储空间的问题。然后就各种折腾，写了一堆代码逻辑来尽可能降低存储占用，还把 Redis 换成了磁盘大容量存储的类 Redis 存储。

刚才和 ChatGPT 讨论的时候，被指出可以使用 HyperLogLog。雀食 🙈。技术还是得常用常新，不用不复习太容易忘。

https://www.bitestring.com/posts/2023-03-19-web-fingerprinting-is-worse-than-I-thought.html

TIL，原来清除网站数据或者开匿名模式，并不能避免浏览器指纹标记。

https://cord.com/ 果然有了，画布评论SaaS

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/