#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 了（面向未来编程😁

一年一度地重构了一遍我基于 Notion 搭建的 个人网站, 从使用 Notion 前端私有接口切换到 Notion 的开放接口, 可以尽量避免接口发生 Breaking Change. Notion 的私有接口经常发生变动导致我需要重新适配, 非常恼人.

另外, Notion 接口当中很多 Block 类型字段不完整或者不满足定制化的前端渲染需要, 比如:

- 部分类型 Block 需要二次查询子节点
- 代码块需要异步渲染高亮
- 多媒体文件需要额外多鉴权
- 需要异步生成 LQIP
- bookmark 类型不包含 opengraph 信息
- 等等……

放弃了在前端直接使用 Notion SDK 提供的数据结构, 而是使用 Protobuf 自定义一套数据结构, 并搭建了一个 BFF 服务来做数据聚合, 把所有需要异步完成的工作全在服务端一次性完成.

这样只需要在 SSG 的时候拉取数据不需要在端上额外计算就能渲染出页面, 无论是对于 SEO 还是性能都能带来提升.

（提前优化爱好者就是我本人了

自己的一些服务用需要 redis，直接用了 upstash，一开始以为每天 10k 的 request quota 妥妥够用，没想到放开了用分分钟超额。

最后还是乖乖地在自己的服务器上跑了一个 redis 容器，只作缓存，稳定性低一点，数据丢就丢吧。

无意当中看到这个 issue。当我们使用 Notion 作为 CMS 搭建网站的时候，绕不开 Notion 的 S3 图片链接会过期的问题。因为图片会过期，静态生成的网页常常会加载不出图片。哪怕现在去看 Railway blog 依然可以发现有些图片加载不出来。

最简单的避免这个问题方法就是不要将图片 host 在 Notion 上，而是使用外链塞到 Notion 当中，但是比较麻烦，需要先上传图床再做插入。

Issue 帖主选择放弃 SSG，使用 SSR 渲染，可以保证每次下发的图片链接都是最新的，这肯定会导致网页加载慢（不能套 CDN，套了 CDN 就无法保证页面最新了）。

我的主页也是使用 Notion 搭建，但是在服务端做了非常多的预渲染工作，SSR 肯定是无法接受的。我目前的方案是使用 cronjob 拉取网站的 sitemap，使用 Next.js 的 revalidate 功能定期重新生成每一个页面，并保证新渲染出的页面被 Vercel 的 CDN 缓存下来。非常粗暴的方案，但目前来看是能正常工作，前端加载速度也非常快。

不过我还有另外一个未验证的办法：既然我们为了方便，不可避免地直接将图片 host 在 Notion 上。那么我们可以通过 Notion API 定期扫描页面，将 host 在 Notion 上的图片下载下来上传到图床，并替换原图片。虽然看起来在源头上解决了问题，不过似乎也不太省事。

最近发现服务器用量忽然上涨，查了半天发现 Redis 缓存逻辑根本没执行。

查了一下 Redis，惊讶的发现 Redis 里面居然是空的。尝试 Set 一个不会过期的值过了一会儿就消失了。

猜测是因为 Redis 没设置密码，直接在公网上被扫描到了，然后被执行了 flushall。

因为 Redis 里面就是一些计算缓存，不是很重要所以直接都没做鉴权。看来无论如何还是不能忘记设置密码。

我有一个服务，反向代理了机场的Clash/Surge规则，并在输出的时候在其中加入了一些自定义的 proxy/rule（比如内网跳板、开发机、屏蔽host）。所有设备上的客户端只需要订阅这个反代地址，就能在所有设备上同步相同的配置。

对于我个人来说这还是非常实用的，不知道如果有这么一个 SaaS 服务会不会有受众？

https://www.jetbrains.com/idea/whatsnew/

Jetbrains 全家桶 2022.2 发了，更新了一下 Goland，新功能乏善可陈，本期最大的更新应该是 runtime 从 jre11 切换到 jre17 了，得益于使用了 macOS Metal API，体感上确实流畅了一点。