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 优雅。
https://github.com/topgrade-rs/topgrade
一条命令更新各种包管理中的包，包括 homebrew/zsh插件/pip/npm/docker镜像等等，不更新会死星人感到舒适。
一条命令更新各种包管理中的包，包括 homebrew/zsh插件/pip/npm/docker镜像等等，不更新会死星人感到舒适。
最近体验 railway.app ，试着部署了些服务，说一些感受：
⁃ 类似 Heroku，服务实例不会被销毁，不会出现冷启动的问题。
⁃ 计费是按照 CPU 和内存用量+耗时来计算，每个月消费低于 $5 不收费。
⁃ 不启用付费计划（绑定信用卡）的话，每个月也有 $5 的额度，但是会限制实例每月总在线时长 500 小时（21 天），也就是说想长期部署服务必须启用付费计划。
⁃ 可以部署数据库 （PG、MySQL、Redis、MongoDB），还支持在前端访问和操作数据库。不过目前没有看到数据库扩容、备份等功能，感觉就是单纯的提供一个数据库容器实例，不适合用于生产。
⁃ Railway 当中有 Project 的概念，一个 Project 可以有多套环境、部署多个服务/数据库，很像 K8S 的 Namespace，适合用来做业务隔离。
⁃ 会自动识别项目中的 Dockerfile 构建镜像部署，构建速度也比较快。
⁃ 和 Vercel 一样，不支持 VPC，也就是说如果做服务间调用，服务只能通过公网域名来互相访问，比较不安全。不过这个功能在 roadmap 中已经是 WIP 状态，可期。
⁃ 不保留历史日志，需要依赖像 logtail 这类外部日志服务做日志存储。
⁃ 不支持 cronjob，文档里给的解决方案是起一个实例自己调度……
总的来说，对于个人开发来说，Railway 体验还可以。但毕竟是一家只有两年的创业公司，平台功能和文档建设还是不够完善。
⁃ 类似 Heroku，服务实例不会被销毁，不会出现冷启动的问题。
⁃ 计费是按照 CPU 和内存用量+耗时来计算，每个月消费低于 $5 不收费。
⁃ 不启用付费计划（绑定信用卡）的话，每个月也有 $5 的额度，但是会限制实例每月总在线时长 500 小时（21 天），也就是说想长期部署服务必须启用付费计划。
⁃ 可以部署数据库 （PG、MySQL、Redis、MongoDB），还支持在前端访问和操作数据库。不过目前没有看到数据库扩容、备份等功能，感觉就是单纯的提供一个数据库容器实例，不适合用于生产。
⁃ Railway 当中有 Project 的概念，一个 Project 可以有多套环境、部署多个服务/数据库，很像 K8S 的 Namespace，适合用来做业务隔离。
⁃ 会自动识别项目中的 Dockerfile 构建镜像部署，构建速度也比较快。
⁃ 和 Vercel 一样，不支持 VPC，也就是说如果做服务间调用，服务只能通过公网域名来互相访问，比较不安全。不过这个功能在 roadmap 中已经是 WIP 状态，可期。
⁃ 不保留历史日志，需要依赖像 logtail 这类外部日志服务做日志存储。
⁃ 不支持 cronjob，文档里给的解决方案是起一个实例自己调度……
总的来说，对于个人开发来说，Railway 体验还可以。但毕竟是一家只有两年的创业公司，平台功能和文档建设还是不够完善。
Railway
Railway is an infrastructure platform where you can provision infrastructure, develop with that infrastructure locally, and then deploy to the cloud.
BFF 这个概念，宣传上要接管各种仅为前端服务的脏活累活，让业务服务专注运行逻辑。但是实践上 BFF 层又推崇尽可能薄。
往往会能看到两个极端。业务服务定义了一堆专为前端服务的 RPC 接口，BFF 沦为 API Gateway。或者是 BFF 包含了非常重的业务逻辑，业务服务沦为 CRUD 执行器。
往往会能看到两个极端。业务服务定义了一堆专为前端服务的 RPC 接口，BFF 沦为 API Gateway。或者是 BFF 包含了非常重的业务逻辑，业务服务沦为 CRUD 执行器。
日常技术碎碎念
最近体验 railway.app ，试着部署了些服务，说一些感受： ⁃ 类似 Heroku，服务实例不会被销毁，不会出现冷启动的问题。 ⁃ 计费是按照 CPU 和内存用量+耗时来计算，每个月消费低于 $5 不收费。 ⁃ 不启用付费计划（绑定信用卡）的话，每个月也有 $5 的额度，但是会限制实例每月总在线时长 500 小时（21 天），也就是说想长期部署服务必须启用付费计划。 ⁃ 可以部署数据库 （PG、MySQL、Redis、MongoDB），还支持在前端访问和操作数据库。不过目前没有看到数据库扩…
前几天对信用卡账单的时候，惊讶地发现上个月 MongoDB Atlas 托管数据库扣了将近 200 刀。可能是因为上个月部署了些 cronjob，对数据库用量比较大。但几个小服务产生这么高的消费还是不能接受的。
想着 MongoDB Atlas 是用不起了。但暂时找不到 MongoDB 托管的替代品，试着在 Railway 上起了台 MongoDB 托管实例。把老数据 dump 过去并重启了所有相关服务，完成迁移也就十分钟。
刚看了一眼 Railway 的 Usage 统计，根据每分钟的 CPU/MEM 的平均用量，预估了当月费用，一个月不超过 5 刀 🫠 （比根据读写次数计费划算多了）。
不过如之前所说，Railway 对数据库的可用性没有强的保证，也没有显式的数据备份解决方案。打算先用 Github Action 写个定时 dump 数据库保存到 S3 的脚本，临时先用着。
想着 MongoDB Atlas 是用不起了。但暂时找不到 MongoDB 托管的替代品，试着在 Railway 上起了台 MongoDB 托管实例。把老数据 dump 过去并重启了所有相关服务，完成迁移也就十分钟。
刚看了一眼 Railway 的 Usage 统计，根据每分钟的 CPU/MEM 的平均用量，预估了当月费用，一个月不超过 5 刀 🫠 （比根据读写次数计费划算多了）。
不过如之前所说，Railway 对数据库的可用性没有强的保证，也没有显式的数据备份解决方案。打算先用 Github Action 写个定时 dump 数据库保存到 S3 的脚本，临时先用着。
之前通过 DHCP，把全家的所有设备的网关指向软路由（openclash），从而实现翻墙。不过最近发现 homekit 的稳定性不太好，家居中枢经常掉线。想了一下大概是 openclash 连接代理服务器本身稳定性不够。
于是在路由器上通过 dnsmasq，调整了 DHCP 配置，只将部分设备的网关指向软路由。考虑 homekit 本身可能也有翻墙需要，故两个家居中枢，一个（homepod）留在了墙内，一个（apple tv）开启了翻墙。
这样一来，整体稳定多了。
于是在路由器上通过 dnsmasq，调整了 DHCP 配置，只将部分设备的网关指向软路由。考虑 homekit 本身可能也有翻墙需要，故两个家居中枢，一个（homepod）留在了墙内，一个（apple tv）开启了翻墙。
这样一来，整体稳定多了。