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，体感上确实流畅了一点。

https://deephaven.io/blog/2022/08/08/AI-generated-blog-thumbnails/

有点意思，使用 DALL·E 生成图片作为文章插图。

以前插入一张图是使用关键词去搜索引擎找，然后再给图片配上 alt。

现在是直接给 alt 配上一张图片，还能保证图片独一无二、风格一致，确实是革命性的。

https://hnpredictions.github.io/

通过爬虫抓取了 hacker news 上所有 prediction 发言。算是某种意义上的“自动挖坟”。得益于 HN 的高质量用户群体，看看几年前用户对科技政治经济的预测，还是蛮有意思的。

https://medium.com/vanguards-of-code/lodash-is-dead-long-live-radash-d9d52abf428b

radash - 取代 lodash 的工具函数库

看起来比 lodash 的代码质量更好更精简。由于使用 TypeScript 编写，相比 lodash 类型校验也更加完善。另外还加了一些基于 async-await 的工具函数。感觉不错。

https://github.com/rayepps/radash

最近一个体会是个人玩票项目 side project，尽量用一两个简单的工具完成核心功能就好了。千万不要引入一堆组件、工具链、外部依赖去达成一些炫酷的能力，产品为技术让一下步，鬼知道三个月后还能不能跑起来。

Cloudflare 发布消息队列内测

从Worker开始，Cloudflare为帮助开发者构建大型、可靠的应用程序，不断开发所需基础设施，当遇到不需要立即获得结果，但并发量又需要进行控制时，差不多就需要消息队列上场了

限制
队列个数 10个/每账号
消息大小 ≤128KB
消息重试次数 ≤100次
批量提交消息数 ≤100条
批处理等待时间 ≤30秒
消息吞吐量 ≤100条/每秒
*Cloudflare Queues 与Cloudflare Workers集成，收发消息目前必须使用 Worker，后续将支持其它API接口
*部分限制可能会在后续测试调整、放宽或取消

定价
按每月总操作次数收费；每写入、读取或删除 64 KB 的数据，就计为一次操作，没有带宽流量费用
每月前一百万次操作免费，后续每百万次操作 0.4$
完整传递一条消息需要 3 次操作：1 次写入、1 次读取和 1 次删除
月账单估算公式为：
(消息总数-1000000)*3*/1000000*0.4$
*在内测期间试用免费 >>申请内测

🗂文档
Cloudflare Queues

Cloudflare Queues: globally distributed queues without the egress fees
#消息队列
Via @Cloudflare_CN

https://vercel.com/changelog/improved-monorepo-support-with-increased-projects-per-repository

Vercel 把 pro 用户的单 repo 可绑定的 project 数量从 10 提升到 60，可以支持一个中型 monorepo 了

最近实现了一个更加优雅的方案，就是将所有网页上面的 notion block （img/video/...）的 src 指向 /api/resource/{block-id} ，这个接口每次被请求的时候都会请求 Notion API 去获取最新的 S3 链接，最后返回客户端 HTTP 307 重定向到资源地址，并使用 Cache-Control 保证最近一段时间内都不需要重新获取。

这样一来，每一次浏览器都能跳转到未过期的资源链接，就不再需要任何外部 cronjob 去主动触发刷新了。

https://makeavideo.studio/
Meta 的 AI 视频生成，太酷了

正儿八经地用 Github Codespaces 写了一段时间的代码，把本地开发环境用 Github Dotfiles 配置了一遍。

不得不说体验非常不好，期间无数次压住 clone 代码到本地直接用 IDE 打开的念头。

一方面我非常不习惯使用 VSCode 开发，即便是 VSC 强项前端开发，我也觉得是不如 Goland 智能响应快的。其实也试过通过 Goland 直接 SSH 到 Codespaces 开发，但这就有点脱裤子放屁了。

另一方面是网络不够稳定。虽然大多数时候是稳定的，但一旦碰到连接中断，可能会发现本地变更代码压根没法 commit，刷新一下网页，代码可能直接丢了。开发的时候无时无刻都会焦虑网络问题。

也好，彻底打消了购入 iPad Pro 念头。

https://vercel.com/analytics

Vercel 收购了 Splitbee，把访客分析集成到了自家的 Analytics。对于个人项目来说也不需要专门去引入 Google Analytics 了。

一直想试试看 Splitbee，喜欢它的产品调性，现在省事了。

最近需要在数据库存储一批复杂的配置文件，需要原子化更新配置的内部字段的能力。一开始打算用 MySQL，有两个方案：

1. 整个数据结构序列化后塞在一行的一个字段里面。更新的时候在开事务（上行锁）整个读出来更新好写回去。
2. 根据数据结构，老老实实建模，各种 list 表，relation 表，每一个字段都是一列……多数情况下不需要用事务就能单独更新内部字段。

前者省事，但是不优雅；后者足够教条，但太麻烦了。

最后，还是换成了用 MongoDB，整个配置作为 document 写到库里，想怎么原子更新子字段就 怎么更新。虽然 MongoDB 更新文档本质上也是单行事务，但局部更新的语义支持确实比 MySQL 优雅。

https://github.com/topgrade-rs/topgrade

一条命令更新各种包管理中的包，包括 homebrew/zsh插件/pip/npm/docker镜像等等，不更新会死星人感到舒适。