TIL：以 root 安装 GBase，用 gbasedbt 初始化实例
DEV
GBase 8s 在 Linux 上手动安装时，文档里一句“不要用 root”常被误解成不能用 root 安装。这篇 TIL 澄清了两件事的边界：软件安装与实例初始化是两个独立步骤——可以以 root 完成二进制文件与目录的安装，但数据库实例必须由 gbasedbt 用户初始化并持有，否则后续属主、权限和启动脚本都会出问题。对第一次在信创或国产数据库环境落地的 DBA 来说，这类权限模型差异是最常见的踩坑点，文中给出了对应的操作顺序。
你的免费服务器会忘掉一切：六个部署误区与一次重启演练
DEV
在免费服务器上跑通一个 demo，第二天数据全没了——进程没崩，也没有任何告警，只是被平台重启了。作者据此拆解六条常见部署误区：把内存当存储、把免费层当生产环境、假设进程不会被回收、忽略启动脚本的幂等性等，并给出一套“重启演练”：主动杀掉进程、重启机器，观察数据与状态是否还活着。对小团队和个人项目来说，上线前花十分钟做一次重启演练，比事后补监控便宜得多。
用 Unity 把游戏发布到 Google Play：构建设置、keystore 与 AAB 导出
DEV
Unity 开发者习惯在编辑器里工作，但把游戏发到 Google Play 要穿过一层 Unity 帮你隐藏的 Android 构建工具链。这篇指南按顺序拆解：Android 平台的 Build Settings 配置、keystore 的生成与保管（丢失后无法更新已上线应用）、用 AAB 导出替代旧式 APK、Google Play 强制的 64 位架构要求，以及商店 listing 的准备。对第一次独立上架的开发者来说，keystore 与 64 位两条最容易在审核阶段被卡住。
用可复用的 Python 组件构建 pandas PDF 报告
DEV
月度产品报告通常包含标题、汇总指标、明细账和页码这几块固定结构，正好可以拆成可复用的 Python 组件。这篇文章以一个 pandas DataFrame 为数据源，用若干函数拼出三页 PDF：首页放标题与核心指标，中间是明细，页脚自动编号；同一套数据还顺带导出带样式的 HTML 与无样式版本。对每周都要手工复制粘贴做报表的团队，把这套组件沉淀成脚本，往往比换一个 BI 工具更快见效。
3-2-1 备份法则：面向个人与小团队的实操指南
3-2-1 法则：至少保留 3 份数据副本、存放在 2 种不同介质上、其中 1 份放在异地。文章面向个人和小团队，把这条规则落到可执行方案：本机一份工作副本、外置硬盘或 NAS 一份本地备份、再加一份云上或异地副本，并强调“恢复演练”与备份本身同样重要。多数人是在笔记本开不了机、手机掉进湖里或共享文件夹被误删的那天才发现备份策略根本不存在，而按文中步骤一个下午就能搭完。
科技爱好者周刊（第 415 期）：3D 版《看不见的城市》
阮一峰《科技爱好者周刊》第 415 期发布，封面主题为“3D 版《看不见的城市》”。周刊每周五更新，固定收录一周内值得分享的科技动态、工具与资源、文摘和读者留言，是中文技术社区里连载时间最长的个人周刊之一。对开发者来说，它的价值不在快讯，而在于选题口径：能被它选中的工具和文章，往往代表接下来一段时间值得投入注意力的方向。
补丁里加了一个 sleep：合并前先审时序与重试的那些 hunk
DEV
关于“偶发失败测试”的争论，通常在合并之后才开始，而更便宜的做法是在合并之前介入。作者主张评审补丁时先读它对时序、重试和跳过逻辑改了什么：多加的一次 sleep、被放大的一处 timeout、被悄悄 skip 掉的用例，往往才是 CI 不稳定的真实来源；随后只在改动前后两棵代码树上重跑被触及的测试，而不是整条流水线。对每天被 flaky test 消耗的团队，这套评审习惯能把定位成本大幅前移。
刻画边界，而不是刻画模块：混乱重构中的导入图闸门
DEV
重构一个混乱仓库时，为整个模块补特征测试（characterization test）通常要花上几周，而且很快会随代码腐化。作者提出的规则是：只针对其它模块 import 的那些符号建立特征测试，然后再动手改其中一个。边界比模块小得多，可测、稳定、维护成本低，而且它恰好就是对外契约所在。对正在接手遗留系统、又不敢大改的团队，这是一种把风险切小、能逐步推进的重构节奏。
把决策模型放进 agent 循环内部，而不是放在旁边
AI
搭一个 agent，再统计 token 到底花在哪里，会发现相当大一部分不是“干活”，而是 agent 在不停问自己小问题：这个工具调用安全吗？这份文档回答了问题吗？要不要转人工？输出格式对吗？作者因此主张把决策模型放进 agent 循环内部，而不是挂在旁边做后置校验，让判断发生在每一次工具调用之前。对正把 agent 推上生产的团队，这直接决定延迟、成本与可控性。
要的是草稿权限，不是草稿质量：把“模型能写什么”和“人能签什么”分开
AI
文档里代价最高的缺陷，往往不是句子写得笨拙，而是一句没有任何有签署权限的人批准过的承诺——关于退款政策、速率限制的流畅表述，看上去和普通段落毫无区别，质量评审照样会漏掉。作者提出以“草稿权限”而非“草稿质量”作为门禁：区分模型可以写什么、人类必须签什么，用权限边界替代文风检查。对已把 LLM 接进文档流水线的团队，这是把合规责任固定到人的一种工程化做法。
今天的来源集中在 Dev.to 与个人周刊，没有一条符合“GitHub 热门项目”的收录标准，dev 分类因此空缺。宁可空着，也不拿泛技术帖充数——这本身也是个信号：项目热度正在从单一榜单，分散到博客、周刊和社群的口口相传里。
“补丁里加了一个 sleep”和“刻画边界”两篇，共同点是把质量成本前移：flaky test 与重构风险都不是合并之后才出现的问题，而是评审时没人读懂那段 diff。工具链再花哨，也替代不了逐行读代码这一步。
AI 侧两篇指向同一件事：把判断放进流程内部，把签署权留给人。agent 的决策模型、文档的草稿权限，本质都是给模型划一条可审计的边界——这大概会是很长一段时间里 AI 工程化的主线。