Hexo

这次本来想把博客的文章目录结构彻底整理一下。 起因很简单：有一篇文章需要附带两个可公开访问的脚本。如果脚本继续放在单独的 source/files 里，文章和资源会分开；如果脚本放在 _posts 的同名目录里，目录又会慢慢变多。既然迟早要给博客定一个长期规范，不如趁这个机会把文章 URL、文章源码和相关资源一起想清楚。 最理想的样子大概是这样： source/_posts/webstorm-ea

有些小项目很难被正式归到某个业务仓库里。 它可能是一组给自己用的脚本，一个本地知识库，一套 AI 工具的 Skill，也可能是一份还没成熟到要进入团队工程体系的内部资料。它确实有价值，也确实需要长期维护，但它又不像正式业务项目那样天然有一个远端仓库可以放。 最理想的做法当然是建一个私有 Git 仓库。Git 能保留提交历史、分支、作者信息和变更差异，也方便多设备同步。 但现实里经常会遇到两个限制：

WebStorm 升级 EAP 版本时，经常会遇到一个有点尴尬的提示：某个插件不兼容，要求 IDE 内部版本必须是某个 build 或者更低。 这类提示不一定说明插件真的跑不了。 JetBrains 插件包里通常有一个 META-INF/plugin.xml，里面用 <idea-version> 声明兼容范围。比如： <idea-version since-build="253"

最近开始认真考虑一个问题：Codex 里沉淀下来的东西，应该怎么长期保存？ 一开始，做法很朴素：把一些重要目录打成 zip，上传到云盘。这能兜住「电脑坏了怎么办」「换设备怎么办」这类问题，但不适合长期维护： 每次备份都是一个新的压缩包，不容易看差异。 只知道「备份了」，但不知道具体变了什么。 想回到某个历史版本，需要先下载、解压、人工比较。 想在多台设备之间同步，也不够自然。 压缩包更像一个快

文件遍历看起来是一个很小的问题。 写进工具后，它往往会变成一串细节：要不要递归、要不要只要文件、要不要包含 dotfile、符号链接怎么办、输出路径是系统路径还是 URL 路径、Windows 反斜杠要不要处理、远端对象存储需要什么 key。 这次问题来自一个发布脚本：Hexo 生成 public 目录后，需要把里面所有文件上传到 OSS。ali-oss 提供的是上传单个对象的 API，不能把「上

最近在用 Codex 做比较长的工程任务时，遇到一个很现实的问题：Codex 的体验很好，但额度并不是无限的。 如果一个任务要长时间读仓库、查资料、反复写文档、跑验证，Codex 的周额度和短周期额度会降得很快。与此同时，Cursor 那边也有 Agent 和 GPT 模型，额度按月算，池子更宽裕。直觉上，这两边应该能配合起来：Codex 负责我真正想待着的主工作台，Cursor 负责分担一部分可

看一些成熟开源项目的 Git 历史时，经常会看到一条很干净的线： 主干上的每个提交都像一次完整的变化。它不太关心开发者中途修了几次 bug、改了几次 lint、补了几次测试。 再看一些日常项目，历史经常会乱很多： 一堆 Merge branch ... 之类的信息。 一个需求里混着很多 fix、update、test、临时提交。 不同需求的提交交叉在一起，想回滚一个需求时很难判断到底要撤哪些提

刚从 Windows 切到 Mac 时，最别扭的往往是手已经习惯了另一套键位。 复制、搜索、刷新、锁屏、终端中断、鼠标滚动、触摸板手势，这些动作每天会重复很多次。只要有一个按键不顺，就会一直打断工作节奏。 这是一份把 Mac 调顺手的记录，不是「Mac 必装软件大全」。大方向是：外接 Windows 键盘尽量保留原来的手感，Mac 自己好用的地方也别硬拧回去。 截图来自当时的系统版本。不同 mac

本文为已获授权的原文转载，原作者：Marine。正文除标注为「编者补充」的小节外，仅做段落、标点、链接与代码格式整理。 一、基本概念以下命题，哪些为真，哪些为假？ 一年总有 365 天。 一天总有 24 小时。 一分钟总有 60 秒。 地球上所有人当前的时间都一样。 历法时间总是连续、单调向前的。例如，2012-03-25 01:59:59 的下一秒一定是 2012-03-25 02:00:

定时任务一开始通常都不复杂。 比如每隔十秒轮询一次接口，用 setInterval 就能写完。可需求一旦变成「每天上午 10 点执行」「周一到周五 9 点半执行」「每月 1 号同步报表」，手写时间判断就会开始绕。 这时候一般会换成 cron 表达式。它不负责让任务变得更可靠，只是把「什么时候跑」这件事写得更像时间规则，而不是一堆日期计算。 Node.js 里可以用 cron 这个包把 cron 表