使用 Encore 的时候, 使用 Google 登录给了一个提示告诉我当前邮箱有另一个账号在使用, 可以选择合并或者另开账号. 才想起原来一年前我就用 Github 注册过 encore 了呀.
个人认为体验非常好, 每次登录一个服务的时候, 如果这个网站提供了多个第三方登录方式, 如 Google / Github / Twitter 等, 我常常会非常困惑, 忘了之前用的是哪个方式, 担心选错了会创建出一个无用的账号. Encore 的做法避免了这种情况, 但也不阻止你另开账号.
技术上实现猜测并不难: 在用户表上存下用户不同平台的 open id (唯一索引), 以及相应的 email (非唯一索引), 在用户注册的时候都拿用户邮箱去检索比对.
我在个人项目当中去对接第三方登录的时候, 为了精简权限 (第三方登录流程中, 获取用户邮箱往往是需要额外权限的) 和数据库表设计, 往往只会存下 open id, 但在未来扩展其他登录方式的时候, 就失去了账号聚合的可能性了.
个人认为体验非常好, 每次登录一个服务的时候, 如果这个网站提供了多个第三方登录方式, 如 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 了（面向未来编程😁
原来 Chrome 已经内建了自动夜间模式了， 目测在不久的将来会向普通用户开放。
测试了一下，总体效果不错，相比 Dark Reader 还差一点。
这一改动估计能够让不少设计师和开发者脱离维护 Dark Mode 的苦海，只需要对部分元素定制深色配色，其他全部交给算法就好了。
之后个人项目的前端页面，也不打算花心思为 Dark Mode 定制 Palette 了（面向未来编程😁
Chrome for Developers
Auto Dark Theme | Blog | Chrome for Developers
Autogenerating a dark theme for light-themed sites.
另外, Notion 接口当中很多 Block 类型字段不完整或者不满足定制化的前端渲染需要, 比如:
- 部分类型 Block 需要二次查询子节点
- 代码块需要异步渲染高亮
- 多媒体文件需要额外多鉴权
- 需要异步生成 LQIP
- bookmark 类型不包含 opengraph 信息
- 等等……
放弃了在前端直接使用 Notion SDK 提供的数据结构, 而是使用 Protobuf 自定义一套数据结构, 并搭建了一个 BFF 服务来做数据聚合, 把所有需要异步完成的工作全在服务端一次性完成.
这样只需要在 SSG 的时候拉取数据不需要在端上额外计算就能渲染出页面, 无论是对于 SEO 还是性能都能带来提升.
（提前优化爱好者就是我本人了
无意当中看到这个 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 上的图片下载下来上传到图床，并替换原图片。虽然看起来在源头上解决了问题，不过似乎也不太省事。
最简单的避免这个问题方法就是不要将图片 host 在 Notion 上，而是使用外链塞到 Notion 当中，但是比较麻烦，需要先上传图床再做插入。
Issue 帖主选择放弃 SSG，使用 SSR 渲染，可以保证每次下发的图片链接都是最新的，这肯定会导致网页加载慢（不能套 CDN，套了 CDN 就无法保证页面最新了）。
我的主页也是使用 Notion 搭建，但是在服务端做了非常多的预渲染工作，SSR 肯定是无法接受的。我目前的方案是使用 cronjob 拉取网站的 sitemap，使用 Next.js 的 revalidate 功能定期重新生成每一个页面，并保证新渲染出的页面被 Vercel 的 CDN 缓存下来。非常粗暴的方案，但目前来看是能正常工作，前端加载速度也非常快。
不过我还有另外一个未验证的办法：既然我们为了方便，不可避免地直接将图片 host 在 Notion 上。那么我们可以通过 Notion API 定期扫描页面，将 host 在 Notion 上的图片下载下来上传到图床，并替换原图片。虽然看起来在源头上解决了问题，不过似乎也不太省事。
GitHub
Using `getStaticProps` for fetching images hosted on Notion? · Issue #8 · railwayapp/blog
Hi there, apologies for posting this random question here, but I was curious about how you overcame the issue for rendering images hosted on Notion and also using next/image for optimisation? (As I...
日常技术碎碎念
自己的一些服务用需要 redis，直接用了 upstash，一开始以为每天 10k 的 request quota 妥妥够用，没想到放开了用分分钟超额。 最后还是乖乖地在自己的服务器上跑了一个 redis 容器，只作缓存，稳定性低一点，数据丢就丢吧。
最近发现服务器用量忽然上涨，查了半天发现 Redis 缓存逻辑根本没执行。
查了一下 Redis，惊讶的发现 Redis 里面居然是空的。尝试 Set 一个不会过期的值过了一会儿就消失了。
猜测是因为 Redis 没设置密码，直接在公网上被扫描到了，然后被执行了 flushall。
因为 Redis 里面就是一些计算缓存，不是很重要所以直接都没做鉴权。看来无论如何还是不能忘记设置密码。
查了一下 Redis，惊讶的发现 Redis 里面居然是空的。尝试 Set 一个不会过期的值过了一会儿就消失了。
猜测是因为 Redis 没设置密码，直接在公网上被扫描到了，然后被执行了 flushall。
因为 Redis 里面就是一些计算缓存，不是很重要所以直接都没做鉴权。看来无论如何还是不能忘记设置密码。
我有一个服务，反向代理了机场的Clash/Surge规则，并在输出的时候在其中加入了一些自定义的 proxy/rule（比如内网跳板、开发机、屏蔽host）。所有设备上的客户端只需要订阅这个反代地址，就能在所有设备上同步相同的配置。
对于我个人来说这还是非常实用的，不知道如果有这么一个 SaaS 服务会不会有受众？
对于我个人来说这还是非常实用的，不知道如果有这么一个 SaaS 服务会不会有受众？
https://www.jetbrains.com/idea/whatsnew/
Jetbrains 全家桶 2022.2 发了，更新了一下 Goland，新功能乏善可陈，本期最大的更新应该是 runtime 从 jre11 切换到 jre17 了，得益于使用了 macOS Metal API，体感上确实流畅了一点。
Jetbrains 全家桶 2022.2 发了，更新了一下 Goland，新功能乏善可陈，本期最大的更新应该是 runtime 从 jre11 切换到 jre17 了，得益于使用了 macOS Metal API，体感上确实流畅了一点。
JetBrains
What's New in IntelliJ IDEA - 2024.2
IntelliJ IDEA 2024.2 Ultimate lets you run Spring Data JPA methods directly in the IDE for instant repository query verification. It also simplifies the management of cron expressions by providing inline descriptions and advanced autocompletion, and it upgrades…
https://deephaven.io/blog/2022/08/08/AI-generated-blog-thumbnails/
有点意思，使用 DALL·E 生成图片作为文章插图。
以前插入一张图是使用关键词去搜索引擎找，然后再给图片配上 alt。
现在是直接给 alt 配上一张图片，还能保证图片独一无二、风格一致，确实是革命性的。
有点意思，使用 DALL·E 生成图片作为文章插图。
以前插入一张图是使用关键词去搜索引擎找，然后再给图片配上 alt。
现在是直接给 alt 配上一张图片，还能保证图片独一无二、风格一致，确实是革命性的。
deephaven.io
I replaced all our blog thumbnails using DALL·E 2 for $45: here’s what I learned | Deephaven
Blog posts with images get 2.3x more engagement. Here’s the problem - we make a query engine for streaming tables. How the heck are you supposed to pick images for technical topics like comparing the similarities between Deephaven and Materalize, viewing…
https://hnpredictions.github.io/
通过爬虫抓取了 hacker news 上所有 prediction 发言。算是某种意义上的“自动挖坟”。得益于 HN 的高质量用户群体，看看几年前用户对科技政治经济的预测，还是蛮有意思的。
通过爬虫抓取了 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
radash - 取代 lodash 的工具函数库
看起来比 lodash 的代码质量更好更精简。由于使用 TypeScript 编写，相比 lodash 类型校验也更加完善。另外还加了一些基于 async-await 的工具函数。感觉不错。
https://github.com/rayepps/radash
Medium
Lodash is dead. Long live Radash.
Lodash is old and lame, Radash is new and kool. What more do you need to know?
最近一个体会是个人玩票项目 side project，尽量用一两个简单的工具完成核心功能就好了。千万不要引入一堆组件、工具链、外部依赖去达成一些炫酷的能力，产品为技术让一下步，鬼知道三个月后还能不能跑起来。
Forwarded from Cloudflare 在中国频道
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
从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 了
Vercel 把 pro 用户的单 repo 可绑定的 project 数量从 10 提升到 60，可以支持一个中型 monorepo 了
Vercel
Improved monorepo support with increased Projects per repository – Vercel
日常技术碎碎念
无意当中看到这个 issue。当我们使用 Notion 作为 CMS 搭建网站的时候，绕不开 Notion 的 S3 图片链接会过期的问题。因为图片会过期，静态生成的网页常常会加载不出图片。哪怕现在去看 Railway blog 依然可以发现有些图片加载不出来。 最简单的避免这个问题方法就是不要将图片 host 在 Notion 上，而是使用外链塞到 Notion 当中，但是比较麻烦，需要先上传图床再做插入。 Issue 帖主选择放弃 SSG，使用 SSR 渲染，可以保证每次下发的图片链接都是最新的，这肯定会导致网页加载慢（不能套…
最近实现了一个更加优雅的方案，就是将所有网页上面的 notion block （img/video/...）的 src 指向
这样一来，每一次浏览器都能跳转到未过期的资源链接，就不再需要任何外部 cronjob 去主动触发刷新了。
/api/resource/{block-id} ，这个接口每次被请求的时候都会请求 Notion API 去获取最新的 S3 链接，最后返回客户端 HTTP 307 重定向到资源地址，并使用 Cache-Control 保证最近一段时间内都不需要重新获取。这样一来，每一次浏览器都能跳转到未过期的资源链接，就不再需要任何外部 cronjob 去主动触发刷新了。
正儿八经地用 Github Codespaces 写了一段时间的代码，把本地开发环境用 Github Dotfiles 配置了一遍。
不得不说体验非常不好，期间无数次压住 clone 代码到本地直接用 IDE 打开的念头。
一方面我非常不习惯使用 VSCode 开发，即便是 VSC 强项前端开发，我也觉得是不如 Goland 智能响应快的。其实也试过通过 Goland 直接 SSH 到 Codespaces 开发，但这就有点脱裤子放屁了。
另一方面是网络不够稳定。虽然大多数时候是稳定的，但一旦碰到连接中断，可能会发现本地变更代码压根没法 commit，刷新一下网页，代码可能直接丢了。开发的时候无时无刻都会焦虑网络问题。
也好，彻底打消了购入 iPad Pro 念头。
不得不说体验非常不好，期间无数次压住 clone 代码到本地直接用 IDE 打开的念头。
一方面我非常不习惯使用 VSCode 开发，即便是 VSC 强项前端开发，我也觉得是不如 Goland 智能响应快的。其实也试过通过 Goland 直接 SSH 到 Codespaces 开发，但这就有点脱裤子放屁了。
另一方面是网络不够稳定。虽然大多数时候是稳定的，但一旦碰到连接中断，可能会发现本地变更代码压根没法 commit，刷新一下网页，代码可能直接丢了。开发的时候无时无刻都会焦虑网络问题。
也好，彻底打消了购入 iPad Pro 念头。
https://vercel.com/analytics
Vercel 收购了 Splitbee，把访客分析集成到了自家的 Analytics。对于个人项目来说也不需要专门去引入 Google Analytics 了。
一直想试试看 Splitbee，喜欢它的产品调性，现在省事了。
Vercel 收购了 Splitbee，把访客分析集成到了自家的 Analytics。对于个人项目来说也不需要专门去引入 Google Analytics 了。
一直想试试看 Splitbee，喜欢它的产品调性，现在省事了。
Vercel
Observability
At Vercel, our mission is to enable developers to build and publish wonderful, high-performant apps and websites. Learn more about Vercel here.
最近需要在数据库存储一批复杂的配置文件，需要原子化更新配置的内部字段的能力。一开始打算用 MySQL，有两个方案：
1. 整个数据结构序列化后塞在一行的一个字段里面。更新的时候在开事务（上行锁）整个读出来更新好写回去。
2. 根据数据结构，老老实实建模，各种 list 表，relation 表，每一个字段都是一列……多数情况下不需要用事务就能单独更新内部字段。
前者省事，但是不优雅；后者足够教条，但太麻烦了。
最后，还是换成了用 MongoDB，整个配置作为 document 写到库里，想怎么原子更新子字段就 怎么更新。虽然 MongoDB 更新文档本质上也是单行事务，但局部更新的语义支持确实比 MySQL 优雅。
1. 整个数据结构序列化后塞在一行的一个字段里面。更新的时候在开事务（上行锁）整个读出来更新好写回去。
2. 根据数据结构，老老实实建模，各种 list 表，relation 表，每一个字段都是一列……多数情况下不需要用事务就能单独更新内部字段。
前者省事，但是不优雅；后者足够教条，但太麻烦了。
最后，还是换成了用 MongoDB，整个配置作为 document 写到库里，想怎么原子更新子字段就 怎么更新。虽然 MongoDB 更新文档本质上也是单行事务，但局部更新的语义支持确实比 MySQL 优雅。