研究了一下 github.com/samber/lo 这个 Go 泛型工具库，看到了这段代码……可以说有点魔怔了，这就是为什么之前这么多人反对给 Go 加入泛型。

最近把梅林路由器的翻墙代理从 fancyss 切换到了 MerlinClash，不但稳定性提升了非常多，还支持使用 Clash 规则了，强推！
https://t.me/merlinclashcat

苦于 Vercel Serverless 函数上使用 ffmpeg 麻烦：
- 无法预装 ffmpeg（配置 lambda layer 感觉很麻烦）
- 限制编译产物体积上限，压缩后 (tar.gz) 需要控制在 50MB 以内

Node 当中可以使用 ffmpeg-static，不过对应到 Go 并没有好的方案。

于是最近封装了一个库 github.com/go-ffstatic/ffstatic 。类似 ffmpeg-static 的方案———包含完整的 ffmpeg 可执行文件在库内。不过，我为了使用更简单，直接将 ffmpeg 整个 embed 到 Go 编译产物当中，启动的时候再把它们导出到 tmp 目录中。

不过目前还是有点小问题，ffmpeg 4.x 的 x64 版本的 ffmpeg 和 ffprobe 都有 70+MB，一起封装起来压缩完依然有 50+MB，超过了 Vercel 的限制。

不太可能自己去编译个精简的 ffmpeg 出来，目前考虑使用 ffmpeg 3.x 版本来降低体积。另外，也可以考虑通过编译参数来选择是否打包 ffprobe。

体验了 arctype，又是一个“协作+X”思路的基础工具。

作为一个本地 SQL Client，素质还是非常不错的，相比 DataGrip 响应速度快，相比Sequel Ace 界面更好看。

另外，arctype 还支持直接连接 PlanetScale 数据库（不需要本地启端口转发），对于 PlanetScale 用户（包括我）非常友好。

最近字节的汽水音乐发布了，想体验了一下。打算先跑个脚本把在 Spotify 上的歌单同步一份过去。

不同于 Moo 只支持微信登录，汽水音乐提供了手机号登录的方式，这就给了通过脚本获取 token 机会。

尝试用 Proxyman 抓一下包看看各个接口详情，发现一启动 MITM，汽水就没法正常工作了。猜测是客户端启用了SSL pinning，禁止了中间人攻击。

经过一番折腾，终于绕过了 SSL pinning。尝试去抓登录接口，发现请求参数里面部分关键字段被加密了…

虽然客户端加密也是绝对能破解的，但实在是太折腾了，还是放弃了。

对 gRPC-web 祛魅了，gRPC-web 所有请求都使用 POST 发送，导致所有读请求都无法被浏览器/CDN 缓存，对于性能来说还是有比较大的影响的。
参考 https://github.com/grpc/grpc/issues/7945

目前看来在 client 端做一层封装，识别请求体并做缓存可以缓解，但毕竟不是 HTTP 协议的原生实现，并不优雅。

但是，基于 IDL 生成 Client 和 Server Stub 实在是太爽了，目前来看还是会继续使用 gRPC web 的。

因为 Go 的 error 不带错误栈，如果希望追溯错误来源，原生的方法就是每一次 error 抛出的配上一段 message 来 wrap。

因为嫌弃这种做法太麻烦了，一直都使用 pkg/errors 来在 error 当中封装原始 error 的运行栈。但是这不得不让我在最终的错误收集、日志输出上做定制以实现监控。

现在好了，直接让 Copilot 生成 wrap message 就好了。

Copilot 让“大道至简”变得真的简单易用。

https://danpetrov.xyz/programming/2021/12/30/telegram-google-translate.html

这一篇文章还挺有意思的，讲的是 Telegram 引入基于 Google Translate 翻译功能，但是使用 私有 API 来薅 Google 羊毛。

这个 API 是用来给 Chrome 浏览器实现文本翻译的，免费提供给用户使用，自然是可以匿名访问的。调用方只需要使用各种方式模拟出一个请求，欺骗 Google 让其认为这是一个来自普通用户的请求。

#golang

据我所见，字节的 Go 后端是彻底 polyrepo，一个仓库只会是一个服务，多个服务的公共逻辑会拆成各种包来复用。在我看来是不如 monorepo 来得便利高效的，但也不否认 polyrepo 可以简化权限控制、CI 等各种基建工作。没有绝对的正确选择，这取决不同组织架构。

如果选择 polyrepo，日常开发的时候往往会出现一个需求需要改动多个 repo。如果存在 go mod 依赖，还需要先将依赖 push 到仓库，再在调用方仓库通过 git commit hash 拉新的版本。可以算是比较麻烦的了。

好在 Go 1.18 终于加入了workspace 功能，可以通过 go.work 在本地直接将某一个包指向另一个目录，本地改动代码另一边马上就能调用了，大大降低了跨仓库开发的麻烦。

.
└── gitlab/
├── biz_1/
│ ├── svc_1/
│ │ └── go.mod
│ └── svc_2/
│ └── go.mod
├── biz_2/
│ └── svc_3/
│ └── go.mod
├── common/
│ ├── pkg_1/
│ │ └── go.mod
│ └── pkg_2/
│ └── go.mod
└── go.work

这样一来，只需要用 IDE 打开整个代码根目录并配置好 go.work，立马就能获得与 monorepo 几乎一样的开发体验！

刚在 HN 上看到的 https://indigostack.app/

一键在本地配置开发环境, 包括反向代理配置 SSL/数据库等, 确实能节省不少工作.

界面上将所有组件展示为机架上的一个主机, 也很有意思.

目前测试了一下, 发现软件包非常大有 1.6GB, 猜测是将所有依赖软件都打包进来了. 另外由于还未正式发布, 还是存在 BUG, 不能用于实际生产.

太能共情这种在大的技术组织当中放个屁都要写篇文档拉个会议的感受了

https://liou28335.medium.com/many-software-companies-are-a-joke-9f4b10378c7a

这段时间 Bionic Reading 这个概念又火了一把, 猜测原因是有团队在 HN 上分享了他们制作的一款名为 Jiffy Reader 的 Bionic Reading Chrome Extension.
https://news.ycombinator.com/item?id=31475420

最早接触 Bionic Reading 是在 Reeder 上, 个人认为原理大概如此: 按比例将每个单词开头的几个字母加粗加黑, 以让眼睛能够快速地在单词间定位, 提高效率避免走神, 对于英文文章阅读确实效果不错.

不过 Jiffy Reader 似乎尚未发布, 在 Chrome 商店上找到另一款 Bionic Reading 的插件, 体验还是不错的, 可以自定义高亮字母的字重和比例, 推荐.

https://chrome.google.com/webstore/detail/bionic-reading-digest-pas/lbmambbnglofgbcaphmokiadbfdicddj/related

Project Volterra 堆叠设计看起很酷, 可以无限扩容算力?
虽然不用 Windows 做开发, 但是看是起来当家用服务器还是不错的选项.

https://www.youtube.com/watch?v=yICVNta8jMU

工作中大量遇到的情况: 用着 Protobuf/Thrift/Golang 等各种强类型工具, 却又为了灵(tou)活(lan), 把各种字段都包在 object 里面序列化成字符串来传递.
为了解析这个 object 又写了各种 util 去提取里面的值, 真是迷惑行为.

https://buf.build/blog/connect-a-better-grpc

Protobuf 管理工具 Buf 团队发布名为 Connect 的 RPC 套件. 他们罗列了一些 gRPC 的问题:

⁃ 过于复杂, 难以调试, 而且庞大的代码库容易出现漏洞
⁃ 不使用 net/http 标准库
⁃ 不支持浏览器

而 Connect 是在 gRPC 的基础上, 对其进行优化, 一些特性:

⁃ 精简代码, 包括生成的代码也更加可读
⁃ 使用 net/http 标准库, 兼容性更好
⁃ 支持 gRPC/gRPC-Web/Connect 三种协议
⁃ 只支持 HTTP POST 方法, 同时支持 HTTP/1.1 和 HTTP/2, 同时支持 pb 和 json 两种数据格式
⁃ 支持完整的 gRPC 协议, 包括 server reflection 和 health checks.

相比 Twitch 家的 twirp, Connect 还是兼容了 gRPC 协议, 而 twirp 更像是一套基于 Protobuf generator 的 JSON-RPC.

看起来 Connect 确实是 “A better gRPC”, 既能兼顾高性能的场景, 也能对受限的环境(浏览器/调试)做 fallback.

在 Product Hunt 发现个神器 jsonhero, 可以结构化地查看 JSON 内容, 甚至对于一些特殊格式的字符串定制了相应的视图:

⁃ 预览 URL 内容 (多媒体可以直接播放, JSON 可以进一步探查)
⁃ 时间字段 (ISO8601) 可以展示日历
⁃ RGB Hex 可以预览颜色
⁃ 内嵌的 JSON 字符串也可以结构化预览 (这个最实用!)

他们也刚刚推出了 Chrome 插件, 在 JSON 数据的页面 (当前页面的 URL 的 content-type 为 application/json)上, 点击插件就能跳转到 jsonhero 上查看

平时预览 JSON 我一般使用命令行工具 jless (类似 jq, 但能实现折叠)

curl https://example.com/demo.json | jless

常见的场景是从 Chrome DevTool 当中拷贝 curl 出来调用一下并预览, 所以这个时候直接使用 jsonhero 并不方便

所以我写了一个类似 jq 的命令行工具 https://github.com/sorcererxw/jsonhero 来实现将 JSON 输出到 jsonhero 上查看

go install github.com/sorcererxw/jsonhero@latest

curl https://example.com/demo.json | jsonhero