C++编译后，要在Editor点击重新生成Typescript的Stub Typescript继承UE的类名和文件名要一致

选型 客户端引擎：UE5.6+PuerTS。不选5.7的原因，主要是稳定，我的目的是实践动画相关的。PuerTS选个puerts_v8_94版本，兼容性稍微好点？ 服务器：大概率是NodeJS+TS。 其实Unrealsharp我也想试试，之前做一个Unity的项目的时候，感觉作为游戏开发确实挺顶的。而且能通吃服务端客户端。 PuerTS PuerTS官网的介绍相对简单，刚接触游戏开发或者TS的同学会有点困难。下面几点是我过程中碰过的一些坑： 尽量不要用git-master安装的方式，用Release包。可以避免配置Backend引擎的问题。例如文档上写的v8_10.6.194实际上在master是被移除掉了。而新的V11版本binrary目录又变了，看起来在调整中 UE最高目前支持到5.6。5.7因为某些接口变了，编译静态绑定会报错。 插件的目录要注意不要嵌套多一层。不然调用enable_puerts_module.js会报错 安装Node和NPM、进入到Puerts\插件目录，调用node enable_puerts_module.js，脚本会安装依赖和生成tsconfig。这个居然文档没有说，而且getting started.md的中文版居然是空的。 如果你使用VsCode，需要再添加一些Task，具体可以参考：UE5 从零搭建UE的puerts开发环境 如果你使用Rider可以将Typescript添加的工程，类似这样： 顺便开启tsc自动编译，如下： 那基本上环境的配置完了。Rider基本能完美识别符号，后续看开发过程再继续评估Rider是否适合作为AIO的IDE。 7. 要测试PuerTS是否已经work，可以创建一个GameInstance类： #include "ARDTsGameInstance.h" void UARDTsGameInstance::OnStart() { JsEnv = MakeShared<puerts::FJsEnv>(); TArray<TPair<FString, UObject*>> Arguments; Arguments.Add(TPair<FString, UObject*>(TEXT("GameInstance"), this)); // 可选步骤 JsEnv->Start("QuickStart", Arguments); UE_LOG(LogLoad, Display, TEXT("GameInstance::OnStart")); } void UARDTsGameInstance::Shutdown() { UARDGameInstance::Shutdown(); JsEnv.Reset(); } 然后在Typescript目录（跑上面js脚本时候生成的），建一个TS脚本(QuickStart.ts): import * as UE from 'ue' import {argv} from 'puerts'; let world = (argv.getByName("GameInstance") as UE.GameInstance).GetWorld(); console.log("World Name: " + world.GetName()); 最后在编辑器点ProjectsSettings替换GameInstancce为UARDTsGameInstance。点击Play运行，观察Log是否输出World Name:xxxx，输出成功的话，整个PuerTS的开发环境就准备好了。下一步就是正式开发逻辑了。

ResilioSync(AKA BTSync)在Docker容器部署无法Link设备。台式机和Macbook可以正常链接。 排插了半天，结论如下： 官方的Tracker和Relay在大陆是用不了的。 台式机和Macbook能正常链接和发现是因为在同一个局域网，依赖Multicast。 Docker的网络驱动默认是Bridge，无法接收局域网的Multicast，所以发现不了。 改用Host网络，容器的BTSync能正常链接设备。 官方不支持Custom Tracker和Relay，所以只能用Predefined Host来发现设备。少量设备其实还行，设备多估计很麻烦。

开始使用OB应该有4年，一直对OB的插件选用非常谨慎。以前除了一些必要的插件外，基本都不折腾，主题也不折腾。最近半年将笔记全切换到OB后发现以前的插件都有些问题，所以干脆就将这些插件都精简掉。顺便谈谈我对Obsidian目前的一些看法，以及去掉啥插件。 关于Obsidian一些看法 从2020开始到2025年的今天，Obsidian虽然说一直的保持着更新。期间也更新了不少的大功能，例如LiveEditor，Canvas，Bases等之类的。但是给人的感觉还是节奏太慢，OB现在跟5年前的核心功能几乎没有发生什么变化。 例如Cavanas虽然出来了，但是之后一直没有更进一步的扩展。感觉只是为了对标Heaptbase而推出的功能。Bases也是类似，而且还挤占了原来Dataview的生态位。 中文社区把OB宣传成一个自由灵活、全能的工具。什么任务管理、kanban之类的东西。实际深度使用后你会发现插件都会有各种各样的问题。 插件 这次我也发现了，OB许多插件生命周期似乎都在2年左右，2年之后就基本会被作者弃坑。即便是下载量在排在前面的。 Self-hosted LiveSync 曾经我认为这是一个很好的插件，配置方式也还行，支持实时同步支持移动端。使用了三年，最后决定还是放弃。原因： 我不会再移动端使用OB，同步功能可以选择其他的插件 虽然频繁维护，但是版本选项功能越来越多，文档说明也欠缺。 版本更新经常容易出幺蛾子。 二进制文件支持不好，所以我一直不敢在仓库放太多的图片。 同步的底层原理黑盒，文档描述不清楚。 最近这个版本更新之后，同步会导致编辑器卡顿，体验很差。 Local images 多年不维护了，本来也就一个很小的插件 Dataview 部分的功能被官方的Bases挤占。而且从原理上讲，Dataview的功能本来就有限，按照上面提到的原则，只把OB当成一个Markdown编辑工具，Dataview的功能就不再需要。 Admonition 被官方的Callout挤占了，几乎停止维护 Advanced Slides 这个插件已经不维护，虽然有一些Fork，看着活跃度还不错。但是本质这是一个Markdown编辑器，做PPT功能无论怎样都是鸡肋，只能说能快速顶上，用在一些不太严肃的场合。严肃场合的PPT还是得用Office做。 结论 Obsidian只适合当一个使用体验良好的Markdown编辑器。不要幻想用他来做All-in-one的PKM。插件生态持续性还有待观察。

结论 键盘作为消费品的前提下，选择X架构（剪刀脚）的静音巧克力键盘，作为程序员是非常合适。键盘作为一个工具，在特定群体中（程序员、游戏玩家）形成一种消费主义。 历史 2006开始“烧”第一个键盘，罗技的84键，巧克力，但是应该只是普通薄膜键盘，不静音。那个松垮的程度，我现在都还记得。不过当时没在意这么多，只是看中颜值。 2006-2013年中间一直用普通的薄膜键盘，用过戴尔、罗技的经典型号。 2013年开始看论坛，买了第一只机械键盘Noppoo 87 104红轴。 2015年买了一个静电电容 RK RC930-87。 一把IKBC X410，红轴短轴。 一把Noppoo青轴。 一把罗技的Craft。 苹果笔记本的键盘（初代Retina、M1 MacbookPro） 键帽ABS、POM、PBT都用过。 观点 手感上，剪刀脚键盘完胜。 剪刀脚行程短。传统的机械硬盘和静电电容高度非常高，打字手腕要抬很高。 反馈准确。 不费力。 声音清脆。 静音上，也是剪刀脚键盘完胜。作为一个没有独立书房的人，用过了Craft才知道以前的键盘有多吵。 清洁上，两个半斤八两。巧克力键盘的缝隙非常小，东西很难掉进去，但是清理确实很麻烦；相反，传统“玩家”类键盘都被设计成非常容易拆卸。相对应的几乎这些键盘缝隙都非常大。 耐用性上，剪刀脚键盘确实不如机械键盘。主要原因是集成度比较高，尤其是剪刀脚的键帽，拆开之后非常容易装坏。但是用个3-5年问题不大。键帽一般都是ABS，相对也容易打油。 键帽并不会提供任何加成，是消费主义的重灾区。

编译报错：Getting “error C4756: overflow in constant arithmetic”， 跟INFINITY常量相关。 原因：应该是新版的WindowsSDKINFINITY常量范围变大，导致溢出。 解决：通常出现在旧引擎用新的WindowsSDK编译，安装和修改WindowsSDK版本即可。

前言 最近赋闲在家（被迫），有时间可以看一下一些UE的新技术。其实Horde和UBA对我来说也不算特别“新”，我大概是在2025年初的时候就知道有这么个东西。不过当时心思不在，就没去折腾。昨天在B站虚幻引擎看到介绍，就搭建了使用一下，整体效果还不错。对于Homelab，能有效替代Incredibuild免费版。对于大型团队，复杂的网络环境，有待验证。 Horde和UBA是什么 做过游戏项目的都知道，打包、测试、发布这几个流程是非常折磨人的。不管是什么引擎（UE更甚），几乎打打包都需要耗费大量的时间，尤其是版本日（估计行业内看到这个词都PTSD）。我在这里姑且先不讨论打包为什么需要这么久。Horde和UBA就是EpicGames提出一个解决方案。 UBA提供联机编译，替代的是IncrediBuild的生态位，目前支持Shader和C++联机编译。相对IB，UBA的功能更加简单、纯粹。它只提供联机任务执行的框架，其他IB的例如节点管理、节点发现等都是由Horde提供。 而Horde相对来说更加复杂，提供了很多功能，后面会针对这个功能逐一细说。关于这两者的安装和使用，以下这两篇文章12基本都提到了。唯一的区别是我是Docker安装Horde服务器，也很简单，官网有参考的Compose文件。 唯一需要注意的是，Project范围的BuildConfiguration.xml似乎没生效；在用户目录下有个BuildConfiguration.xml，在那里修改UBA和HordeServer才生效。 联机编译 性能初略测试 测试了两遍，3700X+5950X，全新编译Larya（不包含引擎），大概2分钟。 全引擎编译重编（Build All），UE5.7Release全新checkout的代码代码，3700X+5950X+E3 1280，大概是2个小时30分钟。 全引擎编译重编（Build All），UE5.7Release全新checkout的代码代码，3700X+5950X+E3 1280+8809G，编译时间2小时。Build completed at 22:46 and took 02:02:55.179 hours 带有一个简单UBA Visualizer如下图： 结论 对于目前有限次测试来说还是很稳定的，Horde基本没出现挂掉的情况。偶尔会出现Agent连开以后又断开，原因暂时未知。 免费、不限CPU数量很香，比IB的免费版香太多了。 安装难度比IB麻烦一点，要先装一个Toolbox，然后再安装Agent，还要改BuildConfiguration，如果能都集成在Toolbox就完美。 观察到发起编译的机器也会被Horde分配到联合编译当Helper，相当于发放了两倍任务。虽然总体完成时间不会有太大差异，但是内存占用是实打实翻了一倍。 单核性能太弱鸡的建议不要放到Pool里面。最后几个任务总会拖后腿，高性能的机器总在等待，最长有10-20秒。 分发的启动稍微有点慢，参考图1，基本发起要在Initiator编译完1.5轮以后才全部连接上。不过其实IB也是这样，分发的策略也保守。 CI/CD Horde还有一个很重要的功能，就是提供CI/CD。本来看视频的时候还寄予厚望能替代Jenkins，没想到还是一个要靠编辑服务器JSON写流程。对于协作来说没有可操作性，不过文档看起来还挺Promising的，后面有机会可以试试。 不过相比于完善编辑器，我觉得更加希望可以将其他步骤都进行分布式，尤其是Cooking，这个才是日常打包耗时大户。 设备测试 可以连接移动端的设备。除了跑自动化测试框架之外，似乎还能跑Job，暂时还不清楚怎样跑Job，有什么能力。 工作室遥测 这个其实是一个相当有用的概念。它可以测量编辑器在工作室内部的卡点，有什么特别耗时的地方。不过对于Horde的统计和分析能力我觉得是要打个问号。仅从文档来看，只提供了一些Charts的定义方式，远不如传统的ELK分析灵活。不过还好Horde也提供了透传日志的功能，算是额外的扩展。 我觉得更有价值的是编辑器提供打点的插件。简单搜了一下UE5.7的代码，目前提供的打点不少。工作室内部在这个基础上扩展肯定有一番作为。 总结 我觉得Horde和UBA算是开了一个很好的头，EpicGames也意识到天下苦打包久矣。对于低成本的公司、工作室，通过免费的联机编译作为“诱饵“，吸引他们入局使用，然后提出意见修改，算是比较好的切入点；相反，对于已经购买IB授权的大公司，这个诱饵对他们的吸引力不强。而其他功能也没能完善到开箱即用、非用不可的地步。 如果能投入更多的人力，把分布式Cooking搞掂，Horde才能实现自己更多的野心。 UE5.4 UBA分布式构筑和打包 初探 ↩︎ 虚幻5 Horde服务安装和配置 ↩︎

在7月份的时候用beancount重新建了一个账本，然后到现在一直没有对过帐。想自己写一些脚本和自动化工具导入账单。在花了两天时间写完了基本导入和研究前人的代码后，突然意识到这个自动导入其实是伪需求。 个人记账的本质是什么？ 记录汇总 当我们做了一笔交易后，支付平台、银行已经为我们记下一笔永久记录。我们为什么要费劲将这笔记录转移到我们的账本上呢？很大一部分原因是现代支付平台、银行是多种多样的。我们需要一个在自己视角的汇总支出、收益的总览。如果只是为了满足这一点，自动导入是有一定的帮助的（局限我在下面详述）。 财务回顾 可能大部分人都忽略在记账过程中另外一个作用，就是对这段时间的支出进行回顾。就像复习一样，我们记了笔记，就要回顾。自动导入账单虽然能帮助我们汇总，但是无法替代人工记账时的回顾、思考。你可能会说，那我导入了之后在进行回顾不就行了吗？这里面有两个问题： 自动导入一般周期都在一个月，时间相对已经比较长了，很多交易你已经无法记忆清楚，只能机械入账。 过程越自动化，回顾的倾向就越容易忽略。举个例子，如果是要命令行导入账单的，你可能导入之后还会预览一下；如果是机器人导入的，你可能心安理得的导入完就结束了。 自动导入的问题 自动导入的分类方式局限性。现在大部分的导入账单都是通过配置收款人->支出账号来进行映射。好一点的还可能会有一些规则。理论上，这些规则是只需要添加一次，并且通过不停添加规则达到收敛。当然，这种收敛只是美好的想象，事实是，你可能通过微信扫码，扫不同商家；淘宝上，会和不同的人交易。这些人大部分都是只交易一次，但是规则添加和修改就会变得无法收敛。 同样是规则问题，你无法通过简单的映射总结出每一笔交易的性质。其实你看现在微信账本和支付宝的收支统计就清楚。所有的分类或多少或少都有错误。当你看到某个类目的支出超出你预期的时候，你会点进去才发现归类错误。 一比一的导入会导致大量冗余。就我目前举例，我早上起码会做6-7笔扫码支付，实际上都是用于买菜，支出分类都是同一个类目，自动导入会一笔笔的记录，并归类到分类目录（如果归类正确的话），会产生大量的冗余。长期来看账本的性能会衰减。 修改规则困难。正如上面说的，规则需要经常迭代。当导入出现问题，要浪费不少时间处理。如果只是简单的加规则还行。如果是新的交易方式，需要调整导入代码的，恐怕不是一时半会能解决的。 所有支付平台、银行似乎都不太愿意提供账单。虽然可以通过邮件等方式获取，但似乎也过于麻烦了。 实际每日的支出笔数，人工对账耗费的时间只要15分钟。一个月一次可能也只需要1小时。比起自动导入需要的维护时间成本，可能更少。 Update（20251111）： 你不知道什么时候需要导入账单；不能自动化断言账号余额。

Update(2025-09-27): 453B Mini 已经卖了，彻底跟威联通再见！ 终于要放弃使用多年的QNAP 453B Mini。虽然这不是我NAS的启蒙设备，但是我这几年Homelab经历中第一台成品NAS，也有可能是唯一一台成品NAS。 不再使用这台NAS并不是硬件损坏。相反QNAP的硬件一向性价比都不错，虽然J3455CPU确实有点落后，但是16G的“大”内存也刚好适应家庭Homelab的“低载多服”的环境。真正让人诟病的是QNAP的系统。 过高的系统定制性 无论是以前的QTS还是现在最新的QuTS Hero和QuTS Cloud，都是经过厂商深度定制的Linux系统。从内核到Shell、设备配置方式都是高度定制的，而且是脱离时代的。 Shell是Busybox，Linux大部分的工具不齐全，虽然有个半官方的Entware可以补充一些Shell工具，但是更新也是极其慢。 ContainerStation脱离Webgui就非常难用，很多东西也是裁剪过。 内核也是定制的，导致文件系统不通用，V2ex就有案例，系统坏了之后因为内核定制的文件系统驱动导致其他Linux无法读取。 系统服务的管理方式像上个世纪的Linux。 这些问题使得QNAP脱离了WebGUI后基本没办法，但是WebGUI却有更多的问题。 莫名奇妙的高负载 在使用这个设备的时候经过很多次莫名其妙的高负载。 最近也是，只要打开WebGUI，系统负载立马飙到10-17，这是一个4核的CPU啊，我差点卡得Shell都动不了。 而且原因也莫名奇妙，CPU负载不高、IO负载也不高，但是就是卡。 WebGUI跑的也还是CGI，这个请求慢得不行。 安全性 这个不详细说了，2024-07-03-Homelab安全建议里面有提到，0Day漏洞毫不在意。 散热欠佳 这个算是这个设备的硬件问题，453B-Mini只有一个定速风扇。 没有任何优势 传统意义上，成品NAS优势在于周边服务的提供。但是QTS的周边服务真不行，照片管理不行；APP稀烂不改进；风口在哪里就开坑，现有的坑绝对不填。 提供的代理服务也有免费的CF和EdgeOne替代。 DDNS有自己的域名，证书也有自己的Let’s Encrypt。 它唯一的优势就是我在6年前花“重金”购买了它。给了它多次的机会依然拉跨，既然如此我还是算了，何必折磨自己。以前单个硬盘容量低，又有空间需求，所以还能增加盘位。现在本地只存必要数据，电影备份到云，单盘容量又高，似乎已经没有留下来的必要。 最后建议 对于习惯使用Linux的同学，真心不建议入成品NAS。如果真的要入，慎重考虑QNAP。他的这套WebGUI、系统底层已经沿用很多年，并且从目前来看，并没有革新的打算。观察了最新的系统，也是修修补补。 至于国产NAS系统，我只能说你信任我推荐，我不信任。Alist、iKuai事件历历在目，国产软件的下限有待观察。 补充 由于NAS已经出售，这里补充一些之前使用时候碰到的问题作为总结归档，留后人参考 威联通NAS(QNAS)的DDNS域名在国内部分地区解析失败以及解决办法 使用ddns中的别名，增加*.mycloudnas.com的子域名，该子域名支持let’s encrypt 证书 新的AMIZCloud导致负载过高 机型版本：453BMini;QTS 5.1.7.2770; AMIZcloud Agent 2.2.0517 表现：CPU实际占用不高，但是LoadAvg基本维持在9+（对于一个4核CPU来说已经好高了），甚至飙到20+直接卡死。 解决办法：查了一圈，实际LoadAvg代表的是有多少进程在等待状态。看了一下IO也没多少Wait的。想到最近更新了一个AMIZCloud的插件，闲得没事装了试试。该APP嫌疑，遂卸载之，发现LoadAvg已经降到0.x，问题解决。具体的原因没再深入排查，可能是AMIZCloud采集某些数据导致内核负载高。（PS：不卸载，只在QnapCloud中关闭上传采集没有用处，必须卸载掉App） 威联通nasqnas的ddns域名在国内部分地区解析失败 大概在半年前，发现手机的Joplin无法同步QNAS中的笔记。一顿排查后居然是5G的网络用的DNS服务器202.96.128.166和202.96.128.86这两个解析*.myqnapcloud.com失败，全部返回127.0.0.1，详情看[这里][1]。 保障到中国电信，反馈该域名没有在白名单中，需要域名的拥有者申请。遂联络QNAP的HelpDesk，客服反馈很积极，但是由于这个只有部分地区有问题，而且他们也不清楚电信那边具体要做什么。他只能建议我用中国区的域名，问题是最近中国区的域名也不是很稳定，解析从myqnapcloud.cn切换到mycloudnas.com了。最后只能放弃。 直到今天看到cloudlink的app更新了，看了一眼CL，其中有一条: Added support for adding 3 DDNS alias names using mycloudnas.com. 是不是全球的也可以用mycloudnas.com这个域名了？加了一下别名，还真的生效了，而且电信也能正确解析了，而且let’s encrypt 的证书也支持两个别名，困扰半年的问题终于解决了。PS：反代也需要重新更新一下证书（重启就行）。