对 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

https://github.blog/2022-06-14-accelerating-github-theme-creation-with-color-tooling/

Github 出的色彩系统设计工具 Primer Prism, 可以在默认色板上批量调整 HSL 改变整个色系, 有点意思

使用 Encore 的时候, 使用 Google 登录给了一个提示告诉我当前邮箱有另一个账号在使用, 可以选择合并或者另开账号. 才想起原来一年前我就用 Github 注册过 encore 了呀.

个人认为体验非常好, 每次登录一个服务的时候, 如果这个网站提供了多个第三方登录方式, 如 Google / Github / Twitter 等, 我常常会非常困惑, 忘了之前用的是哪个方式, 担心选错了会创建出一个无用的账号. Encore 的做法避免了这种情况, 但也不阻止你另开账号.

技术上实现猜测并不难: 在用户表上存下用户不同平台的 open id (唯一索引), 以及相应的 email (非唯一索引), 在用户注册的时候都拿用户邮箱去检索比对.

我在个人项目当中去对接第三方登录的时候, 为了精简权限 (第三方登录流程中, 获取用户邮箱往往是需要额外权限的) 和数据库表设计, 往往只会存下 open id, 但在未来扩展其他登录方式的时候, 就失去了账号聚合的可能性了.

https://developer.chrome.com/blog/auto-dark-theme/

原来 Chrome 已经内建了自动夜间模式了， 目测在不久的将来会向普通用户开放。

测试了一下，总体效果不错，相比 Dark Reader 还差一点。

这一改动估计能够让不少设计师和开发者脱离维护 Dark Mode 的苦海，只需要对部分元素定制深色配色，其他全部交给算法就好了。

之后个人项目的前端页面，也不打算花心思为 Dark Mode 定制 Palette 了（面向未来编程😁